Got a pair Sidewinders (peer-to-peer), HA work just fine until recently the member fw could not longer join the cluster. Getting the following error:
Waiting to start 'scobrad' because 'nss' is disabled
Waiting to start 'scobrap' because 'nss' is disabled
Waiting to start 'ccmd' because 'nss' is disabled
Waiting to start 'entrelayp' because 'nss' is disabled
We are scheduled for downtime and planning to re-create the cluster. Im not sure this will resolve the issue.
Any advice is appreciated.
Are any of your partitions full? Run "df" and check (/dev will always be 100%, so you can ignore that one). If that's not the problem, check through the audit again or look in /var/log/daemond.log and see if there is a more informative error in there.
Without knowing the root issue, it's difficult to say if breaking and rejoining the pair will fix the problem. You may want to file a ticket so support can fully review the audit.
Thank you. I have checked the disk space already and we are not running low on any of the partition.
snippet from my daemod.log entry:
'nss' i s not ready
Waiting to start 'hostd' because 'nss' is not running
Starting 'restart-all' ..... Invalid configuration data ....can't parse state table file '/etc/server.conf'
What service is using the server.conf? Looks like the serveral components services cannot be started if server.conf could not read.
Any particular incident that could possibly bring down the nss service?
> Invalid configuration data ....can't parse state table file '/etc/server.conf'
Check /etc/server.conf for any errors - it's a simple text file.
After fixing the errors restart nss.
Edited to add:
If unsure compare it with the working one from the other cluster member.Message was edited by: oreeh on 12/22/09 8:43:17 AM CET
server.conf is the config file for the servers/daemons on the Sidewinder. This doesn't include any proxies. Like oreeh said, you can grab a copy of server.conf from the working pair memeber and compare it.
I don't know for sure what could have caused this. Some guesses are a patch installation, config restore, improper shutdown if the firewall was writing to the file, or if someone (another admin) improperly edited the file. Without seeing the audit.raw from when the problem initially started happening, it's tough to say why the firewall can no longer read the state table for server.conf.