Kennisbank / enterprise Linux beheer

Enterprise Linux-beheer: tmp, journald, NFS en versionlock

Auteur: DEWOLF.IT

Enterprise Linux beheer raakt meerdere lagen tegelijk. Een tijdelijke map, loglimiet, Kerberos-ticket of package-lock kan een applicatie beïnvloeden zonder dat de applicatieconfiguratie is veranderd. Deze gids maakt vier van zulke beheerafspraken expliciet en toetsbaar.

Scope: RHEL 8/9, systemd en DNF 4. NFS/Kerberos vereist bestaande realm-, DNS-, identiteits- en keytabconfiguratie.

Toepassing. RHEL 8/9 met systemd en DNF 4. Deze vier beheeronderwerpen horen in een platformstandaard. NFS/Kerberos-voorbeelden veronderstellen een correct ingerichte realm, identiteitsmapping, DNS en keytabs.

Probleem en achtergrond: kleine beheerafspraken hebben grote gevolgen

Een applicatie kan storing geven doordat tijdelijke bestanden verdwijnen, logs niet bewaard blijven, een Kerberos-ticket verlopen is of een package niet meer mag upgraden. Die oorzaken liggen buiten de eigen applicatieconfiguratie. Maak daarom per beheerafspraak duidelijk wat de eigenaar is, welk gedrag wordt verwacht en hoe je het controleert.

De vier onderwerpen hieronder vragen elk hun eigen diagnose. Deel wel dezelfde werkwijze: observeer de effectieve toestand, vergelijk met de afspraak, verander alleen de betrokken laag en test de applicatie. Beheerdefaults zijn geen bewijs dat een omgeving voldoet aan het afgesproken gedrag.

1. Tijdelijke bestanden: scheid cleanup, mounts en service-isolatie

findmnt /tmp
findmnt /var/tmp
stat -c '%a %U:%G %n' /tmp /var/tmp
systemctl status systemd-tmpfiles-clean.timer --no-pager
systemd-tmpfiles --cat-config

Onderzoek afzonderlijk mountopties, ownership/mode, tmpfiles-regels en PrivateTmp van de service. noexec beperkt directe uitvoering vanaf de mount, maar vormt geen algemene blokkade voor scripts die een interpreter leest. PrivateTmp geeft een service een eigen zicht op tijdelijke directories; dat verklaart waarom twee processen niet hetzelfde tijdelijke pad zien. Zie systemd.exec.

Beheer applicatiecache liever in een eigen directory dan met een algemene uitzondering voor /tmp. Onderstaand voorbeeld maakt een afgebakende tijdelijke map voor een reeds bestaand serviceaccount. Stem de leeftijd af op de applicatie; verander de globale /tmp-policy niet voor één workload.

# /etc/tmpfiles.d/exampleapp.conf
# Type Path                  Mode User       Group      Age
 d     /var/tmp/exampleapp    0700 exampleapp exampleapp 7d

De d-regel maakt/beheert de directory en de leeftijd wordt gebruikt bij cleanup van de inhoud volgens de tmpfiles-semantiek. Het is geen garantie dat elk bestand exact zeven dagen na creatie verdwijnt: timestamps en de gebruikte systemd-versie spelen mee. Lees tmpfiles.d en test met representatieve bestanden. Voer –clean niet blind uit op productie; dat kan direct bestanden verwijderen.

2. Journald: retentie begint bij effectieve opslag

sudo journalctl --disk-usage
sudo journalctl --list-boots
sudo journalctl -u systemd-journald -b --no-pager
systemd-analyze cat-config systemd/journald.conf

Met Storage=persistent worden logs op persistente storage bewaard als de daarvoor benodigde filesystemcondities zijn vervuld. Met vluchtige opslag kan historische incidentinformatie na reboot ontbreken. Retentie hangt daarnaast af van limieten, vrije ruimte, logvolume en rate limiting. De journald-configuratiedocumentatie beschrijft die samenhang.

# /etc/systemd/journald.conf.d/60-retention.conf
# Voorbeeldwaarden, afstemmen op capaciteit en bewaarbeleid.
[Journal]
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=2G
MaxRetentionSec=30day

Dertig dagen is hier een maximumleeftijd, geen gegarandeerde minimumretentie: een ruimtelimiet kan eerder oude archived journals verwijderen. Stel capacity en centraal logtransport zo in dat de vereiste periode ook onder piekbelasting haalbaar is. Plan het toepassen van deze configuratie en verifieer daarna opslag, bootgeschiedenis en ontvangst aan de centrale kant.

