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

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/

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

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/

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.

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. 

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.