Schlagwort-Archive: Linux

PC-Kram

Linux: Optisches Laufwerk RAW über Netzwerk einbinden

Schreibe einen Kommentar

(Hinweis: Der Artikel lag schon etwas rum – möglicherweise sind die verwendeten Tools nicht mehr aktuell)

Hmmm – ungünstig. Das einzige optische Laufwerk steckt in einem Linux-Server, ich möchte die Discs jedoch auf einem anderen Gerät verwenden. Üblicherweise reicht hier ein File-Share wie Samba, NFS o.Ä. aus, wenn man jedoch beispielsweise kopiergeschützte DVDs abspielen möchte ist eine solche Freigabe nicht ausreichend. Glücklicherweise können wir hier einen alten Bekannten bemühen: iSCSI. Dies hatten wie bereits für Festplatten besprochen, kann aber auch für optische Laufwerke genutzt werden.

Server / Target

Nach dem Aufruf von targetcli sollten wir die altbekannte Textkonsole erhalten, welche auf der Root (/) der Konfiguration startet. Im ersten Schritt registrieren wir das physikalische Laufwerk /dev/sr0 als Backstore und aktivieren es für iSCSI. Sofern nicht bereits vorhanden wird automatisch eine TPG erzeugt.

/> cd backstores/pscsi
/backstores/pscsi> create name=cdrom_backend dev=/dev/sr0
Note: block backstore recommended for SCSI block devices
Created pscsi storage object cdrom_backend using /dev/sr0
/backstores/pscsi> cd cdrom_backend
/backstores/p...cdrom_backend> /iscsi create
Created target iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.3299e9a7999b.
Created TPG 1.
Global pref auto_add_default_portal=true
Created default portal listening on all IPs (0.0.0.0), port 3260.

Nun müssen wir noch eine LUN erstellen um Clients den Zugriff zum Gerät zu ermöglichen. Diese Konfiguration findet im Kontext der TPG statt, die nötige ID wurde ja weiter oben angezeigt. Da nur ein Backstore verfügbar ist wird dieser automatisch ausgewählt. Da es sich um ein Testnetz handelt verzichte ich auf eine Absicherung und alle alle Clients zu – bei CD-Laufwerken ein überschaubares Risiko.

/backstores/p...cdrom_backend> cd /iscsi/iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.3299e9a7999b/tpg1/
/iscsi/iqn.20...e8a7999b/tpg1> cd luns
/iscsi/iqn.20...99b/tpg1/luns> create /backstores/pscsi/cdrom_backend
Created LUN 0.
/iscsi/iqn.20...99b/tpg1/luns> cd ..
/iscsi/iqn.20...e8a7999b/tpg1> set attribute authentication=0 demo_mode_write_protect=0 generate_node_acls=1 cache_dynamic_acls=1
Parameter cache_dynamic_acls is now '1'.
Parameter authentication is now '0'.
Parameter generate_node_acls is now '1'.
Parameter demo_mode_write_protect is now '0'.
/iscsi/iqn.20...e8a7999b/tpg1>

Zuletzt wird die Konfiguration gespeichert, so ist sie z.B. auch nach einem Neustart noch vorhanden

/iscsi/iqn.20...e8a7999b/tpg1> cd /
/> saveconfig
Last 10 configs saved in /etc/target/backup.
Configuration saved to /etc/target/saveconfig.json
/> exit
Global pref auto_save_on_exit=true
Last 10 configs saved in /etc/target/backup.
Configuration saved to /etc/target/saveconfig.json

Client / Initiator

Auf der Clientseite benötigen wir ebenfalls eine Userspace-Software. Ich nutze zur Konfiguration iscsiadm aus dem Paket open-iscsi. Hier wird erst über Discover geprüft welche LUNs auf der TPG/Ziel-IP verfügbar sind. Über Login werden diese dann verbunden.

# iscsiadm --mode discoverydb --type sendtargets --portal 10.11.12.13 --discover
10.11.12.13:3260,1 iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.3299e9a7999b
# iscsiadm --mode node --login
Logging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.3299e9a7999b, portal: 10.11.12.13,3260] (multiple)
Login to [iface: default, target: iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.3299e9a7999b, portal: 10.11.12.13,3260] successful.

Das Ergebnis ist ein zusätzliches Blockdevice, welches wie ein Lokales angesteuert werden kann.

# dmesg | tail
[269195.457603] Loading iSCSI transport class v2.0-870.
[269196.464444] iscsi: registered transport (tcp)
[269243.373172] scsi host5: iSCSI Initiator over TCP/IP
[269243.636444] scsi 5:0:0:0: CD-ROM TSSTcorp DVD+-RW TS-H653B D300 PQ: 0 ANSI: 5
[269243.668795] sr 5:0:0:0: [sr1] scsi-1 drive
[269243.669219] sr 5:0:0:0: Attached scsi CD-ROM sr1

 

PC-Kram

