Donnerstag, 21. November 2013

GNU getopt in Shellskripten

Auch in Shell Skripten möchte man hin- und wieder Optionen einsetzen. Hierzu bieten sich das GNU getopt Programm an, das neben kurzen Argumenten auch lange Argumente erlaubt. Auch optionale Parameter werden unterstützt.

Der Aufruf von getopt sortiert die Parameter nach ihrer Beschreibung um, so dass die zugewiesenen Parameter am Anfang stehen. Nach diesen folgt ein --, das von den nicht-zugewiesenen Parametern gefolgt wird.

Ein Beispiel: Wir erwarten einen Parameter a. Der dazugehörige Aufruf von getopt lautet:
getopt --options a -- "$@"
Wenn wir diesen Aufruf mit den Parametern "x -a y" aufrufen, dann liefert getopt den String "-a -- x y" zurück.
Falls wir ein notwendiges Argument mittels des Kennzeichners ":" markiert haben, wird dieser an die Option angehängt. Ein optionales Argument (markiert mit "::") führt, je nachdem ob es angegeben wurde oder nicht, zu einem Leerstring oder dem Argument. Auch hier wieder die Beispiele:
getopt --option a: -- "$@"
führt beim Aufruf mit "x -a y" zu dem String "-a y -- x". Wird das notwendige Argument weggelassen, bricht der getopt Aufruf mit einem Fehler ab.
Die optionale Variante:
getopt --option a:: -- "$@"
beim Aufruf mit "x -a y" zum Ausgabestring " -a '' -- 'x' 'y'" führt. Wenn hier das Argument y Teil von -a sein soll, muss der Aufruf "x -ay" lauten.

Doch wie wertet man das Ergebnis aus? Hier kann man am einfachsten die Aufrufargumente mittels
eval set -- "$TEMP"
neu setzen. Danach kann man in einer Schleife die Argumente prüfen und per shift entfernen, bis man zum "--" Argument kommt. Somit bleiben die restlichen Argumente übrig.
while true ; do
  case "$1" in
    -a|--along) do-something; shift ;;
    --) shift; break;;
    *) Error
  esac
done
Ein Beispiel findet man häufig auch unter: /usr/share/doc/util-linux/examples/getopt-parse.bash

Mittwoch, 30. Oktober 2013

Passwort von einem PKCS#12 File entfernen

Gelegentlich ergibt sich die Notwendigkeit ein PKCS#12 File zu verwenden, das kein Passwort besitzen darf. Aus Sicherheitsgründen verlangen jedoch die meisten Export-Tools ein Passwort (und das ist auch prinzipiell zu empfehlen).

Um aber trotzdem zu seinem "passwortfreien" PKCS#12 File zu kommen, kann man OpenSSL verwenden. Hierzu sind folgende Befehle einzugeben.

Mit diesem Befehl extrahiert man den privaten Schlüssel aus dem PKCS#12 File:
openssl pkcs12 -in protected.p12 -nodes -out temp.pem

Danach erzeugt man ein neues PKCS#12 File aus dem private-Key:
openssl pkcs12 -export -in temp.pem  -out unprotected.p12

Den überflüssigen Export (temp.pem) kann man danach löschen.


Quelle: http://blog.armbruster-it.de/2010/03/remove-the-passphrase-from-a-pkcs12-certificate/

Donnerstag, 26. September 2013

PKCS#7 gegen Content prüfen

