It is certainly obvious but there was no mention of it in the LVM howto, and that made me feel the need to confirm it experimentally using lvcreate on an heterogeneous VG. So there : the size of an LVM stripe cannot be larger than the smallest physical volume (PV) in the volume group (VG).

Each MAC address is supposed to be globally unique. You can change the MAC address when configuring the interface and you can even write a new MAC address to the adapter’s EEPROM. But such alterations are generally only done for testing purposes and the only other excentric use of MAC adressing I know about is giving a Speedtouch Home ADSL modem the Ping of Life. This is because an important feature of the MAC address is that you were supposed to be able to rely on its uniqueness, and many programs assume they can. Mistaken they are ! A large supplier of ADSL modems once shipped us several batches of ADSL modems with variously duplicated MAC addresses. Worse : we accepted them. And we then had to find ourselves another unique identifier for the modems on our network… Just another invalid assumption…

A while ago I published lbdb-fetchalladdresses-firsttime.sh and lbdb-fetchalladdresses-daily.sh, two scripts that scour a maildir hierarchy to records all addresses from the headers in the lbdb m_inmail database in order to feed whole maildirs to LBDB for Mutt’s address completion.

A few days ago, for some unknown reasons this script ceased to work correctly. I traced the problem to an incorrect argument to ‘uniq‘. While I was at it I decided to let ‘sort‘ handle the job of ‘uniq‘ and in one fell swoop enhanced the sort operation with some better criterias (-u -d -f -i -k 1,1). So here is version 0.3 for you :

• lbdb-fetchalladdresses-firsttime.sh
• lbdb-fetchalladdresses-daily.sh

As I mentioned earlier, if you do not have an existing lbdb database, you should run lbdb-fetchalladdresses-firsttime.sh first. Once you have done that you can from time to time update your database with lbdb-fetchalladdresses-daily.sh who does the same thing as lbdb-fetchalladdresses-firsttime.sh but only for messages not older than a certain user-set age.

I just maybe apparently (inch’Allah !) about (I am definitely unsure…) got rid of (“solved” would probably be too strong a word for that haphazard process) a very vexing problem that kept me wondering for weeks.

On an otherwise very healthy Debian Linux host I saw idle /USR/SBIN/CRON processes begin to accumulate by the hundreds at a rate of a few every few minutes and after some time inducing significant load although some of them eventually died. Killing them was only a temporary remedy as they kept reappearing. I could not link their appearance to specific cron jobs nor could I link them to a specific command. And hours of sifting through forums and mailing lists yielded nothing conclusive : /USR/SBIN/CRON processes not terminating were not unheard of but their causes seemed to be varied and most often quite mysterious.

Liberal use of strace with various combinations of ‘-p’ ‘-f’ ‘-F’ and ‘-ff’ binding to the running cron daemon process and following vforks showed that the undead processes were left listening on an open connection. I also observed that the /USR/SBIN/CRON spawning was inhibited by an attached strace – in presence of strace the children did receive their missing SIGSTOP. And sometimes days went by with no manifestation of the dreaded processes – but as soon as I thought the problem was solved they began to reappear…

Anyway, finding that the undead processes were left listening on an open connection was the smelly trail I was looking for. ‘netstat -p | grep tcp | grep CRON’ soon showed me that each one of them had an open connexion to the local LDAP server. Then ‘lsof | grep cron | grep ldap’ hinted that it was not the cron process itself that was directly connecting to the LDAP server but an underlying library involved in our PAM LDAP user management system.

Armed with those new results I went hunting for some wild data and found a discussion between Robert Rakowicz and Jerome Reinert about a somewhat similar problem. But the maintenance operations Jerome Reinert suggested on slapd‘s Berkeley DB database did not solve the problem.

For now I have read another post mentioning that versions mismatches and assorted maintainance issues in slapd‘s Berkeley DB database can cause a similar problem. I can’t find the adress anymore but if I do I’ll post it here. We found that a simple slapd restart got us rid of the undead /USR/SBIN/CRON. It has been a few days and I have not seen one again… We keep our fingers crossed – maybe an upgrade silently fixed the problem…

