Dit artikel werd recent aangepast met kleine technische verbeteringen.

In het Vlaamse secundair onderwijs wordt vrije software nauwelijks gebruikt. Vanuit de verschillende opleidingskanalen worden ICT-coördinatoren geleid naar Windows, Chrome-books, IOS en in mindere mate MacOS als besturingssystemen. Voor toepassingssoftware en beheersoftware wordt resoluut voor gesloten, commerciële pakketten gekozen: Microsoft Office, Sharepoint, Fortinet, Gsuite, … De uitgeverijen, leveranciers, ontwikkelaars voor schoolsoftware en de overheid bouwen en stimuleren het gebruik van gesloten software.

Nochtans is het gebruik en beheer van vrije software niet moeilijk, niet duur en worden er heel wat zaken mogelijk. Vrije software kan immers de privacy, het eigenaarschap van data en de continuïteit van de beschikbaarheid van software garanderen door het publiceren van de code. Niet-vrije software probeert ditzelfde te doen via contracten en licenties, die vaak vaag zijn opgesteld. Er zijn voorbeelden genoeg waar dit leidt tot vendor-lockin en data-driven businessmodellen waar de privacy van de gebruikers niet geheel gerespecteerd wordt. Garanties dat de software veilig is, kunnen ook niet worden gegeven, getuige de vele aanvallen met ransomware, virussen, spyware enzovoort. De voordelen van commerciële, gesloten software zijn ver zoek.

Ik denk dan ook dat het nodig is om jonge leerlingen te laten werken met vrije software, zodat ze hiermee geconfronteerd worden, zich bewust worden van het bestaan en van de voor- en nadelen van vrije software. Alleen zo kunnen zij later gefundeerde software-keuzes maken voor het invullen van persoonlijke en professionele noden.

Daarom als voorbeeld een laptopproject: hoe rol je honderden of duizenden laptops uit met vrije software en hoe beheer je die?

Hardware

Je hebt natuurlijk laptops nodig. Die zijn courant verkrijgbaar met Windows of met MacOS. Bij aankoop van grotere aantallen willen sommige fabrikanten ze wel leveren zonder besturingssysteem of met één of andere Linux-variant. Daar zit al een eerste besparing. Zonder Windows zijn laptops vaak goedkoper. De hardware mag ook lichter zijn. Maar het zijn natuurlijk de bijkomende kosten van het besturingssysteem, zoals betalende virusscanners, configuratiesystemen en dergelijke, die de totale kost van een toestel mee gaan bepalen.

Het loont de moeite om te kijken naar Linux certified hardware. Het komt voor dat de bios van een toestel ondermaats is met soms vreemde problemen tot gevolg. We zagen problemen zoals de functietoetsen die niet werken, de slaapstand die slecht ondersteund wordt, hardware waarvoor geen open bron drivers bestaan enz. Voorzichtig zijn en testen is de boodschap.

Keuze van een distributie

Het codewoord in vrije software is keuzevrijheid. Zoveel dat het tot keuzestress kan leiden.

Linux komt in de vorm van een distributie. Een distributie is een geheel van een linux-kernel, toepassingssoftware en eventueel een grafisch systeem. Dat laatste is voor een laptop echt nodig, voor een server totaal overbodig. De keuze van distributie bepaalt hoe de kernel zal zijn - veel of minder hardware-drivers inbegrepen, welke toepassingssoftware er voorhanden is, welk pakketbeheerprogramma voor software-installatie gebruikt wordt, welk grafisch systeem er geïnstalleerd wordt enzovoort. Door die gemaakte keuzes zijn sommige distributies erg makkelijk om te installeren omdat er al veel vast ligt, andere distributies geven dan weer heel veel keuzevrijheid en zijn daardoor wat moeilijker te installeren of te beheren.

De geschiedenis van de verschillende distributies maakt het mogelijk om ze op te delen in families. Zie https://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Distribution_Timeline.svg We onderscheiden 4 grote families naar oorsprong: Slackware, Debian, Red Hat en Android. De laatste klinkt waarschijnlijk bekend in de oren.

