I have spent some time earlier on getting mrtg to work on my server but by now it has sent me hundreds of emails already telling me it’s not working properly, telling me things like:

Constant subroutine SNMP_Session::AF_INET6 redefined at /usr/share/perl/5.12/Exporter.pm line 64.
 at /usr/share/perl5/SNMP_Session.pm line 149

As I never gave mrtg much time on installation, let’s try and do this a bit more structurally, as MRTG, but mostly the RRD database being used as an engine for it, is really quite a nice tool that deserves some more attention. So, I removed the mrtg package first to start again from scratch:

omega:~# dpkg --purge mrtg

Reinstalling

With the mrtg package now removed, let’s reinstall and analyze what’s happening exactly:

omega:~# apt-get install mrtg

The package install asks whether the /etc/mrtg.cfg should be readable by root-only as making it readable by others is a security risk. I’m not sure why bother to ask then, so I said to make it readable by root-only. The package install recommends installing mrtg-contrib as well, so let’s:

omega:~# apt-get install mrtg-contrib

Configuration

The config file /etc/mrtg.cfg mentioned in the install is very simple indeed as it only specifies the WorkDir, the WriteExpires and the Title.

After the install there doesn’t appear to be any daemon running, nor is there an init RC file for MRTG. Fortunately we do find an /etc/cron.d/mrtg file:

*/5 *	* * *	root	if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg.cfg ]; then mkdir -p /var/log/mrtg ; env LANG=C /usr/bin/mrtg /etc/mrtg.cfg 2>&1 | tee -a /var/log/mrtg/mrtg.log ; fi

So we see mrtg gets fired up every 5 minutes through cron. Looking at this we expect to find something in /var/log/mrtg as well, and indeed there’s a logfile which contains repetitive error messages seen earlier. As the script runs as root, we can also try reproducing this from the command line:

omega:/etc/cron.d# env LANG=C /usr/bin/mrtg /etc/mrtg.cfg
Constant subroutine SNMP_Session::AF_INET6 redefined at /usr/share/perl/5.12/Exporter.pm line 64.
 at /usr/share/perl5/SNMP_Session.pm line 149
Prototype mismatch: sub SNMP_Session::AF_INET6 () vs none at /usr/share/perl/5.12/Exporter.pm line 64.
 at /usr/share/perl5/SNMP_Session.pm line 149
Constant subroutine SNMP_Session::PF_INET6 redefined at /usr/share/perl/5.12/Exporter.pm line 64.
 at /usr/share/perl5/SNMP_Session.pm line 149
Prototype mismatch: sub SNMP_Session::PF_INET6 () vs none at /usr/share/perl/5.12/Exporter.pm line 64.
 at /usr/share/perl5/SNMP_Session.pm line 149
Constant subroutine SNMPv1_Session::AF_INET6 redefined at /usr/share/perl/5.12/Exporter.pm line 64.
 at /usr/share/perl5/SNMP_Session.pm line 608
Prototype mismatch: sub SNMPv1_Session::AF_INET6 () vs none at /usr/share/perl/5.12/Exporter.pm line 64.
 at /usr/share/perl5/SNMP_Session.pm line 608
Constant subroutine SNMPv1_Session::PF_INET6 redefined at /usr/share/perl/5.12/Exporter.pm line 64.
 at /usr/share/perl5/SNMP_Session.pm line 608
Prototype mismatch: sub SNMPv1_Session::PF_INET6 () vs none at /usr/share/perl/5.12/Exporter.pm line 64.
 at /usr/share/perl5/SNMP_Session.pm line 608

Just lovely…

Fixing the bug wasn’t very difficult. I found a Debian bug report which alas didn’t include a fix yet; however I found a fix here. Voila, now I have mrtg running, let’s see how to configure it.

I recently bumped into a problem when trying to install OpenLDAP and will document how I fixed these problems.

Problem

When trying to install OpenLDAP through the regular methods:

omega:~# apt-get install slapd

I ran into a ‘grave bug’:

