02-05-2009 12:10 PM
I just got a new NSM appliance and upgraded it from 2007.3r1 to 2008.2r1 and have it taking to the Windows UI piece. However, the windows UI reports the Device Server as down while the server reports it as up (/etc/init.d/devSvr status returns all OK). I've done a lot of reading about deleting the RSA keys from devSrv.cfg or using the .xdbViewEdit.sh script to fix mismatched keys. However, in our case the /var/netscreen/DevSvr/errorLog/device.Daemon.0 file I have line after line of:
[Error] [1123680-soCfgFile.c:142] "ourRsaPrivateKey" is missing in /use/netscreen/DevSvr/var/devSvr.cfg!
I've got no keys to delete anywhere. Most of the things I've read imply that deleting the keys causes new keys to be generated, but that doesn't seem to work. I've put in a blank value with the ourRsaPrivateKey line in the cfg file, restarted the devSvr, rebooted the box, etc, etc and it won'r generate keys.
Any ideas would be greatly appreciated. Thanks.
Solved! Go to Solution.
02-05-2009 12:20 PM
if you remove your empty entries, and restart the devSvr service (/etc/init.d/devSvr restart) i should generate and repopulate them in the devSvr.cfg file.
02-05-2009 12:41 PM
I've removed the empty entry from the devSvr.cfg file, but where else should I look? I've used xdbViewEdit to check for keys via Option 7 and then looking in 0.server.0 and 0.server.1 and there are no RSA key fields to remove. I've checked that the one-time passwords match and everything else could think of. Should I just delete the entire server record for the devSvr?
02-05-2009 12:46 PM
yip from .xdbViewEdit.sh option 7 (in read write mode , the guiSvr will have to be stopped)
then 0.shadow_server.1 and you will see the old RSA keys listed there also. Just remove (using dd) the entire rsa key lines and write ad quit.
Delete the devSvr rsakeys from the devSvf.cfg file also (/var/netscreen/DevSvr/devSvr.cfg) and restart the services.
02-05-2009 12:56 PM
No can do... There are no RSA keys in the 0.shadow_server.1 entry, just like there never were any in the devSvr.cfg file. My entire 0.shadow_server.1 file consists of:
I think I may need a re-install. The only other thing that I've noticed is that I hunted down a file based on a release note. It mentions deleting keys from shadow_server__table.nml, but I have a file called shadow_server_table_STANDALONE.nml. I'm begininning to suspect I messed up my upgrade.
02-05-2009 01:00 PM
well if you are going to reinstall, check the folder /var/netscreen/installerBackup
this should contain backups of the dev and gui server.
Also you could tar up the /var/netscreen/GuiSvr/xdb so that you can restore the config database after reinstalling.
Either way i would recommend that you make a backup of your current /var/netscreen folders or move them elsewhere on the filesystem so that you can recover the databases after reinstall.
02-05-2009 02:58 PM
There are a certain more check that can be performed.
1. Make sure that the onetime password in the /usr/netscreen/DevSvr/var/devSvr.cfg is the same as what is there in your GUI Server. In your case, it is dk2003ns on the Device Server.
To verify that on GUI Server, you can start xdbViewEdit.sh in the readonly mode, select 7 and select 0.shadow_server.1
2. In the DevSvr.cfg, make sure that the IP Address of the GUI Server is defined correct.
3. I am assuming that this is an install with GUI Server & Device Server being installed on 2 different systems. In such a case, if the Dev Server is started before it is added on the GUI server, we have seen this happen. Unfortunately in such a situation, you will need to reinstall the Device Server, don't start it up until it is added through the GUI on the GUI server.
Hope this helps.
02-05-2009 06:32 PM
1. I've checked the passwords and they are the same.
2. In /var/netscreen/DevSvr/devSrv.cfg the IP address of the GUI server is correct because...
3. The GUI server and the Dev server are on the same box. It's a Juniper NSMXpress appliance.
I'm going to try re-installing the Dev server and see if that helps, otherwise I'm not sure what to do.
02-05-2009 07:13 PM - edited 02-05-2009 07:16 PM
Fixed it. For anybody interested I reinstalled the servers with:
# cd /var/install
# sh ./nsm2008.2r1_servers_linux_x86.sh
answered all the questions, explicitly entered "dk2003ns" for GUI server one-time pass and chose NO for "Start servers at end of install". Then:
# /etc/init.d/guiSrv start
Waited for that to initialize and then connected to the NSM server using the 'super' user from my Windows box. Confirmed that the Gui server was up and the Dev server down. Then back to the NSM box and
# /etc/init.d/devSrv start
and... success. It came up and changed status in the Windows UI and looks good so far. The /var/netscreen/DevSrv/devSrv.cfg file has the RSA keys in it now.
Thanks to Colin and Chandra for their suggestions.
02-05-2009 07:18 PM
Its interesting that being all these values being correct, the problem still exists. One thought that I had was probably to look at the permissions of the file. Just to make sure they are owned by NSM (guiSvr.cfg & devSvr.cfg)
Since its a new install, you can restore the NSMXpress back to factory defaults. This can be done by using the details in the link
12-12-2010 10:36 PM
Since I didn't get an answer on my new thread, let's see if I get some help by reviving this one:
I'm having the same issue, and I followed all the same steps as RobinT, but my DevSvr is still down. The major difference is that I'm running 2010.4, but it seems to operate pretty much the same.
I need this configured with 2 IDP800s morning, so night owls and west coast dwellers, please help!