Schlagwort-Archive: Linux

BitNotice #108 – Rspamd: Server-SPAM-Filter mit Postfix

BitNotice #108 - Rspamd: Server-SPAM-Filter mit Postfix

(36 MB) 00:23:26

2017-04-30 10:30 🛈

Aktuell teste ich für einige meiner Server neue Setups, unter anderem zur SPAM-Abwehr. Einen recht soliden Eindruck macht hierbei Rspamd, ein in C geschriebener SPAM-Filter mit LUA-Modulen. Neben einer großen Liste an Header- und Contentfiltern für die Punktevergabe beherrscht er auch die üblichen Dinge wie SPF, DKIM, DCC und RBLs. Ergänzt durch einen selbstlernenden Bayes-Filter soll so der „Unrat“ abgehalten werden. Ergänzt wird das Ganze durch ein Webinterfact, welches Statistiken bietet und Parametereinstellungen zulässt.

Zusammen mit Postfix und RMilter lässt sich so ein Setup erstellen, welches die Prüfung bereits während des Empfangs durchführt. So lässt sich die Mail unverzüglich ablehnen und man belästigt keine Dritten mit ungewolltem Backscatter.

Hier mal kurz und etwas Planlos die Installation des Rspamd mit Zubehör sowie die Integration in Postfix.

Edit: Je nach Setup muss der Postfix-User der Gruppe rmilter hinzugefügt werden

ZFS/ZOL: Pool UNAVAIL nach Reboot

Nicht schön. Nach dem Reboot eines Server musste ich feststellen, dass diverse Storages nicht mehr zugreifbar waren. Schnell stellte sich heraus, dass alle ZFS-Pools offline waren und die Geräte mit der Meldung „too many errors“ als FAULTED markiert wurden.

 zpool import
   pool: tempstore
     id: xyz
  state: UNAVAIL
 status: One or more devices are faulted.
 action: The pool cannot be imported due to damaged devices or data.
 config:

        tempstore   UNAVAIL  insufficient replicas
          sdd       FAULTED  too many errors
          sde       FAULTED  too many errors

   pool: storage
     id: xyy
  state: UNAVAIL
 status: One or more devices are faulted.
 action: The pool cannot be imported due to damaged devices or data.
 config:

        storage     UNAVAIL  insufficient replicas
          sdb       FAULTED  too many errors

Nunja, Consumer-Platten traue ich ja viele defekte zu, aber drei unabhängige Platten gleichzeitig? Eher nein. Auch S.M.A.R.T. zeigte keine wirklich bedenkenswerten Werte. Aufschlussreicher ist da schon das Kernel-Log:

[  776.890127] Large kmem_alloc(131128, 0x1000), please file an issue at:
               https://github.com/zfsonlinux/zfs/issues/new
[  776.890129] CPU: 1 PID: 12969 Comm: vdev_open Tainted: P           O    4.4.39-gentoo-adlerweb #2
[  776.890130] Hardware name: LENOVO yxz/        , BIOS xyz 01/10/2012
[  776.890132]  0000000000000000 ffff880417a37bc0 ffffffff813545d8 000000000240c200
[  776.890134]  0000000000000000 ffff880417a37c00 ffffffffa0018af1 0000000017a37be0
[  776.890138]  0000000000000000 ffff88041626d480 ffff8804174ed660 0000000000004000
[  776.890139] Call Trace:
[  776.890144]  [<ffffffff813545d8>] dump_stack+0x4d/0x65
[  776.890148]  [<ffffffffa0018af1>] spl_kmem_zalloc+0x131/0x180 [spl]
[  776.890163]  [<ffffffffa0109aa8>] vdev_cache_stat_fini+0x258/0xcc0 [zfs]
[  776.890175]  [<ffffffffa010a3ba>] vdev_cache_stat_fini+0xb6a/0xcc0 [zfs]
[  776.890188]  [<ffffffffa014426a>] zio_data_buf_free+0x51a/0xdc0 [zfs]
[  776.890200]  [<ffffffffa014798f>] zio_nowait+0xaf/0x190 [zfs]
[  776.890215]  [<ffffffffa0104cce>] vdev_probe+0xfe/0x200 [zfs]
[  776.890228]  [<ffffffffa01059e0>] ? vdev_accessible+0x70/0x2b0 [zfs]
[  776.890240]  [<ffffffffa0107969>] vdev_open+0x3c9/0x4b0 [zfs]
[  776.890251]  [<ffffffffa0107bdd>] vdev_open_children+0x18d/0x1c0 [zfs]
[  776.890254]  [<ffffffffa001b8ec>] taskq_dispatch+0x3ac/0x5b0 [spl]
[  776.890257]  [<ffffffff810c1ed0>] ? wake_up_q+0x70/0x70
[  776.890261]  [<ffffffffa001b6e0>] ? taskq_dispatch+0x1a0/0x5b0 [spl]
[  776.890263]  [<ffffffff810b8c04>] kthread+0xc4/0xe0
[  776.890265]  [<ffffffff810b8b40>] ? kthread_park+0x50/0x50
[  776.890268]  [<ffffffff81a6a5df>] ret_from_fork+0x3f/0x70
[  776.890270]  [<ffffffff810b8b40>] ? kthread_park+0x50/0x50

