Alle posts van Wander

Sinds een aantal jaren kun je naast de regulier Fedora Workstation (en de spins daarvan) ook een radicaal andere versie van een Fedora desktop installeren: Fedora Silverblue. Op een Silverblue systeem heb je niet één root filesysteem, maar meerdere. Updates werken dan ook niet op je live systeem, maar als overlays op een upstream image. Applicaties installeer je als het even kan via Flatpak, maar je mag ook zelf RPM pakketten laten layeren bovenop het basis image.

Met de release van OpenShift 4.13 is de support voor het gebruik van de nieuwste generatie Control Groups (cgroup v2) van Technology Preview (TP) naar General Availability (GA) gegaan. Wel staat de standaard instelling nog op de eerste generatie.

Met de release van OpenShift 4.13 is de Custom Metrics Autoscaler Operator gepromoveerd naar General Availability (GA). Met deze operator kun je het aantal replica’s van je deployments automatisch laten schalen aan de hand van CPU gebruik, geheugen gebruik, custom Prometheus metrics, of Kafka Queues (die laatste is wel nog Technology Preview).

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

In een heterogene server omgeving wil je vaak dezelfde (soort) taken uitvoeren op machines die verschillende distributies draaien. Nu kun je hiervoor verschillende playbooks gebruiken, maar je kunt je playbooks ook slim hiermee om laten gaan en voor één doel ook één playbook gebruiken.

Bijna iedereen die met Bash werkt kent de magische variabele $? wel, met daarin de exit-code van je meest recente commando. Maar wist je dat ook de individuele exit-codes van de onderdelen van een pipeline kunt bekijken?

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.

Met pasen hebben jullie alemaal mee kunnen doen met de jaarlijkse HCS Paas Puzzel, en dat hebben velen van jullie ook gedaan. Er is ondertussen een winnaar getrokken, en inzenden kan niet meer. Vandaag loopt Wander voor degene die zijn vastgelopen op de puzzel over alle vragen heen, en laat zien waar je de antwoorden had kunnen vinden.

Podman Containers als systemd Units - Nieuwe Heetheid met Quadlet In een vorige video hebben we al eens gekeken hoe je een systemd unit kan maken van een Podman container. De functionaliteit zoals daar beschreven werkt nog steeds, maar vanaf Podman 4.4 is er ook een makkelijkere methode met behulp van Quadlet. Met de nieuwe manier kun je een systemd .container unit schrijven, die tijdens het opstarten van je systeem automagisch een .service unit genereert met de juiste instellingen.