Automatische Sicherheitsupdates mit unattended-upgrades einrichten

Zwischen dem Erscheinen eines Sicherheitsupdates und seiner Installation liegt auf den meisten Servern eine Lücke. Sie entsteht selten aus Nachlässigkeit, sondern daraus, dass sich jemand vornimmt, es "nächste Woche" einzuspielen. Scanner probieren eine bekannt gewordene Schwachstelle innerhalb von Stunden durch. Das Paket unattended-upgrades schließt die Lücke.

Die Kurzfassung steht als Schritt 7 in der Checkliste für einen neuen Rootserver. Hier geht es um alles danach: Sicherheitsupdates gegen alle Updates, das Neustartverhalten auf einem Gameserver, Mailbenachrichtigung, ausgenommene Pakete, Trockenlauf und Nachweis im Protokoll.

Geprüft für Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS und Ubuntu 22.04 LTS. Wo sich die vier unterscheiden, steht es dabei. Die Befehle gelten für root; als normaler Benutzer stellen Sie jedem ein sudo voran.

Was hier eigentlich läuft

Fehlersuchen dauern hier lange, weil unklar ist, welches der drei beteiligten Teile nicht tut, was es soll:

1. Zwei systemd-Zeitgeber: apt-daily.timer für Paketlisten und Herunterladen, apt-daily-upgrade.timer für die Installation.
2. Das Skript /usr/lib/apt/apt.systemd.daily, das die Schalter unter APT::Periodic:: auswertet.
3. Das Programm unattended-upgrade, das die Schalter unter Unattended-Upgrade:: auswertet und die Arbeit erledigt.

Achten Sie auf die Einzahl: Paket unattended-upgrades, Programm unattended-upgrade.

systemctl list-timers 'apt-daily*' --all
systemctl cat apt-daily-upgrade.timer

Die Spalten LAST und PASSED zeigen, ob je ein Lauf stattgefunden hat. In der Unit steht OnCalendar=*-*-* 6:00 mit RandomizedDelaySec=60m: Der Lauf findet zwischen sechs und sieben statt, bei apt-daily.timer mit zwölf Stunden Streuung. Wer um 06:05 nachsieht, hält den Mechanismus fälschlich für kaputt.

Vor der ersten Änderung: der Rückweg

Automatische Updates greifen ein, wenn Sie nicht davorsitzen. Drei Dinge können schiefgehen: Ein Neustart nimmt den Server aus dem Betrieb, ein Paketvorgang bricht ab und hinterlässt dpkg unvollständig, oder ein Dienst startet danach nicht mehr.

Der Zugang, der in allen drei Fällen noch funktioniert, ist nicht SSH. KVM-Rootserver und Dedicated Server von KernelHost haben kein IPMI und kein iDRAC, der Notzugang läuft über die VNC-Konsole im Kundenbereich. Sie hängt an der Virtualisierungsschicht beziehungsweise am Anschluss selbst, eine Störung im Gastsystem erreicht sie also nicht. Melden Sie sich einmal vorher darüber an und prüfen Sie das root-Passwort. Ein Rettungsweg, den man erst im Ernstfall ausprobiert, ist keiner.

Dann den Ausgangszustand sichern:

mkdir -p /root/vor-unattended
cp -a /etc/apt/apt.conf.d/50unattended-upgrades /root/vor-unattended/
dpkg --get-selections > /root/vor-unattended/pakete.txt
apt-mark showhold > /root/vor-unattended/holds.txt

Den Notausschalter gibt es zweimal. Hart über die Zeitgeber:

systemctl disable --now apt-daily-upgrade.timer apt-daily.timer

Der weiche Weg setzt in /etc/apt/apt.conf.d/20auto-upgrades den Wert APT::Periodic::Unattended-Upgrade "0";. Dann bleiben die Paketlisten aktuell, installiert wird nichts.

Erfolgskontrolle:

systemctl is-enabled apt-daily-upgrade.timer
apt-config dump APT::Periodic

