Werken met Systemd

Eerder dit jaar heb je reeds kunnen lezen over de basiswerking van systemd. In dat artikel heb je geleerd hoe systemd zorgdraagt voor het starten van services en daarnaast ook mounts voor zijn rekening kan nemen. In dit artikel gaan we kijken naar de echt leuke dingen die je met systemd kunt doen.

 De hoeveelheid zaken die systemd voor zijn rekening neemt, wekt soms irritatie op bij ontwikkelaar als beheerders. Het lijkt er soms op dat systemd de ambitie heeft om zich te ontwikkelen tot een eigen besturingssysteem. Volgens de ontwikkelaars is dat ook zo. Het doel van systemd is om een besturingssysteem te bouwen bovenop de Linux kernel. Vanuit die optiek wordt het dan ook volkomen duidelijk dat systemd zaken voor zijn rekening neemt die je niet direct verwacht. In dit artikel kijken we naar drie van dit soort dingen.

 Om te beginnen bespreken we hoe je met systemd sockets kunt werken om services te starten op basis van activiteit op een specifieke socket. Vervolgens leer je hoe je cgroup informatie kunt omvatten in een systemd unit file, om er zo voor te zorgen dat de systemd unit toegang heeft tot een specifiek gedefinieerde hoeveelheid resources. Als laatste lees je hoe je met systemd Linux containers aan kunt maken.

 Sockets

 Op de meeste Linux servers staan processen te luisteren naar verkeer dat binnen komt op specifieke poorten. De systemd socket draait dit om en zorgt ervoor dat een proces gestart wordt als er op een bepaalde poort verkeer binnen komt. Door gebruik te maken van sockets zorg je ervoor dat je systeem echt event driven wordt en dat geen zaken geladen worden die je niet nodig hebt. Dat is misschien niet al te nuttig op een Linux server, maar op een Linux desktop kun je hier zeker veel baat bij hebben.

 Configuratie van een systemd socket is niet moeilijk. De configuratie gaat er van uit dat het eerste deel van de naam van de socket gelijk is aan het eerste deel van de naam van de service. Dus als je een socket wilt maken voor sshd.service, dan heet die socket sshd.socket. De inhoud van de unit file ziet er dan als volgt uit:

 ***************************start listing************************

  [Unit]

 Description=OpenSSH Server Socket

 Conflicts=sshd.service

 [Socket]

 ListenStream=22

 Accept=yes

  [Install]

 WantedBy=sockets.target

  ***************************eind listing************************

  Om te beginnen zie je een Conflicts regel, deze geeft aan dat sshd.socket niet tegelijk actief kan zijn met sshd.service. Dat is ook logisch, want de socket zorgt er juist voor dat de service gestart wordt. Vervolgens wordt onder [Socket] aangegeven waar de socket moet luisteren. ListenStream geeft aan dat het TCP is en het poortnummer is 22. Tot slot wordt een want gedefinieerd voor deze socket in sockets.target, een target die automatisch bij het opstarten geactiveerd wordt. Rest enkel nog de socket te activeren. Dat doe je door achtereenvolgens de volgende commando’s te gebruiken:

