Category Archives: Unix

Creating persistent USB device names on a Raspberry Pi

If you use multiple USB devices that for example create device names like /dev/ttyUSB0, /dev/ttyUSB1 and so on, you probably want to assign device names that are more descriptive. On Linux (and thus on an Raspberry Pi) you can do this by writing an udev rule. Udev is a device event handler, so when you plugin your USB device it will be seen by udev and will create device names according the ruleset.

I have two devices that I like to have a device name that are persistent. A Xbee/Zigbee Xstick from digi.com and an USB FTDI serial cable. Normally on a Linux system, you use the command ‘udevadm info’ to get the information you need to specify in the config file, but on the RPi ‘udevadm info’ results in a kernel panic, so use the commands ‘lsusb -v’ and ‘usb-devices’ to get the information you need.

Create a file /etc/udev/rules.d/99-usbdevices.rules with the following content:

ATTRS{idVendor}==”0403″, ATTRS{idProduct}==”6001″, ATTRS{product}==”XStick”, SYMLINK+=”zigbee”
ATTRS{idVendor}==”0403″, ATTRS{idProduct}==”6001″, ATTRS{serial}==”A6WGT0NS”, SYMLINK+=”smartmeter”

And restart udev and trigger pulling the devices:

sudo /etc/init.d/udev reload
sudo udevadm trigger

After that you should have links with the names you specified pointing to the real devices

$ ls -l /dev/zigbee /dev/smartmeter
lrwxrwxrwx 1 root root 7 Jul 30 21:02 /dev/smartmeter -> ttyUSB0
lrwxrwxrwx 1 root root 7 Jul 30 21:02 /dev/zigbee -> ttyUSB1

From now you can reference /dev/smartmeter instead of /dev/ttyUSB0 or some other number.

CentOS remote headless install

Soms is het nodig om een systeem op afstand te herinstalleren zonder dat je toegang hebt tot het console, bijvoorbeeld als jouw systeem in een datacenter hangt aan de andere kant van het land. Ik verwacht dit binnenkort nodig te gaan hebben bij een hoster die gebruik maakt van een eigen kernel, waar ik geen gebruik van wil maken en dus een schone installatie wil doen.

CentOS en dus Red Hat, Fedora, Scientific Linux, e.d., gebruiken Anaconda als installatie programma en deze kan gebruik maken van VNC, dus het principe is simpel. Boot met de installatie kernel en geef aan dat je gebruik wilt maken van VNC, zodat je vanaf een remote locatie contact kunt maken met de VNC server die door Anaconda is gestart, om de installatie af te maken.

Uiteraard is het ook mogelijk om gebruik te maken van een kickstart file, zodat de hele installatie ‘unattended’ zal, maar dat gaat voor dit doel een beetje te ver.

Download installatie kernel

Log in op het systeem die je opnieuw wilt installeren en voorzie deze van de installatie kernel

mkdir /boot/netimage
wget -P /boot/netimage http://mirror.centos.org/centos/6.2/os/x86_64/isolinux/vmlinuz
wget -P /boot/netimage http://mirror.centos.org/centos/6.2/os/x86_64/isolinux/initrd.img

Pas de bootloader aan

Nu moet de installatie kernel toegevoegd worden aan de (Grub) bootloader. Dit kun je het beste met het commando grubby doen, die zorgt voor de juiste formattering en zal ook de padnamen aanpassen aan de lokale situatie. Gebruik je grubby niet, let er dan in ieder geval op dat indien je /boot op een aparte partitie hebt, je de kernel-bestanden aanwijst als /netimage/vmlinuz en /netimage/initrd.img, dus zonder /boot er voor.

grubby --add-kernel=/boot/netimage/vmlinuz --initrd=/boot/netimage/initrd.img --args="ip=10.0.0.116 netmask=255.255.255.0 gateway=10.0.0.1 dns=8.8.8.8 ksdevice=eth0 repo=http://mirror.centos.org/centos/6.2/os/x86_64/ headless lang=en_US keymap=us vnc vncpassword=foobar" --title="CentOS 6.2 VNC install"

Het ip adres, netmask en de gateway dien je uiteraard aan te passen aan je eigen situatie. Voor de duidelijkheid, deze gegevens neem je over van het draaiende systeem!

De dns server 8.8.8.8 is de Google publieke DNS server, deze kun je aanpassen naar eigen wens, maar is dus niet nodig.

