(I have a case open with Sun on this, but I'd love feedback from the real world
as well :-))
We're preparing for scheduled (offsite vendor) disaster-recovery tests with a
pre-test of our own on a local isolated network, and I've run into a Catch-22
in a previously "works fine" procedure. This is Sun's OEM-ed Networker (EBS
7.2) on Solaris 8/SPARC, BTW.
Here's what has worked 4 or 5 times so far :
1. On the DR test server, build up Solaris and install a clean (i.e., eval)
copy of Networker, full server installation, all packages
2. On the production server, shutdown Networker and tar up the entire contents
of /nsr to tape
3. On the DR server, shutdown Networker, 'mv /nsr /nsr.default' and untar the
tape of production's /nsr
4. Reboot the DR server, (restart Networker, etc.) reconfigure tape devices,
libraries, etc. as necessary, delete all backup pool volumes and start
recoveries from clone tapes
Here's the problem we're having :
In the past, step 4 would generate a warning that the authorization codes are
invalid and the enablers will be good for only X number of days, which is OK
(plenty of time for testing). What's happening now is, the Networker server
processes apparently start, the invalid authorization codes are detected and
the server processes then just shutdown, leaving only the client daemons
running (two nsrexecd's and an nsrd process).
There are only a couple of lines in /nsr/logs/daemon.log :
nsrd: server notice: started
nsrd: registration notice: invalid auth codes detected.
...and that's it. The server processes won't start because the codes are bad,
but I can't remove the codes using nwadmin (or any other way I know of -
nsrcap, etc.) since the server processes won't start.
How do we get around this? Any known issues here?
All of the codes (AFAIK) used to be in /nsr/res/nsr.res prior to 7.x, but
apparently not anymore. I don't want to go poking around in the config database
without good reason, however, if we can manually delete the codes somehow, they
can be re-entered (but in the past we've never even had to do that).
Unless we can work around this, we'll have to mmrecov, manually recover the
indexes, etc. (which will decimate the time we have at our DR vendor for
testing). Besides, our procedure has worked fine at least three times before...
?
Thanks in advance.
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 with 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
|