Falls man ein PKCS#7 Signaturfile und einen Datenblock hat und prüfen möchte, ob die beiden zusammengehören, kann man dies manuell auf der Kommandozeile durchführen:
openssl smime -verify -inform DER -in sign.p7 -content data.bin  > /dev/null
Die inform muss natürlich für das PKCS#7 File angepasst werden. Hier sind DER und PEM möglich.
Falls die Prüfung mit einem Fehler der Art ":unable to get local issuer certificate" fehlschlägt, konnte das Zertifikat nicht korrekt geprüft werden (fehlende CA?). Falls man nur die Signatur prüfen möchte, kann man zusätzlich den Parameter noverify verwenden, der die Zertifikatsprüfung überspringt:
openssl smime -verify -noverify -inform DER -in sig.p7 -content data.bin  > /dev/null
Der Befehl gibt am Schluss den Datenblock auf stdout aus, daher sollte man stdout nach /dev/null schicken.
Die Prüfung kann auch über den Errorcode erfolgen:
  • 0: Erfolgreich
  • 1: Fehler beim Parsen der Argumente
  • 2: Fehler beim Lesen einer der Dateien
  • 3: Fehler beim Lesen des Datenfiles
  • 4: Fehler beim Verifizieren der Nachricht
  • 5: Die Nachricht konnte verifiziert werden, aber es trat ein Fehler beim Schreiben der Zertifikate auf

Montag, 16. September 2013

Gerät nicht im Android Device Manager

Wenn ein Android Gerät nicht im Android Device Manager auftaucht, obwohl es bereits registriert wurde, kann folgender Vorgang vielleicht das Problem lösen:

  • In der App "Google Einstellungen" den "Android Gerätemanager" auswählen und die Option "Zurücksetzen per Remote-Zugriff zulassen" abwählen
  • In den Einstellungen Apps -> Alle -> "Google Play-Dienste" auswählen (hier kann man auch gleich prüfen, dass die Version >= 3.2.25 ist) und den "Daten löschen" Button auswählen. Falls dieser ausgegraut ist, kann es helfen, mit einem "Beenden erzwingen" den Dienst zu stoppen, um die Daten danach löschen zu können. Durch diesen Vorgang sollten keine persönlichen Daten gelöscht werden.
  • Nun geht man zurück in die "Google Einstellungen" und wählt im "Android Gerätemanager" die Option "Zurücksetzen per Remote-Zugriff zulassen" aus.
  • Schließlich muss das Gerät neu gestartet werden. Nach dem Neustart sollte (vielleicht nach einer kurzen Wartezeit) das Gerät im Device Manager verfügbar sein.


Quelle: http://www.reddit.com/r/Android/comments/1jw90u/android_device_manager_is_now_live/

Mittwoch, 11. September 2013

Label eines RAID Arrays ändern

SUSE (und wahrscheinlich auch andere Distributionen) legen ein RAID Array mit einem automatischen Namen an. Wenn man das RAID Array immer an der gleichen Stelle verwendet, ist das üblicherweise auch kein Problem. Hat man aber mehrere Arrays oder will man das Array aber auf einen anderen Rechner transportieren, möchte man vielleicht wissen, was das Array mit dem Namen "/dev/md?" enthält. Hierzu ist dann ein aussagekräftiges Label des RAID-Arrays sinnvoll.

Ein bestehenden Label kann man mit diesem Befehl ändern:
mdadm --assemble /dev/md/alpha --name=newname --update=name /dev/sd[gf]
  • /dev/md/alpha ist der Name des RAID Devices (hier kann man auch /dev/md0) verwenden
  • newname ist der neue Name des RAID Arrays
  • /dev/sd[gf] sind die Einzeldevices des RAID-Arrays

Den Array-Namen kann man in der Ausgabe des blkid Befehls auf den Einzeldevices sehen oder in der Ausgabe von:
mdadm --detail /dev/md/alpha

Quelle: http://askubuntu.com/questions/63980/how-do-i-rename-an-mdadm-raid-array

Montag, 9. September 2013

static imports in Eclipse

Einige Bibliotheken stellen ihre Methoden ja als statische Methoden zur Verfügung. Beispiele dafür sind jUnit#Assert oder guava#Preconditions. Wenn diese Klassen in Eclipse unter
Preferences -> Java -> Editor -> Content Assist -> Favorites
eingetragen werden, tauchen diese Methoden direkt in der Code-Completion des Content-Assistenten mit auf und können einfacher ausgewählt werden.
Meine Empfehlung:
  • org.hamcrest.Matchers.*
  • org.hamcrest.CoreMatchers.*
  • org.junit.*
  • org.junit.Assert.*
  • org.junit.Assume.*
  • org.junit.matchers.JUnitMatchers.*
  • com.google.common.base.Preconditions.*
  • org.mockito.Mockito.*



