line coverage per test by Jacoco

Nach einem Eintrag in der Mailingliste von Sonar wird Jacoco demnächst auch die Coverage von einzelnen Tests unterscheiden können. Siehe auch Sonar Issue.

Damit könnte man dann ähnlich wie hier beim metricanalyzer eine qualitative Einschätzung der Tests vornehmen. Wird noch richtig interessant!

Nun stellen sich mir nur noch die Fagen, ob ...

  • ...auch Branch-Coverage möglich wird?
  • ... das auch bei parallelen Tests geht?

EncFS --reverse

Gerade habe ich in der Manpage von EncFS eine sehr schöne Lösung für ein sicheres Backup in der Cloud gefunden.

Encfs ist ein Dateisystem im Userspace und bietet eine Sicht auf Verzeichnisse an. Ursprünglich ging es darum verschlüsselte Verzeichnisse entschlüsselt anzuzeigen. Der Reverse Modus bietet genau den umgekehrten Weg an. Somit können beliebige (unverschlüsselte) Verzeichnisse mittels EncFs als verschlüsselte Verzeichnisse angezeigt werden.

"Wow. Wtf?" Werden sich gerade einige fragen. Aber mit dieser umgekehrten Sicht, kann man einfach mit einem Synchronisationswerkzeug das Ganze an syncronisieren. "Wow!"

Ich verweise einfach nur auf den Artikel: Daten sicher in der Synchro-Wolke dank encfs.

Habe leider keine Ahnung, ob dieser Modus auch für Mac bzw. auch für Windows via dokan verfügbar ist. :|

P.S. Python WrapperSkript encfs –reverse + rsync = encrb

Clean Code Regel für Sonar

Diese Woche habe ich das 'Clean Code: A Handbook of Agile Software Craftsmanship' noch einmal gelesen. Nach einem weiteren Jahr Praxis, sieht man viele Sachen schon wieder erstaunlich anders.
Ich mußte dann doch gleich auf der Sonar-Mailingliste nachfragen, ob es schon eine Regel für 'G15 Selector Arguments' gibt. Gibt es wohl nicht.

Kleine Vorschau
Hier nun mein Beitrag dazu: commit. Bin mal gespannt, ob und wenn in welcher Form die Regel aufgenommen wird.

Datenschutz auf dem Blocklevel bei Rootservern

Ich habe vor kurzem meinen Server umgezogen, wie in Serverbörse bei Hetzner angekündigt. Dabei ging es mir vorallem um mehr Speicherplatz. Die Kapazität ohne monatliche Mehrkosten konnte ich von 750GB auf 3TB erhöhen.

So ein Umzug ist auch immer ein Neuanfang. Ja, so pathetisch wie es klingt, so denkt man auch ... ganz kurz. Ich habe mir vorgenommen einige Sachen besser zu machen.

Bei meinem letzten Umzug waren die großen Veränderungen, dass ich die einzelnen Dienste in autonome virtuelle Maschine portiert. Diese VMs laufen nun in einem virtuellen Netz auf dem Server, mittels Virtualbox. Läuft alles wunderbar und man kann schnell mal experimentieren und neue VMs dazupacken.

Bei diesem Umzug war mir Datensicherheit sehr wichtig. Zeitgleich ist mir zuhause eine 2TB Platte peu-à-peu kaputt gegangen. Beim Dumpen der Daten ist mir dann wieder bewußt geworden, dass auch lokal bei 100MB/s immer noch knappe 6h zum Kopieren notwendig sind. Ich versuche meine kaputten Platten vor dem Verschrotten meistens noch einige Runden zu shreddern.
Bei meinem neuen Rootserver habe ich mir überlegt mit einer Basisverschlüsselung, kann ich mir das Shreddern sparen. Dank AES und schnellen Prozessoren ist der Leistungsabfall recht gering und verschmerzbar.

Ziel: Absicherung bei Server-/Festplattentausch

Vorgehensweise:

Aufbauend auf diesen Anleitungen Festplattenverschlüsselung mit Debian GNU/Linux und CryptoPartitionHowTo habe ich cryptsetup eingesetzt. Die Formatierung, wie in den Anleitungen angegeben (mit luks) und dann ...

/etc/crypttab


...
crypted-md2 /dev/md2 /etc/disk.key luks
...
lvm config

# lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
vm raid1 -wi-ao-- 400.00g
...
/etc/fstab

...
/dev/raid1/vm /vm ext4 defaults 0 0
...

kleines Benchmark

Zuerst von der "rohen" Festplatte, dann vom verschlüsselten Gerät. Der Arbeitspeicher hat die Größe von 12GB, daher nehme ich zum Test mehr, dass mir kein Caching dazwischen kommt.

root@wirt2:~# hdparm -t /dev/sda

/dev/sda:
Timing buffered disk reads: 356 MB in 3.00 seconds = 118.53 MB/sec
von der Festplatte /dev/sda

root@wirt2:/vm# time dd if=/dev/sda bs=1M count=10k > /dev/null
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 82.7227 s, 130 MB/s

real 1m22.725s
user 0m0.404s
sys 0m22.109s
aus der Datei /vm/x

root@wirt2:/vm# time dd if=x bs=1M count=10k > /dev/null
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 80.9839 s, 133 MB/s

real 1m20.986s
user 0m0.248s
sys 0m16.261s
Aufgrund der Zahlen läßt sich abschätzen, dass die Grundverschlüsselung bei heutigen Prozessoren durchaus tragbar ist, sofern die Last niedrig bis mittel ist. Mit AES-NI sollte es dann weiter im Grundrauschen versinken. (Auf diesem Server ist ein i7 CPU 975 @ 3.33GHz.)