use of GNATSDB

use of GNATSDB

[Mel Hatzis]

I'm trying to setup a separate database instance by adding a line
into the share/gnats/databases file and setting the GNATSDB env
variable to point to it. I can successfully 'telnet localhost port#'
and, say, lockdb, but when I try using pr-edit it ends up locking
the default database.

Grokking through the code, I find that client_init_gnats
in client.c is invoking 'chdb default' because the scanenv function
always sets database to 'default' during initialization.

My question is..."wouldn't it make more sense to do the equivalent of
'database =  getenv ("GNATSDB")' rather than blindly setting it
to 'default'?

--
Mel Hatzis
Juniper Networks Inc.


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

Re: use of GNATSDB

[Mel Hatzis]

Looking at the use of the GNATSDB environment variable
throughout the code, it seems somewhat ambiguous.

On the one hand, it can be set to a database name
corresponding to an entry in the databases file, and on
the other hand, it can be set to a colon separated tuple
defining a 'remote' database, as follows:
    hostname:portnumber:databasename:username:password

I'd like to suggest that two variables be used for these
different purposes to cleanly delineate and clearly specify
the intended functionality.

My proposal is to continue to use GNATSDB as the
'colon separated tuple' and introduce GNATSID to
replace the use of GNATSDB in findOrLoadDatabase
(in database.c).

I've included an earlier email exchange related to the topic
below...

My apologies if this is not the right forum for such a
discussion.

--
Mel Hatzis
Juniper Networks, Inc.

Hans-Albert Schneider wrote:
>>>>>>"Mel" == Mel Hatzis <hatzis@juniper.net> writes:
>>>>>>
> 
>     Mel> I believe I have the latest code...version 1.42 of
>     Mel> client.c.
> 
> Yes, that's the version I've got, too.
> 
>     Mel> The problem occurs around 13 lines from the bottom of
>     Mel> the scanEnv function...
> 
>     Mel>     if (*database == NULL)
>     Mel>       {
>     Mel>         *database = xstrdup ("default");
>     Mel>       }
> 
>     Mel> If you look closely, you'll note that even though the
>     Mel> env. variable is read, it is not used to initialize the
>     Mel> 'database' variable....and therefore, the lines I've
>     Mel> pasted above end up setting it to 'default'.
> 
> I see... It is even a bit more complicated:
> 
> If GNATSDB is a colon separated tuple of
> 	hostname:portnumber:databasename:username:password
> then "database" gets initialized, but not if it is the name of a
> database listed in the "databases" file.
> 
> (The tuple format is described in the manual in "Environment
> variables and GNATS tools" in chapter "The GNATS user tools".  It
> is probably intended for databases that must be accessed across
> the net, but are not listed in the "databases" file.)
> 
> Even worse: I do not see how scanEnv deals with a *local*
> database at all.
> 
> A workaround seems to be to specify the database name via option
> --database or -d.  This is passed to client_init_gnats(), then to
> scanEnv(), and is left untouched.
> 
> 
> I don't dare to change the code, because I do not know it good
> enough to be sure not to break another place.
> 
> 
> Hans-Albert
> 
> 




_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

Re: use of GNATSDB

[Lars Henriksen]

On Wed, Mar 27, 2002 at 07:21:11PM -0800, Mel Hatzis wrote:
> I'm trying to setup a separate database instance by adding a line
> into the share/gnats/databases file and setting the GNATSDB env
> variable to point to it. I can successfully 'telnet localhost port#'
> and, say, lockdb, but when I try using pr-edit it ends up locking
> the default database.

I can't reproduce this behaviour. Whether GNATSDB is set or not, the command
"pr-edit --lockdb" seems to lock nothing at all. Neither does "pr-edit
--database=<db> --lockdb". On the other hand, "pr-edit --lock <user> <PR>"
honors GNATSDB as well as the --database option.

> Grokking through the code, I find that client_init_gnats
> in client.c is invoking 'chdb default' because the scanenv function
> always sets database to 'default' during initialization.

There must be more to it than that, but I haven't yet been able to figure out
what.

Lars Henriksen

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

Re: use of GNATSDB

[Lars Henriksen]

On Fri, May 17, 2002 at 02:03:08PM +0200, Lars Henriksen wrote:
> On Wed, Mar 27, 2002 at 07:21:11PM -0800, Mel Hatzis wrote:
> > I'm trying to setup a separate database instance by adding a line
> > into the share/gnats/databases file and setting the GNATSDB env
> > variable to point to it. I can successfully 'telnet localhost port#'
> > and, say, lockdb, but when I try using pr-edit it ends up locking
> > the default database.
> 
> I can't reproduce this behaviour. Whether GNATSDB is set or not, the command
> "pr-edit --lockdb" seems to lock nothing at all. Neither does "pr-edit
> --database=<db> --lockdb". On the other hand, "pr-edit --lock <user> <PR>"
> honors GNATSDB as well as the --database option.

