Alle posts van Wander

Je kunt tegenwoordig geen steen gooien zonder iets “AI” te raken. Nu mist de “I” uit AI nog overal, maar sommige dingen kunnen dat wel geloofwaardig nadoen. Één van de huidige hype vlakken zij Large Language Models (LLM), software met datasets die plausibel klinkende antwoorden kunnen geven op vragen. Waarschijnlijk ben je wel bekend met commerciële LLMs, zoals bijvoorbeeld ChatGPT.

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.

De meeste beheerders zijn wel bekend met de basis van het systemctl commando om hun (draaiende) services te beheren. Maar soms wil je toch iets meer gemak, zoals het makkelijk naar de logs van een service kunnen klikken, of de dependencies in één overzicht kunnen zien.

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.

Mensen die de hele dag in hun editor of IDE naar keuze leven hebben waarschijnlijk een flinke lading aan trucjes, kunstjes, macros, en zwarte magie die ze uit hun vingertoppen schudden om veelvoorkomende transformaties uit te voeren. Denk bijvoorbeeld aan Base64 Encode/Decode, het omzetten van een document tussen JSON en YAML, of het escapen van speciale karakters in URLS. Mar de mensen die dit soort acties met minder regelmaat uit moeten voeren zijn vaak op zoek naar de goede plugin of commandline tool voor wat ze willen, en vallen vaak terug op (soms wat minder betrouwbare) websites om dit voor ze te doen. Zij die gelukkig genoeg zijn om op een moderne Linux desktop te werken kunnen ook gebruik maken van “Text Pieces”, een handige grafische applicatie die je makkelijk transformaties laat uitvoeren op (stukken van) je tekst. Naast een hele rits aan ingebouwde filters kun je Text Pieces ook uitbreiden met je eigen filters door daar (eenvoudige) scripts voor te schrijven.

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.