The Lenny version of the spamassassin package contains a regular expressions that considers as coming from the future mails dated in 2010. Starting from a couple of days ago, that has increased the possibility of false positives.
More information about that can be found in some blog posts such as this one and in the Debian BTS, bug #563245.

If you are running spamassassin on a Debian machine, you should probably upgrade it to avoid false positives. That can be easily achieved using the volatile version of spamassassin 3.2.5-2+lenny1.1~volatile1. More information about this update and instructions of how to update in this announcement from the debian-volatile-announce mailing list.

Generally, it is a good idea to have a volatile line in your sources.list. Read more about the debian-volatile project in their website.

Unstable users only need to make sure they update to the latest version available in the archive 3.2.5-7.

Contributed by: Stefano Zacchiroli

The MirBSD Midi-ISO (bi-arch manifold boot) and NetInstall for both i386 and sparc have been upgraded to the 20091226 snapshot (sorry for the delay). A separate news announcement will be done when a full ISO (MirBSD + MirGRML) is done. Other than that, I have fixed a couple of things all over the place, jupp for example. The planned release of mksh R39b is still not done though, as I m only human as well, and too much hacking isn t something one can do without relaxing some in between. On the Debian front, my RCBD #1 was continued, here s #1 results:

• Carry over from day #1
• bug #552791 acorn-fdisk Copyright file does not contain verbatim copy of the license or a pointer to one
• bug #562647 gidentd Does not work with ipv4 after recent change in netbase
• bug #558812 dietlibc incorrect license in debian/copyright
• bug #531937 autossh FTBFS on mipsel due to missing -fPIC
• New ones
• bug #563522 acorn-fdisk cleanup patches
• bug #563525 gidentd cleanup patches

