Thursday, October 22, 2015

Installing Check_MK client on a Linux server

Installing a Check_Mk client is not hard but can be quite lengthy. This means there are a lot of things to do and a lot of chances to make a mistake. Hopefully the steps below will help you set up a client without too much fuss. I've broken it into 4 major steps.
First, some pre-requisites: Xinetd has to be installed on the server to be monitored. Second, the Check_mk or OMD server has to be installed or at the very least, you know what the IP address of the server will be and have access to the Check_mk client files.
The 4 Steps are :
  1. Install the Check_MK client program / agent to the server to be monitored
    1. Find where check_mk client package is stored on the monitoring server. Usually at /opt/omd/versions/1.30/share/check_mk/agents. If you stored the client files on a different server, use that instead. There is also a URL available at the Wato configuration interface under Monitoring Agents.
    2. Find the client that matches the OS of the server to be monitored / target server. If for a Linux server, find the matching package. Eg. for CentOS the agent is check-mk-agent-1.2.6p12-1.noarch.rpm. There is a MSI Windows installer file for Windows server.
    3. Copy the file to server to be monitored. For example, for a CentOS server: scp /opt/omd/versions/1.20/share/check_mk/agents/check-mk-agent-1.2.6p12-1.noarch.rpm user@targetserver:/tmp
    4.  Install the agent:  yum install check-mk-agent-1.2.6p12-1.noarch.rpm
    5. Check whether the client is working by running the file you just copied from the prompt (check_mk_agent). 
    6. For extra points, copy the waitmax program in the same directory to the same location.This program is sometimes used by the check_mk_agent program. If you installed from a package, this is automatically done.
  2. Configure xinetd to respond to polls from monitoring server 
    1. Copy the xinet.conf file from the monitoring server to the target server's /etc/xinetd.d directory, renaming the file into check_mk in the process. This can be achieved with a command like this:   scp /opt/omd/versions/1.20/share/check_mk/agents/xinetd.conf user@targetserver:/etc/xinetd.d/check_mk
    2. Configure the xinetd check_mk file.
      1. Uncomment the #only_from  line and add the IP address of the monitoring server.
      2.  Extra points: Add a line to configure the agent to only listen to only one interface. This is useful is the server has multiple interfaces. The line to listen only on is : bind =
      3. Restart the xinetd on the target server using the comment service xinetd restart.
  3. Create Firewall rules to allow the monitoring server access to Check_MK client (port 6556). This depends on the firewall being used. Below is an example how to do it on a CentOS/RedHat server running iptables.
    1.  Edit the file /etc/sysconfig/iptables
    2. Find other lines that look similar to the following line and add this : -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 6556 -j ACCEPT
    3.  Make sure that the line you added is between the lines marked *filter and COMMIT.
    4. Apply the new setting by running the command: service iptables restart.
  4. Add entry on the monitoring server. Use WATO to add the new host.
If your security processes don't allow direct copying to the any of the directories mentioned above, copy the files to a directory where you have the rights to, first. Then logon onto the target server, escalate your privileges with the sudo command and copy the files to the correct location.

Solved! New Check_mk user unable to access Network Topology

After creating a new user on OMD, that user should get access to the features that his rights/role allows him to. This applies across all of the OMD apps, Nagios, Check_mk, DokuWiki and NagVis. 
However, users created by Wato, the tool to configure Nagios, can't get access to the Network Topology item on the side menu. A message saying that the user is not allowed comes up, even though the user's role is an administrator. Stangely enough, even if you clone the user 'omd' to create a new user, the new user still won't be able to use the Network Topology.
It seems this is due to a bug in NagVis or WATO. It could also be a mismatch in role mapping that OMD uses to create users across of it's apps. But there is a workaround.
Basically the user in Nagvis needs to be given admin privileges or  Read-only privileges. Say you are dealing with the account 'mike'.
1. Open the NagVis OMD URL, http://<omd>/<site name>/nagvis e.g.
2. If you are not already logged on, it will prompt for a username amd password. Enter the OMD/Check_admin administratror, which is usually 'omd'.
3. Choose User Menu on the top right and choose Manage User.
4. In the Modify User section select the user 'mike'
5. Move the role 'Users (Read-only)' from the left column (Available Roles) to the right column (Selected Roles).
6. Move the role 'Guest' from the right column to the left.
7. Click Modify User button to apply the changes.

Try logging in Check_mk with the account 'mike'. You have to do the same for all new users. Until the bug is fixed, at least.