Die keer dat ik de server opnieuw installeerde

Straks vers het nieuwe jaar in

Na een heleboel peinzen en plannen is nu eindelijk het grootste deel van het werk gebeurd, en snort mijn thuisserver niet meer op een fork van CentOS, maar op een eigen installatie van OpenSUSE Leap 15.2. Er zijn nog genoeg kleine dingetjes af te maken, maar de belangrijkste dingen - bestanden, websites, e-mail - draaien allemaal weer. Poeh.

Die overgang zat echt al een hele tijd in de lucht, maar zoals dat bij mij wel vaker gaat, moest er eerst nog uitgebreid gewikt en nog uitgebreider gewogen worden. Hoe ga ik het aanpakken (met zo min mogelijk downtime), welk systeem komt erop, hoe richt ik het in, waar haal ik in godsnaam de tijd vandaan, dat soort vraagstukjes.

Maar laten we eens beginnen met het waarom.

Het waarom

Voor de overgang draaide de server een paar jaar lang op Rockstor 3, een op CentOS7 gebaseerd systeem. Ik had dat destijds (na ook weer het nodige wikken en wegen) gekozen omdat het de beste keuze leek voor mensen die een voorkeur hebben voor btrfs als bestandssysteem. En voor dat doel is het nog steeds een prima systeem, zeker nu de aankomende versie 4 volledig op een OpenSUSE-basis is herbouwd. Ik merkte echter wel steeds meer dat wat ik met die server wilde doen steeds vaker net niet helemaal overeenkwam met de Rockstor-manier, en dat het gebrek aan updates - tegelijk een zegen en een vloek van een traag bewegende distro als CentOS - begon me ook wat tegen te staan.

Tijd voor iets nieuws dus. Maar wat dan?

De opties

Ik heb in de aanloop meerdere systemen en distro's overwogen. Toch hadden die allemaal wel een nadeel waar ik niet helemaal of helemaal niet overheen kon stappen.

  • TrueNAS (voorheen FreeNAS) - publiekslieveling, maar ten eerste zeer sterk zfs-gebaseerd, en ik heb geen enorme behoefte aan zfs. Daarmee ga ik dwars in tegen een hoop mensen die er lyrisch over zijn, en dat is prima. btrfs is flexibeler en maakt onderdeel uit van de Linux-kernel, dus het is voor mij een veiligere, probleemloze keuze. Bovendien is TrueNAS gebaseerd op FreeBSD en zou ik dus alle aanvullende spullen in VMs moeten draaien. An sich geen enorme doodzonde, maar ik ziet niet op zoveel overhead te wachten.
  • Proxmox VE - nog eentje die je vaak tegenkomt. Dit systeem is gebouwd op een Debian-basis en vooral bedoeld als VM-host, dus dan komt dat overhead-verhaal weer om de hoek kijken, en de ondersteuning voor btrfs is er nog niet helemaal.
  • OMV zie je ook nog wel eens, maar ook hier weinig echte ondersteuning voor btrfs.
  • Rockstor 4 - intussen ben ik redelijk bekend met het systeem en hoewel de ontwikkeling wat traag gaat is de community prima. En versie 4 is dus herbouwd op OpenSUSE (Leap of Tumbleweed naar keuze).
  • Gewoon zelf een distro installeren, en het stukje btrfs met de hand doen. Ik heb redelijk vertrouwen in mijn skills om een server op te tuigen en draaiende te houden, en ik hoef dan niet tegen een systeem in te gaan om te bereiken wat ik wil. Dan hoef ik alleen nog maar "even" een distro te kiezen - het veilige CentOS, het actievere maar daardoor wel onderhouds-intensievere broertje Fedora, de vertrouwde Debian of de inmiddels op mijn desktop zeer prettig werkende OpenSUSE? Ubuntu zou het sowieso niet worden aangezien ik iets onbestemds tegen Ubuntu heb (meer tegen Canonical, eigenlijk), en Arch-achtigen op een server is niet mijn ding.