Gemakkelijkheidshalve kiezen we voor Ubuntu. Dat is een zeer populaire distributie uit de Debian-familie. Ubuntu komt met een zeer goede hardware-ondersteuning, installeert heel eenvoudig, komt met waanzinnig veel software. Een gewone standaard-installatie geeft een heel werkbaar toestel. Ubuntu komt ook in een Long Term Support (LTS) versie die 5 jaar meegaat en dan nog is upgraden vrij makkelijk voor een gewone gebruiker.

We gaan een Ubuntu-server installeren voor het beheer van de toestellen en er komt een Ubuntu-desktop op de laptops. De distributie kunnen we doen met Fog, maar we kunnen ook gaan voor een voorgeïnstalleerde laptop die we met een script gaan beheren.

Ontwerpkeuzes voor het project

Rechten van de gebruikers

Ik geloof niet in het beperken van de gebruikers. Leerlingen moeten alle ruimte hebben om te experimenteren. Software installeren, een ander grafisch systeem installeren, instellingen wijzigen, … het moet allemaal kunnen. Dus ze krijgen volledig systeembeheer.

Voorinstallatie van software

Vermits de leerlingen toch beheersrechten hebben, zouden we kunnen verwachten dat ze hun computer zelf in orde zetten. In weze zou dat het beste zijn. Ik heb echter gemerkt dat jonge leerlingen toch wel wat problemen hebben om dat te doen. Om er voor te zorgen dat toch al minstens de software er op staat die ze voor school nodig hebben, gaan we wat software uitrollen. We willen toch ook enkele instellingen kunnen wijzigen en je weet nooit wat er gebeurt - een beheersysteem op zijn plaats maakt problemen oplossen achteraf makkelijk. Als beheersysteem kiezen we voor SaltStack. Meer info over SaltStack in een verder hoofdstuk.

Accounts

We hebben op school twee authenticatiesystemen: LDAP voor toestellen en wat ander gedoe, en een SAML2 identiteitsprovider voor al het web-gebeuren. De toestellen zouden dus tegen de LDAP-server kunnen aanmelden, maar dan moet die wel altijd - ook van thuis, op de trein of bus, … bereikbaar zijn en netwerk kun je nu eenmaal niet garanderen. Er zijn een drietal manieren op Linux om caching van dat LDAP wachtwoord te bereiken. Ze zijn alle drie vrij moeilijk te configureren en niets van wat ik aan het werk gekregen heb bleek echt 100% betrouwbaar. Hoe lang laat je die cache geldig? Wat als een leerling in het weekend of in de vakantie niet meer aangemeld geraakt? Bovendien eisen ze natuurlijk allemaal netwerk bij de eerste aanmelding.

Na veel prutsen en testen stelde ik me de vraag wat ik eigenlijk wou bereiken met die centrale aanmelding en ik moest toegeven dat ik er eigenlijk geen goede reden voor had. Buiten misschien om centraal het wachtwoord te kunnen wijzigen als een leerling dat vergeten was … maar via de “recovery-console” is dat makkelijk te doen als je het toestel in je handen hebt. En waarom zou een leerling zijn wachtwoord vergeten als die dat meerdere keren per dag gebruikt - hoe dikwijls gaat dat gebeuren? Waarschijnlijk zo goed als nooit.

Dus nee, geen centrale authenticatie nodig.

We rollen de laptops uit als een OEM-installatie, net zoals die uit de fabriek komt: de computer vraagt de taal, toetsenbord, tijdzone, gebruikersnaam en wachtwoord bij eerste opstart. De gebruiker die dan aangemaakt wordt heeft beheerdersrechten en dat wilden we toch al.

Softwarebeheer

Inleiding

We kiezen SaltStack voor het beheer van instellingen en software-installatie. SaltStack is ontworpen voor het beheer van datacenters. Dan zal het ook wel goed genoeg zijn voor onze laptops (alternatieven: Puppet, Cheff, Ansible). We kiezen voor SaltStack omdat het opschaalt naar zeer grote hoeveelheden toestellen.

SaltStack bestaat uit een servergedeelde, de salt-master, en een client-gedeelte, de salt-minion.

