Schlagwort-Archive: Gentoo

[Gentoo] Slot-Conflice durch Perl-Updates

Schon etwas älter, aber ab und zu stoße ich trotzdem drauf: Durch Perl kommt es bei Updates zu einem Slot-Conflice / Blocked Packages. Die Lösung wird z.T. gleich mitgeliefert:


* Remove all perl-core packages from your world file
* emerge --deselect --ask $(qlist -IC 'perl-core/*')
* Update all the installed Perl virtuals
* emerge -uD1a $(qlist -IC 'virtual/perl-*')
* Afterwards re-run perl-cleaner
perl-cleaner --reallyall

CURL & OpenSSL – Zertifikatsfehler

In den letzten Tagen hatte ich einige seltsame Ergebnisse bei CURL – einige URLs wurden wegen eines fehlerhaften Zertifikatsunterschrift abgelehnt:

Cannot connect to URL : Peer certificate cannot be authenticated with known CA certificates: SSL certificate problem, verify that the CA cert is OK. Details:
[…]routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Seltsamerweise ist manuell sowohl Zertifikat als auch CA fehlerfrei, letztere ist auch in /etc/ssl/certs/ korrekt hinterlegt. Laut diversen Posts handelt es sich wohl um einen Fehler in OpenSSL – um vorerst Ruhe zu bekommen habe ich curl nun unter Gentoo mit CURL_SSL=”gnutls” oder CURL_SSL=”polarssl” installiert und bisher keine Probleme mehr. Für Ubuntu wäre libcurl4-gnutls-dev der richtige Startpunkt.

VsFTPd 3.x und 64Bit-Server

Bein Aufsetzen eines FTP-Servers mittels VsFTPd kam es zu einem etwas anderen Problem: Der Server startete, beim Connect erhielt der Client jedoch lediglich die Meldung “500 OOPS: child died”. Im Log selbst war keine Meldung auffindbar.

Auslöser ist offenbar ein zu strikter Sicherheitsfilter in Verbindung mit 64Bit-Kerneln. Gentoo scheint nicht betroffen zu sein, dort lief die Version 3.0.2 fehlerfrei, selbige unter Arch Linux verursacht den Fehler. Als Workarround kann man die neuen Sicherheitsfunktionen durch setzen des Wertes “seccomp_sandbox=NO” in der vsftpd.conf abschalten.

Gentoo: Abbruch beim Update auf Qemu 2.x bei Nutzung von libvirt

Das letzte world-Update eines Gentoo-Servers war etwas aufwändiger als üblich: Die betroffene Kiste kümmert sich unter anderem per libvirt und qemu um Virtualisierung, letzteres sollte mit dem Update von einer 1.5.x-Version auf eine 2.x aktualisiert werden. Mit der neuen Qemu-Version haben sich jedoch einige wichtige Dinge geändert, so gibt es nun keine zentrale Datei zum Start von VMs mehr. Auch die KVM-Unterstützung ist nicht länger als eigener Wrapper vonhanden. Statt einem bösen Erwachen fängt glücklicherweise das Update – bei Verwendung von Libvirt – eine veraltete Konfiguration ab und führt zu einer Fehlermeldung:

* The kvm/qemu-kvm wrappers no longer exist, but your libvirt
* instances are still pointing to it. Please update your
* configs in /etc/libvirt/qemu/ to use the -enable-kvm flag
* and the right system binary (e.g. qemu-system-x86_64).
* ERROR: app-emulation/qemu-2.0.0::gentoo failed (pretend phase):
* update your virt configs to not use qemu-kvm
*
* Call stack:
* ebuild.sh, line 93: Called pkg_pretend
* qemu-2.0.0.ebuild, line 225: Called die
* The specific snippet of code:
* die “update your virt configs to not use qemu-kvm”

Schauen wir mal nach – in /etc/libvirt/qemu liegt für jede VM eine XML-Datei mit allen Einstellungen, unter anderem findet sich in jeder der Dateien ein Eintrag <emulator>/usr/bin/qemu-kvm</emulator>, welcher mit dem “neuen” Pfad des Emulators, also “qemu-system-x86_64” für einen 64Bit-x86-Client, ersetzt werden muss. Die KVM-Erweiterung muss man hierbei nicht beachten, Libvirt gibt die nötigen Argumente zum aktivieren des Virtualisierungsmodus automatisch mit. Also Texteditor auf und ran ans Editieren, richtig? Nunja, das geht bei 2 oder 3 VMs, ich hab da aber ein paar mehr, also muss folgender Einzeiler herhalten:

