Nagios Tutorial for Programmers – 1

If you’re reading this post, then you probably know what Nagios is. It is a good, open-source monitoring solution for most of the needs. Most of the Nagios concept is very straight-forward for system admins. But if you’re rather a programmer then a system administrator some of Nagios concepts may confuse you. You have already looked for what “Passive Check” stands for already! If you’re like me this tutorial is for you.

Please note that this post is rather a learning process than a complete tutorial. But I thought if a concept is hard for me to understand it may be hard for others too.

Nagios in Short

It is a monitoring tool. It can monitor your assets like: servers/clients, services (means server processes on servers). If you want to know what is the current status of your hosts&services, or you want to get notifications as soon as any critical event (such as service interruption) took place on your assets. Nagios CAN monitor hosts&servers behind NAT ( i.e. router/firewall).

There are two versions of Nagios. Even though I’m not quite sure, you have to pay for one version, but there is a free version also. I will cover free version here. I’ve tested paid version, and it is much simpler and better look-and-feel. But if you’re tight on budget, or like to learn scenes behind it, this tutorial is perfect for you.

Nagios Checks

Nagios reports its hosts and services to us. To report their current health or other important metrics, Nagios should “somehow” get their status. Nagios can gather this information using 2 completely different methods.

Active Checks

First method, active checks, is what everybody is familiar with. In active checks Nagios server actively makes connections to hosts&services and runs some scripts/binary files using its Nagios client on the related hosts. It is important to understand that Nagios server is initiating the connection at the active checks. That means you can NOT reach hosts&services behind firewall or NAT if they are not configured to allow Nagios active checks. Checks are executed on the clients (as expected) and results are reported to Nagios server.

Passive Checks

Second method, passive checks, is an enabler actually. This method enables us to monitor hosts&services behind firewalls and routers. In passive checks, connection is initiated from client to Nagios server. This means Nagios server is accepting connections. This is totally different from active checks where Nagios server was initiating the connections.

This is it for first part. Next part covers Nagios Server setup on CentOS 7.

Debian Bring Manually Configured Interface Up at Boot/Reboot

Edit /etc/network/interfaces and make following changes:

1.Add interface to auto line (your interface name may change and number of interfaces may also change). This change makes interface to be brought up at boot time:

auto lo eth0 eth1 eth2

2.Add following lines for each interface. This change will make interface to be manually configured:

iface eth1 inet manual
   pre-up /sbin/ifconfig $IFACE up
   post-down /sbin/ifconfig $IFACE down

reboot and see your changes.

KVM Persistent Interface Names

If you’re using KVM for virtualization you may notice that your ethernet device that is attached to the bridge may have different names each time KVM restarts, and KVM manages attaching/detaching this interface to the bridge by itself.

If you’re using standard linux bridge you can check attached ports:

brctl show

This gives you current bridges (KVM and user defined) and ports on them as shown below:

But you may have some special rules/routes/mirrors based on this interface name. If this interface name ever changes you might execute some commands that disable/cancel previous commands, and update the commands to reflect new interface name. If you’re managing many interfaces, this task may be very time consuming.

Fortunately there is a way to prevent this. You can define the interface name generated by KVM for each guest interface. To enable this feature we’ll be adding some definitions to XML presentation of virtual machine (domain in other words). To add this definition we use “virsh” as expected.

virsh edit <domain-name>

This opens a text editor (vi/vim/nano depending on your OS and configuration) to modify contents. File is in XML format. So make sure that changes result a valid XML file.

Find Interface node in the file. Add below line within the interface node defining a desired interface name:

<target dev="<interface_name>" />

Also note that longer interface names may cause errors and choose a name that is not started with “vnet”. It is obvious not to start with “vnet” because KVM uses “vnet” by default.

Restart KVM service to changes to be effective:

systemctl restart libvirtd.service

Check your bridges again and confirm that KVM guests use your new naming.

Autostart KVM Guest on System Boot

If you want your virtual machine to start when host starts, there are two ways to do this. First one uses command line and pretty straightforward. Second one uses virt-manager (a GUI to manage kvm guests)

Command line:

virsh autostart <domain>

Replace domain with your virtual machine name (case sensitive). For instance, if you have a VM named “websrv”

virsh autstart websrv

will mark websrv to autostart on host reboot/boot.

Virt-manager GUI

Open virt-manager and select your virtual machine from list.

Then display properties of virtual machine (i button next to computer monitor icon).

Select “boot” item from properties in the list (image 1):

