IT

LXC Ubuntu Template failed unter Debian

Leave a Comment

Als ich heute unter Debian Ubuntu in einen LXC Container installieren wollte, schlug dies fehl mit folgender Meldung:

I: Keyring file not available at /usr/share/keyrings/ubuntu-archive-keyring.gpg; switching to https mirror https://mirrors.kernel.org/debian
I: Retrieving Release 
E: Failed getting release file https://mirrors.kernel.org/debian/dists/precise/Release

Dazu gibt es auch schon ein entsprechendes Ticket auf Github. Die Lösung ist ganz einfach das Paket ubuntu-archive-keyring zu installieren. Cooler wäre natürlich wenn man entweder direkt darauf hingewiesen wird, oder es in die Abhängigkeiten von LXC aufgenommen wird.

Arch Linux: login incorrect without password prompt

3 Comments

Heute habe ich zum ersten mal mit Arch Linux rummgespielt, da ich kein Lust hatte das riesige Rasbian auf das neue Raspberry Pi 2 der Firma zu spielen. Also SD Karte erstellt, gebootet und nenn Upgrade gemacht mit anschließendem Reboot. Danach konnte ich mich dann nicht mehr einloggen. Das kuriose daran ich kam gar nicht bis zum Passwort. Direkt nach Bestätigung des Users bekam ich Login Incorrect. Da ich so nun gar nicht mehr ins System kam, entschied ich mich nochmal alles neu drauf zu spielen.
Nachdem das geschehen war, ging ich vor wie beim ersten mal, nur ohne reboot. Direkt nach dem Update bekam ich schon auf tty2 den gleichen Fehler. Also mal einen Blick in die syslog schauen. Jaaaaa denkste, ist ja systemd. Also mal eben die journalctl Manpage zu Rate gezogen und einen Blick ins Log geworfen. An dieser Stelle möchte ich mal anmerken das ich es persönlich umständlich finde eine Logdatei nur mit einem Programm lesen zu können, weil sie binär abgelegt wird. Ich weiß zwar wieso es so gemacht wird, aber dennoch… Aber egal, jedenfalls bekam ich so den Grund raus wieso ich mich nicht mehr einloggen konnte:

login[4179]: PAM unable to dlopen(/usr/lib/security/pam_unix.so): libtirpc.so.1: cannot open shared object file: No such file or directory
login[4179]: PAM adding faulty module: /usr/lib/security/pam_unix.so
login[4179]: PAM unable to dlopen(/usr/lib/security/pam_access.so): libtirpc.so.1: cannot open shared object file: No such file or directory
login[4179]: PAM adding faulty module: /usr/lib/security/pam_access.so
login[4179]: FAILED LOGIN SESSION FROM tty2 FOR root, Module is unknown

libtirpc.so.1 ist also nicht mehr vorhanden. Die Library wurde auch im Update aktualisiert und zwar von Version 0.3.2-2 auf 1.0.1-2. Mit 

pacman -Ql libtirpc

lies ich mir dann mal die Dateien des Pakets anzeigen und siehe da, der Filename hat sich in libtirpc.so.3 geändert. Also erster Versuch, erstmal einen Symlink setzen:

cd /usr/lib/
ln -s libtirpc.so.3.0.0 libtirpc.so.1

und siehe da, man kann sich wieder einloggen.

zabbix-check-ksm: Kernel Samepage Merging

Leave a Comment

Kernel Samepage Merging (KSM) erlaubt eine Deduplizierung des Memory unter Linux und wurde mit der Kernel Version 2.6.32 eingeführt. KSM versucht gleiche Memory Pages zu erkennen und diese zusammenzuführen um den doppelt belegten Memory freizugeben. Ursprünglich für Virtualisierung vorgesehen kann es nun auch von allen Programmen genutzt werden, die viele Instanzen mit gleichen Daten erzeugen.
Die Werte dazu kann man schön unter /sys/kernel/mm/ksm/ abfragen und in Zabbix integrieren. Bei Hostsystemen mit vielen Gästen ist es sicher interessant sich das mal in Form von Graphen im Frontend anzuschauen. Die Werte sind die folgenden:

pages_to_scan Zu scannende Shared pages
sleep_millisecs Zeit bis zum nächsten Scan
run 0 = stop ksmd, 1 = start/running ksmd, 2 = stop ksmd und unmerge
pages_shared how many shared pages are being used
pages_sharing how many more sites are sharing them i.e. how much saved
pages_unshared how many pages unique but repeatedly checked for merging
pages_volatile how many pages changing too fast to be placed in a tree
full_scans how many times all mergeable areas have been scanned

