IPv6 crawler gesichtet

Friday, February 25. 2011

Yo, der erste, den ich bewusst wahrnehme, im access_log steht:

blog.dreckhaen.de:80 2001:250:3c00:1062:224:e8ff:fe40:da50 - - [24/Feb/2011:11:15:53 +0100] "GET /robots.txt HTTP/1.0" 200 43 "-" "agent6/Nutch-1.1"

Wer ist das? 

host 2001:250:3c00:1062:224:e8ff:fe40:da50 
0.5.a.d.0.4.e.f.f.f.8.e. domain name pointer cernet.edu.cn.

Ein chinesisches Wissenschaftsnetzwerk  an der Qinghua Universität. 

So, und warum crawlt man mit einem IPv6-crawler, um eine Suchmaschiene nur fuer per IPv6 zugänglichen Content aufzubauen? Wär ja mal ein Projekt, beim Googeln findet man immer wieder Leute, die danach fragen und als Antwort auf sixy.ch verwiesen werden. 

Nutch jedenfalls ist eine opensource Suchmaschiene

TimeMachine on the Linux box

Wednesday, February 23. 2011

So that headline was made to attract. TimeMachine as it comes on a Mac with that timel tunnel interface and it looks so easy and intuitive - I found nohing of that sort for Linux desktop even when there were some attempts to go into that direction. And I didn't try that, too, command line interface seemed good enough for me. 

Minus Interface, minus application-awareness remains this: create a series of dated backups with less granularity the more you go into the past in surprisingly compact format.

The best idea how to accomplish that i could find lives here, the tools we need are rsync, cp and rm.
It works like so: We have a list of sources we want to include in that backup and a destination directory. When called for the first time rsync creates a copy of all the backup sources at the destination, in a subdirectory of its own, let's call it backup.00. On the next run, this earlier backup gets renamed to backup.01 and then a new backup.00 gets created as a hard link of the previous one. Now rsync does it's job, comparing the content of the source directories with the hard linked copy and only if it detects a change it copies only the changed files and folders into the new backup folder. 

Seen from the hard drives point of view we now have a bunch of hard links in the backup folder with only a relatively small number of changed files sitting next to them. However, looking at it with a file manager it is a 1:1 copy of the original source folders at the time of creation. Rinse and repeat and we get a collection of snapshots of the state of our source directories.

 Done in a rather space efficient way a hourly cron job may pack a large number of snapshots next to each other but eventually the drive will still overfow, so we need to teach that digital memory how to forget. We need a range limit so when the backup folder names get shifted up and the oldest exceeds the given limit this folder gets deleted.

Up to now we just created houly snapshots, now we introduce more time classes, i.e. daily, weekly, monthly, seasonly, yearly. Add range limits for each of them and a script to add the latest of one time class as the first of the next (and shift the names of the folders up) and we have a clockwork of backups remebering the major changes on our sources for a long time while slowly forgetting the details.

After some time running we have in our snapShot folder hourly.00 .. hourly.23, daily.00 .. daily.06, weekly.00 .. weekly.03, etc. Performance depends mostly on hd througput and the size of the source data, cpu is only the third important factor.

In praxis, writing a lot of data onto a huge but somewhat slow external usb drive with a crypted filesystem I found  that two lines of the original script took most of the time: 
deleting the the oldest folder with rm -rf and creating the hard linked copy with cp -al. So I modified the script to calling rsync with the --link-dest option which turned out to be much faster. And Instead of deleting the recycled backup immediately I move it into a trash folder which in turn gets emptied by a clean-up script late at night when it doesn't hurt. 


If you have locate/updatedb installied (as many distros have) you might want to adapt the config at /etc/updatedb.conf since all those snapshots create an ocean of file pathes and you really don't want to get them listed if you try to locate a file. And running over the snapshots makes updatedb take forever...

In /etc/updatedb.conf there is PRUNEPATHS="", a space delimited list of directories which should not get included into the locate - data base. Just put the path to your snapShot directory into this.

Android k9-mail with a different Icon

Monday, February 21. 2011

My Android mobile (HTC desire) runs k9-mail, a dilligently updated, configurable, imap-capable application well prepared to handle lots of mail but struck with an esthetically challenged icon. The head of a robot dog featured in a british cult tv series from the sixties - let's say you either love it or hate it. Judging by the number of hits this article gets I'm not alone with my irritation.

The little pic caused many discussions and every now and then someone creates a more suitable alternative and dares to propose it to the development team, but apparently this is like chewing rocks

OK, so either you leave it as it is or you change it yourself. But it is not completly trivial to change the icon of an android app, simply using an ressource editor and paste another icon into the file won't do. This is because Android apps are signed and if you change them after the signing they stop running.

On the other hand: it's open source, isn't it? So, create a project folder and on the command line type:
git clone https://github.com/k9mail/k-9.git
That done we follow the steps of 'How to build K-9 Mail' and if you happen to have set up an Android-Development Environment already, it takes but minutes and you see k9 running in the emulator. Nice, now for the icons. 

