Ja ich weiß, der IPv6 Launch Day war gestern, aber da hatte ich Blutdruck und nicht so richtig Zeit euch was zu erzählen. Jedes mal, wenn man irgendwo etwas von IPv6 hört (oder gar selbst was sagt), kommen die ach so tollen Datenschützer und schreien "Aua!" und "Ohje!" und weil ich es nicht mehr hören kann, schrei ich einfach mal selber mit. Klingt doch wie ein Plan, oder? Oh, moment, das habe ich doch letztes Jahr schonmal gemacht, aber vielleicht können nicht so viele Leute Englisch, ich versuche es auf jeden Fall nochmal. Also lieber Herr Beuth von der Zeit Redaktion, lieber Herr Tremmel von netzpolitik.org und auch Herr Schaar, hingesetzt und zugehört, bitte! IPv6 bringt einige Neuerungen gegenüber dem (in die Jahre gekommenen) IPv4. Die wahrscheinlich Bekannteste ist der Anstieg des Adressbereichs von 2^32 auf 2^128 IP-Adressen (Google hat mal ausgerechnet wieviel das ist). Das reicht zwar nicht, um jedem Atom auf der Erde eine eigene IPv6-Adresse zu geben, für die Menschen und ihre elektronische Spielzeuge sollte es aber reichen (hoffe ich zumindest). Aber IPv6 bringt auch IPsec mit, welches es erlaubt, direkt auf der IP Schicht zu verschlüsseln und zu authentifizieren. Und SLAAC und ... eigentlich wollte ich gar nicht erzählen wie toll IPv6 ist. Was euch stört ist die Anzahl der Adressen. Alles hat auf einmal eine eigene IP-Adresse. Jeder ist auf Schritt und Tritt verfolgbar. Ja, in ziemlich genau dem selben Maße wie heute! Wenn meine Logs nicht lügen (und das trauen sie sich nicht!), habe ich meine IPv4-Adresse mindestens seit dem 12. Februar 2012. Unverändert. Seit fast vier Monaten. Mein Provider ist Unitymedia, aber ich weiß, dass auch Andere (z.B. Vodafone) schon lange keine richtig dynamischen IPv4-Adressen mehr vergeben. Die meisten Leute sind doch eh dauer-online mit ihren Routern, da kann man denen auch die Adresse wiedergeben, wenn sie sich neu verbinden. Richtig, man ist heutzutage also schon genauso via IPv4-Adresse identifizierbar wie morgen via IPv6. Aber bei IPv6 hat doch jede Maschine (Computer, Handy, Tablet) eine ganz eigene Adresse! Aber nicht der Windows PC den jeder Schreihals zuhause hat (Update: und auch nicht bei Ubuntu), der hat die Privacy Extensions automatisch an und bei OSX und Linux kann man es ganz einfach einschalten. Bei Heise stehts etwas komplizierter. <Update>Wem das nicht reicht, der kann ja gucken ob sein Provider ihm da helfen kann oder mal selbst Hand anlegen.</Update> Und übrigens lieber Herr Tremmel, Cookies gehen auch via IPv4. Wenn ich Cookies habe, muss ich niemanden mit der IP-Adresse tracken. Und wenn wir (die bösen Netzwerker, Webseitenbetreiber, Admins, ...) euch schon nicht tracken wollen, dann hacken? Weil ja nun jeder Computer eine eigene Adresse hat? Auf einmal muss jeder Computer sicher gemacht werden? Er ist es nicht, weil ihr dachtet euer NAT ist auch eine Firewall? Nun, die meisten aktuellen Router (die auch euer NAT machen) können ein wenig Firewall spielen, aber das können die auch bestimmt bei IPv6, wenn man es einschaltet. Und echt, eure Computer sind nicht von alleine sicher? Was passiert eigentlich wenn ihr mit dem Laptop bei Starbucks sitzt, oder im ICE, oder in der Uni, oder gar im Bundestag? Hat euch da schonmal jemand via WLAN gekitzelt? Wird mal Zeit. Man sollte sich wirklich nicht darauf verlassen in einem "sicheren" Netzwerk zu sein. Sowas gibt es nicht. Gab es nicht. Wird es auch nie geben, versprochen. Wenn ihr wirklich Privatsphäre wollt, schaltet ihr Cookies aus und JavaScript auch. UND BENUTZT TOR! Und verschlüsseln solltet ihr auch! Ach und Herr Beuth, nur weil die Provider meistens ein /64 Netz an ihre Kunden vergeben (Update: die Telekom aber z.B. nicht, hier gibts /56, was wohl auch Empfehlung ist!), heißt es lange noch nicht, dass der Präfix die Hälfte einer IPv6-Adresse ist. Ein Präfix ist ein Präfix und kann so groß/lang sein, wie der Provider es möchte, eine Hälfte sind immer 50%. Der Präfix den der Amerikanische Provider Sprint von der ARIN zugewiesen bekommen hat (ja, bei denen heißt das auch Präfix), lautet 2600::/29, hat also 99 "freie" Bits, und ist damit etwas weniger als die Hälfte. Und jetzt Feierabend. Ich nutze mein IPv6, ich hab morgen noch Spaß, macht was ihr wollt!

