(using “source” to copy data as-is, and using “template(”filename”) to use a template structure as data).

Or, if one wishes to directly set the content of the target file:

Please note that on the first line, for example ‘file { “/etc/mpd.conf”:’), the “/etc/mpd.conf” is a merge of two functionalities/concepts: Usually, the syntax is clear and simple:

The first line is about the resource description. Its goal is to be able to reference to it a little later from another resources (Notify[], etc.). By putting directly the file path and name (I think it’s identified as a filename and not as a description because there are quotes, or maybe it’s because it begins with a slash?) you mege the “path” attribute with its description.
On the other end, we’ll not be able to reference to it later, if you need to.

You may also need to synchronize a file that is not present in the repository (puppet:///files/*). That usually happens, for example, when that file is regenerated by an external program or an external action (like /etc/passwd).

I know, some programs already do this, but they require Xwindow and some ugly Gnome/KDE app. What we’re doing here is a minimal setup, using the least memory.

Normally, on a normal Unix system you would use the included device detection mechanism, which is hotplug. But on Ubuntu (at least Gutsy and Hardy), the de-facto/required way is by using udev, which is an event based system, using rules to fire new events/mount/symlink or run programs according to some patterns defined as “rules”.

So, the first thing to do is to identify your device according to USB events. udevinfo is your friend. So, after looking at the output of dmesg, you’ll see your USB device is available on some sd* device.

So run:

You will get a list of “blocks” representing each layer of drivers. For example:

These are in fact attributes that you can use in your rule to filter the devices. So for example,
to run a shell script when a SCSI device is detected which has a size of 1GB, I’ll use the following line:

This line is to be put in a new file in /etc/udev/rules.d, named something like 91-backuptousbdrivetrigger.rules. It’s better to put the file at the end of the rules (the “91″), as not to disturb other module loadings.

The content of the recup_usb.sh file can be:

(yes, I know this code is dirty, I should have used mktemp, but you get the point…)
Don’t forget to chmod +x the shell script and reload the configuration with:

For more detailed information about writing udev rules, take a look at the official documentation, or another’s detailed information about doing the same thing.

• DBERROR: reading /var/lib/cyrus/db/skipstamp, assuming the worst: No such file or directory
• DBERROR db4: PANIC: fatal region error detected; run recovery
• DBERROR: critical database situation

Structure of Cyrus database

The database is split in two parts. The first part is the real database, normally located in

:

mail:/usr/src/cyrus-imapd-2.2.10# cd /var/lib/cyrus
mail:/var/lib/cyrus# ll
total 60
-rw——- 1 cyrus mail 144 Feb 20 16:54 annotations.db
drwxr-xr-x 2 cyrus mail 4096 Feb 20 16:54 db
drwx—— 2 cyrus mail 4096 Feb 20 16:54 db.backup1
-rw——- 1 cyrus mail 8192 Feb 20 16:54 deliver.db
drwxr-xr-x 2 cyrus mail 4096 Feb 20 16:46 log
-rw——- 1 cyrus mail 11644 Feb 20 16:54 mailboxes.db
drwxr-xr-x 2 cyrus mail 4096 Feb 20 16:46 msg
drwxr-xr-x 2 cyrus mail 4096 Feb 20 17:15 proc
drwxr-xr-x 2 cyrus mail 4096 Feb 20 16:46 ptclient
drwxr-xr-x 2 cyrus mail 4096 Feb 20 16:55 socket
-rw——- 1 cyrus mail 8192 Feb 20 16:54 tls_sessions.db

In fact, in this part, the only (and most important in all of Cyrus) useful thing, is the mailboxes.db file. Everything else can be reconstructed from nothing.

The second part is containing all the emails and filters (sieve). Usually they are located in

. I advise you to make a recursive backup of these two directories in case something goes really wrong.

Possible problems, and their solution

Look for all the instances of cyrus executables you may have. The easiest for this is to use the

command (after updating the database with updatedb). Try

for example. For each of the files run a

(or on any other executable from cyrus):

mail:/var/lib/cyrus# ldd /usr/cyrus/bin/ctl_mboxlist
libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0×4001c000)
libssl.so.0.9.7 => /usr/lib/i686/cmov/libssl.so.0.9.7 (0×40031000)
libcrypto.so.0.9.7 => /usr/lib/i686/cmov/libcrypto.so.0.9.7 (0×40063000)
libresolv.so.2 => /lib/tls/libresolv.so.2 (0×40162000)
libdb-4.2.so => /usr/lib/libdb-4.2.so (0×40174000)
libc.so.6 => /lib/tls/libc.so.6 (0×4024a000)
libdl.so.2 => /lib/tls/libdl.so.2 (0×4037f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0×40000000)