Op de server beschrijf je in een tekstbestand hoe je client er moet uitzien. De salt-minion weet op welk besturingssyteem die draait en hoe de gevraagde instellingen moeten bereikt worden op dat systeem. Je kunt dus nagenoeg dezelfde configuratie op de master gebruiken voor Debian, Red Hat of zelfs Windows-toestellen. Pure magie.

De communicatie tussen master en minion is beveiligd. Een minion kan automatisch vragen aan de master wat zijn status moet zijn of je kunt vanuit de master één of een groep minions aanspreken. Minions zijn aanspreekbaar op hun ID - standaard is dat de computernaam, maar dit kan ook geconfigureerd worden, op hun rol - je kunt een computer één of meerdere rollen geven, of op een “grain” - een grain is een eigenschap van de computer, bijvoorbeeld merk, type, processormodel, hoeveelheid RAM, harde schijfgrootte, besturingssysteem… noem maar op. Op deze manier kun je toestelspecifieke of besturingssyteemspecifieke zaken meegeven in dezelfde configuratie.

Installatie van de serversoftware

De installatie van de serversoftware is niet moeilijk. Kies je favoriete Linux-distributie om een server te installeren en volg de instructies op https://docs.saltproject.io/en/latest/topics/installation/index.html

In het kort komt het er op neer:

• installeer SaltStack met het pakketbeheerprogramma van je serversoftware
• zorg ervoor dat die kan gevonden worden door de clients (dns, firewall) - standaard zoeken die naar salt.domein.be op poort 4505 en 4506. Deze instellingen kunnen natuurlijk gewijzigd worden in je DNS-server en in /etc/salt/master en overeenkomstig op je client.
• standaard zet je de receptjes op je clients te configureren in /srv/salt. Ook dit kan in /etc/salt/master gewijzigd worden als je daar een reden voor hebt.

De server moet de minions (= de clients) aanvaarden. Manueel is dat een lastig proces, dus we maken een bestandje /etc/salt/autosign_file met daarin een lijst van alle clients die we deze server gaan laten beheren (hostname of minion_id).

Installatie van de cliëntsoftware