Explanations: I did go overboard during the first patching session, but I suppose this is what the NM learning period is for too. The autossh maintainer said thanks and will probably integrate my patches, so I don t need to NMU. I could close the dietlibc bug. The other two didn t look as good, I had to separate the fix for the RC bug (and other required fixes, such as ftp-master rejects there were none though) and my other fixes; I submit the former as NMU diffs again and pointed Zack to the .dsc files, and opened the aforementioned two new bugs with the rest of the diffs, so the proper maintainers can take and apply them. There s questioning if gidentd should be removed (see the PR for more); the acorn-fdisk upstream (arm-fdisk it s called there) is not actively developing but will receive patches; the autossh maintainer said thanks but I didn t yet hear back from upstream. The binutils as intel_mode bug was fixed upstream and in experimental for my case, but I had to reopen things because the variant documented in binutils-current still doesn t work, so others (who use the new, more intel-like, syntax) don t run into it. Luk sent me a request to do more mipsel-FTBFS-due-to-toolchain-bugs workarounds. Will do (but can t promise to do so before the upcoming BSP. Robert Millan incorporated something like manifold-boot into GRUB 2, after I described it to him (the debian-bsd@ people are currently sorting out some heisenbugs with it, though). Now there s three variants (but then, this helps spotting bugs that don t appear in all implementations). sendmail 8.13.4 is out, I wonder when OgreBSD will upgrade I could do it myself again, but this time it s not that urgent. Still waiting for the TLS extension, though

After modernizing all font packages maintained by the pkg-fonts team (dropping defoma, source v3, etc.), I'm now investigating (with the help of other pkg-fonts team members) the list of ttf-* packages that are *not* maintained by our team. It seems that several of these suffer from low interest from their respective maintainers, so that task will often involve checking whether the said font is still wished in Debian, then talk with the maintainer if there is still one to convince him her to maintain the package collaboratively....or adopt the package when it is clearly abandoned. As of now, I already imported 4 ttf-arphic-* packages in our SVN and I'm working to modernize them. Dear readers, please feel free to point me to good candidates for this. Otherwise, I'll process the output of "apt-cache search -n ttf-" alphabetically...

If you ever tried to determine what patches other distributions apply to some package you are interested in, you might have come to the same conclusion as I: It is quite an impudence how those are presented. If you don't give up, you end up with programs or scripts to extract many propietary source package formats, more VCS systems installed than you think there should exist. Thats when you start to love the concept that every Debian mirror has next to each binary package the source in a format that you can extract the changes easily with only tools you find on every unixoid. And that's why I love the new (though in my eyes quite misnamed) "3.0 (quilt)" format, because that makes it even clearer and easier. Sadly one problem remained: How to generate and store those patches? While you can just use patches manually or use quilt to handle those patches and store the result in a vcs of your choice, the newfangled VCSes (especially git) became quite good at managing, moving and merging changes around, so it seems quite a waste to not be able to use this also to handle those patches easily. While one can either use git to handle a patchset, by storing it as a chain of commits and using the interactive rebase, or using git to store the history of your package, doing both at the same time is tricky and not resonably doable with git provided porcelain. Thus I wrote my own tool to faciliate git for both tasks at the same time. The idea is to have three branches: a branch storing the history of the your package, a branch storing your patches in a way suitable to submit them upstream or to create a debian/patches/ directory from, and an branch with the upstream contents. I've an implemenation which seems to already work, though I am sure there is still much to improve and many errors and pitfalls still to find. Thus if you also like to experiment with handling patches of a debian package in git, take a look at the manpage or the program at git://git.debian.org/~brlink/git-dpm.git
(WARNING: as stated above: alpha quality; also places are temporary and are likely to change in the future).

RCBW - #17 Given that my "most blogged" Debian activity since last summer has been RCBW, what else could be my first post of 2010 if not a RCBW update? With further ado, here are this week squashes by yours truly:

• bug #559898 - flowcanvas - fixed in unstable, tag as needed
• bug #562503 - man-db - downgrading severity (RC-ness was in zlib, which is now fixed)
• bug #541610 - docbook2odf - switch dep away from (now gone) libxml-sablot-perl
• bug #528088 - ttf-aenigma - fonts are actually free, as detailed in debian/copyright
• bug #544113 - tiger - remove dep on essential package (bonus: misc deps/debhelper fixes)
• bug #561466 - ttf-beteckna - rebuild against fixed defoma (thanks Julien Cristau who spotted a wrong fix of mine)
• bug #561470, bug #549987 - halevt - add missing dep on policykit (bonus: QA upload with misc fixes)

No particular remarks, but a long overdue tip of the week: the turmzimmer BTS interface is a great tool for bug squashing. Still, it has a issue with comments which can slow down some activities, but which you can help getting better! First of all you should know that comments are per-package and not per-bug (which might not be obvious, especially since often packages listed on the page have just one bug per-package). That means that you should generally mention the bug you are referring to when you post comments, unless the comments are really package-specific. Additionally, old comments are persistent, so you might get baffled by old comments that "invalidate" current issues. So, if you notice a comment that predates the actual bug numbers, please remove the comment by editing it and stating "no comment" in the form. Ah, happy new year (in case you care about sharp, calendar-based time partitions).

This is primarily a bug-fix release, cleaning up some issues introduced in 2.3.0. Specifically, it fixes collection of the contents of *.a files, fixes the severity of spelling errors in man pages, properly parses Depends starting with a newline for weak-library-dev-dependency, and fixes the spurious display of archive areas in some cases in the HTML reports. This release also includes Raphael Geissert's work to eliminate unpack level two (which means having a full unpacked copy of the package) in favor of a collection script that does this and a new type of collection that's automatically removed after processing. This is the first step towards eliminating the internal Lintian distinction between unpack and collection scripts and implementing both using the same mechanisms. As usual, there are a variety of other fixes and improvements, but there shouldn't be any major user-visible changes in this release. Note that, following advice from Joey Hess, Lintian now warns about missing $ misc:Depends dependencies for any package that uses debhelper, since any debhelper script may start adding dependencies there. This was already mostly in place in 2.3.0, but is the source of a large number of new warnings in the archive.

I've spent the past few days trying to get MMS to work on the N900.

EDIT: Seems frals has managed to beat me! read more

Two weeks after the Rcpp 0.7.0 release, Romain and I are happy to announce release 0.7.1 of Rcpp. It is currently in the incoming section of CRAN and has been accepted into Debian. Mirrors will catch up over the next few days, in the meantime the local page is available for download too. A lot has changed under the hood since 0.7.0, and this is the first release that really reflects many of Romain's additions. Some of the changes are

• A new base class Rcpp::RObject that replaces RcppSexp (which is still provided for compatibility); it provides basic R object handling and other new classes derive from it.
• Rcpp::RObject has real simple wrappers for object creation and a SEXP operator for transfer back to R that make simple interfaces even easier.
• New classes Rcpp::Evaluator and Rcpp::Environment for expression evaluation and R environment access, respectively.
• A new class Rcpp::XPtr for external pointer access and management.
• Enhanced exception handling: exception can be trapped at the R even outside of try/catch blocks, see Romain's blog post for more.
• Namespace support with the addition of a Rcpp namespace; we will be incremental in phasing this in keeping compatibility with the old interface
• Unit test for most all of the above via use of the RUnit package, and several new examples.
• Inline support has been removed and replaced with a Depends: on inline (>= 0.3.4) as our patch is now part of the current inline package as mentioned <here.

As before, fuller details are in the ChangeLog on the Rcpp page.

Today, since a year of the first commit to the git repository, I released Cupt 1.5 and uploaded it to Debian unstable.

Notable changes since the last blog post about cupt 1.2:

1.3: various speed and RAM usage improvements
1.5: priorities for download protocols and download methods, download methods are now pluggable; bash completion for 'cupt' program

Have fun :)