Zum Zurückrollen: /var/log/apt/history.log nennt alte und neue Versionsnummer. Ein apt install paket=version gelingt aber nur, solange die alte Version noch auf einem Spiegelserver liegt, und die Archive halten meist nur den aktuellen Stand vor. Planen Sie mit Vorwärtskorrektur und Sicherung.

Installation und Scharfschalten

apt update
apt install -y unattended-upgrades

Unterschied zwischen den Distributionen: Auf Ubuntu 22.04 und 24.04 ist das Paket auf Serverabbildern installiert und aktiv, prüfen Sie dort zuerst. Auf Debian fehlt es auf Minimalabbildern, und die Installation fragt, ob stabile Aktualisierungen automatisch eingespielt werden sollen. Läuft sie nicht interaktiv, etwa im Abbildbau, gilt die Voreinstellung und die entscheidende Datei entsteht nicht.

Denn das Paket allein schaltet nichts scharf. Das tut erst diese Datei:

cat /etc/apt/apt.conf.d/20auto-upgrades

Fehlt sie, meldet der Befehl cat: /etc/apt/apt.conf.d/20auto-upgrades: No such file or directory. Dann holen Sie die Rückfrage mit dpkg-reconfigure -plow unattended-upgrades nach oder schreiben die Datei selbst:

cat > /etc/apt/apt.conf.d/20auto-upgrades <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";
EOF

Die Werte sind keine Ja-Nein-Schalter, sondern Abstände in Tagen: "1" täglich, "7" höchstens wöchentlich, "0" aus. AutocleanInterval räumt Paketdateien weg, die es auf dem Spiegelserver nicht mehr gibt, auf kleinen Systemplatten spürbar (Festplatte voll unter Linux).

Erfolgskontrolle: apt-config dump APT::Periodic gibt die gesetzten Zeilen aus. Kommt gar nichts, wurde keine Datei gelesen und der nächtliche Lauf tut nichts.

Eigene Einstellungen an der richtigen Stelle

Die mitgelieferte /etc/apt/apt.conf.d/50unattended-upgrades gehört dem Paket. Ändern Sie sie, entsteht beim nächsten Paketupdate ein Konflikt über die Konfigurationsdatei, und unattended-upgrades überspringt das Paket dann. Das Werkzeug für automatische Updates wäre selbst davon ausgenommen.

Eigene Werte gehören in eine eigene Datei mit höherer Nummer. APT liest das Verzeichnis alphabetisch, bei einfachen Werten gewinnt der zuletzt gelesene:

cat > /etc/apt/apt.conf.d/52unattended-upgrades-local <<'EOF'
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
Unattended-Upgrade::MinimalSteps "true";
EOF

MinimalSteps ist ab Werk an und zerlegt den Lauf in kleine Schritte, die sich beim Herunterfahren sauber abbrechen lassen. Remove-Unused-Kernel-Packages räumt alte Kernel ab, die sonst die /boot-Partition füllen. Die beiden Aufräumschalter sind auf Ubuntu ab Werk gesetzt, auf Debian nicht.

Der Dateiname ist kein Detail. APT liest hier nur Dateien ohne Endung oder mit .conf, und nur Namen aus Buchstaben, Ziffern, Bindestrich, Unterstrich und Punkt. Eine Sicherungskopie 52unattended-upgrades-local.bak wird stillschweigend übergangen, was praktisch ist; eine Datei 52-meine-einstellungen.txt genauso, was ärgerlich ist.

Erfolgskontrolle, sofort nach jeder Änderung:

apt-config dump > /dev/null && echo "Syntax in Ordnung"
apt-config dump | grep "^Unattended-Upgrade::"

Ein fehlendes Semikolon legt jeden apt-Aufruf lahm, auch den nächtlichen.

Nur Sicherheitsupdates oder alle Updates

Welche Pakete infrage kommen, entscheidet eine Liste erlaubter Quellen. Die Distributionen unterscheiden sich schon im Schlüsselnamen: Debian nutzt Unattended-Upgrade::Origins-Pattern, Ubuntu Unattended-Upgrade::Allowed-Origins.

sed -n '/Allowed-Origins\|Origins-Pattern/,/};/p' /etc/apt/apt.conf.d/50unattended-upgrades

