/etc/passwd Monitoring of Solaris Xymon Clients
Is there an established way of monitoring for /etc/passwd entriy changes/additions on Solaris servers?
If not, is it possible to add it as a log to be fetched and then do some processing on the Xymon server?
Regards,
Nick Pettefar
On Wed, 10 Apr 2013 11:48:51 +0100, Nick Pettefar <Nick at Pettefar.com> wrote:
Is there an established way of monitoring for /etc/passwd entriy changes/additions on Solaris servers?
If it is not supposed to change, then you can check an MD5 or SHA1 hash of the file matches.
See the "FILE" check in analysis.cfg
http://www.xymon.com/xymon/help/manpages/man5/analysis.cfg.5.html#lbAK http://www.xymon.com/xymon/help/manpages/man5/client-local.cfg.5.html#lbAI
The "xymondigest" tool can calculate the hash for you, if the system doesn't have a pre-installed MD5/SHA1 hash tool installed.
Regards, Henrik
Maybe this is supported(?) or someone has a hack available: Would like to see support for a displayed description field for the hosts.cfg conn declaration for cases where there are multiple IPs.
When there are a multiple IPs being tested on a given host, it can be a bit confusing figuring out what a particular failing IP is associated with. Ideally the description would show up in the status report to help identify the IP's purpose.
For example in the hosts.cfg file:
1.2.3.1 main-host1 # conn=worst,1.2.4.10 (ILO address), 1.2.5.20 (PA-RISC Console port), 1.2.3.2 (Web Server Business Portal), 1.2.3.3 (Web Server https Business Portal), 1.2.3.4 (Oracle Listener/databases connections)......
In web status page:
1.2.3.1 is alive (1ms) 1.2.4.10 is alive (3 ms) ILO address 1.2.5.20 is alive (3 ms) PA-RISC Console port 1.2.3.2 is alive (1 ms) Web Server Business Portal 1.2.3.3 is unreachable Web Server https Business Portal 1.2.3.4 is alive (1 ms) Oracle Listener/databases connections
The secondary IPs can be declared as separate entries in the hosts.cfg but that can lead to display "bloat". Even using the separate entries, there is still no user-friendly detail in the status messages on what is being tested.
group-compress <B>Operations</B> 1.2.3.1 main-host1 # conn .... ...
Group-compress <B>ILO ports</B> 1.2.4.10 main-host1 # conn ....
Group-compress <B>Console ports</B> 1.2.5.20 main-host1 # conn ....
Group-compress <B>Web Servers ports</B> 1.2.3.2 main-host1 # conn=worst,1.2.3.3 (so if the .3 address ip is unreachable, you don't know what the business impact is from just looking at the web status display) ....
participants (3)
-
henrik@hswn.dk
-
Mark.Deiss@xerox.com
-
Nick@Pettefar.com