De installatie op de clients gebeurt op dezelfde manier. Installeer op de clients je favoriete besturingssysteem, installeer volgens de geplogenheden van dat systeem salt-minion (zie ook https://docs.saltproject.io/en/latest/topics/installation/index.html).

Salt-minion gaat op zoek naar salt.domein.be op poort 4505 en 4506. Je kunt aanpassen waar die gaat zoeken door de instellingen op de client aan te passen in /etc/salt/minion.d/. Zet daar een bestandje met extensie .conf met daarin wat je wil wijzigen

• master: servernaam (of ip) om een andere servernaam te gebruiken dan salt.domein.be
• master_port: en publish_port als je andere poorten wil gebruiken
• startup_states: highstate als je wil dat de client bij opstarten moet gaan vragen hoe zijn toestand moet zijn.

De salt-minion stelt zichzelf bij de server voor met zijn hostname. Als je dat anders wil, dan kun je /etc/salt/minion_id een naam opgeven. Die moet uniek zijn voor de client. De hostname (als je geen minion_id gebruikt) en de minion_id moeten uniek zijn.

Als de hostname/minion_id voorkomt in /etc/salt/autosign_file van de server, dan zal de client automatisch mee onder het beheer van de server genomen worden en is geen manuele aanvaarding meer nodig.

Bootstrappen van een client.

Veel moet er niet gebeuren op een client, maar toch iets. Bovendien moet elke client op één of andere wijze uniek gemaakt kunnen worden - althans toch minstens de minion_id.

Daar zijn verschillende manier voor te bedenken, maar ik kwam uit op het volgende: de serienummer van een toestel is uniek. Dus als ik die als hostname/minion_id kan gebruiken, dan heb ik unieke ID’s. Ik steek de computers ook in mijn inventarissysteem (Snipe-IT) met hun serienummer als identificatie, dus ik kan mijn lijstje om /etc/salt/autosign_file te vullen gemakkelijk daar uit exporteren.

Ik installeer op een client een OEM-configuratie van Ubuntu met minimale software-installatie. Dat geeft het volgende:

• de image is klein (5G) en daarom snel te distribueren via FOG
• er zijn weinig updates na het installeren want er staat bijna geen software op het toestel
• leerlingen kunnen hun eigen lokale account maken - ik had eerder al besloten dat de account op de computer niet belangrijk is.

Op de OEM-installatie laat ik volgend script los alvorens die af te sluiten voor verschepen naar de gebruiker:

#! /bin/bash
# service installeren
# volgende service start installatie_digissprong, wat de voorbereiding van de laptop is bij zijn eerste start
sudo cat > /etc/systemd/system/installatie_digispronglaptop.service << EOF
#Éénmalig uit te voeren unit, zie script ..
[Unit]
Description=Setup na image deploy via FOG
After=network-online.target
Wants=network-online.target
Before=avahi-daemon.service gdm3.service
[Service]
ExecStart=/usr/local/bin/installatie_digispronglaptop.sh
Type=oneshot
[Install]
WantedBy=multi-user.target
EOF

# dit script installeert salt-minion na de eerste start en zal bij de volgende start verbinding zoeken met de salt-master.
sudo cat > /usr/local/bin/installatie_digispronglaptop.sh << EOF 
#! /bin/bash
#Salt installeren (instellingen in /etc/salt/minion.d worden gebruikt):
while fuser /var/{lib/{dpkg,apt/lists},cache/apt/archives}/lock >/dev/null 2>&1; do
   sleep 1
done
apt-get update
while fuser /var/{lib/{dpkg,apt/lists},cache/apt/archives}/lock >/dev/null 2>&1; do
   sleep 1
done
apt-get -y install salt-minion openssh-server
EOF

# Dit is het eigenlijke script dat de laptop zal klaarzetten tijdens de 
# eerste start. De configuratie van salt-minion en het instellen van de 
# hostname gebeurt hiermee.
# De single quotes rond EOF op de volgende regel zorgen er voor dat de variablen niet
# geïnterpreteerd worden tijdens het uitvoeren van het script
sudo cat >> /usr/local/bin/installatie_digispronglaptop.sh << 'EOF' 


# salt configuratie
mkdir -p /etc/salt
mkdir -p /etc/salt/minion.d
# minon ID configureren
touch /etc/salt/minion_id
echo $(dmidecode -s system-serial-number) > /etc/salt/minion_id
touch /etc/salt/grains
echo "roles:" > /etc/salt/grains
echo "- 2022" >> /etc/salt/grains
# server configureren
touch /etc/salt/minion.d/server.conf
echo "#andere master dan standaard" > /etc/salt/minion.d/server.conf
echo "master: saltextern.ritacollege.be" >> /etc/salt/minion.d/server.conf
echo "# eventueel andere poorten" >> /etc/salt/minion.d/server.conf
echo "master_port: 4506" >> /etc/salt/minion.d/server.conf
echo "publish_port: 4505" >> /etc/salt/minion.d/server.conf
echo "#Niet meer over klagen in logfile:" >> /etc/salt/minion.d/server.conf
echo "hash_type: sha256" >> /etc/salt/minion.d/server.conf
echo "#En begin er ineens aan:" >> /etc/salt/minion.d/server.conf
echo "startup_states: highstate" >> /etc/salt/minion.d/server.conf
# hostname instellen
hostnamectl set-hostname $(dmidecode -s system-serial-number)
EOF

sudo chmod 755 /usr/local/bin/installatie_digispronglaptop.sh


# We zorgen er voor dat we met de OEM-versie zo proper mogelijk beginnen
sudo apt-get update
sudo apt dist-upgrade -y

# repo's juist zetten
# Er is nog geen 22.04-versie van salt, maar de 20.04-versie werkt nog goed genoeg
# Download key
sudo apt install curl -y
sudo curl -fsSL -o /usr/share/keyrings/salt-archive-keyring.gpg https://repo.saltproject.io/py3/ubuntu/20.04/amd64/latest/salt-archive-keyring.gpg
# Create apt sources list file
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/salt-archive-keyring.gpg] https://repo.saltproject.io/py3/ubuntu/20.04/amd64/latest focal main" | sudo tee /etc/apt/sources.list.d/salt.list

