Gentoo: Mailman 2.1.11 incompatibility with Python 2.6

Mailman 2.1.11 (or earlier) isn’t compatible to Python 2.6. So if you upgrade your box to Python 2.6 without upgrading to Mailman 2.1.12 at the same time, you’ll run into troubles. And if you’re unlucky (e.g. when running some low-volume mailing lists), you might not even notice it.

One sign of such troubles is that messages sent to your Mailman mailing lists aren’t processed anymore. They simply seem to get “swallowed” by your Mailman server: Messages don’t reach the list, don’t get forwarded to subscribers and there’s no bounce or failure notice. For low-traffic lists, this might go unnoticed for several days or even weeks.

Another sign (that can easily slip through under certain, quite common circumstances) is that as long as you’re running Mailman 2.1.11 with Python 2.6, cron will, every 5 minutes,  send an error message to mailman@myhost.com with a subject similar to

Cron <mailman@myhost> /usr/bin/python -S /usr/lib64/mailman/cron/gate_news

and a content like

/usr/lib64/mailman/Mailman/Utils.py:32: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
import sha
Traceback (most recent call last):
File “/usr/lib64/mailman/cron/gate_news”, line 44, in <module>
from Mailman import MailList
File “/usr/lib64/mailman/Mailman/MailList.py”, line 51, in <module>
from Mailman.Archiver import Archiver
File “/usr/lib64/mailman/Mailman/Archiver/__init__.py”, line 17, in <module>
from Archiver import *
File “/usr/lib64/mailman/Mailman/Archiver/Archiver.py”, line 32, in <module>
from Mailman import Mailbox
File “/usr/lib64/mailman/Mailman/Mailbox.py”, line 21, in <module>
import mailbox
File “/usr/lib64/python2.6/mailbox.py”, line 19, in <module>
import email.message
ImportError: No module named message

That by itself wouldn’t be a big problem and probably get noticed quickly if you forwarded mailman@yourhost.com to your admin’s e-mail address. The problem arises if you happen to host a mailing list named “mailman” (which is often set up as a mailing list for testing and debugging). In that (not uncommon) case, all these cron error messages are forwarded to the “mailman” mailing list.  This makes about 288 messages per day that are queued in /var/lib/mailman/qfiles/in and won’t be delivered (due to the compatibility problem with Python 2.6).

Once you upgrade to Mailman 2.1.12 (and restart /etc/init.d/mailman), all these messages in /var/lib/mailman/qfiles/in will be queued by your MTA (e.g. postfix). This may seem like a strange loop problem in Mailman (or your MTA configuration), which is quite irritating at first.

Here’s how to solve the problem (you may need to adjust these steps to your settings/system paths):

1) Temporarily stop the Mailman service

/etc/init.d/mailman stop

2) Delete all the queued messages to/for mailman-owner@myhost.mydomain.com in your MTA’s mail queue. For postfix as MTA, the following script may be helpful: mailq by Dan Mick.

3) Delete all the cron-generated error messages in /var/lib/mailman/qfiles/in.

In order to determine these error messages, use Mailman’s show_qfiles command to view the message content, e.g.

/usr/lib64/mailman/bin/show_qfiles /var/lib/mailman/qfiles/in/longnumber.longnumber.pck

The best way to identify these messages is by filtering them according to their file size. Usually they have sizes around 1600 bytes. E.g. for a file size of 1635 bytes, try sth similar to:

cd /var/lib/mailman/qfiles/in

find ./ -size 1635c -exec rm {} \;

4) Once you’ve deleted all these cron error messages in Mailman’s in-queue, you can restart Mailman (/etc/init.d/mailman start). Mailman will then start delivering the remaining valid files in its in-queue. Your MTA/postfix queue looks normal again (i.e. there’s no more overflowing)!

