diff --git a/general/swag/index.html b/general/swag/index.html index 9191d0c0b6..0d89e4cbcd 100644 --- a/general/swag/index.html +++ b/general/swag/index.html @@ -9,16 +9,15 @@ -e VALIDATION=http \ -e CERTPROVIDER= `#optional` \ -e DNSPLUGIN=cloudflare `#optional` \ - -e DUCKDNSTOKEN=<token> `#optional` \ - -e EMAIL=<e-mail> `#optional` \ - -e ONLY_SUBDOMAINS=false `#optional` \ - -e EXTRA_DOMAINS=<extradomains> `#optional` \ - -e STAGING=false `#optional` \ - -p 443:443 \ - -p 80:80 `#optional` \ - -v </path/to/appdata/config>:/config \ - --restart unless-stopped \ - lscr.io/linuxserver/swag + -e EMAIL=<e-mail> `#optional` \ + -e ONLY_SUBDOMAINS=false `#optional` \ + -e EXTRA_DOMAINS=<extradomains> `#optional` \ + -e STAGING=false `#optional` \ + -p 443:443 \ + -p 80:80 `#optional` \ + -v </path/to/appdata/config>:/config \ + --restart unless-stopped \ + lscr.io/linuxserver/swag
Compatible with docker-compose v2 schemas.
---
version: "2.1"
services:
@@ -36,18 +35,17 @@
- VALIDATION=http
- CERTPROVIDER= #optional
- DNSPLUGIN=cloudflare #optional
- - DUCKDNSTOKEN=<token> #optional
- - EMAIL=<e-mail> #optional
- - ONLY_SUBDOMAINS=false #optional
- - EXTRA_DOMAINS=<extradomains> #optional
- - STAGING=false #optional
- volumes:
- - </path/to/appdata/config>:/config
- ports:
- - 443:443
- - 80:80 #optional
- restart: unless-stopped
-
Our image currently supports three different methods to validate domain ownership:
ini
files under /config/dns-conf/
The validation is performed when the container is started for the first time. Nginx won't be up until ssl certs are successfully generated.
The certs are valid for 90 days. The container will check the cert expiration status every night and if they are to expire within 30 days, it will attempt to auto-renew. If your certs are about to expire in less than 30 days, check the logs under /config/log/letsencrypt
to see why the auto-renewals failed.
As of January 2021, SWAG supports getting certs validated by either Let's Encrypt or ZeroSSL. Both services use the ACME protocol as the underlying method to validate ownership. Our Certbot client in the SWAG image is ACME compliant and therefore supports both services.
Although very similar, ZeroSSL does (at the time of writing) have a couple of advantages over Let's Encrypt:
SWAG currently defaults to Let's Encrypt as the cert provider so as not to break existing installs, however users can override that behavior by setting the environment variable CERTPROVIDER=zerossl
to retrieve a cert from ZeroSSL instead. The only gotcha is that ZeroSSL requires the EMAIL
env var to be set so the certs can be tied to a ZeroSSL account for management over their web interface.
Port 443 mapping is required for access through https://domain.com
. However, you don't necessarily need to have it listen on port 443 on the host server. All that is needed is to have port 443 on the router (wan) somehow forward to port 443 inside the container, while it can go through a different port on the host.
For instance, it is ok to have port 443 on router (wan) forward to port 444 on the host, and then map port 444 to port 443 in docker run/create or compose yml.
Port 80 forwarding is required for http
validation only. Same rule as above applies, and it's OK to go from 80 on the router to 81 on the host, mapped to 80 in the container.
SWAG container happily runs with bridge networking. However, the default bridge network in docker does not allow containers to connect each other via container names used as dns hostnames. Therefore, it is recommended to first create a user defined bridge network and attach the containers to that network.
If you are using docker-compose, and your services are on the same yaml, you do not need to do this, because docker-compose automatically creates a user defined bridge network and attaches each container to it as long as no other networking option is defined in their config.
For the below examples, we will use a network named lsio
. We can create it via docker network create lsio
. After that, any container that is created with --net=lsio
can ping each other by container name as dns hostname.
Info
Keep in mind that dns hostnames are meant to be case-insensitive, however container names are case-sensitive. For container names to be used as dns hostnames in nginx, they should be all lowercase as nginx will convert them to all lowercase before trying to resolve.
Let's assume our domain name is linuxserver-test.com
and we would like our cert to also cover www.linuxserver-test.com
and ombi.linuxserver-test.com
. On the router, forward ports 80
and 443
to your host server. On your dns provider (if using your own domain), create an A
record for the main domain and point it to your server IP (wan). Also create CNAMES for www
and ombi
and point them to the A
record for the domain.
With docker cli, we'll first create a user defined bridge network if we haven't already docker network create lsio
, and then create the container:
docker create \
+ - EMAIL=<e-mail> #optional
+ - ONLY_SUBDOMAINS=false #optional
+ - EXTRA_DOMAINS=<extradomains> #optional
+ - STAGING=false #optional
+ volumes:
+ - </path/to/appdata/config>:/config
+ ports:
+ - 443:443
+ - 80:80 #optional
+ restart: unless-stopped
+
Our image currently supports two different methods to validate domain ownership:
ini
files under /config/dns-conf/
The validation is performed when the container is started for the first time. Nginx won't be up until ssl certs are successfully generated.
The certs are valid for 90 days. The container will check the cert expiration status every night and if they are to expire within 30 days, it will attempt to auto-renew. If your certs are about to expire in less than 30 days, check the logs under /config/log/letsencrypt
to see why the auto-renewals failed.
As of January 2021, SWAG supports getting certs validated by either Let's Encrypt or ZeroSSL. Both services use the ACME protocol as the underlying method to validate ownership. Our Certbot client in the SWAG image is ACME compliant and therefore supports both services.
Although very similar, ZeroSSL does (at the time of writing) have a couple of advantages over Let's Encrypt:
SWAG currently defaults to Let's Encrypt as the cert provider so as not to break existing installs, however users can override that behavior by setting the environment variable CERTPROVIDER=zerossl
to retrieve a cert from ZeroSSL instead. The only gotcha is that ZeroSSL requires the EMAIL
env var to be set so the certs can be tied to a ZeroSSL account for management over their web interface.
Port 443 mapping is required for access through https://domain.com
. However, you don't necessarily need to have it listen on port 443 on the host server. All that is needed is to have port 443 on the router (wan) somehow forward to port 443 inside the container, while it can go through a different port on the host.
For instance, it is ok to have port 443 on router (wan) forward to port 444 on the host, and then map port 444 to port 443 in docker run/create or compose yml.
Port 80 forwarding is required for http
validation only. Same rule as above applies, and it's OK to go from 80 on the router to 81 on the host, mapped to 80 in the container.
SWAG container happily runs with bridge networking. However, the default bridge network in docker does not allow containers to connect each other via container names used as dns hostnames. Therefore, it is recommended to first create a user defined bridge network and attach the containers to that network.
If you are using docker compose, and your services are on the same yaml, you do not need to do this, because docker compose automatically creates a user defined bridge network and attaches each container to it as long as no other networking option is defined in their config.
For the below examples, we will use a network named lsio
(only for the cli created containers). We can create it via docker network create lsio
. After that, any container that is created with --net=lsio
can ping each other by container name as dns hostname.
Info
Keep in mind that dns hostnames are meant to be case-insensitive, however container names are case-sensitive. For container names to be used as dns hostnames in nginx, they should be all lowercase as nginx will convert them to all lowercase before trying to resolve.
Let's assume our domain name is linuxserver-test.com
and we would like our cert to also cover www.linuxserver-test.com
and ombi.linuxserver-test.com
. On the router, forward ports 80
and 443
to your host server. On your dns provider (if using your own domain), create an A
record for the main domain and point it to your server IP (wan). Also create CNAMES for www
and ombi
and point them to the A
record for the domain.
With docker cli, we'll first create a user defined bridge network if we haven't already docker network create lsio
, and then create the container:
docker create \
--name=swag \
--cap-add=NET_ADMIN \
--net=lsio \
@@ -130,8 +128,8 @@
-e TZ=Europe/London \
-e URL=linuxserver-test.duckdns.org \
-e SUBDOMAINS=wildcard \
- -e VALIDATION=duckdns \
- -e DUCKDNSTOKEN=97654867496t0877648659765854 \
+ -e VALIDATION=dns \
+ -e DNSPLUGIN=duckdns \
-p 443:443 \
-p 80:80 \
-v /home/aptalca/appdata/swag:/config \
@@ -151,15 +149,15 @@
- TZ=Europe/London
- URL=linuxserver-test.duckdns.org
- SUBDOMAINS=wildcard
- - VALIDATION=duckdns
- - DUCKDNSTOKEN=97654867496t0877648659765854
+ - VALIDATION=dns
+ - DNSPLUGIN=duckdns
volumes:
- /home/aptalca/appdata/swag:/config
ports:
- 443:443
- 80:80
restart: unless-stopped
-
Then we'll fire up the container via docker-compose up -d
After the container is started, we'll watch the logs with docker logs swag -f
. We'll see some initialization and then we will see the validation steps. After all the steps, it should print Server ready
in the logs.
Now we can access the webserver by browsing to https://www.linuxserver-test.duckdns.org
.
Warning
Due to a DuckDNS limitation, our cert only covers the wildcard subdomains, but it doesn't cover the main url. So if we try to access https://linuxserver-test.duckdns.org
, we'll see a browser warning about an invalid ssl cert. But accessing it through the www
(or ombi
or any other) subdomain should work fine.
Once we have a working container, we can drop our web documents in and modify the nginx config files to set up our webserver.
All the necessary files are under /config
which is mapped from the host location (set by above examples) /home/aptalca/appdata/swag
.
We can drop all of our web/html files into /config/www
.
The main site config nginx uses can be found at /config/nginx/site-confs/default
. Don't delete this file, as it will be regenerated on container restart, but feel free to modify as needed. By default, it is listening on port 443, and the root folder is set to /config/www
, so if you drop a page1.html
into that location, it will be accessible at https://linuxserver-test.com/page1.html
.
To enable listening on port 80 and automatically redirecting to port 443 for enforcing ssl, uncomment the lines at the top of the default
site config so it reads:
Then we'll fire up the container via docker-compose up -d
After the container is started, we'll watch the logs with docker logs swag -f
. After some init steps, we'll notice that the container will give an error during validation due to wrong credentials. That's because we didn't enter the correct credentials for the Cloudflare API yet. We can browse to the location /config/dns-conf
which is mapped from the host location (according to above settings) /home/aptalca/appdata/swag/dns-conf/
and edit the correct ini file for our dns provider. For DuckDNS, we'll enter our API token. The API token can be retrieved from the DuckDNS admin interface.
Once we enter the credentials into the ini file, we'll restart the docker container via docker restart swag
and again watch the logs. After successful validation, we should see the notice Server ready
and our webserver should be up and accessible at https://www.linuxserver-test.duckdns.org
.
Warning
Due to a DuckDNS limitation, our cert only covers the wildcard subdomains, but it doesn't cover the main url. So if we try to access https://linuxserver-test.duckdns.org
, we'll see a browser warning about an invalid ssl cert. But accessing it through the www
(or ombi
or any other) subdomain should work fine.
Once we have a working container, we can drop our web documents in and modify the nginx config files to set up our webserver.
All the necessary files are under /config
which is mapped from the host location (set by above examples) /home/aptalca/appdata/swag
.
We can drop all of our web/html files into /config/www
.
The main site config nginx uses can be found at /config/nginx/site-confs/default
. Don't delete this file, as it will be regenerated on container restart, but feel free to modify as needed. By default, it is listening on port 443, and the root folder is set to /config/www
, so if you drop a page1.html
into that location, it will be accessible at https://linuxserver-test.com/page1.html
.
To enable listening on port 80 and automatically redirecting to port 443 for enforcing ssl, uncomment the lines at the top of the default
site config so it reads:
That way, nginx will use the /
location block from our heimdall proxy conf instead.
After that, when we navigate to https://linuxserver-test.com
, we'll see the Heimdall interface.
If we want to password protect our new homepage, we can run the following on the host command line to create a new .htpasswd
file: docker exec -it swag htpasswd -c /config/nginx/.htpasswd anyusername
. After which, we can activate authentication by editing the heimdall.subfolder.conf
file to uncomment the relevant lines so it reads:
# enable the next two lines for http auth
auth_basic "Restricted";
auth_basic_user_file /config/nginx/.htpasswd;
-
We wrote a blogpost for the deprecated letsencrypt image diving into troubleshooting issues regarding dns and port-forwards, which still is a very good resource: blog.linuxserver.io
This error simply means that the resource was not found. Commonly happening when you try to access a subfolder that is not enabled.
This error means that nginx can't talk to the application. There is a few common reasons for this:
The application and SWAG is not on the same custom docker network
Further up we talk about how to set up Docker networking, however there are some other common traps
The container name does not match the application name.
Covered in the section for Understanding the proxy conf structure
You manually changed the port.
Also covered in the section for Understanding the proxy conf structure
The container originally ran with host networking, or the default bridge.
In most cases the contents of /config/nginx/resolver.conf;
should be ...resolver 127.0.0.11 valid=30s;
, if this is not the case, you can:
Here are a few troubleshooting steps:
docker exec swag ping <container name>
(If your swag container isn't named swag
, replace swag
with the swag container's name).docker inspect <container name>
) and try to ping that from swag (docker exec swag ping <container ip>
)docker exec swag curl http(s)://<container name>:<application port>
(make sure that this matches whatever is in your proxy conf)docker logs <container name>
).This image can be used in many different scenarios as it is a full fledged web server with some bells and whistles added. The above examples should be enough to get you started. For more information, please refer to the official documentation on either Github or Docker Hub. If you have questions or issues, or want to discuss and share ideas, feel free to visit our discord: https://discord.gg/YWrKVTn
As you can see in this article, there are many different configurations, therefore we need to understand your exact setup before we can provide support. If you encounter a bug and confirm that it's a bug, please report it on our github thread. If you need help with setting it up, join our discord and upload the following info to a service like pastebin and post the link:
docker logs swag
)