Aktiv sind ab Werk die Muster für die Sicherheitsquelle und für das Stammarchiv der eigenen Veröffentlichung. Auskommentiert sind die Pockets -updates, -proposed und -backports. Auf Ubuntu stehen zusätzlich zwei Einträge für den erweiterten Wartungsdienst darin; ohne Abonnement liefern sie nichts. Die Platzhalter ${distro_id} und ${distro_codename} löst das Programm zur Laufzeit auf, etwa zu Debian und trixie.

Woher die Bestandteile eines Musters stammen, zeigt apt-cache policy. Zu jeder Quelle steht dort eine Zeile ab release mit den Feldern o= (Ursprung), a= (Archiv), n= (Codename), l= (Label) und c= (Komponente). Die Debian-Sicherheitsquelle trägt das Label Debian-Security, genau darauf zielt das mitgelieferte Muster.

Sollen auch die laufenden Korrekturen der Distribution automatisch kommen, ergänzen Sie das Muster in Ihrer eigenen Datei. Listen werden in der apt-Konfiguration ergänzt und nicht ersetzt:

Unattended-Upgrade::Origins-Pattern {
        "origin=Debian,codename=${distro_codename}-updates";
};

Auf Ubuntu lautet die Entsprechung "${distro_id}:${distro_codename}-updates"; in einem Allowed-Origins-Block. Eine Liste vollständig ersetzen können Sie nur, indem Sie sie vorher mit #clear Unattended-Upgrade::Origins-Pattern; leeren.

Für Fremdquellen gilt dasselbe Verfahren. Sie liefern allerdings oft neue Funktionsversionen statt reiner Sicherheitskorrekturen; unbeaufsichtigt nachts eingespielt ist das eine andere Risikoklasse. Für Produktivsysteme gilt deshalb: bei den Sicherheitsquellen bleiben.

Der Trockenlauf

apt update
unattended-upgrade --dry-run --debug

Das apt update davor ist kein Beiwerk: Der Trockenlauf aktualisiert die Paketlisten nicht selbst, ohne den Aufruf bewerten Sie den Stand von gestern. Installiert wird nichts. Vier Stellen der Ausgabe zählen:

• Allowed origins are: mit der Liste, die tatsächlich gilt. Das ist der Nachweis, dass Ihre Änderung angekommen ist, nicht der Blick in die Datei.
• Initial blacklist: mit Ihren Ausnahmen. Steht dort nichts, obwohl Sie welche eingetragen haben, wird Ihre Datei nicht gelesen.
• Zeilen ab Checking:, je Paket mit Quelle und Zulassung.
• Am Ende entweder Packages that will be upgraded: mit einer Liste oder No packages found that can be upgraded unattended and no pending auto-removals.

Die letzte Meldung erscheint auch dann, wenn apt list --upgradable sehr wohl Pakete auflistet. Das ist kein Fehler, sondern der Filter bei der Arbeit: Jedes Paket, das dort steht und im Trockenlauf fehlt, kommt aus einer nicht erlaubten Quelle, steht auf Ihrer Ausnahmeliste, ist per apt-mark hold festgehalten oder löst eine Konfigurationsrückfrage aus.

Pakete von der Automatik ausnehmen

Manches soll nicht nachts aktualisiert werden: eine Datenbank, deren Neustart eine Anwendung abhängt, oder der Kernel eines Systems, das nicht unangekündigt neu startet. Der erste von zwei Wegen wirkt nur auf die Automatik:

Unattended-Upgrade::Package-Blacklist {
        "mariadb-server$";
        "nginx$";
        "linux-image-";
};

Die Einträge sind reguläre Ausdrücke, verankert am Anfang des Paketnamens. "nginx" ohne Dollarzeichen trifft deshalb auch nginx-common und nginx-full; das $ begrenzt den Eintrag auf genau diesen Namen. Umgekehrt ist "linux-image-" ohne $ richtig, wenn Sie sämtliche Kernelpakete meinen.

Der zweite Weg wirkt auf jeden apt-Aufruf, also auch auf Ihr manuelles apt upgrade:

apt-mark hold mariadb-server
apt-mark showhold