BTRFS: Dateisystem mit mehreren Festplatten vergrößern

Schreibe einen Kommentar

Das ist jetzt doof – Platte voll. Und das auf einem Multi-Device/RAID BTRFS-System. Die unterliegenden LUNs zu vergrößern ist kein wirkliches Problem, aber btrfs zeigte sich etwas widerspenstig: Die meisten Anleitungen empfehlen folgendes:
btrfs filesystem resize max /mnt/data

Leider scheint es bei multi-device keine reaktion zu geben. Der Trick: Dieser Befehl lässt nur die erste Festplatte wachsen. Hat man mehrere muss man den Befehl für jede LUN separat ausführen, die Plattennummer wird dabei als ID mitgegeben:
btrfs filesystem resize 2:max /mnt/data

Die IDs aller beteiligten Platten kann man mit

btrfs filesystem show /mnt/data
anzeigen. Wurden alle Platten vergrößert kann man natürlich auch eine bash-Schleife bemühen um den Befehl für alle abzusetzen.
for i in {1..8} ;do btrfs filesystem resize $i:max /mnt/data/ ;done

Restmüll, Software

Linux: Gerät wacht nach Suspend sofort wieder auf

Ein Kommentar

Narf. Akku leer. Nur warum?
Tja, mein Laptop hatte sich entschieden nach meinem Klick auf „Suspend“ sofort wieder aus dem Standby-Modus aufzuwachen. Reproduzierbar. Erste Vermutung: Die GUI ist Schuld. Wie immer. Aber auch ein systemctl suspend zeigt nicht wirklich eine Besserung. Auch die Logs zeigen nichts verwertbares. Na dann graben wir etwas tiefer:

Erst mal zur Klarstellung: Standby funktioniert – der Laptop schaltet die Geräte aus, die Power-LED blinkt wie erwartet, doch nach knapp einer Sekunde wacht wer direkt wieder auf. Entsprechend des Fehlers dürfte also die Aufwachquelle am ehesten Verantwortlich sein. Eine Liste aller Quellen findet sich in /proc/acpi/wakeup:

# cat /proc/acpi/wakeup
LID	  S4	*enabled  platform:PNP0C0D:00
SLPB	  S3	*enabled   platform:PNP0C0E:00
IGBE	  S4	*enabled   pci:0000:00:19.0
EXP2	  S4	*disabled  pci:0000:00:1c.1
XHCI	  S3	*enabled   pci:0000:00:14.0
EHC1	  S3	*enabled   pci:0000:00:1d.0

Die Liste sieht natürlich je nach Verbauter Hardware anders aus, hier die Zuordnung meines Gerätes: 

LID -> Laptop-Deckel
SLPB/SBTN -> Standby-Button
IGBE -> Integrated Gigabit Ethernet
EXP2 -> ??
XHCI -> USB3
EHC1 -> USB(1/2)

Wie wir sehen können diverse Geräte ein Aufwachen verursachen, lediglich EXP2 ist nicht aktiv. Um das Ganze einzugrenzen heißt es also nun: Aufwachquelle abschalten, Suspend testen und hoffen, dass es was bringt. Über ein gezieltes echo kann der Zustand zwischen enabled und disabled gewechselt werden:

echo LID > /proc/acpi/wakeup

In meinem Fall stellte sich USB als Fehlerteufel heraus. Offenbar störte sich das System an einem USB-Stick – egal ob gemountet oder nicht. Wie auch immer, USB brauche ich ohnehin nicht zum aufwachen, Deckel und/oder Power-Button sollten ausreichen. Den „bösen“ USB schalte ich beim Boot per Script nun ab.

Software

[Gentoo] Apache 2.4.26 + WordPress: Invalid post type

4 Kommentare

Hmk? After the latest system updates on Gentoo I noticed WordPress was no longer able to open any kind of post list („invalid post type“), edit posts (you do not have access to this kind of post) or create posts (form shown, but right sidebar missing). Not quite uncommon, but this time it was no broken plugin – I could reproduce the same behavior with several other WordPress instances with different versions – even a fresh install. That’s a new one.

After some probing around I’m fairly certain Apache 2.4.26 is the culprit, after downgrading to 2.4.25 the problem disappeared. All other downgrades like PHP 7.0.15 instead of PHP 7.0.19 didn’t show any effect. I yet have to confirm which combination ultimately triggers the error (FPM? Event-MPM?), but if you have similar errors: Here is your starting point…

BitNotice

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

Schreibe einen Kommentar
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

Software

ZFS/ZOL: Pool UNAVAIL nach Reboot

Schreibe einen Kommentar

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.

Software

STDOUT verdoppeln mit ftee

Schreibe einen Kommentar

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.

PC-Kram

rsync vs. curlftpfs: mkstemp-Fehler

Schreibe einen Kommentar

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

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

Schreibe einen Kommentar
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
			}
		]
	}
}

 

Software

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

Schreibe einen Kommentar

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