PSclient sending from intranet

I may have spoken too soon.  It's indeed working on box1, but when I edited the xymonclient_config.xml on box2 and re-entered the password so box2 would re-encrypt it for it's connection to the server, it's timing out.  Does each client need it's own individual user/pass?  That seems unnecessary.  I just tried different credentials and it still timed out.  The difference between box1 and box2 is the OS.  They're on the same network and can both reach the server via https so I don't think it's a networking issue.
box1 = Windows 10 Pro
box2 = Windows Server 2008 R2 Enterprise

Apache logs show nothing unusual.
I've looked at all the logs I can find on the server but I'm not seeing anything that would tip me off as to the issue.
Ideas?

Kris Springer


On 11/8/18 2:25 AM, Beck, Zak wrote:

Hi Kris

Yes, I have it working. As you say, the URL needs to include the full path to xymoncgimsg.cgi.

All xymoncgimsg.cgi does as far as I can tell is relay the message(s) received over HTTPS via TCP to localhost port 1984 (which is what the man page says as well). So you need that listening (which by default it will be).

I don’t recall making any other config changes to make this work (aside from Apache etc to sort out the authentication).

I suspect the time out is waiting for the response – when you submit data to Xymon, you normally get the client local config back from the server. This comes back via the HTTPS response. There is a timeout setting – sorry I forgot to document it in the table in the Word doc – serverHttpTimeoutMs – which defaults to 100000 milliseconds – i.e. 100 seconds. This is the time it waits for the response from the server. 100 seconds is pretty generous unless you’re traversing particularly slow VPNs or saturated connections. You can override this in the xymonclient_config.xml file.

I’m assuming you’re getting this message:

    "  Connecting to $($url), body length $($body.Length), timeout $($script:XymonSettings.serverHttpTimeoutMs)ms"

And then this one (with a timeout exception):

        "  Exception connecting to $($url):`n$($_)"

And not either of these:

        "  FAILED, HTTP response code: $($response.StatusCode) ($statusCode)"

or

        "  Received $($output.Length) bytes from server"

Zak

*From:*Xymon <xymon-bounces at xymon.com> *On Behalf Of *user-c2caa0a7a8d5@xymon.invalid
*Sent:* Thursday, 8 November 2018 08:51
*To:* Xymon MailingList <xymon at xymon.com>
*Subject:* [External] Re: [Xymon] PSclient sending from intranet

Anyone have xymoncgimsg.cgi functioning on their server and successfully receiving PSclient data over HTTPS?  The documentation for this is vague and doesn't specify how to make it work. Any specifics would be greatly appreciated.

Thanks,
Kris Springer


-----Original Message-----
From: Timothy Williams <user-1a5482fb085e@xymon.invalid <mailto:user-1a5482fb085e@xymon.invalid>>
To: user-c2caa0a7a8d5@xymon.invalid <mailto:user-c2caa0a7a8d5@xymon.invalid>
Cc: xymon at xymon.com <mailto:xymon at xymon.com>
Sent: Tue, 06 Nov 2018 2:22 PM
Subject: Re: [Xymon] PSclient sending from intranet

Alas, I am unable to help further, as my InfoSec allows port 1984, and not 80 or 443 to Xymon, so I don't have http running.

Tim

On Tue, Nov 6, 2018 at 3:29 PM Kris Springer <user-c2caa0a7a8d5@xymon.invalid <mailto:user-c2caa0a7a8d5@xymon.invalid>> wrote:

    I've configured one of my PSclients to test this HTTPS
    functionality, and it indeed does try to send data over port 443. 
    But the client logs say that my Xymon server is timing out.  Is
    there a specific server url path that I need to be using?  The
    documentation doesn't give any example.


    Kris Springer

      
    On 11/6/18 7:54 AM, Timothy Williams wrote:

        The Powershell client can connect to the Xymon server using
        TCP port 1984 as default, but can also connect using HTTP or
        HTTPS with/without user/password. You likely have port 80 or
        443 open. Here are Word doc details:

        HTTP is an alternate method. It can be used if you have
        xymoncgimsg.cgi running on the web server on your Xymon server
        – see
        https://www.xymon.com/help/manpages/man8/xymoncgimsg.cgi.8.html
        <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.xymon.com_help_manpages_man8_xymoncgimsg.cgi.8.html&d=DwMGaQ&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=-OwMT0n637myRsiGrh2Ey_FyOjBckX9cnzeXB9ID_dw&s=nwg-TdqZw8dbasxkybIMrt8HKpuV-U4Z2HpC5Rbr1BM&e=>;.
        The web server running the CGI can be configured for SSL (i.e.
        HTTPS) and / or authentication – XymonPSClient supports basic
        authentication and SSL. If you require authentication, the
        <serverHttpUsername> and <serverHttpPassword> elements should
        be configured.

        If you are using HTTP and transmitting over unsecure networks
        (e.g.  the internet), it is strongly recommended to enable
        SSL, authentication and disallow HTTP connections.

        ServerHttpPassword encryption

        If <serverHttpPassword> is set, the Xymon client will encrypt
        the password if it is not encrypted and remove the plain text
        password from the configuration file, overwriting with the
        encrypted password. The Xymon client will prefix the encrypted
        password with ‘{SecureString}’, so it is easy to tell if the
        client has attempted to encrypt the password or not.

        This is done using the .NET SecureString functions, which
        means that the encryption is unique to the server and user.
        This means that once the password has been encrypted, you
        cannot use the same xymonclient_config.xml on another server.
        It also means that if you have been testing by running
        XymonPSClient from a command prompt, and this encrypts the
        password, when you run XymonPSClient as a service it will not
        be able to decrypt the password unless the service is running
        as the same user.

        In both scenarios, replacing the encrypted password with the
        plain text password and re-starting Xymon will cause the
        password to be re-encypted.

        Tim Williams

        On Tue, Nov 6, 2018 at 9:37 AM Rolf Schrittenlocher
        <user-4b3b4051a09b@xymon.invalid
        <mailto:user-4b3b4051a09b@xymon.invalid>> wrote:

            any possibility to send something from intranet to the
            world outside?
            creating webpage, send by sftp or scp? This could be done
            by cron and
            xymon could analyze this data then.

Anyone have an idea about how to collect client server
            stats using the
Powershell client on machines that are on an intranet
            that blocks port
1984, and send it out to our external xymon server
            located in a
different part of the country?  The intranet network
            doesn't want to
open any additional ports to allow the traffic out.

            --             Mit freundlichen Grüßen
            Rolf Schrittenlocher

            Lokales Bibliothekssystem Frankfurt
            Bockenheimer Landstr. 134-138, 60325 Frankfurt
            Tel LBS: (49) 69 - 798 28830
            Tel persönlich: (49) 69 - 798 28908
            LBS: user-7d592aff76ba@xymon.invalid <mailto:user-7d592aff76ba@xymon.invalid>
            Persönlich: user-4b3b4051a09b@xymon.invalid

            <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.xymon.com_mailman_listinfo_xymon&d=DwMGaQ&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=-OwMT0n637myRsiGrh2Ey_FyOjBckX9cnzeXB9ID_dw&s=F_2sRqz669yemQ4GbrwkTlh6D0HtrNX1wqu7RvAN1WE&e=>;


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