Yesterday I finally got my girlfriend to switch from X-Chat to irssi. Well, she actually switched herself as she wanted to have a persistent backlog and the ability to connect to it from everywhere. Setup was easy and painless, but she missed one feature of X-Chat, the nicklist on the right. That's easy: /script load nicklist and /nicklist screen and done, huh? But X-Chat's nicklist does not only list the nicks and their modes but also indicates whether the person is away or not. irssi's nicklist.pl does not support that. Well, did not support. Some unspeakable words about Perl later I had it working. At least sort of. I am not satisfied with the result yet. irssi saves the away status of the person in the gone attribute of the nick. But it seems not to be updated regularly but only when you do a /WHO to the nick or a channel he is in. To solve this, I currently issue a /WHO every time someone joins the active channel plus every 5 minutes, again, only for the active channel. This means you might miss updates in channels you don't have open frequently but you also do not spam the IRCd too much. Better solution anyone? I'd prefer not to have an own list of channels and nicks somewhere with "last updated" timestamps. Get the diff against the latest upstream version or a fully patched file here and throw me your (better) solutions!

Because I have this:

It's a hand-made, erm, hand-knitted Tux with a Debian swirl. Made by Birgit Hüsken of stricktux.de for me. A howto can be found on Birgit's site, CC BY-NC-SA licensed. Very very happy about the new member of the family right now. He will have to travel a bit with me in the future and hopes to meet you soon :)

Today I wanted to clone my dotfiles repository (no, not available online, too much private stuff in there) to a remote machine and noticed that it has grown way too big (20MiB working directory and about 200MiB in .git), so I decided to clean it up. git gc did clean up a couple of megabytes, but .git was still about 190MiB, so I wasn't satisfied. Short thinking revealed the "lost" megabytes are somewhere in the history when I accidentally added some files and removed them afterwards (iceweasel, icedove, it's you I'm blaming ;)). But how the heck do I find and remove them? git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch FILE' -- --all will remove FILE from all commits, says git-filter-branch(1), but how to find those files? They are not in my working directory anymore and I do not want to checkout every revision and look for big files in there. Let's ask git itself :) for commit in `git log --all --pretty=format:%H`; do git ls-tree -r -l $commit; done |awk '{print $4 " " $5}' |sort -nu will show all files (actually all versions of all files) ever known to git, with the biggest ones at the end. Just identify the really big (unused) ones and remove them as above, thats what you think, right? Right, but .git won't be any smaller. Huh? Read git-filter-branch(1) again, just create a clone and it will be smaller, so mission accomplished! Now I had just 6MiB to push (compressed). For reference, the old tree would have used something about 150MiB to push.