Het VNC wachtwoord is niet nodig maar ik raad je wel aan om deze te gebruiken. Er zal maar een of andere grapjas je installatie overnemen en de boel vernaggelen.

Bereid volgende boot voor

Grub kent een leuk grapje waarbij je eenmalig de default kernel aan kunt passen. Dat houdt dus in dat indien er onverhoopt iets mis gaan bij het booten van de installatie kernel, je met een reboot (powercycle) het systeem weer laat booten van de normale kernel.

De volgende commando’s regelen dit voor je. GRUBINDEX levert dus de positie op van de installatie kernel in de grub config.

GRUBINDEX=$(grubby --info=/boot/netimage/vmlinuz|awk -F\= '$1 ~ /^index/ {print $2}')
echo "savedefault --stage2=/boot/grub/stage2 --default=${GRUBINDEX} --once" | grub --batch

Reboot!

Na de reboot zal je systeem booten van de installatie kernel en via http://mirror.centos.org/centos/6.2/os/x86_64/ de installatie image (install.img = 129MB) ophalen. Zodra deze binnen is zal de grafische installatie gestart worden en pas van dit moment kun je met VNC connecten op 10.0.0.116:1 (:1 is gelijk aan poort 5901) om de installatie af te maken.

Voor dat je dit remote gaat doen, is het trouwens verstandig om dit een paar keer te testen op een (lokaal) systeem waar je wel het scherm van kunt zien tijdens de boot. Zo kun je een en ander finetunen en ervaring krijgen met dit bootproces. Deze handleiding heb ik geschreven door gebruik te maken van virtuele (KVM) hosts.

 

Virtual hosting met Postfix en Dovecot

Mijn mailserver is nodig aan vervanging toe en zoals ook voor mijn andere machines geldt, wordt ook deze voorzien van Centos in verband mijn aanloop naar het RHCA zijn.

In de nieuwe setup wilde ik geen gebruik meer maken van LDAP, dat heb ik jaren gedaan, maar gewoon simpel van configuratie bestanden, daar heb ik met mijn paar domeintjes ruim voldoende aan. De uiteindelijke aflevering van de email in de juiste box, laat ik over aan het ‘deliver’ programma van Dovecot, zodat ik in de toekomst ook de filtering daarvan kan gaan gebruiken.

Postfix

De wijzigingen (toevoegingen in dit geval) aan /etc/postfix/main.cf zijn minimaal:

1 virtual_minimum_uid = 500
2 virtual_uid_maps = static:500
3 virtual_gid_maps = static:500
4 virtual_mailbox_domains = hash:/etc/postfix/vdomains
5 virtual_transport = dovecot:
6 transport_maps = hash:/etc/postfix/transport
7 virtual_mailbox_maps = hash:/etc/postfix/vmailbox
8 virtual_alias_maps = hash:/etc/postfix/virtual

Op regel 1 zie je virtual_minimum_uid staan. Dit is fallback methode van Postfix, mocht er ergens een fout gemaakt zijn, dan zal er nooit een lager UID dan 500 gebruikt worden.

Regel 2 en 3 (virtual_uid_maps, virtual_gid_maps) geven aan hoe de mapping van de UID en GID informatie moet geschieden. Omdat ik gebruik maak van virtual hosting en dus de gebruikers geen entry in /etc/passwd hebben, dienen we postfix te vertellen welk UID en GID we willen gebruiken. Ik maak gebruik van UID en GID 500, welke ik koppel aan de gebruiker vmail. Deze gebruiker dient ook aangemaakt te worden:

groupadd -g 500 vmail
adduser -c 'Virtual Mail User' -d /var/vmail -M -g 500 -u 500 -s /sbin/nologin vmail

Met regel 4 (virtual_mailbox_domains) geef ik aan welke domeinen ik als virtueel beschouw. Ik neem hier alle domeinen in op, ook degene waarvoor ik alleen maar backup MX ben en via virtual_transport (regel 5) vertel ik Postfix welke manier van aflevering (transport) ik voor deze domeinen wil. Met transport_maps (regel 6) kan in de default waarde die gezet is met virtual_transport overrulen, dat gebruik ik voor de domeinen waarvoor ik MX backup ben.

De optie virtual_mailbox_maps op regel 7 koppelt een email adres aan een mailbox (directory of bestand) op het systeem. Normaal gesproken vertel je Postfix hiermee in welke directory er geschreven dient te worden, maar aangezien ik het programma deliver van Dovecot gebruik, hoef ik hierin alleen maar de email adressen te specificeren. Het tweede veld verwacht Postfix wel, dus daar kunnen we dummy info plaatsen.

