Ralf’s Blog

After I had upgraded my server to Debian 5.0, I found that I could no longer log in via IMAP. I turned authentication debugging on by changing /etc/courier/authdaemonrc as follows:

DEBUG_LOGIN=1

This did not reveal any problems. Here’s an excerpt from mail.info:

authdaemond: received auth request, service=imap, authtype=cram-md5
authdaemond: authmysql: trying this module
authdaemond: cram: challenge=[...], response=[...]
authdaemond: cram: decoded challenge/response, username ‘user@example.org’
authdaemond: SQL query: SELECT username, crypt, clear, uid, gid, pop, “”,
  “”, realname, “” FROM users WHERE username = ‘user@example.org’
authdaemond: cram validation succeeded
authdaemond: Authenticated: sysusername=<null>, sysuserid=1000,
  sysgroupid=1000, homedir=/home/user/var/mail/example.org/user,
  address=user@example.org, fullname=Joe User, maildir=<null>,
  quota=<null>, options=<null>

Even though all seemed fine, Thunderbird complained about “server doesn’t support secure authentication.”

So I telnetted into my IMAP server by issuing telnet localhost imap and manually logged in as follows:

a login user@example.org thePass

Now I noticed immediately what was wrong:

* BYE [ALERT] Fatal error: Account’s mailbox directory is not owned
  by the correct uid or gid:

The solution is that Courier now by default performs stricter checks on the “sanity” of your setup. I changed /etc/courier/imapd as follows, and all was fine again:

IMAP_MAILBOX_SANITY_CHECK=0

After I had upgraded to Debian 5.0 SVN told me its database was broken. I googled for this problem and quickly found the solution:

svnadmin recover /var/lib/svn

This did the trick!

When I upgraded to Debian 5.0 lately I noticed that there is no Gallery2 package anymore in Lenny. So I asked the Debian maintainer about this.

Here’s what he replied:

Gallery 2 is not available in Lenny due to large amount of differences between the previous version and 2.3-1 from unstable. The release team and I decided not to include Gallery 2 in stable due to this disruptive change late in the release process. The gallery2 package from sid can be installed via pinning.

WTF?!

I was startled today by a message in syslog that seems to point to a problem with my RAID1 volumes:

Mar  1 01:13:54 server mdadm[961]: RebuildFinished event detected on md device /dev/md3, component device  mismatches found: 512

This value is reflected in the following counter:
root:/etc/mdadm# cat /sys/block/md3/md/mismatch_cnt 512

I tried to clarify this by googling around, but I found no definitive answer whether this is an actual problem or not. However, I found a way to resync the MD components so that no mismatches remain:

root:/etc/mdadm# echo repair >> /sys/block/md3/md/sync_action

After you execute the repair you will notice that the counter shows the same number of mismatches again:

root:/etc/mdadm# cat /sys/block/md3/md/mismatch_cnt 512

This was to be expected — because the repair corrected (and thus encountered) this number of mismatches. So, if you force a check again, the counter should be down to 0:

root:/etc/mdadm# echo check >> /sys/block/md3/md/sync_action
root:/etc/mdadm# watch cat /proc/mdstat
[wait until check is finished]
root:/etc/mdadm# cat /sys/block/md3/md/mismatch_cnt
0