On Tue, Jan 12, 2010 at 2:26 PM, Rich Rumble <[email protected]> wrote: > The newly added servers are the only ones that are never > disconnecting, all others are still disconnecting, even if they have > been restarted and the keys copied back to them and the client > restarted. I've not issued new keys to old hosts, is there a way I can > check for corruption, a backup I can revert to, a way to export all > the auth keys, uninstall, reinstall and restore the keys again? I > seriously can't touch the client servers for weeks, they are in > production, and even though no downtime or reboots are necessary the > clearance to make a change takes forever. I can mess with the ossec > server almost as much as I need to. Any suggestions? > The only saving grace is it seems that the logs are still being > written, just not emailed except for the latest batch of hosts I've > added. > So /var/ossec/logs/alerts/2010/Jan/<log_file_name.log> contains events > for all the hosts that keep disconnecting, those alerts are just not > being emailed for the "old" hosts. The last 10 I've added after > noticing the issue are emailing their alerts and not disconnecting > ever. > -rich >
There are no client systems you can mess with to try and solve this? It'd be great if you could upgrade one to 2.3 to see if that solves the problem. Check the client.keys file to make sure it looks okay. It should look something like (HAS is replaced by a long string of hex): 002 power 192.168.17.249 HASH Are there any duplicate IPs? Do your nagios and cacti installations just look at disk space or do they also check inodes (df -i)? Do you get any more information if you run ossec-remoted in debug mode? ( kill ossec-remoted and run it with "/var/ossec/bin/ossec-remoted -d" )
