Using mod_proxy for HTTP references to remote sites

The Theory

In a distributed Multisite environment Multsite fetches its data from the remote sites via Livestatus over TCP. This is easy, fast and works pleasingly trouble-free.

Some data - however - cannot be fetched via Livestatus: Data provided by third party addons like PNP4Nagios. They solution to this is using HTTP. But we do not let Multisite fetch the data from the remote addon but directly the user's browser. When displaying remote objects, Multsite simply lets links to PNP point to the according remote installation of PNP instead of the local one.

The URL base for that links is configured in the sites variable via url_prefix:

sites = {
  "munich" : {
      "alias" : "Munich"
  },
  "paris": {
     "alias":          "Paris",
     "socket":         "tcp:10.0.0.2:6557",
     "url_prefix":     "http://10.0.0.2/",
   },
}

The Problems

While this is simple and works not entirely bad, it has several drawbacks:

• Since the browser fetches data from another host the user will have to login on the other host. For each remote site he is connecting the first time, an authentification dialog will popup and require to login - even if the username and password is the same as on the local host.
• The remote host might not be reachable via network for the user - only for the local monitoring server (it might be placed in a DMZ).
• Some users might be logged in with https://, some with http://. But in the URL prefix you have to decide in favour of one of those.

The Solution

The perfect solution to all of these problems is using moving the task of fetching data via HTTP from the remote site from the browser to Apache. This can be done with a few simple rules and using mod_proxy. The Apache module works like a reverse proxy and internally redirects HTTP requests to other servers. This is completely transparent to the browser and solves all of the upper problems quite well.

An important precondition

An important precondition is that all of your monitoring sites use globally unique URLs. Consider the following example:

Alias	ID	IP Address	Livestatus-Port	URL of Check_MK
Munich	munich	10.0.0.1	UNIX-socket	http://10.0.0.1/munich/check_mk/
Paris	paris	10.0.0.2	6557	http://10.0.0.2/paris/check_mk/

As you can see in that table, the URL of Check_MK (and other addons as well!) are not located at / but below /munich and /paris.

This is very important. The crucial point here is that if the HTTP output of the remote server is embedded in the HTML frame of the local web GUI the embedded links still must have the information to which site they point!

If you are using OMD then everything is fine for you: OMD exactly uses that scheme of URLs. On a self-installed and self-configured system you have to make sure that all addons are configured to use such URls yourself.

How to configure Multisite

Now let's see how Multisite needs to be configured:

sites = {
  "munich" : {
      "alias" : "Munich"
  },
  "paris": {
     "alias":          "Paris",
     "socket":         "tcp:10.0.0.2:6557",
     "url_prefix":     "/paris/",
   },
}

How Apache needs to be configured

Look at the following configuration file:

<Location /paris>
    RewriteEngine On
    RewriteRule ^/.+/paris/(.*) http://10.0.0.2/paris/$1 [P]
</Location>

It tells apache, that all URLs beginning with /paris should be fetched via reverse proxy ([P]) from http://10.0.0.2/paris. That's all! Just also make sure that:

• You put that file into /etc/apache2/conf.d or /etc/httpd/conf.d (RedHat). This holds also for OMD. This cannot be done within a site!
• Enable the Apache modules proxy and proxy_http. On most systems this is done as root with a2enmod proxy ; a2enmod proxy_http. On OMD systems those modules are already activated, so nothing needs to be done here.
• Reload Apache afterwards

The AuthName

If we have made no mistake so far (you in doing, I in the docu), then you should be able to access your remote addons now. You can test this by clicking on a PNP performance graph for a service being part of the remote host.

You probably will still get a popup for logging in, though. Why? Well, this time it's easier. You just need to make sure, that all of your local and remote sites use the same AuthName in their Apache configuration.

OMD users edit this in ~/etc/apache/conf.d/auth.conf in all sites:

<Location "/paris">
  Order allow,deny
  Allow from all

  AuthName "OMD Monitoring"
  AuthType Basic
  AuthUserFile /omd/sites/bi/etc/htpasswd
  require valid-user
</Location>

If you compare this with your default version of that file you will notice that I have removed the "Site paris" or "Site muc".

If you are not using OMD, that file will be found in /etc/apache2/conf.d/zzz_check_mk.conf (again replace apache2 with httpd on RedHat).

Error: Options FollowSymLinks

In some cases you might run into a strange error. When calling a page via mod_proxy you get a 403 and in the error log of Apache:

[Fri Apr 08 14:01:54 2011] [error] [client 10.18.1.52] Options FollowSymLinks or SymL
inksIfOwnerMatch is off which implies that RewriteRule directive is forbidden: /srv/w
ww/htdocs/dmz, referer: http://hxv-nagios-s10/moni/check_mk/view.py?host=EDIRCLUSTER-
WEBMAIL&site=dmz&view_name=hostpnp

What helps here is added FollowSymlink for the specific site URL:

<Location /paris>
    Options +FollowSymLinks
    RewriteEngine On
    RewriteRule ^/.+/dmz/(.*) http://10.18.1.5/dmz/$1 [P]
</Location>