Andreas Bergman

Icon

Restrict users to one hostgroup in Icinga Web

So, say that you want to monitor your customers servers with a single icingainstallation, and you want to give the customer access to your icinga-web, but they should only see their own servers. This is how you do:

* Create a hostgroup / customer with the serves in
* Create a group in which you add the principal “icingahostgroups” and then you choose what hostgroup to limit to.
* Add the user to the group
* Make sure that the user don’t have the “Standard users group”, that’ll probably give them rights to see all hosts.

Done! Feel free to ask if you want to.

Icinga + Scheduled passive checks

Jag har funderat ett tag på hur man kan använda Icinga för övervakning av maskiner som inte står i samma nät som icingaservern, jag vill även uppnå det utan att öppna några brandväggsportar mer än nödvändigt. Lösningen jag har klurat på bygger på passiva checks och ett API samt ett schemalagt script för att exekvera scriptet. Jag ska se om jag kan snickra ihop något så återkommer jag!

Konfigurera Icinga för NRPE

I ett tidigare inlägg  skriver jag om hur man sätter upp NRPE på maskinerna, nu ska jag gå igenom hur man konfigurerar kontrollerna.

Först måste vi definiera att kommando för nrpe_check, detta gör vi i vår command.cfg enligt nedan.

define command{
command_name check_nrpe
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

Nu måste vi skapa en host som vi kan köra våra kontroller på, det gör vi i en fil som vi kallar för server02.cfg enligt nedan:

define host{
        use           linux-server                                                                    
        host_name     Server02
        alias         Server02
        address       192.168.0.1
        }

När vi har en Host uppsatt, så sätter vi upp en check som ska göras:

define service{
        use            local-service        
        host_name      Server02
        service_description  Current Load
        check_command  check_nrpe!check_load
}

Glöm inte att starta om/ ladda om konfigurationen i Icinga innan du försöker se om det funkar, kontrollen kommer nu att synas i webbgränssnittet som en vanlig check.
Anledningen till att vi kan skriva bara check_load och ändå få det att funka är att check_load redan är definierad med gränsväden i filen /usr/local/icinga/etc/nrpe.cfg på Server02

command[check_load]=/usr/local/icinga/libexec//check_load -w 15,10,5 -c 30,25,20

Av säkerhetsskäl så är det smartast att fördefiniera alla kontroller på maskinen som ska kunna utföra, då behöver man bara skicka minimalt med kommandon/inkommande data via nätverket och minskar därmed risken för att någon med illvilliga avsikter tar över din maskin. Det går att skicka med gränsvärden från icinga, men det rekomenderas inte om du kör övervakningen över nätet, kör du det i ditt interna nätverk så är det en mindre risk för intrång och kan vara ett smidigare sätt att justera sina gränsvärden.

Installera NRPE för Icinga

Eftersom Icinga är fullt bakåtkompatibelt med Nagios så kan man utan problem använda sig av nagiosplugins för att göra vissa manövrar, i mitt fall övervaka en annan server, en linux VPS. Den enda nackdelen med att använda en nagiosplugin är för att den har standardanvändare och grupper, men det går som tur är att definiera
själv när man kompilerar pluginen/add-on:en.

Det vi ska göra är att kompilera addonen och pluginen NRPE(http://nagios.sourceforge.net/docs/3_0/addons.html), notera att addonen NRPE har en plugin(check) som också heter NRPE, den heter i systemet check_nrpe men ingår i samma projekt.

NRPE är en demon som körs via xinet.d och används för att låta en Icinga/Nagios installation exekvera scripts på den aktuella maskinen, man måste dock komma ihåg att alla script som ska exekveras måste finnas på den aktuella maskinen.Jag har två stycker servrar jag vill blanda in, Server01 som håller icinga installationen och Server02 som jag vill övervaka, noteras ska att båda maskinerna är Debian Stable.

Förberedelser på båda maskinerna
Börja med att ladda ner de paket som krävs, du behöver:

* Openssl samt libssl-dev
* NRPE: http://www.nagios.org/download/addons
*Nagiosplugins: http://sourceforge.net/projects/nagiosplug/files/ (behövs bara på Server02)
*Xinetd(behövs bara på server02)

Det är möjligt att kompilera in vissa kontroller direkt i NRPE, men jag väljer att inte göra det.

 
Skapa användare och grupper
För att kunna köra NRPE och Nagiosplugin så måste vi skapa en användare och en grupp på maskinen, jag väljer att kalla dessa för ‘icinganrpe’, användaren icinganrpe ska vara medlem av gruppen icinganrpe.
Vi börjar med att installera de delar som krävs på Server02.

Konfigurera och installera Nagiosplugins
 
Packa upp det nerladdade arkivet och kör:

./configure --prefix=/usr/local/icinga --with-nagios-user=icinganrpe --with-nagios-group=icinganrpe
make && make install

–prefix anger i vilken katalog nagiosplugins ska installeras, jag väljer samma katalog som icinga ligger i på Server01.
–with-nagios-user anger vilken användare pluginen ska kompileras med.
–with-nagios-group samma som ovan fast för gruppen.

Konfigurera och installera NRPE
Packa upp det nerladdade arkivet och kör:

./configure --with-nagios-user=icinganrpe --with-nagios-group=icinganrpe --with-nrpe-user=icinganrpe --with-nrpe-group=icinganrpe --enable-ssl --libexecdir=/usr/local/icinga/libexec/ --bindir=/usr/local/icinga/bin/ --sysconfdir=/usr/local/icinga/etc
make all
make install
make install-daemon
make install-daemon-config
make install-plugin
make install-xinetd

–prefix anger i vilken katalog nagiosplugins ska installeras, jag väljer samma katalog som icinga ligger i på Server01.
–with-nagios-user anger vilken användare pluginen ska kompileras med.
–with-nagios-group samma som ovan fast för gruppen.
–with-nrpe-user samma som för nagios-user och group.
–with-nrpe-group samma som ovan.
–enable-ssl eftersom vi inte vill att maskinerna ska kommunicera med varandra i klartext så installerar vi NRPE med SSL påslaget, därav Openssl som krav.
–libexecdir anger vart nagiosplugins finns installerade.
–bindir anger vart binärfilen för NRPE ska installeras.
–sysconfdir anger vart konfigurationen för NRPE ska installeras. 

Anledningen till att det blir så många flaggor är för att nrpe och nagiosplugins som standard installeras i kataloger som heter *nagios* något, och det vill jag inte när jag ska använda det med Icinga.

Konfigurera Xinetd
xinetd är en “internet superserver” som används för att starta och köra demoner och servrar som inte har några egna PID, precis som svchost i windows. När vi ovan körde make install-xinetd så gjorde den i princip allt som vi behöver göra, dock så ska vi dubbelkolla att det blev rätt, börja med /etc/Xinetd.d/nrpe här har du en flagga som heter “Only from” som standard står det 127.0.0.1 där, låt det stå kvar tillsvidare, men senare ska vi ändra det till IP:t på Icinga maskinen.
Byt fil till /etc/services och lägg till i slutet på filen:

nrpe 5666/tcp #nrpe

Starta nu om xinetd, /etc/initd./xinetd restart. om allt har gått enligt plan så ska du nu ha en nrpe-demon körandes, för att kolla det kör:

netstat -at | grep nrpe
Det borde ge dig, gör det inte det prova starta om xinted.d igen, funkar inte det kolla syslog efter felmeddelanden.

tcp        0      0 *:nrpe                  *:*                     LISTEN

För att testa om nrpe funkar,  anslut till NRPE demonen med check_nrpe:

/usr/local/icinga/libexec/check_nrpe -H localhost

Det borde ge dig något liknande:
NRPE v2.8

Konfigurera Server01 för NRPE

Ladda ner källkodspaketet för NRPE på maskinen som kör Icinga, anpassa ./configure för att använda samma användare som icinga(i mitt fall ‘icinga’).

./configure --with-nagios-user=icinganrpe --with-nagios-group=icinga --with-nrpe-user=icinga --with-nrpe-group=icinga --enable-ssl --libexecdir=/usr/local/icinga/libexec/ --bindir=/usr/local/icinga/bin/ --sysconfdir=/usr/local/icinga/etc
make all
make install-plugin

Skillnaden mot att installera på Server02 är att vi inte är intresserade av demonen utan bara pluginen, för att testa NRPE, ändra “Only From” i /etc/xinetd.d/nrpe och kör sedan samma kommando igen:

/usr/local/icinga/libexec/check_nrpe -H Server02

Det borde ge dig något liknande:
NRPE v2.8

Glöm om inte att byta ut Server02 mitt din servers IP! Om du får rätt svar så fungerar det, om den klagar på SSL, se till att du har openssl installerat och att det är samma version på båda maskinerna.

Nu är du klar med att installera NRPE på din maskiner, nu är nästa steg att konfigurera Icinga.
Läs mer om att konfa icinga med NRPE: http://abergmanse.wordpress.com/2010/05/06/konfigurera-icinga-for-nrpe/

Kontrollera Vhostar och Redirects med Icinga

Vi har en webbserver med ett antal vhostar som vi vill övervaka, dock så kommer standardkonfigurationen till Icinga med en servicecheck som kontrollerar HTTP med hjälp av IP:t, så för att få den att kontrollera det jag vill så skriver jag om service checken till:

check_http -H $HOSTADRESS$

Det gör att check_http tar emot www.test.se istället för bara en ip, nu vill jag också kolla så att jag får den HTTP-status jag förväntar mig, detta då check_http tycker att både 200 och 301 är OK, men efter som min site inte ska redirecta(301) så vill jag att den bara ska tycka att 200 är ok, det åstadkommer jag med:

check_http -H $HOSTADDRESS$ -e 200

Där -e betyder “expect”, alltså förväntar sig checken HTTP-status 200. För att hålla koll på mina redirects så använder jag samma kontroll fast med 301 istället för 200.

För att underlätta för mig själv har jag definierat upp ett nytt kommando som heter just HTTP-redir och som bara accepterar 301 som http-status, sedan styr jag med hostgroups vilken sida som kontrolleras på vilket sätt.

Såhär ser det ut på en maskin som både har en HTTP-adress och en HTTP-redir:

Passiva service checks med Icinga/Nagios

Jag vill veta hur mina cronjobb går, om de går igenom eller om de failar någonstans längs vägen. För att samla ihop det med Icinga så väljer jag att skriva om mina cronjobb script så att de beroende på exit-code kör ett annat script som lägger in informationen i Icinga.

Den första delen i det är att skapa en service som du kan använda för att ta emot passive service checks, det kan vara en helt vanlig service, men den skillanden att du lägger till “active_checks_enabled 0″ i definitionen. Så den ser ut såhär:

define service{
use local-service
service_description Cron Jobs
host_name localhost-test
check_command check_mailq!10!20
active_checks_enabled 0
}

Notera att det finns ett check command i defintionen, men det kommer inte att köras pga “active_checks_enabled 0″, det måste bara vara där för sakens skull. Glöm inte att knyta check:en till en host också!

I nagios egen dokumentation finns ett litet bash-script för att skicka commandon till .cmd-filen, du hittar det här: http://nagios.sourceforge.net/docs/3_0/volatileservices.html
För att exekvera scriptet sedan så kör du bara:

# ./submit_passive_check.sh localhost-test 'Cron Jobs' 0 'Cron has run!'

Där du byter ut “localhost-test” till ditt eget hostnamn, siffran i mitten är exitcode och severitycode i Icinga, 0= OK 1= Warning 2= Critical och 3 är Unknown. Lek med det lite själv och se hur det går! Lycka till!

Övervaka mailkön på din linuxserver

Jag stötte på ett problem med att postfix av någon anledning hade hängt sig på en av våra hostingservrar, det resulterade i att en massa mail inte gick iväg(typ 500st låg i kön), detta drabbade alla siter som ligger hostade på den maskinen, så det är viktigt att det inte händer igen. Som tur var så räckte det med att starta om postfix för att få mailen att flöda igen.

Vi övervakar våra siter och maskiner med icinga som är en fork av nagios, det gör att man lika gärna kan använda nagiosplugins till icinga.
Pluginpaketet “Nagiosplugins” (http://nagiosplugins.org/) innehåller ett script för check av mailq som standard, vilket jag såklart använde!

Jag skapade ett nytt ‘command’ i min commands.cfg:

define command{
        command_name    check_mailq
        command_line    $USER1$/check_mailq -w $ARG1$ -c $ARG2$
        }

Där -w är gränsen för Warning och -c är gränsen för critical $ARG1$ och $ARG2$ är placeholders för argument som specificeras när kommandot anropas. För att kunna använda mitt kommando så la jag in det direkt på hosten, eftersom det bara är den maskinen jag vill köra den kontrollen på.

define service{
        host_name                       localhost
        service_description             Check Mailq
        check_command                   check_mailq!10!20
}

Som ni ser så anger jag 10 mail i kö som warning gränsen och 20 mail i kö som critical, om det är så att det blir för många falsklarm så får jag justera det senare. Så här ser det sedan ut i Icinga WebUI:
Icinga Mailq Check

Den här bloggen

skriver jag, Andreas Bergman, vilket i sig inte bör vara så förvånande. Jag driver en SMS tjänst och jobbar som tekniker/allt i allo på SEA där jag bland annat driftar en stor bloggportal och ett webbhotell. Vi håller även på att bygga ett datacenter.


Jag har några microsoft titlar, ett gäng DELL certifikat och jobbar dagligen med hårt belastade webbservrar. Utöver det jobbar jag också med virtualisering och server/storage. Någon gång ibland säljer jag även server och storagelösningar.

Maila mig gärna om något av ovan, eller annat, jag är ganska trevlig sägs det. andreas@abergman.se.