Zugschlusbeobachtungen

20% [1 Packages 24266/117kB 20%]                                    1689B/s 54s

That's actually worse than it was with the old box.

Today, over the day, access to security.debian.org was intermittent as usual in the last few weeks. But this afternoon, things suddenly got much worse. All my cron-apt installations on and behind firewalls began to yell at me that securiy.debian.org was completely unreachable.

But. Wait. I don't know that IP address. I don't know the host name tartini.debian.org.

Once again, the solution was found in Joey's Blog. Apparently, security.debian.org was moved to the new host, and everything is fine.

Nearly everything.

UPDATE: There has been an Announcement, but not where I would have expected it. The IP address hasn't been mentioned there, though, and that announcement wasn't signed.

UPDATE: There has been one more change to the IP addresses of security.debian.org: It now seems to be round-robin DNS of three hosts. While this is now a real advance compared to the old situation, it has - again - been unannounced to the public. And I get a free trip around my firewalls for the second time in 24 hours. Thanks, guys - I'd surely be twiddling my thumbs otherwise.

Vor einem Monat hat ajt Usertags und User Categories angekündigt.

Damit wird die Behandlung komplexer Packages im BTS einfacher, weil man eigene Struktur in die Bugreports bringen kann. Hoffentlich reicht das Featureset, um meine unabhängig vom BTS im Debian Wiki geführten Webseiten zur Bugklassifikation in die Tonne treten zu können. Die Zeit wird das zeigen.

Jurij Smakov et al have published the Debian Linux Kernel Handbook, which will help in documenting the internals of the Debian Linux Kernel build process. The document is still work in progress with a lot of sections missing, but it's a giant step in the right direction.

if [ -n "$NOISE" ]; then
        NOISETMP=`tempfile --directory "/tmp" --prefix "aidenoise"`
        NOISETMP2=`tempfile --directory "/tmp" --prefix "aidenoise"`
        sed -n "1,/^Detailed information about changes:/p; "$LOGDIR/$LOGFILE" | grep "^\\(changed|removed|added\\):" | grep -v "^added: THERE WERE ALSO [0-9]\\+ FILES ADDED UNDER THIS DIRECTORY" > $NOISETMP2

        if [ -n "$NOISE" ]; then
                < $NOISETMP2 grep -v "^\\(changed|removed|added\\):$NOISE" > $NOISETMP
                rm -f $NOISETMP2
                echo "De-Noised output removes everything matching $NOISE"
        else
                mv $NOISETMP2 $NOISETMP
                echo "No noise expression was given."
        fi
fi

Too bad that a shell doesn't complain about unreachable code. I must have smoked some very strange stuff when submitting that patch to aide years ago.

After taking over aide co-maintainership in January and successfully convincing Mike to put the project on alioth, I have done some work on aide and have uploaded 0.10-8 on September 18 and 0.10-9 on September 27 to experimental.

These two versions acknowledge the two NMUs we recently had and fix some issues that I thought would be worth fixing. Please test. I plan on uploading to unstable on a week, if no bad goofs surface during the experimental phase.

Unfortunately, aide's upstream is quite dead, so it is unlikely that any upstream bugs will get fixed without you submitting patches.

Next step will be convincing Mike to allow creation of a pkg-aide-maintainers mailing list for the Maintainer:-Field, so that messages sent to the maintainer field instead of aide@packages.debian.org can reach me as well.

The recently released security update of Xfree86 for sarge has made something happen what I have been fearing for years: Gazillions of systems downloading the update have slashdotted security.debian.org, which is now sluggishly responding for the second day in a row.

This doesn't make my cron-apts happy, which in turn bury me under error message e-mails. Ungood, since one might miss an important update in the avalanche of "cannot pull packages.gz from security.debian.org" mails.

This experience has shown that having security.debian.org a single point of failure is not as good of an idea as we thought. I am afraid that the security team will have to reconsider and to finally establish mirrors for security.debian.org to spread the load.

Update: After reading much of the discussion about the topic, I find it strange that nobody besides me blogged about the issue, but we actually have an official announcement about the sdo outage. Very good.

Establishing a mirror network for sdo is not quite easy since unlike for the main archive, we cannot use "randomly offered" mirroring services, but we need the sdo mirrors under our control. Main reason for this is that we need sdo mirrors to be fast, because people would begin to complain that an update has not yet hit the mirrors after the advisory has gone out. Already today, it frequently happens that the cron-apt processes have detected an update quite some time before the release of the actual advisory, and you don't want the process to take even longer. Even push mirroring is way too slow.

I like the idea of not establishing mirrors, but caching proxies distributed around the world, so that the issue of a mirror pulse simply vanishes: The proxy would fetch the update on the first incoming request, and deliver from its local cache for some time before looking on the actual sdo server again whether the file is still current. Neat idea.

Found on exim-users:

My advice as a new exim4 / debian user myself is to read the documentation first. Then read the documentation. (There is a lot of it.) Read the documentation, or some people might point out that you have not read the documentation.

Thanks, Jeremiah Foster, this has just made my day.

After using the unofficial kde 3.4 packages from alioth for some months, I have migrated back to Debian unstable on the weekend, and my main work machine is now plain sid again. That means that I am running x.org and official transitioned kde 3.4, and can finally report bugs against the official setup again. So, kde and x.org people, brace for impact of bug reports and keep up your excellent work.

aba blogs about his wishes for post-processing of the output of cron jobs

Well, I have a wishlist as well (of course all items should be configurable):

• Save cronjob output to a file
• Append that output to log files on the system, after applying regexp filters
• Send E-Mail to a number configurable addresses
• Have a list of regexps that the output is filtered through before being included in the e-mail
• Allow the preceding operation to be done multiple times for a single mail, allowing to include different "verbosity levels" in a single message to have the admin decide which to read
• Allow certain parts of messages to be tacced (printed with line order reversed)
• Modify message subject if certain conditions are met (for including tags like [OK], [ALERT] etc)
• Allow arbitrary texts (preferably using macro expansion) in between message parts

This is only what immediately comes to my mind. I will keep this wishlist updated, and have a Wiki Page.

In my Wiki, I have published two old articles (written in German) about Building Debian Packages and Building Debian Backports after adapting them to today's situation.

Ich habe in meinem Wiki zwei alte Artikel über den Bau von Debian-Packages und die Erstellung von Backports von Debian-Packages in aktualisierter Version veröffentlicht.

Looks like there is no passwd-compatible crypt(1) for the command line. htpasswd, unfortunately, uses a different algorithm.

This short perl script might be a replacement:

#!/usr/bin/perl -w

use strict;

while(<>) {
    my $seed = `apg -a 1 -m 8`;
    chomp;
    print crypt(&#8220;$_&#8221;, &#8220;\\$1\\$$seed&#8221;). &#8220;\\n&#8221;;
}

Or do we have something better already in the distribution?

Update: looks like mkpasswd (from the whois package, whatever makes it belong in there) does the job quite nicely, but the script shown above takes care of automatic salt creation as well. Any ideas how to do that more elegantly, without requireing apg?

A lot of recent systems I have to work with have Tigon3 ethernet interfaces, which behave strangly when used under Linux in settings that are non-trivial, networking-wise.

While browsing Debian Planet, I happened to have the desire to comment on one article innutmeg's Blog. What I found was a blog I couldn't comment on, but one whose format I know pretty well: It looks suspiciously like a Debian changelog. nutmeg then told me that he uses a script from Romain Francoise which indeed builds an RSS feed from a Debian changelog to feed his blog to Debian Planet.

This is something I love Debian for. Use existing tools for new challenges. Well done.

I still like s9y more, though.