5) Finally, you need to manually “discard all messages marked Defer” for the ‘mailman’ mailing list using the web admin interface (usually on https://myhost.mydomain.com/mailman/admindb/mailman or similar). Before discarding these messages, make sure you don’t discard any valid messages.

That’s it!

Thanks to Mark Sapiro AKA msapiro from #mailman @ irc.freenode.net for very useful hints and help!

P.S. Some other helpful resources in case of Mailman problems:

How to find running Mailman instances (qrunners)

How to integrate postfix and Mailman

Gentoo, Django and PyFacebook: Updated Ebuild

If you happen to use PyFacebook on Gentoo you probably noticed that djangofb.py didn’t create/copy any skeleton files for the Facebook application to be created (for an example how it should work, take a look at the PyFacebook tutorial).

In order to fix this, just download my update of the pyfacebook-9999.ebuild. This updated ebuild reflects PyFacebook’s move to GIT for versioning (from SVN), hence ensuring that you always use the latest available (‘official’) sources with latest fixes (among others, some changes to /pyfacebook/setup.py to fix the djangofb problem). I also recommend to watch the forks of PyFacebook for recent changes.

Gentoo: How to fix a broken Python installation

If your Python environment seems to be buggy or broken after a recent Python upgrade, it probably is. To fix it, simply execute the following command on your Gentoo box:

# python-updater -v

(note that this process takes quite some time to complete)

Additionally, you might want to make Gentoo check the dependency tree and rebuild broken packages (related to Python or other packages):

# revdep-rebuild

P.S. This is more or less a repost of an earlier post about python-updater.

WordPress 2.8.3: Quick-fix for admin lock-out security problem

Problem description (In WP 2.8.3 and earlier, the admin password can be reset remotely without WordPress generating a new one, locking-out the admin):

[Full-disclosure] WordPress <= 2.8.3 Remote admin reset password

For a quick-fix, see:

http://core.trac.wordpress.org/changeset/11798

i.e., in wp-login.php, replace the line

if ( empty( $key ) )

with

 if ( empty( $key ) || is_array( $key ) )


If your WordPress installation has been hacked already, here’s an emergency password reset script you can use to reset and regenerate your admin password.

A German explanation of the security bug and how to fix it can be found on heise online:

Lücke in WordPress ermöglicht Aussperren des Admins

[Update 20090812: Now that a security update is available, users are advised to update to WordPress 2.8.4]

Linux: Saving energy using auto-poweroff

I used to have a headless Linux LAN server that ran 24/7, i.e. even when I actually didn’t use it. Now, it powers itself off automatically as soon as it doesn’t detect any running workstations/notebooks (with dynamically assigned IP addresses) in the LAN.

Here’s how to do it:

In /usr/local/bin, create a new bash script named “shutdown_if_no_dhcp_client_in_lan” with the following content:

#!/bin/sh
# Shutdown the box if there aren't any (not ignored)
# DHCP clients in the LAN

# ignore the skype base station
ignored_macaddr="aa:bb:cc:dd:ee:ff"

# dhcp range starts at 192.168.1.$dhcpstart
dhcpstart=32

# dhcp range ends at 192.168.1.$dhcpend
dhcpend=46

for i in $(seq $dhcpstart 1 $dhcpend)
do
  # returns 0, if ip reachable. returns 1, if not reachable
  ping -w 1 -q 192.168.1.$i >/dev/null
  if [ "$?" = "0" ]; then
    # check whether this ip should be ignored
    if [ "`ip neighbor|grep 192.168.1.$i|grep $ignored_macaddr|wc -l`" = "1" ]; then
      echo "192.168.1.$i is reachable but ignored"
    else
      echo "192.168.1.$i is reachable and NOT ignored"
      # exit the program without shutting down the box
      exit;
    fi
  else
    echo "192.168.1.$i is NOT reachable"
  fi
done
# we didn't find any (not ignored) DHCP client in the LAN
# we can thus shutdown this box
echo "warning the users and shutting down the box in 5 minutes"
shutdown -h -P +5 Please save your work now!

(Adjust the script to your LAN environment)

In /etc/crontabs, add:

*/20  * * * * root /usr/local/bin/shutdown_if_no_dhcp_client_in_lan >/dev/null 2>&1

Now the LAN server will shutdown automatically after a while when no workstations/notebooks are running anymore. Note that this can happen 5 to 25 minutes after the last activity and isn’t fault-tolerant at all. The script can easily be improved however.

Gentoo Anti-Spam: iXhash Ebuild

As spam levels increased quite a bit lately, I made a Gentoo Ebuild for the iXhash SpamAssassin plugin by Bert Ungerer / Heise iX, Germany.

So far, it’s available on bugs.gentoo.org only. In order to install it, download

iXhash-1.5.5.ebuild

and put it in your local Portage Overlay.

YMMV, but it performs really well on my server (particularly for German spam which is difficult to catch without). Don’t forget to adjust the according penalty scores to your liking, though!

Gentoo: Greylisting for Postfix using Postgrey

Finally, I’ve had to enable greylisting for this domain due to ever increasing levels of spam. Fortunately, setting it up is very easy. For Gentoo and Postfix, here’s a nice walkthrough:

postfix greylisting on gentoo (postgrey) | andreas d.’s.

Let’s hope that this, in conjunction with other anti-spam measures, will do it for a while.

Non-spammers shouldn’t experience any problems due to this change, but if you do, please contact me using Skype (mettlerd), phone or SMS.

Gentoo ebuild for Lx-Office ERP 2.6.0 beta 1

Finally, I’ve created Gentoo ebuilds for Lx-Office ERP 2.6.0 beta 1 and its dependencies. Lx-Office is a fork of the server-based open source accounting solution SQL-Ledger and customized for the German market (and to some extent, the Swiss and Austrian markets).

A screenshot of Lx-Office ERP 2.6.0 beta 1 showing the XUL menu:

Screenshot of Lx-Office ERP 2.6.0 beta 1 using the XUL menu

And here’s a flash video of Lx-Office ERP 2.6.0 beta 1 showing the XUL menu in action.

Lx-System (the company backing Lx-Office ERP) and LINET Services host a public demo of Lx-Office ERP 2.4.3 (user: demo, password: demo).

To install Lx-Office ERP 2.6.0 beta 1 on Gentoo, follow these steps:

1) Set up a local portage overlay (e.g. at /usr/local/portage), if you haven’t done so already.

