Monitoring Red Hat IdM's LDAP server with SNMP

Oh SNMP, how crazy art thou!

Overall this one isn't well documented, or at least not in one place, there are bits and pieces all over.  Because IdM (or IPA) is built on top of 389 Directory Server this means that the SNMP monitoring capability is there by default and once you've hit your head on the bumps it's overall pretty straight forward.

Install the packags

You'll only need to install the "net-snmp" package at a minimum, let yum handle any dependencies if needed, however if you want to be able to read the snmp variables you'll also need the "net-snmp-utils" package.

Configure net-snmp

I'm going to assume you're starting with a fresh install of net-snmp from RPM, if you have a pre-existing installation adapt the following as needed.  At the bottom of the /etc/snmp/snmpd.conf file I added the following:

rocommunity public
view systemview included .1.3.6.1.4.1.2312
master agentx

The first sets up the read only community, then we allow access to the Red Hat OIDs and finally enable the agentx protocol for the ldap agent.





Originally I didn't have the Red Hat OID enabled and grew a little frustrated at snmpwalk saying it had reached the end.

Configure the ldap-agent

The configuration file for the ldap-agent is found here: /etc/dirsrv/config/ldap-agent.conf

Open the file and you'll find that most of the options are configured as they need to be, however you will need to add a server entry.  In my case the following was used:

server slapd-EXAMPLE-COM

 To find your server name get a list of the directories in the /etc/dirsrv directory, and take the directory which starts with "slapd-" and use it as shown above.

Starting it all up

I haven't dug around too deeply at this point but it appears that the ldap-agent must be started manually on RHEL7 and IDM.  However that's a simple matter of the following:

 /usr/sbin/ldap-agent /etc/dirsrv/config/ldap-agent.conf

 Once the agent has started it will return.

Testing it

From another server I pointed snmpwalk at the server and wala, data!

[root@zabbix ~]# snmpwalk -v2c -Cp -On -c public ipa.example.com .1.3.6.1.4.1.2312
.1.3.6.1.4.1.2312.6.1.1.1.389 = Counter64: 0
.1.3.6.1.4.1.2312.6.1.1.2.389 = Counter64: 0
.1.3.6.1.4.1.2312.6.1.1.3.389 = Counter64: 38
.1.3.6.1.4.1.2312.6.1.1.4.389 = Counter64: 2237
.1.3.6.1.4.1.2312.6.1.1.5.389 = Counter64: 0
.1.3.6.1.4.1.2312.6.1.1.6.389 = Counter64: 28111
.1.3.6.1.4.1.2312.6.1.1.7.389 = Counter64: 0
.1.3.6.1.4.1.2312.6.1.1.8.389 = Counter64: 0
.1.3.6.1.4.1.2312.6.1.1.9.389 = Counter64: 2
.1.3.6.1.4.1.2312.6.1.1.10.389 = Counter64: 2
.1.3.6.1.4.1.2312.6.1.1.11.389 = Counter64: 997
.1.3.6.1.4.1.2312.6.1.1.12.389 = Counter64: 0
.1.3.6.1.4.1.2312.6.1.1.13.389 = Counter64: 0
.1.3.6.1.4.1.2312.6.1.1.14.389 = Counter64: 18364
.1.3.6.1.4.1.2312.6.1.1.15.389 = Counter64: 92
.1.3.6.1.4.1.2312.6.1.1.16.389 = Counter64: 9543
.1.3.6.1.4.1.2312.6.1.1.17.389 = Counter64: 0
.1.3.6.1.4.1.2312.6.1.1.18.389 = Counter64: 0
.1.3.6.1.4.1.2312.6.1.1.19.389 = Counter64: 0
.1.3.6.1.4.1.2312.6.1.1.20.389 = Counter64: 5981
.1.3.6.1.4.1.2312.6.1.1.21.389 = Counter64: 21
.1.3.6.1.4.1.2312.6.1.1.22.389 = Counter64: 0
.1.3.6.1.4.1.2312.6.1.1.23.389 = Counter64: 0
.1.3.6.1.4.1.2312.6.2.1.1.389 = Counter64: 0
.1.3.6.1.4.1.2312.6.2.1.2.389 = Counter64: 0
.1.3.6.1.4.1.2312.6.2.1.3.389 = Counter64: 0
.1.3.6.1.4.1.2312.6.2.1.4.389 = Counter64: 0
.1.3.6.1.4.1.2312.6.2.1.5.389 = Counter64: 0
.1.3.6.1.4.1.2312.6.5.1.1.389 = ""
.1.3.6.1.4.1.2312.6.5.1.2.389 = STRING: "389-Directory/1.3.3.1"
.1.3.6.1.4.1.2312.6.5.1.3.389 = ""
.1.3.6.1.4.1.2312.6.5.1.4.389 = ""
.1.3.6.1.4.1.2312.6.5.1.5.389 = ""
.1.3.6.1.4.1.2312.6.5.1.6.389 = ""
.1.3.6.1.4.1.2312.6.5.1.6.389 = No more variables left in this MIB View (It is past the end of the MIB tree)

 It is worth noting that at this time I couldn't get the Red Hat MIB to properly load so I had to use the OID numbers, but a little sluthing of the Red Hat MIB file (default location is /usr/share/dirsrv/mibs) and you can figure out which OIDs to monitor.

