Één van de nieuwe features in RHEL9.5 is de mogelijkheid om in Cockpit, de grafische management console van RHEL, bestanden te beheren alsof je in een grafische file-manager werkt.

Wanneer je op een Linux systeem regelmatig dynamisch bestandssystemen moet mounten (bijvoorbeeld NFS home directories), of liever niet alle mounts standaard aan hebt staan terwijl ze nauwelijks gebruikt worden, kan de automounter (autofs) uitkomst bieden.

Autofs mount zichzelf op een directory, en mount dan vervolgens dynamisch subdirectories wanneer ze aangesproken worden, en unmount ze na een periode van inactiviteit weer.

Iedere beheerder komt wel een keer op het punt dat hij het root wachtwoord van een systeem niet (meer) kent. Misschien is het een oud, niet goed gedocumenteerd, systeem, misschien is het een super-speciaaltje uit een verloren tijd, of misschien had iemand dikke vingers bij het instellen.

In een moderne setup kan het het makkelijkst zijn om dat systeem gewoonweg opnieuw in te spoelen, maar helaas is dat niet altijd een mogelijkheid. In het geval van een virtuele machine zou je ook het disk-image ergens anders kunnen koppelen en op die manier /etc/shadow bewerken, maar ook dat is niet altijd een uitkomst.

Wat je wel (bijna) altijd kunt doen, als er geen wachtwoord op de bootloader staat, of dat wachtwoord is bekend, is inbreken op het boot proces en op die manier jezelf toegang verschaffen tot het systeem, waarna je dingen kunt doen als het root wachtwoord resetten naar een bekende waarde.

In wat recente videos hebben we gekeken naar SELinux troubleshooting en policy queries, zonder de basis van SELinux te behandelen. Nu hebben we de basis meer dan twee jaar geleden behandeld in een serie videos, maar het is wel weer tijd voor een opfrisser.

Op een RHEL systeem is standaard een SELinux policy (meestal targeted) actief die bepaalt wat services wel, maar vooral ook niet, mogen doen. In principe is alles wat niet expliciet is toegestaan verboden, maar wat er nou precies is toegestaan is voor veel beheerders een enigma.

Gelukkig zijn er tooltjes waarmee je een SELinux policy kunt uitlezen om te zien wat er nou precies allemaal inzit, zonder naar de source van de policy te hoeven grijpen. Een bijkomend voordeel van je draaiende systeem uitlezen is dat eventueel geladen modules en extensies ook uitgelezen worden.

Sinds de release van Red Hat Enterprise Linux (RHEL) 9.4 is er een toffe Technology Preview (TP) waarmee je ostree gebaseerde RHEL systemen kunt uitrollen met je eigen custom images. Denk de Universal Blue variant van Silverblue, maar dan voor je eigen custom RHEL deployments, of het nou gaat om machines in de cloud, bare-metal, lokale VMs, etc.

Een van de leukste dingen hieraan, naast de standaard voordelen van image-based deployments met ostree zoals pijnloze rollbacks etc., is hoe makkelijk het is om je eigen images te maken aan de hand van een Containerfile (Dockerfile voor degenen die in het vorige decennium leven).

Iedere beheerder die RHEL(-familie) systemen beheert is wel eens tegen een probleem aangelopen waarbij SELinux iets aan het tegenhouden was dat eigenlijk niet tegengehouden had moeten worden. Dan kun je zelf de SELinux log files induiken (/var/log/audit/audit.log), maar je kunt ook andere tooltjes daar naar laten kijken voor je, om wat leesbaardere output te krijgen.

De beste methode om naar een nieuwe major versie van Red Hat Enterprise Linux (RHEL) te migreren is met een schone installatie of een nieuw image. In een ideale wereld kun je dit zonder problemen met al je systemen doen, je custom software werkt gewoon, en al je machines zijn volledig met behulp van automation uitgerold en geconfigureerd. In de echte wereld heb je helaas echter altijd wel een paar machines die zoveel handwerk hebben gehad, of zo slecht gedocumenteerd zijn, dat dit niet mogelijk is.

Voor die gevallen is er sinds de release van RHEL8 wel een manier om in ieder geval je OS wel te kunnen upgraden naar een nieuwe versie, zonder een nieuwe installatie te moeten doen: Leapp

Vroeger was mounten “makkelijk”, je zette wat instellingen op wat regels in /etc/fstab, draaide mount -a, en hoopte dat het na een reboot ook nog werkte. Echte dependencies voor geneste mounts waren er niet, en alle dingen die je systeem nodig hadden om te draaien zoals /proc en /sys stonden er ook in.

Nu is dit voor eenvoudige dingen genoeg, maar zodra je ook mounts gaat toevoegen die wat moeizamer zijn, zoals mounts die netwerk nodig hebben, of die een harde afhankelijkheid hebben op een al reeds draaiende service, werdt het “interessant”, en dan niet op een leuke manier.

Ook kon een kleine typfout in een secundaire mount het hele boot proces van een systeem tegenhouden, met alle outages en andere lol van dien.

RHEL, en dus ook geralteerde distros als CentOS, Rocky, en Alma) hebben een beperkte, gecureerde, lijst aan pakketten die geïnstalleerd kunnen worden. Voor veel use-cases zal deze lijst genoeg zijn, maar in sommige gevallen wil een beheerder toch ent dat beetje meer hebben.

Sinds enige jaren heeft de RHEL familie van distributies een krachtige web-based management tool: Cockpit