It’s been about an year since I’ve been hacking around with Cacti and SNMP on various platform here inside our Server Farm. I always had very interesting results with all the system I had to deal with whether they were FreeBSD/Linux boxes, Windows boxes, printers, routers or anything… except for the AIX boxes. AIX’s internal SNMP just sucks. Full stop. The information he’s able to report can be quantified with 2 fingers of one hand: installed software and TCP statistics. No way to report CPU usage, memory usage, file systems usage, or anything else.

So today I packed everything together and decided to compile net-snmp on AIX. I must admit I was pretty worried by this but it turned out to be pretty simple, if you just pay attention to a few steps.

First of all you need the AIX Linux Toolbox. It’s a bunch of RPMs to be installed to install the GCC compiler, the standard libs (LibGCC) and a few other things. Everything can be be found here:

Basically you need just a few thing:

  • GCC / GCC++
  • LibGCC / LibGCC++ / LibGCC++-Devel
  • LSOF

Note that to compile net-snmp probably you don’t need all of them but I wanted to create a somewhat standard environment, so I decided to include all of them.

Optionally you may want (well, you HAVE to, unless you’re running AIX 5.3 or higher) to install GNU Grep and GNU SED as AIX default one have some problems with lines longer than 2048 chars.

After installing GNU Grep and GNU SED (you can find the RPMs at the usual Linux Toolbox page) you have to make sure that GNU grep and sed take the priority over standard one. There are several way to accomplish this. The one I choose was to edit /etc/environment and to change the standard PATH to include /opt/freeware/bin (that’s where grep and sed will be installed) before /usr/bin. So my PATH actually looked like this:


Now it was just a matter of un-tarring net-snmp’s sources somewhere and running configure. BUT! (there’s always a “but” with AIX) you have to pay attention to configure’s command line as the the default parameters seems not to work ok.

So what I came up (reading net-snmp’s docs) was this:

./configure –disable-shared –disable-embedded-perl –without-kmem-usage

this way you are disabling shared libs (which seems to cause segmentation faults) and embedded perl support (for the same reason). Last but not least you’re disabling KMEM because of compatibility issues with 64bit kernels. As of now net-snmp latest version is 5.4… if you’re using a newer version or you’re using a 32bit kernel you may want to test everything using kmem (although I don’t even know what it is).

Ok. After configure finishes (and it asks you a few standard question about snmp you should be able to answer by yourself) just run

make && make install

and you’ll be happy.

Do the standard configuration in /usr/local/share/snmp/snmpd.conf (read net-snmp docs on how to do that).

Now it’s time to stop AIX’s internal snmpd with

stopsrc -s snmpd

Check that it’s really stopped with a nice

ps -ef | grep snmpd

and then run


Check it is running with the same

ps -ef | grep snmpd

as before and check it’s correctly reporting something by using snmpwalk from any other host (or from the same machine on localhost).

Now, there are some problems. At least I have them. net-snmp doesn’t report correctly for the all the TCP stuff (like lan cards activity and such). I really don’t know why but instead of getting crazy with that I just decided to reactivate AIX’s internal snmpd on a different port, for example 8161, (by editing /etc/services and specificing a different port for the snmp service instead of 161) and having net-snmp proxying that part of the snmp-tree to internal’s snmpd. Edit /usr/local/share/snmp/snmpd.conf and make sure you specify the listening port for net-snmp (just because we don’t want it to get confused by our previous changes in /etc/services) using the following line:

agentaddress udp:161

next step is to add the proxy specifications by using the proxy command. It should look something like this:

proxy -v 1 -c public .

Basically you’re saying that whenever someone requests the . branch (that is the branch for the Ethernet Interfaces, net-snmp will proxy the request to the agent running on‘s port 8161, that is AIX’s internal snmpd, by using a version 1 snmp request.

Clever uh?

Restart /usr/local/sbin/snmpd and restart AIX’s snmpd with

startsrc -s snmpd

Let me know if it works for you 🙂

Mac OS X sull’IBM ThinkCentre M52

C’è voluto un poco (in realtà pochissimo) ma alla fine sono riuscito ad installare Mac OS X sul IBM ThinkCentre M52 (8212-16G).

L’hardware della macchina è quasi tutto supportato e dopo aver installato un DVD debitamente patchato della versione 10.4.7 con il supporto per i processori Intel SSE2 il sistema è ripartito al primo boot. L’unico problema grave incontrato è stato che non funzionava correttamente la scheda grafica se non in safe boot (quindi in Vesa standard). Il problema però si è risolto semplicemente installando i driver per la GMA900 presenti sul DVD. La cosa fuorviante è che questo pc non ha una GMA900, ma se tanto mi da tanto…

Ora l’unica cosa rimasta (purtroppo) in sospeso è la scheda audio. Su internet ho trovato vari forum in cui si spiegano metodi con cui questa scheda dovrebbe iniziare a funzionare, ma dopo qualche rapido tentativo di smanazzamenti vari nei vari kext di sistema, il sistema è ancora totalmente muto. E’ un vero peccato perché essendo un grande fan di iTunes (e avendo numerosi brani comprati nell’iTunes music store) sono un po’ bloccato.

Nei prossimi giorni farò qualche altra prova, o altrimenti, come molti fanno, comprerò un paio di quelle bellissime cassette USB con scheda audio integrata, che si mormora funzionino bene.

E intanto mi godo il nuovo mail e la versione nuova di safari che sull’iMac di casa dove gira la 10.3.qualcosa non sono disponibili.

L’efficenza lavorativa è fortunatamente immutata, l’SSH ed il telnet li ho, il browser pure (ho optato per firefox per questioni di javascript e simili, ma appena posso uso safari), il client Terminal Server pure… e vai col tango (no, piuttosto vai col cocoa).

Per i più piccoli un bello screenshot esemplificativo:

Mac OS X al suo meglio

When SendMail ignores the mailertable

Sometimes SendMail behaviours are definitely strange.

Lately I moved my mail server from one machine to another, both running FreeBSD (6.0 the old one and 6.2 the new one) and both running DBMail as mail backend. Everything went smoothly… apart from the fact that just one domain wasn’t working.

Let’s step back a second. DBMail plugs into SendMail by using the mailertable standard. There you say that any mail for a specific domain has to be routed trough a different delivery service instead of the standard local one (SendMail‘s internal). Thus I have no users and domain configured in SendMail as everything gets forwarded to DBMail. This is easily done by adding the following code to /etc/mail/mailertable:

Pretty simple: if you receive mail for domain forward it to dbmail as mail for domain Everything was working but one domain: Every time I tried to send any mail to SendMail was trying to deliver mail locally (read: internally) and thus was reporting an “User unknown” error to the remote mail server.

To make a long story short the problem is that SendMail define a special class of domains called “Class L”. Domains in this class are treated as special local domains that override any other definition from mailertable or such. Now the funny thing is that SendMail‘s default behaviour is to include localhost’s FQDN in the Class L (actually it makes some sense) and to lookup in the DNS the corresponding MX records for this host (thus even if the localhost name was he considered as a local domain because he was listed as the MX for that domain – a very interesting assumption, I’d say). To override this behaviour you can just create an empty /etc/mail/local-host-name (the file used to override the Class L definitions) and you’re done.


(there’s always a “but”)

Be careful! When I say “EMPTY” /etc/mail/local-host-name I really mean EMPTY. I mistakenly created the file by including a white line inside, and for some reason I really don’t know (and actually really don’t care about) SendMail probably assumed the file was garbled and ignored it.

It took me almost two days to find out that this was the problem, so pay real attention to it.