FreeBSD-Server inkl. Jails auf neue Version upgraden

Ich bin gerade dabei, einen FreeBSD-Server, der als Host für diverse ezjail-Jails dient, auf eine neue FreeBSD-Version upzugraden. Als Referenz für mich dokumentiere ich das ganze hier einfach mal.

Das System läuft aktuell auf 10.1 und wird auf 10.3 gehoben. Bei späteren Upgrades müssen die Versionsnummern entsprechend angepasst werden.

Als erstes bringen wir das aktuell installierte System auf den letzten Stand und aktualisieren die Ports.

freebsd-update fetch
freebsd-update install
portsnap fetch update

Im nächsten Schritt laden wir die neuen Systemfiles herunter, installieren den neuen Kernel und rebooten das System.

freebsd-update upgrade -r 10.3-RELEASE
freebsd-update install
shutdown -r now

Nach dem Reboot installieren wir die restlichen Systemfiles und rekompilieren alle installierten Ports. Anschließend starten wir den Server noch mal neu. Die Option -m DISABLE_VULNERABILITIES=yes setze ich, damit ich nicht mitten im Upgrade aufhören muss, falls bei einem Port Sicherheitslücken bekannt sind. Temporär damit hinter der Firewall zu leben erscheint mir sinnvoller, als ein gebrickter Server. ūüėČ

freebsd-update install
portmaster -af -m DISABLE_VULNERABILITIES=yes
shutdown -r now

Nach dem Reboot ist der Server an sich auf 10.3. Nun müssen noch die ezjail-Jails upgegradet werden.

Hierfür laden und installieren wir zunächst die aktualisierten Files für die Basejail und starten anschließend ezjail neu.

ezjail-admin install -r 10.3-RELEASE
env UNAME_r=10.3-RELEASE ezjail-admin update -s 10.1-RELEASE -U
ezjail-admin update -P
service ezjail-admin restart

Jetzt müssen wir nur noch in jeder einzelnen Jail die Ports rekompilieren und einmal neustarten.

portmaster -af -m DISABLE_VULNERABILITIES=yes
service -R

Das war’s. Wenn keine Probleme auftreten und kann man damit in ner Stunde durch sein. Wenn mehrere Jails betrieben werden und viele Ports gebaut werden müssen, dauert es entsprechend länger.

Mehrere SSH-Connections zum selben Host beschleunigen

Manchmal kommt es vor, dass man mehrere SSH-Connections zum selben Host aufbauen muss, um z.B. gleichzeit etwas auszuführen und parallel dazu, die Logfiles zu sehen.

Bei jedem Verbindungsaufbau muss die Verbindung inkl. dem ganzen Overhead neu aufgebaut werden, was Zeit kostet und u.U. dazu führt, dass man Passwörter usw. erneut eingeben muss.

SSH bietet die Möglichkeit, in solchen Fällen die bestehende Verbindung einfach erneut zu benutzen.

Füge folgendes in die .ssh/config ein:

Host *
ControlMaster auto
ControlPath ~/.ssh/control-%h-%p-%r
ControlPersist 600

Host * sorgt dafür, dass die folgenden Bedingungen auf alle Verbindungen angewandt werden. Wenn Du statt dem * einen Hostnamen (z.B. github.com) angibst, beziehen sich die Settings nur auf die Verbindungen zu eben jenem.

ControlMaster auto sorgt dafür, dass bestehende Connections automatisch verwendet werden.

ControlPath ~/.ssh/control-%h-%p-%r legt für jede Verbindung einen Control-Socket unter ~/.ssh an. Diesen Pfad kannst Du frei wählen. Er muss jedoch bereits existieren.

ControlPersist 600 hält die Verbindung für 10 Minuten offen, nachdem die erste Verbindung (der Master) geschlossen wurde. Ohne diese Option werden alle Connections gekappt, sobald der Master geschlossen wird.

In der Manpage zu ssh_config gibt es noch viele weitere Optionen und Konfigurationsbeispiele.

Hostnames und Usernames die man reservieren sollte

Wenn man im Internet Dienste anbietet, die es Menschen ermöglichen, sich selbst zu registrieren, macht es Sinn, von vorneherein einige Namen selbst zu reservieren oder die Reservierung dieser zu blocken.

Bei einigen gibt es Vorschriften, bei anderen Ratschläge aus RFCs und wieder andere sind aus anderen Gründen einfach sinnvoll. Insbesondere, wenn der Username am Ende zu einer automatisch generierten Subdomain oder E-Mail-Adresse führt, kann es hier ganz schnell zu ungewünschten Effekten kommen, die es gilt, zu vermeiden.

Geoffrey Thomas hat in seinem Blogbeitrag mal eine Liste solcher Namen erstellt und will diese weiterpflegen. Er erklärt auch, warum welche Einträge darin aufgenommen wurden.

