# docker stop $(docker ps -a -q)
# for image in $(docker images --format "{{.Repository}}:{{.Tag}}" | grep -v '');
      do docker pull $image;
  done;
# docker start nextcloud-aio-apache nextcloud-aio-nextcloud nextcloud-aio-redis
  nextcloud-aio-database ...

Leider kenne ich mich mit Docker nicht gut genug aus, um in angemessener Zeit selber eine Lösung zu finden und das manuelle Update hat ja geklappt. Nun habe ich endlich die Ursache für das Problem und damit auch die Lösung: Meine Docker-Installation war zu alt. Der Server war noch mit Debian 12 (aka „Bookworm“) unterwegs, das nur Docker 20.10 anbietet. Nach dem Update auf das aktuelle Debian 13 (aka „Trixie“) damit Docker 26.1 startete beim Reboot direkt automatisch der Mastercontainer.

In diesem Beitrag geht es um die Benutzung von Git unter Windows. Git ist ein Programm zur Versionsverwaltung. Wenn man ein Projekt hat, das aus mehreren Dateien besteht, kann man einen Projektstatus jederzeit sichern und bei Bedarf mit anderen teilen. Auch ist es möglich, Änderungen zwischen Versionen anzuzeigen oder auch rückgängig zu machen: Man hat sozusagen ein Backup der alten Versionen und kann jederzeit mit ihnen Vergleichen. Wenn mehrere Beteiligte gleichzeitig auf ihren Rechnern an einer Datei arbeiten, hilft Git auch, die verschiedenen Änderungen zusammen zu führen.

In diesem Tutorial wird davon ausgegangen, dass der Benutzer auf ein existierendes Projekt („Repository“) zugreifen will, das auf einem Git-Server gehostet wird. Gratis Hosting für Git-Projekte bieten unter anderem BitBucket oder GitHub. Da ich den Text für Gelegenheitsznutzer und Windows verfasse, benutze ich nach Möglichkeit nur die grafische Oberfläche. (Wenn man bestimmte Aufgaben oft zu erledigen hat, halte ich Kommandozeilenwerkzeuge eigentlich für benutzerfreundlicher als grafische Oberflächen. Grafische Oberflächen sind bei selterner Benutzung aber eine prima Gedankenstütze.)

Da Git meist nicht vorinstlliert ist, muss man es vor benutzung installieren. Windows-Nutzern sei hierfür das offizielle Git-für-Windows-Setup empfohlen. Die Voreinstellungen des Setup-Proramms sind gut gewählt, weiche nur davon ab, wenn du weißt, was du tust. (Wenn du dieses Tutorial brauchst, ist das wahrscheinlich nicht der Fall.)

Nach der Installation könnteGit direkt verwendet werden. Zuerst gehen wir jetzt aber einmalig in die Kommandozeile. Uploads werden von Git mit einem Namen und eine E-Mail-Adresse markiert, um die Herkunft der Änderungen zu zeigen. Die folgenden beiden Befehle (mit passender E-Mail-Adresse und Benutzernamen) in die Kommandozeile („Eingabeaufforderung“) einfügen und fertig.

git config –global user.email user@server.invalid

git config –global user.name „Vorname Nachname“

(An dieser Stelle ging es über die Kommandozeile dann doch schneller. Das Argument Gedankenstütze zählt bei einmaliger Benutzung ja nicht.) Im Startmenü (oder auf dem Startbildschirm) sollte „Git GUI“ auftauchen. Frisch gestartet sieht sie unbenutzt noch so aus:

Wenn später eigene Änderungen hochgeladen werden sollen, muss der eigene SSH-Key beim Git-Server hochgeladen werden. Bei GitHub findet man eine Eingabemaske unter https://github.com/settings/keys. Den eigenen Key findet man unter „Show SSH Key“ im Menü „Help“ der Git GUI. (Wer vorher noch kein SSH genutzt hat, muss per „Generate Key“ einen erstellen.) Angezeigt wird der persönliche, öffentliche Schlüssel für den aktuell genutzen Computer. Er ist nicht geheim sondern dient dem Identitätsbeweis. Daher könnt ihr meinen auch gern sehen:

