Category: daemon

Hosting your own calendar server

Posted on by pica

I recently came across an interesting story by Cory Doctorow entitled ‘Scroogled‘ in which Google becomes a malevolent force with its comprehensive archive for each user. With that in mind, I began to consider the information I put into Google’s server (the irony of writing this post on Google-owned blogger.com is not lost on me). I use a lot of their services, and thought about which one I could most easily replace. Google’s calendar offering seemed a good place to start since I didn’t really interact with it through Gmail, but accessed it through my phone and through Thunderbird on my other computers.

Some brief searches found a list of potential calendar servers, but the one which stood out to me was radicale. This CalDAV server is a nice simple Python server, with no dependencies besides Python itself. The default configuration is pretty well set up, with a few changes needed before you can start accessing your server.

The default port from which the CalDAV calendars are served is 5232, so I opened up that port on my router so that I could access the calendars from anywhere. I had to install a CalDAV app called CalDAV-sync-beta on my phone to be able to view my calendars on the native calendar widgets. The Lightning plugin for Thunderbird can load the radicale calendars by default. Adding them is a simple walk through the wizard, selecting the option to add a new calendar “On the network:”, then choosing CalDAV as the type of calendar. The syntax for the calendar location is

http://your-home-server.com:5232/username/calendarname

replacing your-home-server.com with either your server’s IP address or its URI. Likewise, username should be the user who’s launched the radicale daemon (I suggest this is not root). The calendarname value can be anything you like, but it’s probably best to make it something memorable, or at least descriptive.  For the CalDAV-sync-beta app on Android, the process is similar (Settings > Accounts & sync > Add account and select CalDAV. I found it easier to select “Manual mode” for configuring the calendar. The syntax for the calendar address is similar to the Lightning example above:

http://your-home-server.com:5232/username/

except you’ll notice I’ve omitted the calendarname value at the end. This is because CalDAV-sync-beta will search for all the calendars you have at that location and offer you the option of syncing them all or just certain ones. You can specify the full path as in the Lightning example if you know you will only want to connect to a single calendar on this server. The username value needs to contain a value, but you can omit the password (we have not set up a password protected calendar).

I have yet to manage to get radicale to accept a username and password, so the calendars are open to the public, which is probably something of which you should be aware.

Overall, it’s been working well, and disentangling myself from at least one Google service is a start.

Dynamic DNS services and ddclient

Posted on by pica

Since changing from O2 to Virgin broadband, I’ve had to hope my dynamic external IP address didn’t change too often. As it turns out, Virgin appear to have a very slow turnover of IPs for home customers, since I’ve had the same one since we changed. I wrote a little script to scrape my IP from http://checkip.dyndns.org every 10 minutes and save the output do Dropbox, but this seemed less than optimal.

I recently read about a nifty little client called ddclient. If your router doesn’t support updating a dynamic DNS service (such as www.dyndns.org) for you, then having a tool like ddclient do it for you is pretty handy.

It’s a little perl utility, which on Slackware requires some external dependencies (perl-IO-Socket-SSL, Net-SSLeay, libwww-perl, perl-html-parser and perl-html-tagset) available from SlackBuilds.org. Set up is pretty straightforward, and the default configuration file (/etc/ddclient/ddclient.conf) is pretty comprehensive. I found, however, it was a bit overwhelming, and the documentation on the website was more useful. In the end, my configuration looked like this:

# Stripped down version of the config file.
# Easier to manage, I think.

daemon=600                      # update every 10 minutes
syslog=yes                      # write to syslog
mail=root                       # all messages go to root
mail-failure=root               # failures sent to root too
pid=/var/run/ddclient.pid       # runtime pid file
# host setup
ssl=yes                         # use ssl when updating hostname
protocol=dyndns2                # using dyndns.org
use=web, web=checkip.dyndns.org/, web-skip=’IP Address’
#use=web                        # get ip from internet
login=myusername                # username
password=mypassword             # duh…
my.hostname.com                 # my hostname

I set the daemon to run every ten minutes and it uses www.dyndns.org to update the IP associated with my.hostname.com. I altered the line use=web to use=web, web=checkip.dyndns.org/, web-skip=’IP Address’ because I was getting errors with ddclient finding the checkip.dyndns.org address. In theory, this forces ddclient to parse the output from checkip.dyndns.org correctly.

In the end, ddclient does a very similar thing to my suboptimal approach, though it updates my dyndns account for me rather than me having to do so from the Dropbox text file to which my script saved my IP address.