Aufgehoben wird das mit apt-mark unhold. Soll ein Paket nur nicht unbeaufsichtigt aktualisiert werden, nehmen Sie die Ausnahmeliste; soll es gar nicht aktualisiert werden, hold.

Erfolgskontrolle: apt-config dump | grep -i "Package-Blacklist" und apt-mark showhold. Die unbequeme Seite: Ein ausgenommenes Paket müssen Sie selbst aktualisieren. Notieren Sie einen Termin dafür, sonst ist die Ausnahme in einem halben Jahr eine vergessene Schwachstelle.

Automatischer Neustart

Ein neuer Kernel liegt nach dem Update auf der Platte, läuft aber erst nach einem Neustart; ersetzte Bibliotheken wirken erst, wenn der Dienst neu startet. Drei Schalter steuern das:

Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot ist ab Werk aus. Automatic-Reboot-WithUsers ist ab Werk an, und das überrascht viele: Eine offene SSH-Sitzung verhindert den Neustart nicht; wer das will, setzt den Wert auf "false". Automatic-Reboot-Time gehört zwingend dazu, sobald der Neustart an ist. Ohne die Angabe gilt now, der Server startet also gleich nach dem Lauf neu, mithin zwischen sechs und sieben Uhr morgens.

Ausgelöst wird er nicht vom Kernelpaket, sondern von einer Markierungsdatei:

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

Der folgenreichste Unterschied dieses Artikels: Ubuntu legt diese Datei an (aus dem Paket update-notifier-common), die zweite nennt die verantwortlichen Pakete. Debian legt sie standardmäßig nicht an. Dort kann Automatic-Reboot "true" dauerhaft wirkungslos bleiben, ohne dass etwas einen Fehler meldet. Wer sich darauf verlässt, läuft monatelang mit einem alten Kernel und einem guten Gefühl. Auf Debian hilft stattdessen:

apt install -y needrestart
needrestart -b

Die Ausgabe nennt unter NEEDRESTART-KCUR den laufenden und unter NEEDRESTART-KEXP den erwarteten Kernel; unterscheiden sie sich, steht ein Neustart an. Die Zeilen NEEDRESTART-SVC listen die Dienste, die noch mit ersetzten Bibliotheken laufen.

Warum die Einstellung auf einem Gameserver anders aussieht

Auf einem Webserver ist ein Neustart um 02:00 eine Sache von Sekunden, die niemand bemerkt. Auf einem Gameserver sind Spieler verbunden, die Welt liegt im Arbeitsspeicher, und der Spielstand wird erst beim geordneten Beenden vollständig geschrieben. Wird der Prozess hart abgeräumt, verlieren Sie die Fortschritte seit dem letzten Zwischenspeichern, im schlechteren Fall ist die Weltdatei beschädigt.

Dazu kommt ein Detail von systemd: Beim Herunterfahren bekommt jeder Dienst sein Stoppsignal und danach eine begrenzte Frist, nach deren Ablauf hart beendet wird. Ein Spielserver, der beim Beenden erst speichert, braucht oft mehr Zeit als die Voreinstellung hergibt, und ein Stoppkommando, das der Serverkonsole ein stop schickt statt nur ein Signal an einen Starter. Für Gameserver ist deshalb diese Kombination die vernünftige:

• Automatic-Reboot "false". Die Sicherheitsupdates laufen weiter, der Neustart bleibt Ihre Entscheidung.
• Ein Wartungsfenster mit wenigen Spielern, angekündigt statt überraschend.
• Eine systemd-Unit mit speicherndem Stoppkommando und ausreichender TimeoutStopSec, siehe systemd-Service erstellen.
• Falls doch automatisch, dann Automatic-Reboot-Time auf eine Uhrzeit mit niedriger Spielerzahl.

Prüfen lässt sich das ohne Neustart: Dienst mit systemctl stop beenden, Spielstand ansehen, wieder starten. Läuft das sauber, übersteht er auch einen Neustart um 02:00.

Die Uhrzeit des Laufs verschieben

systemctl edit apt-daily-upgrade.timer

[Timer]
OnCalendar=
OnCalendar=*-*-* 03:30
RandomizedDelaySec=30m

