Sorry, yes, tests that I create with outside scripts.

And that solution is exactly what I needed. I had tried re-enabling xymon-proxy with xymond also running, with no luck. I didn't even think about setting up the second port as a listener. Thank you so much for your help!

From: Root, Paul T [mailto:Paul.Root at CenturyLink.com] Sent: Friday, September 29, 2017 3:07 PM To: Ness, James E (JMD) <jness at jmd.usdoj.gov>; xymon at xymon.com Subject: RE: Forwarding custom status messages between Xymon servers

So by customer status messages, do you mean tests (columns) that you create with outside scripts or do you mean communications of existing tests?

So what I do, is I have XYMON2 (to use your naming) as a proxy and a server. The proxy listens on port 1984, and the server listens on 1985. Then the proxy forwards everything to port 1985 locally and to port 1984 on XYMON1. You have to handle disabling and such a little carefully (cascade those from XYMON1 to XYMON2 port 1985) or a broadcast storm happens. But it works well otherwise.

[xymond] ENVFILE /etc/xymon/xymonserver.cfg CMD xymond --listen=0.0.0.0:1985 --pidfile=$XYMONSERVERLOGS/xymond.pid --restart=$XYMONTMP/xymond.chk --checkpoint-file=$XYMONTMP/xymond.chk --checkpoint-interval=600 --log=$XYMONSERVERLOGS/xymond.log --admin-senders=127.0.0.1,$XYMONSERVERIP,XYMON1 --store-clientlogs=!msgs

[xymonproxy] ENVFILE /etc/xymon/xymonserver.cfg CMD $XYMONHOME/bin/xymonproxy --server=XYMON1,127.0.0.1:1985 --listen=0.0.0.0:1984 --report=$MACHINE.XYMON2 --no-daemon --pidfile=$XYMONSERVERLOGS/xymonproxy.pid LOGFILE $XYMONSERVERLOGS/xymonproxy.log

[xymonfetch] ENVFILE /etc/xymon/xymonserver.cfg CMD XYMONDPORT=1984 $XYMONHOME/bin/xymonfetch --server=XYMON2 --no-daemon --log-interval=60 --id=1 --pidfile=$XYMONSERVERLOGS/xymonfetch.pid LOGFILE $XYMONSERVERLOGS/xymonfetch.log

At the alerts end, XYMON2 monitors XYMON1, and when it can't see it, takes over by copying the alerts.cfg file in place. This is the rule:

HOST=XYMON1 COLOR=red SERVICE=bbd,conn DURATION>2 SCRIPT /usr/local/scripts/xymSecondaryTakeOver $NG-IM-ONCALL MAIL $NG-IM-ADMIN

Then there is a fall back script:

HOST=XYMON1 COLOR=red SERVICE=bbd,conn RECOVERED SCRIPT /usr/local/scripts/xymSecondaryRelease $NG-IM-ONCALL SCRIPT /usr/local/scripts/html_mail.pl $NG-IM-ADMIN

Lastly, XYMON1 handling disables and acknowledgements inf tasks.cfg:

[distribute]

DISABLED

    ENVFILE /usr/lib64/xymon/server/etc/xymonserver.cfg
    NEEDS xymond
    CMD xymond_channel --channel=enadis --log=$XYMONSERVERLOGS/distribute.log xymond_distribute \
            --peer=XYMON2:1985 --peer=XYMON3:1985

From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Ness, James E (JMD) Sent: Friday, September 29, 2017 12:49 PM To: xymon at xymon.com<mailto:xymon at xymon.com> Subject: [Xymon] Forwarding custom status messages between Xymon servers

To start out, my environment. Two Xymon servers, XYMON1 and XYMON2. XYMON1 is the master, and XYMON2 is the servant. At this time, there are a handful of machines using the Xymon client to report on themselves to XYMON2, which is dutifully forwarding that info on to XYMON1 (as expected). The clients also provide some custom status messages, which are NOT being forwarded from XYMON2 to XYMON1. I see they are picked up and properly processed by XYMON2, but that's it.

Previously, I had set XYMON2 as just a proxy, and both the client data and the custom status messages were sent to XYMON1. I can't go back to that, because XYMON1 will be decommissioned in the near future, and I need XYMON2 to take over. (I also have some other instances that I will eventually need to forward client data and status messages to XYMON2, but that is for later.) I've looked through so many man pages and can't find anything else that would point to what I might need to set to get this working, so I'm hoping someone on here can help me out. Or is this functionality that is not meant to work, no matter what I do?

Thank you in advance for your help. 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.