I have a laptop, a workstation, and a server at home that I use daily. I also have a collection of code, documents, and music that are useful to have locally on all three — especially the laptop when traveling. For a while I would just copy files over the network (NFS and CIFS), or use the server but this has gotten tedious as the amount of data has grown. So I went looking for a syncing app.

I had two requirements:

• It must not run as a service – I don’t want yet another program loading at boot time or hogging RAM. Transfers should use NFS. Preferable since I am already running it and for speed.
• It must be initiated from the client side – I don’t want to SSH into computer X to push or pull an update

Unison

Unison has received a lot of hype. It certainly shows a lot of potential. Amongst notable features, it supports bi-directional syncing. You can have changes in the local and remote directories and interactively merge them. It also has a GUI for simplifying this and handling collisions. During my test, performance was terrible and it crashed during the merge. I read somewhere in the FAQ that using Unison with NFS isn’t ideal. It prefers to use SSH or a socket, which goes against one of my requirements. In short, this is a program to watch and it may be suitable for smaller file sets — but it simply did not work well here. The final strike is that it is no longer a research project and only lightly maintained.

rsync

rsync is a very powerful program. Its method of file transfer minimizes I/O and is fast. It is essentially unidirectional, so it lacks the power that Unison has in this regard. For my use case, this won’t be a problem since updates happen on one system at a time and are usually pushed to the server. Gentoo users will be all to familiar with rsync when updating portage with ‘emerge –sync’.

Using rsync is simple. ‘rsync -av SOURCE DESTINATION’ will be suitable for most jobs. A quick view of the man page will give a rundown on the options. Using a hub and spoke topology, I can sync all three in any direction: laptop <–> server <–> workstation.

I’m not sure why I waited so long to do this. It is incredibly efficient and easy and I recommend a similar setup if you have two or more computers. It nicely complements a version control system for things that don’t need to be tracked over time.

I’ve had a pretty advanced email system running at home (Postfix, SpamAssassin, Dovecot, Fetchmail) for over a year. The original goal was spam filtering for some 10 year old POP3 mail accounts from my old ISP that were heavily spammed. I couldn’t be more pleased with the system; false positives [not spam] are next to zero and very few false negatives [spam] slide through. I might even write a guide for doing a similar setup in the future, but not today.

One of the kinks along the way involved fetchmail. There was an email account that I needed delivered to two separate local user’s inboxes. fetchmail and alternative getmail have no way of doing this natively from what I could tell. You simply can’t have the same mail account twice. The question on IRC brought about strange solutions such as using procmail or aliases, but there were several disadvantage I could think of, especially involving the per user Bayes learning provided by SpamAssassin.

So I got to thinking, what if I simply fooled fetchmail into thinking that the account was actually two different accounts or servers. And here it is, .fetchmailrc.

poll bowling2-kev
uidl
proto pop3
auth password
via pop.isp.tld
user “bowling@isp.tld”
pass “supersecretpassword”
keep
is kev009

poll bowling2-bowling
proto pop3
auth password
via pop.isp.tld
user “bowling@isp.tld.”
pass “supersecretpassword”
is bowling

There are two key things going on here. The first account uses the keep attribute, similar to the “leave mail on server” option in client software. The interesting bit is in the second account. If you look on the line beginning with ‘user’, there is a trailing period. I am simply taking advantage of the fact that fetchmail thinks this is a different host. In reality the final period is the FQDN (Fully Qualified Domain Name), including the root DNS zone so it is the same host.

I speculate that if entries were added to the /etc/hosts file, this could be scaled to more than two users. Also, uidl and keep across all the accounts could prevent the chance of a mail going to only the final fetchmail entry, if it arrives between fetches. The disadvantage would be overflowing mailboxes if they are not externally pruned, and longer fecthes.

So there you have it, a quick and dirty hack for fetchmailing one remote account to two local users.