Die leere Zeile OnCalendar= ist zwingend, sie löscht den mitgelieferten Wert. Ohne sie kommt Ihre Uhrzeit zusätzlich dazu und der Lauf findet zweimal täglich statt.

systemctl daemon-reload
systemctl restart apt-daily-upgrade.timer
systemctl list-timers 'apt-daily*' --all

Erfolgskontrolle: In der Spalte NEXT steht die neue Uhrzeit.

Benachrichtigung per E-Mail

Ein Mechanismus, von dem niemand etwas hört, wird nicht überwacht, sondern vergessen. Zwei Zeilen ändern das:

Unattended-Upgrade::Mail "admin@ihre-domain.de";
Unattended-Upgrade::MailReport "on-change";

MailReport kennt drei Werte: always nach jedem Lauf, on-change nur wenn etwas installiert wurde oder schiefging, only-on-error nur im Fehlerfall. Den älteren Schalter MailOnlyOnError ersetzen Sie, wenn Sie ihn vorfinden.

Voraussetzung ist ein Versandweg. unattended-upgrades verschickt über /usr/bin/mail beziehungsweise /usr/sbin/sendmail. Fehlt beides, unterbleibt der Versand, und Sie merken nichts davon. Auf einem frischen Server ist das der Normalfall:

apt install -y bsd-mailx
echo "Testnachricht" | mail -s "Test vom Server" admin@ihre-domain.de

Dabei wird ein Mail-Transport-Dienst mitinstalliert. Prüfen Sie danach mit ss -lntp | grep ':25', dass er nur auf 127.0.0.1 lauscht. Nachrichten direkt von einer Server-IP landen zudem häufig im Spamordner; soll der Bericht ankommen, führen Sie den Versand über einen Relay-Server mit sauber eingerichteter Absenderdomain.

Praktischer Rat: Für die ersten zwei Wochen always einstellen. Eine tägliche Nachricht, die meldet, dass nichts zu tun war, ist der einfachste Beweis dafür, dass der Mechanismus läuft. Danach zurück auf on-change, sonst löschen Sie sie bald ungelesen.

Nachlesen, ob wirklich etwas passiert ist

ls -l /var/log/unattended-upgrades/
tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log

Dort liegen bis zu drei Dateien. unattended-upgrades.log hält fest, was das Programm entschieden hat. unattended-upgrades-dpkg.log enthält die rohe Ausgabe der Installation, dort sehen Sie nach, wenn ein Paket beim Einrichten gescheitert ist. unattended-upgrades-shutdown.log entsteht bei einem Lauf, der beim Herunterfahren endete.

Ein ereignisloser Lauf endet mit No packages found that can be upgraded unattended and no pending auto-removals. Ein Lauf, der etwas getan hat, enthält Packages that will be upgraded: und weiter unten All upgrades installed. Ist die Datei leer oder fehlt der Ordner, hat nie ein Lauf stattgefunden.

Unabhängig davon protokolliert die Paketverwaltung jede Aktion mit alter und neuer Versionsnummer:

grep -E "^(Start-Date|Commandline|Upgrade|End-Date):" /var/log/apt/history.log | tail -n 20
zgrep -h "^Upgrade:" /var/log/apt/history.log*.gz | tail -n 10

Der zweite Aufruf greift auf die rotierten Dateien zu; wer nur die aktuelle ansieht, findet nichts und schließt daraus das Falsche. Die dritte Quelle ist systemd:

journalctl -u apt-daily-upgrade.service --since "-7 days" --no-pager

Die Falle, die fast jeder einmal tritt: systemctl status unattended-upgrades.service zeigt dauerhaft active (running). Das ist kein laufendes Update. Diese Unit schließt einen begonnenen Lauf beim Herunterfahren ab und wartet sonst. Installiert wird in apt-daily-upgrade.service.

Häufige Fehler und Lösungen

cat: /etc/apt/apt.conf.d/20auto-upgrades: No such file or directory
Das Paket ist installiert, aber nichts eingeschaltet; auf Debian der Normalzustand nach nicht interaktiver Installation. Abhilfe: dpkg-reconfigure -plow unattended-upgrades.