Aktuell empfiehlt er folgende Namen zu blocken:

abuse
admin
administrator
autoconfig
broadcasthost
ftp
hostmaster
imap
info
is
isatap
it
localdomain
localhost
mail
mailer-daemon
marketing
mis
news
nobody
noc
noreply
no-reply
pop
pop3
postmaster
root
sales
security
smtp
ssladmin
ssladministrator
sslwebmaster
support
sysadmin
usenet
uucp
webmaster
wpad
www

System-Monitoring mit Glances

Glances ist ein ziemlich schickes System-Monitoring-Tool für die Shell.

Es ist in Python geschrieben, für alle gängigen Betriebssysteme verfügbar und so eine Art (h)top auf Steroiden.

Es zeigt u.A. CPU- und Speicher-Auslastung, Load, Prozesse, Auslastung der Netzwerk-Interfaces, Disk I/O, Temperaturen und die Filesystembelegung an. So hat man alles auf einen Blick, was man sich sonst mit vielen verschiedenen Tools zusammen basteln müsste.

Es bietet eine API und kann die Daten z.B. an einen StatsD weitergeben oder per Web-Interface zugänglich machen. Den Source Code, Instruktionen zum Schreiben von Plugins, sowie Installationsanleitungen gibt’s auf GitHub.

screenshot-glances

Ich habe Glances jetzt seit ein paar Tagen auf allen Servern und dem MacBook im Einsatz und mag es.

Selbstbau-NAS mit FreeBSD

Wie in Ausgabe 2 von skrupuloes zu hören war, hatte ich Probleme mit dem Speicherplatz auf meinem NAS. Die Synology Diskstation 211J hat nur Platz für zwei Platten, die ich aus Redundanzgründen gespiegelt habe. Ich hatte also effektiv 2 TB Platz. Da die Diskstation auch meine Boxee-Box, Raspberry Pi mit XBMC und diverse iDevices mit Mediendateien versorgt hat, war der Platz relativ schnell voll, wenn man die Time Machine-Backups für zwei MacBooks dazu rechnet. Es musste also etwas neues her.

Die fertigen Lösungen, die es auf dem Markt gibt waren mir alle zu unflexibel und mit Platz für mind. vier Festplatten auch relativ schnell relativ teuer. Ich entschied mich also, etwas selbst zu bauen.

Nach ein wenig Recherche entschied ich mich für folgende Komponenten:

  • Mainboard: ASUS C60M1-I
  • Gehäuse: Fractal Design Array R2
  • RAM: Corsair XMS3 PC-133 8GB (CL9)
  • Festplatten: Western Digital WD20EZRX Green 2TB
  • 320 GB Hitachi 2,5″ HDD aus MacBook Pro

Das Mainboard ist passivgekühlt, kommt mit einem AMD Fusion Dualcore mit 1GHz, Gigabit-LAN und 6 SATA-Ports. Dazu habe ich 8 GB RAM verbaut (man weiß ja nie‚Ķ). Gespeichert wird auf vier 2 TB-Platten und einer 320 GB-Platte, die ich noch aus meinem MacBook rumliegen hatte. Das Gehäuse ist extra für den Einsatz als NAS entwickelt worden. Es kommt komplett mit einem großen Gehäuse-Lüfter, 300 W-Netzteil und bietet sowohl einen herausnehmbaren Festplattenkäfig für bis zu sechs Platten und die Möglichkeit, zusätzlich eine 2,5″-Platte zu verbauen.

Da ich aus Gründen der Datensicherheit gerne ZFS nutzen wollte, bin ich nun gezwungen, nicht mehr Linux zu benutzen. Da mir fertige NAS-Distributionen zu unflexibel sind, entschied ich mich, mal etwas neues zu wagen und jetzt läuft hier ein schickes FreeBSD.

Als Linux-Umsteiger war FreeBSD kurzzeitig ungewohnt, aber mittlerweile bin ich recht gut drin und lerne die diversen Vorzüge bezüglich Software-Verwaltung mit Ports, Konfigurationsdatein etc. zu schätzen.

Die vier großen Platten laufen als RAIDZ1 (vergleichbar mit RAID5) und bieten mir somit knapp 6 TB Speicherplatz und eine mögliche Wiederherstellung, falls eine Platte ausfällt. Wenn der Speicherplatz knapp wird, kann ich noch zwei weitere Platten verbauen und das RAID einfach erweitern.¬†Die 2,5″-Platte nutze ich als Systemplatte und habe hierauf das BSD installiert.

Alles in allem habe ich jetzt für vergleichsweise wenig Geld ein kleines, Leistungsstarkes, stromsparendes und flexibel einsetzbares System, das auch noch Spaß beim Herumexperimentieren mit einem echten UNIX gibt ūüėČ