Jetzt wird es ernst: Über „Clone Existing Repository“ (in der Hauptansicht der Git GUI) kann ein bestehendes Projekt auf den eigenen Computer kopiert werden. Wenn man einen SSH-Key hinterlegt hat, empfiehlt es sich, hier auch eine SSH-Adresse anzugeben. (Das ist im nächsten Screenshot der Fall.) Um nur immer einen aktuellen Stand zu laden ohne eigene Änderungen zu teilen, kann man stattdessen einen HTTP-Link nehmen. Achtung: Das Zielverzeichnis darf noch nicht existieren. (Am bequemsten ist es vermutlich, wenn man sich per „Browse“-Funktion zum richtien Ort manöviert und dann den Namen des Zielverzeichnisses eintippt.)

SSH-Fingerabdruck dürfte beim ersten Mal unbekannt sein. Gewissenhafte Nutzer überprüfen ihn (GitHub SSH Keys). Akzeptiert wird der Key durch Eintippen von „yes“ in das Textfeld.

Nach dem Clone öffnet sich das Projekt-Fenster der Git GUI. Außerdem befinden sich die Dateien des Projekts auf der Festplatte. Dort kann man mit ihnen arbeiten und sie Verändern. Git wird jetzt erst einmal nicht mehr gebraucht. Man arbeitet einfach mit den lokalen Dateien, bearbeitet sie zum Beispiel mit einem Texteditor. Nur das verzeichnis „.git“ (normalerweise versteckt) sollte man tunlichst nicht anfassen: Hierin legt Git seine Statusinforationen ab.

Irgendwann ist das Tagwerk getan – oder man will einfach einen aktuellen Stand sichern oder teilen. Wenn das der Fall ist, kann man das über die Git GUI tun. Die Hauptansicht sollte jetzt eine Übersicht an zuletzt geöffneten Projekten abieten:

Per Klick auf eines der zuletzt geöffneten Projekte („Repositories“) gelangt man leicht wieder in die Projektansicht. Diese listet nun die gemachten Änderungen auf.

Man kann sie nun begutachten und als Projektstand speichern. Hierzu klickt man auf Dateien mit „Unstaged Changes“, sie tauchen daraufhin bei den „Staged Changes“ auf. Um die Übersicht zu behalten, sollte man jetzt noch kurz die Änderungen in der „Commit Message“ zusammenfassen. Aschließend wird der Stand per Klick auf auf den „Commit“-Button (unten neben der gerade geschriebenen Zusammenfassung) gespeichert. Man kann nun jederzeit wieder auf diesen Stand zurückkehren. Wer den Weg über SSH gegangen ist, kann seine Änderungen per Klick auf „Push“ auch auf den Server hochladen.

Wenn auf dem Server Änderungen von anderen Benutzern vorhanden sind, wird das „Push“ nicht gelingen: Die fremden Änderungen müssen zunächst abgeholt und mit den eigenen zusammengeführt werden. Wie das geht, erkläre ich jetzt aber nicht mehr.

Besonders genervt hat mich bei der Webseite SSL. Eine hauptsächlich verschlüsselte Seite mit unverschlüsselten Bildern fühlt sich laut Firefox-Icon unsicherer an als eine komplett unverschlüsselte Seite. Das ist natürlich sehr unästhetisch und da ich absolute Links zu Bildern gesetzt hatte, war die Behebung manuell zu erledigen.

Bei der Umfrage (der Teil mit sed) hat mich vor allem “Mount&Blade: Warband” genervt. Ich musste das “&” in der Variablen escapen, die ich vorher per regexp aus der Tabelle geholt habe. Die Lösung:

while read p; do
replaceme=$(echo "${p#*'    '}" | sed 's/&/\\&/')
replaceby=$(echo "${p%'    '*}" | sed 's/&/\\&/')
sed -i "s#$replaceme#$replaceby#gI" $datenfileout
done < $duplikatsliste

Wenn das jetzt durchläuft, bin ich zumindest ein gutes Stück weiter.

