Project Lancelot FAQ

(or, rather, questions likely to be frequently asked if anybody would actually use the software except myself)

Project Lancelot Meta-Information

Q. Why the funny name?

A. If you think »Project Lancelot« is funny you must not have heard of that other mailing list manager which is called »Enemies of Carlotta« :-)

The name came up when we were talking about starting the project. I had recently been reading T. H. White's »The Once and Future King« to my SO, and it occurred to me that mailing list management as a field of endeavour was in dire need of a knight riding in to slay all the dragons and free all the damsels in distress. Of course for all the nobility this is ultimately futile (we're not going to replace Mailman anytime soon), hence Lancelot. I could have called it Don Quixote but that name is already spoken for.

Configuration

Q. How do I conveniently transfer settings from one list to another?

A. You can initialise a new list from the settings of an existing list using

  $ ll-init --clone=oldlist@example.com newlist@example.com admin@example.com

This will use the configuration settings from oldlist@… except for the list.name, list.address, and list.owneraddress parameters, which are set as for a new list. The details are in ll-init(1). It is also possible to override individual items when cloning a list, by giving them on the command line as usual.

Once a list has been created, a nifty way of transferring (groups of) configuration items is by doing

  $ ll-conf -q oldlist@example.com PATTERN | ll-conf -i newlist@example.com

where PATTERN is something like digest.* (to transfer all digest settings).

Troubleshooting

Q. Whatever I do, I get the following message:

  /usr/bin/ll-list: error accessing list list@example.com

I've been using this list for a while without problems, and I just upgraded Project Lancelot to a new version.

A. If you have had the list for quite some time, the most likely explanation is that it was created when Project Lancelot used SQLite 2 for its database. Recent versions of Project Lancelot use SQLite 3, and the on-disk format of the database files is not directly compatible. You can check whether this is your problem by invoking any Project Lancelot command (ll-list is a good candidate) with the --debug command line option. This should give a message like

  ll-list[24983]: db: /home/alfred/.ll/list@example.com/list.db is an SQLite 2 database, please upgrade

(among others).

Now, about getting this sorted out: If you still have SQLite 2 around, an easy way to upgrade your database is

  $ cd $HOME/.ll/list@example.com    # go to the list directory
  $ cp list.db list.db.old           # make a backup copy (we love backup copies!)
  $ sqlite list.db .dump | sqlite3 list.db.new && mv list.db.new list.db

This uses the SQLite 2 command line tool to dump the old database in SQL and feeds that SQL code to the SQLite 3 command line tool to create a new database, which is then copied over the old one. (Without SQLite 2, you're essentially hosed. Your best bet would be to install SQLite 2, which isn't a big deal; your Linux distribution should have it, and if not, it is still available from the SQLite download page. Check the bottom of that page for instructions on how to get SQLite 2.8.)

Note for Our-ISP users. Remember that your list directory is something along the lines of $HOME/domains/example.com/list.

Q. I'm using ask_confirm(cmd=foo) to have my users confirm a workflow but the module does not appear to do anything (I can see from the log that it is being invoked but no confirmation messages are sent out, and Project Lancelot just proceeds with the workflow as if the module wasn't there).

A. Remember that you must set confirm.foo = 1 in the list configuration for your ask_confirm to actually do anything. This is so we can ship things like the unsubscribe workflow that contain ask_confirm but do not by default require confirmation.