Meanwhile I posted this to debian-user just in case someone there recognizes this problem as something familiar…

Since then I have seen the problem appear again and restarting slapd temporarily fixed it. I am using slapd 2.2.26 from Debian. Maybe I should upgrade to 2.3.23 : although it is available through Debian Unstable it has been released upstream one year ago so maybe I should trust it…

Googlebot indexing Gallery‘s slideshow.html single-handedly brought our server to a crawl. Visits to slideshow.html each produce one Apache process and one Mysql process both pegged at maximum CPU usage. And since the Googlebot visits are quite frequent the processes kept piling up as more were added before the others finished processing the queries. Loads of 30 were not uncommon – something had to be done…

On top of being very CPU intensive, slideshow.html is also totally useless since the information it provides is redundant. So the administrator has every reason to keep the robots from visiting such pages. It took me a discussion with h0bbel to build a working solution that I then recorded in Gallery’s wiki. Thank you h0bbel ! Here is how it goes :

Using URL rewrite module, the default slideshow URL is the following form: “/v/my_album/my_sub_album/my_photo.jpg/slideshow.html“. The problem is that there is no way to exclude that sort of URL in robots.txt syntax. In order to make the URL excludable, some URL rewriting is required.

Happily, there is no need for fiddling with mod_rewrite directly as the nifty rewrite module can handle the details itself. By default the “View Slideshow” rewrite target is “v/%path%/slideshow.html“. The constant slideshow URL mark (“/slideshow.html“) is on the right side of the variable path (“%path%“) and this is why we could not express the slideshow ban in robots.txt syntax. Reversing this order will provide us with an excludable URL.

So we change the rewrite target for “View Slideshow” from “v/%path%/slideshow.html” to “v/slideshow/%path%“. and then add “Disallow: /v/slideshow/” to the site’s robots.txt. If you use the PATH_INFO mode of URL rewrite module then this will be “Disallow: /main.php/v/slideshow/“.

And that’s it: no more spiders hogging our precious resources in vain !

Now in the absence of a centralized multisite administration tool I still have the chore of deploying that solution on each gallery on my host… By the way I wrote a feature request for a one-stop multisite upgrade – use your Gallery forums account to vote for it !

Gaim being evicted from my workstation I went shopping. Gabber and Gabber 2 are no longer developped so that rules them out. Tkabber seems to serve the Jabber hackers well and I found it featureful and highly configurable – I keep it on my shortlist but it does not have the look and feel I am looking for. Gajim looks sweet and solidly gnomish but still a bit wet behind the ears and too simple for my taste. Finally, from my highly subjective point of view it is Psi that strikes the right balance with its good compromise between configurability and simplicity, its excellent coverage of Jabber functionnality and a look and feel to suit my taste. And as a bonus, Psi is available on both Windows and Linux with excellent consistency and Psi will soon feature Jingle. I’m sold !

Gaim does not let the user set the priority of the Jabber client on his workstation. Since I use three different workstations (home, work and mobile), setting Jabber priority is essential so that I get my messages at whichever station I happen to sit or on my mobile when I am not sitting at a desk. So I need another Linux Jabber client…

On my Windows XP workstation at work I found that when receving a message in not yet clearly defined conditions which probably include the message not being aknowledged by the user, Exodus provokes the occupation of about 1 GB of swap space and makes the whole system slow down to a crawl. I went opening a bug report but someone already reported a bug that looked identical to me. So anyway I need another Windows Jabber client…

A month ago I published lbdb-fetchalladdresses-firsttime.sh and lbdb-fetchalladdresses-daily.sh, two scripts that scour a maildir hierarchy to records all addresses from the headers in the lbdb m_inmail database in order to feed whole maildirs to LBDB for Mutt’s address completion.

A month of running these scripts has revealed a few problems wich are now corrected with a speed optimization thrown in for good measure :

• lbdb-fetchalladdresses-firsttime.sh
• lbdb-fetchalladdresses-daily.sh

As I mentioned earlier, if you do not have an existing lbdb database, you should run lbdb-fetchalladdresses-firsttime.sh first. Once you have done that you can from time to time update your database with lbdb-fetchalladdresses-daily.sh who does the same thing as lbdb-fetchalladdresses-firsttime.sh but only for messages not older than a certain user-set age.