Quelle: http://piotrjagielski.com/blog/working-with-static-imports-in-eclipse/

Freitag, 9. August 2013

Reboot required?

Ein notwendiger Reboot eines Ubuntu Systems (z.B. wenn ein Paket-Update diesen erfordert), wird über die Datei
/var/run/reboot-required
signalisiert.

Donnerstag, 25. Juli 2013

Gründe, warum umount nicht funktioniert

Quelle: http://oletange.blogspot.de/2012/04/umount-device-is-busy-why.html


  • Ein Prozess greift gerade auf das gemountete Verzeichnis zu. Dieser kann üblicherweise mittels lsof gefunden und getötet werden.
  • Der nfs Kernelserver verwendet das gemountete Verzeichnis. Dies kann über den Befehl showmount geürft werden. Nach einem Stopp des Servers sollte das umount funktionieren
  • Ein loopback Device verwendet eine Datei im gemounteten Verzeichnis. Dies lässt sich per "losetup -a" überprüfen.
  • Ein Swap-File existiert im gemounteten Verzeichnis. Dies lässt sich per "cat /proc/swaps" prüfen. Falls ja, wird das Swapfile mittels "swapoff" abgeschaltet.
  • Das Device hat einen Fehler. Dieser Fall lässt sich per "dmsg" überprüfen. 

Donnerstag, 18. Juli 2013

Amazon EC2


Informationen über seine EC2 Instance kann man über die Adresse 169.254.169.254 bekommen. Hier bietet sich folgender Request an:

GET http://169.254.169.254/latest/meta-data ; echo

Mehr Informationen findet man in der EC2 Dokumentation.


bash History

Die bash Historie kann mit Hilfe des "!" angesprochen werden. Folgende Abkürzungen sind meiner Meinung nach sinnvoll:

  • !! - der letzte Befehl
  • ! - der letzte Befehl, der mit anfing
  • !* - die Argumente des letzten Befehls
  • !^ - das erste Argument des letzten Befehls
  • !$ - das letzte Argument des letzten Befehls
Zusätzlich kann hinter die !xx History Expansion ein ":p" angehängt werden. Dadurch wird ausgegeben, was die Expansion tun würde.

Damit in der History Duplikate nicht aufgeführt werden, kann man  die Environment Variable HISTCONTROL setzen. Mit
HISTCONTROL=ignoreboth
werden Duplikate und Befehle, die mit einem Space anfangen, nicht in die History übertragen.

Um eine unendliche bash-History zu bekommen, muss man eine Kombination aus den Environment-Variablen HISTSIZE und HISTFILESIZE einsetzen. Die erste beschreibt dabei die max. Größe der im RAM gehaltenen History, die zweite die max. Größe der auf Platte gehaltenen Datei.
Möchte man zum Beispiel die letzten 1000 Einträge im RAM behalten, die Datei aber beliebig groß werden lassen, muss man die Variablen wie folgt setzen:
export HISTSIZE=10000
export HISTFILESIZE=""


Quellen:

Mittwoch, 13. Februar 2013

Durchsatz einer Pipe

Um schnell Daten von einem Linux Rechner auf einen anderen zu transportieren kann man einen ssh tunnel benutzen. Zum Beispiel mit der Befehlszeile:

tar cf - src | ( ssh other "cd dest && tar xfv - " )

Dabei kann man aber leider nicht sehen, wie schnell die Übertragung ist. Hierzu kann man dann den pv (Pipe Viewer) Befehl verwenden. Dieser misst den Durchsatz durch die Pipe. Eingesetzt wird er (im obigen Beispiel) wie folgt:

tar cf - src | pv | ( ssh other "cd dest && tar xfv - " )

Leider ist pv unter SLES nicht im Standard-Repository zu finden. Eine passende Datei lässt sich aber hier herunterladen.