*kick* Da war ja was. ZOL läuft wegen der Lizenzproblematik als Kernel-Modul. Ich hatte zuletzt am Kernel einige Treiber nachgezogen. Hierbei sind zwar Version und Ablageort gleich geblieben, offenbar ist aber die ABI etwas gewandert, sodass SPL/ZFS etwas verwirrt den Dienst quittierten.

Für Gentoo heißt das einmal Module neu Bauen, in meinem Fall

emerge -va spl zfs-kmod

 

Alternativ und in den meisten Fällen zuverlässiger ist es nach jeder Kernel-Änderung alle Module automatisch neu zu erstellen:

emerge -va @module-rebuild

Storage online, Admins glücklich, Update-Doku ergänzt. Passt.

STDOUT verdoppeln mit ftee

Mal wieder eine etwas andere Anforderung: Für eine automatische Verarbeitung soll eine Audioquelle durch eine Software auf der Konsole ausgewertet werden. Die Software ist hierbei für die Analyse von Dateien ausgelegt, kann allerdings auch von STDIN lesen. So weit kein Problem – arecord kümmert sich um die Aufnahme und per STDOUT/Pipe geht es in die Analysesoftware. Leider gibt es hier einen Haken: Es funktioniert nicht zuverlässig. Um zu prüfen ob die Audioquelle oder die Analyse das Problem verursacht müsste ich die eingehenden Audiodateien abhören. Am PC ginge das mit Pulseaudio recht einfach, am Server möchte ich auf dieses Ressourcen- und Dependency-Monster jedoch vorzugsweise verzichten.

Dann halt per File

Meine erste Idee: tee. Mit diesem Befehl kann man die Dateien einer Pipe in eine zusätzliche Datei „abzwacken“:

arecord hw:1,0 | tee test.daten | analyzer -

Was prinzipiell funktioniert hat jedoch einen entscheidenden Nachteil: Es landet alles in der Datei. Dauerhaft. Möchte man nicht, dass die Festplatte voll läuft, muss man nach dem reinhören das Konstrukt abbrechen und ohne tee-Befehl neu starten. Eher unschön, denn das heißt auch Deattime, also eine kurze Zeitspanne in der ich möglicherweise Ereignisse verpasse.

Und was ist mit FIFO?

Als Alternative eignet sich ein FIFO, auch als named Pipe bezeichnet. Diese lassen sich mit mkfifo anlegen und stellen sozusagen einen „Puffer“ zur Verfügung, über den sich Prozesse verbinden lassen. Hier können wir im ersten Terminal z.B. wie folgt starten:

mkfifo test.fifo
arecord hw:1,0 | tee test.fifo | analyzer -

und im Zweiten den Stream abgreifen

cat test.fifo > test.daten

Dummerweise gibt es auch hier Probleme: Es blockiert. Der Analyzer im ersten Terminal wird erst gestartet, wenn wir im Zweiten beginnen den Puffer zu lesen. Schlimmer noch: Brechen wir im zweiten Terminal das Mitlesen ab wird auch der Analyzer beendet. Nicht wirklich was ich suche.

Dauer-Interimslösung

