Skip to navigation

Quickly configure exim (MTA) on Gutsy

April 14th, 2008
sudo dpkg-reconfigure exim4-config

This will give you a graphical interface and guide you through each step to get the basic setup.

Connecting Logitech Quickcam on Xubuntu Gutsy 7.10

April 14th, 2008

Works almost out of the box (Logitech Quickcam Messenger for 15 GBP on Amazon UK). Well, worked completely out of the box on the laptop. On the desktop, camorama complained “could not connect to device (/dev/video0). Please check connection”, and Skype said it didn’t find a device. However, /dev/video0 looked just the same as on the laptop:

mpromber@audrey:/dev$ ls -l video0 
crw-rw---- 1 root video 81, 0 2008-04-14 16:48 video0

Turns out I didn’t have a group video so I had to create it and add my user (via Xfce Menu → System → Users and Groups). Log out and back in; works.

Sync tomboy via SSH

April 14th, 2008

Tomboy is a nifty little wiki-like application for taking notes on your desktop. You can sync two or more computers via SSH.
If you have an account on a remote server and SSH access, the following screenshot shows how to do it. Note that I set restrictive permissions on the sync folder. For some bizarre reason, Tomboy’s sync makes all the copies of your notes on the server world readable and world executable, so if you share the server with other users you definitely want to put everything into an upper-level directory that only you can access.

Setting up tomboy to sync to a remote server via SSH

Note that this syncs several machines via the remote server. If you don’t have access to a remote server, set up ~/tomboy-sync on one of your local machines. Then sync the other machines to that via SSH just as in the setup above, and sync Tomboy on the machine that hosts ~/tomboy-sync to that folder via Tomboy’s “sync to local folder” option.

Also note that I can just say “isomerica” here instead of the full server name because I have an entry for that host in ~/.ssh/config that looks something like this:

Host isomerica

Shell script to periodically check mail logs (and msmtpQ queue) and notify user by mail

April 13th, 2008

As said in this previous post, I generally really like the speed of having

set sendmail_wait = -1

in my ~/.muttrc, but mutt doesn’t let me know if there are any error messages. That’s not good, and it would be ironic to gain a few seconds when hitting y in mutt just to nervously dig around in error logs all the time. In addition, while I like my new mail queue setup for the laptop,I find that, too, a bit too silent: the mail gets queued without any notification whenever I’m offline, and queued mail doesn’t get sent automatically when I’m back online (I actually prefer that — better that than inadvertently sending off mails that I was planning to delete from the queue).

So I wrote a shell script that checks both for errors and for queued mail and notifies me via the local exim4 MTA with messages that go into /var/mail/username. I’ve put that shell script online: checklog. This is all pretty basic stuff, but it might come in handy for someone, or if you’re new to shell scripting, you can never have too many examples.

I’ve put it into my ~/bin, made it executable, and call it every two hours and at reboot from ~/.crontab.

0 */2 * * *  /home/mpromber/bin/checklog
@reboot      /home/mpromber/bin/checklog

To make it take effect:

crontab ~/.crontab

On the laptop, I’ve also put a symbolic link to that script into /etc/acpi/resume.d so it gets executed on waking up from suspend, because that’s likely to have a correlation with wanting to be reminded of queued mail:

sudo ln -s /home/mpromber/bin/checklog /etc/acpi/resume.d/

Note that I had to give the symlink a name ending in “.sh”, since /etc/acpi/ above that directory only calls scripts with that pattern:


