Last week I’ve introduced you to Observium and shown you how to install it. This week, it’s time to add devices to Observium. In order to add a device to Observium, the device must support SNMP/have SNMP software installed. SNMP stands for Simple Network Management Protocol and is a protocol that was designed for monitoring and management purposes for network-connected devices. It’s quite a simple protocol but very powerful, mainly because so many devices understand it (servers, switches, printers, routers, etc.).

On Ubuntu and CentOS a tool called SNMPd is used to listen to, and answer to, requests over the SNMP protocol.  I’m going to show you how to install the this tool in both Ubuntu and CentOS. After that, I’m going to show you how to add those devices to your Observium installation.

SNMPd on Ubuntu

First, update the apt cache. On new installations a lot of packages may not be found because they haven’t been cached yet.

sudo apt-get update

Now install SNMPd:

sudo apt-get install snmpd

And open up the configuration file:

sudo vim /etc/snmp/snmpd.conf

What you see in this file is default/example configuration. We’re going to ditch all of it and replace it with our custom configuration. This is the configuration we’re going to put in there:

com2sec readonly 192.0.2.5 lowendbox
group MyROGroup v1 readonly
group MyROGroup v2c readonly
group MyROGroup usm readonly
view all included .1 80
access MyROGroup “” any noauth exact all none none
syslocation “Milan, Italy”
syscontact operations@example.net

It looks complicated, but it isn’t. Let’s go over this line by line and I’ll explain what everything does and what you have to change (TL;DR: ‘lowendbox’ is the community name, this is up to you; syslocation is the location of the system; syscontact is the contact e-mail address for this system).

com2sec readonly 192.0.2.5 lowendbox

This line maps a community name (in this case ‘lowendbox’) to a security string. A security string is an access policy and an optional IP address limitation. If you want to allow all IP addresses, you could replace the IP address in my example configuration with the word ‘default’. com2sec6 is the IPv6 ecquivalent to this. You can either give it a single IP address, an IP address and a netmask, or an IP range in CIDR block notation. I’ve chosen to limit access over SNMP to my Observium server.

group MyROGroup v1 readonly
group MyROGroup v2c readonly
group MyROGroup usm readonly

These lines map a group (in this case ‘MyROGroup’) to a security name (in this case ‘v1 readonly’, ‘v2c readonly’, and ‘usm readonly’). We do this for the security model of three versions of SNMP: v1, v2c, and USM. V1 is the oldest of all, while the community-based V2c model is still used very frequently. Both of them use VACM (View-Based Access Control Model). USM (User-Based Security Model) is the newest of all and part of SNMP v3, but more complicated to configure. USM allows for user-based access, which could eventually be more suitable in more complex setups. We’re mapping these all because VACM requires them for both v1 and v2c, and, for future expansion, having the line added for USM can’t hurt.

view all included .1 80

This line is a bit more complicated. This defines a ‘view’, which defines what you are allowed to view when contacting this device over SNMP. This view is named ‘all’. After that, you see ‘included .1 80’. This is sort of an “access policy” to the MIB tree that SNMP makes available (MIB stands for Management Information Base).  Every bit of data in there has an OID (‘Object IDentifier’). Simple said, the MIB tree contains a lot of information about your system. By defining access to a certain OID (which can be a simple piece of data or an entire tree), you can disclose that over SNMP. ‘Included’ is the keyword that tells SNMPd to include the data of the OID string you pass. ‘Excluded’ is the alternative here, with which you can exclude certain data. The OID string we pass here (‘.1’) gives access to the entire ‘iso’ MIB tree of data that SNMP has. To see what’s possibly in there, take a look here: http://oid-info.com/cgi-bin/display?tree=1&see=all. But because not all of that is necessary, we’re limiting access to the .1 tree by setting a mask which is in hexadecimal notation. In this case that mask is 80 (it’s full form is ‘ff.80), which limits the access we give to a certain subtree of the .1 MIB tree. I haven’t been enable to find a proper overview of what you can exactly see, but it’s a long list of data, which includes network, CPU, memory, and drive information. If anybody can find a sane overview of this, please let me know.

access MyROGroup “” any noauth exact all none none

