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.

Status einer SSH-Session an sudo weitergeben

Wenn man sich per SSH auf einen Rechner connected und anschließend mit “sudo“ root-Rechte erlangt, kann man in dieser Session nicht feststellen, ob man per SSH verbunden ist, oder nicht. Ich brauchte dies z.B., um meinen Shell-Prompt in diesem Fall anders anzuzeigen.

Es ist aber sehr einfach, hier Abhilfe zu schaffen. Wir müssen sudo nur sagen, dass es die Variablen betreffend SSH im Environment halten soll.

Hierfür müssen wir nur folgende Zeile in die sudo-Config (/usr/local/etc/sudoers oder /etc/sudoers) eintragen:

Defaults env_keep += "SSH_TTY SSH_CONNECTION SSH_CLIENT"

Von nun an sind die drei Variablen auch in sudo-Sessions verfügbar.

Omnifocus, Todoist, Remember the Milk – Die Qual der Wahl der richtigen Todoliste

Todoist auf dem iPad mini
Andreas Lorenz beschreibt in seinem Beitrag „How to get the best out of Omnifocus ‚Äď for PC Users“ wie er als iOS-User, der dienstlich einen PC benutzt das Beste aus Omnifocus heraus holt und es auch ganz ohne eine fehlende Webapp oder einen Mac-Client nutzt.

Ich bin auch bis heute noch stark begeistert von Omnifocus. Mitte letzten Jahres habe ich nach 8 Jahren als pro-Member Remember the Milk den Rücken gekehrt und bin zu Omnifocus gewechselt. Beim Setup meines Systems habe ich mich ganz stark von Sven Fechner und seinen sehr ausführlichen Artikeln zu Omnifocus inspirieren lassen. Ich konnte mich jedoch mit der iOS-only-Lösung auf Arbeit nie so richtig anfreunden, auch wenn Die Apps für Mac, iOS und Apple Watch am schönsten und durchdachtetsten sind. Nur E-Mails weiterleiten oder Siri um Tasks anzulegen hat mich zu sehr eingeschränkt und ich hatte zu oft das Gefühl, nicht alles im Griff zu haben.

Nach drei Monaten Omnifocus bin ich dann zu Todoist gewechselt und hier bisher am glücklichsten, auch wenn mir hier ein paar Dinge fehlen und wieder andere etwas umständlich sind. Im Design der Apps, sowohl auf iOS, als auch im Web haben alle Elemente ziemlich viel Whitespace. Ich würde mir wünschen, mehr Content sehen zu können und alles etwas kompakter zu haben. Auch das Templating-System ist etwas umständlich und arbeitet mit wenig intuitiven CSV-Files. Die App für die Apple Watch hat leider (noch) keine Compliation und ist manchmal etwas lahm. Außerdem wäre es schön, Start-Dates für Tasks vergeben zu können.

Mit der Veröffentlichung der neuen Remember the Milk-App ging dann jetzt auch die neue Webapp online, die ich im letzten Jahr in der closed Beta intensiv im Einsatz hatte. Auch hier fehlen mir aber noch ein paar Dinge, die mich wieder zu einem Wechsel bewegen könnten. Eine App für die Apple Watch fehlt bisher und eine Möglichkeit verschachtelte Projekte anzulegen fehlt mir auch. Das Handling von Subtasks ist etwas hakelig, das macht Todoist besser. Dafür bietet RTM eine extrem mächtige Query Language um Filter zu erstellen und die Möglichkeit, auch ganze Tasklisten per E-Mail zu importieren.

Ich werde jetzt erst ein mal bei Todoist bleiben und die anderen Entwicklungen beobachten. Ein trusted System, dem man nicht traut, weil man das Gefühl hat, es nicht so nutzen zu können, wie man möchte, oder Angst hat, es nicht komplett zu durchschauen, macht eben einfach keinen Sinn.

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