***************************start listing************************

 systemctl stop sshd

 systemctl disable sshd

 systemctl enable sshd.socket

 systemctl start sshd.socket

  ***************************eind listing************************

 Cgroups

 In een systemd unit file kun je heel veel parameters opnemen om te bepalen hoeveel resources gebruikt kunnen worden. Het gaat hier om de zogenaamde cgroups parameters, een hoeveelheid instellingen die een afzonderlijk artikel meer dan waard is. Om een overzicht te krijgen van de beschikbare parameters voor een Unit file, gebruik je het systemctl show commando. In afbeelding 1 zie je welk type parameters door dit commando getoond wordt.

  Gebruik systemctl show unitfile voor een totaaloverzicht van alle beschikbare parameters

  Een van de parameters is bijvoorbeeld Nice=0, waarmee de standaard nice waarde op 0 gezet wordt. Wil je dat jouw proces met een aangepaste nice waarde gestart wordt? Dan kan je dat hier regelen. Zorg ervoor dat in het [Service] deel van de Unit file bijvoorbeeld Nice=-5 komt te staan om dit proces standaard met een hoger nice waarde te activeren.

  Dit is maar een simpel voorbeeld van hoe je in systemd unit files ervoor zorgt dat performance gerelateerde instellingen geregeld worden. Blader eens door de lijst van instellingen om een beeld te krijgen van wat allemaal mogelijk is.

  Containers

 Hét hype woord van dit moment in Linux omgevingen is ‘Container’. Een container is een omgeving waar binnen een applicatie gestart kan worden en waarbij een beperkte set resources aan de applicatie toegewezen kan worden. Een container is eigenlijk ook een veredelde vorm van een chroot jail en dat is ook iets wat je prima met systemd kunt regelen.

  Het mooie van containers in systemd is dat het echt heel eenvoudig is ze aan te maken. Laten we eerst eens kijken welke commando’s nodig zijn: (deze procedure is geverifieerd op CentOS 7.1)

***************************start listing************************

  mkdir /var/lib/container

 Setenforce Permissive

 Yum -y –releaseserver=7Server –installroot=/var/lib/container/centos7 install systemd passwd yum redhat-release vim-minimal

 systemd-nspawn -D /var/lib/container/centos7 passwd; systemctl disable kdump postfix firewalld tuned

 systemd-nspawn -D /var/lib/container/centos7 -b

  ***************************eind listing************************

  Om te beginnen moet je een root directory aanmaken voor je container omgeving. De directory /var/lib/container is een voor de hand liggende locatie, maar het staat je vrij daar van af te wijken. Als tweede stap is het aan te raden SELinux tijdelijk even op Permissive mode te zetten. Het is natuurlijk stoer als je in Enforcing mode kunt blijven, maar dan is een flink aantal extra stappen nodig. Om deze procedure overzichtelijk te houden, gaan we daarom even uit van Permissive mode.

  Dan begint in commando 3 het inrichten van de container omgeving. Het yum commando zorgt ervoor dat de installatie-root aangemaakt wordt in /var/lib/container/centos7 en installeert een minimaal aantal packages. Houdt er rekening mee dat desalniettemin de nodige dependencies meegenomen moeten worden, zodat je toch wel rond de 350MB uit komt.

  In principe is je container nu klaar. Voordat je hem echter kunt gaan gebruiken, moet je ervoor zorgen dat het wachtwoord wordt ingesteld. Daarnaast is aan te raden gelijk een paar services uit te zetten die je toch niet nodig hebt. In het vierde commando wordt systemd-nspawn aangeroepen, met als eerste argument het passwd commando. Dit start de container, roept passwd aan zodat je het root wachtwoord voor de container in kunt stellen en zet vervolgens in systemd een aantal onnodige services uit. Als dit gebeurd is, kom je weer terug in de root van het host besturingssysteem. Je container is nu klaar en door systemd-nspawn nogmaals aan te roepen met de optie -b kun je erin opstarten.

  Je zult merken dat in minder dan één seconde de login prompt van de container voor je klaar staat en je aan het werk kunt in je eigen geminimaliseerde omgeving. Wil je weten hoe lang het precies geduurd heeft? Type dan systemd-analyze en je ziet precies hoe lang nodig om was de huidige omgeving te starten.

  In dit artikel heb je gelezen hoeveel er mogelijk is met systemd. En dit is nog niet eens alles! Momenteel wordt bijvoorbeeld hard gewerkt aan systemd-networkd, een oplossing die ervoor zou moeten zorgen dat er nu eindelijk eens uniformiteit komt op het gebied van netwerkbeheer in Linux. Waar het allemaal zal eindigen? Niemand die het echt weet, maar de toekomst zal het ons gaan leren.