Now I need to play with it some more to see if there is much value in the data.

Levovo w540 and Fedora 21

It's been a quick succession of new portable systems.  For the last few years I've been rolling with a Mac Air, while I love the form factor and weight, I'm not a fan of the dwindling battery and 4GB memory limit.  To that end I decided to get a beefier laptop to allow me to run VM's and have a bigger screen to work with, thus the W540.

Since my day job is working for the Shadow Man as a consultant, I'm going to run Fedora or RHEL.

Overall I've found the process of getting Fedora 21 on the W540 more challenging than getting it on the Microsoft Surface Pro 3, go figure.  That's especially perplexing since Lenovo is the laptop vendor of choice for Red Hat.

Before upgrading to F21, I recommend installing any hardware updates available via the pre-installed Windows OS from the vendor.  After that I started using a USB flash drive with a live ISO and installed the OS using the normal means.  Do not be surprised if the computer freezes up at random moments.  For me it took a few attempts before I was able to get F21 installed, as best I can tell there is a bug with the Open Source Nvidia driver, nouveau.  Thus I would suggest focusing on getting X working, before updating the OS.  For me this involved removing the nouveau driver and trying to get the proprietary drivers working from RPM before I found the eventual solution below.  I don't have the time to go back and redo this from scratch, so hopefully my notes here can help someone else.

I tried installing the nvidia driver from RPMforge but that didn't work, Gnome kept showing a sad face and a message "and error has occurred."  In looking at the logs (journalctl) it looked like Gnome was failing to detect 3d acceleration and thus failing.  WTF, I was running the proprietary nvidia drivers from RPMforge, more digging was needed.

In many of my searches I kept seeing references to bumblebee, most often on the ArchLinux Wiki's.  A little digging suggested this was the way forward.  Bumblebee is a project for systems with two graphics drivers and one display, such as laptops, where the processor has a built in graphics controller and there's an external graphics controller as well.

Fortunately there's a very useful wiki page for this: http://fedoraproject.org/wiki/Bumblebee. After following the instructions listed everything came up without issue.  It is worth noting that in order to get bumblebee to install I did need to remove the nvidia drivers installed from RPMforge, I had also removed the nouveau driver at an earlier point as well.  I am not able to test, but I think it would be best to try installing Bumblebee before configuring RPMforge.

Now that X is working I can work on getting the rest of the laptop configured and copy over my old home directory.

Fedora 21 and the Microsoft Surface Pro 3

Recently I decided I'd try to upgrade from my MacbokAir running Fedora and thus I decided to try out the Surface Pro 3.  Overall I have to say I'm rather impressed, it's not perfect, and there are still some warts, but it's a functional option, in fact I'm writing this on the Surface now.

The basic steps are as follows:

1. Shrink the windows volumes to allow for a space to install Fedora
2. Put Fedora on to a USB Fash drive and boot the Surface Pro to the USB flash drive.
3. Install Fedora
4. Tweak and enjoy!

For the prep steps I found the following blog useful: http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/. You can safely ignore most of the Distro specific steps with the exception of the firmware step.  Fortunately the cover keyboard and touchscreen and pen work out of the box with Fedora 21, however the touch pad mouse does not, although the buttons do.

After installing the OS, download the marvel firmware git repo and copy the contents to the appropriate directory:

$ git clone git://git.marvell.com/mwifiex-firmware.git
# mkdir -p /lib/firmware/mrvl/
# cp mwifiex-firmware/mrvl/* /lib/firmware/mrvl/

The Wifi device may be unstable before the firmware is updated, and bluetooth will not be available.

Next you will need to add a configureation for the touchpad mouse to work. It is worth noting that most instructions include the matching statement for the product.  I found that by removing this line the touchpad worked after updating the kernel.

/etc/X11/xorg.conf.d/10-touchpad.conf

Section "InputClass"
    Identifier "Surface Pro 3 Cover"
    MatchIsPointer "on"

    MatchDevicePath "/dev/input/event*"
    Driver "evdev"
    Option "vendor" "045e"
#    Option "product" "07dc"
    Option "IgnoreAbsoluteAxes" "True"
EndSection

If you have not already, update your OS "yum -y update" and reboot.  After rebooting you should have a working touchpad and bluetooth adapter along with a much more stable wifi connection.