[Xymon] Web header corruption with cgi calls using xymonmenu.cfg and xymonpage - a workaround

henrik at hswn.dk henrik at hswn.dk
Mon Jan 20 10:24:18 CET 2014


Den 10.01.2014 19:56, Deiss, Mark skrev:
> Maybe this has been fixed in Xymon releases 4.3.11+. This is dealing
> with custom cgi's being placed into
> cgi-bin/cgi-secure that are calling the xymonpage procedure. Problem
> is being experienced in 4.3.11.
>
> When installing/modifying a custom module, running into corrupt web
> content with the
> upper menu installed through the xymonmenu.cfg/XYMONBODYHEADER
> mechanism via xymonpage. One variables is not
> being defined (XYMONSERVERSECURECGIURL) and de-referencing of another
> (XYMONSERVERWWWWURL) during
> execution. The latter condition is kinky; I tried tracing through
> xymonpage.c/headfoot.c but ended
> up getting lost. Until the XYMONSERVESECURECGIURL is ~~encountered in
> the xymonmenu.cfg, the XYMONSERVERWWWURL is
> being resolved.

I think this is caused by missing out the fact that xymonserver.cfg is 
NOT intended to be used directly in shell scripts. As it says at the 
very top of xymonserver.cfg:

    # NB : Even though it might look like a shell-script, it is NOT.


So when you do this:

> #!/bin/sh
> export XYMONHOME=<your path>/xymon/server
> . ${XYMONHOME}/etc/xymonserver.cfg

then you are doing it wrong. E.g. it won't handle any "include" or 
"directory" settings.


> function try1 {
> # 1) bad iteration, source in everything at parent level - this 
> results in erratic variable
> #       expansion in results, cannot find value for 
> XYMONSERVERSECURECGIURL and XYMONSERVERWWWURL
> #       initially defined but lost on first incidence of 
> XYMONSERVERSECURECGIURL (undefined)
> . ${XYMONHOME}/etc/xymonserver.cfg
> echo hello | \
>         ${XYMONHOME}/bin/xymonpage

You cannot source xymonserver.cfg. The correct way of doing what you 
want is:

echo hello | \
         ${XYMONHOME}/bin/xymoncmd 
--env=${XYMONHOME}/etc/xymonserver.cfg xymonpage

In other words, you must let xymoncmd process the xymonserver.cfg file, 
and then have xymoncmd directly invoke the Xymon command that you want 
to use. You can omit the "--env" option if you compiled Xymon with the 
correct XYMONHOME setting.


> function try2 {
> # 2) bad iteration, source in using xymoncmd - same erratic results
> exec ${XYMONHOME}/bin/xymoncmd --env=${XYMONHOME}/etc/xymonserver.cfg 
> echo hello | \
>         ${XYMONHOME}/bin/xymonpage
> }

Here xymoncmd sets up the environment for the "echo hello" command, but 
your SHELL does NOT pass this to the xymonpage command.


> function try3 {
> # 3) works, source in everything at parent level - to set up 
> environment for initial
> #       execution (the "echo hello" portion) then also re-introduce 
> environment in
> #       xymonpage using "--env" setting, xymonpage is not reliably 
> picking up runtime
> #       inherittance otherwise
> exec ${XYMONHOME}/bin/xymoncmd --env=${XYMONHOME}/etc/xymonserver.cfg 
> echo hello | \
>         ${XYMONHOME}/bin/xymonpage 
> --env=${XYMONHOME}/etc/xymonserver.cfg
> }

Yep, this works because xymonpage now reads xymonserver.cfg by itself. 
So it doesn't rely on things coming in via the environment variables. 
You don't need the xymoncmd at all, the "echo hello" doesn't use it 
(same as in 2)).


> function try4 {
> # 4) works
> . ${XYMONHOME}/etc/xymonserver.cfg
> echo hello | \
>         ${XYMONHOME}/bin/xymonpage 
> --env=${XYMONHOME}/etc/xymonserver.cfg
> }

Same as 3), but the source'ing of xymonserver.cfg is both wrong and 
useless.


Hope this helps.


Regards,
Henrik




More information about the Xymon mailing list