Zugschlusbeobachtungen

My systems run cron-apt with an hourly rhythm, running off ftp2.de.d.o. Once in a while, some of them complain about invalid signatures on release files:

CRON-APT LINE: /usr/bin/apt-get update -o quiet=2
W: GPG error: http://debian.debian.zugschlus.de lenny Release: The following signatures were invalid: BADSIG A70DAF536070D3A1 Debian Archive Automatic Signing Key (4.0/etch) 
W: GPG error: http://debian.debian.zugschlus.de sid Release: The following signatures were invalid: BADSIG A70DAF536070D3A1 Debian Archive Automatic Signing Key (4.0/etch) 
W: You may want to run apt-get update to correct these problems

This usually happens in the late evening CEST. In the next cron-apt run, things are fine again. What's going on here? Is this part of a mirror update process where the Release and Release.gpg files are inconsistent?

Any idea how to get rid of these error messages?

Recently, Jurij Smakov resigned from maintenance of the Debian torrus packages. This leaves me as the sole maintainer, and I need help.

Continue reading "co-maintainer sought for torrus"

The DDs reading this might know the situation: You are subscribed to a gazillion of mailing lists, and spend quite some time answering questions of people using your packages. That's fine, service to your users. Occasionally, users take great pains in finding out a personal mail address (for example, by googling, and finding the webmasteridiot mail address on my personal web page) to ask their question in private e-mail. This prevents the answers from showing up in mail archives and deprives the public of a possibility to find a solution to this question themselves in the future.

Continue reading "From the personal Inbox of the exim4 maintainer"

I have uploaded exim4 4.67-2 to experimental. Lots of changes and improvements. Quite some changes have gone into the Debconf stuff (for example, the split/unsplit config question is not asked first any more), and into update-exim4.conf (including input sanitazion, transformation of input to lower case, and getting rid of the DEBCONFsomethingDEBCONF stuff in the configuration).

I'd like you to test the experimental package before I upload to unstable (probably on sunday). Please report your findings.

Continue reading "Please test exim4 from experimental"

Dear Lazyweb, can you please explain how to properly credit a frenchman in a changelog without mangling his name? I do not consider it acceptable to use a different editor, make sure that my terminal was started with the proper environment variables set (run-time configuration does not seem to do it) before I can correctly enter non-english characters in a text mode editor.

I guess I need to make the UTF-8 transition on the desktop. Are there any docs about how to do this?

It is just incredibly frustrating to spend an hour on IRC just to create a changelog entry for a patch that took a minute to make and five minutes to test.

One of my dedicated servers was in bad need of major LVM surgery today. Since the rescue system delivered with the server by the housing provider suffers from lack of LVM support, I needed to pull a creative stunt with grub and grml to accomplish this.

Continue reading "using grml to prepare LVM surgery"

After asking for useable CA Software, I have finally settled on using EasyRSA. This is what I did to come across the packaging shortcomings of EasyRSA in Debian.

Continue reading "EasyRSA on Debian for an OpenVPN CA"

Description: SMTP command-line test tool
 swaks (Swiss Army Knife SMTP) is a command-line tool written in Perl
 for testing SMTP setups; it supports STARTTLS and SMTP AUTH (PLAIN,
 LOGIN, CRAM-MD5, SPA, and DIGEST-MD5). swaks allows to stop the SMTP
 dialog at any stage, e.g to check RCPT TO: without actually sending a
 mail.
 .
 If you are spending too much time iterating "telnet foo.example 25"
 swaks is for you.

A very important tool which makes debugging e-mail a breeze. A must for every mail admin.

Ich sitze hier gerade in einem Vortrag über Open Source im Auswärtigen Amt. Der erste Satz, den ich - knapp zehn Minuten zu spät kommend - auf der Folie sehe, ist "Debian als führendes Betriebssysem".

Auf der nächsten Folie steht dann "Nagios, Munin als Ablösung für HP OpenView". Ich glaube, mein Tag ist gerettet.

Dear Lazyweb, in late 2001, I bought a shiny new computer to replace my VHS VCR and to finally help me in getting my last 200 hours worth of music form analog audio tapes into the digital domain. I have to admit that I have failed to do this.