Our friend, the lovely dog, lives in two places within the ressources, at  
k-9/res/drawable/icon.png and k-9/res/drawable-hdpi/icon.png respectively.
In both places we replace it (.png, 72x72) with an image of our choice and proceed to create a new k9mail.apk with eclipse's File/Export/Android/Export android Application.

Now don't try to install the freshly built and signed k9-mail over the existing one, cause it won't. The AppInstaller starts up, displays the loading-grphs for a moment but it soon stops with nothing but a laconic message: Not installed. Searching the logs on my android didn't make me any wiser as to what was happening. 

So I tried adb which was far more eloquent. Started it as root:
sudo su
cd /opt/android-sdk-linux_86/platform-tools
./adb kill-server
./adb start-server
./adb devices

and it outputs:
List of devices attached 
emulator-5554   device
HT03ZPL02277    device

I closed the emulator with a click to make sure adb doesn't get confused about where to install in the next step and then input at the command line:
 ./adb install -r /path/to/git/proj/k9/apk/k9mail.apk

and it tells me all I need to know about the nature of the problem:
304 KB/s (2591136 bytes in 8.312s)
        pkg: /data/local/tmp/k9mail.apk

Doh! The original app was signed with a totally different keys than my own built all that signing serves to keep some bad guy to silently change an app - of course it wouldn't install. Somewhat incomfortable but I had to uninstall the original app in order to install my own built. Don't forget to backup your settings! 

Sort of breaking the dog on a wheel but it works and is a nice exercise, too. There is a con though: it probably breaks the updating so you'll need to check for new versions and build them manually. Alternative approaches do exist though I didn't try them.

Addendum re: k9 and documentation: it is rather sporadic and they are in search of people to help them writing it. But there is a Wiki a FAQ and a much needed explanation re: folder classes and how to use them

And another addendum, not that related to the above but I wanted to put the link somewhere: About installing Certificates

Oh, and then there is Kaiten Email. Dogless Icon included in the feature set, costs about 4€.


Am Beispiel einer externen Festplatte, die sich nach dem Anstöpseln als /dev/sdc meldet:

fdisk -l
gibt unter anderem:

Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x08040000

Disk /dev/sdc doesn't contain a valid partition table

Die Partition mit ziemlichem Zufall initialisieren und dabei gleichzeitig die Zuverlässigkeit der Platte prüfen:

badblocks -c 10240 -s -w -t random -v /dev/sdc
(dauert ewig.)

Formatieren und mit dem Namen silva einbinden:
luksformat -t ext3 /dev/sdc
cryptsetup luksOpen /dev/sdc silva

Optional die fsck-Frequenz etwas ausdünnen: 
tune2fs -c 1000 /dev/mapper/silva
tune2fs -i 365 /dev/mapper/silva

und ins Dateisystem holen:
mount /dev/mapper/silva /mnt/silva

und zurück:
umount /mnt/silva , falls dass mit device busy hakt, ggf fuser -m /mnt/silva
cryptsetup luksClose /dev/mapper/silva

Mehr Infos

dm-crypt vs. truecrypt:
- beide können einen Container in einer Datei, einer Partition oder einem ganzen device einrichten, beide sind opensource und bier-frei, beide sind schwer genug zu knacken dass es aussichtsreicher ist, das Versteck für den Schlüssel zu finden.
- dm-crypt ist gefühlt paarmal schneller. Bei einem Container mit Passwörtern und Tagebüchern etc. macht das keinen nennenswerten Unterschied, aber bei einer TB-Platte mit der Musiksammlung dann schon.
- dafür hat truecrypt deutlich die Nase vorn, wenn man den Container mal von win*, mal von linux her öffnen möchte
- mit dem Konzept der plausible deniability und hidden volumes hat truecrypt ein Alleinstellungsmerkmal, das unter Umständen den Abstand zwischen Kopf und Kragen regulieren helfen kann.

Vom Einsatz-Szenario her würde ich das Projekte-Device, auf dem unter anderem auch Vorhaben, die unter NDA stehen, gewiss auf dm-crypt legen, dito die Sammlung von vmware und vmbox - Maschinen oder Videos fraglicherer Herkunft.
Die MindMaps, Tagebücher, Liebesbriefe und org/finanzamt wären da eher auf einem trauecrypt-Volumen gut aufgehoben und die Sammlung von Belegen all' der schoflen  Begebenheiten, die irgendwann mal reif für ein Upload nach wikileaks sein wird, käme wohl am besten zu truecrypt in ein hidden volume.

Zertifikate: für Thunderbird

Friday, February 18. 2011

Signierte oder verschlüsselte emails versenden, mit Thunderbird und startcom - Zertifikaten: eines dieser Art bekommt man ja direkt bei der startCom - Anmeldung im Browser installiert, und man kann sich nach Belieben weitere S/MIME Client -Zertifikate für weitere email-Adressen erzeugen. 

