Packagemanagers – Werken met software op Linux

Op het eerste gezicht lijkt het werken met software pakketten op Linux nogal ondoorzichtig. Bij nader inzien gaat het echter om functionaliteit die uitermate goed doordacht is. In dit artikel lees je hoe software management op Linux georganiseerd is. 

Ook al zijn er heel veel verschillende Linux distributies, er zijn eigenlijk maar twee systemen voor package management: RPM en DPKG. Qua architectuur lijken deze oplossingen erg veel op elkaar, we gooien daarom in dit artikel beiden op een hoop om te kijken van welke ontwerpprincipes gebruik gemaakt wordt. Nadat bekeken is hoe packages zich verhouden tot eenvoudige archiefbestanden, lees je hoe meta package handlers het werken met packages eenvoudiger maken.  

Van archiefbestanden tot repositories
In de beginjaren van Linux was het beheer van packages eenvoudig geregeld: er was geen beheer van packages. Wel waren er archiefbestanden, vaak in de vorm van een tarball (letterlijk: een teerbal, dit is een soort zip bestand dat met het archiveringsprogramma tar gemaakt is en vervolgens is gecomprimeerd). 

Installatie van software was in de tijd van de tarball eenvoudig geregeld: je pakt eerst het archiefbestand uit en vervolgens kijk je wat er in zit. Op basis van die inhoud ga je dan verder. Kenmerken voor deze manier van aanpak is dat de intelligentie over waar software terecht komt in het archief zit, en niet in het besturingssysteem. Dat betekent dat je de ene keer de kans hebt source bestanden uit te moeten pakken en vervolgens te compileren, een volgende keer een kant en klaar programmabestand krijgt dat je ergens naar toe moet kopiëren, en weer een andere keer een grote hoeveelheid bestanden op de juiste plaats moet zetten door een script te activeren.

Naast het kenmerk dat je met een tarball nooit weet wat je krijgt, is er nog een belangrijk kenmerk. Vanuit het besturingssysteem is het niet mogelijk te achterhalen waar bepaalde bestanden vandaan komen. Dat betekent dat het besturingssysteem ook feitelijk buiten spel staat voor wat het betreft het upgraden van software. Desalniettemin had het werken met tarballs ook een voordeel (en om die reden kom je ze nog steeds af en toe tegen). Elke Linux is in staat om tar archieven uit te pakken en dat betekent dat de maker van de software zich maar op één distributiemethode hoeft te richten. 

RPM en DKPG
Al vrij vroeg kwam er een beter alternatief voor tarballs: het PRM of DPKG package formaat. RPM (Red Hat Package Manager) is ontworpen door Red Hat en wordt niet alleen op Red Hat gebruikt, maar ook op afgeleide distributies zoals SUSE. DPKG staat voor Debian Package en zoals de naam al doet vermoeden is dit een formaat dat in Debian kringen ontwikkeld is. Kenmerkend voor dit package formaat is dat ze bestaan uit een archiefbestand met metadata. In deze metadata kan heel veel informatie opgenomen worden over het package, waardoor het een stuk eenvoudiger wordt om het package in kwestie niet alleen te installeren, maar ook te beheren (denk met name aan upgrades). In afbeelding 1 zie je het resultaat van de opdracht rpm –qi httpd, een commando waarmee op Red Hat de metadata van het httpd package getoond worden. 

Weergeven van metadata uit een RPM package

 

Naast de metadata in het package die gebruikt wordt tijdens de installatie van het package, kunnen ook andere zaken opgenomen worden. Een andere belangrijke vernieuwing zijn de pre- en post-installatiescripts. Door gebruik te maken van deze scripts, kunnen tijdens de installatie ook bepaalde acties uitgevoerd worden. Een derde vorm van vooruitgang is dat in packages bestanden doorgaans gearchiveerd zijn op de manier zoals ze ook op het besturingssysteem geïnstalleerd moeten worden. Al deze veranderingen maken het mogelijk dat vanuit het besturingssysteem packages op een uniforme wijze geïnstalleerd worden. 

Het gebruik van intelligente packages biedt echter meer voordeel dan alleen de mogelijkheid op een eenvoudiger en uniformere wijze software te installeren. Wat er allemaal geïnstalleerd is wordt ook nog eens netjes bijgehouden in een database. Op basis van de informatie uit die database is het eenvoudig om beheerstaken uit te voeren zoals het upgraden van packages, of het verwijderen van software. root