While the TV ambitions were originally spoiled with the rotten Windows TV software that came with the Hauppauge PVR PCI card, audio with windows used to work rather decently. Until I decided to ditch Windows and to use Linux. Which looks like a mistake. Not even the audio stuff works any more.

I have bought a new TV card and a new sound card, but all I currently get (with the old sound card, btw) are audio recordings that sound way too fast.

Continue reading "Recording digital audio with Linux impossible?"

I recently had an issue where a remote host would frequently run out of memory after a number of processes had been invoked from remote. I looked in the wrong direction first, but finally found out that each process invocation leaves two sshd processes hanging around, which are eventually exhausting the memory on the box.

Next step was finding out what happened for the sshd processes not to properly terminate. Eventually, I remembered that the incoming ssh connections were not invoked directly, but via a third host with "proxycommand ssh other-host socket %h %p". Looking on other-host quickly showed a number of socket processes being around, and killing them made the sshds on the low-memory host vanish as well.

Short-term remedy was therefore to set ClientAliveInterval in the low-memory host's sshd configuration.

I then searched for reasons why ClientAliveInterval is not set by default at least in Debian's sshd configuration. I didn't find a reason and proceeded to file a wishlist bug request againnst openesh-server for this option to be set by default.

Before filing this bug, I routinely visited the BTS, just to find out that the bug was already filed. By me. One year and 285 days ago. And that the openssh maintainer(s) didn't even bother to reply to it yet.

Guys, _this_ is a textbook example how to discourage people from filing Bugs against your packages. Please, give them at least the appreciation of a short ACK if you don't get around to fixing the bugs in reasonably short time. Having a bug rot away uncommented and unfixed in the BTS for two years is simpy not acceptable. Yes, that goes even for a wishlist bug.

Dear Lazyweb, dear Santa Claus,

One thing I wish for exim is a patch for Exim Bugzilla Issue #66, which will incidentally fix Debian Bug #244724, which has become a recurring issue in various complex ISP configuration schemes.

A patch solving this would add an option to an SMTP transport which allows the transport to set the authentication credentials instead of the authenticator. The transport still knows the host name given to it and can look up the right authentication credentials, while the authenticator only knows the IP address that we are connected to and thus needs to rely on reverse DNS information to look up the credentials. Which leads to numerous kinds of confusion regarding CNAMEs and broken reverse DNS on the ISP side.

So, please dear Santa, give me a patch for that. It shouldn't be too hard to do.

Yesterday, Philip Hazel released exim 4.64. I have just uploaded the packages to Debian experimental. If you want to try the lastest and finest exim, please check out the packages.

Unfortunately, the release is too late for etch. Debian etch will release with exim 4.63. I mean, unless the release team decides to bend their rules very badly, which I really do not assume.

I have uploaded vmware-package to Debian experimental (contrib). While it waits in the NEW queue, the package is available for download from here.

vmware-package contains packaging for the kernel modules of Vmware and VMware Player, and make-vmpkg, a script that takes the appropriate upstream tar balls (vmware-any-any-104 and vmware-player 1.0.2, which have to be obtained by the package user and are of course not included), adds the packaging data and builds the .deb packages, which are of course non-distributable.

The vmware-kernel-source .deb created by make-vmpkg can then be used with module-assistant or make-kpkg to build a .deb that contains the modules suiteable for a given kernel and a given userspace application.

There are still a number of issues in the resulting vmware-player Debian packages, but it is useable. I am interested in sharing the load to improve the package with other people who'd want to spend time on evil non-free software without being paid. A list of currently pending issues is included in README.Debian in the package.

Andreas, I am not a nice guy. I am only lazy. If the change to exim4 (it now displays a debconf note to everybody who tries do dpkg-reconfigure exim4, -base or a daemon package telling them to dpkg-reconfigure exim4-config) saves #debian from answering the question "how do I reconfigure exim4, dpkg-reconfigure exim4 does nothing!" twice a day, it is a good change.

I basically agree with you that people who not read the minimum basics of documentation are a nuisance, but they're unfortunately real. You need to hurl the docs into their faces. And even then they're going to ignore them and google for answers instead. And on google, they're going to find wrong or outdated docs.