grave bugs of slapd (-> 2.4.25-1.1) <unfixed>
 #628237 - slapd: installation fails: slap_sasl_init: auxprop add plugin failed
   Merged with: 627984

The above message is generated by the apt-listbugs program that checks bug reports before actually installing something. So we can inspect the cause of this problem by viewing the Debian Bug Database.

omega:~# aptitude install nagios3-core

This also installs the packages nagios-plugins, nagios-plugins-basic, nagios-plugins-standard and nagios3-common. The only thing Debian specific in the /usr/share/doc/nagios3-common/README.Debian is a note about running external commands from Nagios:

/etc/init.d/nagios3 stop
dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
/etc/init.d/nagios3 start

A service startup file is added in /etc/init.d/nagios3 and the service is immediately started after the package install:

omega:/etc/init.d# ps xa|grep nagios
14937 pts/0    S+     0:00 grep nagios
24092 ?        SNs    0:00 /usr/sbin/nagios3 -d /etc/nagios3/nagios.cfg

I also immediately got two emails from Nagios, one telling me a filesystem is getting full and one telling me that a lot of processes are running on my server. I knew this last bit already.

Configuration

The main config file is right where I expect it, /etc/nagios3/nagios.cfg. Lots of parameters there, but most very comprehensive and well documented. The configured logfile /var/log/nagios3/nagios.log immediately shows the emailed alerts in a human readable format and the /etc/nagios3/command.cfg immediately shows how I got the emails I got:

