DietPi-Software | Reverse proxy integration for web applications

[Gill-Bates]

Hey there,

I am using many Services on my Raspberry and have already a Zoo of different Ports that I need to use for a particular service.

To get rid of it, I did following:

• Installing nginx
• Setup nginx as a ReverseProxy
• Installl ufw and allow only inbound Traffic on Port 443, 80, 22
• Adding a record to my /etc/hosts file (using dietpi as local DNS-Resolver)

Now I can easily access:

http://adguard.lan.local
http://portainer.lan.local
etc... 

without struggeling with Ports. And I have secured my Installation. What do you think to make this Standard for Dietpi?

Example Config for nginx:

# docker.lan.local / Portainer
server {
        server_name ocker.lan.local;
        listen 80;
        listen [::]:80;

        location / {
            # Reverse Proxy
            proxy_pass http://127.0.0.1:9002;
            index index.html index.htm index.php;
            autoindex off;
        }
}

[Joulinar]

Basically this could be done with other web server as well. We might think on a documentation page on our online docs on how to setup a reverse proxy, rather than creating this as software option.

[MichaIng]

Generally I think it would be nice indeed to have some GUI wise reverse proxy setup. But I'm not sure whether this makes sense within dietpi-software or whether er should create an own script for this, like dietpi-proxy or so 😄.

What could be done is detecting installed web servers, load balancers (HAProxy) and other proxies, or allowing to install one if not available yet. Then detecting web applications with internal web server, respectively TCP or UNIX socket listener. Then allow to enable/disable a reverse proxy on a choosable URL path (does does not exist on the actual filesystem yet) for each web application. This would safe users quite same hassle I guess, especially when otherwise guides are followed to install dedicated proxy servers, even with a whole Docker daemon and container around, while a webserver is present already (also conflicting on the port) or lightweight and fast HAProxy is the much better alternative on a low RAM SBC.

[Joulinar]

this could be quite complex. Each software require a different proxy configuration, probably. We might need to keep templates for each software title individually. And this for all available proxy software/ web server.

[MichaIng]

Indeed, we'll likely not be able to implement every combination directly, probably we can ship it gradually.

[Gill-Bates]

I would like to point you Guys to traefik -> https://github.com/traefik/traefik

It looks like a load-balancer and reverse proxy with autodetection :-)

[Joulinar]

It needs a backend like Docker if I'm not mistaken. I guess it is not working on a normal system. But maybe I'm wrong.

[MichaIng]

Especially since it is a single standalone binary, what is the benefit or wrapping it into a container engine? In the end one can/needs to configure Traefik via traefik.toml, isn't it?

[Joulinar]

I don't think we will provide any of our software title as individual container. Why? Because quite a larger number of software title have their own original container / docker image.

[MichaIng]

Where possible we provide bare metal installs. And for Traefik this seems to be pretty trivial. To me it looks like when using a container, you trade the one config file for another one, loose flexibility, add a lot of overhead and add another engine and point of failure. We had enough fun with Docker recently: #6126

It's nice for complex multi-process setups with strict module version requirements, like if you have frontend, middle-end and backend + database and in case a dedicated cache server and all needs to work with each other and in case specific versions of each are required. But for most other things ... I don't know how difficult it is to manually setup Traefik as reverse proxy, but when it is easier to do it with a Docker container including all the implications, it does something wrong.

However, the discussion here is not about Traefik anyway but about reverse proxies in general. And of course we'd implement the ones we do already have in our software catalogue first, i.e. HAProxy, frp, Nginx, Apache, Lighttpd.

[mews-se]

https://nginxproxymanager.com/ is my go-to for this - also worth a look!

[MichaIng]

But it is a little massive as whole container + AFAIK it cannot be automated to create proxy entries for all web applications. The goal here would be to use bare metal webserver/proxy applications and optionally create individual proxy configs as part of the dietpi-software install process, or a dedicated script.

And same as with Caddy, NPM is not an install option yet: #4417

Also Docker (container engines) does not run on RISC-V yet and there will always be individual new SBCs with vendor kernel builds which do not support Docker, like the Quartz64 until we added support recently. So we should avoid relying on Docker, if there are alternatives.

[Joulinar]

Theoretically it should be possible to create NPM configs from outside the container as well

root@DietPiProd:~# cat /mnt/dietpi_userdata/docker-data/volumes/npm_data/_data/nginx/proxy_host/1.conf
# ------------------------------------------------------------
# pi.hole
# ------------------------------------------------------------


server {
  set $forward_scheme http;
  set $server         "192.168.0.11";
  set $port           8080;

  listen 80;
listen [::]:80;


  server_name pi.hole;






  # Block Exploits
  include conf.d/include/block-exploits.conf;







  access_log /data/logs/proxy-host-1_access.log proxy;
  error_log /data/logs/proxy-host-1_error.log warn;







  location / {








    # Proxy!
    include conf.d/include/proxy.conf;
  }


  # Custom
  include /data/nginx/custom/server_proxy[.]conf;
}

root@DietPiProd:~#

[jalsco]

I would like to point you Guys to traefik -> https://github.com/traefik/traefik

Traefik does look pretty cool ! I been using Caddy for a few years and never had any problem with it on DietPi.

But Traefik looks awesome too 👍