Dazu hab ich kleines Paket gebaut, was im Grund eigentlich nur aus einem Einzeiler besteht. Zu finden unter:

Sourcecode: Github
Repository: repository.chr.istoph.de

Default Kompressionsalgorithmus von debuild ändern

Leave a Comment

Auf Arbeit laufen große Teile der Clients noch auf Ubuntu 12.04 Precise, weshalb ich dafür natürlich auch meist Pakete dafür baute. Gestern habe ich ein paar Pakete für 14.04 Trusty bauen müssen und hab dabei fast die Kriese bekommen. Das bauen an sich machte keine Probleme, allerdings unser Repository, welches schon etwas in die Jahre gekommen ist. Ich bekam nun bei erstellen des Repository’s jedes mal 

E: This is not a valid DEB archive, it has no 'data.tar.gz', 'data.tar.bz2' or 'data.tar.lzma' member
E: Errors apply to file '/var/www/linux/dists/gpl-trusty/main/binary-i386/libmd5-perl_2.03-1_all.deb'

Wenn ich mir das nun auf unserem Repository das Paket anschaute meldete der auch das damit etwas nicht stimmt. Gut hier ist es wieder meine eigene Schuld, denn ich las die Fehlermeldung nicht richtig, welche wie folgt lautete:

dpkg-deb: file `/root/gpl-trusty/main/libmd5-perl_2.03-1_all.deb' contains ununderstood data member data.tar.xz, giving up

Hätte ich mir diese und die vorhergehende Meldung mal direkt genauer angeschaut, hätte ich auch gesehen das er einfach mit dem Kompressionsalgorithmus XZ nicht klar kommt. Also Fazit, unter Trusty wurde der Default Kompressionsalgorithmus auf XZ gestellt, womit alte Systeme ein Problem haben. Nun muss ich also debuild beibringen das er wieder gzip als Default zu benutzen hat, was ich wie folgt getan habe:

  • Die Datei /usr/local/bin/dpkg-deb, mit folgendem Inhalt, erstellen
    • #!/bin/bash
/usr/bin/dpkg-deb -Zgzip $@
  • Folgendes noch in der .bashrc hinzufügen, da es in meinem Fall dauerhaft sein soll
    • alias debuild="debuild --preserve-envvar PATH"

    Anschließend nutzt dann debuild auch gzip und alles funktioniert. Es gibt auch noch andere Varianten debuild dazu zu bewegen gzip zu nutzen, wie beispielsweise die Datei debian/source/options mit folgendem Inhalt anzulegen:

    compression = "gzip"

    Dies ignorierte aber debuild bei mir komplett.

    Quelle: http://comments.gmane.org/gmane.linux.debian.devel.devscripts/9977

    PS: Dank geht auch wieder an meinen Kollegen, der mir bei der Aufklärung behilflich war.

    Diskfilter writes are not supported

    2 Comments

    Auf Servern mit Ubuntu 14.04 bekomme ich beim booten schon immer folgenden Fehler angezeigt:

    error:  Diskfilter writes are not supported

    Dies ist ein Bug, der Auftritt wenn man die Root, oder wenn einzeln die Boot Partition, in einem RAID oder LVM anlegt. Ein sehr gute ausführliche Beschreibung, warum der Bug auftritt gibt es in diesem Forumbeitrag: Beitrag bei askbuntu.com Da dieser alles ziemlich gut erklärt, werde ich das jetzt nicht nochmal niederschreiben, sondern nur die Lösung:

  • Download der gepatchten GRUB Header Datei
    • wget https://gist.githubusercontent.com/rarylson/da6b77ad6edde25529b2/raw/99f266a10e663e1829efc25eca6eddb9412c6fdc/00_header_patched
  • Sichern der Originaldatei und verschieben der neuen
    • mv /etc/grub.d/00_header /etc/grub.d/00_header.orig
mv 00_header_patched /etc/grub.d/00_header
  • Altes Script deaktivieren und neues aktivieren
    • chmod -x /etc/grub.d/00_header.orig
chmod +x /etc/grub.d/00_header
  • GRUB updaten
    • update-grub

    Wie man in dem Beitrag auch lesen kann ist das ab 15.04 gefixt. Warum sie den Patch nicht in 14.04 einfließen lassen, versteh ich nicht.

    Move LV’s von einem Device auf ein anderes

    Leave a Comment

    Ich habe auf Arbeit ein Storage worin 3 RAID’s sind. Ein RAID1, welches für diesen Artikel irrelevant ist, ein RAID6 (md1) worauf iSCSI Volumes in Form von LV’s liegen und ein RAID5 (md2) welches zum Testen da ist. Das RAID6 besteht dabei aus 8 relativ alten Platten, welches nun zu bröckeln anfing und zu allem Übel fing ein Platteneinschub auch noch an CRC Error zu produzieren, wodurch ein Plattentausch verhindert wurde, da jede sofort wieder aus dem RAID geworfen wurde. Es wurde von mir also kurzer Hand das RAID5 Volume gekapert, da mir die Tests in dem Moment relativ egal waren, und fügte es meiner VG hinzu:

    vgextend vg /dev/md2

    Diese sollte mit einer Erfolgsmeldung quittiert werden. Man kann aber mit pvdisplay nochmal kontrollieren. Um zu sehen auf welchem Volume welches LV liegt benutzt man

    lvs -o +devices

    Moven der LV’s geht dann wie folgt, entweder man tut es mit jeder einzeln:

    pvmove -n test /dev/md1 /dev/md2

    was ich, wie man schon an dem Namen der LV sieht, erstmal nur zum testen tat, oder man verschiebt einmal den gesamten Pool:

    pvmove /dev/md1 /dev/md2

    Das ganze funktionierte während des Betriebs, ohne das die VM’s, zu welchen die LV’s gehören, irgendwas davon merkten. Das ganze dauert natürlich, abhängig von der Größe eine ganze Weile, da die Daten blockweise kopiert werden.
    Sind die Daten dann alle verschoben kann man das kaputte RAID aus der VG entfernen:

    vgreduce vg /dev/md1

    apt-get force IPv4

    3 Comments

    Ich hatte letzte Woche auf Arbeit das Problem, das scheinbar das IPv6 bei einem Kunden kaputt war, weshalb ich kein apt-get update durchführen konnte, da er die IP nicht erreichen konnte. Also musste ich apt-get dazu bewegen doch bitte IPv4 zu nutzen. Ab Version 0.9.7.9~exp1 geht das wie folgt:

    apt-get -o Acquire::ForceIPv4=true update

    Da es sich in diesen Fall aber um ein Precise handelte mit einer älteren apt-get Version muss hier anders vorgegangen werden. Und zwar muss in /etc/gai.conf folgende Zeile einkommentiert werden:

    precedence ::ffff:0:0/96  100

    XFCE4: Lock screen after Lid Switch

    Leave a Comment

    Letzte Woche musste mein mir Jahre lang treues Netbook, ein Asus EeePC R051PX, in den Ruhestand gehen und wurde nun durch ein Lenovo X220 ersetzt. Erster Akt natürlich, Linux installieren – also Debian mit XFCE um genau zu sein.
    Mir fiel jetzt die Tage etwas unangenehm auf, dass nachdem ich den Deckel geschlossen habe das Gerät in Standby geht, beim Aufwachen allerdings der Bildschirm nicht gesperrt ist. Also nochmal alle Einstellungen in der Energieverwaltung angeschaut, alles richtig. Auch der entsprechende Haken unter Sitzung und Startverhalten > Advanced > Bildschirm vor dem Versetzen in den Energiesparmodus sperren war gesetzt. Zusätzlich habe ich die gesetzten Einstellungen nochmal auf der Konsole mit dem Tool xfconf-query überprüft und hier dann auch die Lösung gefunden:
    logind-handle-lid-switch war auf True gesetzt, allerdings ist unter /etc/systemd/logind.conf überhaupt nichts in der Richtung konfiguriert. Also habe ich die Option, wie folgt, auf False gesetzt:

    xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/logind-handle-lid-switch -s false

    Danach funktioniert es so wie es sollte.

    pgAdmin III: Passwort expired nach Bearbeiten von Login Rollen

    Leave a Comment

    Mein Kollege und ich waren heute extrem verwirrt. Er wollte mir einen Benutzer in postgres Datenbank anlegen und tat dies auch. Gleichzeitig änderte er bei sich noch eine der Privilegien, danach stürzte bei ihm pgAdmin ab. Keine Seltenheit, nun kam aber der kuriose, er konnte sich nicht mehr einloggen, Grund: keiner. Dann loggte er sich mit meinem User ein, änderte auch hier ein Privileg und schon konnte ich mir auch nicht mehr einloggen. Beim connecten mal auf SSL require gestellt und nun bekamen wir die Meldung das das Passwort falsch ist. Also Passwort in der Datenbank auf der Console geändert, kein Login möglich. Auf der Console fiel uns dann irgendwann mal auf, das unsere Accounts plötzlich auf „Expired“ gestellt sind. Also das wieder Rückgängig gemacht, und schon ging es wieder.
    Dann änderten wir in pgAdmin nochmal die Privilegien, und siehe da, er stellt sofort beim speichern das Expiry Date auf den heutigen Tag. Grund dafür ist, das sobald die Properties eines Logins geöffnet werden, pgAdmin in dem Reiter Definition das Expiry Date auf den aktuellen Tag setzt, ohne darüber einen Hinweis einzublenden.

    Heißt, wenn ihr mit pgAdmin eine Benutzer bearbeitet, denkt daran das Expiry Date im Reiter Definition zu checken und gegebenfalls zu löschen.

    pgAdmin II Version: 1.18.1
    Ubuntu Version: 14.04

    Laut Changelog auf der pgAdmin Seite wurde das in Version 1.18.2 gefixt, scheinbar aber nur für Mac:
    2013-10-22 DP 1.18.2 Fix the handling of the „Valid Until“ date/time on the
    role dialogue on Mac [Dinesh Kumar].

    Installations-Odyssee Windows Server

    Leave a Comment

    Ich musste heute einen Windows 2008 Server installieren, welcher bei Hetzner gehostet wird. Hier trage ich mal die frustrierendsten Punkte zusammen:

    System Reserved Partition
    Warum zur Hölle will die Windows installieren? Man kann es auch nicht verhindern, man wird nur darauf hingewiesen das es getan wird, klickt man Abbrechen gehts nicht weiter. Installiert doch den Bootloader kram einfach mit in die NTFS, ging doch früher auch…
    Vor allem die Dreistigkeit dieses Installationsmanagers kotzt mich an. Ich partitioniere mit diskpart alles vor, damit der Installationsassi gar keine Möglichkeit hat mir die irgendwohin zu knallen, und was macht das Dreckding, es konvertiert mir einfach die NTFS Partition auf der andere Platte um und belegt damit die gesamte zweite Platte. Gehts noch?

    Partitionen auf dynamischen Datenträgern löschen
    Warum kann man im Installationsassistenten nicht Partitionen von dynamischen Datenträgern löschen. Man kann die Partitionen nur formatieren. Unter Linux kann man sogar die Partitionstabelle neu schreiben, selbst sowas geht nicht. Auch dispart kann das nicht.

    Software RAID im Installationsassistenten
    Warum kann man das nicht während der Installation konfigurieren? Da gäbs sicher nicht solche Probleme, wie das der die Systempartition plötzlich auf die andere Platte haut und du nochmal alles neu machen darfst.

    Treiber nachinstallieren
    Warum muss man bei einem Betriebssystem was stolze 38GB nach der Installation einnimmt noch Treiber nachinstallieren? Linux verbauch wenns hoch kommt 1,5 und ich hatte bisher einmal in 15 Jahren das Problem das da der Netzwerktreiber nach der Installation fehlte.

    Festplattenreihenfolge im Installationsassi anders als im späteren System
    Im Installationsassi wurde mir die zweite Platte als Datenträger 0 angeboten, wo ich dann natürlich auch das System drauf installierte. Nach der Installation wurde die Platte mir dann plötzlich als Datenträger 1 präsentiert. Das wird auch der Grund gewesen sein, wieso der Installtionsassi mir so dreist die gesamte Partition als System Partition formatierte.

    Mir stellt sich die Frage: Was soll der Scheiss? Bei solchen Dingen kann man ja auch nicht mit den üblichen Argumenten kommen: „Windows soll halt einfach sein, viele wollen gar nicht so viel einstellen“. Lass ich bei einem Desktop OS gelten, aber nicht bei einem Server OS.
    Wenn man wenigstens in irgendeiner Weise nachvollziehen könnte, warum dieser Mist fabriziert wird, aber Transparenz ist ja da ein Fremdwort.

    Und so schließe ich mein Windows Bashing, was ich ja echt nicht gern betreibe, da jeder selber wissen muss mit was er gut zurecht kommt, mit dem Zitat meines Kollegen, welcher sich meine Odyssee immer wieder mal kurz anschaute und schließlich mit den Worten „Dieses Betriebssystem gehört nicht auf einen Server!“ in den Feierabend ging.