Einführung
Dieses abschließende geführte Lab fasst verschiedene für die RHCSA-Prüfung relevante Fähigkeiten zusammen. Sie erhalten zwar weiterhin Anleitungen zu den Befehlen, die Schritte orientieren sich jedoch stärker an einem realen administrativen Validierungs-Workflow: das System inspizieren, den erforderlichen Zustand konfigurieren und das Endergebnis mit Standard-Tools verifizieren.
In diesem Lab erstellen Sie eine lokale Benutzeridentität für Operatoren, bereiten persistenten Speicher vor, stellen einen kleinen Dienst von diesem Speicher aus bereit, fügen SELinux- und Firewall-Richtlinien hinzu und führen eine abschließende Überprüfung der Einsatzbereitschaft durch.
Das vorbereitete System inspizieren
In diesem Schritt inspizieren Sie die für den abschließenden Workflow vorbereiteten Ressourcen. Beginnen Sie damit, das Blockgerät, den Dienststatus und den SELinux-Modus zu bestätigen.
Die Vorbereitung erhält die Freigaben für SSH und das LabEx-Browserterminal auf 3002/tcp dauerhaft in der Zone public. Behalten Sie diese Verwaltungsregeln bei, wenn Sie die Firewall-Richtlinie für die Anwendung ändern.
Wechseln Sie in das Projektverzeichnis.
cd /home/labex/project
Lassen Sie sich den Pfad der vorbereiteten Partition anzeigen. Spätere Befehle verwenden diesen Pfad wieder, sodass Sie nicht raten müssen, welches Blockgerät zum Lab gehört.
cat /home/labex/project/rhcsa-final-part
Inspizieren Sie das vorbereitete Blockgerät. Es verfügt noch über kein Dateisystem; dies ist also Ihr Ausgangszustand vor der Formatierung.
lsblk "$(cat /home/labex/project/rhcsa-final-part)"
Überprüfen Sie, ob der finale Dienst noch nicht konfiguriert wurde. Der Zusatz || true sorgt dafür, dass das Lab fortgesetzt wird, auch wenn die Unit zu diesem Zeitpunkt noch nicht vorhanden ist.
systemctl status rhcsa-final-web.service --no-pager || true
Bestätigen Sie, dass SELinux im Modus Enforcing läuft, bevor Sie beginnen. Der Enforcing-Modus ist wichtig, da die späteren SELinux-Labels nicht nur informativ sind, sondern bestimmen, ob die Richtlinien tatsächlich angewendet werden.
getenforce
Operator-Identität und freigegebenes Verzeichnis erstellen
In diesem Schritt erstellen Sie eine lokale Gruppe, einen lokalen Benutzer und ein freigegebenes Verzeichnis mit gesetztem setgid-Bit. Die Befehle sind so geschrieben, dass sie sicher sind, falls Sie sie erneut ausführen müssen.
Erstellen Sie die Gruppe, falls sie noch nicht existiert. getent group prüft zuerst den lokalen Namensdienst, und der ||-Teil erstellt die Gruppe nur, wenn die Suche fehlschlägt.
getent group rhcsaops || sudo groupadd rhcsaops
Erstellen Sie den Benutzer finaladmin, falls er noch nicht existiert.
id finaladmin >/dev/null 2>&1 || sudo useradd -m -s /bin/bash -G rhcsaops finaladmin
Stellen Sie sicher, dass der Benutzer Mitglied der Operator-Gruppe ist. Die Optionen -aG fügen die Gruppenmitgliedschaft hinzu, anstatt die bestehenden ergänzenden Gruppen des Benutzers zu ersetzen.
sudo usermod -aG rhcsaops finaladmin
id finaladmin
Erstellen Sie ein freigegebenes Verzeichnis für Operator-Notizen. Der Modus 2770 gewährt der Gruppe vollen Zugriff und setzt das setgid-Bit, sodass neue Dateien automatisch die Gruppe rhcsaops erben.
sudo mkdir -p /srv/rhcsa-final/team
sudo chown root:rhcsaops /srv/rhcsa-final/team
sudo chmod 2770 /srv/rhcsa-final/team
Erstellen Sie eine Testdatei als Benutzer finaladmin.
sudo -u finaladmin bash -c 'echo final validation access > /srv/rhcsa-final/team/finaladmin.txt'
Inspizieren Sie das Verzeichnis und die Datei.
sudo stat -c '%a %U:%G %n' /srv/rhcsa-final/team /srv/rhcsa-final/team/finaladmin.txt
Persistenten Speicher vorbereiten
In diesem Schritt erstellen Sie ein Dateisystem auf der vorbereiteten Partition und binden es persistent über die UUID ein. Dies spiegelt das Muster der Speichervalidierung wider, das bei Aufgaben im RHCSA-Stil verwendet wird.
Speichern Sie den Pfad der vorbereiteten Partition in einer Shell-Variablen.
part="$(cat /home/labex/project/rhcsa-final-part)"
Erstellen Sie ein ext4-Dateisystem mit einem erkennbaren Label. Da dies die vorbereitete Übungspartition überschreibt, führen Sie diesen Schritt erst aus, nachdem Sie den Gerätepfad bestätigt haben.
sudo mkfs.ext4 -F -L RHCSA_FINAL "$part"
Erstellen Sie den Mount-Punkt.
sudo mkdir -p /mnt/rhcsa-final
Ermitteln Sie die UUID des Dateisystems und entfernen Sie eventuelle alte Einträge für diesen Mount-Punkt aus der /etc/fstab. UUIDs sind stabile Identifikatoren für persistente Mounts; das Entfernen alter Zeilen verhindert doppelte Einträge in der fstab.
uuid="$(sudo blkid -s UUID -o value "$part")"
sudo sed -i '/\/mnt\/rhcsa-final/d' /etc/fstab
Fügen Sie den Eintrag für den persistenten Mount hinzu.
echo "UUID=$uuid /mnt/rhcsa-final ext4 defaults 0 0" | sudo tee -a /etc/fstab
Binden Sie das Dateisystem gemäß fstab ein und überprüfen Sie das Ergebnis. mount -a beweist, dass der fstab-Eintrag korrekt ist, während findmnt und df das Mount-Ziel und die verfügbare Kapazität bestätigen.
sudo mount -a
findmnt /mnt/rhcsa-final
df -h /mnt/rhcsa-final
Den finalen Dienst bereitstellen und aktivieren
In diesem Schritt legen Sie Webinhalte auf dem eingebundenen Dateisystem ab und erstellen einen systemd-Dienst, der diese lokal auf Port 18083 bereitstellt.
Erstellen Sie das Verzeichnis für die Webinhalte.
sudo mkdir -p /mnt/rhcsa-final/www
Erstellen Sie die Inhaltsdatei.
echo "RHCSA final validation service" | sudo tee /mnt/rhcsa-final/www/index.html >/dev/null
Setzen Sie die Berechtigungen so, dass der Dienstbenutzer labex die Inhalte lesen kann, ohne dass sie für alle schreibbar sind. Der Dienst benötigt lediglich Lesezugriff für die Gruppe und das Recht, das Verzeichnis zu durchlaufen, nicht jedoch umfassende Schreibrechte.
sudo chown -R root:labex /mnt/rhcsa-final/www
sudo chmod 750 /mnt/rhcsa-final/www
sudo chmod 640 /mnt/rhcsa-final/www/index.html
Erstellen Sie die Service-Unit. Der Dienst läuft aus dem eingebundenen Inhaltsverzeichnis und bindet sich an localhost auf Port 18083, was eine lokale Validierung mit curl erleichtert.
sudo tee /etc/systemd/system/rhcsa-final-web.service >/dev/null <<'EOF'
[Unit]
Description=RHCSA final validation web service
After=network.target
[Service]
Type=simple
User=labex
Group=labex
WorkingDirectory=/mnt/rhcsa-final/www
ExecStart=/usr/bin/python3 -m http.server 18083 --bind 127.0.0.1
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
Sichern Sie die Unit-Datei, laden Sie systemd neu und aktivieren Sie den Dienst. Unit-Dateien unter /etc/systemd/system sollten dem Benutzer root gehören. daemon-reload sorgt dafür, dass systemd die neue Unit einliest, bevor Sie sie aktivieren und neu starten.
sudo chown root:root /etc/systemd/system/rhcsa-final-web.service
sudo chmod 644 /etc/systemd/system/rhcsa-final-web.service
sudo systemctl daemon-reload
sudo systemctl enable rhcsa-final-web.service
sudo systemctl restart rhcsa-final-web.service
sleep 1
Testen Sie den Dienst.
systemctl is-active rhcsa-final-web.service
curl -s http://127.0.0.1:18083/
SELinux- und Firewall-Richtlinien hinzufügen
In diesem Schritt vervollständigen Sie die Dienstrichtlinien. Fügen Sie persistente SELinux-Labels für den Inhalt und den Port hinzu und öffnen Sie den Port in der Firewall.
Fügen Sie die persistente Dateikontext-Regel hinzu oder aktualisieren Sie sie. Das ||-Muster macht diesen Befehl sicher für wiederholte Ausführungen: Er fügt die Regel hinzu, wenn sie fehlt, und ändert sie, falls der Pfad bereits eine benutzerdefinierte Regel hat.
sudo semanage fcontext -a -t httpd_sys_content_t '/mnt/rhcsa-final/www(/.*)?' || sudo semanage fcontext -m -t httpd_sys_content_t '/mnt/rhcsa-final/www(/.*)?'
Wenden Sie die Kontextregel an. restorecon passt die aktuellen Dateilabels an die soeben erstellte persistente SELinux-Regel an.
sudo restorecon -Rv /mnt/rhcsa-final/www
Fügen Sie das SELinux-Label für den HTTP-Port hinzu oder aktualisieren Sie es. Das Add-or-Modify-Muster funktioniert sowohl bei einem frischen System als auch bei einer erneuten Ausführung, falls das Port-Label bereits existiert.
sudo semanage port -a -t http_port_t -p tcp 18083 || sudo semanage port -m -t http_port_t -p tcp 18083
Starten Sie firewalld und öffnen Sie den Dienst-Port dauerhaft.
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-port=18083/tcp
sudo firewall-cmd --reload
Inspizieren Sie die Labels und den Firewall-Status. Diese Prüfungen verknüpfen die Richtlinienkonfiguration mit dem beobachtbaren Zustand: Dateilabel, erlaubter HTTP-Port-Typ und offener Firewall-Port.
ls -Z /mnt/rhcsa-final/www/index.html
sudo semanage port -l | grep '^http_port_t'
sudo firewall-cmd --list-ports
Die abschließende Überprüfung der Einsatzbereitschaft durchführen
In diesem Schritt validieren Sie den vollständigen Systemzustand mit denselben Tools, die Sie während des gesamten Kurses verwendet haben. Dies ist kein schriftlicher Bericht, sondern eine operative Überprüfung.
Überprüfen Sie die lokale Identität und die Gruppenmitgliedschaft.
id finaladmin
getent group rhcsaops
Überprüfen Sie den persistenten Speicher. Sie verifizieren sowohl den aktiven Mount als auch den gespeicherten fstab-Eintrag, da nur beides zusammen die Speicheranforderungen vollständig erfüllt.
findmnt /mnt/rhcsa-final
grep /mnt/rhcsa-final /etc/fstab
Überprüfen Sie den Dienst.
systemctl is-enabled rhcsa-final-web.service
systemctl is-active rhcsa-final-web.service
curl -s http://127.0.0.1:18083/
Überprüfen Sie SELinux und firewalld. Der finale Zustand sollte ein SELinux im Enforcing-Modus, das korrekte HTTP-Inhaltslabel auf der Dienstdatei und den offenen Port 18083/tcp in der Firewall zeigen.
getenforce
ls -Z /mnt/rhcsa-final/www/index.html
sudo firewall-cmd --list-ports
Zusammenfassung
Sie haben einen abschließenden geführten Workflow zur Einsatzbereitschaft abgeschlossen, indem Sie eine Operator-Identität, ein freigegebenes Verzeichnis mit setgid-Bit, persistenten Speicher, einen systemd-Dienst, SELinux-Datei- und Port-Labels, die Firewall-Freigabe sowie eine befehlsbasierte finale Validierung konfiguriert haben.