# mkdir -p /usr/local/portage

In /etc/make.conf, set

PORTDIR_OVERLAY=/usr/local/portage

2) Download lx-office-erp-2.6.0_beta_p1-r1_plus_dependencies.tgz and extract it to your local portage overlay

# cd /usr/local/portage
# tar xzvf lx-office-erp-2.6.0_beta_p1-r1_plus_dependencies.tgz

3) In /etc/portage/package.keywords, add the line

www-apps/lx-office-erp ~amd64

(or ‘www-apps/lx-office-erp ~x86‘, depending on the architecture of your machine)

4) In /etc/portage/package.use, add the line

www-apps/lx-office-erp vhosts

5) Install Lx-Office ERP on your system by executing

# emerge -av lx-office-erp

Depending on your current portage settings and installed ebuilds, you may need to unmask additional ebuilds.

6) Use webapp-config to link your Lx-Office ERP installation to a specific host, e.g. by executing

# webapp-config -I -h localhost -d lx-erp lx-office-erp 2.6.0_beta_p1-r1

7) Follow the steps displayed on the screen to setup and configure Lx-Office ERP. Some of these steps might be automated in a later release of the ebuild.

8) Have fun using Lx-Office ERP on Gentoo! :)

(These ebuilds are sponsored by my company Printscreen GmbH, dedicated to the developers of Lx-Office ERP and Gentoo and released for free use under the terms and conditions of the GNU GPLv2 license.)