Want to know everything that matters about tap-to-click and other touchpad configurations in GNOME. Look no further, go straight to the source.

Posted at: 22:45 | Category: /software | permalink

Since late February I stopped seeing my GTalk friends in my IM client. I use a personal Jabber server (jabberd2) and all its connections to the GTalk servers were being dropped. After some investigation in the web, I found that Google:

• Uses a buggy TLS implementation.
• Has activated encryption for s2s connections starting in February.

The end result was that my server could not establish an encrypted connection with GTalk servers. Here is a very informative bug report.

As GTalk connectivity is very important for any open Jabber server, many servers have published workarounds for the problem. Here is a patch for jabberd2. A new release (2.2.7.1) of jabberd2 was also made to address the issue.

I have jabberd2 2.2.4 in my server. For some reason, I could not make 2.2.7.1 work because of some problems with the Berkeley DB back end. I ended up applying this patch to 2.2.4 and it fixed the problem. I also created a bug report in the Fedora Bugzilla, so maybe a fixed package will be pushed as an update.

Posted at: 10:45 | Category: /software | permalink

One more in the ongoing series "patches that make the world go round". If you happen do use the excellent Munin to monitor your servers and use the Postfix plugins, you may have noticed that Munin 1.2.5 introduced a bug in the postfix_mailstats plugin. The bug report and fix is here.

Remember people: release early, release often!

Posted at: 14:00 | Category: /software | permalink

I run a personal SIP server powered by OpenSER. Actually, calling something a SIP server is a bit of oversimplification as the protocol and actions associated with it are fairly complex (as far as I know, I run a SIP proxy and location server). All this to say that OpenSER uses a relational database to store its data, as do all classy enterprise software out there.

So far, so good, but when it comes to relational databases I like using PostgreSQL instead of the OpenSER default MySQL. Why? Because I know how to use it! Problem is, the last stable release of OpenSER (1.2.2) has a serious bug in the PostgreSQL driver, making it impossible to use. It's a pity no one bothered to do a brown bag release because of this issue. Not being the default database really turns you into a second class citizen. Anyway, the fix is already in the OpenSER SVN, but I will post the patch here, to those that want to stick to the released version.

diff -ru openser-1.2.2-tls.orig/modules/postgres/db_res.c openser-1.2.2-tls/modules/postgres/db_res.c
--- openser-1.2.2-tls.orig/modules/postgres/db_res.c    2007-08-16 11:23:05.000000000 -0300
+++ openser-1.2.2-tls/modules/postgres/db_res.c 2007-11-25 08:23:53.000000000 -0200
@@ -572,6 +572,7 @@
         * If this is not done, a memory leak will happen.
         */
        for (col = 0; col < ROW_N(_row); col++) {
+         _val = &(ROW_VALUES(_row)[col]);
           switch (VAL_TYPE(_val)) {
             case DB_STRING:
               LOG(L_DBG, "PG[free_row]: %p=pkg_free() VAL_STRING[%d]\n", (char *)VAL_STRING(_val), col);

The silver lining in this was that it was quite easy to find a solution to this problem. Before OpenSER I used for some time the original SER, and I can tell you, it is almost impossible to find some help on the web. Both because SER is a lousy name to base a Google search :) and because the project isn't quite transparent as a proper open source project should be. So, congratulations to the OpenSER developers! And remember, release early, release often!

Posted at: 18:03 | Category: /software | permalink

This one is for the "unlikely bugs" section. If you use the magic combination of Emacs 22, a US keyboard and dead keys in a UTF-8 locale, the combination ' + c will give you ć instead of ç. Of course, this is a bug only if you want ç and not ć, so please forgive my ç-centrism. No offense intended to ć-using languages, whatever they may be. :)

GTK2 had this same bug about 5 years ago, and they solved it by creating the "cedilla" input method, and selecting it according to locale. Guess the Emacs guys will have to go the same route. Meanwhile, a simple workaround is to fire up Emacs in a ISO-8859-1 locale: "$ LC_ALL=pt_BR emacs" and as soon as the program opens up, select "Options|Mule|Set Language Environment|UTF-8". It isn't pretty, but as I use the US keyboard only rarely this works for me.

Posted at: 14:04 | Category: /software | permalink

I use the fantastic DSPAM SPAM filter in my mail server. I like it very much, specially when using the built-in hash-based storage, making it very fast and really easy to setup. That is, if the documentation and administration tools weren't so lacking. On the plus side, I got to know a little better the tool that keeps my email sanity and respect the developers that make it happen.

If you are an user of the hash driver, you can't rely on the provided tools to maintain your installation. The recommended way of cleaning old messages signatures doesn't work for this driver. Also, the hash-based database has to be cleaned from time to time or it will grow too big, but the tool to do it (cssclean) just doesn't work. To handle these problems, I first had to patch DSPAM so I could get a working cssclean. The main patch was created by Frank Cusack and you can get it in his aptly named message "cssclean is a redheaded stepchild" to the dspam-dev mailing list.

The second patch isn't strictly necessary (and I fear it might violate some design principle of DSPAM), but it keeps cssclean from resetting the statistics of the database. I really can't remember where I found it, so I post it here:

diff -ru dspam-3.8.0.orig/src/tools.hash_drv/cssclean.c dspam-3.8.0/src/tools.hash_drv/cssclean.c
--- dspam-3.8.0.orig/src/tools.hash_drv/cssclean.c      2006-05-27 18:00:36.000000000 -0300
+++ dspam-3.8.0/src/tools.hash_drv/cssclean.c   2007-06-27 19:18:51.000000000 -0300
@@ -167,7 +167,7 @@
     header = offset;
     filepos += sizeof(struct _hash_drv_header);
   }
-
+  bcopy (old.header, new.header, sizeof(struct _hash_drv_header));
   _hash_drv_close(&new);
   _hash_drv_close(&old);
   rename(newfile, filename);

Finally, I run the following script monthly using cron:

# Clean hashes and signatures.
for u in /var/lib/dspam/data/*/*.css; do
    /usr/bin/cssclean $u
done
find /var/lib/dspam/data -name *sig -type f -mtime +30 -exec rm -f {} \;

Probably you will have to adapt it to the file locations of your DSPAM installation.

Posted at: 17:19 | Category: /software | permalink