Ich bin gestern auf was gestossen. Ich betreibe einen kleinen Server mit einer Mastodon Instanz mit nur mir als User. Der Server auf dem dies läuft ist ein Ubuntu 16.04 LTS.

Das neue Mastodon Docker Image hat einen Entrypoint der bei jedem Aufruf des Containers erstmal einen Haufen Files nach ihren Benutzerrechten abfragt und diese dann gegebenenfalls ändert. Dies hat beim letzten Update dann einfach Stunden gedauert, da bei jeder Datenbank-Migration oder Assert-Kompilierung erstmal wieder alle Files durchkämmt wurden. Ein Graus. Ein wenig in den Bugreports von Mastodon geschaut und auch was gefunden. Anscheinend liegt das an dem Storagedriver overlay2 und mit aufs sollte dies “viel schneller” gehen. Unter Ubuntu Zesty ist aufs wohl auch der Default. Nun unter 16.04 sieht man davon nichts. Dies kann man mit grep aufs /proc/filesystems überprüfen. Es gibt aber einen Weg…

1. Mit sudo apt-get install linux-image-extra-$(uname -r) linux-image-extra-virtual die passenden Pakete installieren

2. Mit sudo modprobe aufs das Kernelmodul laden

3. grep aufs /proc/filesystems sollte nun was auswerfen

4. Das File /etc/docker/daemon.conf so anpassen das auch wirklich aufs genutzt wird

    {
        "storage-driver": "aufs"
    }
   

5. Docker neu starten mit service docker restart

6. Mit docker info überprüfen ob wirklich aufs genutzt wird

7. aufs zu /etc/modules hinzufügen damit es auch nach einem Neustart funktioniert

8. Nun kann /var/lib/docker/overlay2 gelöscht werden. Alle Images müssen nun neu heruntergeladen oder gebaut werden

Neuer Wohnort und das Generve sein Netzwerk neu einzurichten. So betreibe ich einen kleinen Raspberry Pi der sich um mein VPN, DNS und DHCP kümmert. Für die beiden letzteren Dienste setze ich auf dnsmasq. Ein ziemlich kleiner und Schlanker DNS und DHCP Server. Mein Problem was das es auf meinen Ubuntu Laptops immer wieder zu komische DNS Abfrage Problemen kam. Irgendwie wollte er manchmal Domains nicht richtig auflösen. Einfach nervig. Anscheinend gibt es ein Problem zwischen dem NetworkManager unter Ubuntu und dnsmasq. Der NetworkManager setzt dnsmasq selber auf dem Client ein um den Resolver zu stellen. Da scheint in manchen Fällen auch das Problem zu liegen. Was in meinem Fall geholfen hat: den NetworkManager so zu konfigurieren das er wieder normal die /etc/resolv.conf benutzt. Dazu editieren wir /etc/NetworkManager/NetworkManager.conf und kommentieren die Zeile dns=dnsmasq aus.

Irgendwie habe ich auf 90% der Linux Systeme Probleme mit dem Splashscreen bei Booten. Manchmal taucht er einfach nicht auf und manchmal ist irgendein Foo mit der Auflösung. Eigentlich brauche ich den Splashscreen auch nicht. Also weg damit…

Unter Ubuntu geht es wie folgt. Man editiert /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT=""

Und danach updated man GRUB mit:

sudo update-grub

Zack… Fertig!

Eigentlich wollte ich ja nur mein ThinkPad upgraden. Die neue Ubuntu Version “Trusty Tahr” ist erschienen. Der Updateprozess lief soweit sauber durch und nach dem Reboot war viel weniger kaputt als sonst. Also schnell wieder ran ans coden. Mein virtualenv ging auf einmal nicht mehr. “Trusty Tahr” ist mit Python 3.4 gekommen, da schien das “Problem” zu sein. virtualenv wollte nicht mehr. Irgendeine komische Fehlermeldung. Ab Python 3 und vor allem mit 3.4 sollte man eigentlich das eigene pyvenv benutzen anstatt virtualenv. Dieses failed unter Ubuntu aber sowas von:

$ pyvenv-3.4 foo
Error: Command '['/home/mpreuss/foo/bin/python3.4', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

What the fizzle? Versucht man es mit --without-pip klappt es… aber immer extra pip per Hand installieren? Habe ich eigentlich keine Lust zu. Ich bin auch nicht alleine. Also eine Lösung musste her. Und die ist einfacher als ich dachte.

Einfach per pip install --upgrade virtualenv virtualenv upgraden. Und schon kann man mit

virtualenv -p /usr/bin/python3 foo

sich ein Python 3 Environment bauen. Ist zwar nur ein Workaround aber ich hatte eh immer virtualenv genommen.