Frischer Build nach HeartBleed, Package-Upgrade für shell.uugrn.org
April 9, 2014Im Zuge von HeartBleed musste kurzfristig alles aktualisiert werden, was auf OpenSSL 1.0.1
Have fun!
Raphael
Im Zuge von HeartBleed musste kurzfristig alles aktualisiert werden, was auf OpenSSL 1.0.1
Have fun!
Raphael
Hallo zusammen,
die letzten Wochen habe ich den neuen UUGRN Vereinsserver fertig gemacht und weitgehend in Betrieb genommen. Der neue Server löst den Anfang 2006
gekaufen Server top.uugrn.org ab, der bis heute auf einem P4 mit 2GB RAM seinen Dienst verrichtet hat.
Auf dem alten Server war vieles “gewachsen” und wurde daher reichlich unflexibel, der Server läuft bis jetzt noch unter FreeBSD 7.4 (i386).
Der neue Server (top3.uugrn.org) läuft mit dem aktuellen FreeBSD 9.1 (amd64).
Ich wollte aufgrund der großen Differenzen keine alten Jails 1:1 auf dem neuen Server hochfahren, auch wenn dies vermutlich weitgehend
geklappt hätte. Aus diesem Grund habe ich alle UUGRN-Services und (fast) alle aktiven Mitglieder-Jails auf den neuen Server neu aufgebaut!
Mitglieder, die seit sehr langer Zeit gar nichts mehr mit ihren Jails gemacht haben wurden nicht migriert, die Jails sind aber noch offline vorhanden (Backup) und können auf Wunsch neu aufgebaut werden.
Jail vermisst? Einfach melden!
Da ich einen stark automatisierten Buildprozess für Packages und Images habe und jetzt außerdem auf ZFS aufsetzen kann, kann ich mit verhältnismäßig wenig Aufwand ein komplettes neues Jail anlegen.
Die gesamte Migration bringt auch weitere Neuerungen: Alle Services, die wir über IPv4 anbieten, bieten wir prinzipiell jetzt auch unter IPv6 an. Es könnte irgendwo noch Ausnahmen geben, da wurde es schlichtweg noch nicht reinkonfiguriert.
Das bedeutet aber auch, dass Mitglieder mit Zugang auf shell.uugrn.org oder eigenen Jails nicht nur via IPv6 hinkommen, sondern auch von dort
wieder wegkommen.
Aktuell haben wir folgende Jails am laufen:
Bei der Migration der Dienste wurden manche Dinge nicht mit übernommen, beispielsweise ist der Webserver auf shell.uugrn.org ersatzlos entfallen mangels erkennbarer aktiver Nutzung. Sollte jemand einen Webserver benötigen richtige ich gerne ein eigenes Jail dafür ein.
Es existieren folgende fertige Images, aus denen sich ad-hoc neue Jails anlegen lassen:
Das ist jeweils die Basis für ein neues Jail. Ein einmal installiertes Jail kann natuerlich per Packages oder durchselbst kompilieren von Ports (make install clean) beliebig verändert oder erweitert werden.
Ich habe das Mailrouting (IMHO) vereinfacht und gewachsene Altlasten entsorgt. Da gab es teilweise arg verworrene, sich widersprechende Konfigurationen verteilt über mail/mx1, shell, verein und lists. Mailadressen wurden teilweise mit alias UND per virtusertable auf verschiedene Ziele konfiguriert etc.
Das “vereinfachte” Mailkonzept sieht so aus:
Jedes Mitglied kann im eigenen Jail eigene Domains hosten. Entsprechendes Mailrouting gibts dann gratis dazu.
UUGRN hostet seine Domains (und diverse rDNS) im Vereinsjail “uugrn.uugrn.org” als Hidden Primary. Öffentliche DNS sind ns{1,2,3}.jpru.de, weitere (inoffizielle) slaves sind u.a. auf top3.uugrn.org, welcher auch gleichzeitig der primäre recursor für alle Jails ist, d.h. Änderungen an der Zone werden auf dem Server sofort
wirksam (also-notify) und sehr zeitnah auch an die öffentlichen DNS-Server notifiziert, Vorausgesetzt man hat die serial erhöht und die zone reloaded.
Wer eine eigene Domain hat und damit ins IRC möchte, kann auf bnc.uugrn.org einen User und eine *persönliche* IPv6-Adresse mit rDNS auf einen Namen aus der eigenen Domain bekommen, also zB nickname!user_at_foo.example.com
Wer BNC will aber keine Domain hat, kann wahlweise mit nick!user_at_bnc.uugrn.org (v4+v6) oder nick!user_at_wunschname.uugrn.org (nur v6) auf einen oder mehrere IRC-Server eigener Wahl zugreifen und dazu die Vorteile eines BNC (wir bieten znc mit SSL) insgesamt nutzen.
Fragen? Anregungen?
Viele Grüße
Raphael
Heute wurde der aktuelle Stand der Ports (28. januar 2012) in Form von vorkompilierten Packages auf shell.uugrn.org ausgerollt.
Have fun!
Raphael
Es gibt wieder einen Haufen aufgefrischte Software auf shell.uugrn.org, insbesondere das Upgrade auf PHP 5.3.6 ist mit dabei.
Wer ein bestimmtes Paket oder generell eine bestimmte Funktionalität vermisst, kann das in der Wunschliste eintragen. Sicher kann nicht jeder Wunsch erfüllt werden, aber wir schauen uns alles an oder nehmen das als Anregung besser zu werden.
Have fun!
Raphael
Der Vereinsserver top.uugrn.org wurde vor einiger Zeit schon auf FreeBSD 7.3 upgedatet. Aufgrund von Bugs mit pkg_info (bei gesetztem PKG_PATH) konnten die Jails jedoch nicht nachgezogen werden. Inzwischen läuft auch shell.uugrn.org mit einem FreeBSD 7.3 Userland und hat außerdem zahlreiche neue Packages bekommen.
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 »
Das UUGRN Package-Build-Jail erzeugt regelmäßig neue Packages aus den aktuellen FreeBSD Ports. Derzeit läuft der Großteil der UUGRN-Infrastruktur noch auf FreeBSD 7.2, entsprechend werden für dieses RELEASE auch die Packages gebaut. Wie das genau funktioniert habe ich im Juli 2009 im Artikel Pflege und Aufzucht von FreeBSD Ports und Packages beschrieben.
Bis Ende 2009 lief dieses Jail auf meinem PC @home, der dank moderner QuadCore CPU genug Power hat, um Packages in angenehmer Zeit zu bauen. Da ich @home inzwischen aber auf FreeBSD 8.0 upgegraded habe, habe ich das UUGRN-Buildjail nun unter dem Namen freebsd.forum41.uugrn.org auf charm.uugrn.org laufen, der mit 4GB RAM und 2x 2.8GHz XEON CPU ebenfalls ausreichend dimensioniert ist.
Charm dient derzeit außerdem als Backup für top.uugrn.org und als IPv6-Gateway im Forum41 (kann auch IPv4 mit NAT). Etwas tricky ist das Setup für Jails, denn die laufen nur auf einer RFC 1918-IP-Adresse (z.B. freebsd.forum41.uugrn.org has address 192.168.0.20) müssen aber via externem Interface auf das Internet zugreifen können.
Hierfür benötigen wir den natd, der im Userland IP-Pakete umschreibt und in den IP-Stack zurückschiebt. Damit der natd die IP-Pakete überhaupt zu sehen bekommt, muss folgende IPFW-Regel weit oben stehen:
add divert natd ip4 from any to any via em0
In der /etc/rc.conf benötigen wir dann noch:
natd_enable="YES"
natd_interface="em0"
… wobei “em0” das externe Interface ist, die Jails sind an das Interface em1 gebunden und sind somit im LAN verfügbar.
Wichtiges Detail: wenn man via SSH am NAT-Setup rumspielt (die ipfw-Regel), sollte man tunlichst dafür sorgen, dass der natd schon läuft sonst werden alle IP-Pakete ins Nirvana geroutet.
Sobald das Jail “in-sync” ist wird es den nächsten Packagebuild geben.
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.
Ein sehr ähnliche Methode betrifft übrigens auch Linux-Kernel die älter als ein paar Wochen sind, mehr Infos unter heise.de.
Gruß
Raphael
… ich musste mich leider auch darauf hinweisen lassen, dass ich wenigstens hin und wieder mal /usr/ports/UPDATING lese:
20090802: AFFECTS: users of devel/libtool15 and devel/libltdl15 AUTHOR: mezz@FreeBSD.org The devel/libtool15 and devel/libltdl15 ports have been moved to libtool22 and libltdl22, respectively, then updated to 2.2.6a. You will need to run portmaster or portupgrade to properly perform the upgrade: Portmaster: ----------- portmaster -o devel/libtool22 devel/libtool15 portmaster -o devel/libltdl22 devel/libltdl15 Portupgrade: ------------ portupgrade -o devel/libtool22 libtool-1.5\* portupgrade -o devel/libltdl22 libltdl-1.5\* After that, you will need to rebuild all ports that depend on libltdl. Since all dependent ports' PORTREVISIONs have been bumped, you can run portupgrade or portmaster with '-a' to complete the upgrade.
Nachdem ich in meinem Buildjail viel Spaß hatte wegen scheinbar defekten Ports (multimedia/gstreamer etc) habe ich diesen Rat befolgt. Leider konnte ich nicht mehr von “Since all dependent ports’ PORTREVISIONs have been bumped, you can run portupgrade or portmaster with ‘-a’ to complete the upgrade.” profitieren, denn ich hatte einen Teil scheinbar schon “irgendwie” anderweitig upgedatet.
Also war heute ein
# BATCH=yes portupgrade -afp
im Buildjail fällig. Das hat zum Glück nur ein paar Stunden gedauert und ist bis auf einen winzigen Fehler mit www/elinks durchgelaufen.
Das (jetzt wieder hoffentlich saubere und konsistente) /usr/ports aus dem Buildjail werde ich gleich hochladen, damit können dann alle Jails upgedatet werden, im Zweifel einfach mit
# portupgrade -afPP
ungetestet, auf eigene Gefahr!.
Have Fun!
Raphael Becker
Auf Wunsch des Admins habe ich das NoName Jail abgebaut, das Jail wurde nicht mehr benötigt und wäre sonst verwaist.
Raphael