Image 1: Virtual machine properties

From boot settings enable check box that says: “Start virtual machine on host boot up”

That’s it!

Openvswitch RPM build on Centos 7

If you ever needed to build openvswitch for Centos 7 (including kernel module) this post may help you.

Commands to build a RPM:

Download openvswitch source. I’ve tested with 2.7.x series. So I recommend you to do same. It can be found at (at the moment, if link becomes absolute look for a newer one, if newer one fails, look for this one)

http://openvswitch.org/releases/openvswitch-2.7.0.tar.gz

wget can be used to download it:

wget http://openvswitch.org/releases/openvswitch-2.7.0.tar.gz

we’ll be using some build tools, so install them to the system with the following command.

yum install gcc make python-devel openssl-devel kernel-devel graphviz ernel-debug-devel autoconf automake rpm-build redhat-rpm-config libtool python-six checkpolicy selinux-policy-devel

Then prepare the directories for rpmbuild.

mkdir -p rpmbuild/SOURCES/
mkdir -p rpmbuild/SPECS/

copy source to rpmbuild/SOURCES

cp openvswitch-2.7.0.tar.gz rpmbuild/SOURCES/

Now we have two copies of openvswitch source, one in SOURCES directory the other in the directory where we executed wget. Now navigate to the latter, and extract it.

tar xzf openvswitch-2.7.0.tar.gz

We’ll copy all spec files related to rhel to rpmbuild/SPECS/ from the directory that we extracted.

cp openvswitch-2.7.0/rhel/*.spec rpmbuild/SPECS/

We also need some files to be in SOURCES, so copy them as well,

cp openvswitch-2.7.0/rhel/* rpmbuild/SOURCES/

Now, it’s time to check our kernel version:

uname -a
3.10.0-514.el7.x86_64

yours may be different, so note your kernel version.

And finally time to build our kernel module for openvswitch:

rpmbuild -bb --without check -D "kversion 3.10.0-514.el7.x86_64" rpmbuild/SPECS/openvswitch-kmod-fedora.spec

If you updated your operating system, and had a kernel update, some of your links may be broken. To be more precise, link to build directory may be broken. You can check it with:

ls -la /lib/modules/3.10.0-514.el7.x86_64/build

This path should point to a directory, and if it is broken then we have to fix it.

Fixing broken build link (note that if you have this link with contents, do not run commands to fix this issue (4 command listed just below)):

rm /lib/modules/3.10.0-514.el7.x86_64/build
cd /lib/modules/3.10.0-514.el7.x86_64/
ln -s /usr/src/kernels/3.10.0-514.el7.x86_64/ build
ls build/

if contents of build is listed, we’re good to go.

After you fix broken link, go ahead and run same rpmbuild command again to build kernel module:

rpmbuild -bb --without check -D "kversion 3.10.0-514.el7.x86_64" rpmbuild/SPECS/openvswitch-kmod-fedora.spec

if it’s completed succesfully then run rpmbuild again to build user space programs (ovs-*)

rpmbuild -bb --without check -D "kversion 3.10.0-514.el7.x86_64" rpmbuild/SPECS/openvswitch.spec

If both of these commands successfully complete, you can install your openvswitch using generated rpms. Rpms can installed with:

rpm -ivh rpmbuild/RPMS/x86_64/openvswitch-kmod-2.7.0-1.el7.centos.x86_64.rpm 
rpm -ivh rpmbuild/RPMS/x86_64/openvswitch-2.7.0-1.x86_64.rpm

Either reboot, or modprobe to load kernel module and make some tests to check openvswitch.

Get OVS Version
#ovs-vsctl -V
List bridge configuration
#ovs-vsctl show
Create a new bridge
#ovs-vsctl add-br ovs-br0
Add port to the bridge
#ovs-vsctl add-port ovs-br0 eth1
#ovs-vsctl show

 

 

Linux Bridge as Hub

You can configure your linux bridge (brctl operates them) as a hub (if you want to) with setting the aging property of the bridge to 0.

This make your bridge to behave as a hub. Most of you may not remember a network hub’s functionality that is different from switches. Hubs are dummy devices, in other words they forward every packet to every other ports. It has no look-up table to decide packets destination port. Whereas switches are smart devices. They know which device (based on mac address) is connected to its port and with the help of this information it forward packets only to the destination port. There is an exception at that procedure. If a switch lookup table is full of MAC addresses then it starts to behave as a HUB. Lots of security issues raises from this HUB-Like behavior.