Softwareconflicten zijn een nachtmerrie voor systeembeheerders en programmeurs. De installatie en het updaten van software mislukt vaak vanwege conflicten met andere applicaties. Het terugdraaien van een update gaat zelden probleemloos. Promovendus Eelco Dolstra van de Universiteit van Utrecht heeft de methodiek van software deployment bestudeerd en heeft een beter alternatief.
Tijdens zijn functie van assistent-in-opleiding is Dolstra verbonden aan het project TraCE van de Universiteit van Utrecht, dat het doel heeft software engineering te verbeteren. "Je kunt componenten op verschillende manieren bouwen, maar er is geen duidelijke standaardmethodiek voor. Eén softwarecomponent bestaat meestal uit verschillende bronbestanden. Deze worden op een hoger niveau samengevoegd, maar daar zijn geen goede hulpmiddelen voor. In de Linux-wereld kom je dan snel terecht bij package-management tools als RPM (Linux) en in een Windows-omgeving worden tools als Installshield gebruikt. Hulpmiddelen als RPM automatiseren de bestaande praktijk. Hiermee wordt bepaald waar bestanden tijdens de installatie worden opgeslagen; bij Linux vaak bij elkaar in een directory zoals /usr/bin, en bij Windows gedeeltelijk in een map zoals C:WindowsSystem32, samen met andere DLL's (dynamic link libraries). Software onder Linux gaat er bovendien vaak vanuit dat andere componenten reeds aanwezig zijn. Dat maakt het moeilijk om software te testen", aldus Dolstra.
RPM automatiseert dat proces voor een deel, doordat er een database bijgehouden wordt van welke bestanden bij welke applicatie horen. In die zin gaat RPM al verder dan Windows, aldus Dolstra. Maar wat de RPM-methodiek niet mogelijk maakt is het draaien van verschillende versies naast elkaar, wat een uitkomst is voor testdoeleinden. Bovendien kan het zo zijn dat wanneer een bepaalde component geüpgradet wordt, een andere applicatie die daar mede van afhankelijk is niet meer correct functioneert. "Een hulpmiddel als RPM kan daar niet goed mee omgaan", vult Dolstra aan. "Het is in feite een geautomatiseerd laagje bovenop een aanpak die fundamenteel niet deugt."
Methodologie
Het alternatieve voorstel van Dolstra, Nix gedoopt, is een puur functioneel software deployment model. Nix beheert het installatieproces, de distributie en het management van softwarecomponenten. In zijn proefschrift, ‘The Purely Functional Software Deployment Model', betitelt hij de Nix-methode als een betere techniek om software uit te rollen. "Het probleem is een gebrek aan isolatie tussen de componenten, en het feit dat het lastig is om afhankelijkheden tussen componenten correct te identificeren", schrijft hij in de samenvatting van zijn proefschrift. Omdat, in tegenstelling tot de Windows-wereld, er onder Linux en Unix vaak uit wordt gegaan van de aanwezigheid van bepaalde bestanden (of softwarecomponenten), kan software deployment mislukken doordat een component afwezig is, aanwezig is in een incompatibele versie of met verkeerde compilerinstellingen gebouwd is. Terwijl Linux-distributies zich voornamelijk van elkaar onderscheiden door hun verschillende package-managementsystemen (RPM, Debian APT, Gentoo Portage, etc.), zijn ze geen van alle in staat om afhankelijkheidsspecificaties af te dwingen en de aanwezigheid van meerdere versies van componenten te ondersteunen. Dolstra stelt vast dat er relatief weinig onderzoek is gedaan naar deployment en de manier van opslaan van componenten in het bestandssysteem. Met NIX is daar verandering in gekomen.
Het Nix deployment-principe
Nix is een package-management systeem zoals RPM en is dan ook relatief eenvoudig te gebruiken in bestaande (Linux) besturingssystemen. Het systeem slaat componenten in isolatie van elkaar op in de zogenaamde ‘Nix store', een speciale directory in het bestandssysteem. De verschillende paden worden aangemaakt op basis van cryptografische hash-codes, een soort digitale handtekening. Deze is gebaseerd op de invoer die heeft bijgedragen aan het bouwen van een component. Als er ook maar iets verschilt tussen twee versies van componenten, ontstaat een andere hash-code en wordt het apart in het bestandssysteem opgeslagen. Dolstra: "Daardoor is interferentie uitgesloten. Bovendien is het eenvoudig om een installatie ongedaan te maken, ongeacht of het een update of een nieuw programma betreft. NIX geeft daarnaast inzicht welke afhankelijkheden er zijn tussen componenten. Iemand die een softwarepakket wil distribueren kan daardoor direct zien van welke versies de software afhankelijk is en er voor kiezen deze mee te leveren of op een andere manier beschikbaar te stellen." Net zoals een RPM is het relatief eenvoudig om bestaande software aan te bieden als Nix-installatie. Er moet alleen een zogeheten Nix-expressie geschreven worden, waarin het bouwproces beschreven staat (welke bestanden er zijn, wat de broncode is, hoe het geheel gebouwd moet worden). Aangezien veel Linux-software open source is, zou iedereen dat kunnen doen.
Een ander unicum is de mogelijkheid voor service deployment. Het uitrollen van draaiende netwerkdiensten, zoals een webserver, is een tijdrovend proces, omdat veel acties handmatig moeten worden uitgevoerd en daardoor niet reproduceerbaar zijn. Met NIX kunnen de statische delen van een dienst (de software en de configuratiebestanden) als een Nix-component behandeld worden. Hiervoor moet een Nix-expressie gebouwd worden, waardoor meerdere versies naast elkaar gebruikt kunnen worden, het geheel reproduceerbaar is en rollbacks mogelijk zijn. Alleen het dynamische deel, zoals een database, valt niet onder het Nix-beheer.
Ambities
De methodologie heeft potentie. Het is dan ook de vraag welke ambities Dolstra heeft met het project. Zou het niet mooi zijn als Nix wordt opgenomen door bekende Linux-distributies? "Het is in eerste instantie een research-project", reageert Dolstra bescheiden. "Nix moet zich eerst nog echt bewijzen. De methodologie is toch tamelijk ingrijpend omdat het de manier waarop software geïnstalleerd wordt verandert." Daarnaast is het de vraag of Nix ook een toegevoegde waarde heeft op het Windows-platform, getuige de herkomst van het woord DLL-hel. Dolstra: "Technisch zijn er geen bezwaren voor het gebruik van Nix. Door de omslachtige interactieve installatieprocedures onder Windows en de relatief beperkte beschikbaarheid van open source software zie ik dat echter niet snel gebeuren. Nix is weliswaar een betere oplossing in mijn ogen, maar Microsoft lijkt met .Net op de goede weg te zijn."
Meer infeo op www.cs.uu.nl/wiki/Trace/Nix
