If you use it, make sure you use the latest version of libnids (currently v1.24) as it fixes a bunch of important bugs. This currently isn’t in Debian/Ubuntu and the maintainer has disappeared, so compile from source for now. Red Hat based distributions get it easy it seems, as somebody has already compiled it for RHEL4 or later.

The best bit? It’s pure Perl, therefore also uses real Perl regular expressions. Yes, there might be grep --perl-regexp, but nobody bothers compiling that in. Plus ack has some other neat features.

See more at the ack website.

I needed this for rsync, to let a remote backup server slowly catch up if large amounts of data were added to the live server during the day. A useful post on the rsync mailing list discusses an rsync patch but also the timeout command.

After installing (the Debian package is simply timeout) it is as easy as running with the number of seconds to run for:

It is also possible to specify the signal which will be sent to a program, which is useful if you do not want to simply send SIGKILL. I used SIGHUP in the hope that rsync would have a chance to exit gracefully:

A full list of signals and their numeric values can be found in man 1 kill.

A wrapper script is also available from Johannes Buchner.

This causes the router to request DNS server addresses when the PPP session is negotiated (when it “dials up” to ADSL).

After reconnecting the PPP session (either reload or shutdown the interface and then bring it back) it is possible to check that DNS servers have been obtained using sh host:

If the router is running a DNS server it is possible to direct DHCP clients at the router IP instead, forcing them to use these same settings.

I grabbed a source tarball from the website and started there. Installing is simple:

1. After extracting, copy defconfig to .config
2. Edit .config to set the user and enable the backends you require
3. Run make and then make install (as root, obviously)
4. Edit the dovecot configuration to set plugin configuration

I chose the dspam-exec backend, but read the documentation before using it as it will spawn the dspam binary for each mail moved in.

You should ensure that the user that the dspam-antispam plugin runs as is trusted by dspam (edit /etc/dspam/dspam.conf and ensure there is a Trust <user> line) and does not violate dovecot security settings (set at compile time). On Debian, this seemed to mean running the plugin as root.

Editing the dovecot configuration includes enabling the plugin in the protocol imap section:

mail_plugins = antispam

And, for the dspam-exec plugin, configuring it like so:

# Which folder the antispam plugin monitors
antispam_spam = Junk
# Antispam trash folder
antispam_trash = trash;Trash;Deleted Items;Deleted Messages

antispam_signature = X-DSPAM-Signature
antispam_signature_missing = move

#===================
# dspam-exec plugin

# dspam binary
antispam_dspam_binary = /usr/bin/dspam

# semicolon-separated list of extra arguments to dspam
# (default unset i.e. none)
antispam_dspam_args = --deliver;--user;%u
# antispam_dspam_args = --deliver=;--user;%u  # % expansion done by dovecot
# antispam_dspam_args = --mode=teft

This seems to be the minimum to get the dspam-exec backend working. Note that configuration for other options will be different, if somebody fancies sharing a configuration that sends mail to <user>-spam@<domain> I’d be very grateful

Thanks to Johannes for writing this plugin.

The best bit is that it is completely transparent to the end user and doesn’t require them to forward messages with headers intact to a weird user-spam@example.net address in order to conduct training.

If you find it useful or make changes, please let me know in the comments below.

The code

Hopefully Rafal Wojtczuk, the libnids author, will publish these changes on the Sourceforge site soon.  Until then you can grab a patch between the two versions or a complete distribution tarball below.

Update: As of today (March 14th 2010) Rafal has updated libnids to v1.24 with a number of other changes. You can grab it from the official libnids website. Thanks!

I thought I would share my experience of submitting a module to CPAN for the first time. In summary: it’s stupidly easy and if I can do it, so can you.

I’m not the best Perl coder and therefore I rely heavily on CPAN modules to do the real work. Every now and again I stumble upon bugs, many of which are simple to fix after a little debugging. However, some modules aren’t heavily maintained and some haven’t been touched in years. Bugs that are filed on RT can go unanswered, gathering digital dust while your development machine is riddled with heavily modified modules.

The solution? In my case it was as easy as discussing a few changes with the module author, who added me as a co-maintainer. That allows me to upload new versions, fix tickets in the bug queue and probably many other things I’ve not discovered.

Uploading a new module requires logging into PAUSE and pointing it at a file on your local disk or a remote HTTP server. A few emails later and a short wait and the changes appear on the CPAN website itself.