for i in /etc/libvirt/qemu/*.xml ;do mv "$i" "$i.backup" && sed 's/\/usr\/bin\/qemu-kvm/\/usr\/bin\/qemu-system-x86_64/' "$i.backup" > "$i" ;done

Hinweis: Der Einzeiler lässt die Originaldateien als Backup zurück – wenn alles funktioniert hat können die Dateien mit der Endung *.backup entfernt werden.

Nachdem die XML-Dateien angepasst wurden lässt sich das Qemu-Update wie gewohnt installieren.

Gentoo: Linker-Fehler bei alten Paketen mit neuer GLibc

Möchte man alte Pakete auf einem System mit neuerer GLibc nutzen kommt es u.U. beim Linknen zu kleineren Verstimmungen:

/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: note: 'floor@@GLIBC_2.2.5' is defined in DSO /lib64/libm.so.6 so try adding it to the linker command line 
/lib64/libm.so.6: could not read symbols: Invalid operation 
collect2: error: ld returned 1 exit status

Als Workarround kann man die nötige Lib über paketspezifische LDFLAGS händisch einbinden:

/etc/portage/enc/templd.conf

LDFLAGS="$LDFLAGS -lm"

/etc/portage/package.env:

bla-foo/bar   templd.conf

Via nlsa8z6zoz7lyih3ap @ Gentoo Forums

Gentoo: tcpdump -w kann keine Dateien schreiben / Dateien nicht auffindbar

Mit tcpdump kann man sehr einfach auf der Konsole Netzwerkverbindungen mitlesen und so Fehler genauer betrachten. Üblicherweise lässt sich mit der Option “-w datei.pcap” dieser Mitschnitt auch als pcap-Datei speichern, welche beispielsweise mit Wireshark geöffnet und weiter analysiert werden kann.

Unter Gentoo zeigten sich heute 2 seltsame Verhaltensmuster:

Mit absoluten oder relativen Pfaden:


tcpdump -i br0 -w /tmp/test.pcap
tcpdump: /tmp/test.pcap: No such file or directory

Ohne Pfad erscheint keine Fehlermeldung, die Datei wird aber augenscheinlich auch nicht erstellt:


host tmp # tcpdump -i br106 -w test.pcap
tcpdump: WARNING: br106: no IPv4 address assigned
tcpdump: listening on br106, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
14 packets captured
14 packets received by filter
0 packets dropped by kernel
host tmp # ls -l test.pcap
ls: cannot access test.pcap: No such file or directory
host tmp #

Auslöser ist das USE-Flag “chroot” – hierdurch wird der Prozess in ein virtuelles Root gesperrt, sodass Fehler (hoffentlich) nicht zu viel Schaden anrichten können. Alle Pfade beziehen sich auf /var/lib/tcpdump/ – entsprechend sind dort auch die ohne Pfadangabe generierten pcap-Dateien zu finden.

Gentoo: You’re missing a /dev/fd symlink to /proc/self/fd.

Hui, ich dachte der wäre schon mal da gewesen, aber hey… Während eines Updates verabschiedete sich Portage mit folgender Meldung:

Gentoo: You're missing a /dev/fd symlink to /proc/self/fd.

Auslöser ist, dass das udev-initscript, zumindest auf meinem hardened-System, nicht bei Systemstart ausgeführt wird. Ein kurzes

rc-update add udev sysinit
/etc/init.d/udev start

[Source]

sollte das Problem beheben.

Gentoo-Upgrade: XML::Parser perl module is required for intltool

Uff… Updates schleifen lassen ist bei Rolling-Release-Distros ja immer ein Problem. Heute im Angebot: Das Gentoo-Upgrade eines Systems, welches etwa 4 Monate stand, verabschiedet sich bei nahezu allen Paketen mit folgender Meldung während “configure”:

XML::Parser perl module is required for intltool

Eine Neuinstallation von Perl und dem genannten XML-Modul brachte keine Besserung, auch unter @preserved… oder revdep-rebuild zeigte sich nichts passendes. Die Lösung ist einfacher als befürchtet: Der Befehl

perl-cleaner --reallyall

sucht alle betroffenen Pakete, welche noch Verweise auf ein altes Perl enthalten, und baut sie über portage neu. Bei mir kam es noch zu einer Kollision durch veraltete glib und qt-Pakete, da der emerge-Befehl aber bereits fertig zum kopieren bereitstand war die nötige Ergänzung kein wirkliches Problem – knapp 190 Pakete später funktioniert’s dann auch wieder mit dem Update.

Hinweis zum Gentoo-Update auf www-apps/owncloud-5.0.12

Kurzer Hinweis zu letzten Owncloud-Update unter Gentoo: Durch eine nicht ganz performante Funktion scheint das ebuild in der Install-Phase zu hängen. Auf einem Atom-System dauerte es 2 Stunden bis Portage den Vorgang abschließen konnte, auf einem i7 mit RAID 15 Minuten, also nicht ungeduldig werden und nach Anstoßen des Updates doch erst mal eine (Familien)Pizza essen gehen. Der Installationsvorgang kann mit lsof auf den Temp-Ordner (/var/tmp/portage/) beobachtet werden.

top: write error

Nutzt man unter Linux “top” kombiniert mit einer Pipe kommt es in einigen Fällen derzeit zu einem Fehler, z.B.

top -bn1 | head -n 10
top: write error

Schuld ist offenbar ein Bug in einer top-Version. Der Fehler tritt auf wenn die Pipe vor top beendet wird, also z.B. bei “head” – in diesem Fall erhält top ein SIGPIPE und wirft die Meldung. Betroffen ist 3.3.6 (Gentoo) und einige 3.3.7 (Fedora). Unter Fedora sollte >=3.3.7-6.fc19 aus Stable Abhilfe schaffen, unter Gentoo ist der Fehler auch in der aktuellen Testing (3.3.8) vorhanden, hier muss manuell der zugehörige 1-Zeilen-Patch aus dem Upstream eingespielt werden. Gentoo-Bug mit genauerer Beschreibung existiert jetzt, ich vermute mal der Einzeiler sollte es recht schnell schaffen.

—Update—

Status: CONFIRMED -> RESOLVED
Resolution: FIXED

*procps-3.3.8-r1 (25 Oct 2013)

25 Oct 2013; Lars Wendler +procps-3.3.8-r1.ebuild:
Fixed write error when using top with pipes. Thanks to Florian Knodt for reporting this in bug #485952.