It's been a long time since my last post about my "desktop in a shell", but today I stumbled over something absolutely awesome I want to share with you. A bit of background: I am using mutt with a single imap server (where everything is forwarded to), because I disliked the idea of having multiple mutt instances running and did not want to play the "<change-folder>imaps://other.server.tld/<enter>" game too much. Now today I had to delete some mail from an account I don't use regularly (and where the webmail sucks), so I switched my screen to mutt and actually did the <change-folder> game and was like wow... because the account showed up in my sidebar and I could just jump between the folders of both accounts. So I thought how to automate this, so I could actually use mutt with multiple accounts (without offline-imap and friends, which is what you find on the web). It's damn easy:

# muttrc
set imap_user=account1
set imap_pass=password
set folder="imaps://imap.one.example.com/INBOX"
set spoolfile="imaps://imap.one.example.com/INBOX"
...
push <change-folder>imaps://account2@imap.two.example.com/<enter>

Well, what does this do? It advises mutt to use imap.one.example.com, but then just jumps to imap.two.example.com at the end of the config, resulting in both accounts being loaded into the sidebar and usable. That's it, one line and it is awesome! Please note, the password to both accounts is the same, you will have to fiddle around and put it in the URL somehow if it differs.

So I own some machines with that Universal OS on them and had to create a bunch (300) identical USB-keys (with the not so universal daughter OS). Doesn't sound too complicated, huh? Buy 300 USB-keys, create one by hand, dd that over the 299 others. To make life easier, add some USB-hubs to the mix. Well, I will drop the part how to use dd to make identical copies of USB-keys and just list the lessons learned:

1. The regular USB-key is some millimeters wider than a standardized USB-plug and almost all manufactors of USB-hubs place the ports in a way that there is exactly no space between the plugs. Yes, that means that you cannot plug two USB-keys in two neighboring ports of the hub then.
2. There is NO way to get a USB-hub for below 10€ here in Düsseldorf, and if you do...
3. HiSpeed USB 2.0 does NOT mean the hub will actually work as a USB 2.0 hub with 480Mbit/s, but as USB 1.1 with 12MBit/s
4. If you happen to own a Cherry keyboard with an integrated USB hub, it's most probably USB 1.1 too :/
5. When you buy 300 USB-keys, don't expect them to be identical, about 100 of them are 3MiB smaller than the other 200, and we created the initial image on one of the "big" ones of course.