With this line, we actually tie the group we’ve added before to an access rule. In this case the ‘MyROGroup’, in any context (“”), can access the data over any version of the protocol (‘any’), without authentication (‘noauth’), matching the exact context (‘exact’), allowing access to all view rules (‘all’), but no write (‘none’), or modify access (‘none’). The context is what we have limited with com2sec. If you have a loose com2sec policy, you can control access from certain devices with certain IP addresses here. So, you could theoretically allow access from all IP addresses with com2sec and then limit access by IP address here. It wouldn’t have my preference, though.

syslocation “Milan, Italy”
syscontact operations@example.net

The last two lines are actually simple. These note the location of the system (Observium uses this for the map it has) and the system contact. Adjust these to your situation.

Once that’s done, save the file, and your initial configuration is done! Finally, restart SNMPd:

sudo service snmpd restart

And you’re done! You can now add the device to Observium!

SNMPd on CentOS

CentOS has the SNMPd Perl packages in the default repository, so we can install them right away:

sudo yum install net-snmp-utils net-snmp

Now, make sure the daemon starts when CentOS starts:

sudo chkconfig snmpd on

And open up the configuration file:

sudo vi /etc/snmp/snmpd.conf

What you see in this file is default/example configuration. We’re going to ditch all of it and replace it with our custom configuration. This is the configuration we’re going to put in there:

com2sec readonly 192.0.2.5 lowendbox
group MyROGroup v1 readonly
group MyROGroup v2c readonly
group MyROGroup usm readonly
view all included .1 80
access MyROGroup “” any noauth exact all none none
syslocation “Milan, Italy”
syscontact operations@example.net

It looks complicated, but it isn’t. Let’s go over this line by line and I’ll explain what everything does and what you have to change (TL;DR: ‘lowendbox’ is the community name, this is up to you; syslocation is the location of the system; syscontact is the contact e-mail address for this system).

com2sec readonly 192.0.2.5 lowendbox

This line maps a community name (in this case ‘lowendbox’) to a security string. A security string is an access policy and an optional IP address limitation. If you want to allow all IP addresses, you could replace the IP address in my example configuration with the word ‘default’. com2sec6 is the IPv6 ecquivalent to this. You can either give it a single IP address, an IP address and a netmask, or an IP range in CIDR block notation. I’ve chosen to limit access over SNMP to my Observium server.

group MyROGroup v1 readonly
group MyROGroup v2c readonly
group MyROGroup usm readonly

These lines map a group (in this case ‘MyROGroup’) to a security name (in this case ‘v1 readonly’, ‘v2c readonly’, and ‘usm readonly’). We do this for the security model of three versions of SNMP: v1, v2c, and USM. V1 is the oldest of all, while the community-based V2c model is still used very frequently. Both of them use VACM (View-Based Access Control Model). USM (User-Based Security Model) is the newest of all and part of SNMP v3, but more complicated to configure. USM allows for user-based access, which could eventually be more suitable in more complex setups. We’re mapping these all because VACM requires them for both v1 and v2c, and, for future expansion, having the line added for USM can’t hurt.

view all included .1 80

This line is a bit more complicated. This defines a ‘view’, which defines what you are allowed to view when contacting this device over SNMP. This view is named ‘all’. After that, you see ‘included .1 80’. This is sort of an “access policy” to the MIB tree that SNMP makes available (MIB stands for Management Information Base).  Every bit of data in there has an OID (‘Object IDentifier’). Simple said, the MIB tree contains a lot of information about your system. By defining access to a certain OID (which can be a simple piece of data or an entire tree), you can disclose that over SNMP. ‘Included’ is the keyword that tells SNMPd to include the data of the OID string you pass. ‘Excluded’ is the alternative here, with which you can exclude certain data. The OID string we pass here (‘.1’) gives access to the entire ‘iso’ MIB tree of data that SNMP has. To see what’s possibly in there, take a look here: http://oid-info.com/cgi-bin/display?tree=1&see=all. But because not all of that is necessary, we’re limiting access to the .1 tree by setting a mask which is in hexadecimal notation. In this case that mask is 80 (it’s full form is ‘ff.80), which limits the access we give to a certain subtree of the .1 MIB tree. I haven’t been enable to find a proper overview of what you can exactly see, but it’s a long list of data, which includes network, CPU, memory, and drive information. If anybody can find a sane overview of this, please let me know.