Met virtual_alias_maps ( regel 8 ) koppel je een email adres aan een andere. Postfix geeft aan dat je hier nooit een wildcard domein in op moet nemen, uiteraard vanwege spam redenen, ik gebruik dat voor 1 van mijn domeinen wel, maar daar heb ik dan ook goede redenen voor.

De hash tables die aangemaakt dienen te worden, zie je hieronder staan. Waar ‘dummy’ staat, verwacht Postfix informatie die in deze situatie niet nodig is. Vergeet niet om na iedere wijziging een ‘postmap $bestandsnaam’ te doen.

/etc/postfix/vdomains
domain1 dummy
domain2 dummy

/etc/postfix/transport
friends_domain.nl relay
.friends_domain.nl relay

/etc/postfix/vmailbox
user1@domain1.nl dummy
user2@domain1.nl dummy

/etc/postfix/virtual
alias1@domain1.nl address1@domain1.nl
alias2@domain1.nl address1@domain1.nl, address2@domain1.nl
@domain2.nl address1@domain1.nl

Verschillende keren heb ik in bovenstaande tekst het programma deliver genoemd van Dovecot. Postfix kent deze standaard niet als LDA (local delivery agent), daarvoor moet aan /etc/postfix/master.cf het volgende worden toegevoegd:

dovecot unix – n n – – pipe
flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/deliver -f ${sender} -d ${recipient}

Dovecot

De Dovecot configuratie zoals ik hem op dit moment gebruik is alleen voor het afleveren van de email in de juiste mailbox, vandaar dat /etc/dovecot/dovecot.conf er nog minimaal uitziet. In een later stadium ga ik hier onder andere nog SSL aan toevoegen, zoals gezegd, dat heb ik nu nog niet nodig.

ssl = no
protocols = imap
mail_location = maildir:/var/vmail/domains/%d/%n
service auth {
unix_listener auth-userdb {
mode = 0600
user = vmail
group = vmail
}
}
passdb {
driver = passwd-file
args = /etc/dovecot/imapusers
}
userdb {
driver = static
args = uid=vmail gid=vmail home=/var/vmail/domains/%d/%n
}

In het bestand /etc/dovecot/imapusers staan de gebruikers met hun wachtwoord. Het is mogelijk om daarin mee informatie zoals GECOS en dergelijk op te nemen, maar ook hier geldt weer dat ik dat in mijn situatie niet nodig heb.

/etc/dovecot/imapusers
user1@domain1.nl:{DIGEST-MD5}0000aa0000aa0a000aa0a000aa00aa0a
user2@domain1.nl:{DIGEST-MD5}1111bb1111bb1b111bb1b111bb11bb1b

Selinux

Om Dovecot’s deliver te mogen laten schrijven in /var/vmail/, moet de Selinux verteld worden wat de juiste context is voor /var/vmail.

/usr/sbin/semanage fcontext -a -t mail_spool_t '/var/vmail(/.*)?'

Hierna is een restorecon -R /var/vmail nodig om een en ander juist te zetten. Mocht je ooit zelf in deze directory iets aanpassen, herhaal dan het restorecon commando.

Transip VPS pilot

Transip wil binnenkort als dienst VPS’en gaan aanbieden, maar voordat deze dienst wordt aangeboden, willen ze eerst een pilot draaien waarin deelnemers een maand gratis gebruik kunnen maken van een VPS. In die maand kan Transip kijken wat de invloed is van de VPS omgeving op hun bestaande infrastructuur.

Nu komt deze pilot voor mij op precies het juiste moment. Mijn eigen server is inmiddels ouder dan 4 jaar en staat op de nominatie om uitgefaseerd te gaan worden. Deze server draait bij mij thuis en ook dat is een situatie waar ik eigenlijk wel van af wil. Ook al ik de machine zo stil mogelijk en zo heb ik destijds al nagedacht over de energieconsumptie, toch is hij nog hoorbaar in sommige delen van het huis en uiteraard heb ik ook liever het energieverbruik van het huishouden een stukje lager. Tevens staat het idee van het niet meer druk hoeven maken om (mogelijk) uitvallende hardware mij ook wel aan 🙂

Via Twitter account van Transip hoorde ik dat er extra VPS beschikbaar kwamen in de pilot. Ik had al eerder aangeven graag gebruik te willen maken van de pilot, maar hoorde helaas niets. Nu nogmaals gemaild naar Transip en jawel hoor, ik kreeg mail dat er een VPS voor mij beschikbaar zou komen. Yes!