Most readers probably have installed Debian version 5.0 (Lenny) or an older version and are using shadow passwords with the md5 hash algorithm. This is not bad but not good enough. You can find out the details by looking at /etc/passwd and /etc/shadow (as root). The second column in these files should be a simple character x in /etc/passwd and a string like

$1$biMft/Pr$Lo3zPpiItdLZrzx8t/mTy0

in /etc/shadow. The number 1 between the 1st and 2nd $ sign means md5, the following string biMft/Pr is the salt and the last string Lo3zPpiItdLZrzx8t/mTy0 is the actual hash for the password ('testmd5' in this case). The salt is used to avoid attacks based on precomputed hash tables.

The package pam has switched to the stronger sha512 algorithm in version 1.1.0-2 on 31st august 2009. Look for a line like

password        [success=1 default=ignore]      pam_unix.so obscure sha512

in file /etc/pam.d/common-password if you have installed at least version 1.1.0-2. After changing the password I have the new password string

$6$qjc5gFgK$vaz/gLKMyDuhsVOU2oVIkDZrD0.reJM.2Ft3CMEoAsjN/lenvHC2ls6g/MY1ZaYaYBP3HHDOxel1dvTerl17q1

in /etc/shadow. The number 6 means sha512 and the hash

vaz/gLKMyDuhsVOU2oVIkDZrD0.reJM.2Ft3CMEoAsjNlenvHC2ls6g/MY1ZaYaYBP3HHDOxel1dvTerl17q1

is much longer than before.

The pam_unix module in combination with the sha algorithms allows specifying the number of rounds for hashing the password with the argument rounds=... which defaults to 5000. My current machine needs about 20 milliseconds to hash my password. That can be tested with the command

/usr/bin/time -f %U su testmd5 -c true

I have changed the number to 1 million

password        [success=1 default=ignore]      pam_unix.so obscure sha512 rounds=1000000

to make brute force attacks more difficult. After changing the password again the string is

$6$rounds=1000000$Va4plzLi$EtixueZQ1ZQlzQa7eHHsG6UcNvu.EnuCqM79kIyUe82eAZ.JNegn4SBY1RduYlACs0RWLFHD4d//PzQXMsCqk0

with the number of rounds embedded. The su command needs 1.79 seconds now which is an acceptable delay for the login process considering the improved security.

Don't forget to change the root password too if you have set one.

In Egypt s sandy silence, all alone,
Stands a gigantic Leg, which far off throws
The only shadow that the Desert knows:
I am great OZYMANDIAS, saith the stone,
The King of Kings; this mighty City shows
The wonders of my hand. The City s gone,
Nought but the Leg remaining to disclose
The site of this forgotten Babylon. We wonder, and some Hunter may express
Wonder like ours, when thro the wilderness
Where London stood, holding the Wolf in chace,
He meets some fragments huge, and stops to guess
What powerful but unrecorded race
Once dwelt in that annihilated place. Horace Smith