access MyROGroup “” any noauth exact all none none

With this line, we actually tie the group we’ve added before to an access rule. In this case the ‘MyROGroup’, in any context (“”), can access the data over any version of the protocol (‘any’), without authentication (‘noauth’), matching the exact context (‘exact’), allowing access to all view rules (‘all’), but no write (‘none’), or modify access (‘none’). The context is what we have limited with com2sec. If you have a loose com2sec policy, you can control access from certain devices with certain IP addresses here. So, you could theoretically allow access from all IP addresses with com2sec and then limit access by IP address here. It wouldn’t have my preference, though.

syslocation “Milan, Italy”
syscontact operations@example.net

The last two lines are actually simple. These note the location of the system (Observium uses this for the map it has) and the system contact. Adjust these to your situation.

Once that’s done, save the file, and your initial configuration is done! Finally, restart SNMPd:

sudo service snmpd restart

And you’re done! You can now add the device to Observium!

Adding the device to observium

Final step is to add the device you have just installed SNMPd on to Observium. To do this, log into Observium. In the top menu, select ‘Devices’ and then ‘Add device’. This will take you to the following page:

In the ‘Hostname’ field, fill in the host name of the server you want to add. Then, at ‘SNMPv1/v2c Configuration’, the field ‘SNMP Community’, input the community name you have used before. In my example it was ‘lowendbox’. When done, click the green ‘Add Device’ button. The device should now be added to your Observium installation. If you get an error message, be sure to check:

• the connectivity between the Observium server and the device you would like to add
• whether you have restarted SNMPd after changing the configuration
• your firewall

Those are the most common causes for Observium to tell you the device cannot be added.

After about 15 minutes, the first poll should have been done. From that point on, you should start seeing data.

Congratulations, you’re done! You’ve now got a fully working Observium installation with your first device added!

The extra step

If you want proper information about you’re device’s distribution (and the version/architecture) in Observium, there’s a couple of extra steps to take. First, get the tool from Observium that gathers the proper data:

wget http://www.observium.org/svn/observer/trunk/scripts/distro

Now, move it to the /usr/bin directory:

sudo mv distro /usr/bin/distro

And make it executable:

sudo chmod +x /usr/bin/distro

Finally, add the following line to your /etc/snmp/snmpd.conf:

extend .1.3.6.1.4.1.2021.7890.1 distro /usr/bin/distro

This line extends the above ‘view’ policy and allows access to the distro information over SNMP. As you can see, the OID string here is a lot more complex than the one above, and is really limited to a small subset of information.

Save the file and restart SNMPd:

sudo service snmpd restart

And within 15 minutes or so, Observium should pick up on the additional data!

Final notes

While installing Observium isn’t complicated, configuring the SNMP daemon could be. As you will have undoubtedly noticed, the MIB tree and OID string are something that requires more in-depth knowledge to figure out yourself. It’s a good thing to read a bit more about this.

To actually see what data does get passed to Observium, you can use the following command from the Observium server (this does require to have the SNMPd packages installed):

snmpwalk -mALL -v2c -clowendbox 192.0.2.51 .1 80

Replace ‘-clowendbox’ with ‘-c’ followed by your community name and 192.0.2.51 with the IP address of the device you want to check.This should spit out a long, long list of data. This is the list Observium gets as well. If you want to check it out in peace, save it in a file and enjoy :-)

Up next time: MySQL – Master-Slave replication

• Author
• Recent Posts

mpkossen

Maarten Kossen was the administrator of LowEndBox from 2013 to 2015, and brought many ideas and improvements to the website during his leadership. Today he is member of our community and LowEndTalk.

Latest posts by mpkossen (see all)

• How to Rapidly Install Java, OpenJDK & Oracle JDK on your VPS - December 14, 2015
• It’s been a great ride - December 14, 2015
• Cheap Windows VPS – $21/quarter 1GB KVM-based Windows VPS in 11 worldwide locations - November 30, 2015