# Source from /etc/acpi/resume.d/
for SCRIPT in /etc/acpi/resume.d/*.sh; do
    if [ -x $SCRIPT ]; then
        . $SCRIPT

Mutt with msmtp and a mail queue

April 11th, 2008

If you read and send a lot of e-mail, you want to use the mutt mail client. If you travel a lot, you want to be able to compose e-mails offline and then send them off when you’re back online. Mutt has always insisted on being a pure mail user agent (MUA), not a mail transport agent (MTA), so it doesn’t handle a mail queue. Fine.

On a Linux system, you usually have a fully functional MTA like exim or postfix, and those can handle mail queues. However, without additional tweaking, sending mail using these MTAs will always carry the stigma of originating from a non-fixed IP without a valid domain name if you use them on your laptop. Besides, full-fledged MTAs should really be maintained carefully if you allow sending mail to outside IP addresses. So most likely, you’ll want to go with something more low-key, like a lightweight SMTP client that just authenticates with a “real” SMTP server (like that of your ISP) and lets that outside server send the mail. One such nice client is msmtp. Msmtp is really easy to configure and has the benefit of handling multiple accounts. A starting ~/.msmptrc file could look as simple as:

account default 
auth plain	 
user your_username 
password your_passwd
tls_trust_file  /etc/ssl/certs/Thawte_Premium_Server_CA.pem 
logfile ~/.msmtprc-log

And correspondingly, in your ~/muttrc, you would put:

set sendmail="/usr/bin/msmtp -a default"

The problem is, msmtp doesn’t actually handle mail queues. While you’re offline, you can still compose messages in mutt and keep adding them to the “postponed” folder, but when you’re back online, you’ll have to manually send each of these messages individually, which is not good.

When I googled for a solution I found that Chris Gianniotis had actually written two shell scripts to handle this situation, however, links to files of the scripts that I found via Google were defunct. The only instance I could actually find of these scripts is in this archived message of the msmtp-users mailing list. (The link is a post by the autor of the scripts, and is recommended reading for more information). (Addendum: See comment #1 for official location of scripts).) However, some of the long comment lines in the scripts are interrupted by linebreaks on that URL, so I had to remove them manually. To spare you the pain of doing that yourself, I have uploaded the two scripts here in a slightly modified version:

My modifications are:

  • Cleaned up comments from version found online, i.e. removed accidental line breaks
  • Modified location of queue directory and log file to suit my own needs: you are supposed to adjust them to your own needs anyway.
  • Changed the invoked shell from #!/bin/sh to #!/bin/bash, since msmtpq otherwise kept hiccuping on the declare -i CNT bit (then I changed it for both scripts)

The way this works is:

  1. Put the two scripts somewhere you like, say into ~/bin and make them executable, e.g:
    cd ~/bin
    chmod 744 msmtpQ msmtpq
  2. If needed, modify the mail queue and log file locations in each script, near the top.
  3. Create the mail queue directory (the script will not create it). If you haven’t changed what it is:
    mkdir ~/.msmtp.queue
  4. In your ~/.muttrc,
    set sendmail="~/bin/msmtpQ"

    (adjust path if you put the scripts somewhere else).

All set. You should now be able to send mails when you’re online. When you’re offline, sending the mails actually moves them to the queue. When you’re back online, you say:

msmptq -r

to send the mail out. (Type msmtpq to see more options, like deleting messages from the queue).

Optionally, the author of the scripts also recommends setting

set sendmail_wait= -1

in your ~/.muttrc. I didn’t know about this, and it’s great in general — mutt backgrounds sending the mail, which means you don’t wait forever for large attachments to go out, or on a slow connection. You can of course use this with regular .msmtp as well, or with any other MTA. However, be warned: Even though the the mutt manual claims that “if there is some error, you will be informed as to where to find the output,” this didn’t happen when I tested it (using just regular msmtp). I changed my password in the ~/.msmptrc to an incorrect one, but mutt happily backgrounded the msmtp process and never complained. So I’d recommend setting a logfile in ~/.msmtprc and checking that for errors from time to time. (Addendum: See the next post for a script that checks the error logs for you.


To make it even easier to send queued mail, I’ve put together a small script that incorporates the different msmtpq options: You get a quick overview over all queued messages, can either send them all at once, delete individual or all messages.