That wasn't the whole story. In fact GNATSDB is honored by pr-edit when
you specify a remote database, but not when you specify a local one.

Lars Henriksen

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

Re: use of GNATSDB

[Lars Henriksen]

On Fri, May 17, 2002 at 02:21:49PM +0200, Lars Henriksen wrote:
> On Fri, May 17, 2002 at 02:03:08PM +0200, Lars Henriksen wrote:
> > On Wed, Mar 27, 2002 at 07:21:11PM -0800, Mel Hatzis wrote:
> > > I'm trying to setup a separate database instance by adding a line
> > > into the share/gnats/databases file and setting the GNATSDB env
> > > variable to point to it. I can successfully 'telnet localhost port#'
> > > and, say, lockdb, but when I try using pr-edit it ends up locking
> > > the default database.
> > 
> > I can't reproduce this behaviour. Whether GNATSDB is set or not, the command
> > "pr-edit --lockdb" seems to lock nothing at all. Neither does "pr-edit
> > --database=<db> --lockdb". On the other hand, "pr-edit --lock <user> <PR>"
> > honors GNATSDB as well as the --database option.
> 
> That wasn't the whole story. In fact GNATSDB is honored by pr-edit when
> you specify a remote database, but not when you specify a local one.

That should have been:

That wasn't the whole story. In fact GNATSDB is honored by "pr-edit --lockdb"
when you specify a remote database, but not when you specify a local one.

Lars Henriksen

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

Re: use of GNATSDB

[Dirk Bergstrom]

On 5/17/2002 5:03 AM, this issued forth from the mind of Lars Henriksen:
> I can't reproduce this behaviour. Whether GNATSDB is set or not, the command
> "pr-edit --lockdb" seems to lock nothing at all. Neither does "pr-edit
> --database=<db> --lockdb". On the other hand, "pr-edit --lock <user> <PR>"
> honors GNATSDB as well as the --database option.

this is a totally different issue.  as you probably know, gnats has two
separate code paths:

"localhost mode", in which the particular program you're running
directly interacts with the database.

"network mode" in which the program talks to gnatsd over a socket.

i could rant extensively about how foolish, wasteful & bug-prone this
is, but i'll save that for another day, and stick to this particular
example of the folly.

so in pr-edit, the "network mode" lockdb code opens a socket to gnatsd
and issues a LKDB command, and gnatsd locks the database.  in "localhost
mode", pr-edit makes a call to gnats_lock() (actually, it calls foo,
which calls bar, which calls gnats_lock), which is the same call that
gnatsd makes.  this *does* lock the database, but then, at the very end
of main(), there's a check that says something like:

if (gnats_locked) {
    unlock_gnats()
}

this check is entirely reasonable, if you're trying to do an edit, or an
append, but it's just wrong if you're trying to lock the database.

so, you happen to have run into one of the many, many subtle and
outrageous bugs in localhost mode.  this is why i counsel people to
*always* use network mode, even when talking to a local database.

how, you ask, do you make sure you're using network mode?  by specifying
either --host or --port or both.

-- 
Dirk Bergstrom                   dirk@juniper.net
Computer Geek                     v: 707.433.0564
Juniper Networks Inc.             f: 707.433.0769

"it *looks* like a nail; lemme grab my hammer..."


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

Re: use of GNATSDB

[Mel Hatzis]

Lars Henriksen wrote:
> On Fri, May 17, 2002 at 02:21:49PM +0200, Lars Henriksen wrote:
> 
>>On Fri, May 17, 2002 at 02:03:08PM +0200, Lars Henriksen wrote:
>>
>>>On Wed, Mar 27, 2002 at 07:21:11PM -0800, Mel Hatzis wrote:
>>>
>>>>I'm trying to setup a separate database instance by adding a line
>>>>into the share/gnats/databases file and setting the GNATSDB env
>>>>variable to point to it. I can successfully 'telnet localhost port#'
>>>>and, say, lockdb, but when I try using pr-edit it ends up locking
>>>>the default database.
>>>>
>>>I can't reproduce this behaviour. Whether GNATSDB is set or not, the command
>>>"pr-edit --lockdb" seems to lock nothing at all. Neither does "pr-edit
>>>--database=<db> --lockdb". On the other hand, "pr-edit --lock <user> <PR>"
>>>honors GNATSDB as well as the --database option.
>>>
>>That wasn't the whole story. In fact GNATSDB is honored by pr-edit when
>>you specify a remote database, but not when you specify a local one.
>>
> 
> That should have been:
> 
> That wasn't the whole story. In fact GNATSDB is honored by "pr-edit --lockdb"
> when you specify a remote database, but not when you specify a local one.
> 
> Lars Henriksen
> 

Let's clear some things up... the test I'm running is:

   GNATSDB=test $gnats_home/libexec/gnats/pr-edit --lockdb

