Debian Gripes

Now, before you go flying off the handle about Debian being the greatest thing since sliced bread, let me give you a little history. I have been using Linux for over 10 years. While my first distro was Slackware, much of my time was spent as a Red Hat user (from RHL 4.2 onward). It wasn't until I took a new job in 2004 (who use Debian a lot) that I started working with Debian. The learning curve was rather easy due to my experience with Linux in the past. Over time, I started migrating personal servers from RHL and RHEL to Debian. At this point, I have no Red Hat servers, and one Fedora workstation tucked away in the corner. Don't get me wrong, I still like Red Hat; I just happen to like Debian more now.

That being said, Debian is not perfect. sarge made a lot of improvements over woody, but I still have some gripes. Some are trivial ("edit this /etc file to get the functionality that you see by default in every other distro"), but they are gripes nonetheless, and are even more annoying to make a single small change when you're talking about dozens or even hundreds of servers.


The Gripes

inetd

Good lord, why? At the very least, replace it with xinetd, which allows for /etc/xinetd.d, and avoid the headache that is multiple packages manipulating one file.

3.0 woody security support ending May 2006

Granted, woody was released July 2002, making almost 4 years of support, but if looked at another way, you're giving us only 1 year to migrate. In my organization, we had been using sarge for some workstations and internal servers for some time now, but we waited until sarge was marked stable to begin putting it into customer production use. Now we have less than a year to migrate woody machines to sarge. (And no, "just update your sources and do apt-get dist-upgrade" doesn't fly in most business environments.) I have a feeling after May 2006, we will have a company like Progeny stepping up like they did with the RHL EOLs.

Lack of an apt-get "freshen" option

For those not familiar with RPM, "freshen" allows you to say, "Here's a list of 50 packages. If any of these packages are installed, update them, but don't install the packages that don't already exist." The closest equivalent would be:

for i in package1 package2 package3; do dpkg -L $i && apt-get install $i; done

For some reason, whenever I mention this gripe, the users' answer always seems to be "apt-get upgrade". At what point did I say I wanted to upgrade ALL installed packages?

Release schedule

Ahh yes, the popular Debian gripe. My two cents: While I don't belive the "we will release on this date come hell or high water" attitude is effective, I think the current "ehh, whenever" attitude is worse. Pick a release date, try to hit it, and if you don't, it's not the end of the world. I would say 1.5 years between releases would be a good target.

rc.local, or lack thereof

Every other distro has an easy way to throw local startup changes in, but the Debian attitude is "just make a proper init.d script". In my world, sysv-rc would have an init script that checked for a flat file /etc/default/local.start and execute it, and similarly, /etc/default/local.stop during shutdown. This is similar to Gentoo's system.

Recently I went ahead and created such a package: rc-local_1.0-1_all.deb. This installs a script in /etc/init.d/rc-local that should execute at the end of bootup (and first upon shutdown). It uses /etc/rc-local.start and /etc/rc-local.stop, and symlinks /etc/rc-local.start to /etc/rc.local for all you Red Hat guys out there.

/etc/rc.local functionality has been added to etch.

No init scripts for the bincimap package

I know this is a bit specific, but you have to create your own init script after you install the bincimap package to make it function. It's not exactly the easiest. For example, here's the part of my script that starts the SSL (port 993) service:

start-stop-daemon --start --quiet --pidfile \
/var/run/tcpserver_bincimap_ssl.pid --make-pidfile --background --exec \
/usr/bin/tcpserver -- -R -H 0 993 /usr/sbin/stunnel -f -l \
/usr/sbin/bincimap-up -- bincimap-up-ssl --disable-starttls=yes \
--conf=/etc/bincimap/bincimap.conf --logtype=syslog -- \
"${authenticator}" /usr/sbin/bincimapd

A full example is here.

Modification of init scripts required for some packages

I'm on a roll here with the init scripts... Here's a quiz: You've just built qmail-src and installed qmail, and you want to enable the POP3 server. Do you:

Braindead /etc/inputrc

Debian is one of the few distros I've used where you can't type some stuff in bash, press "Home", and have the cursor go to the beginning of the command. This functionality is detailed in /etc/inputrc, but NOT ENABLED. I spent months wondering about this, thinking it was some sort of termcap weirdness.

Bash and title bar stuff (PROMPT_COMMAND)

On the topic of "stuff that is in every other distro's bash but not Debian's"... /etc/skel/.bashrc includes a line to set PROMPT_COMMAND to something sane, but only for xterm and xrvt. A noticable void is screen, so you get misleading xterm title bars while running in screen. Also void is this functionality in root's .bashrc, so if you "su" up, your xterm title bar is again left behind. This sort of functionality should really be in /etc/bash.bashrc anyways, which brings me to...

/etc/bash.bashrc isn't called from anywhere automatically

/etc/profile? Nope. /etc/skel/.bash_profile? Nope. Every system I've seen people build includes this at the end of /etc/profile:

if [ "$BASH" ]; then
. /etc/bash.bashrc
fi

Debian does not give you a back massage at your desk

Once again, Debian is dropping the ball. Though I hear they just added this functionality to sid.

Packages become useless over time

Debian's policy of not updating packages' upstream versions while in stable will make several packages useless over time, namely whois and antivirus programs. Because of this, you're almost sure to use something like backports.org in the future.

debian-volatile solved this, though it's not inserted in your apt sources during installation by default. I just thought I'd list a former gripe, for the record.

Debian's apache2 does not enable mod_deflate by default

Another small change that, frankly, I thought was enabled by default, but never bothered to check. Every browser in the last 6 or 7 years has been asking web servers capable of sending text gzip-encoded to do so. This functionality was available in Apache 1.x as a 3rd-party add-on, but is now distributed as part of the core distribution in 2.x. But it's not enabled by default in sarge. To do so:

cd /etc/apache2/mods-enabled
ln -s ../mods-available/headers.load .
ln -s ../mods-available/deflate.load .
cat > deflate.conf <<'EOM'
<Location />
  # Insert filter
  AddOutputFilterByType DEFLATE text/html text/plain application/xhtml+xml \
    application/xml text/xml

  # Netscape 4.x has some problems...
  BrowserMatch ^Mozilla/4 gzip-only-text/html

  # Netscape 4.06-4.08 have some more problems
  BrowserMatch ^Mozilla/4\.0[678] no-gzip

  # MSIE masquerades as Netscape, but it is fine
  #BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

  # NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
  # the above regex won't work. You can use the following
  # workaround to get the desired effect:
  BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

  # Don't compress images (not needed if only compressing text)
  #SetEnvIfNoCase Request_URI \
  #  \.(?:gif|jpe?g|png)$ no-gzip dont-vary

  # Make sure proxies don't deliver the wrong content
  Header append Vary User-Agent env=!dont-vary
</Location>
EOM
/etc/init.d/apache2 restart

Ryan Finnie