No packages found that can be upgraded unattended and no pending auto-removals, obwohl apt list --upgradable Pakete zeigt
Kein Fehler, sondern der Filter. Prüfen Sie der Reihe nach: erlaubte Quellen im Trockenlauf, Ausnahmeliste, apt-mark showhold, Konfigurationsrückfragen.

E: Syntax error /etc/apt/apt.conf.d/52unattended-upgrades-local:2: Extra junk at end of file
Ein fehlendes Semikolon am Zeilenende oder eine nicht geschlossene geschweifte Klammer. Solange der Fehler drinsteht, scheitert jeder apt-Aufruf, nicht nur die Automatik.

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1234 (unattended-upgr) zusammen mit E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
Der automatische Lauf ist beschäftigt; der auf fünfzehn Zeichen abgeschnittene Prozessname verrät es. Warten Sie ein paar Minuten. Den Prozess abzuschießen erzeugt den nächsten Fehler dieser Liste. Ausführlich: apt konnte Sperre nicht aufheben.

E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.
Genau diesen Befehl ausführen. Der ab Werk gesetzte Unattended-Upgrade::AutoFixInterruptedDpkg lässt den nächsten Lauf das selbst reparieren, aber nur, wenn er bis dahin kommt.

Package nginx-common has conffile prompt and needs to be upgraded manually im Protokoll
Sie haben eine Konfigurationsdatei geändert, die dem Paket gehört, und die neue Version bringt eine geänderte Fassung mit. Das Programm überspringt das Paket dann dauerhaft. Erledigen Sie das Update von Hand. Offene Fälle zeigt:

find /etc -type f \( -name "*.dpkg-dist" -o -name "*.dpkg-new" -o -name "*.ucf-dist" \)

Cache has broken packages, exiting im Protokoll
Aus einer früheren Aktion ist ein unvollständiger Zustand übrig. apt --fix-broken install, danach dpkg --configure -a. Bis dahin tut die Automatik jede Nacht nichts.

Ihre Einstellungen wirken nicht, und es gibt keine Fehlermeldung.
Das Kennzeichen eines übergangenen Dateinamens. Prüfen Sie mit apt-config dump | grep -i unattended, ob die Werte gelesen wurden.

Automatic-Reboot "true" bewirkt auf Debian nichts.
Dort fehlt die Markierungsdatei /var/run/reboot-required.

Die vier Systeme im Vergleich

Was die Automatik nicht leistet

• Keinen Wechsel auf eine neue Hauptversion und keine Fremdquellen, solange kein Muster dafür eingetragen ist.
• Nichts außerhalb der Paketverwaltung. Von Hand entpackte Programme, Erweiterungen eines Redaktionssystems, Plugins eines Spielservers und Container laufen mit ihrem Stand weiter.
• Keinen Ersatz für Sicherung und Überwachung. Ein Update kann einen Dienst zum Stehen bringen, und wenn niemand hinsieht, steht er bis zum Morgen.
• Keinen Schutz vor Netzangriffen. Aktuelle Pakete schließen bekannte Schwachstellen, gegen Volumenangriffe hilft nur Filterung im Netz davor, bei KernelHost im Rechenzentrum maincubes in Frankfurt am Main.

Die Abschlusskontrolle

1. apt-config dump APT::Periodic gibt Update-Package-Lists "1" und Unattended-Upgrade "1" aus.
2. apt-config dump | grep "^Unattended-Upgrade::" zeigt Ihre eigenen Werte.
3. systemctl list-timers 'apt-daily*' --all zeigt beide Zeitgeber mit plausibler Spalte NEXT.
4. unattended-upgrade --dry-run --debug läuft fehlerfrei durch und nennt die erwarteten Quellen.
5. tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log enthält nach dem ersten Lauf einen Eintrag mit Datum.
6. ls -l /var/run/reboot-required auf Ubuntu, needrestart -b auf Debian.

Punkt fünf zählt wirklich, und er braucht einen Tag Geduld: Alles davor ist Vorbereitung, erst der Eintrag von heute Nacht ist der Beweis.