Nunja, da mir die Ideen ausgingen und das Internet auf den ersten Blick nichts passendes lieferte blieb es erst mal bei der dauerhaften Dateiaufzeichnung auf einen speziell limitierten Ordner. Lief alle paar Wochen die zugehörige Partition voll brach die Software ab und ich startete per Hand neu. Auf der Todo-Liste stand etwas von automatischen Neustarts oder einem Gebastel um nur bei Bedarf die Ausgabe zur named Pipe zu starten. Dieser Zustand hielt nun für etwa 2 Jahre.

Rettung bei Stackoverflow

Heute ging es dann um die Behebung. Ich hatte grade ein Rendering gestartet und entsprechend etwas Leerlauf als die altbekannte Mail kam: Partition voll, die Erkennung steht. Jetzt reicht es. Also schnell auf Google und etwas in die Verwendung von Named Pipes einlesen.

Moment.

Nach kurzer Recherche landete ich bei Stackoverflow (wo auch sonst). Nach „Linux non-blocking fifo“ erkundigt sich der Autor „Dronus“ und beschreibt ein Szenario, welches recht Nah an meine Andorderungen heran kam. Und Beantworter „racic“ lieferte auf ganzer Linie: „ftee“ nennt sich sein überschaubarer C-Code, welcher das verhalten von tee nachmacht, jedoch für den FIFO nicht blockiert. Auch wird SIGPIPE, welches beim Abbrechen des Lesevorgangs der Pipe ausgelöst wird, nicht beachtet, der Analyzer läuft also fleißig weiter. Greift man später erneut auf die Pipe zu erhält man wieder die aktuellen Daten.

Wer „wichtige“ Daten nutzt kann alternativ auf das ebenfalls dort zu findende bftee von Fabraxias zurückgreifen, welches bei einem Abbruch der Verbindung alle eingehenden Daten zwischenspeichert und bei der nächsten Verbindung erst einmal nachliefert.

Für mich ist die nicht gepufferte Variante ideal – alte Audiodaten sind für mich nicht relevant. Das Kompilieren ist mit aktuellem GCC schnell erledigt und allein das ersetzen von tee gegen ftee im vorherigen Beispiel löst alle Probleme. Der Analyzer läuft und ich kann bei Bedarf in den Audiostream reinhören ohne eine Unterbrechung der Auswertung zu bekommen. Fein.

rsync vs. curlftpfs: mkstemp-Fehler

Hach ja, wenn Theorie und Praxis mal passen würden. Bei vielen meiner Server bietet der Anbieter einen kostenfreien Backupspeicher an. Gut, ob man dem Vertraut steht wo anders, aber eine weitere (verschlüsselte) Kopie kann ja nicht schaden, richtig?

Am schönsten wäre es für mich Borg einfach ein weiteres Repo auf dem Backupspeicher anlegen zu lassen. Leider gibt es da ein Problem: Der Anbieter bietet den Zugriff nur per FTP an, welches von Borg nicht nativ unterstützt wird.

Zwar ist es mit curlftpfs möglich den Server als lokalen Ordner einzubinden, allerdings unterstützt der Dateisystemtreiber viele Standardoperationen nicht wirklich und hat seit 2008 kein Update mehr gesehen. Mangels Alternativen bleibt wohl nur herumbasteln. Leider konnte ich mit keiner noch so exotischen Kombination – egal ob mount-Parameter oder loop-Devices – eine Funktionierende Umgebung für Borg kreieren, also muss ein weiterer Umweg als Workaround her.

Da lokal genug Platz vorhanden ist lautet das Konzept: Borg sichert in einen lokalen Ordner, der wird dann auf den FTP gespiegelt. Klarer Job für rsync, oder? Naja, sieht die Software anders:

rsync: mkstemp "/mnt/backup/ftp/repo/data/0/.1290.dU25tM" failed: Operation not supported (95)

Glücklicherweise betrifft das Problem wohl ausschließlich die mkstemp-Funktion, welche rsync nur für temporäre Kopien benötigt. Diese werden Standardmäßig auf dem Ziel erstellt, lassen sich über einen passenden Parameter aber auch in anderen, lokalen Ordnern ablegen. Der komplette Befehl lautet dann z.B.

rsync --temp-dir=/tmp/rsync --no-owner --no-group -avP /mnt/backup/staging/ /mnt/backup/ftp/

