xymon, xymon-rclient and md5sum checks

ohemming＠gmail.com

3 Jun 2015 3 Jun '15

2:56 p.m.

This is a brand new installation of Xymon (4.3.21) and I'm trying to use xymon-rclient (0.6) to get some readings on a box where we're not allowed to run the Xymon client.

My hosts.cfg has this line: 10.6.16.24 server2 # conn "RCLIENT:cmd(ssh -T root@%{H}),ostype(sunos),env(MD5=/usr/local/bin/md5sum)"

My analysis.cfg has: HOST=%^server FILE /etc/.sudoers.local red md5=3478c3977fd53a9de552bf1545595b31 PORT "LOCAL=%(.80|.443)$" STATE=LISTEN col=yellow TEXT=HTTP PROC xntpd col=red

My client-local.cfg (on the Xymon server) has: [server2] file:/etc/.sudoers.local:md5

All the tests are working fine (cpu/disk/procs/ports etc) but the md5 on /etc/.sudoers.local is failing. The Xymon status says: /etc/.sudoers.local File has MD5 hash (No MD5 data) - should be 3478c3977fd53a9de552bf1545595b31

So it looks like it's not being read/checksummed.

Here's some CLI output to show the paths/os/results etc [xymon at xymon]$ ssh root at server2 "/usr/local/bin/md5sum /etc/.sudoers.local; uname -a" 3478c3977fd53a9de552bf1545595b31 /etc/.sudoers.local SunOS server2.sjo1 5.10 Generic_142910-17 i86pc i386 i86pc

In the clientlog, it says "[file:/etc/.sudoers.local]" with no extra information

I'm doing a similar test on a the Xymon server and in that clientlog, I see:

[file:/app/scripts/check_sudoers/golden/as/etcdotsudoersdotlocal] type:100000 (file) mode:444 (-r--r--r--) linkcount:1 owner:10002 (t3user) group:3284 (t3group) size:102 clock:1433342702 (2015/06/03-14:45:02) atime:1433275649 (2015/06/02-20:07:29) ctime:1432929163 (2015/05/29-19:52:43) mtime:1432054326 (2015/05/19-16:52:06) md5:3478c3977fd53a9de552bf1545595b31

Questions:

Should this be working or is it a limitation of xymon-rclient?
What, if anything, is wrong with my config?

Thanks for reading

Show replies by date

jlaidman＠rebel-it.com.au

4 Jun 4 Jun

1:57 a.m.

On 4 June 2015 at 00:56, oliver <ohemming at gmail.com> wrote:

...

Should this be working or is it a limitation of xymon-rclient?

It's the latter, I'm afraid. :-(

xymon-rclient is intended to (among other things) emulate logfetch, which is where the md5 hashing is implemented. I don't believe any part of Xymon (client or server) uses the MD5 environment variable, so setting will have no effect.

...

What, if anything, is wrong with my config?

Nothing that I can see. It's just not (yet) supported. I couldn't remember for sure, but comments in the source code are my off-line memory:

# Note: Due to the complexity in keeping state,
# only "file:" and "dir:" are implemented at this
# stage.  Neither can backticks be used yet (the
# result is unknown).  The "file:" setting cannot
# use the optional hash field yet.  Linecount does
# not require state, but simply hasn't yet been
# implemented.

Also, the "file:" line parser code (line 482) simply discards anything after a second colon.

Patches are welcome. ;-)

Cheers Jeremy

ohemming＠gmail.com

7:47 p.m.

On Wed, Jun 3, 2015 at 9:57 PM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:

...

...

Should this be working or is it a limitation of xymon-rclient?