Die Schrittfolge ist, auf startssl.com, recht schnell durchlaufen: im Validation Wizard wählt man Email Address Validation, dann eine Adresse zur Validierung eintragen, es kommt eine Mail an diese Adresse mit einem Code, den man wieder in dem Formular auf der Webseite einsetzt. Ein Klick auf Finish und nun findet man diese Adresse unter dem Reiter 'Email Validations' gelistet. 

Wechseln zum Certificates Wizard, der S/MIME gleich als default-Option hat, continue , und das koennen wir auch gleich bei der nächsten Seite (Schlüssellänge: hochgradig) klicken.

Es dauert einen Moment, während der Server bei startCom einen privaten Schlüssel generiert. Hmm, im Unterschied zur Generierung der SSL/TLS-Server certificates gibt es hier keine Option, einen selbstgenerierten privaten Schlüssel anzugeben.

In der folgenden Maske kann man aus der Menge der bislang unbedienten validierten email-Adressen eine auswählen, continue, es dauert einen Moment und dann meldet ein Popup, dass das Zertifikat im Browser installiert wurde.

Dies Zertifikat muessen wir jetzt aus dem Browser (bei mir ein Firefox/3.5.16) an einen sicheren Ort im Dateisystem und von dort hinein in Thunderbird transferieren. Der erste Schritt ist bei mir unter Bearbeiten/Einstellungen/erweitert/Verschlüsselung/Zertifikate anzeigen erreichbar, ich wähle einen der Einträge unter StartCom Ltd. aus.Mit Ansehen/Details kann man sich vergewissern, das richtige erwischt zu haben, die mail-Adresse ist als Zertifikatsgegenstand-Alternativ-Name verzeichnet. Ein Klick auf "Sichern", wenn man mehr als eine Adresse mit Zertifikaten ausruesten moechte, empfiehlt sich ein sprechender Dateiname. Nun werden Passworte abgefragt, zuerst, falls man es einsetzt, das Master-Passwort, mit dem Firefox das Sicherheitsmodul schützt und anschliessend legt man für das zu speichernde Zertifikat ein Zugangspasswort an.  Wenn man es recht bedenkt, hängt an diesen Passworten das ganze Sicherheitsversprechen des Zertifikats.

 Damit können wir den Firefox - Zertifikatsmanager schliessen und Thunderbird zum Import der Zertifikate öffnen. Edit/Preferences/Advanced/Certificates/View Certificates öffnet den Certificate Manager, unter dem Reiter 'Your Certificates' werden ggf schon vorhandene Zertifikate gelistet und auf diesem Blatt findet sich auch der Button "Import". Im Dateiauswahl-Dialog navigieren wir zum eben abgespeicherten Zertifikat und öffnen es, wieder wird erst das Master-Passwort und danach das Zertifikatspasswort abgefragt und dann ist es drin.

 Damit Thunderbird die Zertifikate nun auch nutzt, müssen sie mit bestimmten Accounts verbunden werden, dazu geht man in den Account Settings auf 'Manage Identities', markiert hier in der Liste von (ausgehenden) email-Adressen die, für die das Zertifikat ausgestellt wurde, und klickt dann Edit/Security. Unter "Digital Signing" klickt man 'Select' und hat nun oben eine Auswahl der installierten Zertifikate, zu denen darunter jeweils die wesentlichen details angezeigt werden. Hat man das rechte erwischt und klickt OK folgt die Abfrage, ob man das gleiche Zertifikat auch für verschlüsselte Mailkorrespondenzen nutzen will. Hier zustimmen und dann wird das Zertifikat auch in der Zeile Encryption eingetragen. Jetzt noch ein Häkchen bei 'Digitally sign messages (by default) und dann kann man die offenen Dialog allesamt mit OK schliessen. 

Derart signierte Mails schicken die Nachricht immer noch im Klartext durchs Netz, die Signatur garantiert nur, dass die Nachricht auf dem Wege nicht verändert wurde. Aber gleichzeitig verteilt man auf diese Art den öffentlichen Schlüssel des eigenen Zertifikates an die Empfänger, und schafft damit die Voraussetzung für die zweite Funktion, verschlüsselte Mails.
Verschlüsselte Korrespondenz ist zwischen Mailpartnern möglich, die beide ein gültiges Zertifikat installiert haben und jeweils auch den öffentlichen Schlüssel des anderen kennen. Welche Schlüssel der eigene Mailer schon kennt, listet Thunderbird im Certificate Manager unter dem Reiter 'People'.

Kostenlose S/Mime-Zertifikate  bekommt man nicht nur von startCom, mozillazine listet und diskutiert Alternativen. Mehr Infos zu Mailverschlüsselung und S/Mime. Statt mit S/Mime kann man auch mit OpenPGP verschlüsseln aber die beiden Protokolle verstehen einander nicht.

(Page 1 of 3, totaling 13 entries) » next page