define command{
    command_name    notify-host-by-email
    ....

This is just one of the more important command definitions in this file but there are a few others as well, I’m already getting the hang of this thing after 10 minutes or so.

nagios.cfg also sets two config_dir parameters, /etc/nagios-plugins/config and /etc/nagios3/conf.d. These are both directories in which we find several files. The conf.d directory has files that:

• contacts_nagios2.cfg: defines a few contacts
• extinfo_nagios2.cfg: defines host and service information
• generic-host_nagios2.cfg: defines a template for a host
• generic-service_nagios2.cfg: defines a template for a service
• hostgroups_nagios2.cfg: defines generic hostgroups
• localhost_nagios2.cfg: defines an actual host, localhost
• services_nagios2.cfg: defines web service and ssh service
• timeperiods_nagios2.cfg: defines the timings for monitoring

The nagios-plugins/config directory has files that:

• apt.cfg: check apt
• breeze.cfg: wireless?
• dhcp.cfg: check dhcp server
• disk.cfg: check diskspace
• disk-smb.cfg: check SMB
• dns.cfg: check DNS
• flexlm.cfg: check  flexlm
• fping.cfg: check fping
• ftp.cfg: check ftp
• games.cfg: check games
• hppjd.cfg: HP printer?
• http.cfg: check webserver
• ifstatus.cfg: check network interfaces
• ldap.cfg: check ldap server
• load.cfg: check system load
• mail.cfg: check mailserver
• mailq.cfg: check mailserver
• mrtg.cfg: Check mrtg
• mysql.cfg: check MySQL database server
• netware.cfg:
• news.cfg:
• nt.cfg:
• ntp.cfg:
• pgsql.cfg:
• ping.cfg:
• procs.cfg:
• radius.cfg:
• real.cfg:
• rpc-nfs.cfg:
• snmp.cfg:
• ssh.cfg:
• tcp_udp.cfg:
• telnet.cfg:
• users.cfg:

Installation

The installation of sendmail, as with most Debian packages, is very straightforward. All the software for Debian, much like most Linux distributions nowadays, is packaged and available from an online repository. The tool aptitude can be used to install a package from one of these repositories:

omega:~# aptitude install sendmail

As a result of this simple little command however, a LOT of things actually happen:

The following extra packages will be installed:
  sendmail-base sendmail-bin sendmail-cf sensible-mda
Suggested packages:
  sendmail-doc rmail logcheck sasl2-bin
The following packages will be REMOVED:
  postfix
The following NEW packages will be installed:
  sendmail sendmail-base sendmail-bin sendmail-cf sensible-mda
0 upgraded, 5 newly installed, 1 to remove and 335 not upgraded.
Need to get 2,084 kB of archives.

So we see here the postfix package actually being removed. Debian knows that postfix functions as MTA and that in most ordinary cases no two MTA’s should be running on one server.

We also see a number of new packages being install, sendmail, sendmail-base, sendmail-bin, sendmail-cf and ‘sensible-mda’, which aptitude apparently finds to be required to set up a sendmail MTA. One thing that’s often overlooked in the aptitude output is the ‘Suggested packages:’. I’ve found these to be very accurate suggestions in the past so when we’re done converting to sendmail we’ll check out these packages as well.

Frequently I install small applications and hardly really check the output that flies by. An MTA however is often a complicated and important service which requires meticulous checking. One thing I immediately noticed:

Setting up sendmail-base (8.14.4-2) ...
adduser: Warning: The home directory `/var/lib/sendmail' does not belong to the user you are currently creating.

This should immediately trigger a mental note to verify which user is being created as part of the installation of the sendmail-base package. After the installation finishes a quick check in /etc/passwd reveals:

smmta:x:125:125:Mail Transfer Agent,,,:/var/lib/sendmail:/bin/false
smmsp:x:126:140:Mail Submission Program,,,:/var/lib/sendmail:/bin/false
omega:~# ls -la /var/lib/sendmail/
total 8
drwxr-s--x  2 smmta smmsp 4096 Jun 25 01:59 .
drwxr-xr-x 91 root  root  4096 Jun 26 01:28 ..
-rw-rw----  1 root  smmsp    0 Jun 25 01:59 dead.letter

So two new users were created, both having the same homedirectory, somewhat odd but it explains the error message.

Immediately after the install we also see right away that sendmail has been started up:

omega:~# ps xa|grep sendmail|grep -v grep
25117 ?        Ss     0:05 sendmail: MTA: accepting connections

And inspection shows it’s also immediately accepting connections on port 25, the SMTP port:

omega:~# telnet localhost 25
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 omega.dutchie.org. ESMTP Sendmail 8.14.4/8.14.4/Debian-2; Wed, 29 Jun 2011 08:27:52 +0200; (No UCE/UBE) logging access from: localhost.localdomain(OK)-localhost.localdomain [127.0.0.1]

Configuration

The packages that have been installed have installed some documentation according to Debian standards:

omega:/usr/share/doc/sendmail# ls -dlF /usr/share/doc/sendmail*
drwxr-xr-x 2 root root 4096 Jun 25 01:59 /usr/share/doc/sendmail/
lrwxrwxrwx 1 root root    8 Jun 25 01:58 /usr/share/doc/sendmail-base -> sendmail/
drwxr-xr-x 2 root root 4096 Jun 25 01:59 /usr/share/doc/sendmail-bin/
lrwxrwxrwx 1 root root    8 Jun 25 01:59 /usr/share/doc/sendmail-cf -> sendmail/

The README.gz file gives a couple of good points to get started:

• Overview of directory permissions required
• DontBlameSendmail
• File locking note

Interesting is that not all the recommendations in the README.gz file are implemented in the Debian package, for example:

omega:/etc/mail# ls -l ../aliases
-rw-r--r-- 1 root root 222 Oct  4  2009 ../aliases

While the README.gz suggests permissions 0640. We see however from the timestamp on this file that this aliases file is a much older one already and a leftover from the postfix package that was removed when installing sendmail. This leaves open a potential risk of authorized users (in this case everybody) to lock the file and make locking by sendmail impossible!

All of the configuration files have been installed in /etc/mail. The most important one to inspect right away is of course sendmail.cf and its source sendmail.mc. Right after the install a sendmail.cf.errors has also been generated (?):

omega:/etc/mail# cat sendmail.cf.errors
*** ERROR: FEATURE() should be before MAILER()
*** MAILER(`local') must appear after FEATURE(`always_add_domain')*** ERROR: FEATURE() should be before MAILER()
*** MAILER(`local') must appear after FEATURE(`allmasquerade')*** ERROR: FEATURE() should be before MAILER()

Sendmail.cf is a generated file with an M4 file as its source. M4 is a rather complex macro processors which turns a small and simple file like sendmail.mc into a complicated and approx. 15 times as large sendmail.cf. Inspection of sendmail.cf has often been referred to as ‘black magic’, indicating the complexity of the file as sendmail has an enormous amount of configuration options.

I can’t be quite sure yet but the sendmail.cf.errors are probably quite harmless as they appear to be caused by something that’s been added dynamically to sendmail.mc:

dnl # Masquerading options
FEATURE(`always_add_domain')dnl
MASQUERADE_AS(`3dn.nl.')dnl
FEATURE(`allmasquerade')dnl
FEATURE(`masquerade_envelope')dnl

As we can see, 3dn.nl is in here, which is my local mail domain. The Debian package builder probably decided to simply add these lines to the end of the sendmail.mc before generating a reasonable default configuration. It’s also handy to know this as we now have a pretty good idea of what has been done to give sendmail a reasonable initial configuration. Just to be certain though, I moved these lines before the MAILER_DEFINITIONS and regenerated sendmail.cf:

omega:/etc/mail# make sendmail.cf
Updating databases ...
Reading configuration from /etc/mail/sendmail.conf.
Validating configuration.
Creating /etc/mail/databases...
Updating Makefile ...
Reading configuration from /etc/mail/sendmail.conf.
Validating configuration.
Creating /etc/mail/Makefile...
Updating sendmail.cf ...

This got rid of the error messages and shows something I don’t remember having seen before on earlier sendmail installs, which is the sendmail.conf file being used. Inspection of this file reveals:

# Parameter file for sendmail (sourced by /usr/share/sendmail/sendmail)
# Make all changes herein, instead of altering /etc/init.d/sendmail.
#
# After making changes here, you'll need to run /usr/sbin/sendmailconfig
# or /usr/share/sendmail/update_conf to have the changes take effect -
# If you change DAEMON_MODE, QUEUE_MODE, or QUEUE_INTERVAL, you'll also
# need to run /etc/init.d/sendmail restart.

Using Linux and hostapd however, it is possible to build an access point that does offer 802.1x functionality. For this to work, a supported network adapter needs to be used. In this article I will document how to build an 802.1x capable access point (WLAN), while a next article may demonstrate how to use 802.1x on a wired LAN.

Required Hardware

To provide access point functionality the so called ‘master mode’ needs to be supported on the Linux device driver for the network card. I purchased a TP-Link TL-WN951N PCI card for this purpose. This card has an Atheros chipset that’s recognized by Linux’ ath9k driver in the current (2.6.32-5, Debian Sid) kernel.

Software and Drivers

To get the card to behave like a basic access point, we first need to load the ath9k driver. On Debian Sid kernels (and probably most other kernels) this happens automatically. The oldest supported kernel according to Linux Wireless is 2.6.32. The dmesg output shows:

[    6.636267] ath9k 0000:09:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17

[    7.065708] ath: EEPROM regdomain: 0x809c

[    7.065709] ath: EEPROM indicates we should expect a country code

[    7.065711] ath: doing EEPROM country->regdmn map search

[    7.065712] ath: country maps to regdmn code: 0x52

[    7.065713] ath: Country alpha2 being used: CN

[    7.065714] ath: Regpair used: 0x52

[    7.118038] phy0: Selected rate control algorithm 'ath9k_rate_control'

[    7.118473] cfg80211: Calling CRDA for country: CN

[    7.118494] Registered led device: ath9k-phy0::radio

[    7.118504] Registered led device: ath9k-phy0::assoc

[    7.118513] Registered led device: ath9k-phy0::tx

[    7.118522] Registered led device: ath9k-phy0::rx

[    7.118527] phy0: Atheros AR5416 MAC/BB Rev:2 AR2133 RF Rev:81: mem=0xffffc900057a0000, irq=17