Configuring Taskwarrior Server on Debian Buster
I have been a long time fan of taskwarrior, the command line todo-manager. It does almost everything I want and it is very configurable, so I can change the things that I don’t want. I have gone astray to other programs and services, but I’ve always come back. Fast, open source, self hosted, terminal oriented, complete and configurable, what’s not to like.
Well, configuring taskwarrior server, that’s what’s not to like. Each time I returned I had to set up and configure the server again and it always took time and some debugging. As I’ve gone through the whole process again this morning, I thought I’d jot some notes down. I am not going to repeat all steps, because there are a lot of them. (Probably the reason it never goed smooth.) As basis I used these guides from Vultr, describing the process for Debian 9:
- https://www.vultr.com/docs/install-taskserver-taskd-on-centos-7 (for the client part)
These are the things to take into account:
Editing the vars file
The script that generates the server certificates uses
/usr/share/taskd/pki/vars for the variables, so you must edit it for your situation. One of variables is the
CN. As an example value is given:
taskd.example.com. I followed the idea of creating a separate subdomain. I thought that would work, because the DNS entry for my domain has a wildcard and so it would point to the same ip as the main domain anyway.
This is true, but later on taskwarrior server gets confused and gives this error:
Certificate fails validation, Handshake failed.
Turns out that the value for
CN must match the output of
hostname -f on the server and this output is the main domain.
See here for more info: https://taskwarrior.org/docs/taskserver/troubleshooting-sync.html
Client setup guide - Step 5
After the guide on how to set up the server, we get pointed to the CentOS guide, Step 5 to continue the setup of the group and the client certificates. We get warned that we must substitue the
/usr/share/taskd/pki/, which is correct, but don’t forget to also switch back to root user before starting.
Client setup guide - Step 6
Two things. First, we are going to create an organisation, but that will fail with the error:
Failed to create organization.
This is because the directory where that information is to be stored is not writable for the server user.
sudo chown Debian-taskd.Debian-taskd /var/lib/taskd/orgs
This was the ticket that gave me the clue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860329
Apparently they fixed the bug because the directory was present on my system. But unfortunately, it belonged to root, so taskwarrior could still not write to it.
Second, the user under which the server runs is
taskd. So the commands should start with:
sudo -u Debian-taskd taskd ...
sudo -u taskd taskd ...
Preventing multiple instances of recurring tasks
By default, every taskwarrior client checks whether it is time to generate a new task from a recurring task. In a setup with multiple clients this can lead to doubles. The task command checks whether it is necessary to generate a new instance each time it runs. If you run it before syncing with the server, the client does not know that another client already might have generated it. So all clients generate the next instance and then sync them back and forth, making you scratch you head and think “But I already did that task, didn’t I?”
There is however a config option for the client that can disable this behavior:
recurrence. So an option is to choose one client instance that is responsible for generating instances of recurring tasks and set
recurrence=no for all the others. It is best to pick the client that is used most for this, because the generating only happens when the task command is executed.
I have a client configured on the same machine as the server runs, so I can ssh into it and do task stuff if necessary. I picked this client and configured a cron job to run the task command periodically:
# in the crontab of your user */5 * * * * task && task sync
man taskrc for more info.