Server/srs2342

srs2342 ist die Bezeichnung für das System auf dem Server fette Elke.

Einrichtung

nach: RootOnZFS/UFSBoot[1]

auf ada4 ist der Bootcode, kernel (/boot ada4s1a) und swap(ada4s1b) vorhanden.

weitere Konfigurationen

loader.conf

• für den apache Eintrag anlegen

accf_data_load="YES" # Wait for data accept filter
accf_http_load="YES" # Wait for full HTTP request accept filter

sysctl.conf

kern.ipc.somaxconn=1024  #mögliche Verbindungen erhöhen
security.jail.allow_raw_sockets=1   # Jail kann raw-socket

rc.conf

Konfiguration für Jails in der rc.conf

beispielsweise (Der Eintrag existiert so nicht und soll nur das bisherige Schema darstellen.) für eine Jail, die srs15 wäre

ifconfig_em0_alias0="inet 141.56.50.15 netmask 255.255.255.0" # IP-Adresse der Jail als alias für die Schnittstelle des Netzwerkes vom Hauptsystem
jail_srs15_rootdir="/usr/home/jails/srs15"                    # Hauptverzeichnis der Jail im Hauptsystem
jail_srs15_hostname="srs15.stura.htw-dresden.de"              # hostname der Jail
jail_srs15_ip="141.56.50.15"                                  # IP-Adresse der Jail
jail_srs15_devfs_enable="YES"                                 # Einhaengen von devfs in der Jail
jail_srs15_devfs_ruleset="devfsrules_jail"                    # Regelwerk zu devfs das fuer die Jail angewendet wird

• Es ist darauf zu achten, dass alias von 0 beginnend fortlaufend vergeben werden. (Die Anordnung innerhalb der rc.conf ist nicht relevant.) Ansonsten werden gar keine aliases vergeben und somit haben alle Jails keine Netz, da sie nicht über das interface erreicht werden können.

  Im Übrigen wird die Art wohl bald obsolet sein, denn alle Instanzen sollen zu Server/srs1337 umgezogen werden und danach Server/srs2342 neu aufgesetzt werden. (Wir werden sehen was dann kommt und wie das da läuft. Wenn es ein normales FreeBSD wird: ezjail oder iocage nutzen!)

Daten

Auf Server/srs2342 liegen viele Daten. Nahezu alle sind Datasets mit ZFS.

Dataset der Jail srs2

Zerstörung vom Dataset für die Jail srs2

Paul hat das Dataset zu srs2 mit zfs destroy -r zerstört.

• Es bestand Handlungsbedarf, da die Kapazitäten an Speicherplatz erschöpft waren. Somit lief keiner der Dienste auf Server/srs2342 mehr richtig. Dabei handelte es sich auch um wichtige Dienste wie Website (srs1) und Mail (srs14).

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 Mails mehr stura.htw-dresden.de ausgeliefert
• Website bringt HTTP 503
• kein Anmelden per ssh mehr möglich (timed out)

Vorgehen

• Display angeschlossen
• Aussagen wie

kern.maxfiles limit exceeded by uid 0, please see tuning(7)

kern.maxfiles limit exceeded by uid 25, please see tuning(7)

kern.maxfiles limit exceeded by uid 80, please see tuning(7)

• 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

dev: bind: No space left on device

/var/run/clean_var: No space left on device

• zur Kenntnis genommen.

• angemeldet
• (per su) zu root gewechselt
• zfs list und df -h 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 reboot)
• Das Starten von Server/srs2342 funktioniert soweit! :-)
• fsck 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?)
• …
• ifconfig wies für die Schnittstelle vom Netzwerk (em0 usw.) nur die IP-Adresse vom Hauptsystem auf, nicht aber von den Jails, obwohl rc.conf 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 aliases 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 reboot)

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: service netif restart 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 zfs upgrade, 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.

• zpool scrub <pool> 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.)

Beginning ZFS volume imports

• 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.

  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

  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

• ZFS Einhängepunkte gesetzt:

  zfs set mountpoint=legacy primusinterpares

  zfs set mountpoint=/tmp primusinterpares/tmp

  zfs set mountpoint=/usr primusinterpares/usr

  zfs set mountpoint=/var primusinterpares/var

• Nach dem Neustart des Systems wird /dev in den Jails SRS1 und SRS14 nicht gefunden und können daher nicht starten.

Siehe auch

• Ports auf dem Hauptsystem srs2342
• Jails auf dem Hauptsystem srs2342
• Server/fette Elke