Für alltäglichen Mailverkehr interessant sind vor allem die beiden Keys, von denen ich jeweils einen für eine Mailadresse verwende:
Patrik Schönfeldt (mail@patrikschoenfeldt.de)
Fingerprint=89C4 340D 292A 5215 8389 BAAB 2DAC 3458 9558 2294

Patrik Schönfeldt (patrik.schoenfeldt@vdvc.de)
Fingerprint=DF1E 85A4 1E4B B9E0 3731 F47E E910 9892 D1E9 B3AD

Nur für Signaturen anderer Keys gibt es folgenden Key:
Patrik Schönfeldt
Fingerprint=922A E025 4C43 63F8 3D00 A306 8946 BCDE EADF 86F0
Dieser ist an einem sicheren Ort gespeichert und bestätigt z.B. die Echtheit der Primärkeys. Die Gültigkeit ist 2015/2016. Wer einen Schlüssel von mir signieren möchte: Dieser ist der beste für diesen Zweck.

Mein alter Key (damals einer für alles) wurde durch die bisher genannten abgelöst.
Patrik Schönfeldt (Key for 2011 to 2015, patrik.schoenfeldt@gmx.net)
Fingerprint=393B DD4B FA25 5092 68BC 9081 AD1B D149 64F8 EC43
Er wird dieses Jahr auslaufen, und hat noch Mailadressen angegeben, die ich eigentlich gar nicht mehr benutze. Da er aber häufiger signiert wurde als die anderen Keys, werde ich ihn nicht widerrufen, damit er mittelbar das Vertrauen in die neueren Schlüssel bestätigt.

Es gibt noch andere Schlüssel, aber dazu habe ich keine privaten Schlüssel mehr. Widerrufen ist ist also nicht mehr drin.

Seit Ende November ist Steam für Linux erhältlich, sogar mit Counter-Strike: Source (seit vorgestern). Doch offiziell unterstützt wird leider nur Ubuntu in der Version 12.04. Für die meisten Linuxnutzer ist das kein Problem, weil es meistens trotzdem läuft. Mit Debian ist das leider nicht der Fall. Ein bekanntes Workaround ist das Setzen von Umgebungsvariablen, was aber leider den Paketmanager umgeht. Eine in meinen Augen elegantere Möglichkeit ist die Benutzung von chroot.

