Skip to content

Usertags im BTS

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.

My daily wtf. today: cron.daily/aide


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.

aide 0.10-9 in experimental

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.

Continue reading "aide 0.10-9 in experimental"

security.debian.org overloaded

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.

The six dumbest ideas in Computer Security

Marcus Ranum schreibt über die sechs dümmsten Ideen im Berich der Computersicherheit (The six dumbest ideas in Computer Security.)

Wenn ich ihm auch nicht in allen seinen Thesen vorbehaltlos zustimmen kann, lesenswert ist der Artikel allemal.

Gefunden: fast überall.

Continue reading "The six dumbest ideas in Computer Security"

my notebook pure unstable again

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.

Continue reading "my notebook pure unstable again"

Versatile Post-Processing for cronjob's output

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.