Many of us that can afford an Internet connection still qualify as exceedingly rich compared to, for example, many poor people in Africa. On a scale of centuries, the ancient centers of civilization and wealth tend to collapse. Even Rome, with over a million inhabitants in its day of ancient prominence, shrank to only 20,000 over the course of history. Some other ancient cities no longer dot our maps. It helps us, perhaps, to have some perspective. Those magnificent working monuments to wealth in New York, London, or Tokyo probably won t be there 1000 years from now. What will?

I run a personal server that hosts web space for a few friends. Probably the most popular thing to do with the space is to install WordPress and run a personal blog. A few days ago, I discovered some attackers were abusing one of the sites. Once we upgraded the site to the latest version of WordPress, the attack went away. So I wrote a tool that, every night, emails me a report of the locations of old versions of WordPress. A sample email:

Current version of WordPress: 2.9

oldroommate has WordPress 2.5 in /home/oldroommate/web/oldroommate.com/

Eek! WordPress 2.5 is old!

How it works Each time it runs, it looks at wordpress.org to see what the current version is. The code to do that is written in Python and uses lxml.html. It prints the current version in the report, and it uses it when analyzing WordPress installs. To analyze WordPress installs, it executes locate readme.html, looking for WordPress's tell-tale documentation file. For every such readme.html, if it matches a simple regular expression suggesting it's a WordPress readme file, it performs the following analysis:

• It does some simple seding and greping looking for the version of WordPress described by that file.
• If the version detected is older (as calculated by dpkg --compare-versions), it creates a one-line report like the one above about oldroommate.

If it found any installs of old WordPress, it prints a report like the one blockquoted above to stdout.

How to use it To get emails, I run it with cron. You can add a stanza like this to your crontab (edit it with crontab -e):

@daily cd find-out-of-date-wordpress; ./look.sh

Ta-da, nightly reports.

To get a copy Do a git clone:

git clone git://git.asheesh.org/find-out-of-date-wordpress.git

or browse its gitweb.

Feedback I'm quite interested to hear what others do to avoid old web apps being attacked. If there's another bit of software that monitors web apps for needing upgrades, I'd love to hear about it! Obviously if you have feedback on this tidbit I wrote, let me know. (To me, apt-get doesn't seem to be the answer. Web apps (especially PHP ones) don't usually seem to support keeping the code in one place with multiple different configuration files. And users get excited about the latest and greatest and don't want to wait for me to upgrade, and I can't blame them.) If some of you don't like the Python dependency or anything else, I do welcome patches!

With the help of a couple of friends, we ve put a 4.5T RAID-5 machine on our network and I m trying to figure out how to share the storage with the rest of the hosts. In the past, I have used NFS and CIFS/Samba to provide access to remote hosts. This has generally worked okay so long as the server stays online. I don t know if the results are going to be much different, but I am now trying a different approach. I plan to run an iSCSI server, and I ve already configured AoE (ATA over Ethernet). I ve exported a block device on the network segment and mounted it on a remote host. This was pretty easy to configure. There is a bit of documentation on the internet already, but I ll give another quick overview. I gave the storage server the unoriginal name san0 . This host is running debian lenny. I am testing the configuration from my debian sid development host, which has the similarly unoriginal name dev0 . So, think server when you see san0 and client when you see dev0 . I assume that you ve already got an LVM volume group set up. Mine is called vg0 . Correct the following examples to account for any differences. You can use disk partitions instead of LVM logical volumes.

---

Create a logical volume to be exported: cjac@san0:~$ sudo lvcreate /dev/vg0 -n e0.1 -L 5G Load the AoE kernel module: cjac@san0:~$ sudo modprobe aoe Install the package containing the vblade block device export server: cjac@san0:~$ sudo apt-get install vblade Export the block device. Note that the ethernet bridge on which I export the device is called loc : cjac@san0:~$ sudo vbladed 0 1 loc /dev/vg0/e0.1 Install the AoE discovery tools on the client: cjac@dev0:~$ sudo apt-get install aoetools Load the AoE kernel module: cjac@dev0:~$ sudo modprobe aoe Probe for exported AoE devices: cjac@dev0:~$ sudo aoe-discover Verify that our exported device was discovered: cjac@dev0:~$ test -e /dev/etherd/e0.1 && echo "yep"
yep

---

You can now treat /dev/etherd/e0.1 as you would any other block device. You can format it directly, or partition it and format a partition, use it as a device in your software RAID array, use it as swap space (ha), or something completely different. Now to figure out this iSCSI stuff