One of the problems with my Jabber presence indicator on a web page was that the page’s presence was being sent to the polled account instead of being hidden. I fixed that and the updated code is available. The fix was trivial :

29c29
< $JABBER->SendPresence();
—
> $JABBER->SendPresence(“invisible”);

Although widely implemented (even Edgar does it that way), the “invisible” presence type is not XMPP compliant. JEP 126 explains how to provide selective visibility in a XMPP compliant manner. Of course this is less trivial. But since JEP 126 provides the appropriate XML snippets, I could probably do it the right way using SendPacket($xml) to send the raw XML. Maybe next time… Meanwhile I reported the standard compliance issue on the Edgar bug tracker.

I now rely on Jabber to publish my presence. Not everyone has a Jabber client at hand but Web access is about ubiquitous so it makes sense to me to make my presence available on a Web page. To me this is a personnal itch and an excuse to practice some PHP and learn a little about the exciting world of XMPP.

The source code for my presence indicator is now available for whoever wants it. It is made possible by class.jabber.php, a Jabber library for PHP. I customized one of the examples provided with class.jabber.php. It has many rough edges such as the user’s name sprinkled across the markup code instead of being a proper parameter, or the page’s presence being sent to the polled account instead of being hidden. And it is quite slow because it queries at load time. But I like it better than the example packaged with class.jabber.php.

It basically does the job and I am therefore quite sure that there will be interested users. So this is the “early” part of “Release Early, Release Often”. Take that hack, customize it, tweak it and generally improve it… And most of all please report back somewhere so that everyone can benefit. Here would be a good start.

As many have said before, Jabber is to instant messaging what SMTP is to email:

Today most people understand instant messaging almost entirely in terms provided by AOL, Microsoft and Yahoo. As with on-line services and operating systems, closed IM systems became familiar to the general public long before the open ones. In terms of architecture and control, AOL’s, Microsoft’s and Yahoo’s instant messaging systems are as closed and non-interoperable as Prodigy, Compuserve and AOL were back in the [early] nineties.

In other words, AOL, Microsoft and Yahoo all want to keep private something that should be no less public than mail and web services. All of those companies’ IM systems use the Internet and offer free clients, but they offer no internet service anybody can build on.

This quote dates back from 2001… After all these years I at last consider the Jabber ecosystem to reach both reasonnable usability and critical mass. I believe we can thank Google for tipping the scale. So what’s next ?

I have said it privately since 2002 : the buddy list will become the center of user interaction with the mobile “phone”. Presence management holds every synchronous media together. Through presence management, messaging has moved from the periphery of the desktop toward its core. It changes the environment in which other services interoperate. For example it makes the answering machine obsolete : no one is going to knowingly initiate a call when there is on one on the other end. And the buddy list is where convergence happens : any communication can be initiated from there, not just what the operator deems reasonnable to provide.

As usual the operators are busy fighting rear-guard action, but they cannot keep the customer from craving the ideal of the Stupid Network. GPRS and UMTS enable innovation at the edge and that is the end of the walled gardens. Of course capital expenditure and spectrum scarcity still provide them with a fairly entrenched position, but we are now firmly in Internet land and there is no going back.

So as we all have been thinking all along, the open protocol takes over the closed ones. It takes time, but it is inexorable. The mobile networks are next and they know it… But that does not mean they can avoid it.

Mobile network operators will not like it but instant messaging is going to be priced at bulk data prices, not anywhere near the EUR 1000 a MB that they can get away with for SMS. Earlier attempts to sell services instead of selling raw data have met mixed responses – it will only get worse and I do not believe this to be only my wishful thinking.

It has been a few days since I have begin using Chatopus as a Jabber client on my Treo 650. Overall I am very pleased. Chatopus is very simple and quite polished. It works as advertised with no effort and no undue feature creep.

The only major functionnality that I miss in Chatopus is background operation during an SSL secured connexion. It works fine with a cleartext Jabber connexion, but not with SSL. According to the author, Tony Yat-Tung Cheung it “is an issue with Palm OS’ built-in SSL library. Unfortunately, PalmSource is no longer updating the Palm OS Garnet“.