(let's ignore all other uses of GNATSDB and stick with this one)

My $gnats_home/etc/gnats/databases file looks like:

   default:Bug database:/usr/local/com/gnatsdb:server.juniper.net:1529
   test:GNATS Test:/homes/hatzis/local/gnats/test:server.juniper.net:1529

Let's also define local vs remote...as far as the code is concerned, it's
remote if the line in the databases file defines the server and port number
...as per the last line in databaseSpecIsNetConn which reads:

    return (dbEnt->fieldcount > 3) ? 1 : 0;

So, as far as my test is concerned, local mode is not used at all.

When I run the 'pr-edit --lockdb' command, I don't see a gnats.lock
in my test database...

bash-2.03$ ls /homes/hatzis/local/gnats/test/gnats-adm
addresses      current        index          states
categories     dbconfig       locks/         submitters
classes        gnatsd.access  responsible

but I do see a gnats.lock file in the default database...

bash-2.03$ ls /usr/local/com/gnatsdb/gnats-adm
addresses      classes        gnats.lock     locks/         states
categories     dbconfig       gnatsd.access  responsible    submitters

-Mel


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

Re: use of GNATSDB

[Lars Henriksen]

On Fri, May 17, 2002 at 10:31:10AM -0700, Dirk Bergstrom wrote:
> On 5/17/2002 5:03 AM, this issued forth from the mind of Lars Henriksen:
> > I can't reproduce this behaviour. Whether GNATSDB is set or not, the command
> > "pr-edit --lockdb" seems to lock nothing at all. Neither does "pr-edit
> > --database=<db> --lockdb". On the other hand, "pr-edit --lock <user> <PR>"
> > honors GNATSDB as well as the --database option.
> 
> this is a totally different issue.

Is it? The issue is how or whether GNATSDB is honered by (for example) pr-edit
and it was claimed, without reservations, that it always ended up locking
the default database. As far as I can see, you confirm below that this is
not the case. 

> so in pr-edit, the "network mode" lockdb code opens a socket to gnatsd
> and issues a LKDB command, and gnatsd locks the database.

...

>                                                           in "localhost
> mode", pr-edit makes a call to gnats_lock() (actually, it calls foo,
> which calls bar, which calls gnats_lock), which is the same call that
> gnatsd makes.  this *does* lock the database, but then, at the very end
> of main(), there's a check that says something like:
> 
> if (gnats_locked) {
>     unlock_gnats()
> }
> 
> this check is entirely reasonable, if you're trying to do an edit, or an
> append, but it's just wrong if you're trying to lock the database.

Thanks for the explanations. They agree with my observations.

> so, you happen to have run into one of the many, many subtle and
> outrageous bugs in localhost mode.  this is why i counsel people to
> *always* use network mode, even when talking to a local database.

But of course you are right that this behaviour has nothing to do with GNATSDB.

> how, you ask, do you make sure you're using network mode?  by specifying
> either --host or --port or both.

Or by setting GNATSDB to point to the remote database.

Lars Henriksen

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

Re: use of GNATSDB

[Dirk Bergstrom]

On 5/17/2002 11:13 AM, this issued forth from the mind of Lars Henriksen:
> On Fri, May 17, 2002 at 10:31:10AM -0700, Dirk Bergstrom wrote:
>> On 5/17/2002 5:03 AM, this issued forth from the mind of Lars Henriksen:
>> > I can't reproduce this behaviour. Whether GNATSDB is set or not, the command
>> > "pr-edit --lockdb" seems to lock nothing at all. Neither does "pr-edit
>> > --database=<db> --lockdb". On the other hand, "pr-edit --lock <user> <PR>"
>> > honors GNATSDB as well as the --database option.
>> this is a totally different issue.
> Is it? The issue is how or whether GNATSDB is honered by (for example) pr-edit
> and it was claimed, without reservations, that it always ended up locking
> the default database. As far as I can see, you confirm below that this is
> not the case. 

i guess i wasn't very clear in my explanation:

using pr-edit in localhost mode, it is IMPOSSIBLE to lock ANY database.

the program locks the db, then unlocks it a few lines later.  it's a bug
in the localhost mode code, one of many.

-- 
Dirk Bergstrom                   dirk@juniper.net
Computer Geek                     v: 707.433.0564
Juniper Networks Inc.             f: 707.433.0769

"it *looks* like a nail; lemme grab my hammer..."


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats

Re: use of GNATSDB

[Lars Henriksen]

On Fri, May 17, 2002 at 11:06:14AM -0700, Mel Hatzis wrote:
> Let's clear some things up... the test I'm running is:
> 
>   GNATSDB=test $gnats_home/libexec/gnats/pr-edit --lockdb
> 
> (let's ignore all other uses of GNATSDB and stick with this one)
> 
> My $gnats_home/etc/gnats/databases file looks like:
> 
>   default:Bug database:/usr/local/com/gnatsdb:server.juniper.net:1529
>   test:GNATS Test:/homes/hatzis/local/gnats/test:server.juniper.net:1529

I believe you. That was the combination I didn't try! I had GNATSDB itself
point to the remote host.

Lars Henriksen

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnats