xymon client in 'local' mode, build pain
I've been using my Solaris BB clients with my Xymon server, but am hoping the xymon client will be more zfs-aware than the ancient BB client. To that end, I'm trying to compile a xymon client.
I've spent most of the day fighting with the 'make' process.
Following the notes in: http://lists.xymon.com/pipermail/xymon/2013-January/036466.html http://lists.xymon.com/pipermail/xymon/2010-September/029376.html I have modified xymond/Makefile several ways. . . Adding the line:
IDTOOL := $(shell if test
uname -s= "SunOS"; then echo /usr/xpg4/bin/id; else echo id; fi)
Changing the lines beginning "../client/xymond_client" to be:
../client/xymond_client: $(CLIENTOBJS) ../lib/libxymonclient.a $(CC) -o $@ $(RPATHOPT) $(CLIENTOBJS) ../lib/loadhosts.o ../lib/matching.o ../lib/timing.o ../lib/locator.o ../lib/libxymonclientcomm.a ../lib/libxymonclient.a -lrt -lpcre $(PCRELIBS) $(NETLIBS) $(LIBRTDEF)
The crazy part is when I compare the results of making with --client and --server. I can only find one difference. A --client build has created the application bin/xymond_client
Is this really the only difference? If so, why is there a broken build process for the '--client' option? Why doesn't the '--server' option also build the xymond_client and leave it abandoned in the bin directory?
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska
Den 2014-02-08 3:49, John Thurston skrev:
I've been using my Solaris BB clients with my Xymon server, but am hoping the xymon client will be more zfs-aware than the ancient BB client. To that end, I'm trying to compile a xymon client.
I've spent most of the day fighting with the 'make' process.
[snip]
The crazy part is when I compare the results of making with --client and --server. I can only find one difference. A --client build has created the application bin/xymond_client
There are two ways of running the client: In "server-side" mode, where all of the configuration and data analysis happens on the Xymon server, and "client-side" mode where you configure the client locally (the way BB does).
The "xymond_client" binary is the only difference between a client- and server-side configured client. "xymond_client" is the program that analyses the client data and generates the status updates, so when you configure the client for "client-side" configuration, then you get this extra binary. However, it also uses a lot of external libraries that you can avoid installing on all of the servers you monitor by using server-side configuration.
Client-side really is a hack, and it will probably be removed in v5. So I really do recommend that you use server-side configuration, to keep the client installation as dumb as possible.
Is this really the only difference? If so, why is there a broken build process for the '--client' option? Why doesn't the '--server' option also build the xymond_client and leave it abandoned in the bin directory?
"configure --server" builds both the Xymon server programs and the Xymon client programs. The client programs end up in the "~xymon/client/" directory.
Building only the client with "configure --client" should work, but I'll readily admit that testing on Solaris is not at the top of my priority list. I haven't had reports that it is completely broken, though.
Regards, Henrik
I am pretty sure I've seen reports on the list that this build simply doesn't work, even on Linux.
----- Original Message ----- From: henrik at hswn.dk [mailto:henrik at hswn.dk] Sent: Monday, February 10, 2014 09:56 AM To: xymon at xymon.com <xymon at xymon.com> Subject: Re: [Xymon] xymon client in 'local' mode, build pain
Den 2014-02-08 3:49, John Thurston skrev:
I've been using my Solaris BB clients with my Xymon server, but am hoping the xymon client will be more zfs-aware than the ancient BB client. To that end, I'm trying to compile a xymon client.
I've spent most of the day fighting with the 'make' process.
[snip]
The crazy part is when I compare the results of making with --client and --server. I can only find one difference. A --client build has created the application bin/xymond_client
There are two ways of running the client: In "server-side" mode, where all of the configuration and data analysis happens on the Xymon server, and "client-side" mode where you configure the client locally (the way BB does).
The "xymond_client" binary is the only difference between a client- and server-side configured client. "xymond_client" is the program that analyses the client data and generates the status updates, so when you configure the client for "client-side" configuration, then you get this extra binary. However, it also uses a lot of external libraries that you can avoid installing on all of the servers you monitor by using server-side configuration.
Client-side really is a hack, and it will probably be removed in v5. So I really do recommend that you use server-side configuration, to keep the client installation as dumb as possible.
Is this really the only difference? If so, why is there a broken build process for the '--client' option? Why doesn't the '--server' option also build the xymond_client and leave it abandoned in the bin directory?
"configure --server" builds both the Xymon server programs and the Xymon client programs. The client programs end up in the "~xymon/client/" directory.
Building only the client with "configure --client" should work, but I'll readily admit that testing on Solaris is not at the top of my priority list. I haven't had reports that it is completely broken, though.
Regards, Henrik
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Den 10-02-2014 16:01, Novosielski, Ryan skrev:
I am pretty sure I've seen reports on the list that this build simply doesn't work, even on Linux.
Have you tried?
At least on my Debian box - minimal installation - it builds without any problems.
I have a Solaris 10/x86 VM with a load of CSW add-on packages (gcc, GNU make etc from www.opencsw.org) installed. If I set PATH to $PATH:/opt/csw/bin:/usr/ccs/bin, then the 4.3.16 client also configures and compiles without any problems.
I am sure John had some real problems, but I just have to say that I simply dont have all kinds of systems for testing, so if it breaks on a setup out there, then I need help figuring out what the problem is - and if it is a Xymon problem or a local problem.
Regards, Henrik
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/10/2014 01:24 PM, Henrik Størner wrote:
Den 10-02-2014 16:01, Novosielski, Ryan skrev:
I am pretty sure I've seen reports on the list that this build simply doesn't work, even on Linux.
Have you tried?
At least on my Debian box - minimal installation - it builds without any problems.
I'll admit I have not tried -- we're talking specifically about the client-side configuration option, right, not the client-only build? I've never wanted a client-side config so I've not tested it. But I could have sworn there was a buzz on the mailing list a month ago or two about how it wouldn't build.
I have a Solaris 10/x86 VM with a load of CSW add-on packages (gcc, GNU make etc from www.opencsw.org) installed. If I set PATH to $PATH:/opt/csw/bin:/usr/ccs/bin, then the 4.3.16 client also configures and compiles without any problems.
I am sure John had some real problems, but I just have to say that I simply dont have all kinds of systems for testing, so if it breaks on a setup out there, then I need help figuring out what the problem is - and if it is a Xymon problem or a local problem.
Totally understandable. I can say for my part, I have access to perhaps an above-average variety of systems (Solaris SPARC, Solaris x86, MacOS, X and Ubuntu and RedHat/CentOS Linux) so I'm happy to test builds and stuff like that. In most cases, I have to do it anyway (though I don't test Macs or Ubuntu machines currently).
____*Note: UMDNJ is now Rutgers-Biomedical and Health Sciences* || \\UTGERS |---------------------*O*--------------------- ||_// Biomedical | Ryan Novosielski - Sr. Systems Programmer || \\ and Health | novosirj at rutgers.edu - 973/972.0922 (2x0922) || \\ Sciences | OIT/EI-Academic Svcs. - ADMC 450, Newark `' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlL5JBkACgkQmb+gadEcsb4qnACgvyWCWjPx9jO9DBDltub2iYMs TUcAnjLvWbN+YTQJpFORktponT6VARE4 =S30d -----END PGP SIGNATURE-----
Den 10-02-2014 20:10, Novosielski, Ryan skrev:
On 02/10/2014 01:24 PM, Henrik Størner wrote:
Den 10-02-2014 16:01, Novosielski, Ryan skrev:
I am pretty sure I've seen reports on the list that this build simply doesn't work, even on Linux.
Have you tried?
At least on my Debian box - minimal installation - it builds without any problems.
I'll admit I have not tried -- we're talking specifically about the client-side configuration option, right, not the client-only build?
My apologies, I was a bit hot-headed there. You are right - the "client-only / client-side configuration" build is broken. In several places, actually.
The attached diff against 4.3.16 works here, I have committed it for 4.3.17 if I need to do such a release.
John, I think this should also resolve the problems you've been having getting a client built the way you tried. To apply it, save the attached file somewhere, then go to the xymon-4.3.16 directory and run "cat /tmp/clientbuild.diff | patch -p0". And if there is a Makefile already (i.e. if you have previously run 'configure' there), please delete it and start with "./configure --client" again.
Regards, Henrik
On 2/10/2014 12:19 PM, Henrik Størner wrote:
The attached diff against 4.3.16 works here, I have committed it for 4.3.17 if I need to do such a release.
Thank you for your work on this.
John, I think this should also resolve the problems you've been having getting a client built the way you tried. To apply it, save the attached file somewhere, then go to the xymon-4.3.16 directory and run "cat /tmp/clientbuild.diff | patch -p0".
Chuckle. I spent an hour trying to learn why the diff would not apply. I was looking for differences between patch and gpatch and which version my Solaris has. It hadn't occurred to me that I would need to dos2unix your patch file :) Once I did that, gpatch happily consumed and applied it.
I had to do a couple more things to make this client build work for me. (I say 'work', but I have not yet run the client to confirm it works as expected. I have only built it without errors.)
The configure.client uses build/pcre.sh to locate the required pcre libraries. It does not, however, recognize the --pcreinclude --pcrelib options recognized by the configure.server file. Since I built the pcre libraries just for this application (and put them in xymon/pcre), I need to tell pcre.sh where to find them. I modified configure.client by inserting the parameter splitting block from configure.server.
clientMakefile looks up a group for use with chgrp -R. This failed, so I inserted > IDTOOL := $(shell if test
uname -s= "SunOS"; then echo /usr/xpg4/bin/id; else echo id; fi) at the top of the file.
Tomorrow, I'll see if the client can actually talk to the Xymon server.
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska
On 2/10/2014 5:56 AM, henrik at hswn.dk wrote:
- snip -
Is this really the only difference? If so, why is there a broken build process for the '--client' option? Why doesn't the '--server' option also build the xymond_client and leave it abandoned in the bin directory?
"configure --server" builds both the Xymon server programs and the Xymon client programs. The client programs end up in the "~xymon/client/" directory.
Den 2014-02-08 3:49, John Thurston skrev:
I apologize. My question was written incorrectly. It should have read:
The build process for --client asks if it should build for server-side or client-side configuration. Why doesn't the --client build process always build xymond_client?
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska
On 2/10/2014 5:56 AM, henrik at hswn.dk wrote:
- snip -
The "xymond_client" binary is the only difference between a client- and server-side configured client. "xymond_client" is the program that analyses the client data and generates the status updates, so when you configure the client for "client-side" configuration, then you get this extra binary. However, it also uses a lot of external libraries that you can avoid installing on all of the servers you monitor by using server-side configuration.
Den 2014-02-08 3:49, John Thurston skrev:
I've been using my Solaris BB clients with my Xymon server, but am hoping the xymon client will be more zfs-aware than the ancient BB client. To that end, I'm trying to compile a xymon client.
I've spent most of the day fighting with the 'make' process.
[snip]
It appeared to me to only require the pcre libraries. Were there others I missed?
Client-side really is a hack, and it will probably be removed in v5. So I really do recommend that you use server-side configuration, to keep the client installation as dumb as possible.
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.
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?
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.
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 ~/*.
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.
- snip -
Building only the client with "configure --client" should work, but I'll readily admit that testing on Solaris is not at the top of my priority list.
I can understand that. We Solaris users are decreasing in number (thanks Oracle!).
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska
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
participants (3)
-
henrik＠hswn.dk
-
john.thurston＠alaska.gov
-
novosirj＠ca.rutgers.edu