It’s frankly baffling to me that we have both a Webserver module and a LAMP module. More so that their respective capabilities are so different (to name two, multiple vhosts with the same instance, SFTPGo). More so yet that, though I know there are other topics that have talked about the LAMP module, I can’t find them using the search feature here, looking for lamp or for ns8-lamp.[1] But with all of that said…
Pretty simple issue, really. I need to upload a .zip file to my LAMP instance. And because ns8-lamp doesn’t include any UI to manage files the way the Webserver module does, I decided to upload it to one of the webserver vhosts and then wget it inside lamp1. I thought that was a good idea, anyway:
root@lamp:/app# wget https://www.familybrown.org/foo.zip
--2025-10-06 13:39:05-- https://www.familybrown.org/foo.zip
Resolving www.familybrown.org (www.familybrown.org)... failed: Temporary failure in name resolution.
wget: unable to resolve host address 'www.familybrown.org'
Really? It isn’t like DNS is completely broken in the container:
root@lamp:/app# curl google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
But it doesn’t want to resolve anything that’s set up as a virtual host using the Webserver module.
This seems to be because the search bar at the top is broken–if I use the search button in the upper-right corner, it works ↩︎
[root@ns8 ~]# dig www.familybrown.org
; <<>> DiG 9.16.23-RH <<>> www.familybrown.org
;; global options: +cmd
;; connection timed out; no servers could be reached
[root@ns8 ~]# dig www.familybrown.org @8.8.8.8
; <<>> DiG 9.16.23-RH <<>> www.familybrown.org @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47375
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.familybrown.org. IN A
;; ANSWER SECTION:
www.familybrown.org. 300 IN A 104.21.58.117
www.familybrown.org. 300 IN A 172.67.159.105
;; Query time: 21 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Oct 06 10:49:59 EDT 2025
;; MSG SIZE rcvd: 80
[root@ns8 ~]# dig www.familybrown.org @1.1.1.1
; <<>> DiG 9.16.23-RH <<>> www.familybrown.org @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31549
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.familybrown.org. IN A
;; ANSWER SECTION:
www.familybrown.org. 300 IN A 104.21.58.117
www.familybrown.org. 300 IN A 172.67.159.105
;; Query time: 9 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Oct 06 10:50:07 EDT 2025
;; MSG SIZE rcvd: 80
[root@ns8 ~]#
I’m thinking this may be something Tailscale-related. Let me check something.
Yep, it’s always DNS. I doubt anyone else will be doing the same thing to benefit from this explanation, but just in case…
One of my domains is familybrown.org. I use FQDNs in that domain for both public and LAN resources.
I’ve since realized that it’d be better if I’d set up something like lan.familybrown.org for my local resources, then they’d have FQDNs like truenas.lan.familybrown.org. That would have avoided this problem.
I’m running Tailscale on my NS8 host, connecting to @mrmarkuz’ Headscale app as a coordination server
I’ve configured Headscale to point to my local OPNsense router (192.168.1.1) for DNS for anything in familybrown.org
My OPNsense box is connected to the same Tailnet, and is advertising a route of 192.168.1.0/24
My NS8 box is a VPS; it isn’t on my LAN
And Tailscale for Linux doesn’t turn on --accept-routes by default when it logs in.
The result: when my NS8 box wants to resolve something in familybrown.org, it asks the Headscale server, which in turn refers it to 192.168.1.1. And since it has no route to 192.168.1.1, resolution fails. Running tailscale set --accept-routes resolves the issue.