In de portal van Transip (pilot is alleen beschikbaar voor bestaande klanten), was voor mij nu de optie VPS er bij gekomen. Ik kon kiezen uit een installatie van verschillende Linux’en, FreeBSD en OpenBSD. Ik heb gekozen voor Centos 6 en via het console (webbased java applet), zag ik dat het systeem geboot was en in het normale Centos installatie scherm stond te wachten op input van mij.

Het werken via webgui console ging goed, ik merkte echter wel een duidelijke vertraging in de muis bewegingen. Toen het systeem eenmaal geïnstalleerd (minimal) was, werkte het text console uitstekend via de webgui. Via het console heb ik uiteraard meteen SSH aangezet, zodat ik het systeem verder via SSH kon afconfigureren.

Tot nu toe gaat het werken met de VPS erg goed. Het systeem is lekker ‘responsive’ en eigenlijk merk ik geen verschil in het werken met deze VPS bij Transip, of mijn eigen (net als Transip, gebruik ik ook KVM voor virtualisatie) virtuele systemen die op mijn LAN gehost worden.

De VPS zoals deze door Transip is opgeleverd, is voorzien van een 50 GB harddisk. Hopelijk is straks na de pilot het mogelijk om meer storage te krijgen, bijvoorbeeld via NFS of iSCSI.

Conclusie: dit zou wel eens een blijvertje kunnen zijn, als de prijsstelling mij een ‘beetje’ aanstaat 🙂

Dovecot met LDAP (jamm) en SSL (imaps)

Ik gebruik al langere tijd FreeBSD voor al mijn thuis servers. Echter zakelijk kom ik FreeBSD niet zo vaak tegen, echter Red Hat Enterprise Linux en aanverwanten wel. Vorig jaar heb ik besloten om mezelf te gaan certificeren voor Red Hat en heb RHCE gehaald. Nu ben ik voorzichtig aan het kijken om misschien zelfs voor RHCA te gaan.

Om nog vaker met RHEL systemen te werken, worden steeds meer van mijn FreeBSD machines vervangen door Centos systemen. Binnenkort zal mijn huidige FreeBSD mailserver daarom ook vervangen worden door een Centos systeem. Ter voorbereiding daarop heb ik alvast uitgezocht hoe ik Dovecot (imaps) laat samenwerken met mijn huidige mailstorage omgeving, waarbij authenticatie gegevens in LDAP staan en ik gebruik heb gemaakt van het Jamm schema.

Voor IMAPS maak ik gebruik van certificaten die gesigned zijn door cacert.org. Deze Certificate Authority werkt met een methode ‘Web of trust’ die soortgelijk is aan de methode waarop bijvoorbeeld PGP/GPG key signing werkt. Uiteraard kun je er ook voor kiezen om je certificaten van een andere partij te betrekken of te werken met ‘self signed’ certificaten.

Voordat we aan de slag kunnen, moeten er eerst wat packages geïnstalleerd worden:

sudo yum -y install dovecot openssl

Voor het verkrijgen van een door CAcert gesigned certificaat, moet je een ‘signing request’ (CSR) aanmaken. Een CSR maak je aan voor een door jezelf gegeneerde RSA private key. Normaal gesproken moet je dus met het openssl commando eerst een RSA KEY aanmaken en dan een CSR. Dit is allemaal best wel lastig, gelukkig is het bij RHEL systemen erg simpel gemaakt:

cd /etc/pki/tls/certs
make dovecot.csr

(Vul bij CommonName de volledige naam (fqdn) in van jouw systeem, dus bijvoorbeeld: imapserver.example.com)

Ga hierna naar https://secure.cacert.org/account.php?id=10 en plak de inhoud van dovecot.csr in het formulier. Laat het certificaat type op Class 3 staan. Na wat klikken komt er uiteindelijk een prachtig gesigned certificaat, plak de inhoudt hiervan in dovecot.crt. Je krijgt ook een email van CAcert met de link naar jouw nieuwe certificaat. Je hebt ook het Class 3 root certificaat nodig van CAcert. download deze van http://www.cacert.org/certs/class3.crt

Vanuit de Dovecot configuratie file gaan we straks verwijzen naar deze 3 bestanden, zet deze op de juiste plaats, met passende permissies:

