Die Installation von dev-ruby/ffi-1.9.4, welches als Dep gezogen wurde, machte auf einem Server Probleme. Unter anderem war folgende Meldung zu lesen:
cannot load such file -- rspec/core/rake_task
Woher die Anforderung kam oder warum keine Dep da ist konnte ich nicht direkt sehen, ein manuelles Installieren von dev-ruby/rspec sollte jedoch die nötigen Voraussetzungen schaffen um das Kompilieren zu ermöglichen.
Auf mehreren Servern quittierte das Update von sys-apps/man-db-2.6.6 mit folgender Meldung:
BEGIN failed--compilation aborted at /usr/bin/po4a line 547.
Schuld ist Perl, entsprechend kann das gute, alte perl-cleaner --all Wunder wirken.
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
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.
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.
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.
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
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.
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
sollte das Problem beheben.
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.