SWAG & OMV Webconfig

    Zitat von KM0201

    I thought you'd still need to pull a new cert

    That is what the wildcard is doing there: the cert is created for subdomain.duckdns.org

    Then, SWAG proxy it to any sub-subdomain you want/need.

    Zitat von KM0201

    At the very least you're going to have to restart the container to pick up the new subdomain.conf.

    That is always mandatory when editing/creating new proxy-confs


    ;)

    • Offizieller Beitrag

    I have a feeling his whole problem is that IP he has is not on the same network as docker.


    I just set this up in like 10sec in a virtual machine. It's not rocket surgery by any stretch. (10sec may be a stretch, but it was less than 2min I'm sure)



    Code
    joe0201@omv6-test:~$ cd /NAS/AppData/swag/nginx/proxy-confs/
joe0201@omv6-test:/NAS/AppData/swag/nginx/proxy-confs$ cp _template.subdomain.conf.sample openmediavault.subdomain.conf
joe0201@omv6-test:/NAS/AppData/swag/nginx/proxy-confs$ nano openmediavault.subdomain.conf


    edited my openmediavault.subdomain.conf as follows. Whether you use omv, openmediavault, or something completely different, is really irrelevant to the discussion so long as you know what it is

    At this point, I changed the port for the OMV webUI to 99, as reflected in the subdomain.conf

    Code
    root@omv6-test:~# docker restart swag

    literally less than 10sec later (note, it didn't pull a new cert. Obviously I've not used wildcards in a while)


    Zitat von stefan1983

    http://172.16.10.100:50000 also opens the web UI


    So finally I should have to be able to access: https://172.16.10.100:443 or https://omv.blablabla.duckdns.org ?

    That does not work currently.

    Now I understand what you are doing.

    You have an internal dns which resolves the same name but to an internal ip and you have an external dns for the same name resolving to the external ip.


    What are the symptoms of "not work currently"?


    Even with an invalid cert you should see something.

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

    Gefällt mir 1
    Zitat von KM0201

    Really? I thought you'd still need to pull a new cert.. At the very least you're going to have to restart the container to pick up the new subdomain.conf. I don't use wildcard domains with my personal domain, so I have to identify each subdomain in my domain panel... which will require redeployment.

    You need to pull a new cert if you are using http validation, as all names are validated by letsencrypt. If it is possible to use DNS validation, letsencrypt will provide wildcard certs.


    As I do not use DuckDNS, I can not tell which methods are supported.

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

    • Offizieller Beitrag
    Zitat von KM0201

    I don't use wildcard domains with my personal domain, so I have to identify each subdomain in my domain panel... which will require redeployment.

    In that case, yes you have to pull a new cert. I have about eight subdomains and only have to restart the swag container after creating a new proxy.conf file.

    • Offizieller Beitrag

    Just thinking about it this morning - for reverse proxy to work for multiple containers, all of them need to be on the same network with the swag container. That is what the first part of my How-To was about. But omv is not set up in a container, so it doesn’t have a network set up like that. I still haven’t gone to my files to see what my .conf file looks like. Way busy today. :)

    Zitat von Agricola

    for reverse proxy to work for multiple containers, all of them need to be on the same network with the swag container.

    Not entirely true. This is only valid if you don't want to edit the proxy-conf samples.

    To have the services on different networks, all you have to do is change the conf to point to the IP:port of the service you want.


    In fact, you can even proxy it to a different server on the same LAN.


    For eg: I have 2 instances (2x RPi) running on the LAN each with it's own OMV and I have 2 different proxy-confs to point to each of those instances.

    So I can access them both via WAN.

    Not only OMV but also all other services that are running on the LAN.


    Of course there's a catch to this: whenever Linuxserver updates the proxy-confs (NOT OMV since this was made by us but those pre-made) and were edited to suit our needs, it's necessary to update them by hand to reflect those changes.

    Zitat von stefan1983

    By the way, is there any difference between ghcr.io/linuxserver/swag and lscr.io/linuxserver/swag:latest (which I used previously)?

    They are equal:



    It is the same manifest in two different registries.

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

    • Offizieller Beitrag
    Zitat von stefan1983

    By the way, is there any difference between ghcr.io/linuxserver/swag and lscr.io/linuxserver/swag:latest (which I used previously)?

    linuxserver has underwent several image name changes... *usually* the old ones continue to work, and just link to proper image.


    Their images used to be called linuxserver/swag, linuxserver/nextcloud, linuxserver/mariadb, etc.

    Then they went to ghcr.io/linuxserver/swag

    Then (and I believe currently) lscr.io/linuxserver/swag.


    I have no idea why the constant namge change them but when they do it they seem to change them across the board, As Zoki said, the old names still work.

    The first part is not part of the name, but gives the dns name of the registry where the image is stored.

    no dns part -> dockerhub

    ghcr.io -> github registry

    lscr.io -> linuxserver own registry (or a proxy to other directories. https://www.linuxserver.io/blog/wrap-up-warm-for-the-winter)

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

    Gefällt mir 1

    Thanks!


    I now went ahead and configured a conf file for portainer which worked as well.

    Although both URLs (server.blablabla.duckdns.org and portainer.blablabla.duckdns.org) resolve to the same local IP > 172.16.10.100, I land on the correct (hlogin page depending on the used URL.


    Does this work this way because of the SNI - TLS extension?

    Yes, in the config you define a server name which is matched against the sni.

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

    Gefällt mir 1
    • Offizieller Beitrag
    Zitat von Soma

    In fact, you can even proxy it to a different server on the same LAN.


    For eg: I have 2 instances (2x RPi) running on the LAN each with it's own OMV and I have 2 different proxy-confs to point to each of those instances.

    So I can access them both via WAN.

    Not only OMV but also all other services that are running on the LAN.

    Interesting. I thought everything had to be on the same ip. Could you post a sample .conf file?

    Zitat von Agricola

    Interesting. I thought everything had to be on the same ip. Could you post a sample .conf file?

    There's no science on this, ;)


    Let's say you have SWAG running on IP 192.168.1.2 with duckdns/wildcard and you have services running on that same IP for eg: Portainer, OMV, adguard just to name a few).


    And on another IP 192.168.1.3 there's OMV, Portainer, emby.


    Now, to access to all them, make several copies of a standard conf.sample and name them with a simple name:

    omv1.subdomain.conf omv2.subdomain.conf portainer1.subdomain.conf etc...


    Next, just make the changes on the conf to reflect the IPs and ports where those services are running:


    omv1.subdomain.conf:

    Code
    ....
    server_name omv1.*; # note: this is OMV running on the 192.68.1.2 for eg.

.....
        set $upstream_app 192.168.1.2; # note: edit with the LAN IP of your OpenMediaVault server.
        set $upstream_port XX;      # note: same port used on the server for OpenMediaVault.

    Now do the same for omv2.subdomain.conf changing the IP and the port it uses:

    Code
    ....
    server_name omv2.*; # note: this is OMV running on the 192.68.1.3 for eg.

.....
        set $upstream_app 192.168.1.3; # note: edit with the LAN IP of your OpenMediaVault server.
        set $upstream_port XX;      # note: same port used on the server for OpenMediaVault.

    Now do this for portainer also, if you want.

    And this is valid for any pre-made conf.sample that SWAG has.


    So, bottom line is:

    SWAG runs on an IP and reverse-proxies to all LAN if required.

    Heck, it can probably also be reversed to WAN (haven't tried it or needed it)

    All it takes is to point any single conf to the proper IP:port and with a unique name.

    • Offizieller Beitrag

    Soma well I am embarrassed.

    1. Save original omv1.subdomain.conf as omv2.subdomain.conf.
    2. Change server name from server_name abc.* to server_name xyz.*;
    3. Change ip from set $upstream_app 192.168.1.140; to set $upstream_app 192.168.1.10; .
    4. Port number is the same on both servers, so no change is needed.
    5. Save and restart Swag.


    If I had just looked at my original .conf file, I would have seen all of this at a glance. I would be less embarrassed if I had asked you how to fall down. :) Thanks Soma.

    System Backup Typo alert: Under the Linux section the command should be sudo umount /dev/sda1 NOT sudo unmount /dev/sda1

    Backup Data Disk to Backup Disk on Same Machine: In a Scheduled Job:rsync -av --delete /srv/dev-disk-by-uuid-f8814ed9-9a5c-4e1c-8830-426968c20ea3/ /srv/dev-disk-by-uuid-e67439d5-00a3-4942-bd5f-b84ab86aa850/ Don't forget trailing slashes, and BE CAREFUL. (HT: Getting Started with OMV5)

    Equipment - Thinkserver TS140, NanoPi M4 (v.1), Odroid XU4 (Using DietPi): PiHole

    Haha 1
    Zitat von Agricola

    I would have seen all of this at a glance.

    Sometimes the simple answer is the hardest to see, 😁


    Glad you're sorted.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden