Hier werden die Unterschiede zwischen zwei Versionen gezeigt.
|
admin_grundlagen:admin-suse-2022-12 [2022/12/09 14:22] carsten_strotmann angelegt |
admin_grundlagen:admin-suse-2022-12 [2022/12/09 14:26] (aktuell) carsten_strotmann [Pager] |
||
|---|---|---|---|
| Zeile 809: | Zeile 809: | ||
| `---- | `---- | ||
| + | Übung Backup-Restore: | ||
| + | |||
| + | Anleitung im Wiki unter "Backup / Bare-Metal Restore Suse Linux" | ||
| + | https://wiki.lab.linuxhotel.de/doku.php/admin_grundlagen:systemsicherung#backup_bare-metal_restore_suse_linux | ||
| + | |||
| + | Eigene Daten (Notizen, Konfigurationen etc) auf dem Laptop vorher | ||
| + | sichern (z.B. in das Etherpad kopieren oder per "scp" auf einen | ||
| + | anderen Laptop sichern) ! | ||
| + | |||
| + | In 2er Teams zusammen an der Übung arbeiten. Jeden Schritt gemeinsam | ||
| + | besprechen und gegenseitig prüfen. Bei Fehlern beim Backup kann | ||
| + | später der Laptop nicht wiederhergestellt werden und muss neu | ||
| + | installiert werden. | ||
| + | |||
| + | Erst ein Backup eines Laptops auf den Laptop des anderen | ||
| + | Team-Mitglieds durchführen. Danach diesen Laptop unbrauchbar machen | ||
| + | und wiederherstellen. Nach erfolgreicher Wiederherstellung die Rollen | ||
| + | tauschen und den anderen Laptop Sichern, unbrauchbar machen und | ||
| + | wiederherstellen. | ||
| + | |||
| + | Subvolumes welche gesichert werden: | ||
| + | / | ||
| + | /home | ||
| + | /opt | ||
| + | /srv | ||
| + | /var | ||
| + | /root | ||
| + | /usr/local | ||
| + | /tmp | ||
| + | /boot/grub2/x86_64-efi | ||
| + | /boot/grub2/i386-pc | ||
| + | |||
| + | Beispiel Datei /etc/fstab nach Wiederherstellung | ||
| + | |||
| + | /dev/nvme0n1p3 / btrfs defaults 0 0 | ||
| + | /dev/nvme0n1p3 /.snapshots btrfs subid=279 0 0 | ||
| + | /dev/nvme0n1p3 /var btrfs subvol=var 0 0 | ||
| + | /dev/nvme0n1p3 /usr/local btrfs subvol=usr-local 0 0 | ||
| + | /dev/nvme0n1p3 /tmp btrfs subvol=tmp 0 0 | ||
| + | /dev/nvme0n1p3 /srv btrfs subvol=srv 0 0 | ||
| + | /dev/nvme0n1p3 /root btrfs subvol=root 0 0 | ||
| + | /dev/nvme0n1p3 /opt btrfs subvol=opt 0 0 | ||
| + | /dev/nvme0n1p3 /home btrfs subvol=home 0 0 | ||
| + | /dev/nvme0n1p3 /boot/grub2/x86_64-efi btrfs subvol=x86_64-efi 0 0 | ||
| + | /dev/nvme0n1p3 /boot/grub2/i386-pc btrfs subvol=i386-pc 0 0 | ||
| + | |||
| + | /dev/nvme0n1p1 /boot/efi vfat rw 0 2 | ||
| + | /dev/nvme0n1p2 none swap sw 0 0 | ||
| + | |||
| + | BTRFS | ||
| + | 1) Erstelle ein RAID 10 (Stipe of Mirror) ueber die Partitionen 4-7 (4 Geräte) | ||
| + | mkfs.btrfs -f -m raid10 -d raid10 /dev/nvme0n1p4 /dev/nvme0n1p5 /dev/nvme0n1p6 /dev/nvme0n1p7 | ||
| + | 2) Erstelle einen Eintrag in der Datei /etc/fstab welche dieses BTRFS Dateisystem nach /srv/data | ||
| + | einhängt. Dabei sollen die Daten per 'zstd' Algorithmus transparent komprimiert werden | ||
| + | /dev/nvme0n1p4 /srv/data btrfs compress=zstd 0 0 | ||
| + | 3) Teste den Eintrag in der Filesystem-Tabelle (kann das Dateisystem angehangen werden?) | ||
| + | mount -a | ||
| + | 4) Führe ein Reboot des Laptops durch. Prüfe nach dem Reboot, das /srv/data eingehangen ist | ||
| + | 5) Das Dateisystem sollte eine Kapazität von ~4GB (unkomprimiert) besitzen. Teste die Komprimierung, | ||
| + | eine neue Datei von 6 GB bestehend aus vielen NULL Bytes erstellt wird (sollte ideal komprimiert werden) | ||
| + | dd if=/dev/zero of=/srv/data/grosse-datei-mit-nullen.dat bs=1M count=6000 | ||
| + | 6) Vergleiche die Ausgaben dieser Befehle | ||
| + | df -Th | ||
| + | du -sh /srv/data | ||
| + | btrfs filesystem show /srv/data | ||
| + | btrfs filesystem usage /srv/data | ||
| + | btrfs filesystem df /srv/data | ||
| + | |||
| + | BTRFS Quota | ||
| + | 1) Erstelle ein Subvolume /srv/data/subvol | ||
| + | btrfs subvol create /srv/data/subvol | ||
| + | 2) Schalte Quota-Support für dieses BTRFS Dateisystem an | ||
| + | btrfs quota enable /srv/data | ||
| + | 3) Setze ein Limit von 100 MB auf das neue Subvolume | ||
| + | btrfs qgroup limit 100M /srv/data/subvol | ||
| + | 4) Test des Quota (Schreibe eine neue 150 MB Datei) | ||
| + | dd if=/dev/urandom of=/srv/data/subvol/test.dat bs=1M count=150 | ||
| + | 5) Der Test sollte mit eine "Quota exceeded" Fehlermeldung abbrechen | ||
| + | |||
| + | Logical Volume Management | ||
| + | 1) Finde die Dokumentation zu LVM im Linuxhotel Wiki https://wiki.lab.linuhotel.de/ | ||
| + | 2) Hänge das BTRFS Dateisystem aus /srv/data aus | ||
| + | 3) Benutze den Befehl 'wipefs' (siehe Wiki) um die BTRFS Dateisysteme von Partition 4-7 zu löschen | ||
| + | 4) Erstelle ein neues PV (Physical Volume) auf Partition 4 | ||
| + | 5) Erstelle eine neue Volume Group auf dem PV | ||
| + | 6) Erstelle ein Logical Volume (LV) von 1GB in der Volume Group | ||
| + | 7) Formatiere das Logical Volume mit dem XFS Dateisystem (mkfs.xfs /dev/...) | ||
| + | 8) Binde dieses LV unter /srv/data ein (mount) | ||
| + | 9) Vergrössere das LV im laufenden Betrieb um 500 MB | ||
| + | 10) Lege ein 2tes PV auf der Partition 5 an | ||
| + | 11) Füge diese 2te PV der Volume Group hinzu | ||
| + | 12) Wandle das Logical Volume in ein RAID1 (Mirror) um | ||
| + | 13) Binde das LV in die Datei /etc/fstab ein (ersetze die alte BTRFS Konfiguration-Zeile) | ||
| + | 14) Teste die Filesystem-Tabelle mit "mount -a" | ||
| + | 15) Teste ein Reboot des Laptops. Das Dateisystem auf dem LV sollte automatisch unter /srv/data eingehangen sein | ||
| + | (mit "mount" oder "df -TH" testen) | ||
| + | |||
| + | Übung: CUPS Netzwerk-Druckdienst | ||
| + | 1) Der CUPS Netzwerkdruckdienst läuft unter Suse nur auf der Loopback-Schnittstelle | ||
| + | Wir wollen die CUPS Konfiguration ändern, so das der Dienst auch über das Netzwerk erreichbar ist | ||
| + | 2) In der Datei /etc/cups/cupsd.conf den Befehl "Listen 127.0.0.1:631" so ändern, das der Dienst auch | ||
| + | auf alle Netzwerkschnittstellen horcht | ||
| + | Listen 0.0.0.0:631 | ||
| + | 3) In der Datei /etc/cups/cupsd.conf für die Lokation (Location) "/" das Netz 192.168.1.0/24 erlauben | ||
| + | <Location /> | ||
| + | Order allow,deny | ||
| + | Allow from 192.168.1.* | ||
| + | </Location> | ||
| + | 4) Datei sichern und den CUPS-Dienst neu starten | ||
| + | systemctl restart cups | ||
| + | systemctl status cups | ||
| + | 5) Prüfen, das der Cups-Prozess nun auf allen IPv4 Adressen Daten entgegennimmt (Port 631) | ||
| + | lsof -Poni :631 | ||
| + | 6) Einen anderen Teilnehmer bitten, mit dem Firefox auf die eigene IP-Adresse auf Port 631 zu verbinden | ||
| + | http://192.168.1.2XX:631 | ||
| + | Dies sollte noch nicht möglich sein, da die Firewall die Verbindung unterbindet | ||
| + | 7) Port 631 in der Firewall freischalten | ||
| + | firewall-cmd --add-port=631/tcp | ||
| + | firewall-cmd --add-port=631/tcp --permanent | ||
| + | 8) Nochmals von einem anderen Rechner aus testen. Nun sollte die CUPS Admin Webseite erscheinen | ||
| + | |||
| + | Übung: NGINX Webserver | ||
| + | 1) Installiere den NGINX Webserver aus den Suse Paketquellen | ||
| + | 2) Passe die NGINX Konfiguration an, so das der Webserver auf der IP-Adresse des Laptops (Port 80) horcht | ||
| + | 3) Erstelle eine einfache HTML Webseite für den Webserver | ||
| + | 4) Erlaube den Webserver (per Port oder per Service) in der Firewall | ||
| + | 5) Starte den NGINX Webserver Dienst, stelle sicher das der Dienst erfolgreich gestartet wurde | ||
| + | 6) Lasse die Webseite von einem anderen Teilnehmer per http://192.168.1.2XX/ testen | ||
| + | | ||
| + | Übung zu RSyslog: | ||
| + | |||
| + | 1) Erzeuge eine neue Syslog-Regel-Datei unter /etc/rsyslog.d mit der Dateiendung ".frule". | ||
| + | Diese Regel soll alle Log-Meldungen der Facility (Anwendung) "local3" und der Wichtigkeit (Severity) "info" | ||
| + | in die Datei /var/log/mylogfile.log schreiben | ||
| + | |||
| + | Lösung: local3.info -/var/log/mylogfile.log | ||
| + | | ||
| + | 2) Den RSyslog-Dienst neu starten | ||
| + | systemctl restart rsyslog | ||
| + | 3) Lese die "man-page" Dokumentation zum Befehl "logger". Sende eine oder mehrere Log-Meldungen mit dem Befehl "logger" | ||
| + | mit der Facility "local3" und der Severity "info". Prüfe das diese Log-Informationen in der Log-Datei /var/log/mylogfile.log | ||
| + | erscheinen | ||
| + | 4) Schaue die Konfigurationsdatei /etc/rsyslog.d/remote.conf im Text-Editor an. Erstelle eine Regel in dieser Datei, welche | ||
| + | die Log-Meldungen der Facility "local3" (jede Severity) via UDP an den Laptop des Trainers (192.168.1.246) zum Syslogport (514) sendet | ||
| + | |||
| + | Lösung: local3.* @192.168.1.246 | ||
| + | |||
| + | 5) Starte den Dienst RSyslog neu | ||
| + | 6) Sende eine Log-Meldung für die Facility "local3" mit dem Befehl "logger" | ||
| + | 7) Schaue das diese Log-Meldung am Bildschirm des Trainers angezeigt wird | ||
| + | |||
| + | SSH mit Schlüssel | ||
| + | |||
| + | 1) Erstelle ein SSH-Schlüsselpaar auf dem Client (eigenes | ||
| + | Notebook). Bestaetige den Pfad der Schlüssel-Dateien und vergebe eine | ||
| + | Passphrase (langes Passwort). Der private Schlüssel wird mit diesem | ||
| + | Passwort verschlüsselt | ||
| + | ssh-keygen -t ed25519 | ||
| + | 2) Port 22 (SSH) in der Firewall auf dem Laptop freischalten | ||
| + | firewall-cmd --add-service=ssh --permanent | ||
| + | firewall-cmd --reload | ||
| + | 3) Sicherstellen das der SSH-Dienst gestartet ist | ||
| + | systemctl status sshd | ||
| + | 4) Den eigenen öffentlichen SSH-Schlüssel auf den entfernten Rechner (Laptop | ||
| + | des Partner-Teilnehmers) kopieren (XX=Nummer des Partner-Teilnehmers) | ||
| + | ssh-copy-id nutzerXX@192.168.1.2XX | ||
| + | 5) SSH-Verbindung testen. Statt des Passwortes sollte nun die Passphrase des | ||
| + | privaten Schlüssels gefragt werden | ||
| + | ssh nutzerXX@192.168.1.2XX | ||
| + | 6) Wenn die Anmeldung des Partner-Teilnehmers per SSH-Schlüssel am eigenen | ||
| + | Laptop funktioniert, dann in der SSH-Dienst Konfiguration die | ||
| + | Passwort-Anmeldung deaktivieren. In der Datei /etc/ssh/sshd_config | ||
| + | Alt -> PasswordAuthentication yes / UsePAM yes | ||
| + | Neu -> PasswordAuthentication no / UsePAM no | ||
| + | 7) SSH-Dienst neu starten | ||
| + | systemctl restart sshd | ||
| + | 8) Den Partner-Teilnehmer bitten, die Anmeldung per Schlüssel zu testen. Wenn | ||
| + | die Anmeldung per Schlüssel funktioniert, die Gegenprobe durchführen | ||
| + | (Anmeldung per Passwort). Für die Gegenprobe versuchen sich am Rechner per | ||
| + | SSH mit einem unbekannten Benutzer anzumelden (es sollte nicht nach einem | ||
| + | Passwort Gefragt werden): ssh unbekannt@192.168.1.2XX | ||
| + | |||
| + | SSH mit SSH-Agent | ||
| + | 0) Lokalen SSH-Agent laden (gilt nur in der aktuellen Shell, notwenig wenn | ||
| + | man nicht als an der grafischen Oberfläche angemeldeter Benutzer in der | ||
| + | Shell arbeitet) | ||
| + | eval $(ssh-agent) | ||
| + | 1) Privater Schlüssel in den SSH-Agent laden | ||
| + | ssh-add | ||
| + | 2) Schlüssel im Agent auflisten | ||
| + | ssh-add -l | ||
| + | 3) Wenn nun eine SSH Verbindung mit Schlüssel aufgebaut wird, so wird nicht | ||
| + | mehr nach der Passphrase gefragt. Bitte einmal ausprobieren | ||
| + | ssh nutzerXX@192.168.1.2XX | ||
| + | 4) SSH-Agent mit einem Passwort sperren (z.B. wenn man den Laptop einige Zeit | ||
| + | unbeaufsichtigt lässt) | ||
| + | ssh-add -x | ||
| + | 5) SSH-Agent wieder entsperren (grosses 'X') | ||
| + | ssh-add -X | ||
| + | 6) Alle Schlüssel aus dem SSH-Agent löschen | ||
| + | ssh-add -D | ||
| </code> | </code> | ||