In a nutshell: If your system is kind of older than sarge (as in installation date, updates done in the mean time don't matter), beware of 2.6.23.x or update your grub boot sector, which Debian doesn't do automatically on package installation.
Judging from the long list of exim4 bugs, especially #446036, I find myself between a rock and a hard place, and having to choose between staying with GnuTLS and accepting a probably continuing flow of technical issues, or moving over to OpenSSL, setting an example against GNU software, and probably generating a new flow of license issues.
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?
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.
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.
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.
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
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.
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.
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.
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.
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.