Packages bieden echter niet alleen maar voordelen. Met de opkomst van packages deed ook een nadeel haar entree: de dependency. Heel veel programma’s maken gebruik van onderdelen die elders vandaan komen. Denk hierbij met name aan libraries. Deze afhankelijkheidsrelaties worden aangeduid als dependencies. Hierbij is het helemaal niet uitzonderlijk dat om een package te kunnen installeren, je eerst tientallen dependencies moet installeren. Als die dependencies dan ook nog allemaal stuk voor stuk van internet gedownload moeten worden, wordt het beheer van packages al snel heel erg vervelend. Het is niet voor niets dat dit probleem al snel aangeduid werd als ‘dependency hell’. In listing 1 kun je zien hoe dependency hell er uit kan zien.

Listing 1

Dependency hell maakt het werken met packages soms knap vervelend <start code>

[root@tls repo]# rpm -ivh wvdial-1.60-12.el6.x86_64.rpm 

warning: wvdial-1.60-12.el6.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY

error: Failed dependencies:

libuniconf.so.4.6()(64bit) is needed by wvdial-1.60-12.el6.x86_64

libwvbase.so.4.6()(64bit) is needed by wvdial-1.60-12.el6.x86_64

libwvstreams.so.4.6()(64bit) is needed by wvdial-1.60-12.el6.x86_64

libwvutils.so.4.6()(64bit) is needed by wvdial-1.60-12.el6.x86_64

 

 

Meta Package Handlers
Omdat dependency hell het werken met packages heel vervelend maakte, werd ook voor dat probleem een oplossing gezocht: de meta package handler. Kenmerkend voor meta package handlers is het gebruik van repositories. Een repository is letterlijk een pakhuis, een geïndexeerd archief van packages. Het handige van gebruik van meta package handlers is dat dat archief gebruikt kan worden bij het installeren van packages. Bekende meta package handlers zijn apt-get (Debian en afgeleiden), yum (Red Hat en afgeleiden) en zypper (SUSE).

Bij het werken met meta package handlers zijn er twee onderdelen nodig. Als eerste is dat de repository zelf. Deze wordt vaak beschikbaar gesteld door de distributie zelf, maar het is ook mogelijk om zelf repositories aan te maken. Daarnaast is er de gebruiker van de repository, die indexen bijhoudt van software die in de repositories beschikbaar is.  

 

One click install
Op basis van repositories kunnen systemen aangeboden worden zoals SUSE’s One Click Install. Als je naar software.opensuse.org gaat en daar vandaan software installeert, kun je dat met één klik doen. Het systeem dat op de achtergrond gebruikt wordt, zorgt ervoor dat eerst een verwijzing aangemaakt wordt naar de nieuwe repository, waarna het package geïnstalleerd kan worden.

One click install maakt werken met repositories transparant

 

Doordat bij het werken met repositories indexen bijgehouden worden, kon het dependency probleem opgelost worden. Als nu namelijk bij de installatie van software achterhaald wordt dat een dependency vereist is, kan deze op de achtergrond gedownload worden zonder dat enige input van de gebruiker nodig is. Dit betekent dat je voor een zo goed mogelijke gebruikerservaring er naar zou kunnen streven zo veel mogelijk repositories te verzamelen, zodat software altijd transparant geïnstalleerd kan worden. 

Het werken met repositories maakt het heel veel eenvoudiger om op Linux software te installeren en beheren. Met deze nieuwe werkwijze deden echter ook een paar nieuwe problemen hun entree. Als eerste is dat het downloaden van indexbestanden. Om steeds toegang te hebben tot de laatste wijzigingen in de repositories, is het zaak dat de gebruikers ervan periodiek de bijbehorende indexbestanden downloaden. Omdat sommige repositories tienduizenden bestanden bevatten, kan het enige tijd duren voordat deze indexbestanden allemaal opgehaald zijn. Daarnaast is het werken met repositories dusdanig eenvoudig geworden dat er een serieus beveiligingsprobleem haar entree doet. 

Het Linux alternatief voor virussen?
Vanuit de optiek van de gebruiker is het wenselijk zo eenvoudig mogelijk software te installeren. Dat betekent dat One Click Install en aanverwante technieken een zegen zijn. Er wordt niets meer gevraagd en je kunt op een heel eenvoudige manier nieuwe software installeren. 