Vacuum verwijdert archived journals, niet willekeurig alle actieve data. Exporteer benodigde incidentinformatie vóór opruimen. Diagnose vraagt ook controle op suppressed-meldingen; voldoende diskruimte helpt niet als een logstorm belangrijke events door rate limiting laat verdwijnen.

3. NFS/Kerberos: lokaliseer de fout in de authenticatieketen

findmnt -t nfs,nfs4
nfsstat -m
klist
sudo klist -k /etc/krb5.keytab
getent hosts nfs01.example.net
timedatectl
sudo journalctl -u rpc-gssd -b --no-pager

Controleer DNS, tijdsynchronisatie, tickets, serviceprincipal, keytab en identiteit aan beide kanten. klist in de sessie van de beheerder zegt niet dat het applicatieaccount bruikbare credentials heeft. klist -k toont keytabprincipals, geen geheime sleutelbytes; voeg geen opties toe die sleutels tonen.

sec=krb5 levert Kerberos-authenticatie, krb5i voegt integriteitsbescherming toe en krb5p beschermt ook de vertrouwelijkheid van NFS-verkeer. De serverexport moet de gekozen beveiligingsflavour toestaan. Zie RHEL NFS-mountdocumentatie.

# Voorbeeld van een fstab-regel, uitsluitend na passende
# export-, realm-, keytab- en mountpointconfiguratie.
nfs01.example.net:/export/app /mnt/app nfs4 sec=krb5p,_netdev 0 0

rpc.gssd speelt normaal de clientrol; op de RHEL NFS-server handelt gssproxy Kerberos-authenticatie af voor rpc.nfsd. Onderzoek dus gssproxy en nfs-server-logs op de server, niet alleen rpc-gssd op de client. De RHEL-gids voor Kerberos met NFS beschrijft de rollen.

Als de mount slaagt maar bestandstoegang niet, controleer usercredentials, UID-/GID-mapping, ACL’s en exportrechten. Een werkende mount bewijst niet dat elk account toegang heeft. Test ticketvernieuwing en gedrag bij een tijdelijke serverstoring. Los autorisatie niet op door root_squash of Kerberos zonder analyse uit te zetten.

4. Repositories en versionlock: uitzonderingen met een einddatum

sudo dnf repolist --enabled
sudo subscription-manager release --show
sudo dnf versionlock list
sudo dnf list --showduplicates openssl

Gebruik versionlock uitsluitend met een reden, eigenaar en herbeoordelingsdatum. Een lock kan een incompatibele update voorkomen, maar ook een veiligheidsfix blokkeren. Het is geen volledige snapshot van alle dependencies. Stem repositorykanaal, release-lock, modulaire streams, excludes en Satellite-content op elkaar af.

# Demonstratie op een testhost met de DNF-versionlockplugin:
# Lock de momenteel geïnstalleerde openssl-versie(s).
sudo dnf versionlock add openssl
sudo dnf versionlock list
# Verwijder alleen deze gerichte uitzondering na beoordeling.
sudo dnf versionlock delete openssl

De DNF-versionlockdocumentatie legt uit hoe package-specificaties worden opgelost. Niet-transactionele opdrachten zoals list of repoquery kunnen versies tonen die een transactie door versionlock niet zal installeren. Gebruik die zichtbaarheid dus niet als bewijs dat de lock ineffectief is.

Enterprise-aandachtspunten en valkuilen

Neem tijdelijke bestanden, logging, NFS-authenticatie en package-uitzonderingen op in de platformacceptatie. Test reboot, langdurige uitvoering en herstel. Bewaar niet alleen configuratie, maar ook de motivatie: zeven dagen cleanup of een package-lock heeft een operationele eigenaar nodig.

Maak uitzonderingen aantoonbaar tijdelijk en beperk hun scope. Verifieer na elke wijziging de betreffende applicatiefunctie en de bedoelde securitygrens. Zo voorkom je dat een lokale storingsoplossing ongemerkt de nieuwe standaard voor alle hosts wordt.

Bronnen en versiecontrole

Technische referenties geraadpleegd op 30 september 2026. Controleer bij uitvoering de documentatie en manpages van de geïnstalleerde versie.

tmpfiles-regels en cleanup
PrivateTmp en uitvoercontext
Journald-opslag en limieten
NFS-mounts en securityflavours
NFS met Kerberos en gssproxy
DNF versionlock

Gerelateerde artikelen

RHEL 8 naar 9 met Leapp: voorbereiding, lifecycle en migratie
Red Hat Satellite: gecontroleerd patchen met content views
SELinux AVC-denials oplossen: contexts, booleans en policy

Ondersteuning bij jouw platform

Wil je deze aanpak vertalen naar jouw omgeving? Bekijk Linux Consultancy of neem contact op met DEWOLF.IT.