So werden nur noch die wirklichen Zieldaten auf dem FTP-Server abgelegt und die Kopie scheint zuverlässig zu funktionieren. Alles nicht sonderlich schön, aber immerhin funktioniert das Konstrukt und eine weitere Kopie liegt irgendwo rum. Man könnte natürlich auch einfach NFS/iSCSI/… anbieten, aber das wäre ja moderne Technik…

BitBastelei #204 – Linux-Shell-Erweiterung: Powerline für Bash/vim/tmux & Co

BitBastelei #204 - Linux-Shell-Erweiterung: Powerline für Bash/vim/tmux & Co

(20 MB) 00:13:32

2016-07-17 10:00 🛈

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2016/07/powerline-mini-300×59.pngAls Bastler arbeite ich recht viel auf der Linux-Konsole – ein mächtiges Werkzeug, aber nicht unbedingt übersichtlich. Mit dem Tool „powerline“ kann man mit überschaubarem Aufwand die Shell aufhübschen und um diverse Widgets ergänzen. Während Dinge wie Wettervorhersage für mich eher nach unnötiger Spielerei aussehen sind z.B. Statusinformationen in GIT-Ordnern oder der aktuelle Batteriezustand wertvolle Helfer.

Die Installation kann bei Arch, Gentoo und Debian über bereitgestellte Pakete erfolgen, alternativ lässt sich der distributionsunabhängige Python-Paketmanager „pip“ verwenden. Alle Installationsmethoden werden in der Doku beschrieben.

Konfigurationen

https://gist.github.com/adlerweb/14f7543479645483b01e679d7ca307b7

# Powerline
if [ -f `which powerline-daemon` ]; then
        powerline-daemon -q
        POWERLINE_BASH_CONTINUATION=1
        POWERLINE_BASH_SELECT=1
        . /usr/lib/python3.5/site-packages/powerline/bindings/bash/powerline.sh
fi
let $PYTHONPATH='/usr/lib/python3.5/site-packages'
set rtp+=/usr/lib/python3.5/site-packages/powerline/bindings/vim/
set laststatus=2
set t_Co=256
set -g default-terminal "screen-256color"
powerline-config tmux setup
{
	"segments": {
		"left": [
			{
				"function": "powerline.segments.shell.mode"
			},
			{
				"function": "powerline.segments.common.net.hostname",
				"priority": 10
			},
			{
				"function": "powerline.segments.common.env.user",
				"priority": 30
			},
			{
				"function": "powerline.segments.common.env.virtualenv",
				"priority": 50
			},
			{
				"function": "powerline.segments.shell.last_pipe_status",
				"priority": 10
			},
			{
				"function": "powerline.segments.shell.cwd",
				"priority": 10
			},
			{
				"function": "powerline.segments.shell.jobnum",
				"priority": 20
			},
			{
				"function": "powerline_gitstatus.gitstatus",
				"priority": 40
			}
		],
		"right": [
			{
				"function": "powerline.segments.shell.last_pipe_status",
				"priority": 10
			},
			{
				"function": "powerline.segments.common.vcs.branch",
				"priority": 40
			}
		]
	}
}

 

virt-manager/libvirt: Installation nicht möglich: virtlogd-sock

Beim Erstellen einer neuen VM über virt-manager erhielt ich heute folgende Meldung:

Installation konnte nicht fertiggestellt werden: «Socket-Erstellung zu '/var/run/libvirt/virtlogd-sock' fehlgeschlagen: Datei oder Verzeichnis nicht gefunden»

Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/create.py", line 2288, in _do_async_install
guest.start_install(meter=meter)
File "/usr/share/virt-manager/virtinst/guest.py", line 461, in start_install
doboot, transient)
File "/usr/share/virt-manager/virtinst/guest.py", line 396, in _create_guest
self.domain = self.conn.createXML(install_xml or final_xml, 0)
File "/usr/lib/python2.7/site-packages/libvirt.py", line 3777, in createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: Socket-Erstellung zu '/var/run/libvirt/virtlogd-sock' fehlgeschlagen: Datei oder Verzeichnis nicht gefunden

Ursache ist das Logging, welches in einen eigenen Dienst ausgelagert wurde. Neben libvirtd muss nun auch virtlogd vor dem Start der VM geladen werden. Für systemd-Nutzer heißt das also…