Om echter nieuwe software te installeren, moet je gebruikmaken van root privileges. Tel dat op bij het gegeven dat in packages installatiescripts opgenomen kunnen worden,  dan kom je er op uit dat het op Linux dus vrij eenvoudig is om extraatjes in de packages te verstoppen en zo bijvoorbeeld een leuke rootkit te installeren, of de target computer mee te laten werken in een gezellig botnet. Dit is een serieus probleem waar je zeker in professionele omgevingen heel goed over na moet denken hoe je het op wilt lossen.

Een van de dingen die je zou kunnen doen voordat je packages gaat installeren, is ze te onderzoeken op de aanwezigheid van scripts. Als je RPM gebruikt, doe je dit met de opdracht rpm –qp –scripts packagenaam (zie listing 2).

Listing 2

[root@tls repo]# rpm -qp –scripts httpd-2.2.15-15.el6_2.1.x86_64.rpm 

warning: httpd-2.2.15-15.el6_2.1.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY

preinstall scriptlet (using /bin/sh):

# Add the “apache” user

getent group apache >/dev/null || groupadd -g 48 -r apache

getent passwd apache >/dev/null || \

  useradd -r -u 48 -g apache -s /sbin/nologin \

    -d /var/www -c “Apache” apache

exit 0

postinstall scriptlet (using /bin/sh):

# Register the httpd service

/sbin/chkconfig –add httpd

preuninstall scriptlet (using /bin/sh):

if [ $1 = 0 ]; then

/sbin/service httpd stop > /dev/null 2>&1

/sbin/chkconfig –del httpd

fi

posttrans scriptlet (using /bin/sh):

/sbin/service httpd condrestart >/dev/null 2>&1 || :

 

Nu is het mooi dat je packages kunt onderzoeken op scripts voordat je ze installeert, maar er is wel een praktisch nadeel. Om een package te kunnen onderzoeken op de aanwezigheid van scripts, heb je in elk geval bij RPM toegang tot het package nodig. Hierdoor wordt het gemak van het werken met repositories voor een groot deel teniet gedaan. Om die reden wordt deze oplossing alleen gebruikt in omgevingen waar beveiliging de hoogste prioriteit is. 

Een andere manier om ervoor te zorgen dat de pacakges die geïnstalleerd worden betrouwbaar zijn, is gebruik te maken van GPG signatures. Dit is iets wat de maker van de repository moet doen. De werking hiervan is niet moeilijk te begrijpen: elk package is voorzien van een signature die door de repository gemaakt is met de private key van de repository. Op het moment dat een package uit een nieuwe repository gedownload wordt, wordt als eerste de public key van die repository geïmporteerd. Deze public key wordt lokaal op de computer van de gebruiker opgeslagen en de volgende keer dat er weer software geïnstalleerd wordt uit deze repository, wordt deze automatisch gecontroleerd op basis van de public key. Als het package onveranderd is, geeft het aan dat het package onveranderd is sinds het door de eigenaar van de repository daarin gezet is. Is het package gewijzigd door een derde partij (een hacker bijvoorbeeld), dan klopt de signature niet meer en krijgt de gebruiker een waarschuwing als hij het package wil installeren. 

Het werken met signatures voor packages biedt een redelijke bescherming, maar ook hieraan kleeft een nadeel. GPG signatures werken voor repositories van vertrouwde partijen. Als je  werkt met de Red Hat repositories, kun je er op vertrouwen dat Red Hat er alles aan doet de integriteit van de packages te garanderen. Zouden ze dat niet doen, dan zou dat namelijk tot vervelende rechtszaken en hoge claims kunnen leiden. Het wordt al een klein beetje anders als je werkt met een open source distributie. Open Source distributies hebben een goede reputatie op te houden, maar zeker bij de bleeding edge distributies is de controle niet zo grondig als bij een partij als Red Hat (dat is dan ook precies waarom bedrijven betalen voor een enterprise Linux distributie zoals Red Hat). 

Nog heel anders wordt het als je software downloadt van een wazige site uit Oostenrijk, waaruit je allerhande zaken eenvoudig kunt installeren die om legale redenen niet in een distributie meegeleverd mogen worden. Het feit dat zo’n site ook gebruik maakt van GPG signatures garandeert namelijk alleen maar dat het package niet gewijzigd is sinds het in de repository geplaatst is. Het geeft geen enkele garantie over de inhoud van het package. Dit is een probleem waar ook maar weinig aan gedaan kan worden, behalve dan dat je als gebruiker heel goed moet letten op de betrouwbaarheid van software die je installeert. 

 

