Hi All
I am using nginx instead of apache with xymon. I set it up using the link http://timedoctor.org/2010/09/setting-up-xymonhobbit-with-nginx/
I am using nginx with xymon_4.3.12_amd64.deb from sourceforge.
To make the cgi links work I needed to create symlinks as the link above suggested.
/usr/lib/xymon/xymon-cgi -> /usr/lib/xymon/cgi-bin /usr/lib/xymon/xymon-seccgi -> /usr/lib/xymon/cgi-secure
Is that how everyone using it with nginx?
Please advise.
-- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
On Tue, Nov 12, 2013, at 12:27, Asif Iqbal wrote:
Hi All
I am using nginx instead of apache with xymon. I set it up using the link http://timedoctor.org/2010/09/setting-up-xymonhobbit-with-nginx/
I am using nginx with xymon_4.3.12_amd64.deb from sourceforge.
To make the cgi links work I needed to create symlinks as the link above suggested.
/usr/lib/xymon/xymon-cgi -> /usr/lib/xymon/cgi-bin /usr/lib/xymon/xymon-seccgi -> /usr/lib/xymon/cgi-secure
Is that how everyone using it with nginx?
Please advise.
I wrote that article a long time ago. Looks like my friend updated his blog to have a rather annoying theme :-)
I can't comment further as I needed to bring up Xymon on a test box and I didn't want to use Apache. That seemed to work at the time. Scanning the config again it doesn't seem completely out of place, but that symlink solution was a hack that probably could have been avoided.
On Tue, Nov 12, 2013 at 1:53 PM, Mark Felder <feld at feld.me> wrote:
symlink solution was a hack that probably could have been avoided.
Any suggestion on how to avoid that symlink?
-- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
On Mon, Nov 18, 2013, at 11:40, Asif Iqbal wrote:
On Tue, Nov 12, 2013 at 1:53 PM, Mark Felder <feld at feld.me> wrote:
symlink solution was a hack that probably could have been avoided.
Any suggestion on how to avoid that symlink?
I finally got around to figuring out Nginx + Xymon. You have to make some changes due to the way Nginx handles fastcgi variables when aliases are used.
http://blog.feld.me/posts/2014/11/setting-up-xymon-with-nginx/
On 11/10/2014 10:52 AM, Mark Felder wrote:
On Mon, Nov 18, 2013, at 11:40, Asif Iqbal wrote:
On Tue, Nov 12, 2013 at 1:53 PM, Mark Felder <feld at feld.me> wrote:
symlink solution was a hack that probably could have been avoided.
Any suggestion on how to avoid that symlink?
I finally got around to figuring out Nginx + Xymon. You have to make some changes due to the way Nginx handles fastcgi variables when aliases are used.
http://blog.feld.me/posts/2014/11/setting-up-xymon-with-nginx/
Hi Mark. Thanks for that... As a matter of fact, just last week I set off to lower memory use on a VM that runs my Xymon server so I thought ditching Apache and using nginx would be a good idea.
Of course I ran into the same issues regarding the CGI directory names. I opted for the symlink method and was happy with it - didn't know this thread was ongoing. :) Exerything worked fine, including all of the CGIs "acks", "endis", "event logs" etc, except for the "edit critical systems" page. It works fine under Apache, but not under nginx.
Any ideas what I might have missed?
I had to modify ownership on some dirs for some of the CGIs to work (snapshot reports for example: ~xymon/server/www/snap)
nginx logs just show http 200 result on submission of the critical systems form.
Thanks for any input. Would be nice to switch this VM to nxginx once and for all.
Bill
-- Bill Arlofski Reverse Polarity, LLC http://www.revpol.com/ -- Not responsible for anything below this line --
On 11/10/2014 10:52 AM, Mark Felder wrote:
On Mon, Nov 18, 2013, at 11:40, Asif Iqbal wrote:
On Tue, Nov 12, 2013 at 1:53 PM, Mark Felder <feld at feld.me> wrote:
symlink solution was a hack that probably could have been avoided.
Any suggestion on how to avoid that symlink?
I finally got around to figuring out Nginx + Xymon. You have to make some changes due to the way Nginx handles fastcgi variables when aliases are used.
http://blog.feld.me/posts/2014/11/setting-up-xymon-with-nginx/
Hi Mark
I ran across an issue when using http basic_auth for the CGI stuff, the username was not being pasted to the CGI.
So for example, when I disabled a test, clicking on a blue icon would show:
Disabled by: unknown @ 192.168.1.1
Turns out I had to add a line:
fastcgi_param REMOTE_USER $remote_user;
To the configuration. Hope this helps someone else. (Thanks Matt)
I still can not get the Critical Systems editor CGI to work under nginx though.
Bill
-- Bill Arlofski Reverse Polarity, LLC http://www.revpol.com/ -- Not responsible for anything below this line --
On Mon, Nov 10, 2014, at 20:50, Bill Arlofski wrote:
Turns out I had to add a line:
fastcgi_param REMOTE_USER $remote_user;
To the configuration. Hope this helps someone else. (Thanks Matt)
Ahh, that's annoying. Didn't notice REMOTE_USER isn't in the default fastcgi_params that ships with nginx. I'll throw that on my blog post.
I still can not get the Critical Systems editor CGI to work under nginx though.
Which part isn't working? I have never used it personally, but it appears functional to me.
On 11/11/2014 08:58 AM, Mark Felder wrote:
On Mon, Nov 10, 2014, at 20:50, Bill Arlofski wrote:
Turns out I had to add a line:
fastcgi_param REMOTE_USER $remote_user;
To the configuration. Hope this helps someone else. (Thanks Matt)
Ahh, that's annoying. Didn't notice REMOTE_USER isn't in the default fastcgi_params that ships with nginx. I'll throw that on my blog post.
Oh cool. Glad I (and my friend Matt) could help .:)
I still can not get the Critical Systems editor CGI to work under nginx though.
Which part isn't working? I have never used it personally, but it appears functional to me.
Hi Mark,
When I try to add a host/test to the list and click "update record" nothing happens, and the host/test is not added. The page does (quickly) reload though, with the host and test pre-filled in.
Keep in mind, that for this to work quickly while testing, and have something show up in the critical systems page, I choose a test that is currently red or yellow and attempt to add it. :)
Also, you can get a quick indication that it worked or didn't by setting the host/test in the form and clicking search after attempting to add it. A popup will tell you if the host was not found.
Under apache, when I add a host/test and click "update record", I get a popup that says (something like) "record added"
nginx logs show http 200 results on submission of the form, so there is not much I have to go on.
Thanks for any help with this.
Bill
-- Bill Arlofski Reverse Polarity, LLC http://www.revpol.com/ -- Not responsible for anything below this line --
On 11/11/2014 11:53 AM, Bill Arlofski wrote:
On 11/11/2014 08:58 AM, Mark Felder wrote:
On Mon, Nov 10, 2014, at 20:50, Bill Arlofski wrote:
Turns out I had to add a line:
fastcgi_param REMOTE_USER $remote_user;
To the configuration. Hope this helps someone else. (Thanks Matt)
Ahh, that's annoying. Didn't notice REMOTE_USER isn't in the default fastcgi_params that ships with nginx. I'll throw that on my blog post.
Oh cool. Glad I (and my friend Matt) could help .:)
I still can not get the Critical Systems editor CGI to work under nginx though.
Which part isn't working? I have never used it personally, but it appears functional to me.
Hi Mark,
When I try to add a host/test to the list and click "update record" nothing happens, and the host/test is not added. The page does (quickly) reload though, with the host and test pre-filled in.
Keep in mind, that for this to work quickly while testing, and have something show up in the critical systems page, I choose a test that is currently red or yellow and attempt to add it. :)
Also, you can get a quick indication that it worked or didn't by setting the host/test in the form and clicking search after attempting to add it. A popup will tell you if the host was not found.
Under apache, when I add a host/test and click "update record", I get a popup that says (something like) "record added"
nginx logs show http 200 results on submission of the form, so there is not much I have to go on.
Thanks for any help with this.
Bill
<facepalm>
Mark, list, et al
OK, I see what the problem is (was).
When you run the configure script for Xymon, it asks you what user name your web server is running under.
This is so that when you run:
make install
it know what ownerships to set on some of the dirs in the www directory (notes, snap, rep) and on the ~xymon/server/etc/critical.cfg file.
My critical.cfg file was 664 apache:apache from when I answered the "what user does your web server run under" question on a previous install/upgrade.
I just changed my web server from apache to nginx, and of course the username that nginx runs under is not "apache". ;)
I had caught this on the snap and rep dirs in www, but completely missed the critical.cfg file in etc.
So this is 100% working under nginx now, but my only concern is that I got no indication in any logs that the webserver (nginx) could not write to the critical.cfg file, so that is kind of interesting.
Hopefully, sharing my embarrassment will same someone else the trouble. :)
Bill
-- Bill Arlofski Reverse Polarity, LLC http://www.revpol.com/ -- Not responsible for anything below this line --
On Sat, Nov 15, 2014, at 15:23, Bill Arlofski wrote:
<facepalm>
Mark, list, et al
OK, I see what the problem is (was).
When you run the configure script for Xymon, it asks you what user name your web server is running under.
This is so that when you run:
make install
it know what ownerships to set on some of the dirs in the www directory (notes, snap, rep) and on the ~xymon/server/etc/critical.cfg file.
My critical.cfg file was 664 apache:apache from when I answered the "what user does your web server run under" question on a previous install/upgrade.
I just changed my web server from apache to nginx, and of course the username that nginx runs under is not "apache". ;)
I had caught this on the snap and rep dirs in www, but completely missed the critical.cfg file in etc.
So this is 100% working under nginx now, but my only concern is that I got no indication in any logs that the webserver (nginx) could not write to the critical.cfg file, so that is kind of interesting.
Hopefully, sharing my embarrassment will same someone else the trouble. :)
This is good info. I don't do manual installs -- I install it from FreeBSD ports which handles the configuration of Xymon automatically. And FreeBSD shares the user/group "www" between Apache and Nginx, which avoids this problem.
participants (3)
-
feld＠feld.me
-
vadud3＠gmail.com
-
waa-hobbitml＠revpol.com