.Well-Known Directories

WriteFreely Installation
1

I am not finding it yet in searching, what process creates and populates the “.well-known” directories?

@matt pointed me in the right direction on Mastodon that my https://techzerker.com site is not serving up the .well-known addresses, hence no federation working. But when I look at my server, check with ls -a, on both sites I installed, there are no folders at all for that .well-known main folder or any sub-folders.

Figured I would be better to ask here so it’s searchable later vs. a discussion on Mastodon.

2

Hey, thanks for posting here. So the .well-known directory isn’t a physical one – it just holds routes that are dynamically handled by the web application. But based on our Mastodon thread and CloudFlare giving a 502 at those addresses, I’d suggest this troubleshooting path:

  • Make sure you can access /.well-known/webfinger?resource=acct:techzerker@techzerker.com if you send a request directly to your server (not through CloudFlare)
    • If you can access it that way, then see if there is a setting in CloudFlare that is blocking the .well-known path (or hidden directories) for your site. (I’m not familiar with CloudFlare, so I’m not sure if it exists.)
    • Otherwise if you cannot access it that way, I would assume that you’ve installed WriteFreely with a reverse proxy in front of it, and that the reverse proxy is blocking access to the .well-known path. Make sure it’s allowing requests there – often servers like Apache will automatically block access.
3

Thanks Matt!
I assumed they were physical folders, it’s a good chance it’s related to CloudFlare, as yes, I’m doing reverse proxy through Nginx, but it has the entry from the documentation in it for the /.well-known paths.

Hope your enjoying your Train trip, when I can it’s my preferred way to travel!
(I cross Canada every three weeks, so almost always flying…but personal trips, love the Train!)

4

Gotcha – yeah, then that’s what I’d assume is causing it. Definitely let us know what you find, if it is something with CloudFlare!

Thanks! I’m the same – usually flying, but taking the train whenever possible. I think this trip across the US is going to inspire a trip across Canada in the future :slight_smile:

5

It’s worth it, the VIA Rail trip across the country is relaxing, as VIA Rail has done interior renovations, but still uses the 60’s era streamliner looking steel sleeper cars. They are heavy enough that they are very smooth on the tracks, great for sleeping :slight_smile:

1 Like
6

Great to know! Think I’m sold :slight_smile:

7

Bypassing CloudFlare, and it looks like I’m still getting 502 from Nginx. The bypass is definitely now just doing DNS as I get certificate warnings, given my cert is through cloudflare :stuck_out_tongue:

Nothing looks out of place to me, but I’m still learning Nginx server blocks and formatting:

location ~ ^/.well-known/(webfinger|nodeinfo|host-meta) {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_pass http://localhost:8080;
    proxy_redirect off;
}

location ~ ^/(css|img|js|fonts)/ {
    root /var/www/techzerker.com/static;
    # Optionally cache these files in the browser:
    # expires 12M;
}

location ~ ^/images/ {
    root /var/www/techzerker.com;
}

location / {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_pass http://localhost:8080;
    proxy_redirect off;
}

While highly unlikely, I also tried disabling UFW Firewall on the server long enough to see if I was catching some port wrong, but no change, so it’s back on.

8

Yeah, the configuration looks good. Do your nginx error logs say anything about the 502?

9

I’m thinking a separate CDN in my work connection might also have delayed my results from bypassing CloudFlare, as I tried again with straight DNS, after restarting NGINX because I realized I didn’t have a dedicated Access Log for “just” this site, so added one…and it worked at:

https://techzerker.com/.well-known/webfinger?resource=acct:techzerker@techzerker.com
Returns a nice JSON page, and the updated log reflects that:

[25/Mar/2019:12:25:01 -0400] "GET /.well-known/webfinger?resource=acct:techzerker@techzerker.com HTTP/2.0" 200 355 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36"

Where in the main access log, once I found the entry from the many, many attempts, the access log at least does not say much else from what I can tell, beyond the 502:

[25/Mar/2019:11:01:24 -0400] "GET /.well-known/webfinger?resource=acct:techzerker@techzerker.com HTTP/2.0" 502 575 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36"

Error logs in the main Nginx configuration were not turned on, but I’ll turn them on and re-enable cloudflare to re-produce the error, and see if it captures anything. If not, I’ll have to ask CloudFlare, in case it’s a re-write rule of some sort needed.

I also don’t desperately need the full CloudFlare full protection with this site, like I did with WordPress with the constant vulnerabilities and endless security updates :stuck_out_tongue:

10

This is from the other site, but same server, while CloudFlare is enabled and shows the 502. It was installed identical to the TechZerker site, only difference is it’s on a different port of course:

2019/03/25 12:48:37 [error] 13631#13631: *53 connect() failed (111: Connection refused) while connecting to upstream, client: 172.69.46.5, server: drivingshift.com, request: "GET /.well-known/webfinger?resource=acct:scott@drivingshift.com HTTP/1.1", upstream: "http://127.0.0.1:8081/.well-known/webfinger?resource=acct:scott@drivingshift.com", host: "www.drivingshift.com"
11

Seems to be working for both right now, with CloudFlare turned on, after I broke the main site entirely with a big 502 error trying settings.

The setting I changed that seemed to impact it, is for the proxy_pass for .well-known was “http://127.0.0.1:8080” while the main site was “http://localhost:8080”.

I know localhost and 127.0.0.1 are the same, but somewhere in the Nginx back-end maybe it was picking up localhost and directing it differently than 127.0.0.1.

I am going to keep researching as that does not quite Jive with me as the cause, but before it started working that was the only setting I changed, make sure they were consistently localhost:8080 throughout the Nginx config file for each site.

Thanks for the help @matt, only strengthens my resolve to promote what your creating and supporting!

1 Like
12

Yep, looks good for me now too. Glad it’s working now!

That is pretty odd – I’m not sure if Nginx specifically handles 127.0.0.1 and localhost differently, but things can get messed up, for example if there’s no localhost entry in /etc/hosts pointing to 127.0.0.1. So I think it’s always safest to use the IP address instead of the hostname.