set up local DNS using Pi-hole + nginx + audiobookshelf
from happeningtofry99158@lemmy.world to selfhosted@lemmy.world on 22 Jul 02:40
https://lemmy.world/post/33298305

I’m trying to set up local DNS using Pi-hole.

I have successfully set up Pi-hole and added a local DNS record local.com, pointing it to the server running the Pi-hole container 192.168.0.101.

Then I set up the Audiobookshelf container using the guide from Audiobookshelf, where I set up Nginx Proxy Manager with the following compose file:

services:
  nginx-proxy-manager:
    image: docker.io/jc21/nginx-proxy-manager:latest
    container_name: nginx-proxy-manager
    ports:
      - 80:80
      - 443:443
      - 81:81
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    restart: unless-stopped

And Audiobookshelf with the following compose file:

services:
  audiobookshelf:
    image: ghcr.io/advplyr/audiobookshelf:latest
    container_name: audiobookshelf
    volumes:
      - ./audiobooks:/audiobooks
      - ./podcasts:/podcasts
      - ./metadata:/metadata
      - ./config:/config
    restart: unless-stopped
networks:
  nginx:
    name: nginx-proxy-manager_default
    external: true

I did not specify a port, hoping that Nginx could manage it.

Then I set up Nginx Proxy Manager following the guide from Audiobookshelf by adding a proxy host. Trying to resolve audiobookshelf.local.com to I simply followed the guide and wasn’t sure why the “Forward Hostname / IP” should be the container name audiobookshelf.

I also created a self-signed certificate.

But I cannot access https://audiobookshelf.local.com/ or http://audiobookshelf.local.com/ (it automatically forwards to HTTPS).


I tried adding a local DNS record:
audiobookshelf.local.com192.168.0.101 in Pi-hole.
Now, when I access audiobookshelf.local.com, the site shows:
502 Bad Gateway – openresty


I think the problem lies in the Docker network setup. I suspect the Audiobookshelf Docker container is not communicating with Nginx.


Would appreciate any help!

#selfhosted

threaded - newest

pticrix@lemmy.ca on 22 Jul 03:13 next collapse

Just to make sure, your issue is :

But I cannot access audiobookshelf.local.com or audiobookshelf.local.com (it automatically forwards to HTTPS). If so, well, you’re forcing SSL, which means it’ll automatically transmit http request to https. If you don’t want that, turn it off. Anyway, it’s going to be used only locally, correct?

happeningtofry99158@lemmy.world on 22 Jul 03:55 collapse

I have turned it off and tried again, this time it allows me to go to audiobookshelf.local.com, however still giving me the 502 Bad Gateway error.

Anyway, it’s going to be used only locally, correct?

yes that’s correct. But I still want to use self signed certificate just for extra security and get to know how to successfully configure it.

SaltySalamander@fedia.io on 22 Jul 20:02 collapse

But I still want to use self signed certificate just for extra security and get to know how to successfully configure it.

Then buy a real domain name and do it properly.

Malasaur@sh.itjust.works on 22 Jul 04:12 next collapse

I’m pretty sure you have to specify a different port. Audiobookshelf uses port 80 by default - which is already taken by NPM - and since you’re not mapping it to any other port those services will conflict.

Map the port to something easy to remember in the compose file. Not only is it required in your setup but it is good practice. If you have to manage a lot of services, it is hard to keep track of all the ports they use if you keep them on their default values. I personally chose a port range (like 12300 -> 12399) and map all of my services respectively (Komodo to 12300, Authentik to 12301, etc.).

Also remember to update the port in your NPM config.

TL;DR: Audiobookshelf’s default port is 80, which conflicts with NPM. Change it.

happeningtofry99158@lemmy.world on 22 Jul 04:46 next collapse

thank you!

I have added

    ports:
      - 13378:80

in audiobookshelf docker compose and changed npm settings

<img alt="" src="https://lemmy.world/pictrs/image/dc63e3ef-5eed-444b-8fd6-0651a909b319.png">

But it still gives me the same 502 Bad Gateway error.

Malasaur@sh.itjust.works on 22 Jul 07:09 next collapse

I’ve just noticed: you’ve set your forward hostname/IP to audiobookshelf. That should either be your PC’s IP address (if you’ve set up a static one in your router’s panel) or its hostname. Unless you’ve named your PC audiobookshelf it still won’t work.

clmbmb@lemmy.dbzer0.com on 22 Jul 09:39 collapse

This is about addressing the containers in docker. It has nothing to do with the local network.

MysteriousSophon21@lemmy.world on 22 Jul 18:44 collapse

You’re missing the networks section in your audiobookshelf service definition - add networks: [nginx] to your audiobookshelf service to actually connect it to the network (just defining the network at the bottom doesn’t automatically attach your service to it, which is why npm can’t reach it and gives you that 502 error), and if you’re an audiobook fan you might wanna check out the soundleaf app for ios which works great with audiobookshelf.

BigDogDave@lemmy.world on 22 Jul 06:17 next collapse

If the port isn’t being explicitly exposed then it won’t expose by default. I have my containers set up in a similar way where nginx has it’s own network and I attach any containers I want to proxy to the same network. On most cases I’m able to remove the ports section from config and point nginx at the name of the container, and the container’s default http port. The way OP originally configured this should be fine IF nginx and audiobookshelf are on the same docker network.

