Linux

Dynamisches Bash dialog Menü

Leave a Comment

Auf Arbeit muss ich eine kleine GUI, die mit dialog geschrieben ist, anpassen, über welche Kunden ggf. ein paar kleine Einstellungen tätigen können. Im Fall Netzwerkinterface konfigurieren, kam mir heute in den Sinn, dass es ja durchaus sein kann, das es mehrere Interface, gleichen Typs, also z.B. 2x WLAN, geben kann und ich das auch gern berücksichtigen würde. Wenn also mehr als zwei Interface auftauchen, soll ein entsprechendes Menü in dialog generiert werden, was ich wie folgt gelöst hab:

TPATH=$(mktemp -d)
aintf=$(cat /proc/net/dev | grep ^\s*wl.*:.*$ | awk -F":" '{printf"%s ", $1}')

if [ "$(echo $aintf | wc -w)" -gt "1" ]; then
        c=1
        for i in $aintf; do
                list_opt=("${list_opt[@]}" "$i" "Interface$c")
                c=$[c+1]
        done
        diacmd=(dialog --menu "Interface" 15 60 10)
        cmd=`echo "${diacmd[@]}" "${list_opt[@]}"`
        $cmd 2> $TPATH/dialog.tmp
        interf=`cat $TPATH/dialog.tmp`
else
        interf=${aintf[0]}
fi

zabbix-check-mdadm2: mdadm Monitoring für Zabbix

Leave a Comment

Ich habe die Tage mal mein altes mdadm Skript angeschaut, was so mein erster Bash Skript Gehversuch war, und gedacht das ich das mal schöner machen kann. In der Vergangenheit hat auch Christoph bereits ein Check dafür geschrieben, welcher recht simpel gehalten ist und auch ohne root Rechte auskommt. Deshalb hat meines auch die 2 hinten dran hängen.

Das Skript habe ich diesmal in Python geschrieben um ein bisschen zu üben. Es liest einmal /proc/mdstat oder den State von mdadm –detail aus. Für zweiteres sind auch die Root Rechte von nöten. Da hier mehrer States gleichzeitig angezeigt werden können, geb ich nur den schlimmsten aus. Steht also bei 

State : clean, recovering

wird recovering ausgegeben.
Aufgerufen werden kann es wie folgt:

zabbix_check_mdadm2_get.py md0 mdstat
zabbix_check_mdadm2_get.py md0 state

Außerdem habe ich daraus wieder ein Paket gebaut, welches dann demnächst wieder in Christoph’s Repository zu finden sein wird. In diesem ist auch ein entsprechendes Discovery Skript enthalten, welches nach md Devices sucht und diese im JSON Format ausgibt, damit das Zabbix Frontend daraus die Items generieren kann. Das Template liegt wie immer unter share/doc im Paket.

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

mdadm Test RAID mit loop Devices

5 Comments

Ich brauchte heute mal schnell eine mdadm Testumgebung und da ich kein physisches Testgerät da hatte und ich auf keinem Produktivssystem rumspielen wollte, dachte ich mir, das muss doch auch anders gehen, z.B. mit loop Devices:

Je nachdem mit welchem RAID Level man rumspielen will, legt man sich eine entsprechende Anzahl an Files an:

dd bs=1M count=200 if=/dev/zero of=dev1
dd bs=1M count=200 if=/dev/zero of=dev2
dd bs=1M count=200 if=/dev/zero of=dev3

Ich lege mir hier also 3 Files á 200MB an. Nun verknüpft man diese Files mit einem loop Device:

losetup /dev/loop1 dev1
losetup /dev/loop2 dev2
losetup /dev/loop3 dev3

Zu guter letzte noch das RAID Device erstellen, in meinem Fall ein Raid5:

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/loop1 /dev/loop2 /dev/loop3

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