Some useful things to consider when uploading a new module:

• Does it still build? Run make clean (or make realclean) and check from scratch!
• If applicable, do the changes break any tests (run make test)
• Is the MANIFEST file up to date?
• Bump the version number in all files that use it (the .pm itself, README, META.yml etc) – grep is your friend here
• Document what is new in the Changes file
• Remove any other files left over from your development, then tar it all up
• Go and resolve bugs on rt.cpan.org that you have fixed and take some credit!

(I’m sure I have missed some important ones, please add them below!)

I noticed when replying to a bug ticket that there is a “minutes spent” field. In all honesty, the above probably took no longer than 10. And that’s how long it takes to have the whole Perl community benefit from your newly broken nicely updated module.

As another quick plug: this is also my first blog post to blogs.perl.org. It was also stupidly easy so if you don’t fancy coding, get scribbling instead!

Firstly, you need something on the phone which will support SyncML, the standard that allows different devices to exchange data.  To sync, install the iPhone Funambol application (iTunes store link) which is currently free and works really well.

The Funambol application itself is very simple, adding an account is easy:

• set the “Server” field to something like http://example.com/horde/rpc.php (replace the location appropriately)
• set the “Username” and “Password” fields to the same ones you use to login normally
• in the “Contacts” section of the setup, the “Remote Name” should be set to card

The “Sync Direction” can be set whichever way you prefer. A cavaet: I only do one way synchronisation.  That is, I sync my contacts from iPhone to server, but not the other way. Whilst it does work both ways, I haven’t tested it extensively. It is possible that rabid zombies will eat your firstborn if you change something on the server and try to update the iPhone.

Once these settings are updated, you can go back to the main screen and hit the big “Sync Contacts” button. If it succeeds, you will see your contacts appear on the Horde server. If not, you can always view the log from the settings menu to work out what went wrong.

One of the coolest (but most useless) features is that any photos associated with contacts will also be uploaded to the server.

Note that some fields aren’t automatically used by Horde, such as the “Home Email” and “Work Email”. This is very easy to fix, but you’ll need to ask your system administrator to have a look at this post on my blog.

Feel free to leave me a comment if you get stuck and I will endeavour to help you fix it.

• define an attribute (e.g. it is called “Home Email” and is of type “email”)
• add it to list of fields that Turba uses (so it is displayed in the right place)
• add the backend storage (so Turba can query/save the values)

For this example, we are adding the home and work email fields, which are compatible with the iPhone contacts.  This post assumes you use a database backend, if you don’t then step 3 will be slightly different.

1: Define an attribute

Firstly, check the file turba/config/attributes.php and make sure the following is present:

$attributes['homeEmail'] = array(
'label' => _("Home Email"),
'type' => 'email',
'required' => false,
'params' => array('allow_multi' => false, 'strip_domain' => false, 'link_compose' => true)
);

This defines the field “Home Email”. In recent versions of Horde this should already exist, so you shouldn’t need to modify the config. If you are creating a different type of field that does not exist already, it is easiest to copy the definition of something similar and change the label and attribute name.

2: Tell Turba we want to use this field

Next the file turba/config/sources.php needs to be edited. Find the line 'email' => 'object_email' and add below it the following two lines:

'homeEmail' => 'object_homeemail',
'workEmail' => 'object_workemail',

This tells Turba that the fields homeEmail and workEmail come from the database fields object_homeemail and object_workemail, respectively.  We also need to modify the list of tabs so that Turba knows to display our new values in the right place.

Email addresses should go on the “Communications” tab, after the existing email field, so we modify the array and insert the attribute names like below:

_("Communications") => array('email', 'homeEmail', 'workEmail', 'homePhone', 'workPhone',
'cellPhone', 'fax', 'pager'),

3: Add the backend storage

Assuming you use a database backend, this is as easy as creating two new fields in the database.  They should be named according to the values in sources.php that we defined above and should be similar to an existing row of the same type.  As we are creating email fields, we can use the same data type as the object_email row.

For this example, the following SQL will modify the database appropriately:

ALTER TABLE `turba_objects`
ADD `object_homeemail` VARCHAR( 255 ) NOT NULL AFTER `object_email`,
ADD `object_workemail` VARCHAR( 255 ) NOT NULL AFTER `object_homeemail`

The same process above can be followed for other fields that might be missing, post a comment if there is something that you’d like help adding.