Alle posts van Wander

Praktisch iedereen die netwerken beheert heeft het wel eens gezien: Twee hosts die hetzelfde IP(v4) adres proberen te gebruiken. Dit zorgt over het algemeen voor veel hilariteit en weinig productiviteit. Op systemen die “NetworkManager” gebruiken kan er een simpele veiligheidsmaatregel worden aangezet: een ARP request voor het gewenste IPv4 adres voordat deze geactiveerd wordt. Is het adres in gebruik, dan wordt de verbinding niet geactiveerd. Op RHEL9 en ouder staat deze test standaard uit, op RHEL10 en Fedora41 staat deze test standaard aan.

Om het nieuwe jaar goed te beginnen, en misschien wat te helpen met goede voornemens, laat Wander in deze video het (stokoude) commandline tooltje fortune zien. Een kleine applicatie die een willekeurige quote uit een (willekeurige) gekozen lijst aan quotes laat zien.

Spoiler Alert: Deze video bevat wat hints voor de Kerst Puzzel Zoals elk jaar hebben we ook dit jaar weer de traditionele Kerst Puzzel voor jullie. Dit jaar is de opgave simpel: Je bent ingebroken op het datacenter van de Kerstman (iets met jezelf uit de database van stoute mensen willen verwijderen). Je hebt nu een shell op de authorative nameserver voor het .santa domein, en je bent op zoek naar de hostnaam (FQDN) en omschrijving van de server waar de database voor de stouterds op wordt bewaard.

Zoals elk jaar hebben we ook dit jaar weer de traditionele Kerst Puzzel voor jullie. Dit jaar is de opgave simpel: Je bent ingebroken op het datacenter van de Kerstman (iets met jezelf uit de database van stoute mensen willen verwijderen). Je hebt nu een shell op de authorative nameserver voor het .santa domein, en je bent op zoek naar de hostnaam (FQDN) en omschrijving van de server waar de database voor de stouterds op wordt bewaard.

In het verleden hebben we hier al vaker gekeken naar Podman Quadlets, een makkelijke manier om containers als systemd services te draaien. We hebben gekeken naar het maken van container units, en naar het templaten van comtainer units. Maar wat we nog niet gedaan hebben is het kijken naar container image builds met quadlets.

In een Containerfile levert elk RUN commando een aparte “layer” op in het resulterende image. Wanneer je in een latere layer data uit een eerdere layer verwijdert blijft deze data dus wel in je container image zitten, je ziet het alleen niet meer. Een veel voorkomend voorbeeld hiervan is bijvoorbeeld de gecachete metadata van je package manager.

Wanneer je kustomize gebruikt om met Overlays de lifecycle-fases van je applicatie te beheren dan ga je vroeger dan later een keer de vragen stellen hoe je promoties van images (en Bases) tussen deze fases kunt automatiseren. Met de hand references en image transformers doorzetten is meestal geen optie vanwege de kans op fouten, en het willen automatiseren van de promotie pipelines. Nu zijn er bestaande oplossingen met tools als Renovate die dit (gedeeltelijk) voor je kunnen oplossen, maar die hebben vaak wat meer infrastructuur nodig. Als je deze tools nog niet gebruikt dan zou je zelf wat scriptjes kunnen schrijven, maar nu heb je nog iets extras om te beheren en bij te houden.

Éé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.

In a typical containerized application we have a lifecycle that goes a little like this: Developers push code to an application repository. A pipeline builds the latest code and pushes the resulting image to a registry The pipeline updates the images: transformer in a Kustomization Overlay for the dev environment with the new image by using a command like kustomize edit set image foobar=registry.example.com/foobar@sha256:deadbeef A tool like ArgoCD picks up the new image and starts a new deployment. This works well for the dev environment, but when that image needs to be promoted to a new environment like tst we either need to copy the updated image transformer manually, or try to read the updated version from the dev Kustomization. And images are not the only thing. A typical Kustomize Overlay will include a versioned Base with something like this: 1apiVersion: kustomize.config.k8s.io/v1beta1 2kind: Kustomization 3resources: 4- git.example.com/foobar.git/deploy/base?ref=v0.2.1 In this example we see that the Base that is being used comes from the Git tag or branch called v0.2.1. If a newer version of the application needs a newer Base a developer can update that reference in the dev Overlay, but promotions will need to be handled as well. Simply copying the kustomization.yaml file between Overlays will most likely not work, since different Overlays typically use different Replica transformers, different ConfigMap en Secret Generators etc. Read on to learn how you can automate this.