Donnerstag, 20. März 2014

Automatisches Umleiten des stdout/stderr in einem Shell Script

Üblicherweise schreibt ein Shell Script seine Meldungen auf stdout und gegebenenfalls auf stderr. Wenn diese statt dessen in ein File geschrieben werden sollen, wird das Script mit entsprechenden Umlenkungen gestartet:
script.sh > script.log 2> script.err
Soll das Script aber seine Meldungen von vornherein in Dateien schreiben (ggf. getriggert durch einen Parameter) kann man mit Hilfe des Befehls exec dies einstellen.
Ein Beispiel veranschaulicht dies am besten:

#!/usr/bin/env bash

echo Hallo

exec > logme.log 2> logme.err

echo Log

echo Error >&2

Mittwoch, 19. Februar 2014

Programm in Unity hinzufügen

Um ein Programm in Ubuntu Unity zu sehen, muss man eine passende .desktop Datei in das Verzeichnis  ~/.local/share/applications/ legen.


Quelle: http://askubuntu.com/questions/67753/how-do-i-add-an-application-to-the-dash

Mittwoch, 5. Februar 2014

Threaddump für JVM

Unter Linux kann man mit einem QUIT Signal die JVM dazu veranlassen, einen Threaddump zu schreiben:
kill -3 pid kill -QUIT pid
Der Threaddump wird auf stdout geschrieben.
Alternativ kann ab JDK6 das Programm jstack benutzt werden. Dieses zeigt den Threaddump direkt an. Um die verfügbaren Java-Maschinen zu sehen bietet sich das Programm jps an.

Montag, 13. Januar 2014

iscsiadm Übersicht

Kleine Übersicht über die wichtigsten iscsiadm Befehle

Verfügbare Targets an einem Server finden
iscsiadm -m discovery -t sendtargets -p ipaddress

An einem Target anmelden
iscsiadm -m node -T targetname -p ipaddress -l

Von einem Target abmelden
iscsiadm -m node -T targetname -p ipaddress -u

Weitere Befehle:

Informationen über das Target bekommen
iscsiadm -m node -T targetname -p ipaddress

Alle eingeloggten Sessions anzeigen
iscsiadm -m session

Multipath-Infos anzeigen
multipath -ll

Quelle:  http://axelilly.wordpress.com/2010/05/27/help-iscsi-initiator-commands-for-linux/

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