I also found a few minor annoyances. The first one is that the roster can only display at any one time the contacts from one categories or all catefories together, but not a choice of selected categories. Although that Palm OS UI convention is normally simple and practical this is not the first time I find it annoying… This illustrate the fact that UI conventions are guidelines that sometime can be overriden by specific needs. But by sticking to the convention Chatopus does a good job of remaining simple and easy to use.

Chatopus also lacks a custom status in addition to the standard standard Presence Type (Available, Away etc.). For exemple, when the Exodus Jabber client sets the “Extended Away” Presence Type it transmits the standard “xa” flag and an additional customizable and more informative status details such as “Extended away as a result of idle”. It would be nice if Chatopus transmitted this too in addition to the standard Presence Type.

Last minor gripe : if for some reason the GPRS link goes down Chatopus does not reconnect and restart it. Maybe this should be a user-configurable option.

Overall Chatopus makes the mobile use of Jabber a breeze. On my Treo 650 it now has its own button so that my roster is only a keypress away… That tells something about how useful I find it !

When I type the beginning of a name in Mutt, pressing CTRL-T will give me a list of addresses whose real name matches my entry, and I just have to choose the one I want. As a result I seldom type more than a few letters to enter a complete address. This trick is called an external address query which is the mechanism by which Mutt supports connecting to external directory databases through a wrapper script.

The wrapper script I used is called lbdbq and it is part of lbdb. Lbdb provides an abstraction layer to a wide variety of address sources. The one I use most is the m_inmail database built by lbdb-fetchaddr. lbdb-fetchaddr reads a mail on stdin and extracts adresses from the mail header to append them to $HOME/.lbdb/m_inmail.list. Thanks to lbdb-fetchaddr, if we ever exchanged mail I can completion your name to you address.

There are two ways to feed the m_inmail database. The first one is to do it as you go using a MDA filter that pipes a copy of incoming messages to lbdb-fetchaddr. I copied the maildrop recipe from Mark Weinem’s .mailfilter example :

if ( $SIZE < 10000 )
cc "|lbdb-fetchaddr"

As you may have guessed the filter excludes messages larger than 10 KB because lbdb-fetchaddr is not supposed to work with “big messages”. But Mark Weinem’s .mailfilter example does not provide any further explanation and I found none myself. What I did find is that this rule does from time to time cause deferals after maildrop delivery failures for a reason I have yet to discover. Until I find that reason I will refrain from using it.

So I found another way to do it : feed lbdb-fetchaddr my 4 GB of mail dating back from 2001 (the moment when a disk crash taught me the value of good backups). This method has the added value of taking advantage of historical data, not just future traffic. On mutt-users, Jason Helfman asked “if anyone out there has any success in piping their inbox to lbdb-fetchaddr” and got no answer. Indeed, lbdb-fetchaddr does not work like that : each message must be fed individually. Of course I had to automate the process so that all my maildirs can be processed in one go, so I wrote a couple of small scripts :

If you do not have an existing lbdb database, you should run lbdb-fetchalladdresses-firsttime.sh first : it scours a maildir hierarchy to records all addresses from the headers in the lbdb m_inmail database. Once you have done that you can from time to time update your database with lbdb-fetchalladdresses-daily.sh who does the same thing as lbdb-fetchalladdresses-firsttime.sh but only for messages not older than a certain user-set age.

For performance reasons lbdb-fetchaddr appends new addresses to the database without removing duplicates – duplicates are only removed at query time. For 4 GB of mail, lbdb-fetchaddr produces a 6 MB m_inmail file which piping through ‘uniq‘ reduces to a mere 300 KB. Since the process is normally a one-off, I believe it is well worth the transient load. The update script only deals with a few additional entries, so the ‘uniq‘ load is negligible especially since this is likely to be a nightly cron job.

Don’t forget to install the lbdb package before and to add the following line to your muttrc :

'set query_command = "lbdbq '%s'

So there you go : happy CTRL-T completion !