Malasaur@sh.itjust.works on 22 Jul 07:28 collapse

I honestly didn’t know that. I personally just configure a specific port for each stack and have NPM forward it directly without configuring any network.

I just noticed OP did configure a network, but tbh I don’t know how they work exactly and gave recommendations on what I knew.

If using networks is the standard way or OP feels better off that way then I’ll leave them to it

clmbmb@lemmy.dbzer0.com on 22 Jul 09:45 collapse

There’s no conflict regarding ports. Each container can have the same ports open. You’re thinking about the host network here, but it’s not the case.

Swordcutlass@lemmy.world on 22 Jul 04:56 next collapse

Are both containers connected to the same custom docker network? NPM might need to be connected to both a custom docker network and an bridge\external network.

happeningtofry99158@lemmy.world on 22 Jul 05:13 next collapse

I think they are? I have used network setting in audiobookshelf

networks:
  nginx:
    name: nginx-proxy-manager_default
    external: true

I think this allows audiobookshelf container to use the external container generated by nginx by default

mhzawadi@lemmy.horwood.cloud on 22 Jul 06:36 collapse

No, the compose file lists the network but the container is still in its own network.

You need to add this to the container

    networks:
      - nginx-proxy-manager_defualt
rumba@lemmy.zip on 22 Jul 04:57 next collapse

Start a console on NPM. See if you can curl or wget the target.

Start with IPs and ports. Then move to DNS.

NPM’s configuration never felt terribly comfortable to me.

Another common problem is to unintentionally set your container up where URLs require SSL. When you hit the container page the URL call backs can end up with HTTPS.

BigDogDave@lemmy.world on 22 Jul 06:20 next collapse

I can’t be certain here that the network configuration you’ve supplied will allow nginx to connect to audiobookshelf. If I were you I’d create a named docker network and connect both npm and audiobookshelf to it as described in their best practice documentation: nginxproxymanager.com/advanced-config/#best-pract…

A 503 indicates that NPM can’t see the service you’re trying to proxy to.

happeningtofry99158@lemmy.world on 22 Jul 11:12 collapse

Thank you! Can you also explain the difference between

networks:
  default:
    external: true
    name: scoobydoo

and

networks:
  scoobydoo:
    external: true
BigDogDave@lemmy.world on 22 Jul 17:52 collapse

default in this example is the actual name of the network, in this case we’re modifying the default network. external: true declares that the network has already been created, name: scoobydoo is a way of customizing the name of the default network.

Brkdncr@lemmy.world on 22 Jul 06:36 next collapse

I don’t see an immediate issue but I do see some general issues.

Unless you own local.com, don’t use it.

While you could use .local as your tld, I wouldn’t do that either. You can buy a domain name for cheap and really that’s the way to go.

Also, reference your FQDN and not your hostname. Don’t expect hosts to fill in the blanks.

tburkhol@lemmy.world on 22 Jul 09:43 collapse

Second not using local.com If OP doesn’t want a real domain, use an unresolvable TLD, like “private” (so, pihole.private, audiobookshelf.private), but a real domain will just work better, will let them use real TLS certs, and prevent problems from apps bypassing system DNS. Even if it’s not as pretty or memorable as the hijacked domain name.

ShortN0te@lemmy.ml on 22 Jul 07:39 next collapse

Based on you screenshot from the NPM Dashboard there seems to be something wrong. In the setup window you show that you forward the traffic with http and port 80, in the dashboard screenshot you forward the traffic with https and port 80.

Just skip http and self signed certificates all together. Modern Browsers make it a pain to use non https sites. A simple domain setup with dns acme challenge is a little bit of a hassle but worth the hour(s) of invested time. Especially with npm were it is a set and forget option.

Does pihole support wildcard dns entries yet? To my knowledge the gui only supports single entries so that you have to enter every subdomain manually in pihole that you want to have forwarded. Workaround would be to use a dnsmasq config file or use something else like addguard.

clmbmb@lemmy.dbzer0.com on 22 Jul 09:42 next collapse

Are you sure both containers (npm and audiobookshelf) are in the same network? I see you don’t specify the network in the NPM compose file.

Check that like this:

$ docker inspect container-name| grep -A3 Networks
            "Networks": {
                "network_name": {
                    "IPAMConfig": null,
                    "Links": null,

See if both your containers are in the same network - they should be.

Pastime0293@discuss.tchncs.de on 22 Jul 09:48 next collapse

Both your containers need share at least one network. It looks like have created a external network. Good job. The next step is to configure your container to join the network. Do something like this:

services:
  nginx-proxy-manager: 
     ....
     networks:
       - nginx-proxy-manager_default # or just nginx
      ...

networks:
  nginx:
    name: nginx-proxy-manager_default
    external: true  

Don’t forget to also add the network in your audiobookshelf service.

Maybe this helps: docs.docker.com/compose/how-tos/networking/#use-a…

samsapti@feddit.dk on 22 Jul 09:56 collapse

In the compose file for Audiobookshelf, you need to add the service itself to the network you defined at the bottom. Something like:

services:
  audiobookshelf:
    ...
    networks:
      - default
      - nginx

(The default network is to keep it in the network that is created on docker compose up).