June 2018 - Xymon - Xymon mailman web

Syntax for regular expression in client-local.cfg
by EDSchminke＠Hormel.com 08 Jun '18

08 Jun '18

1 0

EXTIME/TIME syntax
by losburn＠thepinnaclegroup.com 07 Jun '18

07 Jun '18

Attempting to prevent "false" cpu alarms during overnight processing, I have included a line in analysis.cfg thus: LOAD 4.0 6.0 HOST=blueteam EXTIME=W:2200:0400 However, alarms continue to be generated during the "excluded" hours. Has anyone else had any difficulty with either TIME or EXTIME entries? Thanks!

4 3

How to get Windows Update info from client
by jtrott＠dancrai.com 07 Jun '18

07 Jun '18

Hi Kris. Nice work on the figuring! Checking the code for xymonclient.ps1 finds this function: function XymonDownloadFromURL([string]$downloadURL, [string]$destinationFilePath) { $downloadURL = $downloadURL.Trim() WriteLog "XymonDownloadFromURL - Downloading $downloadURL to $destinationFilePath" $client = New-Object System.Net.WebClient try { # for self-signed certificates, turn off cert validation # TODO: make this a config option [Net.ServicePointManager]::ServerCertificateValidationCallback = {$true} $client.DownloadFile($downloadURL, $destinationFilePath) } catch { WriteLog "Error downloading: $_" return $false } return $true } A bit of googling returns the collective knowledge that by default that command only uses TLS 1.0. Seems broken.... Apparently you can add the following line to enable more protocols: [Net.ServicePointManager]::SecurityProtocol = "tls12, tls11, tls" So I'll copy in the xymon list so someone more knowledgeable can tell me that I am wrong. Thanks, JT > I figured it out! I set my server up to only use TLSv1.2 and apparently > the Xymon PS download scripts can't work with v1.2, they need 1.0. When > I reduced the TLS level down to allow v1.0 on my server it downloaded > the file as expected. > > Any idea how to allow the Xymon client scripts to work with TLSv1.2? > > > Thank you. > ------------------------------------------------ > Kris Springer

2 1

How to get Linux Update info from client
by kspringer＠innovateteam.com 07 Jun '18

07 Jun '18

An HTML attachment was scrubbed... URL: <http://lists.xymon.com/pipermail/xymon/attachments/20180605/661b3451/attach…>

4 4

Monitoring file ownership
by glauber.ribeiro＠experian.com 04 Jun '18

04 Jun '18

Xymon has me stumped twice today... some kind of record, for me. How do I monitor a file for change in ownership: Right now, "client data" has [file:/logs/vingate/server.log] type:100000 (file) mode:644 (-rw-r--r--) linkcount:1 owner:20602 (siadmin) group:20600 (sysint) size:19298 clock:1528142104 (2018/06/04-14:55:04) atime:1528130404 (2018/06/04-11:40:04) ctime:1528130394 (2018/06/04-11:39:54) mtime:1528130394 (2018/06/04-11:39:54) I want it to go red if the owner changes. Documentation says: ownerid=OWNER triggers a warning if the owner does not match what is listed here. OWNER is specified either with the numeric uid, or the user name. I notice that the data has "owner" instead of "ownerid". However, I can't seem to get it to work, either using the numeric (20602) or the text (siadmin) id. I currently have, in analysis.cfg: HOST=(hostname) FILE /logs/vingate/server.log red ownerid=20603 But it's not turning red. Any ideas? How have you done it? Thanks, g

1 1

Syntax for regular expression in client-local.cfg
by glauber.ribeiro＠experian.com 04 Jun '18

04 Jun '18

What is the syntax for using regular expressions in client-local.cfg? Is it [host=regexp] or [host=%regexp]? Does it require quotes? Thanks, glauber

2 1

[SOLVED] Cannot issue STARTTLS for ldap:389 -- xymon server 4.3.28
by scott.birl＠temple.edu 01 Jun '18

01 Jun '18

That was indeed to trick: use the ldaps test against 389. (surprised I didnt think of that beforehand!) On 6/1/2018 8:44 AM, Scott Birl wrote: > > Hello all: > > > > Running the 4.3.28 server. > > > > My LDAP team wants me to monitor their LDAP farm over both 636 *and* 389. Monitoring 636 is working as expected, but 389 is not; at least not 100%. > > ServerA's 389 has not required the use of STARTTLS, yet, so monitoring it is working well. > > ServerB's 389 is requiring the use of STARTTLS, and tests are failing red with an output of "unknown error." > > > > (Yes, there are applications outside of Xymon that can connect to 389 using STARTTLS with no problem.) > > > > I modified ~xymon/server/etc/protocols.cfg to have the [ldap] section to use "options ssl", but my LDAP team tells me that STARTTLS is not present, and tests are still red. > > > > I ran: strace ~xymon/server/bin/xymonnet --debug --report ServerB > > and I can see the connection being made, as well as the ldaplogin bind credentials being passed over, but certainly no STARTTLS is being passed. > > > > On the receiving end of the strace, I see: > > read(3, "\1\r\4\0\4\30confidentiality required", 30) = 30 > > write(1, "101588 2018-06-01 11:52:08.27042"..., 81101588 2018-06-01 11:52:08.270421 ldap_result returned 97 for ldap_simple_bind()) = 81 > > followed by the "LDAP output: Unknown error" > > > > > > The hosts.cfg has this entry for its LDAP tests for ServerA and ServerB. > > ldap://10.96.160.XX:389/dc=DOMAIN,dc=ORG??sub?(uid=moof8) ldaplogin=cn=USER,ou=roles,dc=DOMAIN,dc=ORG:********* > > > > > > > > Is there something that I am missing in order to have Xymon issue a STARTTLS for 389? > > > > If you want a STARTTLS, I think you should be using the ldaps test: > > 0.0.0.0 serverA.bar.com # ldap://blah blah blah > 0.0.0.0 serverB.bar.com # ldaps://blah blah blah > > > The ldap tests in xymonnet have always been a point of confusion for me, > but I recall finding there are two different tests. The first is > specified by test:port syntax: > 0.0.0.0 foo.bar.com # ldap:399 > 0.0.0.0 baz.bar.com # ldaps:666 > This test uses the lines in protocols.cfg and is pretty brain-dead. > > The second test is specified by URL syntax: > 0.0.0.0 foo.bar.com # ldap://foo.bar.com:399/blah blah blah > 0.0.0.0 baz.bar.com # ldaps://baz.bar.com:666/blah blah blah > This test ignores everything in protocols.cfg, but still reports under > the ldap column. > > The use of ldap/ldaps strings to name both tests caused me all kinds of > confusion. I eventually evaded this by creating my own protocol.cfg (and > referencing it in the stock file). It contains the the following: > > [ldap|ldapPort] > port 389 > > [ldaps|ldapsPort] > options ssl > port 636 > > This redefines the stock ldap/ldaps tests, but defines an alias for each > of them. When I want the brain-dead test, I use the alias of my own > creation. In my hosts.cfg, I have lines like > > > 0.0.0.0 foo.bar.com # ldapPort:389 ldapsPort:667 ldaps://foo.bar.com:667/blah blah blah > > Which gives the three columns. I can see the results of the query under > the 'ldap' column. I can also see if ldap or ldaps brain-dead > connections are working. Yes, I see what you're saying, and though the strace shows xymonnet reading in protocols.cfg, I didnt think it was ignoring it. Our :389 starts off in the clear, but then needs to be wrapped in starttls. I never did get a clear explanation on how this differs from their :636; I just know they want routine test results from both :389 and :636. I did try just brain-dead "ldap" without any search parameters, but that too failed once the connection wasnt over TLS. One thing I havent tried is an LDAPS test using :389 as the port: ldaps://10.96.160.XX:389/dc=DOMAIN,dc=ORG??sub?(uid=moof8) ldaplogin=cn=USER,ou=roles,dc=DOMAIN,dc=ORG:********* I'll give that a shot on one of the servers. Thanks.

1 0

Cannot issue STARTTLS for ldap:389 -- xymon server 4.3.28
by scott.birl＠temple.edu 01 Jun '18

01 Jun '18

Hello all: Running the 4.3.28 server. My LDAP team wants me to monitor their LDAP farm over both 636 *and* 389. Monitoring 636 is working as expected, but 389 is not; at least not 100%. ServerA's 389 has not required the use of STARTTLS, yet, so monitoring it is working well. ServerB's 389 is requiring the use of STARTTLS, and tests are failing red with an output of "unknown error." (Yes, there are applications outside of Xymon that can connect to 389 using STARTTLS with no problem.) I modified ~xymon/server/etc/protocols.cfg to have the [ldap] section to use "options ssl", but my LDAP team tells me that STARTTLS is not present, and tests are still red. I ran: strace ~xymon/server/bin/xymonnet --debug --report ServerB and I can see the connection being made, as well as the ldaplogin bind credentials being passed over, but certainly no STARTTLS is being passed. On the receiving end of the strace, I see: read(3, "\1\r\4\0\4\30confidentiality required", 30) = 30 write(1, "101588 2018-06-01 11:52:08.27042"..., 81101588 2018-06-01 11:52:08.270421 ldap_result returned 97 for ldap_simple_bind()) = 81 followed by the "LDAP output: Unknown error" The hosts.cfg has this entry for its LDAP tests for ServerA and ServerB. ldap://10.96.160.XX:389/dc=DOMAIN,dc=ORG??sub?(uid=moof8) ldaplogin=cn=USER,ou=roles,dc=DOMAIN,dc=ORG:********* Is there something that I am missing in order to have Xymon issue a STARTTLS for 389? Thanks. Birl

2 2

Alias for test name?
by john.thurston＠alaska.gov 01 Jun '18

01 Jun '18

I'm looking for an easy way to have the same test result appear under two different column headings. Here's an example: Host foo.bar.com reports red for the test named 'sql'. This is cool for one page in the xymon web interface. But on a different page, I want that same test result to appear under a column named 'database'. I'm currently getting this done by running the 'combostatus' task, and having an entry in combo.cfg: foo.bar.com.database = foo.bar.com.sql This works, but causes the state of 'database' to trail that of 'sql' by one interval. I've found the 'compact' tag, which lets one cram the status of several tests into one. A line in hosts.cfg like: 0.0.0.0 foo.bar.com # compact:database=sql creates a new column named 'database' which closely tracks 'sql'. But the column name is real, in the sense that the green/red bubble is hyperlinked to svcstatus.sh?HOST=foo.bar.com&SERVICE=database rather than to SERVICE=sql. There aren't any test results for 'database', so the link isn't any good. Can anyone suggest another way? If 'combostatus' is the best I can use, what would be the consequence of shortening its interval? If I shorten the interval (from 5min) to 3min or 1min, my test aliases should track more closely to the real test results. Is there some reason this interval shouldn't be shorter than the common reporting interval? -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska

2 2

xymon server 4.3.28 -- Cannot issue STARTTLS for ldap:389
by scott.birl＠temple.edu 01 Jun '18

01 Jun '18

Hello all: Running the 4.3.28 server. My LDAP team wants me to monitor their LDAP farm over both 636 *and* 389. Monitoring 636 is working as expected, but 389 is not; at least not 100%. ServerA's 389 has not required the use of STARTTLS, yet, so monitoring it is working well. ServerB's 389 is requiring the use of STARTTLS, and tests are failing red with an output of "unknown error." (Yes, there are applications outside of Xymon that can connect to 389 using STARTTLS with no problem.) I modified ~xymon/server/etc/protocols.cfg to have the [ldap] section to use "options ssl", but my LDAP team tells me that STARTTLS is not present, and tests are still red. I ran: strace ~xymon/server/bin/xymonnet --debug --report ServerB and I can see the connection being made, as well as the ldaplogin bind credentials being passed over, but certainly no STARTTLS is being passed. On the receiving end of the strace, I see: read(3, "\1\r\4\0\4\30confidentiality required", 30) = 30 write(1, "101588 2018-06-01 11:52:08.27042"..., 81101588 2018-06-01 11:52:08.270421 ldap_result returned 97 for ldap_simple_bind()) = 81 followed by the "LDAP output: Unknown error" The hosts.cfg has this entry for its LDAP tests for ServerA and ServerB. ldap://10.96.160.XX:389/dc=DOMAIN,dc=ORG??sub?(uid=moof8) ldaplogin=cn=USER,ou=roles,dc=DOMAIN,dc=ORG:********* Is there something that I am missing in order to have Xymon issue a STARTTLS for 389? Thanks. Birl

1 0