In regard to: RE: [Networker] replacing NSR peer information on a NetWorker...:

Tim, I run into peer issue now and then and I do not have access to the 
servers. There is a way to
    Remove them from the master server. Here is how I clear them out.

On Master server with client nts481 having peer issues perform Part 1 and Part 2
   Part 1  ->  a) nsradmin -s nts481 -p nsrexecd
               b) print type: nsr peer information
               c) delete
               d) y
               e) quit

   Part 2  ->  a) nsradmin -s nts740 -p nsrexecd (where nts740 is the master 
server name)
               b) delete type: nsr peer information; name: 
nts481.kii.kimball.com
               c) quit

Tim-

I was under the mistaken impression that the backup server couldn't do
this kind of thing any more -- there was a security issue in the 7.2.x
timeframe and I thought part of plugging it had disabled this.  It appears
not, as I was able to purge the old nsr peer information on each of the
clients.

Unfortunately, this still hasn't fixed the issue.

I've also now tried replacing the nsrladb with the recovered copy, and
that also hasn't fixed the issue.

I'm going to be in touch with a couple of the clients to get a look at
the daemon.raw and see if there are any clues in there, but at this
point it looks like I'm going to be opening a ticket with EMC.

Thanks for your help,

Tim

-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On 
Behalf Of Tim Mooney
Sent: Wednesday, February 01, 2012 2:13 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: [Networker] replacing NSR peer information on a NetWorker server

All-

Yesterday I replaced the hardware on our primary NetWorker server.  The
server OS also went from RHEL 5.7 to RHEL 6.2.  The NetWorker version
stayed the same (7.6.2.5), but I did convert from 32 bit to 64 bit
NetWorker install.

As described in the installation guide, that meant going through the
disaster recovery procedure.  I'm well-versed in that procedure and it
went fine, as did reconfiguring the jukebox (the control port changed
SCSI address) and recovering the client file indexes.

Much to my surprise, though, the disaster recover procedure does *not*
bring back the previous "nsrladb" when it recovers the other resources.
This means that the server certificate used as part of the "peer"
authentication changed.

Surprisingly, only about two dozen of our 125+ clients failed their
backups last night because of the change in the server certificate, but
now I'm in a quandary.

I've now been through one (incremental) cycle with the new/regenerated
server cert.  Can I simply replace the new certificate (or entire nsrladb)
with the one recovered from backups, or is that just going to cause
problems for other clients?

If I controlled all of the clients that failed, I would just delete their
server peer information and let it be regenerated, but unfortunately many
of the clients are SLA backup customers, so I have no access to the
client systems.

Any thoughts on whether replacing the nsrladb on a NetWorker server with
a recovered copy is a good idea, or if that's just asking for trouble?

Thanks,

Tim

--
Tim Mooney                                             Tim.Mooney AT ndsu DOT 
edu
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, IACC Building                             701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

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