... you have to put options scsi_mod scan=sync somewhere in /etc/modprobe.d/ and regenerate the initrd. (thanks to Michal Ludvig in http://lists.debian.org/debian-boot/2010/11/msg00369.html) Just happened to me on my Sun Netra T1-200 after the upgrade from Lenny to Squeeze, which threw me back into busybox of the initrd when it could not find the root-fs (on raid) and where mdadm -A /dev/md0 worked just fine to confuse me.

Let data be textarea->value and browser be (firefox or chrome). I want the user to be able to sign the data he entered in the textarea as I do not trust the website to store the data without modification. So far I found a couple of GnuPG/PGP based solutions:

• FireGPG, orphaned(not compatible with Firefox4+), there is fork on github
• gpgAuth
• GPGTools Mobile

Didn't test any of them yet, so I am asking you, dear Lazyweb: are these any good? Are there any more such tools? What about X.509 client certificates? Can I abuse them for signing in the browser too? So far I found login stuff only. Pointers highly appreciated.

So I got my hands on that new machine, somewhere, somehow, and I had to make myself comfortable on it. The biggest difference in that machine and the ones I used before is the RAID controller, an Adaptec 5405, instead of the 3ware ones I used to have before. That means getting used to new tools, messages and all these things which I'll try to document here.

Step 1: does vendor deliver?

Well, yes, mostly. There is (mainline) kernel support for the controller, Squeeze's kernel will boot up just fine and I just throw my junk into /dev/sda and it will handle the whole raidy thingy itself. But what is when I want to check the health of the disks, to add a spare or modify the caching? Ask the mighty vendor and it will answer "Yes, you can!". So I downloaded that asm_debian_x86_x64_v6_50_18570.tgz, unpacked and faced two debs, one i368 and one amd64. Yes, you could have saved half of the bandwidth if someone would have asked for the arch before, but who cares for some additional 60MiB today? So let's see what it does. Oh no, wait, there is a READMEASM_IUG_for_Debian_and_Ubuntu.txt:

1. Make sure to be in root level access.

2. Install the ASM storman .deb package. For example, if the package is storman_6.50-18570_i386.deb,

   then install it using the following command dpkg -i storman_6.50-18570_i386.deb

3. Adaptec Storage Manager will get installed at /usr/StorMan

4. Add the line /usr/StorMan to /etc/ld.so.conf. Then run "ldconfig". This is needed for the arcconf

   utility to find the path of the libstdc++.so.5 library

Well, 1 is obvious, so is 2. For 3: hum, /usr/StorMan? Ever heard of FHS? Don't think so. For 4: WTF?! I prefer to get libstdc++5 from my local Debian mirror instead. But at least they provide a .deb, right? Uhm, no, it's an RPM converted via alien :( And don't dare to look at preinst, postinst and postrm (it extracts an own copy of Sun JRE 1.6u16, chmods around wildly on install and does rm -rf something on uninstall, did I see that some days ago on the webs?). Let's get rid of that package as soon as possible, I decided, and just keep arcconf (which will be described later), esp because StorMan itself seems to include some call-home functionality which I'd like not to have:

cp -a /usr/StorMan/arcconf /usr/local/sbin/

apt-get remove --purge storman

Step 2: does community deliver?

You can, by the way, get (better) packages at http://hwraid.le-vert.net/wiki/DebianPackages from Adam Cécile (Le_Vert). I didn't test those much, but I currently use the arcconf package from there, which seems to be exactly what I need: proper dependencies and just the arcconf binary, no Java sh*t.

Step 3: monitor the controller

As this post is about monitoring, not ranting, let's continue. As mentioned before, I only have arcconf installed, which is just a cli to do stuff with the controller. If I understood the docs right, the actual StorMan is able to send notification mails when a disk dies or the controller gets eaten by aliens, but as I don't have StorMan, I have to do things myself. Adam has a aacraid-status package in his repository, which includes some minimalistic shell-daemon to monitor the output of arcconf. It didn't perfectly fit my needs (and had some hickups with my disks which refuse to report a vendor, whyever), so I decided to write something myself (slightly based on what Adam has done in aacraid-status, though). The result is on GitHub: https://github.com/evgeni/aacraid As you can see the code contains (at the time of writing) exactly ZERO comments and there is no README either, but it's actually quite usable already.

• aacraid.py is the main magic inspired by Adam's aacraid-status, basically just parsing arcconf output
• aacraid-status prints all useful info about all controllers, arrays and disks (the output is pretty much like Adam's)
• aacraidd is a small daemon which will monitor all controllers every (per default) 5 minutes and mail you in case of status-change

I am now running aacraidd and get happy mails when something breaks :) [running = running from /etc/rc.local, no init script yet :)]

Step 4: monitor the disks via smartmontools

There is one little problem I have with arcconf: it's closed source and does magic to the controller. With the old 3ware controller I was able to monitor the disks with smartmontools/smartd using something like this:

/dev/twa0 -d 3ware,0 -a -s L/../../2/01 -m root

/dev/twa0 -d 3ware,1 -a -s L/../../2/03

This is possible with Adaptect controllers too (not through /dev/twaX obviously). You have to have the sg module loaded, which will result in /dev/sg[012] on my machine, with sg0 being the controller itself and sg1/sg2 the both disks attached to it. Having sg loaded, one can now use smartd with:

/dev/sg1 -d sat -a -s L/../../7/01 -m root

/dev/sg2 -d sat -a -s L/../../7/02 -m root

(-d sat is the important option here!) Thanks to Thomas Krenn Wiki: Smartmontools mit Adaptec RAID Controller for the basic info and ostlogd.spenneberg.net: Adaptec-Raid-Controller S.M.A.R.T.-Healthstatus monitoren for the pointer to the sg module!

Step 5: relax

Yupp, 4 steps are enough, go relax until the next disk dies (you will be doing something REALLY important that moment according to Murphy).

Yupp, it's this time of the month again! Rhonda has already spammed about it, but I think repeating won't hurt: the next (4th) meeting of the Debian/Ubuntu Games Team will be held in #debian-games on June 26th at 10:00 UTC.