UUGRN Admin

Im Zuge von HeartBleed musste kurzfristig alles aktualisiert werden, was auf OpenSSL 1.0.1 für xzahlreiche Softwareupdates für shell.uugrn.org

Have fun!
Raphael

UUGRN e.V. hat sich ein richtiges Wildcard-Zertifikat für seine verschiedenen SSL basierten Dienste geleistet. Da wir davon ausgehen, dass dieses Zertifikat von nahezu allen Clients akzeptiert wird, haben wir alle SSL basierten Dienste darauf umgestellt.

Have fun!

Raphael

Wir fahren auf unseren Vereinsservern noch weitgehend das alte FreeBSD 7.2. Dieses hatte am 30.6.2010 seinen offiziellen End-of-Live Termin und wird daher nicht mehr supportet. Read the rest of this entry »

Nachdem portaudit mal wieder ne Weile gemeckert hat, dass sudo unsicher sei habe ich heute die meisten Infrastruktur- und Projekt-Jails mit Hilfe von vorkompilierten Packages auf den aktuellen Stand gehoben.

Mit dabei waren:

• shell.uugrn.org (schon vor ein paar Tagen)
• verein.uugrn.org
• mail.uugrn.org
• satellite.uugrn.org
• privacy.uugrn.org
• ltrn.uugrn.org

Die Vorgehensweise für Jails, die überwiegend aus Packages gebaut sind ist straight-forward:
# portaudit
# portsdb -Fu
# portversion -FvL=
# portupgrade -aPP

Ich empfehle allen Jail-Inhabern diese Prozedur regelmäßig auszuführen. Wer lieber selbst kompiliert wird wissen wie das geht und es dann sicher auch selbst können.

ggf. Probleme mit Apache 2.2 und openssl

Zwischenzeitlich hatte ich ein Apache 2.2 Package gebaut, welches gegen ein älteres openssl in den Ports gelinkt ist (mod_ssl oder so). OpenSSL wurde upgedatet und hat dabei scheinbar irgendwelche internen Funktionen umbenannt, jedenfalls meckert diese spezielle Package-Version von Apache rum wegen mod_ssl. Hier hilft

# portupgrade -fPP www/apache22

… das reinstalliert den Apache 2.2 mit dem aktuellen Package, auch wenn die Versionsnummer ein Update nicht erforderlich machen würde.

Hintergrundinfo: freebsd.forum41.uugrn.org

Die Packages werden auf freebsd.forum41.uugrn.org gebaut. Dieses Jail läuft auf charm.uugrn.org und managt alle FreeBSD-Angelegenheiten, ist u.a. auch ein cvsup-Mirror, der 4x am Tag aktualisiert wird. Weiterhin läuft hier auch ein Distfile-Mirror, der basierend auf den tagesaktuellen Ports alle fehlenden Distfiles versucht zu fetchen und nicht mehr benötigte distfiles wieder verwirft. Auf diese Weise haben wir im Forum41 einen ständig aktuellen distfile-Mirror für FreeBSD (ca. 56GB), der per vom Forum41 aus per ftp, http, rsync und cifs angesprochen werden kann.

Have Fun!
Raphael

Heute waren eine handvoll Update auf shell.uugrn.org fällig, darunter u.a. mit OpenSSL, sudo und ksh93.

Das komplette Delta gibts im Wiki.

Have Fun!
Raphael

PS: auch nett: Die Updates seit 3/2009.

Heute waren diverse kleinere Updates auf shell.uugrn.org, u.a. verbunden mit dem (Security-)Update auf PHP 5.2.12, siehe auch phpinfo()

Have fun!

Raphael

Es gab in letzter Zeit gehäuft die Probleme, dass Clients auf irc.uugrn.org abgewiesen wurden:

>>> *** Connecting to port 6667 of server irc.uugrn.org
>>> *** All connections in use
>>> *** Connection closed from irc.uugrn.org: Remote end closed connection

Das Problem ließ sich nicht durch Anpassungen in der etc/ircd/ircd.conf lösen und bestand unabhängig von den dort eingestellten Werten.

Auf der Suche nach anderen Limits wurde ich fündig:

# grep -B 10 “^#define MAXCONNECTIONS” /var/tmp/usr/ports/irc/irc/work/irc2.11.2p1/support/config.h.dist

/*
* Maximum number of network connections your server will allow. This must
* not exceed OS limit of max. number of open file descriptors available upon
* ircd start.
* If you have a lot of server connections, it may be worth splitting the load
* over 2 or more servers.
* 1 server = 1 connection, 1 user = 1 connection.
* Due to various sanity checks during startup, minimum is 13.
*/
#define MAXCONNECTIONS 50

Ich habe das ircd-Package mit verschiedenen kleinen Änderungen neu gebaut und den neuen ircd gestartet.

Have fun!
Raphael

Am Freitag (2. Oktober 2009, 22 Uhr CEST) abend wurden verschiedene Security Advisories für FreeBSD veröffentlicht. Es dreht sich dabei um das Problem, dass der Kernel dazu gebracht werden kann (aufgrund von Bugs), Code an der Adresse 0 (null) auszuführen. Schafft man es nun, dort Code abzulegen und den Kernel ausführen zu lassen, kann man die volle Kontrolle über das System erlangen. 2 der 3 Security Advisories beziehen sich in diesem Kontext auf Bugs, bei dem der Kernel dazu gebracht werden kann, genau das zu tun.

Die Version 7.2-RELEASE-p4 behebt diese Probleme bzw. bietet einen Workaround an. Aus diesem Grund habe ich top.uugrn.org rebootet und damit auch alle Jails neu gestartet.

• FreeBSD-SA-09:14.devfs: Devfs / VFS NULL pointer race condition
• FreeBSD-SA-09:13.pipe: kqueue pipe race conditions
• FreeBSD-EN-09:05.null: No zero mapping feature

Ein sehr ähnliche Methode betrifft übrigens auch Linux-Kernel die älter als ein paar Wochen sind, mehr Infos unter heise.de.

Gruß
Raphael

Heute war wieder ein Update der Ports auf shell.uugrn.org fällig, wie gehabt:

portsdb -Fu
portversion -FvL=
portupgrade -arPP

Erwähnenswert ist hier das Update von PHP 5.2.10 auf 5.2.11, was einige Security Fixes und Bugfixes enthält. UUGRN e.V. bietet seinen Mitgliedern ein sehr umfangreich ausgestattetes PHP 5 zur Verfügung.

Have fun!

Raphael

Auf intern.uugrn.org habe ich soeben das installierte MySQL 5.0.83 auf 5.0.85 aktualisiert. Alle relevanten Informationen dazu befinden sich im MYSQL 5.0 Changelog:

• C.1.2. Changes in MySQL 5.0.85 (11 August 2009)
• C.1.3. Changes in MySQL 5.0.84 (07 July 2009)

Alle auf MySQL basierenden Dienste von UUGRN sollten wie gewohnt weiter funktionieren.

Have fun!
Raphael