The important thing is to have all of your executables linked with the same libdb version (here it is

).

The first thing to do, before anything else, is to verify the integrity of your Cyrus installation. Stop the Cyrus daemon, and restart it, and look at the logs. Many times, I see errors about daemons not found. For example, one of them (

) is supposed to recover automatically from a db crash, but when you have the following error:

Feb 20 07:13:48 mail master[11873]: about to exec /usr/sbin/ctl_cyrusdb
Feb 20 07:13:48 mail master[11873]: can’t exec /usr/sbin/ctl_cyrusdb on schedule: No such file or directory
Feb 20 07:13:48 mail master[10665]: process 11873 exited, status 71

You can be sure, you’ll have a disaster next.

One problem is that the database has not been generated with the same libdb version as the current one. To correct this, change your user to the cyrus admin user (normally cyrus) and execute the following command, while looking at the syslog files:

root@mail:/tmp# su - cyrus
cyrus@mail:/var/lib/cyrus$ ctl_cyrusdb -r

It is normal you don’t get any output from the command. The output goes into SYSLOG. When the recovery is successful, you’ll have this:

Feb 20 16:00:07 mail ctl_cyrusdb[31041]: recovering cyrus databases
Feb 20 16:00:07 mail ctl_cyrusdb[31041]: skiplist: recovered /var/lib/cyrus/mailboxes.db (124 records, 13092 bytes) in 0 seconds
Feb 20 16:00:08 mail ctl_cyrusdb[31041]: skiplist: recovered /var/lib/cyrus/annotations.db (0 records, 144 bytes) in 1 second
Feb 20 16:00:08 mail ctl_cyrusdb[31041]: done recovering cyrus databases

Here, you see that Cyrus found 124 mailboxes.

If this is not sufficient, you’ll have to delete the

contents and re-run

.

If this is still not sufficient, you’ll have to do the extreme: Rebuild all the

directory. To do this, first try to get a “text” version (export) of the mailboxes.db. If you manage to do this, you’ve saved. To export the list of mailboxes, do the following, as user cyrus:

cyrus@mail:/tmp$ /usr/cyrus/bin/ctl_mboxlist -d -f /tmp/mailboxes.db

This will output the users/mailboxes to stdout. Verify that it’s ok, then re-run the command and redirect the output to a file:

cyrus@mail:/tmp$ /usr/cyrus/bin/ctl_mboxlist -d -f /tmp/mailboxes.db > /tmp/mboxlist.txt

Then remove completely the

directory. Recreate it with the following commands:

root@mail:/tmp# /usr/bin/cyrus/tools/mkimap
root@mail:/tmp# chown -R cyrus:mail /var/lib/cyrus
root@mail:/tmp# /usr/cyrus/bin/reconstruct -r -f user

Here, you’ll have no output, meaning it found no users. That’s normal, as we just have a clean new mailboxes.db. If you’ve run the command reconstruct as root, do forget to immediately change back the roght to the files:

root@mail:/tmp# chown -R cyrus:mail /var/lib/cyrus

Now we just have to rebuild the mailboxes.db file:

root@mail:/tmp# su - cyrus
cyrus@mail:/tmp$ cat /tmp/mboxlist.txt | /usr/cyrus/bin/ctl_mboxlist -u
cyrus@mail:/tmp$ /usr/cyrus/bin/reconstruct -r -f user

Here, you’ll have a list of the found users in the database.

Now try to start again Cyrus.

Useful references

• http://www.irbs.net/internet/info-cyrus/0411/0412.html
• http://david.codebase.ca/index.cgi/os%20x/cyrus.writeback
• http://www.kalamazoolinux.org/pipermail/members/2004-July/011219.html
• http://www.afp548.com/article.php?story=20040824063737872
• http://www.die.net/doc/linux/man/man8/reconstruct.8.html