Zoek de verschillen
Op het eerste gezicht lijkt het werken met meta package handlers tussen verschillende Linux distributies vervelend. Iedere distributie lijkt zijn eigen oplossing verzonnen te hebben en ze werken allemaal anders! Als je ze iets beter bekijkt, kom je er achter dat de verschillen helemaal niet zo groot zijn. Of het nu yum, zypper of apt-get is, je installeert een package gewoon met naam-van-je-package-handler install packagenaam. Ook overige beheerscommando’s lijken veel op elkaar en daar waar er verschillen zijn, helpen de man pagina’s je verder.

Alles vinden met Queries
Het werken met packages maakt het niet alleen eenvoudiger om software te beheren, het wordt ook een stuk eenvoudiger om dingen terug te vinden op je computer. Op basis van de juiste queries vindt je eenvoudig alle relevante onderdelen en de man pagina’s doen de rest! Laten we eens kijken naar een geval waar iedere Linux gebruiker vroeger of later tegenaan loopt. Je moet iets configureren maar je hebt geen idee hoe! Het enige dat je weet is de naam van het programmabestand in kwestie. In onderstaande procedure lees je hoe je voor een willekeurig programmabestand alles op je systeem vindt dat nodig is om het verder in te richten. Als voorbeeld kijken we naar de NTP service. 

1.Als je niet weet hoe het betreffende programmabestand heet, begin je met whereis. Je kunt natuurlijk ook andere commando’s gebruiken. In het geval ntp zou je dus de opdracht whereis ntpd kunnen typen. Als antwoord krijg je de naam en pad van het betreffende programma te zien (en nog veel meer- maar daar gaat het hier even niet om).

 

[root@tls repo]# whereis ntpd

ntpd: /usr/sbin/ntpd /usr/share/man/man8/ntpd.8.gz

 

2.Op basis van whereis weten we nu dat het pogrammabestand /usr/sbin/ntpd heet. Nu heb je de naam van het bijbehorende RPM package nodig. Die vindt je met de opdracht rpm –qf /usr/sbin/ntpd.

 

[root@tls repo]# rpm -qf /usr/sbin/ntpd

ntp-4.2.4p8-2.el6.x86_64

 

3.Je hebt nu de volledige naam van het RPM package, inclusief versienummer en platform. Versienummer en platform zijn in dit geval niet belangrijk, alleen het eerste deel heb je nodig om verdere queries te doen. Een hele handige query is rpm –qc ntp; de optie –qc laat de configuratiebestanden zien die in de RPM zitten. Je weet nu in elk geval welke bestanden je nodig hebt om de service verder te configureren.

 

[root@tls repo]# rpm -qc ntp

/etc/ntp.conf

/etc/ntp/crypto/pw

/etc/sysconfig/ntpd

 

4.Heb je aan de naam van de configuratiebestanden niet genoeg? Geen probleem, dan kun je vervolgens opvragen wat er allemaal aan documentatie beschikbaar is met de opdracht rpm –qd ntp:

 

[root@tls repo]# rpm -qd ntp

/usr/share/doc/ntp-4.2.4p8/COPYRIGHT

/usr/share/doc/ntp-4.2.4p8/ChangeLog

/usr/share/doc/ntp-4.2.4p8/NEWS

/usr/share/man/man5/ntp.conf.5.gz

/usr/share/man/man5/ntp_acc.5.gz

…

 

Van Meta Package Handlers naar AppStores?
Zoals je gelezen hebt, kun je op basis van Meta Package Handlers op een heel behoorlijke manier software beheren. De ontwikkelingen staan echter niet stil en in de huidige generatie besturingssystemen hoor je er pas echt bij als je ook een AppStore hebt. De eerste distributies zijn al met dergelijke oplossingen gekomen, zo kun je vanuit de Ubuntu Software Center heel eenvoudig software opzoeken en installeren, waarbij je naast open source software ook gelijkwaardige commerciële software kunt installeren. Dit initiatief is niet door iedereen in de Linux community met veel enthousiasme ontvangen, of het wat gaat worden? De tijd zal het leren.