I use Maildrop to dispatch incoming mail to the appropriate maildir. Such server side filtering is nice because my mail is always tidily waiting for me in the right folder whichever tool I use to read it. But it has a major drawback : each message is present in one and only one folder. For those messages about playing paintball with my grandmother I must choose between the “paintball” folder and the “family” folder – they cannot be in both unless I make a copy which would be a gross hack.

This problem is common to all hierarchical storage of physical items. But it has already been solved many times before with the use of tags. Whether you want to go hardcore with a full thesaurus or just use your little folksonomy the required technical foundation is the same : tags.

Of course, using tags is nothing new to Gmail users : Gmail allows users to categorize their e-mails with “labels.” Labels give users a flexible method of categorizing e-mails, since an e-mail may have any number of labels (in contrast to a system in which an e-mail may belong to only one folder). Users can display all e-mails having a particular label and can use labels as a search criterion. Gmail also allows users to set up filters which label incoming e-mail automatically. Users can simulate the functionality of folder-based filtering by applying labels and archiving mail as it arrives.

But most of the rest of the world has not caught up yet. So let’s do it : it seems to me that we have everything we need to build powerful functionnality on top of our fine toolset. As usual we will not settle for anything that makes us dependant on non-free products or on client side contraptions. So let’s review the available tools :

Server side filtering requires a competent mail delivery agent. A draft RFC describes the “IMAP flag extension” to the Sieve filtering language, but I have not found anything else (a reader later supplemented my lacking research by pointing out that “works on the Sieve language specification is still very much alive and well” – see the comments). Procmail can set keywords and Maildrop supports keywords too. The Maildrop package features a command-line utility (maildirkw) that allows other applications to manually set or clear custom keywords on messages and IMAP keywords may also be set with maildrop itself.

So we potentially have a bunch of maildirs containing appropriately tagged messages. And to serve them we luckily have a whole bunch of IMAP servers supporting IMAP keywords. It came to me as a surprise to see both IMAP servers and MDA providing apparently mature support for IMAP keywords. That is a good surprise. So while we are at it here are a few details about Courier-IMAP’s IMAP keywords implementation.

The less good surprise is the state of client support :

• A couple of weeks ago, Nancy McGough herself posted to evolution-list@gnome.org to enquire about IMAP keywords support in Ximian Evolution – I also failed to find any information about it and I do not take that as a good omen.
• A mutt user asked about IMAP keywords but no useful answer was produced – research yields no further information.
• Squirrelmail has a “Message Flags & Icons” plugin. It could be worse, but development does not seem very lively.
• Thunderbird supports IMAP keywords but only allows five of them. This is a known bug but it has been open for more than four year so I’m not holding my breath for it. The amount of comments made to that bug show that user expectations about IMAP keywords are slowly growing.

So IMAP keywords are as far as I am concerned not ready for production use yet but we are now just some client support away from that stage. I am eagerly looking forward to it ! I will certainly still use physical folders for the two top levels of my classification. But below that I am going to replace a lot of them with tags.

If you install the new 2.3.3 version of amavisd-new via the Debian package, you are in for a few (possibly unpleasant) surprises. Among other changes, /etc/amavis/amavisd.conf no longer works.

The new configuration files in /etc/amavis/conf.d there are:

01-debian
05-node_id
15-av_scanners
15-content_filter_mode
20-debian_defaults
30-template_localization
50-user

To my dismay I also found that virus and spam filtering were also rendered inoperative although mail kept passing through Amavis just fine…

The header of 50-user says : “Place your configuration directives here. They will override those in earlier files“. It should have said “Place most of your configuration directives here” because there is another place where a couple of essential configuration parameters must be set, and it is not made obvious nor even pointed to by the documentation or anything encountered on forums and mailing list. The header of /etc/amavis/conf.d/15-content_filter_mode mentions : “You can modify this file to re-enable SPAM checking through spamassassin and to re-enable antivirus checking“. And indeed, commenting out the couple of lines that obviously needed being commented out re-enabled my favorite content filters.

And the lesson of the day : just porting the old configuration does not cut it, you really need to read every new configuration file – RTFC (Read The Fine Configuration)…