MIgrate from Letsencrypt to SWAG

LSIO Discussion Container Support
#1

Hello,

Currently I am using your Letsencrypt container for certs and publishing behind Nginx some other containers. I saw that now it’s renamed to SWAG and I wish to migrate to new container.
What I did so far:

  1. stop letsencrypt container
  2. copy config folder to new folder to be used by SWAG
  3. started SWAG container with same options like I did with letsencrypt
  4. error I am getting in container logs is that authentication failed on letsencrypt web site

What is proper way to migrate to SWAG container? Should I first start SWAG container with options i need, then copy just Nginx conf files from Letsnecrypt container and nothing else?

Regards,
Marjan

#2

You don’t say how you deployed the container, but all you have to do is change the repository from linuxserver/letsencrypt to linuxserver/swag.
No need to change anything else.

#3

Hello,

Here is command for Letsencrypt:
docker run -d --name=letsencrypt --cap-add=NET_ADMIN --net=dock-bridge01 --hostname=letsencrypt -e TZ=Europe/Belgrade -e URL=mydomain.com -e SUBDOMAINS=subdomain1,subdomain2 -e VALIDATION=http -e DHLEVEL=2048 -e ONLY_SUBDOMAINS=false -p 443:443 -p 80:80 -v /data/letsencrypt/appdata/config:/config --restart unless-stopped linuxserver/letsencrypt

And this is for SWAG:
docker run -d --name=swag --cap-add=NET_ADMIN --net=dock-bridge01 --hostname=swag -e TZ=Europe/Belgrade -e URL=mydomain.com -e SUBDOMAINS=subdomain1,subdomain2 -e VALIDATION=http -e DHLEVEL=2048 -e ONLY_SUBDOMAINS=false -p 443:443 -p 80:80 -v /data/swag/appdata/config:/config --restart unless-stopped linuxserver/swag

The only differences are container name, hostname and mount point. I think the problem might be with hostname, I found in configuration folder that hostname is used for authenticating to Letnsencrypt web site to retrieve certificates. I still haven’t been able to try with old hostname but I would like to use new one if possible.

Regards,
Marjan

#4

Are you able to replicate the issue when following our readme? It’s difficult to offer support when you do your own thing. I’m inclined to agree that the superfluous use of --hostname is the culprit, which is why it’s not in our sample.

We do also have a migration guide in our SWAG release article

#5

You’re not supposed to change the mount point, that way it picks up existing data

1 Like
#6

I have just one question…when will there be a downloadable container?

I have never done a docker compose or anything of the sort (no desire) so would prefer…

And since letsencrypt continues to work … :wink:

Cheers

#7

I don’t know what you mean by downloadable container

#8

Well I mean go to apps in unraid - community applications, search and download the container. Then fill in the property sheet…

Thats how I have added all of my containers…

image
image1574×573 82.4 KB

Cheers

#9

When this is merged, there will be one: https://github.com/linuxserver/docker-templates/pull/202

#10

Perfect.
I’ll be waiting…

Thanks

#11

Just out of curiosity why are people still using this while there is Traefik and Authelia?

#12

Why do people still use js when there is python, go, [insert any language]?

Also because SWAG is a full fledged web server, not just a reverse proxy. And it has built in integration for Authelia among others: https://blog.linuxserver.io/2020/08/26/setting-up-authelia/

PS. Our discord gets flooded with people who can’t figure out traefik’s abysmal documentation (which we don’t support btw).

#13

I did read your readme, I always first RTFM then do the thing.
Anyway, the --hostname is the culprit. Changing it to one used with letsencrypt container solved the problem.

@Amviewer, I am using Nginx with Authelia. Simple to integrate and works just fine.

#14

Hello,

I migrated to Swag a while ago with no issues at all. Today there was an update to swag that failed. Once I rebooted my server, the GUI didn’t start.

I booted into safe mode with GUI without plugins and was able to start the array.

I continued working on the system and found that If I stopped swag, the system started and GUI loaded.I copied my settings removed swag, rebooted, and the gui loaded. I then reinstalled swag and rebooted and the gui didn’t load. I open a terminal and type docker stop swag and within seconds the gui loads.

If I restart swag all of my reverser proxies work perfectly.

I am completely lost. I don’t know why swag would stop the GUI from starting

Any suggestions are appreciated

Thanks

Chas

#15

We would need to see logs, your compose, know what you mean when you say “GUI”, know your host os and version, etc.

#16

I’m running unraid with swag in a docker.

#17

logs? screenshot of your setup (i guess you can’t show compose in unraid)
are you reverse proxying the unraid gui through swag?

#18

Hi there,
I also have an issue there. On raspi 4 my nextcloud+mariadb+letsencrypt docker compose runs smoothly (see instructions from @aptalca … still. I tried to switch to swag today, adjusted the proxy confs and site conf just exactly as I did for letsencrypt + restarted the containers. But instead of the nextcloud logon page I keep ending up on the “Welcome to your SWAG instance” page.
Any idea? Thanks alot if you have!

My snippet for swag:

  letsencrypt:
image: linuxserver/swag
container_name: swag
cap_add:
  - NET_ADMIN
environment:
  - PUID=998
  - PGID=100
  - TZ=Europe/Berlin
  - URL=mydomain.duckdns.org
  - SUBDOMAINS=wildcard
  - VALIDATION=duckdns
  - DUCKDNSTOKEN=my token
volumes:
  - /srv/dev-disk-by-uuid-33d220fd-843b-4798-9b8d-0dc25c0bf9e9/appdata/swag:/config
ports:
  - 443:443
  - 82:80  #port 80 is used already
restart: unless-stopped
#19

if you’re getting the swag placeholder page, then your proxy conf for nextcloud is not enabled properly. Double check the filename, and make sure the server_name var matches the address you’re trying to access

#20

Hi,
thanks for the quick reply!
That is the weird thing. The server name uses the wildcard.

This is my /appdata/swag/nginx/proxy-confs/nextcloud.subdomain.conf:
server {
listen 443 ssl;
listen [::]:443 ssl;

server_name nextcloud.*;

include /config/nginx/ssl.conf;

client_max_body_size 0;

location / {
    include /config/nginx/proxy.conf;
    resolver 127.0.0.11 valid=30s;
    set $upstream_app nextcloud;
    set $upstream_port 443;
    set $upstream_proto https;
    proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    proxy_max_temp_file_size 1024m;
}

}

Wich is exactly the same as my /appdata/letsencrypt/nginx/proxy-confs/nextcloud.subdomain.conf:
server {
listen 443 ssl;
listen [::]:443 ssl;

    server_name nextcloud.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    location / {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app nextcloud;
        set $upstream_port 443;
        set $upstream_proto https;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

        proxy_max_temp_file_size 1024m;
    }
}

If I deploy the stack with letsencrypt it works perfectly. If I deploy the stack with swag, I end up at the swag placeholder page…
Am I adressing the correct proxy conf?

The only difference I found is in the swag\nginx\site-confs\default:
In there is an additional line right on the top compared to the letsencrypt’s default:

error_page 502 /502.html;

Thanks,
Flo