install -o root -g root -m 644 class3.crt /etc/pki/tls/certs/cacert-class3.crt
install -o root -g root -m 644 dovecot.crt /etc/pki/dovecot/certs/dovecot.crt
install -o root -g root -m 644 dovecot.key /etc/pki/dovecot/private/dovecot.key

Plaats het volgende in /etc/dovecot.conf. Maak eerst een backup!

auth_verbose = yes
protocols = imap imaps
base_dir = /var/run/dovecot/

ssl_cert_file = /etc/pki/dovecot/certs/dovecot.crt
ssl_key_file = /etc/pki/dovecot/private/dovecot.key
ssl_ca_file = /etc/pki/tls/certs/cacert-class3.crt

shutdown_clients = yes
mail_location = maildir:/var/vmail/domains/%d/%n

auth default {
mechanisms = PLAIN LOGIN

userdb static {
args = uid=500 gid=500
}

passdb ldap {
args = /etc/dovecot-ldap.conf
}

userdb ldap {
args = /etc/dovecot-ldap.conf
}

socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0600
user = vmail
group = vmail
}
}

user = vmail
}

Zorg er voor dat een en ander conform jouw setup is. Denk hierbij vooral aan de user (vmail) en het bijbehorende UID (500) en de locatie van de imap data (mail_location). Bij mij staat de imap dat in /var/vmail/domains/$domein/$user, bijvoorbeeld /var/vmail/domains/example.com/pietjepuk. De loginnaam van deze voorbeeld gebruiker is dan pietjepuk@example.com.

In mail_location worden enkele Dovecot specifieke variabelen gebruikt. De betekenis er van en andere mogelijkheden, vind je op http://wiki.dovecot.org/Variables

Plaats het volgende in /etc/dovecot-ldap.conf. Als het goed is, bestond dit bestand nog niet. Anders maak je uiteraard eerst een backup.

hosts = $ldapserver
auth_bind = yes
auth_bind_userdn = mail=%u,vd=%d,o=hosting,dc=example,dc=com
ldap_version = 3
base = o=hosting,dc=example,dc=com
dn = cn=phamm,o=hosting,dc=example,dc=com
dnpass = $password
deref = never
scope = subtree
user_attrs = mailbox=mail=maildir:/var/vmail/domains/%$
user_filter = (&(objectClass=VirtualMailAccount)(accountActive=TRUE)(mail=%u))
pass_attrs = mail,userPassword
pass_filter = (&(objectClass=VirtualMailAccount)(accountActive=TRUE)(mail=%u))
default_pass_scheme = MD5
user_attrs = quota=quota=maildir:storage=%$B
user_global_uid = 500
user_global_gid = 500

Ook hier geldt weer, pas alles aan naar jouw eigen situatie.

Alle instellingen zijn nu gedaan. Start Dovecot en testen maar!

chkconfig dovecot on
service dovecot restart

Bij het starten van Dovecot, wordt er gevraagd om de passphrase van je SSL key (dovecot.key). Mocht je dit niet willen, dan dien je de passphrase te verwijderen van je key. Dat doe je als volgt:

openssl rsa -in dovecot.key -out dovecot.key

Bestands encryptie met scrypt

In mei 2009 is de tool scrypt geschreven door Colin Percival, de huidige Security Officer van FreeBSD. Wat scrypt nu precies is en kan, kun je lezen op de webpagina, in het kort komt het neer op de volgende quote:

A simple password-based encryption utility is available as a demonstration of the scrypt key derivation function. On modern hardware and with default parameters, the cost of cracking the password on a file encrypted by scrypt enc is approximately 100 billion times more than the cost of cracking the same password on a file encrypted by openssl enc; this means that a five-character password using scrypt is stronger than a ten-character password using openssl.

Klinkt allemaal goed, maar wat ik wil is gewoon een simpele methode om mijn bestand met wachtwoorden beschermen, zodat bij verlies of diefstal, ik niet een megaprobleem heb. Het merendeel van de wachtwoorden die in dat bestand staan, zijn automatisch gegenereerd en bestaan uit minimaal 10 karakters, dus als ik die kwijt ben, weet ik ze ook echt niet meer 🙂

Op een FreeBSD systeem kun je scrypt installeren vanuit de ports collectie (/usr/ports/security/scrypt), voor andere OS’en dien je de source te downloaden en zelf de compileren.

Het aanmaken van een gecrypt bestand gaat met scrypt erg simpel.

scrypt enc infile outfile

