nobody's soup

with "listen-on-v6 { any; };" my bind9 instance binds correctly to all Ipv6 addresses. But as this is bad style - one does not bind services to all Ips, especially not a DNS server - and as it would even cause problems - I have a dnscache on ::1, bind9 is only authoritative - I want it to bind on a specific address. A "listen-on-v6 { 2001:123:1234::1/128; };" should do that. Hrm, after a restart of bind it does not listen on IPv6 at all.
I start up named with "named -g -d 5 -c /etc/bind/named.conf -u bind" for debugging. Here, bind9 binds nicely on the v6 address. So what is that initscript in debian doing different? Hrm, obviously it uses "-t /var/lib/bind" to chroot the named, which is probably a good idea as bind is relatively complex. But that can't have anything todo with IPv6, can it? Firing up "named -g -d 5 -c /etc/bind/named.conf -u bind -t /var/lib/bind" I was negatively stunned: It does have something todo with IPv6. There is no error message or something, it just does not bind on IPv6. For what reason, I can only guess.

Isn't that bind how we now and love it?

Today, I would like to thank Carlo Wood. Who's that you will probably think. He is the author of ext3grep. But first things first.

Everyone's (or at least my) homedir gets a little congestet from time to time and needs to be tidied up. As it goes, I once had a file 'bl.tex' for testing something and this file and all that get created during the run of 'pdflatex' were still lying around. So I typed 'rm bl.*' or at least I wanted to, instead I issued 'rm bl*'. One little dot, but a much larger effect. It happens that I had a file called blub.txt with some important content, and of course after that command, that file was gone.

Few seconds later, after I realized what I had done, I issued 'mount -o remount,ro /mnt/raid1' at my server. This is the volume where my homedir resides. This is important, as it stops writing to the filesystem. If writing would continue, the file might be overwritten or the journal would have lost the interesting parts. (Journal is involved in restore operation)

I probably could have used 'ext3grep /dev/mapper/storage-store --restore-file "home/nobody/blub.txt" however, as '/mnt/raid1' is a 750GB Volume, that would have taken some time. (I would have been willing to spend it, but as a nerd I of course wanted to have a faster way)

I did an "ls -li" in my homedir and discovered that the inode numbers of my files where more or less linear, probably because I recently moved my homedir by rsyncing it all to a new volume. I looked up the inode of the file lexically-before the first file deleted and the inode of the file lexivcally-after the last file deleted.

This way, I could be very sure that blub.txt had an inode somewhere between 10125947 and 10125958. Using

'for i in $(seq 10125947 10125958); do ext3grep /dev/mapper-storage-store --restore-inode $i; done'

I restored all those files deleted. Figuring out which of them was blub.txt was an easy task.

ps> 'ext3grep /dev/mapper-storage-store --ls --inode <inode of homedir>' would have probably shown the inode of 'blub.txt' too, but that would have taken some time on a 750GB volume.

Dank Festival kann trieste jetzt sprechen. Die Stimme klingt leider zugegeben noch etwas künstlich, aber Festival war das beste freie Programm was in dem Bereich finden konnte. Falls jemand mit Sprachsynthese Erfahrung hat, würd ich mich freuen wenn man da noch mehr rausholen könnte, ist vielleicht nur eine Sache des Feintunings.
Momentan sagt sie ab und zu die Uhrzeit und das Wetter an und macht spät abends darauf aufmerksam, dass bald der letzte Bus kommt.
Trieste redet nocht nicht sehr oft, ich dacht mir, erstmal vorsichtig anfangen damits nicht nervt, mehr kann dann immernoch kommen.
Ein paar Ideen für die Zukunft sind: Wetterwarnungen so nach dem Motto "In einer halben Stunde wird es wahrscheinlich anfangen zu regnen" oder auch einfach RSS/ATOM-Feeds vorzulesen, z.B. die Sublab Soup.