Uiteindelijk is die keuze dus op OpenSUSE gevallen, mede omdat ik ermee vertrouwd (en prettig van onder de indruk) ben geraakt op de desktop, deels omdat het al een tijd btrfs als standaard-bestandssysteem gebruikt (intussen Fedora ook, maar dat is toch niet mijn primaire keuze voor een server, met dat tempo van releases). Wat daarin ook meespelt, is dat zo'n HP-server een paar minuten doet over het hele opstartproces - nog voordat er ergens een OS aan te pas komt - dus iets dat om de haverklap moet rebooten is dan niet zo'n handige keuze.

De opzet

De bestaande situatie was in de loop der jaren een beetje organisch gegroeid en mede daardoor niet echt overzichtelijk. Allerlei keuzes en veranderingen die in de loop der tijd eens waren doorgevoerd, natuurlijk nergens gedocumenteerd of anders vastgelegd, dus het nodige uitzoekwerk van wat er nou precies allemaal draait, waar, hoe, en waarom. Bewerkelijk en foutgevoelig.

Dat kan beter, zeker voor een machine waar ik niet dagelijks mee aan het prutsen ben. Gelukkig zijn daar allerlei handige hulpjes voor tegenwoordig, en ik heb besloten om Ansible te gebruiken. We hebben dat op het werk kortgeleden ook voor een server ingezet, en dat werkte prettig.

De werkwijze is dan niet langer dat je inlogt op een server en daar allerlei dingen gaat zitten aanpassen, maar dat je een setje draaiboeken samenstelt (samen met wat configuratie- en andere bestanden die je op de server wil gebruiken), en die vanaf een machine uitvoert. Je beschrijft de situatie zoals je die wil hebben, en Ansible zorgt er dan voor, dat de machine op afstand aan die situatie gaat voldoen. Dat heeft een paar voordelen: je hebt meteen documentatie van hoe de machine is opgebouwd, het is makkelijk te herhalen zonder dat je stappen vergeet of verkloot, en het is veilig meerdere keren achter elkaar uit te voeren, want Ansible verandert alleen de dingen die nog niet naar wens waren.

De uitvoer

Ik wist dat er hoe dan ook wat downtime met zo'n wederopbouw gemoeid zou zijn, maar om die zoveel mogelijk te beperken heb ik de belangrijkste websites tijdelijk op een andere computer laten draaien. Mail redt zich wel even (SMTP is gebouwd met het vooruitzicht dat een host er even uit kan liggen), en de rest kon ik wel even missen.

Dus sites overprikken, oude SSD (en voor de zekerheid ook even de data-schijven) uit de server, nieuwe (nou ja, een andere) SSD erin, OpenSUSE erop jassen en een gebruiker aanmaken, en daarna kon ik vanop afstand verder: even uitvogelen hoe ik iets voorheen had ingericht, dat eventueel wat aanpassen naar smaak of voortschrijdend inzicht, er een playbook van maken of mee aanvullen, dat op de server loslaten, kijken of de uitkomst alles was wat ik ervan hoopte, eventueel aanpassen, rinse, lather, repeat. Een hoop rinses later heb je dan weer de belangrijkste zaken draaien en is het een kwestie van fine-tunen en kijken welke services je wel of niet in stand wil houden.

Het resultaat

De server draait weer volledig mee, alle data staat nog gewoon waar het stond en eerlijk gezegd is de hele operatie sneller en soepeler verlopen dan ik had gedacht. Dat niet alleen, maar als morgen de SSD besluit om te vallen, heb ik veel minder tijd de hele boel weer draaiende. En als ik een verandering wil maken, dan doe ik dat in een centraal setje bestanden, waar ik de samenhang met de rest van het systeem kan bewaren. Dat scheelt weer een hoop nadenkwerk van "hoe zat dat ook alweer, hoe had ik dat destijds ook weer geregeld" en mogelijke fouten als ik iets vergeet of mis.

Misschien kom ik er later nog eens aan toe om het setje playbooks wat op te schonen en eventueel gevoelige informatie eruit te vissen, en de boel dan ergens openbaar te stallen, ter leering ende vermaeck.

En heel, héél misschien, maak ik ooit de overstap naar Tumbleweed, want intussen heb ik uitgeprobeerd en ondervonden dat de server prima reageert op een net-niet-herstart via kexec, die veel minder tijd kost dan een volledige reboot. En daarmee is vaker herstarten ineens niet meer zo'n probleem...

Plaatje: Wallup.net