Die Installation der Chroot-Umgebung mit Ubuntu ist denkbar einfach. (Zu den angegebenen Befehlen: #: als Root ausführen, $: als User ausführen; in eckigen Klammern meint in der Chroot-Umgebung.) Es empfiehlt sich, direkt nach der Installation die Repositories zu bearbeiten und dem Nutzer (in meinem Fall patrik) die Nutzung des chroots zu erlauben:

#: debootstrap --arch i386 precise /srv/chroot/ubuntu/ http://archive.ubuntu.com/ubuntu
#: echo -e "deb http://archive.ubuntu.com/ubuntu precise main\n
deb http://archive.ubuntu.com/ubuntu precise-updates main\n
deb http://archive.ubuntu.com/ubuntu precise-security main\n"
> /srv/chroot/ubuntu/etc/apt/sources.list
#: echo -e "[Ubuntu 12.04]\n
description=Ubuntu Precise\n
directory=/srv/chroot/ubuntu\n
aliases=precise,default\n
users=patrik\n"
>> /etc/schroot/schroot.conf


Zur Vorbereitung der neuen Umgebung sollte man zudem die Benutzereinstellungen in die neue Umgebung einfügen. Ich habe das teilweise per mounts gemacht, teilweise einfach kopiert:

#: echo -e "# Ubuntu chroot\n
/home /srv/chroot/ubuntu/home none bind 0 0\n
/tmp /srv/chroot/ubuntu/tmp none bind 0 0\n
/dev /srv/chroot/ubuntu/dev none bind 0 0\n
/proc /srv/chroot/ubuntu/proc proc defaults 0 0\n
/run/shm /srv/chroot/ubuntu/run/shm none bind 0 0\n"
>> /etc/fstab
#: cp /etc/group /srv/chroot/ubuntu/etc/group
#: cp /etc/passwd /srv/chroot/ubuntu/etc/passwd
#: cp /etc/shadow /srv/chroot/ubuntu/etc/shadow
#: cp /etc/hosts /srv/chroot/ubuntu/etc/hosts
#: mount -a


Um in der Chroot-Umgebung auch auf den XServer zugreifen zu können, kann man (als Nutzer!) xhost erlauben, alle lokal laufenden Prozesse anzuzeigen:
xhost + local:

Damit läuft das Chroot-System auch schon. (Ja, ich hätte auch einfach ein Script bauen können, dann hätte niemand Befehle abtippen oder kopieren und einfügen müssen. Aber man soll ja auch was lernen.) Allerdings hatte zumindest ich Probleme mit der (nicht installierten) Lokalisierung. Also geht es erst einmal ab in die neue Umgebung:

#: dchroot -d

Dort angekommen, habe ich zuerst die Locale auf C gesetzt, um dann ohne Fehlermeldung in der Chroot die Locales installieren zu können. Direkt darauf folgen xterm (das installiert schon mal automatisch Xserver, etc mit) und wget. Beides ist nützlich für die spätere Installation von Steam. Außerdem installiere ich jockey-common und python-apt, weil Steam sonst später sudo startet, was ich nicht benutze(n möchte).

[#:] export LANG=C.UTF-8
[#:] export LANGUAGE=C
[#:] apt-get update
[#:] apt-get upgrade
[#:] apt-get install language-pack-de
[#:] export LANG=de_DE.UTF-8
[#:] export LANGUAGE=de_DE
[#:] apt-get install xterm wget
[#:] apt-get install jockey-common python-apt


Jetzt kann Steam auch schon installiert werden. Direkt danach werden die Abhängigkeiten nachinstalliert.

[#:] wget http://media.steampowered.com/client/installer/steam.deb
[#:] dpkg -i steam.deb
[#:] apt-get -f install


Damit ist Steam installiert. Um es nutzen zu können, muss die Chroot-Umgebung aber noch wissen, wo der Xserver zu finden ist. Um sicher zu gehen, dass es klappt, habe ich vor dem Start von Steam noch eben die DISPLAY-Variable gesetzt.

$: dchroot -d
[$:] export DISPLAY=:0
[$:] steam


Gratulation! Jetzt sollte Steam in der Chroot-Umgebung laufen. Allerdings ist das noch alles andere als komfortabel. Um nicht jedes Mal ins Terminal gehen zu müssen, legen wir ein kleines Skript an. Es liegt /usr/local/bin/do_dchroot und hat folgenden Inhalt:

#! /bin/bash
/usr/bin/dchroot -d "`echo $0 | sed 's|^.*/||'` $*


Dieses Skript ruft automatisch Befehle in der Chroot-Umgebung auf, die den Namen des Skripts haben. Ein direktes Aufrufen würde also „do_dchroot“ innerhalb der Chroot-Umgenung aufrufen. Das ist natürlich nicht nützlich, aber mit einem kleinen Kniff wird es sehr praktisch:

#: ln -s /usr/local/bin/do_dchroot /usr/local/bin/steam

Man kann Symlinks mit beliebigen Namen auf das Skript^[1] verweisen lassen, die dann automatisch den Namen des Links im Chroot ausführen.

Wenn ich nichts vergessen haben sollte, müsste Steam jetzt genau so laufen, als wäre es normal unter Ubuntu installiert.

Update 11. Februar 2013: Einige Flüchtigkeitsfehler behoben.

1. ^[1]Gefunden habe ich diese Idee bei Ubuntuforums↩

Das User-Interface von Windows 8 ist definitiv nicht für die Bedienung mit Maus und Tastatur ausgelegt. Ich habe schon vieles benutzt oder ausprobiert, Windows seit Version 3.0, Gnome, KDE, Enlightenment, XFCE und diverse andere Oberflächen für Linux. Windows 8 ist das erste System, bei dem ich ohne Erklärung nicht einmal ein Fenster schließen konnte. Warum Microsoft den Nutzern so etwas antut? Vermutlich, weil sie es können – die Marktmacht ist groß genug. Fakt ist, dass die meisten die neue Version wohl als Überraschung auf einem neuen Computer entdecken werden.

Doch einen Firma, so groß sie auch sein mag, wird nicht zum Spaß ihre Kunden verärgern. Meine Erklärung: Microsoft hat erkannt, dass viele Menschen keinen PC brauchen und eigentlich auch gar keinen wollen. Sie haben ihren Computer, um E-Mails abzurufen und im Internet zu Surfen. Als sie ihn (oder den Vorgänger) gekauft haben, brauchte man dazu noch einen Computer. Man hat ihnen beigebracht: Um online zu sein, benötigt man einen Computer und ein Modem. Das Modem in seiner ursprünglichen Form ist inzwischen weggefallen, dass es keinen ausgewachsenen PC mehr braucht, haben viele aber noch nicht realisiert. Und selbst wenn das falsch sein sollte: Der mobile Markt wird an Bedeutung gewinnen. Und dieser läuft bisher faktisch ohne Microsoft ab.

Wenn es dann aber so weit ist, dass Tabletts zum Standardequipment gehören, will man in Redmond sagen können: Wir haben hier etwas, das funktioniert genau so, wie ihr es vom Desktop kennt. Hätte Microsoft für Tabletts und Desktops zwei verschiedene (jeweils besser geeignete) Oberflächen designt, würden sich die Käufer frei zwischen Apple, Android und Microsoft entscheiden. An eine neue Umgebung müssen sich ohnehin gewöhnen. Der Mensch ist ein Gewohnheitstier und auf dem PC kann Microsoft dem Nutzer einfacher vorgeben, das eigene Tablett-System zu erlernen.

Der Plan kann aber auch nach hinten los gehen: Wenn die Nutzer schon beim ersten Anblick von Windows 8 merken, dass sie sich eh umgewöhnen müssen – und so den Absprung von Windows wagen.

Auf diese Weise untergräbt die Branche, die so sehr um die Akzeptanz „ihres“ Mediums als Kulturgut kämpft, eben diesen Anspruch, den sie selber stellt. Kultur lehrt sehr viel über die Gesellschaft, was sie denkt, fühlt und fürchtet. Nicht nur dort, wo vermutlich jeder es erwartet, sondern auch in Horrorfilmen und Ego-Shootern. Gozilla zum Beispiel ist Symbol für die zerstörerische Gewalt nuklearer Waffen, unter deren Eindruck sich Japan in den 1950er Jahren befand, King Kong greift die Sklaverei in Amerika als Thema auf und SiFi-Shootern thematisieren typischerweise die Ambivalenz von Nutzen und Gefahr neuer Technologie. Kultur ist Teil des gesellschaftlichen Gedächtnisses, kein Wegwerfprodukt. Daher wird sie in Museen, Archiven und Bibliotheken für die Nachwelt bewahrt. Sie bildet ab, was die Gesellschaft bewegt, und behandelt ihre Ängste.

Es gibt viele Liebhaber, die klassische Konsolen sammeln, reparieren und in Stand halten. Und wer hat nicht noch seine ersten Spiele zuhause auf dem Regal stehen? All das wird nicht mehr funktionieren, wenn zum Spielen irgendwo auf der Welt ein Server laufen müsste, dessen Betrieb sich für den Anbieter nicht mehr lohnt. Nicht mehr lohnt für den „Rechteinhaber“ könnte man sagen – und dabei genau der Wahrheit ins Auge blicken, die man nicht verstehen will: Die Rechte liegen bei jemand anderem, nicht bei mir, dem zahlenden Kunden. Und auch wenn laut EU-Generalanwalt selbst der Handel mit gebrauchten Lizenzen legal ist, so unterbindet das sogenannte Digital Rights Management jedwedes Recht auf technischer Ebene. DRM könnte in diesem Sinne besser übersetzt werden mit Decay of Rightfully used Media. Die Kulturschaffenden selbst haben ihren Werken ein Verfallsdatum aufgeprägt.

Die Einrichtung ist eigentlich nicht weiter schwer. Man benötigt nur ein passendes Mainboard mit IOMMU-Unterstützung, zwei Grafikkarten (eine für jedes Betriebssystem) und eine Linux-Distribution, die mindestens Kernel 3.2 mit bringt. (Es geht natürlich auch mit anderen Distributionen, aber dann muss man selber Kernel backen.) Die Schritte^[2] sind recht schnell durchgeführt:

1. Xen über Paketmanager installieren
2. Computer neu starten – mit Xen.
3. Wenn das läuft, kann man in der „/etc/default/grub“, den Default auf Grub ändern und die „grub.cfg“ neu konfigurieren lassen.
4. Der einfachste Möglichkeit, die Grafikhardware an eine VM abzugeben, ist via Kernelmodul. Das sollte mit jeder Distribution klappen, egal ob Xen nun direkt im Kernel enthalten ist oder später geladen wird. Das funktioniert am einfachsten per Skript. Hier das, welches ich benutze (Quelle: Xen-Wiki):

   BDF=0000:05:02.0
# Unbind a PCI function from its driver as necessary
[ ! -e /sys/bus/pci/devices/$BDF/driver/unbind ] || \
echo -n $BDF > /sys/bus/pci/devices/$BDF/driver/unbind
# Add a new slot to the PCI Backend's list
echo -n $BDF > /sys/bus/pci/drivers/pciback/new_slot
# Now that the backend is watching for the slot, bind to it
echo -n $BDF > /sys/bus/pci/drivers/pciback/bind

5. Skript und Kernelmodul kann man ganz „quick and dirty“ über die „/etc/rc.d/rc.local“ laden:

   xend start
modprobe -i xen-pciback
/etc/xen/unbind-pci.sh

6. Zuletzt muss man nur noch das Config-File für die VM angelegt werden. Meines sieht so aus:

   name = "vm-win7-01"
localtime=1
import os, re
arch = os.uname()[4]
if re.search('64', arch):
arch_libdir = 'lib64'
else:
arch_libdir = 'lib'
kernel = "/usr/lib/xen/boot/hvmloader"
builder ='hvm'
memory = 4096
vcpus = 2
cpus = "2,3"
pci_msitranslate=1
# Should be at least 2KB per MB of domain memory, plus a few MB per vcpu.
shadow_memory = 32
acpi = 1
apic = 1
disk = ['file:/home/xen/domains/win7-01/hda.img,ioemu:hda,w',
'file:/home/xen/disks/Windows_7_x64.iso,ioemu:hdc:cdrom,r'
]
boot = 'c';
device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
sdl=0
vnc=1
vncconsole=0
vncpasswd=''
serial='pty'
gfx_passthru=0
pci=['05:00.0','02:00.0,1','01:06.0']
usb = 1

   Wenn das Image („hda.img“, eine leere Datei) vorhanden ist, lässt sich das Windows mit Hardwarebeschleunigung auch schon vom DVD-iso installieren. Fertig.

Ich habe Windows auch noch eine eigene Soundkarte und eine Netzwerkkarte spendiert. Sound, da ich keine Windows-Treiber für die emulierten Karten finden konnte und Netzwerk, damit sich beide Geräte nicht den Trafic wegnehmen. Das Resultat liefert eine ähnliche Performance wie Windows direkt auf der Hardware – die gefühlte Lesegeschwindigkeit von der Festplatte ist (wohl dank Imagefile, welches man im Ram precachen kann) etwas schneller, die Gesamtperformance aber etwas schlechter (sprich: kürzere Ladezeiten aber etwas weniger FPS). Insgesamt ist es eine erwähnenswerte Alternative zum klassischen Dualboot – allein weil man ohne Wartezeit umschalten kann.

1. ^[1]Windows nur zum Zocken.↩
2. ^[2]Alle angegebenen Dateinamen sind für Fedora gültig, das ich selbst benutze. Angaben für Ubuntu werde ich mit dem Release von „Precise Pangolin“ (12.04) ergänzen, da der momentan von Ubuntu genutzte Kernel noch Handarbeit erfordert.↩

**** This file had errors that were repaired or ignored.
**** The file was produced by:
**** >>>> Microsoft® Office PowerPoint© 2007 <<<< **** Please notify the author of the software that produced this **** file that it does not conform to Adobe's published PDF **** specification.