Check_MK on pfSense 2.4 w/ Update-persistence

[calebh]

Re: PfSense 2.3 Check_mk working with xinetd

Here's instructions on how to get Check_MK running on pfSense 2.3+ (the latest verified setup being 2.4.3_1).

Since the original thread is getting old, the Netgate forum recommended a new thread, which would probably be helpful anyway so people don't have to search through all the replies to find the useful stuff. Most of the credit for this configuration goes to @joeclifford and @FJerusalem, with a small update I've added.

For issues getting set up, I would recommend checking out the original thread to see if your issue has already been discussed there.

1. Get to the firewall's shell (console, SSH, serial, etc.)

2. Install bash:
   pkg install bash

3. Create directories:
   mkdir -p /opt/bin
mkdir -p /opt/etc/xinetd.d

4. Download the latest version of the check_mk_agent for FreeBSD:
   curl "http://git.mathias-kettner.de/git/?p=check_mk.git;a=blob_plain;f=agents/check_mk_agent.freebsd;hb=HEAD" -o /opt/bin/check_mk_agent

5. Make it executable:
   chmod +x /opt/bin/check_mk_agent

6. Verify the agent can run:
   /opt/bin/check_mk_agent

7. Create the service config file using the template below:
   vi /opt/etc/xinetd.d/check_mk

# +------------------------------------------------------------------+
# |             ____ _               _        __  __ _  __           |
# |            / ___| |__   ___  ___| | __   |  \/  | |/ /           |
# |           | |   | '_ \ / _ \/ __| |/ /   | |\/| | ' /            |
# |           | |___| | | |  __/ (__|   <    | |  | | . \            |
# |            \____|_| |_|\___|\___|_|\_\___|_|  |_|_|\_\           |
# |                                                                  |
# | Copyright Mathias Kettner 2014             mk@mathias-kettner.de |
# +------------------------------------------------------------------+
#
# This file is part of Check_MK.
# The official homepage is at http://mathias-kettner.de/check_mk.
#
# check_mk is free software;  you can redistribute it and/or modify it
# under the  terms of the  GNU General Public License  as published by
# the Free Software Foundation in version 2.  check_mk is  distributed
# in the hope that it will be useful, but WITHOUT ANY WARRANTY;  with-
# out even the implied warranty of  MERCHANTABILITY  or  FITNESS FOR A
# PARTICULAR PURPOSE. See the  GNU General Public License for more de-
# ails.  You should have  received  a copy of the  GNU  General Public
# License along with GNU Make; see the file  COPYING.  If  not,  write
# to the Free Software Foundation, Inc., 51 Franklin St,  Fifth Floor,
# Boston, MA 02110-1301 USA.

service check_mk
{
	type           = UNLISTED
	port           = 6556
	socket_type    = stream
	protocol       = tcp
	wait           = no
	user           = root
	server         = /opt/bin/check_mk_agent

	# If you use fully redundant monitoring and poll the client
	# from more then one monitoring servers in parallel you might
	# want to use the agent cache wrapper:

	#server         = /usr/bin/check_mk_caching_agent

	# configure the IP address(es) of your Nagios server here:
	#only_from      = 127.0.0.1 10.0.20.1 10.0.20.2

	# Don't be too verbose. Don't log every check. This might be
	# commented out for debugging. If this option is commented out
	# the default options will be used for this service.
	log_on_success =

	disable        = no
}

8. Create the script to ensure the check_mk service will be persistent across system updates:
   vi /opt/filter_check_mk_cron

#!/bin/sh

grep includedir /etc/inc/filter.inc
if [ $? -eq 0 ]
then
        exit 0
else
        awk '/fclose\(\$xinetd_fd\)\;/{print "fwrite($xinetd_fd, \"includedir /opt/etc/xinetd.d\");"}1' /etc/inc/filter.inc > /etc/inc/filter.inc.temp
        mv /etc/inc/filter.inc.temp /etc/inc/filter.inc
        /etc/rc.filter_configure
fi
exit 0

9. Make it executable:
   chmod +x /opt/filter_check_mk_cron

10. Run the script manually (to apply the change and reconfigure filters and services):
    /opt/filter_check_mk_cron

11. Log in to the pfSense webConfigurator, go to Status > System Logs
    You should have a log entry about one new service:

Jun 15 08:39:03	xinetd	36043	Reconfigured: new=1 old=3 dropped=0 (services)

Or an entry about the check_mk service being reconfigured:

Jun 15 09:26:05	xinetd	36043	readjusting service check_mk

12. Go to System > Package Manager, and install the "Cron" package if necessary

13. Go to Services > Cron > Add, and add a cron job to make the script run every 15 minutes:
    */15
    *
    *
    *
    *
    root
    /opt/filter_check_mk_cron

14. Add any firewall rules that may be needed for your network environment.

There you have it! You should now be able to point your monitoring server to the LAN address of your firewall to get the status from Check_MK. You can always configure extra network rules and/or port forwarding if you need access on another interface.

Again, thanks to @joeclifford and @FJerusalem for their work on this idea!

[matthewfearnley]

Hi calebh, thanks for writing all this up.

Just to say, I've been looking into alternative ways of doing this, which don't need xinetd or the filter cronjob.

One way is to add an SSH key to the User's Authorized Keys, e.g.

`restrict,command="/opt/bin/check_mk_agent" ssh-rsa AAAAB...`

And then set up an Agents > Other integrations > Individual program call instead of agent access rule, like: ssh admin@$HOSTADDRESS$ -i mysshkey

(Some more parameters might be needed to disable TTY or something, I can't remember.)

I've decided against this approach though, because the SSH connections end up spamming the System Logs.

I think a better way is to create a simple .php file that calls the agent:

/usr/local/www/check_mk_agent.php

<?php
 header('Content-Type: text/plain; charset=utf-8');

 system('/opt/bin/check_mk_agent');
?>

Then the Individual Program Call should look something like:

curl -ks https://$HOSTADDRESS$/check_mk_agent.php

It would be possible to modify the PHP to add some more security, perhaps some IP address filtering or to check for a secret parameter. But even without those steps, it at least has the advantage of encrypting the traffic over SSL so it can't be read by third parties.

Note, this will end up spamming the nginx log (System > GUI Service). Arguably that's better than spamming the System Log, but may still not be appreciated.