3

I've been trying to make a taskd server work on my computer (Arch Linux) for days. The problem I'm facing now is that taskd's config documentation (https://taskwarrior.org/docs/taskserver/troubleshooting-sync.html) says that I have to use the output of hostname -f as an address (I do not know what 'CN' abbreviates). I've also tried with my local IP address starting with 192.168 but that gave me the handshake error you can find in the troubleshooting guide I linked.

I started investigating a little, because I couldn't access my taskserver from other machines. I found this:

When I listen to the port I use, let it be 54000, using nc -l -p 54000, I can see this as the output of ss -lntu | grep 54000:

tcp    LISTEN   0        10                0.0.0.0:54000          0.0.0.0:*

Whereas when I start taskd, which listens on the same port, ss gives me:

tcp    LISTEN   0        4               127.0.0.1:54000          0.0.0.0:*

Now from a different machine, I tried checking the port while listening with nc -vv 192.168.x.y 54000 (with the server's IP address) and I found that when the local address is 0.0.0.0, the port shows as open. Otherwise it shows up as closed. I think this is because 127.0.0.1 is essentially localhost and I can't see that from my network?

taskd also has a config file with a server option where I entered the output of hostname -f, which is watermelon.localdomain, as I was instructed by the documentation. I suppose that's what's translated to localhost, right?

I would greatly appreciate your help, thanks in advance!


UPDATE 2018/04/21

I managed to solve the problem by setting the server variable in the config to 0.0.0.0:54000, this way I got taskd to listen for any address on port 54000. Now everything works beautifully. The documentation of taskd was a bit vague on the topic I guess.

  • 2
    CN is an abbreviation for Common Name (usually a fully qualified domain name). So if hostname -f returns watermelon.localdomain, the instructions are saying to use e.g. CN=watermelon.localdomain. According to the taskd website, CN=localhost is the default value and thus is not valid. Regarding 127.0.0.1 vs. 0.0.0.0, 127.0.0.1 is a local loopback address and typically indicates the port is only available to processes on the same machine. In contrast, 0.0.0.0 in this case effectively means "all IPv4 addresses on the local machine" (incl. any IP that is network-accessible). – Anaksunaman Apr 17 '18 at 22:36
  • 1
    Concerning the configuration files, my understanding is that the entry should be something like e.g. taskd.server=watermelon.localdomain:54000 (but I could be wrong). – Anaksunaman Apr 17 '18 at 22:36
  • @Anaksunaman I think you're right... But why does the server listen on the loopback address then? I don't get it. – bertalanp99 Apr 18 '18 at 14:42
  • 1
    My assumption would be that 127.0.0.1 is likely the first (or only) IPv4 address available to watermelon.localdomain (assuming you are using that in your configuration). The taskd website does indicate you can potentially use e.g. your_network_ip:54000 (vs. e.g watermelon.localdomain:54000) - taskwarrior.org/docs/taskserver/protocol.html – Anaksunaman Apr 19 '18 at 21:49
  • @Anaksunaman I managed to solve the problem --- I was really dumb it seems (see updated question). Thanks for your help! – bertalanp99 Apr 21 '18 at 10:29
4

Sockets are configured to listen on a specific IP and Port. There are typically two primary configurations you would use for a Socket and a third that isn't as common, but comes in handy.

1) To only allow communication from the machine running the service

This is configured when you see 127.0.0.1:54000. ONLY the host machine can access this service. You can use something like a reverse proxy to allow access externally, but nothing on the network will be allowed to connect to it.

2) To all machines on any network reachable from the server

This is configured when you see 0.0.0.0:54000. This allows anything to talk to this service as long as the packets can get to it.

3) To only a specific network the server is joined to

This is configured when you see 192.168.0.2:54000 (or whatever IP). This means that ONLY this subnet of this network is allowed access.

If you want to allow your service to be connected from other machines on the network, it needs to be bound on 0.0.0.0 or the local IP.

  • Thanks for your detailed answer! Do you have any idea how I should make taskd listen on 0.0.0.0 then? – bertalanp99 Apr 18 '18 at 14:41
  • it's likely in the config for taskd. Look for some kind of entry indicating 'bind port' or 'bind address'. It might be listed as 127.0.0.1:54000 already. But the best thing is to check the docs for taskd – Andrew Apr 18 '18 at 15:24
  • I found this relevant question just now: stackoverflow.com/questions/44902884/… The answerer mentions 'ensuring /etc/hosts was set with the externally facing IP addresses'. Could you please explain what that means and whether that is a good idea? It seems to have worked for the OP of that question. – bertalanp99 Apr 18 '18 at 16:15
  • 1
    /etc/hosts has no impact on the service's ability for other hosts to connect. It does allow the local machine to properly reference iteslf, but there should be no reason to change it as long as the hostname still matches the systems' configured hostname. – Andrew Apr 18 '18 at 20:59
  • I managed to solve the problem since (see updated question). You helped a lot though, thanks. – bertalanp99 Apr 21 '18 at 10:30

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.