Aktuelle Version |
Dein Text |
Zeile 1: |
Zeile 1: |
| [[Server/srs2342 | srs2342]] ist die Bezeichnung für das System auf dem [[Server/fette Elke | Server ''fette Elke'']]. | | [[Server/srs2342 | srs2342]] ist die Bezeichnung für das System auf dem [[Server/fette Elke | Server ''fette Elke'']]. |
|
| |
| == Einrichtung ==
| |
| nach: RootOnZFS/UFSBoot[https://wiki.freebsd.org/RootOnZFS/UFSBoot]
| |
|
| |
| auf ada4 ist der Bootcode, kernel (/boot ada4s1a) und swap(ada4s1b) vorhanden.
| |
|
| |
|
| == weitere Konfigurationen == | | == weitere Konfigurationen == |
Zeile 24: |
Zeile 19: |
| === rc.conf === | | === rc.conf === |
|
| |
|
| ==== Konfiguration für Jails in der rc.conf ====
| | ; Konfiguration für Jails |
| : beispielsweise (Der Eintrag existiert so nicht und soll nur das bisherige Schema darstellen.) für eine Jail, die ''srs15'' wäre | | : beispielsweise (Der Eintrag existiert so nicht und soll nur das bisherige Schema darstellen.) für eine Jail, die ''srs15'' wäre |
| <pre> | | <pre> |
Zeile 40: |
Zeile 35: |
| == Daten == | | == Daten == |
|
| |
|
| Auf [[Server/srs2342]] liegen viele Daten. Nahezu alle sind Datasets mit [[ZFS]]. | | Auf [[Server/srs2342]] liegen viele Daten. |
| | |
| ==== Dataset der Jail ''srs2'' ====
| |
|
| |
|
| ===== Zerstörung vom Dataset für die Jail ''srs2'' ===== | | ==== dataset srs2 ==== |
|
| |
|
| [[Benutzer:PaulRiegel|Paul]] hat das Dataset zu ''srs2'' mit <code>zfs destroy -r</code> zerstört. | | [[Benutzer:PaulRiegel|Paul]] hat das Dataset zu ''srs2'' mit <code>zfs destroy -r</code> zerstört. |
Zeile 51: |
Zeile 44: |
|
| |
|
| [[srs2]] sollte, so schien es zumindest, bereits auf [[Server/srs1337]] umgezogen sein. | | [[srs2]] sollte, so schien es zumindest, bereits auf [[Server/srs1337]] umgezogen sein. |
|
| |
| == aufgetretene Probleme ==
| |
| mit
| |
| * vorgenommenen Maßnahmen
| |
| * möglichen Lösungen
| |
|
| |
| ==== 2015-08-24 ====
| |
|
| |
| ; Symptome:
| |
| * mindestens seit 2015-08-23 keine [[Mail]]s mehr [[stura.htw-dresden.de]] ausgeliefert
| |
| * Website bringt HTTP 503
| |
| * kein Anmelden per ssh mehr möglich (''timed out'')
| |
|
| |
| ; Vorgehen:
| |
| * Display angeschlossen
| |
| * Aussagen wie
| |
| <pre>
| |
| kern.maxfiles limit exceeded by uid 0, please see tuning(7)
| |
| </pre>
| |
| <pre>
| |
| kern.maxfiles limit exceeded by uid 25, please see tuning(7)
| |
| </pre>
| |
| <pre>
| |
| kern.maxfiles limit exceeded by uid 80, please see tuning(7)
| |
| </pre>
| |
| *: zur Kenntnis genommen.
| |
| * Tastatur angeschlossen
| |
| * Anmelden ist nicht mehr möglich (Account für das Anmelden kann noch eingegeben werden. Keine Rückmeldung mehr nach der Bestätigung des Passwortes.)
| |
| * (leidlicher Zwang zum) neu gestartet per ''Reset''
| |
| * Aussagen wie
| |
| <pre>
| |
| dev: bind: No space left on device
| |
| </pre>
| |
| <pre>
| |
| /var/run/clean_var: No space left on device
| |
| </pre>
| |
| *: zur Kenntnis genommen.
| |
| * angemeldet
| |
| * (per <code>su</code>) zu ''root'' gewechselt
| |
| * <code>zfs list</code> und <code>df -h</code> bestätigten den Verdacht, dass schlichtweg den Kapazität der Festplatte erschöpft ist.
| |
| * [[#Zerstörung vom Dataset für die Jail srs2]] vorgenommen
| |
| * neu gestartet (per <code>reboot</code>)
| |
| * Das Starten von [[Server/srs2342]] funktioniert soweit! :-)
| |
| * <code>fsck</code> und andere Späße zum Prüfen der Funktionalität vom Massenspeicher (Festplatten) durchgeführt
| |
|
| |
| * Jails (mit Diensten) arbeiten nicht richtig. (WTF!)
| |
| * (Es besteht keine Netzwerkverbindung für die Jails.) (Why?)
| |
| * …
| |
| * <code>ifconfig</code> wies für die Schnittstelle vom Netzwerk (''em0'' usw.) nur die IP-Adresse vom Hauptsystem auf, nicht aber von den Jails, obwohl <code>rc.conf</code> darauf hindeuten lies, dass auch dies (als ''alias'') IP-Adressen der Schnittstelle vom Netzwerk hätten sein sollen.
| |
| * Es stellte sich heraus, dass durch die Außerbetriebnahme einer Jail mit ''ifconfig_em0_alias0'' die erste Angabe von ''alias''es fehlte und somit kein einziger Eintrag für ''alias'' der Schnittstelle vom Netzwerk ''em0'' verwendet wurde.
| |
| * Fix! (''ifconfig_em0_alias0'' bis ''ifconfig_em0_alias<n>'' vergeben!)
| |
| * neu gestartet (per <code>reboot</code>)
| |
|
| |
| ; Läuft!
| |
|
| |
| * "kurzes" Spielen mit dem Problem, um Ursache fest zu bestimmen
| |
|
| |
| * per tmux bei [[PT]] für die Bestätigung der Vermutungen gedankt
| |
| * (Diskordia gedankt! (bedauert, dass keine Zeit für Huldigung verbleibt))
| |
|
| |
| * BTW: <code>service netif restart</code> hätte es vielleicht statt eines Neustartes nach dem Fix auch getan. :-/
| |
|
| |
| * Doku-foo!
| |
|
| |
| ==== 2016-09-08 ====
| |
|
| |
| ; Symptome:
| |
| * Website bringt HTTP 503
| |
| * kein Anmelden per ssh mehr möglich (''timed out'')
| |
| * Nach dem Neustart Bootet der Server nicht mehr.
| |
|
| |
| ; Vorgehen:
| |
| * Display angeschlossen
| |
| * Nach dem Neustart vom Server wird nur noch ein Blinken vom Cursor (nach dem Durchlaufen vom BIOS) angezeigt.
| |
| *: zur Kenntnis genommen.
| |
| *: Fu...!
| |
| * Es ist offensichtlich nur noch der 1. Massenspeicher (Festplatte) ansprechbar.
| |
|
| |
| * Tastatur angeschlossen
| |
| * Installation von [[FreeNAS]] (9.10) auf einen USB-Stick, der als zusätzliches Startmedium für den Server installiert
| |
| * Starten von FreeNAS vom passend installierten USB-Stick (als "externes" Startmedium)
| |
|
| |
| * Importieren vom (zum Glück noch) bestehenden Pool für ZFS
| |
| *: ''Storage'' -> ''Volumes'' -> ''Import Pool''
| |
| *: Holy ...! Hoffentlich geht hier jetzt nicht dadurch was flöten.
| |
| *: Läuft!
| |
|
| |
| * Zerstören von einem ersten überflüssigen Dataset für ZFS
| |
| *: Es soll damit abgesichert werden, dass das Problem nich ein "übergelaufene" (cow) Massenspeicher (Festplatte) ist.
| |
| ** Zerstören vom Dataset ''<pool>/jails/srs19''
| |
|
| |
| * Bewusst der Verzicht auf <code>zfs upgrade</code>, da das das nicht aktuell gehaltene Betriebssystem ([[FreeBSD]] 8.2) selbst wird nicht verwenden können und daher nicht mehr nutzbar wäre.
| |
|
| |
| * Es handelt sich beim Pool von ZFS ursprünglich um 3 Massenspeicher als ein Verbund mit raidz2.
| |
|
| |
| * <code>zpool scrub <pool></code> via WUI ausgelöst.
| |
| *: ''Storage'' -> ''Scrubs'' ( -> ''Add Scrub'' -> ''Every N hour'')
| |
| *: mit Fehlern auf der Festplatte dauert das "ewig" (scrub lief 10 Stunden!)
| |
|
| |
| * Es sind scheinbar nun wieder alle 3 Massenspeicher (Festplatten) ansprechbar.
| |
| * (Der Versuch zum eigenständigen Booten scheitert.)
| |
|
| |
| <pre></pre>
| |
| <pre>
| |
| Beginning ZFS volume imports
| |
| </pre>
| |
| <pre></pre>
| |
| * Mit dem Betrieb von gestarteten FreeNAS werden der 2. und 3. Massenspeicher versucht wieder mit in den Pool von ZFS aufzunehmen. (Es besteht arger Betrieb auf allen Platten.)
| |
| * Aktuellen Stand von SRS1 und SRS14 auf die [[Dicke Berta]] transferiert.
| |
| *: <code>zfs send primusinterpares/jails/srs1@CRASH-2016_09_09-09_22 | ssh -p 1005 root@srs1337.stura.htw-dresden.de zfs recv zroot/MIGRATION/fetteelke/jail_srs1_crash-2016_09_09-09_22</code>
| |
| *: <code>zfs send primusinterpares/jails/srs14@CRASH-2016_09_09-09_22 | ssh -p 1005 root@srs1337.stura.htw-dresden.de zfs recv zroot/MIGRATION/fetteelke/jail_srs14_crash-2016_09_09-09_22
| |
| </code>
| |
| * ZFS Einhängepunkte gesetzt:
| |
| *: <code>zfs set mountpoint=legacy primusinterpares</code>
| |
| *: <code>zfs set mountpoint=/tmp primusinterpares/tmp</code>
| |
| *: <code>zfs set mountpoint=/usr primusinterpares/usr</code>
| |
| *: <code>zfs set mountpoint=/var primusinterpares/var</code>
| |
| *: <code>zfs set mountpoint=/usr/home/jails/srs1 primusinterpares/jails/srs1</code>
| |
| *: <code>zfs set mountpoint=/usr/home/jails/srs14 primusinterpares/jails/srs14</code>
| |
| * Bevor neugestartet werden kann muss das Bootdevice im BIOS auf die SATA-PM* eingestellt werden.
| |
| * Nach dem alle Einhängepunkte gesetzt sind, startet das System wieder.
| |
|
| |
| ==== 2017-12-03 ====
| |
|
| |
| ; Symptome
| |
| ''srs2342.stura.htw-dresden.de'' (und alle anderen Domains, die auf den Server zeigen (so leider auch noch mail.stura.htw-dresden.de)) sind nicht erreichbar.
| |
|
| |
| ; Vorgehen:
| |
| * <s>Anmeldung & Co, um Festzustellen, dass der Server keine Netzwerkverbindung hat.</s>
| |
| * (lockeres) Netzwerkkabel wieder "eingesteckt".
| |
| ; Läuft!
| |
|
| |
| ; weitere Entdeckung:
| |
| <pre>
| |
| srs2342 sm-mta[]: : SYSERR(root): MX list for stura.htw-dresden.de points back to srs2342.stura.htw-dresden.de
| |
| srs2342 sm-mta[]: : SYSERR(root): Losing ./ : savemail panic
| |
| srs2342 sm-mta[]: : SYSERR(root): cannot save rejected email anywhere
| |
| srs2342 sm-mta[]: : SYSERR(root): Losing ./ : savemail panic
| |
| </pre>
| |
| Ja, das mit diesem Mail und diesem Monitoring müsste mal werden, wa? :-D :-/
| |
|
| |
|
| == Siehe auch == | | == Siehe auch == |