> I had a situation once where I could not use nsradmin to gather the 
> information I needed - so I had this
> skeleton of a script lying around.  Why not share it - as, most 
> importantly, it provides a bit of insight
> as to how networker stores its configuration.

True, but it's not a supported API.  I'd rather have some justification
for avoiding the nsradmin interface when the same information is
available. 

Also, the server could have cached data internally so that the
information returned by 'nsradmin' is more up-to-date than the
information on the disk.

> I somehow had gotton into the situation where I had two default
> groups, and both the GUI and nsradmin refused to delete them because
> the it is the "default" group.  I started poking around while waiting
> for tech support to get back to me and found my two resources (in
> /nsr/res/nsrdb) belonging to the group default.  I shut down
> networker, renamed one of the groups, restarted networker, then
> deleted the renamed group.  I believe I probably could have simply
> deleted the resource file - but I though it better to make as small a
> change as possible in case I missed something else.

Yes, that's a completely separate issue where 'nsradmin' wouldn't be
useful.  I also hope that the application was shut down when you did
this.  That eliminates the issue of inconsistency.

> One of the joys of unix is that there are numerous ways of accomplishing 
> the same thing.  After all, what
> do you think nsradmin is doing behind the scenes to query this 
> information.

I often write perl programs that make use of 'nsradmin'.  I'd have to
make major changes to allow them to run easily on non-UNIX hosts if I
didn't use 'nsradmin' for queries.

Also the file configuration has changed over time.  The 'nsradmin' query
is the same, but checking files is quite different between the pre-7
monolithic resources and the broken up 7.x ones.  I ran it on my 6.1.3
server and the output is considerably less useful.

-- 
Darren Dunham                                           ddunham AT taos DOT com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu 
if you have any problems
wit this list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER