Wednesday, November 25, 2015

Installing Bareos Client

This guide covers the installation of the Bareos Client in it's most common form, for file backup or also known as a FileDaemon (bareos-fd). It goes through the process of installing the client and testing whether it works. I will post an installation guide for Bareos Client for database backup and as a storage node (StorageDaemon) some time in the future.
First, there are several assumptions taken.
  • No Bareos client or anoy other component installed previously. Install client to backup files only. 
  • Focus is on installation via packages so that updates packages are applied as they come out. Particularly useful if your organization validates updates prior to roll-out.
  • Server-side configuration is using Webmin via the Bacula module (in Webmin: System --> Backup)  This is no longer possible with newer versions of Bareos. Refer to to this updated post on Bareos client configuration for newer instructions.
First the following information is needed
  • The hostname or IP address of the client or machine to be backed up. We'll call this the Client.
  • The name that will be given to the Client in the Bareos system. Usually Client-fd
  • The name of Director in the Bareos system.
  1. Add Bareos repository on the client / target server.
    1. Refer to quickstart information in official documentation for your Distro specific instruction
    2. For RedHat, it's basically
      1. add the Bareos yum repository. The repositories are here. Make sure the client version matches the Bareos server version. Choose the version of RedHat or CentOS for the target server. Download the bareos.repo file to /etc/yum.repos.d
      2. If you haven't added the Epel repository, add the repository. Instructions are here.
      3. do a yum check-update to update the repositories to load them
  2. Install Bareos filedaemon. For Redhat: yum install bareos-filedaemon
  3. Configure the client by editing the /etc/bareos/bareos-fd.conf file
    1. Set Bareos server / Director name in Director section, entry "Name = "
    2. Make note of  
      1. FileDaemon name - set the entry "Name =" in FileDaemon section
      2. Director password - create a password and set the entry "Password =" in the Director section. Make this long and complicated because this will not be used by users.
    3. Start the FileDaemon / Bareos Client:  service bareos-fd start
    4. Open the Bareos Client port (tcp port 9102) on the firewall, if necessary 
  4. Configure Bareos server via Webmin
    1. Create client
      1. System => Bacula backup, Backup Clients, Add new backup client
      2. Enter 
        1. Client name =  FileDaemon name (from step 3.2)
        2. Bacula FD Password = Director Password (replace the automactically generated one)
        3. Save
      3. Confirm setup client ok
        1. Backup Clients, select client, Show Status
        2. Correct response : Status from <client hostname> : <Client name>-fd Version: <bareos version>
    2. Setup job to backup files on the client 
      1. Backup Jobs, Add a new backup job
      2. Enter job name: eg hostname-files
      3. Set "Inherit defaults" to "DefaultJob"
      4. Set Client to backup = Client name
      5. Set File Set to backup = SelfTest
      6. Set Destination Storage = <storage> e.g. "File"
  5. Test backup
    1. Backup Jobs, select Job name
    2. click Run Now
    3. Messages will appear. Test successful when the last message is "Termination: Backup OK"
  6. Create a backup job for the client with the correct fileset.
More information: Official Documentation

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 192.168.1.1 is : bind = 192.168.1.1
      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. http://monitor.myco.com/mysite/nagvis
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.