Serendipitous altruism

A while ago I built a Jabber presence indicator on my personal web page by customizing one of the examples provided with class.jabber.php. I have received enthusiastic feedback from a handful of users – that makes me feel warm inside ! Do not neglect the ego of people who provide free services, be they Free software developpers or volunteers for anything : a kind comment or a nice stroke in the right direction go a long way toward feeding their motivation. So next time you enjoy the produce of the gift economy be sure to let people know how much you liked it !

With the kind words came a question which made me aware that a newcomer may not find the required configuration as obvious as I do. One of the least obvious steps is telling the script whose status it is supposed to check. Don’t look for a JID parameter inside the presence indicator script : the presence indicator script itself knows nothing about the user whose status it checks. It is the watcher bot user that has the watched user on his roster. The presence indicator script will return the status of anyone on the watcher bot user’s roster. That makes it quite flexible because it will work for any number of users.

If anything remains unclear to you, please be sure to report it to me.

Rough handling and repeated falls took their toll on my Treo 650 : the antenna’s root broke and two screws went AWOL. I thought that naturally the manufacturer would sell spare parts but I was wrong : no amount of begging to Palm‘s dreadful telephone support people could convince them to part with some of their apparently precious stock of spares at any price. Same thing with Orange who distributes the Treo 650. The only solution they propose is to send the device into the black hole of their customer support operation and get it repaired at a ludicruous price. This is of course unacceptable.

Happily I found an alternative source : PerformancePDA sells Treo 650 parts at reasonnable prices ! I do not know where they get them from – maybe they disassemble broken devices to get around Palm‘s horrendous spare parts policy. Anyway order fulfillment by PerformancePDA has been fast with no problem. After tightening the minuscule TORX screws my Treo 650 is back in perfect shape. Having it inoperant for a while made me realize how much I depend on it for efficient daily operation…

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…