Hacking dhclient.conf won’t help, as the classic ifup ifdown scripts don’t touch this. Configuring extra search domains through Network Manager itself is no-go also, as you then need to configure static ip’s or at least static all of the dns entries which don’t get your dns server, domain name and search domain configured by dhcp also. What I needed, was adding search domains to resolv.conf.

Long story short, just add an additional search stanza line to /etc/resolvconf/resolv.conf.d/tail.

Getting Network-Manager to do what you want isn’t allways that flexible, and configuration options are limited when you hand over control to the nm daemon. but so far I manged to let it do most of what I needed, which isn’t all that special actually. I you wan’t to avoid NM taking control of you interface, just be sure to add an iface entry to /etc/network/interfaces, Network Manager takes only control of the interfaces which only have an auto line.

We already recovered from file system corruption, data loss, and some other fine things last week. Al we had to do was plugging in a new disk and let the mirror rebuild.

Well, at least , that’s what raid should be about. But as Kris already reports, not only DNS, but also raid is quite funky.

Dell seems to agree with Kris. In short, I afterwards found a forum comment from someone who confirmed the issue where initializing a new disk had the funny side effect of resetting existing “containers” (= raid array) 50% of the times you tried this exercise. Not to say, this is big fun when all you wanted to do was putting back some redundancy in a degraded mirror.

Enjoy hardware RAID. Be stuck wih the controller bios interface. Quite a spartan one I must say. Enjoy a simple interface with not too much choice – or was it not enough choice?

I quickly decided, when reinstalling was all we could do, to define each of the two disks, as a simple volume. They still were exported by that funky scsi controller, but once I had a separate sda and sdb, I was ready to let Debian manage them.

At first I was quite optimistic. It was the first install I did with a freshly downloaded Etch. Software raid md devices and LVM volumes all you can eat.

Let me be short. The Debian installer, even in Etch, is funky. Luckily you can always ctrl-alt-F2 to a shell to have some more control and forcing some stuff manually. But in the meantime, that installer is full of bugs.

I remain deadly sure I did configure the /boot partition (on a md, not lvm device) with the proper mount point. Turns out, and I noticed this again at a later reinstall, the Debian installer insists on resetting stuff like that. This is Not Nice.

Another funky problem is when the Debian Installer kernel cannot handle some SCSI routines to let the running kernel know some new md devices were created. Which is not very handy when you need to put those pv‘s in a vg during the same setup. Setup which refuses to write to disk because you didn’t define a root partition yet.

O well. Besides this funky music, linux software raid remains a lot more flexible.

You can read those partitions from any (operating) system with a recent Linux kernel. No data lock-in.

It’s no problem to create a mirror with one disk. Especially when you have some data left you need on the other disk, it’s nice to know you can start the raid array without needing to already reformat that disk.

Did I mention flexibility?

O, some nice article I found, when unrelatedly browsing tfw today. An interesting read on md devices, which seems quite complete on the debian raid subject.

Read more on rsnapshot on its homepage: rsnapshot was originally based on an article called Easy Automated Snapshot-Style Backups with Linux and Rsync, by Mike Rubel. If you think this is just another mysterious, dark-alley program, think again. This functionality is paid big bucks with commercial vendors, and rsnapshot is actively being used, even in bigger companies.

Performing differential, secure and remote backups is also possible, using rsync over ssh for transport.

Now rsync had a bug, where the --delete option had no effect. Quite annoying, given the fact that rsnapshot uses that option so that files, deleted after your previous backup, get deleted in the new backup archive you currently perform. Backups still roll, and you data is safe, but in directories where you e.g. have a daily dump of you database – with a filename containing the date – the old files never get deleted, and you turn up with all the dumps linked in every archive, instead of having just right dump in the right archive.

Luckily, as usual with Open Source, somebody analyses the problem and posts a patch. I filed bug 317418 in the Debian Bug Tracker with all that info.

It gets slightly more annoying when you realize that in Debian, this kind of bug is not considered critical, and never will be updated in Debian Stable. Very annoying if you standardize on Debian Stable and need the packages with their original functionalities. Luckily for me, in this case, solving the problem isn’t that difficult, as the patch is very tiny and modifying the source code is very simple, even without any C knowledge. It took some time to find out how to customize a Debian package, but thanks to some very helpfull people in the community, it turned out well.

If you experience the same problem, the updated package rsync_2.6.4-6.svg1_i386.deb can be found amongst my downloads, together with all the source. I hope this package was built like it should. If you have extensive knowledge on Debian packaging, as a Debian Devekoper or not, I’d be glad to hear your feedback, as this stuff is quite new for me.