Me: Hey, loggen wir das doch einfach in journald, dann muss ich mich nicht um Logrotation und so kümmern
#Systemd: Ja, hier dein log. Achso, ich hab 4.20mio Nachrichten einfach ignoriert und nicht gespeichert weil mir das zu viel war. Brauchst du ja sicher eh nicht.
*wedelt mit krückstock* ALS ICH NOCH JUNG WAR! >_>
Örks, #fail2ban unter #Debian greift wohl SASL Auth Fehler von #Postfix nicht, Filter wohl kaputt. Problem insbesondere unser Lieblingshassobjekt #systemd / #jounald. Also manuell.
journald -t entspricht SYSLOG_IDENTIFIER bei journalmatch. Macht dann:
journalmatch = SYSLOG_IDENTIFIER=postfix/smtps/smtpd
failregex = \[<HOST>\]: SASL ((?i)LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed:(?! Connection lost to authentication server| Invalid authentication mechanism)
Ohne Gewähr und so.
Tolle Meldung, die das Backupsystem „Veeam Backup&Replication“ da abwirft:
Auf das verworfene Objekt kann nicht zugegriffen werden. Objektname: "System.Net.Sockets.Socket"
…heißt es lapidar in der GUI, die sonst nur darüber informiert, dass kein Backup mehr funktioniert. Zwar ist recht klar, dass es am Netzwerk hängen dürfte, da hier aber pro VM-Sicherung mindestens 5 Server involviert sind gestaltet sich das etwas aufwändiger. Vor allem wenn alle relevanten Systeme fehlerfrei auf ICMP-Ping reagierten.
Tiefer im Log des Jobs fand sich eine Meldung, welche auf einen Fehler des Backupziels hindeutet. In meinem Fall handelt es sich hierbei um einen Linux-Server, welcher übers Netz beschickt wird.
<19> Info [Ssh] Server (nas5.lan.adlerweb.info) version string: "SSH-2.0-OpenSSH_7.2" <19> Info Channel encryption check: *** to *** <19> Info [AP] Starting client agent on 'nas5.lan.adlerweb.info' <19> Info [AP] Linux kernel version [uname -r]: <19> Error Failed to check kernel version. Supported Linux kernel version is assumed.
Uhmk? Im Monitoring war nichts zu sehen, außerdem kommt ja der SSH-Header. Schnell mal per KVM auf die Kiste und geprüft:
# uname -a Linux nas5 4.4.10-1-lts #1 SMP Wed May 11 21:03:02 CEST 2016 x86_64 GNU/Linux #
Also uname sollte also funktionieren. Auch der SSH-Daemon läuft noch. Im Log sind jedoch einige Meldungen, die möglicherweise das Problem beschreiben:
nas5 dbus[**]: [system] Failed to activate service 'org.freedesktop.login1': timed out nas5 sshd[**]: pam_systemd(sshd:session): Failed to create session: Failed to activate service 'org.freedesktop.login1': timed out nas5 sshd[**]: pam_systemd(sshd:session): Failed to create session: Failed to activate service 'org.freedesktop.login1': timed out
freedesktop? Das ding ist Xless -.-. Übeltäter ist wieder einmal „Server sind ja nur Ausnahmeerscheinungen“ Systemd. Dessen Loginmanager bekommt Schluckauf wenn, z.B. im Rahmen von Updated, dbus neu gestartet wird. Als Ergebnis lässt sich PAM bei Logins durchaus mal 15 Sekunden Zeit um in den Timeout zu laufen. Je nach Client/Verbindungsart kann dies jedoch bereits zum Timeout der gesamten Verbindung führen – und nichts geht mehr. um den Fehler zu beheben reicht es aus den Logind neu zu starten:
systemctl restart systemd-logind
Warum ein System, was sonst ja auch alles „on demand“ startet/stoppt/überwacht, sowas seit offenbar langer Zeit nicht in den Griff bekommt bleibt offen. Ebenso wie die Frage, warum Veeam keine genaueren Fehlermeldungen liefert.
Nicht immer kann oder möchte man ein Linux-Programm als Daemon starten – fehlende Daemon-Funktion, die Möglichkeit direkt auf STDOUT/STDERR zu schauen, etc. In den meisten Fällen bemühe ich für diese Fälle den Terminal Multiplexer „screen“. Hiermit wir die Software mit komplettem Terminal gestartet, man kann jedoch die Verbindung trennen, sodass das Programm im Hintergrund weiter seinen Dienst tut. Bei einem späteren Reconnect sind alle vorherigen Ausgaben wieder sichtbar.
Bisher startete ich diese Programme von Hand, auf einem System habe ich nun aber ein Shell-Script, welches sinnigerweise direkt beim Boot gestartet werden soll – bauen wir uns einen passenden Systemd-Service:
[Unit]
Description=Dynamic DNS updater
After=network.target
[Service]
RemainAfterExit=yes
User=root
ExecStart=/usr/bin/screen -AdmS ddns /usr/local/sbin/ddns.sh
ExecStop=/usr/bin/screen -S ddns -X quit
[Install]
WantedBy=multi-user.target
Wie unschwer zu erkennen handelt es sich um einen DDNS-Update-Daemon. Zwar würde der auch direkt laufen, da jedoch ab und an mal manuell ein Befehl abgesetzt werden muss ist mir screen lieber. Die Bedingung nach network.target zu laufen ist rein durch die DNS-Funktion bedingt und für Screen nicht notwendig.
Interessant wird es in [Service] – Erst wird der Nutzer festgelegt, welcher den Screen starten soll – da der Daemon Systemeinstellungen ändert komme ich hier um root nicht herum. Unter ExecStart wird der passende Befehl angegeben – es wird eine screen-Sitzung mit dem Namen „ddns“ gestartet und dort das Script „/usr/local/sbin/ddns.sh“ ausgeführt. In der nächsten Zeile wird zum Stoppen der Screen mit dem Namen „ddns“ beendet.
Die Datei wird unter /etc/systemd/system/ddns.service abgelegt und ist danach wie jeder andere Dienst nutzbar. Ist er mit „systemd start ddns“ gestartet kann der Nutzer root sich mittels „screen -x ddns“ zur laufenden Sitzung verbinden. Mit der Tastenkombination „Ctrl-a d“ wird die Verbindung wieder getrennt.
Einige Warnungen noch:
– Die Sitzung hat ggf. nicht alle Umgebungsvariablen, die man von einer „normalen“ Shell-Sitzung gewohnt ist
– Bricht das Script ab wird der Screen beendet, in dem Fall ist die Ausgabe/Fehlermeldung nicht mehr sichtbar. Hier kann man ggf. eine interaktive Shell nach dem Script starten und so die Sitzung offen halten. Beispiel:
ExecStart=/usr/bin/screen -AdmS ddns sh -c '/usr/local/sbin/ddns.sh ; bash'
War ja klar – gerade erst vom 30c3 zurück und schon die ersten Probleme: Auf meinem Hauptrechner hatte ich vor Abfahrt noch schnell ein Update gemacht, welches auch Systemd betraf. Bei jetzt erfolgtem, ersten Start nach dem Update hing sich das System im Bootvorgang auf:
timed out waiting for device tmpfs.device
Ursache war eine Performanceoptimierung meinerseits: /tmp liegt nicht auf einem Datenträger sondern per tmpfs im RAM. Offenbar war ich aber damals etwas zu schnell bei Copy&Paste, denn meine /etc/fstab-Zeile sah so aus:
tmpfs /tmp tmpfs defaults,nodev,nosuid 0 1
Die letzte 1 besagt, dass das System ein fsck, also Dateisystemcheck, beim Boot durchführen soll. Bisherige Systemd-Installationen ignorierten die Angabe, da tmpfs einerseits beim Boot leer ist und andererseits kein fsck-Befehl für dieses virtuelle Dateisystem existiert. Mit der neuen Version tritt obiger Fehler auf. Fix ist recht einfach: Per Boot-CD oder ohne init.d starten (init=/bin/bash als Kernel-Argument), die Root-Partition schreibbar mounten (mount -o rw /dev/sd** /mnt bzw mount -o remount,rw /) und in der /etc/fstab die letzte 1 der tmpfs-Zeile(n) gegen eine 0 ersetzen.
(85 MB) 00:49:04
2013-12-29 11:00 🛈Die grundlegenden Schritte lassen sich auf https://wiki.archlinux.org/index.php/Beginners’_Guide/Installation finden.
Die Hintergründe warum ich installiere und was meine Ziele sind finden sich in Part 1.
Inhalt
======
00:13 Download
01:05 USB-Stick zur Installation vorbereiten
02:49 Dateiintegrität per md5sum prüfen
03:30 Boot von USB-Stick
05:20 Wenns nicht bootet: acpi=off
07:00 Internetzugang konfigurieren
08:37 Tastatur auf Deutsch umschalten
08:47 Partitionieren der Festplatte
12:21 Formatieren der Partitionen (1 swap/ext2)
13:14 Verschlüsseln einer Partition mit cryptsetup
16:28 Formatieren der Partitionen (2 btrfs)
17:30 Mounten der Partitionen
18:44 Mirrorliste
19:49 Installation des Grundsystems
21:18 Erstellen einer fstab
21:47 Wechsel ins neue System
22:07 Konfiguration: locale-gen, Sprache, Keymap, Zeitzone, Hostname
24:40 initrd für Verschlüsselung anpassen
26:04 Bootloader installieren & konfigurieren
28:20 Passwort setzen
28:44 Erster Start ins neue System
29:50 Netzwerk & Installation von SSH
30:29 Dienste per Systemd
31:18 Desktop Environments: KDE/GNOME/XFCE/LXDE
33:15 Softwareinstallation: Gruppen, Provider, Optionale Abhängigkeiten, Suche
36:06 AUR: Übersicht
37:37 AUR: Installation per Hand
40:45 AUR: Installation per yaourt
43:38 fstab: Kompression für btrfs
45:16 Anlegen eines Users
45:34 Installation eines Grafikservers
46:10 Start des LXDM
46:37 Netzwerkkonfiguration per NetworkManager
47:25 Deutsche Tastatur in der grafischen Oberfläche
47:53 Anpassen des Panels: Akkumonitor
48:20 Fazit
Ergänzungen:
============
02:19 – Korrektur: bs=4M – dd if=archlinux….iso of=/dev/sdx bs=4M
07:53 – Wenn bereits beim Booten ein Netzwerkkabel eingesteckt ist bezieht der Rechner bereits eine IP, dieser Schritt kann dann entfallen
08:29 – https://wiki.archlinux.org/index.php/Beginners’_Guide/Installation#Wireless
10:03 – https://wiki.archlinux.org/index.php/Beginners’_Guide/Installation#Using_cgdisk_to_create_GPT_partitions
11:40 – SWAP = Auslagerungsspeicher, Erweiterung des RAMs auf der Festplatte. Hiermit kann das System selten genutzte Daten des Arbeitsspeichers auf die Festplatte verschieben und so den schnelleren RAM zur Verfügung halten.
20:26 – https://wiki.archlinux.org/index.php/Grub#UEFI_systems_2
42:53 – …und ein RM, welches jedoch auch OK aussieht…
46:49 – Wenn man immer Netzwerk möchte sollte man den Dienst automatisch starten: „systemctl enable NetworkManager“
Hinweise:
=========
Nicht vergessen: Es gibt keine 100%ige Sicherheit. Da die Bootdateien hier zum Beispiel nicht verschlüsselt sind könnte ein Angreifer an dieser Stelle ansetzen und den Kernel infizieren. Erschweren kann man dieses vorgehen z.B. durch ein Bootloader-Passwort, einen modifizierten Bootloader für verschlüsselte Partitionen oder durch dsa Auslagern der Boot-Dateien auf einen USB-Stick. Auch kann man z.T. mit Kältespray und entsprechender Hardware das RAM auslesen und so den Verschlüsselungskey zusammensetzen. Ebenfalls bringt die Verschlüsselung nichts, wenn eine Applikationslücke genutzt wird.
Die Migration auf Systemd hat noch immer ihre Nebenwirkungen auf meinem System: Ich verwende hauptsächlich ein Multimonitor-Setup auf meinem Rechner. Leider unterstützen nicht alle Anwendungen ein solches Konstrukt fehlerfrei, daher nutze ich von Zeit zu Zeit einen zweiten XOrg mit nur einem Monitor um die Software zu betreiben. Um diesen zu starten nutzte ich bisher den Befehl startx -- :1 -layout LayoutSingle. Über das übliche VT-Switch konnte ich ggf. zwischen den Serven wechseln, die Multimonitor-Lösung befand sich auf vt7 (Ctrl-Alt-F7) und der zweite Server mit nur einem Monitor auf vt8 (Ctrl-Alt-F8).
Nach der Migration auf Systemd war damit Schluss: Zwar startete der zweite X-Server normal und ich konnte ihn benutzen, habe ich ihn aber einmal auf eine andere Konsole verlassen gab es keine Möglichkeit mehr auf den Bildschirm zurück zu kommen. Zum Glück ist die Lösung recht einfach und offensichtlich (wenn man sie erst mal gefunden hat) – der Befehl zum Starten heißt nun startx -- :1 -layout LayoutSingle vt8