# installatie klaarzetten
sudo apt-get install --download-only salt-minion -y

# Service starten bij volgende boot
sudo systemctl enable installatie_digispronglaptop.service

# wat debconf voorbereiden
sudo apt install debconf-utils  -y
# Preseeding only locale sets language, country and locale.
sudo echo debian-installer debian-installer/locale string nl_BE | sudo debconf-set-selections
# Keyboard selection.
sudo echo keyboard-configuration keyboard-configuration/xkb-keymap select be | sudo debconf-set-selections
sudo echo keyboard-configuration keyboard-configuration/toggle select No toggling | sudo debconf-set-selections
# You may set this to any valid setting for $TZ; see the contents of
# /usr/share/zoneinfo/ for valid values.
sudo echo time time/zone string Europe/Brussels | sudo debconf-set-selections
sudo echo languagechooser languagechooser/language-name string Dutch | sudo debconf-set-selections
sudo echo countrychooser countrychooser/shortlist string BE | sudo debconf-set-selections
sudo echo localechooser localechooser/supported-locales string nl_BE.utf8 | sudo debconf-set-selections

# grote kuis
sudo apt autoremove -y

Een woordje uitleg:

• we maken en installeren een service om de installatie te starten. De service gaat één keer lopen, de eerste keer dat de gebruiker de computer start, nadat die een gebruikersnaam en wachtwoord ingesteld heeft. Deze service gaat de scripts starten die de computer uniek maken
• het script maakt scripts die door de service gaan gestart worden. Dat maakt het lezen van bovenstaande code wat verwarrend
• de scripts wachten tot de installer vrij is, mocht die beginnen updates te installeren en installeren dan salt-minion, zetten de configuratie van salt-minion op orde (poorten, servernaam, minion_id). Merk op dat we de minion rechtstreeks van de servers van SaltStack installeren zodat die zo up-to-date mogelijk is om beveiligingsrisico’s te verminderen. Voor de minion_id en de hostname lezen we het serienummer uit de bios uit met dmi_decode.
• verder worden er nog wat standaardinstellingen juist gezet, zoals taal, toetsenbord, tijdzone enz.
• we geven de client een initiële rol mee. Die kan in /etc/salt/grains toegevoegd worden. We kunnen deze batch clients daarop aanspreken. Het is niet echt nodig, want via het grains-systeem kan dat even goed op processormodel, hoeveelheid ram, model moederbord, … noem maar op. Rollen kunnne via Salt ook altijd achteraf nog gewijzigd worden.

Het onderscheid tussen verschillende machines kan ook gemaakt worden op basis van nodegroups. Vanaf schooljaar 2022-2023 gaan we hier gebruik van maken voor het onderscheid tussen leraarslaptops en laptops van leerlingen. We maken een bestandje /etc/salt/master.d/nodegroups.conf aan, en daarin zetten we de serienummers van de toestellen in een juiste groep. Bijvoorbeeld:

nodegroups:
# lijst met testlaptops
  test:
    - laptopserienummer1

# lijst met laptops van leraars
  leraars:
    - laptopserienummer2

# lijst met laptops van leerlingen
  leerlingen:
    - laptopserienummer3
    - laptopserienummer4

Alles is nu op z’n plaats gevallen: de serversoftware kent de clients en wacht op hun verzoek, de clients kennen de server, zullen zich aanbieden bij eerste start en bij elke opstart vragen hoe ze er moeten uitzien. Klaar dus om te configureren wat we willen.

Installatie van standaardpakketten op de client

Alle configuraties starten vanuit een bestandje top.sls dat je plaatst op je server in /srv/salt/

Daar maak je een begin van hoe alles er moet uitzien. Bij ons ziet het er zo uit:

base:
  '*':
    - software.iedereen
  
  test:
    - match nodegroup
    - software.test

  leraars:
    - match nodegroup
    - software.leraars
    - printers.leraarslokaal

  leerlingen:
    - match nodegroup
    - software.leerlingen

