Month: Oktober 2014

Neue Interfacenamen (eth0 / em1) – biosdevname

1 Comment

Nachdem ich vor ein paar Tagen Ubuntu 14.04.1 installierte stellte ich zu meinem verwundern fest, das meine Netzwerkinterface plötzlich em1 und em2 hießen. Ubuntu nutzt wohl seit 14.04.1 standardmäßig die Kerneloption biosdevname, welche sich die Informationen zum benennen der Interface direkt aus dem BIOS nimmt. Für die Bezeichnung wird dann systemd Naming Schema genutzt.
Ich seh da für mich derzeit allerdings absolut keinen Vorteil oder Mehrwert drin, sondern eher nur Verwirrung. Für mich reicht die Bezeichnung eth völlig aus und es muss für mich jetzt nicht ersichtlich sein ob es sich dabei um ein virtuelles, embedded oder pci Device handelt. Zum Ausschalten des ganzen also folgendes in die /etc/default/grub eintragen:

GRUB_CMDLINE_LINUX_DEFAULT="biosdevname=0"

Nachgelesen habe ich das ganze bei Redhat.

NTFS Partition mounten obwohl Partitionstabelle defekt ist

3 Comments

Auf Arbeit kam mir eine Festplatte unter, worauf relativ wichtige Daten sind. Diese hat allerdings eine defekte Partitionstabelle, was irgendwie das billige USB Dock verursacht haben muss. Jedenfalls war ich da erstmal etwas ratlos wie ich an die Daten kommen sollte, da zeigte mir mein Kollege Dennis wie es in wenigen Schritten möglich ist.

Als erstes muss man raus finden mit welchen HEX Wert der NTFS Bootsektor beginnt. Dies hatten wir hier erstmal in Erfahrung gebracht. Eine NTFS Partition fängt also immer mit „EB 52 90“ an und so konnte man dann auf der Platte mit hexdump danach suchen:

head -n 1000 /dev/sdb | hexdump -C | egrep "eb 52 90"

was, in unserem Fall, folgende Ausgabe ergab:

00006000  eb 52 90 4e 54 46 53 20  20 20 20 00 10 01 00 00  |.R.NTFS    .....|
08005000  eb 52 90 4e 54 46 53 20  20 20 20 00 10 01 00 00  |.R.NTFS    .....|
08100000  eb 52 90 4e 54 46 53 20  20 20 20 00 10 01 00 00  |.R.NTFS    .....|

Es sind also 3 NTFS Partitionen auf der Platte. In dem Fall interessiert uns nur die letzte, denn die erste ist leer und die zweite kaputt. Es scheint sich hier um alte Partitionen zu handeln. Nun muss der HEX String noch in Byte umgewandelt werden:

python -c 'print int("8100000", 16)'

Ausgabe:

135266304

Mit diesem Wert als offset konnte nun die Partition wie folgt gemountet werden:

mount /dev/sdb /mnt -o ro,loop,offset=135266304

Wir haben sie jetzt mal read-only gemountet, nur um sicher zu gehen.

SSH Timeout unterbinden

4 Comments

Auf Arbeit werden die SSH Connections immer nach einer gewissen Zeit getrennt, was unglaublich nervig ist wenn man eigentlich zu 98% auf Linux Servern arbeitet und er einfach inaktive Sessions einfach Timeouted. Gestern war so der Höhepunkt erreicht, nachdem ich mit Thunar via SFTP auf einen Server drauf bin und nachdem die Session getrennt wurde sich Thunar und gvfs komplett weghang. Einfach mal schnell ins Manual von ssh_config geschaut und das passende gefunden:

ServerAliveInterval 120

LXC Container starten nicht durch AppArmor

Leave a Comment

Ich habe heute mal meinen Server neugestartet, worauf ein paar LXC Container laufen. Nach dem Neustart weigerten sich aber alle Container automatisch oder manuell zu starten. Nachdem ich dann mal einen Container mit 

lxc-start -n db -l info -o outfile

gestartet habe fand ich folgende Zeilen im outfile:

lxc-start 1412384089.536 ERROR    lxc_apparmor - lsm/apparmor.c:mount_feature_enabled:61 - Permission denied - Error mounting securityfs
      lxc-start 1412384089.536 WARN     lxc_apparmor - lsm/apparmor.c:apparmor_process_label_set:184 - Incomplete AppArmor support in your kernel
      lxc-start 1412384089.536 ERROR    lxc_apparmor - lsm/apparmor.c:apparmor_process_label_set:186 - If you really want to start this container, set
      lxc-start 1412384089.536 ERROR    lxc_apparmor - lsm/apparmor.c:apparmor_process_label_set:187 - lxc.aa_allow_incomplete = 1
      lxc-start 1412384089.536 ERROR    lxc_apparmor - lsm/apparmor.c:apparmor_process_label_set:188 - in your container configuration file

Wenn ich nun wie im outfile beschrieben, die Zeile lxc.aa_allow_incomplete = 1 in die Config des Containers einfüge startet dieser nun auch ohne zu murren.
Bei Google fand ich dazu auch direkt folgenden Eintrag auf der LXC Mailingliste. So wie ich es verstanden habe hat es was damit zu tun das ein paar Mount Restrictions von AppArmor nicht im Upstream Kernel enthalten sind. Wie ich das nun verstehe haben sie vorher die Container im ohne AppArmor Sicherung starten lassen und mit dem Config Flag werden diese nun mit Absicherung gestartet.

Bitte korrigiert mich wenn ich hier Mist schreibe, ich habs ehrlich gesagt noch nicht wirklich gecheckt, da ich mich mit AppArmor gar nicht auskenne und ich grad einfach nur müde bin. Es ist für mich immer nur ein Dienst gewesen der irgendwie immer mal dazwischen grätscht und das voll nervt. :D

Erstellung eines Certificate Signing Request

Leave a Comment

Heute habe ich meine ganzen Zertifikate erneuert, da fast alle noch aus selbstsignierten Zertifikaten bestanden und auch grad am ablaufen waren. Um mir meine Zertifikate bei CACert zu erstellen brauchte ich CSR’s wofür ich mir folgendes Script geschrieben hab:

#!/bin/bash

domain=$1
year=$(date +%Y)

# Zertifikatangaben
country=DE
state=Nordrhein-Westfalen
locality=Aachen
organization=Home
organizationalunit=IT
commonname=$domain
email=email

pass=$(dd if=/dev/urandom count=1024 < /dev/null | tr -cd "[:alnum:]" | head -c 20)

if [ -z "$domain" ]; then
    echo "generate-csr.sh example.com"
    exit 1
fi

if [ ! -d "$year" ]; then
        mkdir $year
fi

echo "Erstelle Privat Key für $domain"
openssl genrsa -des3 -passout pass:$pass -out $year/$domain.key 4096 -noout

echo "Entferne Passwort aus Privat Key"
openssl rsa -in $year/$domain.key -passin pass:$pass -out $year/$domain.key

echo "Erstelle CSR"
openssl req -new -key $year/$domain.key -out $year/$domain.csr -passin pass:$pass \
    -subj "/C=$country/ST=$state/L=$locality/O=$organization/OU=$organizationalunit/CN=$commonname/emailAddress=$email"

exit 0