Networker

Re: [Networker] Determining groups a client belongs to?

2004-11-16 18:02:46
Subject: Re: [Networker] Determining groups a client belongs to?
From: George Sinclair <George.Sinclair AT NOAA DOT GOV>
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Date: Tue, 16 Nov 2004 18:05:20 -0500
All good points. I appreciate the great feedback on this forum. I'm
thinking I could have this script run each morning when no backups are
running and then compare the results with some historical listing I've
stored away that is considered accurate as of the time it was created.
If there are any differences then the script can e-mail me a list of the
differences, and I could then have it update the listing accordingly;
otherwise not, depending. Maybe, as you suggested, mminfo could be
incorporated instead and/or maybe I could use the other method
periodically to check the results of the historical listing created from
mminfo. A separate script will then use the older record (possibly
updated) to determine if any saveset did not back up.

In the past, I played around with a script to check this, but it relied
on a hard coded listing of savesets, and this was a pain to keep updated
as clients were added, deleted and savesets moved around. Using a script
to possibly keep this information in sync would make it much easier.

George

Darren Dunham wrote:
>
> > So, I'm thinking my script could run something like:
> >
> > nsradmin> . type: NSR group
> > nsradmin> print
> >
> > to get a listing of all the groups and then have the script parse out
> > only those with autostart enabled,
>
> Or..
>
> nsradmin> show name
> nsradmin> print type:nsr group; autostart:enabled
>
> To have less parsing to do ...
>
> > and these would constitute the active
> > groups, and then when I run:
> >
> > nsradmin> show group
> > nsradmin> print name:clientname
>
> Just to avoid namespace collisions, I would always write that as
> nsradmin> print type:nsr client;name:clientname
>
> It's unlikely that you'll have something else with the same name that's
> not a client, but also having a 'group' attribute, but it avoids
> problems if this section is later modified.
>
> > I can parse out only the active ones since now I know which ones are
> > active from before and then I can run:
> >
> > savegrp -p -c client group
> >
> > for each active group to get a list of all the expected savesets for the
> > client.
>
> Several steps, but yes, I don't know any way to do it that is
> significantly easier.
>
> I would watch out for problems where the client is down and your savegrp
> gives different answers.
>
> Or, if you didn't need future information and could get away with
> historical records, I might use 'mminfo' instead to see what was saved
> on tape recently.  It might not be as accurate, but there would be fewer
> steps, and it wouldn't rely on the client being up.
>
> --
> 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. >
>
> --
> Note: To sign off this list, send a "signoff networker" command via email
> to listserv AT listmail.temple DOT edu or visit the list's Web site at
> http://listmail.temple.edu/archives/networker.html where you can
> also view and post messages to the list. Questions regarding this list
> should be sent to stan AT temple DOT edu
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=