Den 10-02-2014 19:25, John Thurston skrev:
It appeared to me to only require the pcre libraries. Were there others I missed?
No, those are the ones.
I can see the case for server-side, but do not think it meets our business needs. I'm willing to be corrected if I've misunderstood how server-side configuration behaves:
- In server-side configuration, our log, process, user, etc data is passed across the network on clear TCP connections. In the client-side configuration, our host-specific data never leaves our host. The client can be rigged to leak very little host-data.
The status message is still sent across the network, presumably including the most interesting log entries. But yes, that is a problem in v4 - version 5 does TLS encryption of the traffic, if you ask it to.
- If a server-side configuration for log-watching is doing the pattern matching on the Xymon server, how do I avoid sending (resending) my entire log file to the server for analysis?
The logs are scanned by the 'logfetch' utility on the client, so only the last 30 minutes of log entries are sent from the client to the server. You can also limit the amount of log data by setting a limit in the client-local.cfg entry for the logfile. Combined with the "ignore" and "trigger" patterns you can weed out much of the junk logdata.
- Dumb client configurations are not always possible. We have many servers for which the Xymon-server admins do not understand the business requirements. In the client-side configuration, once the host is defined/authorized (in hosts.cfg) the server and application administrators can configure their alarm levels to meet their needs. In the server-side configuration, the Xymon-server admins are going to have to define the alarm levels for every defined/authorized host.
In my experience, the Xymon server admins have a much better understanding of the possibilities that Xymon offers, so they can often find a better way of configuring the monitoring than the business server admins. Of course, they do need to talk to each other :-) I understand that this depends a lot on how your organisation is structured.
- If my testing is correct, the client-local.cfg permits the Xymon server to instruct the client to execute commands on its behalf. The 'file:' option accepts
back-tickedstrings which are used to generate dynamic names. This is very useful, but can also be used to do other things... mayberm -rf ~/*.
Correct. But I would think that if you suspect that your Xymon server admins would resort to such acts of sabotage, then you have a bigger security problem ...
Anyway, that is why never recommend running the Xymon client as "root".
The short version is, server-side client configuration can work for hosts on which I am the sysadmin and business owner. Since that represents only about 20 of the 300+ hosts we monitor with Xymon, it isn't a very good fit. I hope you don't drop client-side configuration, but I will understand if you do.
I'll keep it as long as it works without having to do a lot of special code to support it. The current problems are with Makefile's, configuration options and libraries - such issues can be fixed, just like any other stupid bug. But I won't promise that it will be there forever.
We Solaris users are decreasing in number (thanks Oracle!).
Sadly, yes.
Regards, Henrik