RE: User account

[Hans-Albert Schneider]

Sorry, this has become very long, but it answers Andrew's
questions from several mails.


>>>>> "Andrew" == Andrew  <address@hidden> writes:

    Andrew> I certainly do not want all our users/reports share
    Andrew> the "gnats" user account. The "gnats" is now as an
    Andrew> admin account, it owns everything. How can I easily
    Andrew> set user accounts individually in GNATS for them to
    Andrew> report PRs?  otherwise how can they login to GNATS?

The UNIX/Linux account "gnats" owns the database(s), some tools
are SUID (set-user-id) to it, and (x)inetd starts the gnatsd to
run under that account.

The GNATS users login to the gnatsd which authenticates them by
checking (gnatsd.host_access and) gnatsd.access.  You can
consider this similar to a database management system--the
database runs under a certain userid of the operating system, but
for its internal purposes it has a user database of its own.

Like the communication with the DBMS (or with a remote sendmail
of ftpd), the communication with gnatsd follows some protocol
which results in some changes in the PR database (adding a
report, changing its state or its responsible, etc.).  The users
do it via this protocol (of course, usually the clients do it on
their behalf), so they do not get a shell or anything else that
requires them to have a system account.

Similar for PRs arriving via e-mail.

 
    Andrew> and build the state-change logic?
    >> I am not sure what you mean.  The default dbconfig file
    >> logs any change to the state of a PR, forced by

    Andrew> [...]  For example, if a PR current state is
    Andrew> "Working", then if a user edits the state, the states
    Andrew> shown in web display page should be either "Working"
    Andrew> or "Solved", no other state should be shown for
    Andrew> choose.

I see.  Sorry, I have no idea how to do this with GNATS.  On the
other hand, I did not yet play with GNATS 4.0, and it changed a
lot compared to 3.111 (which I still use), so there might be some
way.  (Any suggestions, anyone?)

(Hmm, maybe you can use dbconfig to force a value if a wrong one
is given.  See the "on-change" examples in the default dbconfig.
Just an idea.)


    Andrew> I need to modify gnatsweb display to ensure my
    Andrew> "states" are correctly shown in the web page; or when
    Andrew> I modified the "state" file, all the changes will be
    Andrew> automatically picked up by the webpage display
    Andrew> functions so to display my states?

The idea is that you modify the "states" file, and the clients
(gnatsweb, tkgnats, ...) learn it from the server.  As gnatsd is
started (via inetd, xinetd or similar) anew for each connection
(including each invocation of gnatsweb via the web server, I
expect), the changes take effect immediately.

For the restrictions concerning the state transitions, it should
be possible to implement them in gnatsweb; however, there are
different clients, and you probably need to make sure no change
can be made via tkgnats, emacs.el, e-mail, and maybe others.  Not
to forget gnatsweb on other servers.


    Andrew> 1, I now want to eliminate the "Priority" field and
    Andrew> change the "Categories" to "subsystems" etc. I can
    Andrew> edit the "dbconfig", but I also need to edit the
    Andrew> "gnatsweb.pl" I guess.

Gnatsweb and other clients should learn these changes from gnatsd
(like with the "states" file), so there is no need to modify
them.  Only edit the display name but keep the builtin-name; e.g.


field "subsystems" {
    builtin-name "category"
    description "Subsystem concerned"

    ...
}


    Andrew> Are there any other files involved?

Those given in dbconfig ("states", "categories", "responsible",
etc.).  As they are given in dbconfig, you can of course change
their names.  You can also change the fields they contain, which
of them is the key, etc.  From a quick look into the dbconfig
grammar, my impression is that two things cannot be changed about
these files: "#" character starts a comment, and ":" is the field
separator.


Concerning fields "Priority" and "Severity", please do not remove
them (renaming should be OK).  On arrival of a new PR, these two
fields are checked and, if they indicate some importance, an "at"
job is started that reminds the responsible after some time if
the PR is still in its initial state.  The length of this time
period is specified in the submitters file.  See my mail earlier
this month.

Unfortunately, the check is still hardwired.  Removing these
fields caused strange effects.


    Andrew> 2, I found that in my server, there are two
    Andrew> "gnatsweb.pl" files under "/var/www/cgi-bin" and
    Andrew> "/usr/local/apache/cgi-bin" respectively. Which one I
    Andrew> need to change?

Easiest case: one of them is a soft link to the other.  Then they
are actually the same.

Otherwise, look into the Apache configuration.  Look for a file
httpd.conf in /usr/local/apache/etc or /usr/local/apache/conf, or
in /etc/httpd.  There may be other places, depending on your
Linux distribution :-(.

In httpd.conf, look for lines reading "ScriptAlias /cgi-bin/ ..."


    Andrew> Hi Uma,

    Andrew> I just can not control the access permission. I tried
    Andrew> several methods, but it seems to me the GNATS just
    Andrew> ignores the "gnats.access" access-level. at the login
    Andrew> prompt, anyone can login and edit. Can you help me
    Andrew> this?

Gnatsd does a two-step authentication: First, it checks whether
the remote machine (in this case, your WWW server) has
permissions higher than "deny" (in GNATS 4, this is configured in
gnatsd.host_access; in GNATS 3 the file was gnatsd.conf).  When a
user logs in, it checks the permissions of the user.  The
permissions used for access checking are the *higher* of the
two--in other words, the permissions given to a user can only
*increase* those given to a host, not *decrease* them.

So the solution is not to give "edit" access to your web server
(nor to your whole domain!), but to use "listdb" or "view" or
"viewconf", and increase this to "edit" for the desired users via
gnatsd.access.


    Andrew> [...] I removed the line of *:*:view already.  The
    Andrew> only two lines valid are: (see my last email
    Andrew> attachment)

    Andrew> azhuang:andrew:edit:
    Andrew> *::deny:

In gnatsd.access, the first line means that user "azhuang" gets
"edit" access, when providing the password "andrew".  The second
line means that anybody else gets no access.  Hmm, to make sure,
use
        *:*:deny

The first * matches any username not yet caught, the second one
matches any password.  I am not sure what your line means.


Concerning gnatsd.host_access:

    Andrew> *.wavecom.com:edit:

Everybody connecting from *any* computer in domain wavecom.com
gets "edit" access.

    Andrew> localhost:edit:

So does everybody connecting from the machine running gnatsd.
You probably have to connect to the gnatsd on "localhost"
(127.0.0.1) to see this rule fire.

    Andrew> #192.168.1.*:edit:
    Andrew> #*.wavecom-inc.com:edit:

Two comment lines; no effect.

    Andrew> 10.200.210.14:edit:

Everybody connecting from this IP address gets "edit" access.

    Andrew> *:deny:

Everybody connecting from a machine not caught above gets rejected.

    Andrew> azhuang:edit:

Users connecting from machine "azhuang" would get "edit" access,
if this line were before the "deny" line.  Note that this talks
about a *computer* called "azhuang", meaning all users connecting
from that computer.  It does not talk about *user* "azhuang"!!


Hope this clarified things a bit.


Hans-Albert

-- 
Hans-Albert Schneider
Munich, Germany
EMail: address@hidden