Re: [Admin] Downtime Vereinsserver am Samstag, den 15.3.2014 ab 21 Uhr

Autor: Raphael Eiselstein <rabe_at_uugrn.org>
Datum: Sun, 16 Mar 2014 22:39:52 +0100
On Thu, Mar 13, 2014 at 08:49:57PM +0100, Raphael Eiselstein wrote:
> abschalten, da eine defekte Platte ausgebaut werden muss. Das ganze wird
> frühestens 21 Uhr stattfinden und dann wenn alles gut geht ca 30 Minuten
> dauern bis alle Jails wieder laufen.

Es gab natürlich weitere Probleme, die unabhängig vom Ausbau der
defekten Platte waren. Ich will hier mal so die "Kleinigkeiten"
zusammenzählen, die den Reboot verhindert haben.

1) Ich habe auf dem Vereinsserver ein /freebsd in allen Jails, welches
read-only in jedes einzelne Jail gemountet wird. /freebsd ist read-only
für alle bis auf das Build/Maintainance-Jail, in dem zB die Updates von
/freebsd/upstream/ports/ etc laufen. 

In der /etc/fstab von top3.uugrn.org (also direkt der Server) gab es 
analog zu den jails sowas:

/shared/freebsd         /freebsd             nullfs  ro,late      0 0

(BTW: Dank ZFS ist fstab ansonsten vollständig leer!)

*Leider* hatte ich vor Monaten das /shared/freebsd nach /tank/freebsd
umgezogen, das liegt auf einem anderen zpool. Ich hätte es weiter unter
/shared/freebsd belassen können, habe es aber nach /tank/freebsd
umgezogen, d.h. das zvol hat seinen mountpoint von "tank" geerbt und
nicht mehr lokal gesetzt. 

Bei Jails würde das dazu führen, dass sie sich nicht mehr starten lassen, 
das kann man dann sehr einfach korrigieren. 

Beim normalen Boot werden als "late" gekennzeichnete Filesysteme via
/etc/rc.d/mountlate gemountet. Wenn das fehlschlägt, dann bricht der
automatische Boot ab und man fällt in eine root-Shell auf /dev/console
von wo aus man dann manuell die /etc/fstab korrigieren kann und weiter
booten kann. 

Das ist *bevor* sshd oder lokale gettys auf VGA gestartet werden!


2) In der /boot/loader.conf hatte ich folgendes stehen:

console="comconsole"
comconsole_speed="115200"
comconsole_port="0xe1c0"
#comconsole_port="0xf0e0"

Das sorgt dafür, dass als console die via iAMT implementierte virtuelle
Serielle Schnittstelle als Console verwendet wird, zu der man sich dann
mittels "amtterm" verbinden kann (bei UUGRN_at_TWX findet das in einem
RfC1918-Netz statt, ist also nicht via Internet erreichbar)

*Allerdings* ist wohl das Zusammenspiel von FreeBSD mit dieser
virtuellen Seriellen Schnittstelle scheinbar instabil (auf einem anderen
ähnlichen Server tut es einwandfrei). Diese Instabilität zeigt sich
darin, dass der Verbindungsaufbau mittels amtterm nur manchmal klappt
und wenn dann nur für wenige Zeichen I/O, d.h. es reicht für ein paarmal
Enter um die Root-Shell zu sehen aber nicht mehr um dort ein Command
abzusetzen.

Sehr ärgerlich! Das System hatte also noch keine lokalen gettys laufen, 
kein ssh-daemon, allerdings schon bind9 (DNS-Server), wir hatten also 
effektiv keine Möglichkeit auf das abgebrochene System zuzugreifen.

Einzige Lösung (Danke an Jürgen):
* Server ausbauen, mit heimnehmen, Rescue-System booten und dann ...
  # zpool import -R /mnt zroot 
  # vi /mnt/boot/loader.conf
  # vi /mnt/etc/fstab
  # reboot
* Server testen, wieder ins RZ bringen und hochfahren. Tut.


Wie kann man solche und ähnliche Probleme künftig entschärfen?

* Für jeden Server im RZ mindestens ein betriebsbereites Rescue-Image
  vorbereiten und auf USB-Stick oder per PXE-Boot verfügbar machen.
        + Dieses spezielle Rescue-System muss so vollständig sein, dass 
          es sich die IP-Adrese des Servers zieht oder als Fallback auf 
          allen Interfaces DHCP versucht. 

        + Es muss einen sshd starten - egal wie, sobald auch nur 
          *irgendeine* IP-Adresse oder Interface hochgefahren ist. 
          Notfalls alle Minute per cronjob prüfen und ggf starten.

        + Außerdem muss über ein cronjob der Zugriff auf den sshd per 
          ssh-Tunnelüber einen Dritt-Rechner (am besten direkt per IP-
          Adresse nicht DNS-Eintrag) gewährleistet werden, damit man 
          auch dann noch auf das System zugreifen kann, wenn es 
          *irgendwo* hinter einem NAT-Router steht.

        + Es muss ein cronjob eingerichtet sein, der periodisch "nach 
          Hause" telefoniert und ggf. Scripte herunter lädt (wget, curl), 
          automatisch ausführt und den Output per Mail oder ssh oder curl 
          zurückliefert. Damit kann man gezielt bestimmte Aktionen
          triggern selbst wenn kein Zugriff/Login per SSH möglich ist

* Jeder Server sollte über einen zweiten (unabhängigen) SSH-Daemon
  verfügen, der sehr früh im Bootprozess auf einem alternativen Port
  hochgefahren wird. Dieser sollte speziell konfiguriert sein sodass
  nur root-Zugriffe von bestimmten Drittsystemen aus möglich sind.


Frohes Restwochenende!

Gruß
Raphael


-- 
Raphael Eiselstein <rabe@uugrn.org>               http://rabe.uugrn.org/
xmpp:freibyter@gmx.de  | https://www.xing.com/profile/Raphael_Eiselstein   
PGP (alt):            E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
PGP (neu):            4E63 5307 6F6A 036D 518D  3C4F 75EE EA14 F625 DB4E
.........|.........|.........|.........|.........|.........|.........|..



-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/

Empfangen am 16.03.2014

Dieses Archiv wurde generiert von hypermail 2.2.0 : 16.03.2014 CET