The other week I saw this toot from the Tor Project:

Jul 9
The Tor Project                                @torproject@mastodon.social

Starting today, we're running a month-long campaign to raise awareness
about onion sites, and if you enable Onion-Location on your site, you
could win Tor swag! Join us to make a more secure web! #MoreOnionsPorFavor

Read our blog for all the details: https://blog.torproject.org/more-onions-porfavor

I've been interested in the privacy oriented Tor network for many years, but I haven't served any content on there before. I've used the Tor browser just for fun a few times (and it's easy to get going with), but I haven't made regular use of it. What they are trying to do with this campaign addresses something I've been missing from it - more just regular content, served straight within the Tor network itself, without the need to have exit nodes to "reach outside".

So... I gave it a shot. It was really simple to set up. I set it up as described here:

https://community.torproject.org/onion-services/advanced/onion-location

The linked article is actually for how to let visitors - connecting the old fashioned way - know that the content is available over Tor, but the article also covers how to configure the other server details.

All this was simple to set up, but I've stumbled upon one isue, which is that nginx just... stopped working after a few days. This blog went down, and nginx started saying something like this in the logs:

"/var/sock/tor-xhrpb.com.sock failed (98: Address already in use)"

... which I guess has to do with the fact that the Tor server regularly restarts itself in order for clients to reach it in a different way or something. As you can tell I haven't really researched this.

Anyway, restarting tor@default.service and then restarting nginx.service seemed to solve the issue.

I don't really get why I'm having this issue though, as I think the Tor service should create the socket and nginx should just set up a listener for it. There shouldn't really be a conflict.

My current workaround (not at all a proper solution) is this:

/etc/systemd/system/nginx.service.d/override.conf:

[Unit]
PartOf=tor@default.service

/etc/systemd/system/tor@default.service.d/override.conf:

[Service]
ExecStartPre=/bin/rm -f /var/run/tor-xhrpb.com.sock

The first one, in short, makes nginx.service restart when tor@default.service restarts. The second one makes sure to remove the socket before tor@default.service starts.

The simple way to make changes to systemd services is to run "systemctl edit ", that way systemd creates the proper files in the right places and you don't have to run systemctl daemon-reload after manually changing the files.

The reason for me sharing this is just to share what some in-the-moment troubleshooting can look like. The proper solution, the ideal, is to figure out exactly what isn't working right, but in reality one doesn't always have the time to do that.

For the services I'm running, the "solution" above is perfectly adequate for me. Personally, the most important thing when making workarounds like this is to document it properly, so that one might come back and fix it later. This is especially important if you're working in teams with other people.

Lastly, back to the topic at hand; What the added HTTP header does is that if you're browsing with the Tor browser and visits this site at https://xhrpb.com, the browser will let you know that it's also available on this address:

http://hppdzw5resw4k7v66yiuiooriqkh3mhnn4jxkm4mzy4rjyxvstmzgoad.onion

It then gives you the choice to browse on that address instead.

I hope I'll see a lot of Tor sites in the future.