Server/srs2342: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
K (→2017-12-03) |
|||
(15 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt) | |||
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 19: | Zeile 24: | ||
=== rc.conf === | === 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 | : beispielsweise (Der Eintrag existiert so nicht und soll nur das bisherige Schema darstellen.) für eine Jail, die ''srs15'' wäre | ||
<pre> | <pre> | ||
Zeile 32: | Zeile 37: | ||
* Es ist darauf zu achten, dass <code>alias</code> von <code>0</code> 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. | * Es ist darauf zu achten, dass <code>alias</code> von <code>0</code> 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!) | *: 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'' ===== | |||
[[Benutzer:PaulRiegel|Paul]] hat das Dataset zu ''srs2'' mit <code>zfs destroy -r</code> 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 [[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 == |
Aktuelle Version vom 3. Dezember 2017, 04:26 Uhr
srs2342 ist die Bezeichnung für das System auf dem Server fette Elke.
Einrichtung[Bearbeiten]
nach: RootOnZFS/UFSBoot[1]
auf ada4 ist der Bootcode, kernel (/boot ada4s1a) und swap(ada4s1b) vorhanden.
weitere Konfigurationen[Bearbeiten]
loader.conf[Bearbeiten]
- 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[Bearbeiten]
kern.ipc.somaxconn=1024 #mögliche Verbindungen erhöhen
security.jail.allow_raw_sockets=1 # Jail kann raw-socket
rc.conf[Bearbeiten]
Konfiguration für Jails in der rc.conf[Bearbeiten]
- 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
von0
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[Bearbeiten]
Auf Server/srs2342 liegen viele Daten. Nahezu alle sind Datasets mit ZFS.
Dataset der Jail srs2[Bearbeiten]
Zerstörung vom Dataset für die Jail srs2[Bearbeiten]
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[Bearbeiten]
mit
- vorgenommenen Maßnahmen
- möglichen Lösungen
2015-08-24[Bearbeiten]
- 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
unddf -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, obwohlrc.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[Bearbeiten]
- 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
zfs set mountpoint=/usr/home/jails/srs1 primusinterpares/jails/srs1
zfs set mountpoint=/usr/home/jails/srs14 primusinterpares/jails/srs14
- 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[Bearbeiten]
- 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
Anmeldung & Co, um Festzustellen, dass der Server keine Netzwerkverbindung hat.- (lockeres) Netzwerkkabel wieder "eingesteckt".
- Läuft!
- weitere Entdeckung
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
Ja, das mit diesem Mail und diesem Monitoring müsste mal werden, wa? :-D :-/