Documentation ============= The upstream source does not include the documentation any more. Instead they want you to read it online, at: http://go.nagios.com/nagioscore/docs/ If you have questions about using/configuring nagios you should contact the nagios-users mailing list: nagios-users@lists.sourceforge.net Authentication ============== The default install ***TURNS OFF AUTHENTICATION*** The default apache2 configuration only allows access from private IP Addresses. This should be fine for the toy example setup by default install, but is unlikely to suffice for real usage. Look at /etc/nagios4/cgi.cfg and /etc/nagios4/apache2.conf. CSRF cookie in cmd.cgi ====================== The 4.4.6-4+deb12u1 security update (Debian bug #1136340) backports the upstream CSRF fix from Nagios Core 4.5.12. cmd.cgi now requires every command-submission request to carry a NagFormId cookie that was previously issued by cmd.cgi itself; cookies generated client-side in JavaScript (the pre-4.5.12 behaviour) are no longer trusted. This change can break legitimate third-party integrations that POST to /cgi-bin/nagios4/cmd.cgi without first visiting the Nagios web UI in the same browser session. Typical examples are custom dashboards, automation/orchestration scripts that submit external commands via curl, mobile status panels, and add-ons such as NagiosBP. The symptom is: instead of the command being passed to the Nagios pipe at /var/lib/nagios4/rw/nagios.cmd, cmd.cgi returns an HTTP 200 response whose body contains literally: Error: Invalid or missing CSRF cookie! Apache access logs show 200s (the error is HTML, not an HTTP status), and /var/log/nagios4/nagios.log shows no incoming command. If you cannot easily rewrite the integration to authenticate through the UI first, you can opt back into the pre-fix behaviour by setting the following in /etc/nagios4/cgi.cfg: cgi_cookie_fail_open=1 WARNING: this reopens the CSRF vulnerability that the fix was intended to close. Use only as a transitional measure, and restrict access to cmd.cgi at the apache2 layer in the meantime. Default Install =============== After the default install of nagios-cgi, if apache2 is running you should be able to see it at: http://127.0.0.1/nagios4 Nagios will not run unless it has a service and a host to monitor, so the default Debian install is configured to verify localhost is up by pinging 127.0.0.1. Obviously this is not very useful, but it does allow a newbie to see what Nagios looks like. A typical Nagios configuration tends towards huge, where "huge" means it's so big syadmins usually resort to writing a tool that generates it. The default install is set up to read additional configuration files from /etc/nagios4/conf.d. This is the preferred place for packages to place their nagios files. Monitoring plugins ================== Debian has separate family of packages for Nagios plugins called monitoring-plugins. Nagios4 only depends on monitoring-plugins-basic but all should work. URL's ===== Nagios4 insists you hardwire URI's into it at compile time. Debian sets these hardwired URI's to: htmlurl=/nagios4 This is where it fetches images, css, and ancillary files from. cgiurl=/cgi-bin/nagios4 Nagios4's cgi programs live here. It would be nice if Nagios4 always respected these settings, but it doesn't. For example at times you will see it fetch .cgi from /nagios4/cgi-bin. In other words, internally Nagios4 uses a combination of relative and absolute URI's. The shipped /etc/nagios4/apache2.conf covers all possibilities. However, you don't have to put the web interface at http://site.com/nagios4. Putting at another URI (eg http://site.com/foobar) will work and it will stick in browsers URL bar, but it will still fetch some stuff from the hardwired URI's under the hood, and of course it will also use combinations of relative URL's combined with the hardwired ones and your new one, which creates a lot of possible paths. There is no easy solution to making this work beyond suck it and see - I'm just letting you know it is possible.