systemctl start virtlogd
systemctl enable virtlogd

 

Gentoo: Pakete von Distcc/pump ausnehmen

Verteiltes Kompilieren mit distcc und pump macht vor allem auf langsamen Systemen eine Menge Sinn. Leider vertragen nicht alle Pakete diese Lastverteilung, so z.B. mysql/mariadb. Um einzelne Pakete von distcc oder pump auszunehmen geht man wie folgt vor:

Folgende Dateien erstellen:

FEATURES="${FEATURES} -distcc -distcc-pump"
FEATURES="${FEATURES} -distcc-pump"

Nun ggf. den Ordner /etc/portage/package.env anlegen und dort – analog zu package.use/package.keywords/… – dateien für die Pakete anlegen, z.B.

dev-db/mariadb no-distcc-pump.conf

So wird z.B. für MariaDB der Pump-Modus abgeschaltet, distcc bleibt jedoch aktiv. Alternativ kann die ebenfalls erstellte no-distcc.conf verwendet werden um das verteilte Kompilieren komplett zu unterbinden.

Synergy 1.7.6 (Pro) unter Gentoo nutzen

Synerwas?

Synergy ist eine Software um eine Tastatus/Maus-Kombination mit mehreren Rechnern nutzen zu können. Bewegt man z.B. die Maus am Haput-PC an den rechten Bildschirmrand steuert man fortan den danebenstehenden Laptop. Sehr praktisch, wenn man viele Systeme nebeneinander stehen hat. Alles konfigurierbar, versteht sich.

Leider hat die Software einen faden Beigeschmack: Zwar ist der Kern Open Source (GPL), wird vom Hersteller aber nur noch gegen Geld zum Download angeboten. Neue Funktionen sind ebenfalls nur noch mit DRM-online-Aktivierung verfügbar und während die Anpassung an neue Betriebssysteme soweit zügig von statten geht ist die Stabilität in meinen Augen eher auf dem absteigenden Ast.

Wie auch immer: Ich komme nicht drumrum. An einem Arbeitsplatz stehen 4 Rechner nebeneinander und ich habe keinen Nerv ständig die Tastaturen zu wechseln. Da ich dank einer Spende aus Full-Open-Source-Zeiten einen Zugang zu den Downloads habe und meine bisherige Version mit Windows 10 und Server 2016 einige Probleme hat heißt es Aktualisieren.

TLS? Proxy? WTF?

Also rauf auf die Webseite, Login-Formular ausgefüllt und … man landet auf einer HTTP-Seite. Auf der das Login-Cookie unverschlüsselt durch die Gegend geht. Great.

Weiter mit dem Windows-Setup. Installieren, aktivieren. Immerhin: Bei der Aktivierung wird offenbar die OS-API verwendet und der Request augenscheinlich per TLS mit OCSP-Abfrage über den Systemproxy übermittelt. Beim anschließenden Download der Plugins ist dann jedoch Schluss: Direktes CONNECT ohne Möglichkeit einen Proxy einzustellen. Ohne direkten Internetzugriff am Rechner also nicht viel Möglichkeiten.

Konfigurationsterror

Die Konfiguration gestaltet sich mühselig, da Dienst und GUI ständig abstürzten. Letztendlich griff ich auf den Texteditor für die Konfigurationsdatei zurück. Das ging in der Vorversion rigendwie besser. Immerhin: Im Betrieb scheint es bisher stabil zu funktionieren.

Linux? Eat my binary!

Etwas mehr Probleme hatte ich jedoch mit Linux: Im Konstrukt ist ein Gentoo-Rechner, welcher ebenfalls gesteuert werden soll. Die aktuelle Version ist dank GPL über Portage verfügbar und schnell kompiliert und installiert. Nach Eingabe meiner Zugangsdaten verwandelt sie sich nach kurzem Plugin-Download zur Pro-Version. Immerhin. Nur Verbinden geht nicht.