Yes, aptitude can list packages by priority, but what I wanted was a simple list of just package names. I've got two ways of getting a bare list:

Updated with many thanks to Phil Hands.

$ aptitude search '~prequired' sed -ne 's/^i [ A] \([^ ]*\).*$/\1/p' tr '\n' ' ' sort -u fold -s ; echo

#!/bin/sh
# Licence: GPL-3+
FILE= find /var/lib/apt/lists/ -name '*unstable*Packages'
LIST= grep-dctrl -n -s Priority '' $FILE sort -u

for P in $LIST; do
[ "optional" != "$P" -a "extra" != "$P" ] continue
echo "Priority: $P"
grep-dctrl -n -s Package,Priority "$P" $FILE sed -ne '/^'$P'$/!h;/^'$P'$/ g;p ' tr '\n' ' ' fold -s
echo
done

The advantage with the script is that is lists all packages in all priorities except optional and extra and can be restricted to individual Packages files and therefore to individual repositories and components. (Change the find expression if you have more than one repository specifying unstable or adapt the script to accept a path to the relevant Packages file on the command line.)

I really ought to have used perl because pattern matching in perl is a
lot more natural to me than using sed or awk. I do tend to chain a
couple of sed commands, just so that it's easier to work out which bit
is broken when it breaks.

The final version of this script will end up in emdebian-grip-server,
converted to perl with POD content, translated and reading the Packages
files using Debian::Packages::Compare.

$ ~/scripts/list-priority
Priority: important
adduser apt-utils apt aptitude bsdmainutils libbz2-1.0 cpio cron libcwidget3
debian-archive-keyring dhcp3-client dhcp3-common dmidecode ed libgdbm3 gnupg
gpgv groff-base ifupdown iproute iptables iputils-ping logrotate libept0
libsigc++-2.0-0c2a libtasn1-3 libusb-0.1-4 man-db manpages module-init-tools
nano libncursesw5 net-tools netbase netcat-traditional libnewt0.52 whiptail
libssl0.9.8 libpopt0 libreadline5 libreadline6 readline-common rsyslog
tasksel-data tasksel libwrap0 info install-info traceroute udev vim-common
vim-tiny wget libxapian15
Priority: required
libacl1 libattr1 base-files base-passwd bash coreutils debconf-i18n debconf
debianutils diffutils dpkg e2fslibs e2fsprogs libcomerr2 libss2 libc-bin libc6
findutils gcc-4.3-base gcc-4.4-base libgcc1 libstdc++6 grep gzip hostname
lsb-base libdevmapper1.02.1 lzma liblocale-gettext-perl libselinux1 libsepol1
libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libunwind7 mawk
libncurses5 ncurses-base ncurses-bin libpam-modules libpam-runtime libpam0g
perl-base procps sed sensible-utils login passwd libslang2 initscripts sysv-rc
sysvinit-utils sysvinit tar tzdata bsdutils libblkid1 libuuid1 mount util-linux
zlib1g
Priority: standard
apt-listchanges at bash-completion bc dc bind9-host dnsutils libbind9-50
libdns53 libisc50 liblwres50 bsd-mailx libsasl2-2 libdb4.8 libdb4.5 libdb4.6
libdb4.7 debian-faq doc-debian doc-linux-text libc6-i386 locales exim4-base
exim4-config exim4-daemon-light exim4 file libmagic1 gettext-base libgnutls26
libgpm2 libkeyutils1 libgssapi-krb5-2 libgssrpc4 libk5crypto3 libkadm5clnt6
libkadm5srv6 libkdb5-4 libkrb5-3 libkrb5support0 less lsof libcap2 libedit2
libevent-1.4-2 libgc1c2 libgcrypt11 libgpg-error0 libgssglue1 libidn11
liblockfile1 libnfsidmap2 librpcsecgss3 libunwind7-dev libxml2 m4 mime-support
mlocate mutt ncurses-term ftp telnet nfs-common libldap-2.4-2 openssh-client
patch libpci3 pciutils libpcre3 perl-modules perl portmap procmail
python-central python-minimal python python2.5-minimal python2.5
python-reportbug reportbug wamerican libsqlite3-0 tcpd texinfo time ucf w3m
whois