We hebben dus drie keer hetzelfde scenario: voor computers in de nodegroup leraars, leerlingen en test. Merk op dat de we geen identificatie gebruiken die met de installatie op de laptop is meegegeven. Initieel zijn ze dus allemaal gelijk, behalve hun serienummer. Alle bijkomende configuratie wordt op basis daarvan gedaan.

De syntax is als volgt: software.iedereen betekent: ga kijken in het bestand /srv/salt/software/iedereen.sls. De mappenstructuur mag weggelaten worden - /srv/salt wordt als root van de salt-server bekeken - de extensie .sls mag ook worden weggelaten en de mappenstructuur wordt met een punt weergegeven. Het had voor mij niet gemoeten, maar het maakt alles wel meer leesbaar.

Veruit de eenvoudigste pakketten om te installeren zijn de pakketten die in de repository van het besturingssysteem zitten. Dat gaat zo:

dpkg:
  cmd.run:
     - name: /usr/bin/dpkg --configure -a

pakket_uptodate:
  pkg.uptodate:
  - refresh: True
  - dist_upgrade: True
  
pakket_install:
  pkg.latest:
    -pkgs:
      - audacity
      - scratch
      - vlc
      - scribus
      - freeplane
      - gimp
      - gnu-cash
      - stellarium
      - klavaro
      - libreoffice

De lijst is nog veel langer, maar je snapt het idee. Bij elke opstart van de pc wordt eerst gecontroleerd of een vorige software update of installatie niet onderbroken was en dat eventueel hersteld, dan worden de nieuwe softwarelijsten opgehaald en wordt de hele machine up-to-date gemaakt. Verder wordt er gecontroleerd of die lijst met pakketten geïnstalleerd is en als dat niet zo zou zijn, dan worden die alsnog geïnstalleerd. Veel eenvoudiger kan het niet worden vrees ik.

Installatie van niet-standaardpakketten op de client

Wat moeilijker zijn niet-standaardpakketten. Dit zijn pakketten waarvan er geen kandidaat is in de repository’s van Ubuntu of waarvan we die in die repository’s niet de juiste versie vinden.

Er zijn eigenlijk drie niveau’s van problemen met een toenemende complexiteit om die te installeren

• er bestaat een repository met de juiste pakketten: fijn. Repository toevoegen en dan de software installeren met pkg.latest.
• er bestaat geen repository, maar de software is wel als .deb beschikbaar: jammer, maar je kunt je eigen repository bouwen en zelf die pakketten naar je clients distribueren.
• er bestaan zelfs geen .deb-bestanden: jammer, maar je kunt zelf .deb-bestanden maken en die dan in je eigen repository verdelen.

Een voorbeeld van een pakket met een repository is Geogebra. In mijn voorbeeld zit dat mee in /srv/salt/software/otherpackages.sls. Vandaar start al dit soort software.

geogebra:
  pkgrepo.managed:
    - name: deb [arch=amd64] http://www.geogebra.net/linux stable main
    - dist: stable
    - key_url: https://static.geogebra.org/linux/office@geogebra.org.gpg.key
    - file: /etc/apt/sources.list.d/geogebra.list
  pkg.latest:
    - pkgs:
      - geogebra-classic

Wat hier gebeurt is dat we de repostitory bij installeren op de client, de beveiligingssleutel ophalen en dan het pakket geogebra-classic installeren.

Andere software die op gelijkaardige manier moet geinstalleerd worden als je ze wil zijn Google Chrome Browser en Google Earth.

Een pakket dat we installeren waarvan we een .deb installatiepakket hebben, maar er is geen repository van, is mLink voor mBlock (Makeblock). Dat is software die het mogelijk maakt om een robotje van mBlock via USB te verbinden, zodat het kan geprogrammeerd worden.

Een Pakket waarvan geen Debian-pakket bestaat en dat we daarom zelf verpakken is Tracker van https://physlets.org/tracker/ om videometingen in de fysicaklas te doen.

Het gaat dus om een zeer klein aantal pakketten. Het opzetten van een eigen repository laat ik daarom buiten de scope van dit document vallen. We gebruiken Reprepro, waarvan je een goede installatie-handleiding vindt op https://wiki.debian.org/DebianRepository/SetupWithReprepro