Auslöser ist die Pro-Version: Diese kann – im Gegensatz zum OSS-Kern – eine Verschlüsselte Verbindung zwischen den beteiligten Rechnern nutzen, sodass nicht jeder Netznutzer alle Tastenanschläge mitlesen kann. Dieses Pro-Feature ist jedoch nicht in den Quellcodes vorhanden sondern wird als „Plugin“ bei der Installation heruntergeladen und in ~/.synergy/plugins/ deponiert. Plugin heißt hierbei .so-Library. In Binär. Natürlich gelinkt gegen Bibliotheken bzw. Dateinamen, die ich nicht habe.

Konkret geht es um folgende Liste:

  • linux-vdso.so.1
  • libpthread.so.0
  • libcurl.so.4
  • libSM.so.6
  • libICE.so.6
  • libXtst.so.6
  • libX11.so.6
  • libXext.so.6
  • libXinerama.so.1
  • libXrandr.so.2
  • libXi.so.6
  • libssl.so.10
  • libcrypto.so.10
  • libdl.so.2
  • libstdc++.so.6
  • libm.so.6
  • libgcc_s.so.1
  • libc.so.6
  • libidn.so.11
  • libldap-2.4.so.2
  • liblber-2.4.so.2
  • libresolv.so.2
  • libgnutls.so.28
  • libgcrypt.so.20
  • libz.so.1
  • libuuid.so.1
  • libxcb.so.1
  • libXrender.so.1
  • libtasn1.so.6
  • libnettle.so.6
  • libhogweed.so.4
  • libgmp.so.10
  • libgpg-error.so.0
  • libXau.so.6
  • libXdmcp.so.6

Die Libraries selbst sollten auf einem Desktop-System meist vorhanden sein, nachinstallieren musste ich jedenfalls bei mir nichts. Problematisch waren jedoch libssl.so.10 und libcrypto.so.10 – diese sind unter Gentoo nicht verfügbar und dürften sich auf OpenSSL mit einer Version >= 1.0 beziehen. Die Dateibenennung scheint dabei von Debian(?) zu stammen und wird bei Gentoo anders durchgeführt. Da hierdurch das Plugin nicht lädt wird es ignoriert und die Verbindung zu dem bereits eingerichteten Windows-Clients schlägt, wegen der fehlenden Cryptofunktion, fehl. Zwar erscheint dies auch im Synergy-Log, versteckt sich aber zwischen den ganzen Connect-Nachrichten und ist schnell zu übersehen:

ERROR: failed to load plugin 'libns.so', error: libcrypto.so.10: cannot open shared object file: No such file or directory

Als Quick’n’Dirty-Workarround habe ich bei mir die angemeckerten Dateinamen als Symlink auf die echten OpenSSL-Files angelegt.

cat /usr/lib64/
ln -s libssl.so.1.0.0 libssl.so.10
ln -s libcrypto.so.1.0.0 libcrypto.so.10

Zumindest für’s erste ist hiermit das Plugin funktionsfähig und die Software wieder nutzbar. Sonderlich schön ist es trotzdem nicht.

Veeam B&R: „Auf das verworfene Objekt kann nicht zugegriffen werden. Objektname: System.Net.Sockets.Socket“

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.

QEMU: Festplatten als SATA/AHCI einbinden

Physikalische Remote-Server aufsetzen macht ohne KVM-IP eher wenig Spaß. Groß ist die Gefahr, dass durch Kernel-Updates oder spielen am Bootloader die Kiste nach einem Reboot nicht mehr bootet. Wäre es nicht praktisch, wenn man die Platten nicht kurz in eine VM werfen und da booten könnte?

QEMU ist – spätestens mit KVM – sicher der schnellste Weg, das übliche -hda bindet die Festplatten jedoch als IDE-Geräte ein. Schlecht, wenn man nur AHCI, also SATA, in fstab, Treibern & Co vorgesehen hat.

Abhilfe schaffen folgende Parameter, welche mir bei Rubénerd über den Weg gelaufen sind:

[..]
-drive file=/dev/sda,if=none,id=Disk1 \
-device ich9-ahci,id=ahci \
-device ide-drive,drive=Disk1,bus=ahci.0 \
[..]

Wichtig: Hierbei sollte das System im Haupt-OS nicht eingehangen oder Read-Only sein. Sowas ist üblicherweise nur mit einem Rettungssystem möglich, andernfalls kann es zu Dateisystemschäden kommen. Alternativ könnte confinedrv helfen eine Testumgebung zu schaffen.