In bovenstaand voorbeeld is infile je bronbestand welke je wilt crypten en outfile het gecrypte bestand. Scrypt zal je bij het uitvoeren twee maal vragen om de passphrase (wachtwoord) waarmee je het bestand wilt beveiligen. Na het aanmaken van outfile, moet je natuurlijk wel je bronbestand verwijderen, maar controleer eerst of je het bestand kunt decrypten.

Decrypten gaat als volgt:

scrypt dec outfile

De output wordt op het scherm getoond (STDOUT), wil je de output naar een bestand hebben, dan zet je uiteraard ‘> newfile‘ achter bovenstaand commando, waarbij newfile de naam is van je gewenste bestandsnaam.

Enjoy!

Renaming a virtual host with virsh :: kvm

Soms is het handig om een virtueel systeem te hernoemen. Als ik bijvoorbeeld een nieuwe versie van een server aan het bouwen ben, noem ik zo’n machine vaak iets als new_$originelenaam. Met onderstaande commando’s kun je de naam van een virtueel systeem KVM hernoemen.

Eerst dienen we de huidige configuratie van het systeem weg te schrijven naar een bestand

sudo virsh dumpxml machinenaam > /tmp/nieuwemachinenaam.xml

Bewerk het bestand /tmp/machinenaam.xml, zet tussen de <name> </name> tags de gewenste nieuwe naam

sudo vi /tmp/nieuwemachinenaam.xml

De bestaande configuratie van het systeem dient nu verwijderd te worden.

sudo virsh undefine machinenaam

Nu kan het systeem weer worden aangemaakt met de nieuwe naam.

sudo virsh define /tmp/nieuwemachinenaam.xml

All done, starten maar!!

Migratie van VMWare naar KVM

Sinds enige tijd ben ik van Debian met VMWare server 1.* overgestapt naar Centos (64 bits) en KVM. De vmdk bestanden heb ik via qemu-img geconverteerd naar het qcow2 formaat van Qemu.

sudo qemu-img convert $machine.vmdk -O qcow2 $machine.qcow2

Het bijbehorende vmx bestand heb ik met het python script vmware2libvirt omgezet naar een Libvirt XML file. vmware2libvirt wordt niet meegeleverd bij Centos, deze wordt geleverd/gemaakt door Ubuntu, maar is gewoon los te downloaden.

vmware2libvirt -f $machine.vmx > $machine.xml

Hierna importeer je deze met

virsh -c qemu:///system define file.xml

Updating FreeBSD systemen

Vandaag was de temperatuur eindelijk zover gedaald, dat ik het laatste systeem welke nog niet op FreeBSD 8.0 draaide, kon updaten. De (virtuele) machine die zorgt draagt voor de interne services (LDAP, DNS, MySQL, Syslog en Subversion) is nu dus ook over. De laatste tijd kreeg ik al dagelijks een melding dat de versie van FreeBSD die er op draaide, niet meer ondersteund werd, en dan wordt het toch wel tijd 🙂

Monitoring Splunk met Nagios

Sinds een tijdje ben ik (weer) aan het spelen met Splunk. Waarom weet ik nog niet, maar inmiddels is Splunk al twee keer gecrashed. Om dit beter in de gaten te kunnen houden heb ik een simpele Nagios check geschreven.

cat check_nagios.pl

#!/usr/bin/perl

use strict;
use warnings;
use diagnostics;

# exit code 0, if the test was okay = green
# exit code 1 means warning = yellow
# exit code 2 means critical = red
# exit code 3 means unknown = orange.

my $input_command = “sudo /opt/splunk/bin/splunk status”;

open(PIPE, “${input_command} |”);

my $count;

while(my $line = ) {
chomp($line);

if ( ${line} =~ m/splunkd\sis\srunning/ ) {
$count++;
} elsif ( ${line} =~ m/splunkweb\sis\srunning/ ) {
$count++;
} elsif ( ${line} =~ m/splunk\shelpers\sare\srunning/ ) {
$count++;
} else {
print “Unknown output from ${input_command}\n$line\n”;
exit(1);
}
}
close(PIPE);

if ( ${count} eq 3 ) {
print “All splunk parts are running\n”;
exit(0);
} else {
print “Not all splunk parts are running!!\n”;
exit(2);
}

Dit perl script heb ik in NRPE gezet, zodat ik vanaf mijn Nagios server, dit script kan uitvoeren.

command[check_splunk]=/usr/local/sbin/check_splunk.pl

Aangezien de nrpe daemon niet door root wordt uitgevoerd, heb ik via sudo de rechten aan Nagios gegeven om de splunk binarie aan te roepen.