Het zelf maken van Debian pakketten is niet moeilijk. Veel online tutorials gaan er natuurlijk vanuit dat je de software zelf geschreven hebt en dat je die nog moet compileren, maar als je van een bestaand pakket uitgaat, dan kun je het resultaat van de installer makkelijk in een pakket steken:

• maak een lege map waar alles in komt
• steek in die map de volledige structuur en alle bestanden van het programma, zoals het moet opgebouwd worden vanuit de root-folder
• maak een extra map “DEBIAN” met daarin een bestandje control
• Dat bestandje moet een zinnige versie van het volgende bevatten:

Package: helloworld
Version: 0.2
Maintainer: King Foo
Architecture: all
Description: hello world 

• start in de bovenliggende map dpkg-deb --build mapnaam
• in de map zal nu een bestandje mapnaam.deb ontstaan, dat je gewoon kunt installeren of publiceren via je eigen repository.

Het is niet echt rocket-science, maar het vraagt een paar keer oefenen.

Instellingen wijzigen

Zo goed als alle instellingen op een Linux zitten in bestanden. Met SaltStack kun je bestanden maken, wijzigen, vervangen, verwijderen, dus in principe is een Linux volledig te beheren met SaltStack. De instellingen van een gebruiker zitten allemaal in zijn home-folder. Hoewel het allemaal wel kan, merk je toch gauw dat instellingen in home-folders wijzigen al een stuk moeilijker is. De wens om dit te doen vergaat je compleet als je uitgaat van het respecteren van de persoonlijke keuzes van een gebruiker: als die gebruiker beslist om zijn bureaublad-acchtergrond te wijzigen, dan is dat maar zo. Misschien komt het iemand zijn productiviteit ten goede als die een donker thema gebruikt? Moet je dan verhinderen om dat te installeren?

Dus instellingen wijzigen: ja, zolang het nuttig is, de wijzigingen de gebruiker of het toestel beschermt, noodzakelijk is enz. Algauw kom je zo uit bij systeem-instellingen en die leven nagenoeg allemaal in de map /etc.

Een voorbeeld van een wijziging die we zo doen, zijn natuurlijk de extra repositories om bepaalde softwarepakketten te installeren, maar ook bijvoorbeeld het niet aanbieden van een release-upgrade. Niet omdat dit niet mag of dat dit een slecht idee is, maar liefst niet per ongeluk tijdens een les. Tijdens een release-upgrade wordt het hele besturingssysteem vervangen door een meer recente versie (bijvoorbeeld een Ubuntu 18.04 naar een 20.04) en dat kan wel een paar uur duren. Daarom schakelen we het aanbieden ervan uit. We maken een bestandje /srv/salt/upgrades/norelupgr.sls aan met daarin:

GeenReleaseUpgradesVoorstellen:
  file.replace:
  - name: '/etc/update-manager/release-upgrades'
  - pattern: 'Prompt=lts'
  - repl: 'Prompt=never'

We gaan dus in het configuratiebestand release-upgrades de tekst Prompt=lts vervangen door Prompt=never. Hierdoor gaat de computer nooit voorstellen om een release-upgrade te doen. Wil je wel een release-upgrade doen, dan moet eerst deze instelling aangepast worden.

Maar voor laptops voor leerlingen zijn weinig extra instellingen nodig - hier houdt het ongeveer op.

Nawoord

Zoals je merkt zijn de gebruikte oplossingen om dit project uit te rollen een combinatie van bouwstenen die voor tal van doelen gebruikt kunnen worden.

Scripts, services, grote softwarepakketten zoals SaltStack en Reprepro, configuratiebestanden, kleine commando’s zoals dmidecode… Er is niet zoiets als een tool die het allemaal ineens doet, maar je trekt een bibliotheek van tools open en je laat elke tool meebouwen aan je unieke maatoplossing. Hoe beter en hoe meer tools je beheerst, hoe dichter je bij de ideale oplossing komt - de enige limiet is je kennis - en die limiet kun je verleggen.