[Xymon] [External] Re: Windows XymonPSClient v2.37

Timothy Williams tlwilliams4 at vcu.edu
Wed Feb 20 20:18:45 CET 2019


Likely the URL is not accessible from the box. Try to use the bb:// version
to pick up file from xymon/download folder. I had issues a few weeks ago on
one of my networks reaching any HTTP sites, but the bb:// uses TCP port
1984 directly off Xymon server..

clientversion:2.37:bb://

Tim Williams


On Wed, Feb 20, 2019 at 11:55 AM Kris Springer <kspringer at innovateteam.com>
wrote:

> I left it running overnight to see if the slowscan was the issue, but the
> cycle has passed more than once now.  The current log said it was on
> collection 36 of 72.
>
> I just restarted the service, waited 15 minutes to let things cycle a few
> times, but still no update is occurring.
>
> Here's the last few lines of the xymonclient.log
>
> -----------------------------
> 2019-02-20 08:48:16  Connecting to host 10.0.0.55
> 2019-02-20 08:48:16  Sent 84667 bytes to server
> 2019-02-20 08:48:16  Received 101 bytes from server
> 2019-02-20 08:48:16  RepeatTests: nothing to do!
> 2019-02-20 08:48:16  Using new remote config, saving locally
> 2019-02-20 08:48:16  Found a command: clientversion:2.37:
> https://redacted.com/xymon/scripts|MD5|a438ab32188505438e41444558578477
> 2019-02-20 08:48:16  Cached config now contains:
> 2019-02-20 08:48:16  clientversion:2.37:
> https://redacted.com/xymon/scripts|MD5|a438ab32188505438e41444558578477
> 2019-02-20 08:48:16  XymonLogSend: nothing to do!
> 2019-02-20 08:48:16  Delaying until next run: 295.3749488 seconds
> -----------------------------
>
> Kris Springer
>
>
>
> On 2/20/19 8:58 AM, Beck, Zak wrote:
>
> Hi
>
>
>
> The client only updates on slowscans – usually every 6 hours – one of
> first lines in the logs will tell which scan number you are on and which
> will be the next slow scan.
>
>
>
> You can force a slow scan by stop/starting the service.
>
>
>
> If you have waited more than 6 hours, then you have some other issue – can
> you check the log on a slow scan? Usually easiest to do this by stopping
> the service and then running the client manually in a Powershell prompt.
>
>
>
> Cheers
>
>
>
> Zak
>
>
>
> *From:* Kris Springer <kspringer at innovateteam.com>
> <kspringer at innovateteam.com>
> *Sent:* Wednesday, 20 February 2019 15:39
> *To:* Beck, Zak <zak.beck at accenture.com> <zak.beck at accenture.com>; Xymon
> MailingList <xymon at xymon.com> <xymon at xymon.com>
> *Subject:* [External] Re: [Xymon] Windows XymonPSClient v2.37
>
>
>
> This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with
> links and attachments.
> ------------------------------
>
>
>
> I'm trying to remotely update a v2.28 client to the latest 2.37 version by
> following the instructions in the XymonPSClient.doc, but the client isn't
> updating.  Here's what I've done.  Maybe I'm missing something.
>
> 1. Download the latest xymonclient.ps1 from github and place it in my
> server's scripts directory.  (This is the directory where I run other
> client scripts successfully)
>
> 2. Rename the xymonclient.ps1 file to xymonclient_2.37.ps1 (per the doc
> instructions)
>
> 3. Get the md5sum of the file
>
> 4. Add the following line to the client-local.cfg file on the server for
> the specific host I'm trying to update. (per the doc instructions)
> clientversion:2.37:
> https://my.domain.com/xymon/scripts:MD5:md5sumadlkfskdkfkfdl
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__my.domain.com_xymon_scripts-3AMD5-3Amd5sumadlkfskdkfkfdl&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=nCeHIt-8vEpIrED5Cu3dEPfxpWypoQE_ddD6QQAX9Ws&s=05m99yiMkc-55R1AKXecttl5doV-7QYCPGCbqVr5S_s&e=>
>
> 5. Check that the xymonclient_config.xml on the client has
> <clientremotecfgexec>1</clientremotecfgexec>
>
> When I look at the logs on the client it says it sees the instruction from
> the server, but it doesn't perform any action.  The client version never
> changes.
>
>
> Kris Springer
>
>
>
>
>
>
>
> ------------------------------------------
>
>
>
> On 2/15/19 5:03 AM, Beck, Zak wrote:
>
> Hi
>
>
>
> I have committed v2.37 today, this has a big performance related fix and
> other fixes – thanks to SebA <spah at syntec.co.uk> and Andy
> abs at shadymint.com for extra work and prompting in this area.
>
>
>
> Download from SVN
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_xymon_code_HEAD_tree_sandbox_WinPSClient_&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=nCeHIt-8vEpIrED5Cu3dEPfxpWypoQE_ddD6QQAX9Ws&s=L-dhmcu_CM75-ARQ7kmDxV7wP_abxGZqOuUDmZXC-RE&e=>
> (the documentation has been updated also, including uninstall instructions).
>
>
>
> The key fixes are:
>
>
>
> * replaced WMI call to get number of processors with Windows API call
>
>
>
> The WMI call to get processor information was taking anything from 4-5
> seconds on most of my VMs, some experience much longer waits and high CPU
> usage while this WMI call executed. There have also been instances where
> the WMI call returns incorrect data or no data. This has been replaced with
> a call to GetNativeSystemInfo(), which should work on 32-bit and 64-bit
> platforms and in testing executes in milliseconds.
>
>
>
> * only supply diskpart data if EnableDiskPart = 1
>
>
>
> There is a test in the client which uses ‘diskpart’ to gather information
> about clustering every slow scan. This is included in the data sent to
> Xymon, but it’s not generally displayed – you can extract it for reporting
> if needed. Hardly anyone uses this and for some reason for some people it
> is causing memory issues in the Microsoft Virtual Disk Service. Therefore
> by default the test will now not be run, you can enable it with the
> EnableDiskPart setting in xymonclient_config.xml.
>
>
>
> * add a dummy, ignored config item in the internal client-local config
> table so that there is always some configuration present (even if nothing
> in the server-side client-local for this host)
>
>
>
> We found that if there is no client-local.cfg for the host and no default
> client-local.cfg (like [powershell] or [XymonPS]), on some platforms there
> appears to be a memory leak. The fix ensures there is always something in
> the internal cache of client-config even if nothing is received from the
> server.
>
>
>
> * XymonAcceptUTF8 - default (0) is now to use the original ASCII encoding,
> added setting for 'pure' ASCII coding which strips/converts diacritic
> characters
>
>
>
> Prior to this version, by default, the client uses ASCII encoding to send
> to the server but also attempts to encode/filter diacritic characters. This
> was added in v2.20, and for some people it adds a large time overhead when
> sending data.
>
>
>
> It’s been changed so that the default setting of 0 acts like it did before
> v2.20 – no diacritic encoding – I’m calling this ‘original’ ASCII encoding.
> XymonAcceptUTF8 = 1 is unchanged, uses UTF8. XymonAcceptUTF8 = 2 is the
> v2.20 setting, use ASCII and encode/filter diacritics – I’m calling this
> ‘pure’ ASCII encoding. I don’t think this will impact on many people other
> than saving time/cpu for the default setting.
>
>
>
> Full changelog:
>
>
>
> v2.37
>
> * replaced WMI call to get number of processors with Windows API call
>
> * fixed servicecheck parentheses
>
> * use TLS for uploading data to xymoncgi if using http reporting and URL
> begins https
>
> * add milliseconds to log timestamp
>
> * add a dummy, ignored config item in the internal client-local config
> table so that there is always some configuration present (even if nothing
> in the server-side client-local for this host)
>
> * fix a couple of instances where we were using variables before they are
> assigned
>
>
>
> settings changes/additions:
>
> * XymonAcceptUTF8 - default (0) is now to use the original ASCII encoding,
> added setting for 'pure' ASCII coding which strips/converts diacritic
> characters
>
> * only supply diskpart data if EnableDiskPart = 1
>
>
>
>
>
> Zak
>
>
>
>
> ------------------------------
>
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If you have
> received it in error, please notify the sender immediately and delete the
> original. Any other use of the e-mail by you is prohibited. Where allowed
> by local law, electronic communications with Accenture and its affiliates,
> including e-mail and instant messaging (including content), may be scanned
> by our systems for the purposes of information security and assessment of
> internal compliance with Accenture policy. Your privacy is important to us.
> Accenture uses your personal data only in compliance with data protection
> laws. For further information on how Accenture processes your personal
> data, please see our privacy statement at
> https://www.accenture.com/us-en/privacy-policy.
>
> ______________________________________________________________________________________
>
> www.accenture.com
>
>
> _______________________________________________
>
>
>
> Xymon mailing list
>
>
>
> Xymon at xymon.com
>
>
>
> http://lists.xymon.com/mailman/listinfo/xymon <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.xymon.com_mailman_listinfo_xymon&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=nCeHIt-8vEpIrED5Cu3dEPfxpWypoQE_ddD6QQAX9Ws&s=dlri1VGEnUrfF1SmKT2_B0vclSkFM--ZA8iIjLbfCtk&e=>
>
>
>
>
>
>
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20190220/dfc264d7/attachment.html>


More information about the Xymon mailing list