Hmm, next step is to check the "Priority: standard" set for Emdebian - it looks far too large for what would be standard on an embedded device. LDAP will be dropped for one - and what is a -dev package doing in there? libunwind7-dev isn't even installed on my amd64 Debian desktop!

Probably check the important and required listings too, then tweak what we need to change via the archive overrides for Emdebian Grip.

Come to think of it, I might need a PHP version of this to read live data from the repository, documenting the changes.

My first RC Bug-squashing Day (or rather night):

• bug #552791 acorn-fdisk Copyright file does not contain verbatim copy of the license or a pointer to one
• bug #562647 gidentd Does not work with ipv4 after recent change in netbase
• bug #558812 dietlibc incorrect license in debian/copyright
• bug #531937 autossh FTBFS on mipsel due to missing -fPIC

I picked all of them mostly randomly from the list Zack gave me, and except dietlibc they are packages I had not even heard of before. The first one begun easily (track down licencing information, pimp debian/copyright, but I ended up fixing compiler and lintian warnings and even wrote a manpage for it while there (but for this one, I didn t bump the Standards-Version). The second one was only the second one to complete because the others took longer; it s basically a change of a d mon to use two instead of one listening socket, to work with a doble stack OS instead of just a dual stack OS by not using v4-mapped IPv6 addresses (I considered if to use select(2) or poll(2), or to just fork and have two d mons running, but that seemed too ressource-consuming to me so I chose the less-complicated poll(2) method, looking at popa3d(8) s source code (inherited from OpenBSD) in the MirBSD tree since I could not find my network programming book. The third one was basically communicating with upstream; the bug can be blosed with no change to the package. The fourth one took me a while; luckily I have qemu 0.11.0 on MirBSD, and aurel32 s mipsel qemu images helped a great deal; however, cowbuilder --create failed for me, so I ended up waiting almost the entire night for a-g d-u to finish; in the end, it was simply a bug in upstream s configure.ac which is only exposed due to a toolchain bug on mips(el). To do: my AM Zack needs to upload the NMUs (after checking, of course); I need to communicate some of the fixes upstream (the gidentd upstream is NXDOMAIN ), produce a very small testcase for the mipsel toolchain bug, maybe fix some more mipsel FTBFSen as I have a working qemu instance now, but maybe I ll do that at the BSP when I can t find IPv6 bugs or so that I feel I can fix (I also want to do an mksh release which has to be prepared first RSN, and there s still the need to formally publish the MirBSD-current bi-arch snapshot and make another ISO out of it for BT and prepare the multi-BSD USB stick for allbsd.de ). Annoyances: a-g d-u could ask me things at the start before working for some four+ hours instead of in the middle, and the same questions several times (PAM restart). The sid kernel doesn t boot today but did yesterday, the lenny kernel produces this:
Starting the hotplug events dispatcher: udevdudevd[320]: udev: missing sysfs features; please update the kernel or disable the kernel's CONFIG_SYSFS_DEPRECATED option; udev may fail to work correctly
(I hate udev.) And, worst of all, these annoying fireworks (some sounded like originating from inside our staircase, I pity the neighbour s cats) when one wants to hack Finally, I *loathe* CDBS. Debhelper v5 rules! Oh, and I also was under the impression that Firstname LASTNAME was a French thing, and to a much lesser extent Asian. (@bubulle)

It's the late afternoon of the first day of 2010 here, though I suppose its still 2009 for someone for a little while.

After a lot of waiting, JFFNMS release candidate 1 for 0.8.5 got uploaded to sourceforge. This release is mainly about fixing some database release bugs 0.8.4 had and they're all caused by the fact that working with PHP and database to release code is plain awful.

The problem is tracking changes in your database. So version 1 has 3 tables and 60 rows, version 2 has 4 tables and 90 rows, but what changed? Everything I've seen so far is a bit of a hack or is real fiddly. JFFNMS release process is both which is why I'll go and release several versions of C code or Debian packages before trying to crack that nut again.

If you are wondering what JFFNMS is, its a Network Management System. It makes graphs and red/green icons depending on the status of your routers and servers. Written in PHP and web based and of course licensed under the GPL

The Koha Community Blogs was broken over Christmas. It s now back online and using the same collection of feeds as the microblogging services. A full list of Koha Social Networks is on the wiki.