Re: [Admin] Mitglieder-Jails updaten

[Raphael Eiselstein <rabe@xxxxxxxxx>]

Hallo Michael,

On Sat, Jan 29, 2011 at 09:55:42AM +0100, Michael Lestinsky wrote:
> Am 28.01.11 20:34, schrieb Raphael Eiselstein:
> > Es ist *unbedingt* erforderlich, dass alle Jails in absehbarer Zeit ein 
> > Update erhalten. Insbesondere solche, die von aussen erreichbare Dienste 
> > betreiben und vor allem alle, die Webseiten mit PHP von extern 
> > erreichbar haben.
> 
> Kannst du dass naeher erleutern? Sind davon auch Jails betroffen, in denen
> die installierten Ports (PHP) selbst gepflegt werden? Oder ist das ein
> Zusammenspiel mit der konkreten Basis-Version des Jails?

Es gibt ansich 2 unterschiedliche Dinge zu beachten: 

* Basissystem 
* Ports/Packages

Da Ports je nach Konfiguration auch von Libraries aus dem Basissystem
abhaengig sind (openssl, bzip2, ... ) sind auch aktuelle Ports anfaellig
fuer Luecken in nicht aktuellen Libraries:

20101129:       p4      FreeBSD-SA-10:10.openssl
        Fix OpenSSL multiple vulnerabilities.

20100920:       p3      FreeBSD-SA-10:08.bzip2
        Fix an integer overflow in RLE length parsing when decompressing
        corrupt bzip2 data.

20100713:       p2      FreeBSD-SA-10:07.mbuf
        Correctly copy the M_RDONLY flag when duplicating a reference
        to an mbuf external buffer.

20100526:       p1      FreeBSD-SA-10:05.opie,
FreeBSD-SA-10:06.nfsclient
        Fix a one-NUL-byte buffer overflow in libopie. [10:05]

        Correctly sanity-check a buffer length in nfs mount. [10:06]

20100323:
        FreeBSD 7.3-RELEASE


In 7.3-RELEASE sind also -p3 und -p4 dringend erforderlich, wenn man die
betroffenen Teile irgendwo verwendet.


Ports/Packages: Fuer Jailowner, die nicht alles selbst aus Sourcen
kompilieren, biete ich seit 2 Jahren oder laenger vorkompilierte
*aktuelle* und vor allem *getestete* Packages an. Das sorgt dafuer, dass
man selbst bei halbwegs maroden Jails noch durch einfaches "pkg_delete"
und "pkg_add" Dinge wieder geradeziehen kann, was deutlich mehr Aufwand
waere, waere ein marodes Jail nur aus Sourcen gebaut.
 
> portaudit meckert in meinem Jail gegenwaertig jedenfalls zu keinem meiner Ports.

Das ist schonmal gut, aber eben noch nicht 100%.

Mein Angebot mit den Ports gilt allen, die nicht viel Erfahrung mit 
komplizierten Upgrades haben und daher Support von mir bekommen.

Das Upgrade des Basissystems ist im Jail nicht ohne weiteres moeglich (zB
weil man im Jail keine immutable flags aendern kann):

security.jail.chflags_allowed: 0
 
> > PS: Wenn ich von einzelnen Jailownern gar kein Feedback bekomme, werde
> > ich die entsprechenden Jails irgendwann zwangsweise stillegen muessen.
> 
> Gib mal bitte einen Zeitplan vor.

Das Stillegen der Jails wird spaetestens dann erforderlich, wenn diese
nach einem Major-Release-Upgrade nicht mehr sinnvoll funktionieren. Das
waere potenziell der Fall, sobald top.uugrn.org auf 8.x-RELEASE angehoben
wird. Da ich derzeit noch keinen Server mit 8.2-RELEASE laufen habe,
kann ich da auch nicht testen, wie kompatibel die 7.<uralt>-Jails darin
funktionieren. Kritisch sind hier alle Tools, die im Jail funktionieren
und relativ nah mit dem Kernel kommunizieren, zB "ps",
"sockstat"/"netstat", ... 

Schlimmstenfalls aeussert sich eine Inkompatiblitaet im Fehlerfall durch 
hohen Ressourcenverbrauch (CPU/RAM).

Jails, die nicht mehr sinnvoll laufen koennen oft nur noch mit der
Brechstange upgegraded werden. Einige Jails auf dem Vereinsserver laufen
noch mit 6.x-Userland und sind im Grunde genommen jetzt schon nicht mehr
sinnvoll benutzbar (auch wenns noch "irgendwie" funktioniert). 

Jails, die 2 Jahre nicht upgegraded wurden sind in meinen Augen ohnehin
nicht gepflegt und sollten dringend mal angefasst werden.

Ich will wenns geht noch in Q1/2011 mit 8.2-RELEASE auf top.uugrn.org
weitermachen. Bis dahin sollten alle installierten Jails entweder
upgedatet, reinstalliert oder geloescht sein, da ein Major-Upgrade in den
Jails nochmal viel Aufwand sein wird. 

Wenn alle Jails aber auf dem gleichen Stand sind, kann ich Upgrade-Szenarien
ausprobieren, bevor ich sie "LIVE" ausrolle. Wenn wir auf dem Server aber 
20 verschiedene Staende von ungepflegten Jails haben, wird jedes Jail-Upgrade 
eine neue Ueberraschung. Upgrades ergeben immer irgendwelche Bugs, auf die man
reagieren muss. Wenn diese Bugs vorab bekannt sind, kann man proaktiv
Workarounds schaffen und sich unnoetige Fehlversuche ersparen.

Beispiel: Ich habe in ca 2 Tagen 8 Jails aktualisiert, die ich alle
selbst pflege, d.h. die hatten alle den gleichen Stand. Alle hatten die
gleichen Bugs und ich konnte mir eine nette Checkliste schreiben, mit
der ich sicher stellen konnte, dass ich bei allen Jails alle Bugs
beseitigt habe. 

Ich spekuliere dausserdem arauf, dass diverse Jails mangels Interesse nicht 
weiter betrieben werden und ich mir somit den Aufwand erspare, irgendwelche 
Jail-Leichen upzugraden, bei denen sich die Owner nicht mehr verantwortlich 
fuehlen. 


> Bye,
> Michael

Gruss
Raphael

-- 
Raphael Eiselstein <rabe@xxxxxxxxx>               http://rabe.uugrn.org/
xmpp:freibyterægmx.de  | https://www.xing.com/profile/Raphael_Eiselstein   
GnuPG:                E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
.........|.........|.........|.........|.........|.........|.........|..



-- 
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/