It's the latter, I'm afraid. :-(

xymon-rclient is intended to (among other things) emulate logfetch, which is where the md5 hashing is implemented. I don't believe any part of Xymon (client or server) uses the MD5 environment variable, so setting will have no effect.

Thanks for confirming. I missed your comments in the script about 'hash field' because I was looking for md5 - d'oh.

I've switched to checking file size instead and have this in my analysis.cfg: FILE /etc/sudoers red SIZE=1192

It works for a linux client but not for a solaris one. Is this a problem with Xymon's .../client/bin/xymonclient-sunos.sh file or something I need to modify in the xymon-rclient.sh script?

If I click on the 'red' filename from a Solaris box, I see this: [file:/etc/sudoers]

If I click on the 'green' filename from a Linux box, I see this: [file:/etc/sudoers] type:100000 (file) mode:440 (-r--r-----) linkcount:1 owner:0 (root) group:0 (root) size:1192 clock:1433446819 atime:1433446799 ctime:1433420119 mtime:1433420119

and I assumed this was output from 'stat' that the Solaris one is obviously missing

I tried symlinking /usr/bin/stat to /usr/local/bin/stat on the Solaris box but it stays red.

Any idea where to go from here?

jlaidman＠rebel-it.com.au

5 Jun 5 Jun

2:10 a.m.

No, it's not using "stat". Instead, it's using a series of shell commands, and in some cases (such as for the "*time" and "group" lines) a bit of perl. If you're interested, you can check how it's all done in the send_logfetch_file() function (from line 323). This function essentially creates a sequence of commands that get sent to the shell on the remote client.

I have no idea why it's not working for Solaris. But I can confirm that it's not working for my Solaris boxes also. This means I can do some testing here and (I hope) come up with a fix. Sorry I can't offer any more at this stage.

On 5 June 2015 at 05:47, oliver <ohemming at gmail.com> wrote:

...

On Wed, Jun 3, 2015 at 9:57 PM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:

...
...

Should this be working or is it a limitation of xymon-rclient?

It's the latter, I'm afraid. :-(

xymon-rclient is intended to (among other things) emulate logfetch, which is where the md5 hashing is implemented. I don't believe any part of Xymon (client or server) uses the MD5 environment variable, so setting will have no effect.

Thanks for confirming. I missed your comments in the script about 'hash field' because I was looking for md5 - d'oh.

I've switched to checking file size instead and have this in my analysis.cfg: FILE /etc/sudoers red SIZE=1192

It works for a linux client but not for a solaris one. Is this a problem with Xymon's .../client/bin/xymonclient-sunos.sh file or something I need to modify in the xymon-rclient.sh script?

If I click on the 'red' filename from a Solaris box, I see this: [file:/etc/sudoers]

If I click on the 'green' filename from a Linux box, I see this: [file:/etc/sudoers] type:100000 (file) mode:440 (-r--r-----) linkcount:1 owner:0 (root) group:0 (root) size:1192 clock:1433446819 atime:1433446799 ctime:1433420119 mtime:1433420119

and I assumed this was output from 'stat' that the Solaris one is obviously missing

I tried symlinking /usr/bin/stat to /usr/local/bin/stat on the Solaris box but it stays red.

Any idea where to go from here?

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

ohemming＠gmail.com

9 Jun 9 Jun

7:24 p.m.

On Thu, Jun 4, 2015 at 10:10 PM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:

...

No, it's not using "stat". Instead, it's using a series of shell commands, and in some cases (such as for the "*time" and "group" lines) a bit of perl. If you're interested, you can check how it's all done in the send_logfetch_file() function (from line 323). This function essentially creates a sequence of commands that get sent to the shell on the remote client.

I have no idea why it's not working for Solaris. But I can confirm that it's not working for my Solaris boxes also. This means I can do some testing here and (I hope) come up with a fix. Sorry I can't offer any more at this stage.

I think I see the problem.

Line 310: echo "if [ \"$FILENAME\" -a -e \"$FILENAME\" ]; then"

If I construct a similar command on a linux box, I get this: $ [ /etc/sudoers -a -e /etc/sudoers ] && echo hello hello

but on Solaris, I get this: $ [ /etc/sudoers -a -e /etc/sudoers ] && echo hello test: argument expected

I guess you could drop the -e and it will still work for both linux/solaris or add another 'if' statement.... something like this (but I'm not sure if this is the best way:)

    if [ "$OSTYPE" = "sunos" ] || [ "$SCRIPTOS" = "sunos" ]; then
      echo "if [ \"$FILENAME\" -a \"$FILENAME\" ]; then"
    else
      echo "if [ \"$FILENAME\" -a -e \"$FILENAME\" ]; then"
    fi

Either way, it's working for me now using the 'if' method - but Solaris and Linux is all I have. If there's a better way to do it, please let me know.

Paul.Root＠CenturyLink.com

7:49 p.m.

This issue is actually what shell you are running, not the OS.

The default shell for root in Solaris is sh, that can't handle the test. But the default shell for root in Linux is bash.

-----Original Message----- From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of oliver Sent: Tuesday, June 09, 2015 2:25 PM To: Xymon at xymon.com Subject: Re: [Xymon] xymon, xymon-rclient and md5sum checks

On Thu, Jun 4, 2015 at 10:10 PM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:

...

No, it's not using "stat". Instead, it's using a series of shell commands, and in some cases (such as for the "*time" and "group" lines) a bit of perl. If you're interested, you can check how it's all done in the send_logfetch_file() function (from line 323). This function essentially creates a sequence of commands that get sent to the shell on the remote client.

I have no idea why it's not working for Solaris. But I can confirm that it's not working for my Solaris boxes also. This means I can do some testing here and (I hope) come up with a fix. Sorry I can't offer any more at this stage.

I think I see the problem.

Line 310: echo "if [ \"$FILENAME\" -a -e \"$FILENAME\" ]; then"

If I construct a similar command on a linux box, I get this: $ [ /etc/sudoers -a -e /etc/sudoers ] && echo hello hello

but on Solaris, I get this: $ [ /etc/sudoers -a -e /etc/sudoers ] && echo hello test: argument expected

I guess you could drop the -e and it will still work for both linux/solaris or add another 'if' statement.... something like this (but I'm not sure if this is the best way:)

    if [ "$OSTYPE" = "sunos" ] || [ "$SCRIPTOS" = "sunos" ]; then
      echo "if [ \"$FILENAME\" -a \"$FILENAME\" ]; then"
    else
      echo "if [ \"$FILENAME\" -a -e \"$FILENAME\" ]; then"
    fi

Either way, it's working for me now using the 'if' method - but Solaris and Linux is all I have. If there's a better way to do it, please let me know.

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

Paul.Root＠CenturyLink.com

7:55 p.m.

Also, your solution doesn't work.

The test as written is testing that the variable $FILENAME is not null, and then testing to see if the file exists. Removing the -e just tests that the variable is not null twice.

The solution would be more like: echo "if [ \"$FILENAME\" != \"\" -a -e \"$FILENAME\" ]; then"

On Thu, Jun 4, 2015 at 10:10 PM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:

...

No, it's not using "stat". Instead, it's using a series of shell commands, and in some cases (such as for the "*time" and "group" lines) a bit of perl. If you're interested, you can check how it's all done in the send_logfetch_file() function (from line 323). This function essentially creates a sequence of commands that get sent to the shell on the remote client.

I have no idea why it's not working for Solaris. But I can confirm that it's not working for my Solaris boxes also. This means I can do some testing here and (I hope) come up with a fix. Sorry I can't offer any more at this stage.

I think I see the problem.

Line 310: echo "if [ \"$FILENAME\" -a -e \"$FILENAME\" ]; then"

If I construct a similar command on a linux box, I get this: $ [ /etc/sudoers -a -e /etc/sudoers ] && echo hello hello

but on Solaris, I get this: $ [ /etc/sudoers -a -e /etc/sudoers ] && echo hello test: argument expected

I guess you could drop the -e and it will still work for both linux/solaris or add another 'if' statement.... something like this (but I'm not sure if this is the best way:)

    if [ "$OSTYPE" = "sunos" ] || [ "$SCRIPTOS" = "sunos" ]; then
      echo "if [ \"$FILENAME\" -a \"$FILENAME\" ]; then"
    else
      echo "if [ \"$FILENAME\" -a -e \"$FILENAME\" ]; then"
    fi

Either way, it's working for me now using the 'if' method - but Solaris and Linux is all I have. If there's a better way to do it, please let me know.

ohemming＠gmail.com

8:28 p.m.

On Tue, Jun 9, 2015 at 3:55 PM, Root, Paul T <Paul.Root at centurylink.com> wrote:

...

Also, your solution doesn't work.

The test as written is testing that the variable $FILENAME is not null, and then testing to see if the file exists. Removing the -e just tests that the variable is not null twice.

The solution would be more like: echo "if [ \"$FILENAME\" != \"\" -a -e \"$FILENAME\" ]; then"

Thanks - makes more sense now but I think you added an errant -e in that solution :-)

jlaidman＠rebel-it.com.au

10:29 p.m.

On 10 June 2015 at 06:28, oliver <ohemming at gmail.com> wrote:

...

On Tue, Jun 9, 2015 at 3:55 PM, Root, Paul T <Paul.Root at centurylink.com> wrote:

...
The solution would be more like: echo "if [ \"$FILENAME\" != \"\" -a -e \"$FILENAME\" ]; then"

Thanks - makes more sense now but I think you added an errant -e in that solution :-)

Yes, and no. The "-e" for "exists" is a required test. The fact that it isn't supported as such on Solaris Bourne shell (sh) means that we need an alternative. The solution you proposed is to effectively not test for the file's existence, meaning that if the file exists, no problem, but if the file doesn't exist, error and unknown consequences.

Paul's solution was attempting to solve a perceived problem about Solaris Bourne shell's ability to test whether a string is non-empty, and I'm guessing he thought that was the cause of the error. But it's not.

A workable solution is to substitute "-f" for "-e". The difference between "-f" and "-e" is that "-f" tests for a file that exists AND is a regular file. In our situation, it's going to be rare that we would want a Xymon file test on a non-file (socket, pipe, device) and so for our purposes, "-f" is a suitable replacement. Other alternatives that might be suitable are "-r" (exists and is readable) or "-s" (exists and has size >0) but I can imagine cases where these might not fit requirements, so "-f" is probably the most useful alternative.

So the following should work:

echo "if [ \"$FILENAME\" -a -f \"$FILENAME\" ]; then"

Thanks for the bug report. I'll update the version on my site in the next day or so.

Cheers Jeremy

4033

Age (days ago)

4039

Last active (days ago)

List overview

Download

8 comments

3 participants

participants (3)

jlaidman＠rebel-it.com.au
ohemming＠gmail.com
Paul.Root＠CenturyLink.com