Update Madness?! This is Debian!

12 02 2008

I really like Debian. Or (K)Ubuntu which I actually use. And of course apt/dpkg. Great stuff. Almost as good as Portage, with the unbeatable advantage that you don’t have to compile all that stuff on your own :)

But can somebody please explain something to me?

Why does a little update in KDE packages always trigger such an update madness?

Like currently in kdepim:

debian/control: Added Conflict/Replaces on ksync for kitchensync. “ksync” gets shipped with kitchensync now. (LP: #133944)

That’s only two packages. Why do I have to update all the stuff coming from PIM? Actually, why do I have to update at all if its only metadata which was changed?

Or in kdebase:

* Stable release update, support new Flash in Konqueror
* Add kubuntu_9917_flash_xembed.diff, adds xembed support to Konqueror
* Add build-dep on libglib2.0-dev
* Closes LP: #184149

Great, flash should work again. But why do I have to download kdebase-data for that?

One of the reasons Gentoo switched to split ebuilds for KDE was the advantage that you didn’t have to download the whole package again just because only one small app like ksync was changed. Why does Portage manage to do that and the good olde dpkg not? Or does that only happen in gutsy-proposed? Can somebody enlighten me?



Using dnsmasq and resolvconf with Linux-VServer

20 12 2006

I take care of a server running under Linux-VServer. LVS has a few weird gotchas, network-wise. Missing IPv6 support is not the worst. I mean, why IPv6 if I can’t even configure the IPv4 interfaces? And iptables doesn’t work. Oh, and I don’t even have a lo interface. Crap.

Yeah, I know the technical reasons for all this, its supposed to get better with NGNET, but its still weird.

Anyway, on that box runs a SpamAssassin, so at some point I decided to install dnsmasq as a caching nameserver (thats always a good idea if you have DNSBL and stuff enabled in SpamAssassin). Most the network config is pushed in from the host, just the nameservers had to be configured manually. I decided to configure resolvconf to do the name service stuff because it takes care that all servers (except SpamAssassin, seems like I’ll have to write a script for that when I’m in the mood) are restarted/reloaded when the DNS config changes.

Remember, there’s no lo device and so also no loopback address. dnsmasq has to listen on (one of) the VServer’s IPs. The file /etc/dnsmasq.conf looks like this (with a different IP address):

listen-address=5.4.3.2
bind-interfaces
query-port=1053
domain-needed
bogus-priv
cache-size=1024
no-negcache
log-queries

Because dnsmasq’s init script always adds 127.0.0.1 and doesn’t grep for the option listen-address (got to write a patch for that, too), I had to hard-code this IP in /etc/resolvconf/resolv.conf.d/base, too:

nameserver 5.4.3.2

I also switched to the ORSN resolvers because the name servers hosted by the provider seemed to be chronically overloaded and dropped requests like hell. I first added these via resolvconf -a, but see below.

It looked all very fine and worked well, until the admin of the host machine had to reboot the box(es). Suddenly dnsmasq refused all requests (I noticed this only after a few days). After some digging I found out that the file /var/run/dnsmasq/resolv.conf, which is supposed to be a filtered copy of the actual one, was empty. The simple reason was that resolvconf didn’t know anything about the two nameservers I added before.

To tell resolvconf about the desired nameservers I had to add the host-configured interface as a manual interface in /etc/network/interfaces:

auto eth0:dev
iface eth0:dev inet manual
dns-nameservers 217.146.139.5 62.157.101.211

This seems to work fine now, lets wait for the next reboot…