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] 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> |