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

[Raphael Eiselstein <rabe@xxxxxxxxx>]

On Thu, Mar 13, 2014 at 08:49:57PM +0100, Raphael Eiselstein wrote:
> abschalten, da eine defekte Platte ausgebaut werden muss. Das ganze wird
> fruehestens 21 Uhr stattfinden und dann wenn alles gut geht ca 30 Minuten
> dauern bis alle Jails wieder laufen.

Es gab natuerlich weitere Probleme, die unabhaengig vom Ausbau der
defekten Platte waren. Ich will hier mal so die "Kleinigkeiten"
zusammenzaehlen, 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
fuer 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 vollstaendig leer!)

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

Bei Jails wuerde das dazu fuehren, 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 fehlschlaegt, dann bricht der
automatische Boot ab und man faellt 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 dafuer, 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@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
aehnlichen Server tut es einwandfrei). Diese Instabilitaet zeigt sich
darin, dass der Verbindungsaufbau mittels amtterm nur manchmal klappt
und wenn dann nur fuer wenige Zeichen I/O, d.h. es reicht fuer ein paarmal
Enter um die Root-Shell zu sehen aber nicht mehr um dort ein Command
abzusetzen.

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

Einzige Loesung (Danke an Juergen):
* 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 aehnliche Probleme kuenftig entschaerfen?

* Fuer jeden Server im RZ mindestens ein betriebsbereites Rescue-Image
  vorbereiten und auf USB-Stick oder per PXE-Boot verfuegbar machen.
        + Dieses spezielle Rescue-System muss so vollstaendig 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 pruefen und ggf starten.

        + Ausserdem muss ueber ein cronjob der Zugriff auf den sshd per 
          ssh-Tunnelueber einen Dritt-Rechner (am besten direkt per IP-
          Adresse nicht DNS-Eintrag) gewaehrleistet 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 laedt (wget, curl), 
          automatisch ausfuehrt und den Output per Mail oder ssh oder curl 
          zurueckliefert. Damit kann man gezielt bestimmte Aktionen
          triggern selbst wenn kein Zugriff/Login per SSH moeglich ist

* Jeder Server sollte ueber einen zweiten (unabhaengigen) SSH-Daemon
  verfuegen, der sehr frueh im Bootprozess auf einem alternativen Port
  hochgefahren wird. Dieser sollte speziell konfiguriert sein sodass
  nur root-Zugriffe von bestimmten Drittsystemen aus moeglich sind.


Frohes Restwochenende!

Gruss
Raphael


-- 
Raphael Eiselstein <rabe@xxxxxxxxx>               http://rabe.uugrn.org/
xmpp:freibyter@xxxxxx  | 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/