Unrayed Posted March 9 Share Posted March 9 On 3/7/2024 at 6:03 PM, Unrayed said: I'm having an issue whereby my certs are no longer auto-renewing. I had the cron set for 20:30 each night to check and renew if necessary, but for whatever reason, it recently stopped using the specified cron time and is now using the default 2:08am time (a time that my server is powered off.) Appdata/swag/crontabs/root: 30 20 * * * /app/le-renew.sh >> /config/log/letsencrypt/letsencrypt.log 2>&1 cronjob running on Mon Nov 20 20:30:00 GMT 2023 Running certbot renew Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/mydomain.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Certificate not yet due for renewal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The following certificates are not due for renewal yet: /etc/letsencrypt/live/mydomain/fullchain.pem expires on 2024-01-14 (skipped) No renewals were attempted. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - <-------------------------------------------------> <-------------------------------------------------> cronjob running on Tue Jan 2 02:08:00 GMT 2024 Running certbot renew Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/mydomain.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Certificate not yet due for renewal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The following certificates are not due for renewal yet: /etc/letsencrypt/live/mydomain/fullchain.pem expires on 2024-03-26 (skipped) No renewals were attempted. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ^^^ You can see here that things USED to run normally for me at 20:30, but more recently it's back to 02:08 and the cron time specified above isn't being used. Has anyone ANY idea how to fix this? I really don't want to wait for cert expiry reminder emails and then have to manually renew them with certbot. Would appreciate any help, thanks The solution to this lied with the fact that SWAG no longer respects that root/cron file without the cron docker-mod installed. Info and solution here, confirmed as working as required now - https://github.com/linuxserver/docker-mods/tree/universal-cron Quote Link to comment
nraygun Posted March 10 Share Posted March 10 23 hours ago, Unrayed said: The solution to this lied with the fact that SWAG no longer respects that root/cron file without the cron docker-mod installed. Info and solution here, confirmed as working as required now - https://github.com/linuxserver/docker-mods/tree/universal-cron I think the cron function was restored per this posting. https://github.com/linuxserver/docker-swag/pull/441 My cert cron job (and maxmind) seem to update these days. Quote Link to comment
rayray14 Posted March 27 Share Posted March 27 (edited) Good afternoon, I started getting SSL errors this morning, and the Swag container logs state: Using Let's Encrypt as the cert provider SUBDOMAINS entered, processing Sub-domains processed are: home.robraymond.com E-mail address entered: [email protected] http validation is selected Certificate exists; parameters unchanged; starting nginx The cert is either expired or it expires within the next day. Attempting to renew. This could take up to 10 minutes. <-------------------------------------------------> <-------------------------------------------------> cronjob running on Wed Mar 27 15:41:58 EDT 2024 Running certbot renew - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/home.mydomain.com.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - When I look at the swag\log\letsencrypt\logs.txt, I get more info (actual domain replaced with domain.com) cronjob running on Wed Mar 27 02:08:02 EDT 2024 Running certbot renew Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/home.mydomain.com.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Failed to renew certificate home.mydomain.com with error: Missing command line flag or config entry for this setting: Please choose an account Choices: ['124eb8e48d2d@2024-02-28T19:41:02Z (c60d)', '9fba956a9707@2021-04-17T23:28:02Z (9ef6)'] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - All renewals failed. The following certificates could not be renewed: /etc/letsencrypt/live/home.mydomain.com/fullchain.pem (failure) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1 renew failure(s), 0 parse failure(s) Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details. When I tried to run "certbot renew --account 124eb8e48d2d@2024-02-28T19:41:02Z" manually from the container's console, I get: Failed to renew certificate home.mydomain.com with error: Account at /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/124eb8e48d2d@2024-02-28T19:41:02Z does not exist - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - All renewals failed. The following certificates could not be renewed: /etc/letsencrypt/live/home.mydomain.com/fullchain.pem (failure) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1 renew failure(s), 0 parse failure(s) Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details. Any thoughts? Edited March 27 by rayray14 Quote Link to comment
MxFox Posted March 31 Share Posted March 31 Hi Guys, Iam also having issue renewing certs. Any Ideas. ? <-------------------------------------------------> <-------------------------------------------------> cronjob running on Sun Mar 31 02:08:00 AEST 2024 Running certbot renew Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/..org.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Hook 'pre-hook' reported error code 111 Hook 'pre-hook' ran with error output: s6-svc: fatal: unable to control /var/run/s6/services/nginx: No such file or directory Renewing an existing certificate for ..org and 2 more domains Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems: Domain: Type: connection Detail: : Fetching http://..org/.well-known/acme-challenge/0h-0uQ00FcRsGmHcAMCVe94XaXZ50uQukjriA8qpPNo: Timeout during connect (likely firewall problem) Domain: ..org Type: connection Detail: : Fetching http://..org/.well-known/acme-challenge/FSkXlkFClj1ROJ95T_ZpVt1kOzMnXDgZcYk0fNia3Q0: Timeout during connect (likely firewall problem) Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet. Failed to renew certificate ..org with error: Some challenges have failed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - All renewals failed. The following certificates could not be renewed: /etc/letsencrypt/live/..org/fullchain.pem (failure) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1 renew failure(s), 0 parse failure(s) Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details. Quote Link to comment
Ben4 Posted April 4 Share Posted April 4 (edited) On 3/31/2024 at 5:21 AM, MxFox said: Hi Guys, Iam also having issue renewing certs. Any Ideas. ? <-------------------------------------------------> <-------------------------------------------------> cronjob running on Sun Mar 31 02:08:00 AEST 2024 Running certbot renew Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/..org.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Hook 'pre-hook' reported error code 111 Hook 'pre-hook' ran with error output: s6-svc: fatal: unable to control /var/run/s6/services/nginx: No such file or directory Renewing an existing certificate for ..org and 2 more domains Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems: Domain: Type: connection Detail: : Fetching http://..org/.well-known/acme-challenge/0h-0uQ00FcRsGmHcAMCVe94XaXZ50uQukjriA8qpPNo: Timeout during connect (likely firewall problem) Domain: ..org Type: connection Detail: : Fetching http://..org/.well-known/acme-challenge/FSkXlkFClj1ROJ95T_ZpVt1kOzMnXDgZcYk0fNia3Q0: Timeout during connect (likely firewall problem) Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet. Failed to renew certificate ..org with error: Some challenges have failed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - All renewals failed. The following certificates could not be renewed: /etc/letsencrypt/live/..org/fullchain.pem (failure) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1 renew failure(s), 0 parse failure(s) Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details. I was able to renew my certs using Zerossl instead of Letsencrypt. I was waiting for an update, but I need my Nextcloud site back up. Per Swag support site How to switch from Letsencrypt to Zerossl: https://docs.linuxserver.io/general/swag/#authorization-method "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." Stop swag, then edit your Swag container and add the variable CERTPROVIDER ( i have attached screenshots). Then hit apply and start your container. Open the log viewer to make sure Swag has switched to Zerossl and has successfully renewed your certs. I also restarted my Nextcloud and Collobora containers, so restart any containers that use Swag. Edited April 4 by Ben4 Quote Link to comment
dboonthego Posted April 7 Share Posted April 7 I'm already forwarding port 80 to a webserver hosted on a separate (non-unraid) physical machine. As I understand in this scenario, http validation isn't possible unless 80 is forwarded to the SWAG docker. Correct? I tried using dns validation with godaddy api and see this in the letsencrypt log. Any thoughts? Thanks. 2024-04-06 16:07:28,398:DEBUG:root:Actual zone name resolved for domain nextcloud.example.com: example.com 2024-04-06 16:07:28,398:DEBUG:root:Override resolved zone name because --delegated option is set: nextcloud.example.com 2024-04-06 16:07:28,910:DEBUG:certbot._internal.error_handler:Encountered exception: Traceback (most recent call last): File "/lsiopy/lib/python3.11/site-packages/certbot/plugins/dns_common_lexicon.py", line 250, in _resolve_domain with Client(self._build_lexicon_config(domain_name)): File "/lsiopy/lib/python3.11/site-packages/lexicon/client.py", line 168, in __enter__ raise e File "/lsiopy/lib/python3.11/site-packages/lexicon/client.py", line 161, in __enter__ provider.authenticate() File "/lsiopy/lib/python3.11/site-packages/lexicon/_private/providers/godaddy.py", line 62, in authenticate result = self._get(f"/domains/{domain}") ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/lsiopy/lib/python3.11/site-packages/lexicon/interfaces.py", line 162, in _get return self._request("GET", url, query_params=query_params) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/lsiopy/lib/python3.11/site-packages/lexicon/_private/providers/godaddy.py", line 338, in _request result.raise_for_status() File "/lsiopy/lib/python3.11/site-packages/requests/models.py", line 1021, in raise_for_status raise HTTPError(http_error_msg, response=self) requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://api.godaddy.com/v1/domains/nextcloud.example.com Not sure if my config is wrong or what, but it seems the api call isn't happy with the subdomain in dot format. A manual api call to this endpoint is not successful (same url from lets encrypt log): https://api.godaddy.com/v1/domains/nextcloud.example.com A manually api call to these endpoints are successful: https://api.godaddy.com/v1/domains/example.com https://api.godaddy.com/v1/domains/example.com/records/CNAME/nextcloud This are my docker options: URL: example.com VALIDATION:dns SUBDOMAINS:nextcloud CERTPROVIDER:letsencrypt DNSPLUGIN:godaddy PROPAGATION: EMAIL:[email protected] ONLY_SUBDOMAINS:true EXTRA_DOMAINS: STAGING:true Quote Link to comment
alturismo Posted April 7 Share Posted April 7 8 minutes ago, dboonthego said: http validation isn't possible unless 80 is forwarded to the SWAG docker. Correct? correct 9 minutes ago, dboonthego said: Not sure if my config is wrong or what, but it seems the api call isn't happy with the subdomain in dot format. as lsio is not active here here, may try their discord to get a answer for this certain issue. 1 Quote Link to comment
pltaylor Posted April 7 Share Posted April 7 I have gone through everything I can find and can't seem to find my error. I'm sure it's something silly but I can't figure out what it is. When I go to immich.mydomain.com I get a 502 error. Other custom domains work without issue. My nginx error log contains the following 2024/04/05 14:42:43 [error] 709#709: *350 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.1, server: immich.*, request: "GET /favicon.ico HTTP/2.0", upstream: "http://172.18.0.7:3001/favicon.ico", host: "immich.mydomain.com", referrer: "https://immich.mydomain.com/" The docker container that is hosting immich looks like the following and the docker container is on the same custom network as my swag instance. What am I missing? Quote Link to comment
Jaybau Posted April 16 Share Posted April 16 I had SWAG previously working, but something changed, and now I get an error message about "Permissions could not be set. This is probably because your volume mounts are remote or read-only." chown: cannot dereference '/config/keys/letsencrypt': No such file or directory find: /var/lib/letsencrypt: No such file or directory find: /var/log/letsencrypt: No such file or directory /etc/s6-overlay/s6-rc.d/init-certbot-config/run: line 372: 361 Illegal instruction certbot certonly --non-interactive --renew-by-default chown: cannot dereference '/config/keys/letsencrypt': No such file or directory find: /var/lib/letsencrypt: No such file or directory find: /var/log/letsencrypt: No such file or directory /etc/s6-overlay/s6-rc.d/init-certbot-config/run: line 372: 364 Illegal instruction certbot certonly --non-interactive --renew-by-default using keys found in /config/keys **** Permissions could not be set. This is probably because your volume mounts are remote or read-only. **** **** The app may not work properly and we will not provide support for it. **** Variables set: PUID=99 PGID=100 TZ=America/Los_Angeles URL=<redacted> SUBDOMAINS= EXTRA_DOMAINS= ONLY_SUBDOMAINS=true VALIDATION=http CERTPROVIDER= DNSPLUGIN=duckdns [email protected] STAGING=false **** Permissions could not be set. This is probably because your volume mounts are remote or read-only. **** **** The app may not work properly and we will not provide support for it. **** Using Let's Encrypt as the cert provider SUBDOMAINS entered, processing Sub-domains processed are: <redacted> E-mail address entered: [email protected] http validation is selected Generating new certificate ERROR: Cert does not exist! Please see the validation error above. The issue may be due to incorrect dns or port forwarding settings. Please fix your settings and recreate the container [migrations] started [migrations] 01-nginx-site-confs-default: skipped [migrations] done usermod: no changes ─────────────────────────────────────── ██╗ ███████╗██╗ ██████╗ ██║ ██╔════╝██║██╔═══██╗ ██║ ███████╗██║██║ ██║ ██║ ╚════██║██║██║ ██║ ███████╗███████║██║╚██████╔╝ ╚══════╝╚══════╝╚═╝ ╚═════╝ Brought to you by linuxserver.io ─────────────────────────────────────── To support the app dev(s) visit: Certbot: https://supporters.eff.org/donate/support-work-on-certbot To support LSIO projects visit: https://www.linuxserver.io/donate/ ─────────────────────────────────────── GID/UID ─────────────────────────────────────── User UID: 99 User GID: 100 ─────────────────────────────────────── using keys found in /config/keys **** Permissions could not be set. This is probably because your volume mounts are remote or read-only. **** **** The app may not work properly and we will not provide support for it. **** Variables set: PUID=99 PGID=100 TZ=America/Los_Angeles URL=<redacted> SUBDOMAINS= EXTRA_DOMAINS= ONLY_SUBDOMAINS=true VALIDATION=http CERTPROVIDER= DNSPLUGIN=duckdns [email protected] STAGING=false **** Permissions could not be set. This is probably because your volume mounts are remote or read-only. **** **** The app may not work properly and we will not provide support for it. **** Using Let's Encrypt as the cert provider SUBDOMAINS entered, processing Sub-domains processed are: <redacted> E-mail address entered: [email protected] http validation is selected Generating new certificate ERROR: Cert does not exist! Please see the validation error above. The issue may be due to incorrect dns or port forwarding settings. Please fix your settings and recreate the container Docker Config: docker run -d --name='swag' --net='proxynet' -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -e HOST_HOSTNAME="Tower" -e HOST_CONTAINERNAME="swag" -e 'URL'='<redacte>' -e 'VALIDATION'='http' -e 'SUBDOMAINS'='<redacted>' -e 'CERTPROVIDER'='' -e 'DNSPLUGIN'='duckdns' -e 'PROPAGATION'='' -e 'EMAIL'='[email protected]' -e 'ONLY_SUBDOMAINS'='true' -e 'EXTRA_DOMAINS'='' -e 'STAGING'='false' -e 'PUID'='99' -e 'PGID'='100' -e 'UMASK'='022' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.icon='https://raw.githubusercontent.com/linuxserver/docker-templates/master/linuxserver.io/img/linuxserver-ls-logo.png' -p '1443:443/tcp' -p '180:80/tcp' -v '/mnt/user/appdata/swag':'/config':'rw' --cap-add=NET_ADMIN 'lscr.io/linuxserver/swag' I also have my router ports forwarding 443 to 1443 and 80 to 180. Ideas of where to look for the problem? Quote Link to comment
Spucoly2 Posted April 22 Share Posted April 22 So after a total loss of half of my drives I am trying to reconfigure Sawg to work with Deluge. I have done this many times with no issue. No matter what I do all I get is a ERR_CONNECTION_REFUSED when navigating to the address. Ports 80 and 443 are forwarded to the ports on swag correctly. I am using Cloudflare. Both dockers are on the same custom docker network and preserve user defined network is set the true. Any help would be much appreciated. tower-diagnostics-20240422-1646.zip deluge.subdomain.conf Quote Link to comment
vw-kombi Posted April 22 Share Posted April 22 I just use tailscale to securely access stuff that are admin things just for me. Swag for me is for the others to access stuff. Play media etc. Quote Link to comment
chanrc Posted April 25 Share Posted April 25 (edited) On 4/4/2024 at 8:40 AM, Ben4 said: I was able to renew my certs using Zerossl instead of Letsencrypt. I was waiting for an update, but I need my Nextcloud site back up. Per Swag support site How to switch from Letsencrypt to Zerossl: https://docs.linuxserver.io/general/swag/#authorization-method "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." Stop swag, then edit your Swag container and add the variable CERTPROVIDER ( i have attached screenshots). Then hit apply and start your container. Open the log viewer to make sure Swag has switched to Zerossl and has successfully renewed your certs. I also restarted my Nextcloud and Collobora containers, so restart any containers that use Swag. Letsencrypt is now requiring secondary validation of your domains from other locations. Basically this means that letsencrypt will start a web server, try to connect to your domains from some external locations, before validating your domain and issuing you a cert if your validation method is set to http. Issue is there are a lot of different firewall configurations and nginx configurations. In @MxFox case his firewall is blocking one of the secondary validation cloudflare locations https://community.letsencrypt.org/t/unexpected-renewal-failures-during-april-2024-please-read-this/216830 https://letsencrypt.org/docs/challenge-types/#http-01-challenge http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN> Looks like both your cases are failing validation at on the HTTP-01 challenge. As am I, but with different reasons. In my case, I have my nginx configured to hit Authelia for SSO signon but that is messing things up on all subdomains because the webserver that letsecrypt spins up to answer validation requests are being blocked my Authelia. I switched to DNS validation using Cloudflare and that works fine now Edited April 29 by chanrc 1 Quote Link to comment
patthe Posted April 29 Share Posted April 29 I have a question. Currently have Swag configure so it goes to nextcloud.domaine.net How can I configure SWAG so that domaine.net (the root of the domain) bring me to heimdall (docker) by default? Quote Link to comment
ElectricBadger Posted June 21 Share Posted June 21 Is it possible to have wildcard certificates for more than one domain? Annoyingly, wildcards don't cover subdomains, so a wildcard for *.example.com doesn't cover *.subdomain.example.com as well. I guess I could spin up a second container with its own appdata, but that seems rather wasteful Quote Link to comment
alturismo Posted June 21 Share Posted June 21 1 hour ago, ElectricBadger said: Is it possible to have wildcard certificates for more than one domain? did you try the EXTRA DOMAIN part yet ? of course both needs to be set to same DNS validation, sample cloudflare ... i never used it but may could be what you looking for 1 Quote Link to comment
nraygun Posted June 29 Share Posted June 29 The MaxMind geoip docker mod doesn't seem to work anymore. It doesn't run from the cron job that's setup in crontabs nor does it run if I run the script directly at /etc/periodic/weekly/libmaxminddb I get an error that says "tar: short read". For the cron, I might have to add another docker mod. I can look into that. As for the libmaxminddb script, I received a notice from Maxmind saying they were changing some URLs starting May 1st 2024. I think the URL that's formed in the libmaxminddb script is wrong. My shell scripting Kung Fu is not that good these days but I'll give it a go. Anyone else having this problem? Is there an updated libmaxxminddb out there somewhere? Quote Link to comment
nraygun Posted June 29 Share Posted June 29 (edited) 4 hours ago, nraygun said: The MaxMind geoip docker mod doesn't seem to work anymore. It doesn't run from the cron job that's setup in crontabs nor does it run if I run the script directly at /etc/periodic/weekly/libmaxminddb I get an error that says "tar: short read". For the cron, I might have to add another docker mod. I can look into that. As for the libmaxminddb script, I received a notice from Maxmind saying they were changing some URLs starting May 1st 2024. I think the URL that's formed in the libmaxminddb script is wrong. My shell scripting Kung Fu is not that good these days but I'll give it a go. Anyone else having this problem? Is there an updated libmaxxminddb out there somewhere? Oh wait, found this: https://github.com/linuxserver/docker-mods/issues/853 And in that thread, someone posted this: "Alpine's libmaxmind package was only fixed in 3.20. The issue will persist until SWAG is rebased on alpine 3.20, which will be soon" So, I guess I'll wait before messing around with the script since the version I have now shows Alpine at 3.19.1 (2.11.0-ls307). Edited June 29 by nraygun Quote Link to comment
ElectricBadger Posted July 2 Share Posted July 2 On 6/21/2024 at 7:13 PM, alturismo said: did you try the EXTRA DOMAIN part yet ? of course both needs to be set to same DNS validation, sample cloudflare ... i never used it but may could be what you looking for Thanks — that seems to work when I try accessing the site in a browser that hasn’t accessed it before. In Vivaldi, opening a new tab and accessing the site also works. Simply reloading an existing tab gives this, which caused a bit of confusion! Off to the Vivaldi bug reporter I go… Quote Link to comment
joker1319 Posted July 18 Share Posted July 18 Hello, unfortunately I have the following problem... Today I configured my nginx.conf so that I have two domains. Here is the config for the two exemplary domains “domainone.com” and “domaintwo.com”: server { listen *:80 default_server; listen *:443 ssl default_server; server_name _; include /config/nginx/ssl.conf; set $root /app/www/public; if (!-d /app/www/public) { set $root /config/www; } root $root; index index.html index.htm index.php; location / { try_files $uri $uri/ /index.html /index.htm /index.php$is_args$args; } location /nginx_status { stub_status; allow 127.0.0.1; allow 192.168.178.42; allow 192.168.178.22; deny all; } location ~ ^(.+\.php)(.*)$ { fastcgi_split_path_info ^(.+\.php)(.*)$; if (!-f $document_root$fastcgi_script_name) { return 404; } fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include /etc/nginx/fastcgi_params; } location ~ /\.ht { deny all; } } server { listen *:80; listen *:443 ssl; server_name domaintwo.com www.domaintwo.com; include /config/nginx/ssl.conf; root /config/www/domaintwo; index index.html index.htm index.php; location / { try_files $uri $uri/ /index.html /index.htm /index.php$is_args$args; } location ~ ^(.+\.php)(.*)$ { fastcgi_split_path_info ^(.+\.php)(.*)$; if (!-f $document_root$fastcgi_script_name) { return 404; } fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include /etc/nginx/fastcgi_params; } location ~ /\.ht { deny all; } } server { listen *:80; listen *:443 ssl; server_name domainone.com www.domainone.com; include /config/nginx/ssl.conf; root /config/www/domainone; index index.html index.htm index.php; location / { try_files $uri $uri/ /index.html /index.htm /index.php$is_args$args; } location ~ ^(.+\.php)(.*)$ { fastcgi_split_path_info ^(.+\.php)(.*)$; if (!-f $document_root$fastcgi_script_name) { return 404; } fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include /etc/nginx/fastcgi_params; } location ~ /\.ht { deny all; } } With this setting, I reach the correct index.php of the respective domain (e.g. domainone.com => /config/www/domainone/index.php, domaintwo.com => /config/www/domaintwo/index.php, direct IP => /config/www/index.php). Now I wanted to add the following in the Nginx Proxy Manager under “Custom Nginx Configuration”, as I have already done successfully with other Poxys: proxy_buffers 8 16k; proxy_buffer_size 32k; port_in_redirect off; location / { proxy_pass $forward_scheme://$server:$port; auth_request /outpost.goauthentik.io/auth/nginx; error_page 401 = @goauthentik_proxy_signin; auth_request_set $auth_cookie $upstream_http_set_cookie; add_header Set-Cookie $auth_cookie; auth_request_set $authentik_username $upstream_http_x_authentik_username; auth_request_set $authentik_groups $upstream_http_x_authentik_groups; auth_request_set $authentik_email $upstream_http_x_authentik_email; auth_request_set $authentik_name $upstream_http_x_authentik_name; auth_request_set $authentik_uid $upstream_http_x_authentik_uid; proxy_set_header X-authentik-username $authentik_username; proxy_set_header X-authentik-groups $authentik_groups; proxy_set_header X-authentik-email $authentik_email; proxy_set_header X-authentik-name $authentik_name; proxy_set_header X-authentik-uid $authentik_uid; } location /outpost.goauthentik.io { proxy_pass https://192.168.178.9:9443/outpost.goauthentik.io; proxy_set_header Host $host; proxy_set_header X-Original-URL $scheme://$http_host$request_uri; add_header Set-Cookie $auth_cookie; auth_request_set $auth_cookie $upstream_http_set_cookie; proxy_pass_request_body off; proxy_set_header Content-Length ""; } location @goauthentik_proxy_signin { internal; add_header Set-Cookie $auth_cookie; return 302 /outpost.goauthentik.io/start?rd=$request_uri; } As soon as this is now in use, I am now suddenly always (regardless of whether domainone.com or domaintwo.com) redirected to /config/www/index.php and not to the respective domain folder. I also tried to rewrite “proxy_pass $forward_scheme://$server:$port;” to the correct domain directly (e.g.: https://domaintwo.com) but then I get “502 Bad Gateway”. Does anyone have an idea how I can use authentik for both domains? In the worst case, one of the domains cannot be used otherwise... If I should provide any other information, please just let me know. Thanks in advance! Quote Link to comment
PenguinGuy Posted July 24 Share Posted July 24 Hi everyone. I've been having some errors in my swag container log lately and not sure how to resolve. The errors are: nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in /config/nginx/site-confs/default.conf:15 nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in /config/nginx/site-confs/default.conf:16 Any help with this is greatly appreciated Quote Link to comment
gurulee Posted July 25 Share Posted July 25 On 7/24/2024 at 3:42 AM, PenguinGuy said: Hi everyone. I've been having some errors in my swag container log lately and not sure how to resolve. The errors are: nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in /config/nginx/site-confs/default.conf:15 nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in /config/nginx/site-confs/default.conf:16 Any help with this is greatly appreciated I had the same issue. Just remove the reference to 'http2' on those two lines in your conf file. Then restart Swag. Quote Link to comment
hundsboog Posted July 28 Share Posted July 28 Hey folks! Must confess, I've never switched to swag and let the deprecated letsencrypt docker just run (i know i know...). Today, I got an available update for it... why that? Can I safely run it? I had absolutely no issues the last time, so... Is it safe? Thanks! Quote Link to comment
Archonw Posted July 30 Share Posted July 30 Hello, i want to use Swag, but when i start the container i got this in my logs: Domain: kino.abc.abc.de Type: connection Detail: 178.200.xxx.xxx: Fetching https://kino.abc.abc.de:4433/.well-known/acme-challenge/IoSe-bfuoX6cLtRG8TNnOVEyWwaP6BrwgSVj92q2Yvo: Invalid port in redirect target. Only ports 80 and 443 are supported, not 4433 Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet. Some challenges have failed. Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details. ERROR: Cert does not exist! Please see the validation error above. The issue may be due to incorrect dns or port forwarding settings. Please fix your settings and recreate the container In the Swag template i use "bridge" and port 443 and 80. I switched the Unraid Webui to port 8088 and 4433. Quote Link to comment
vw-kombi Posted July 30 Share Posted July 30 8 minutes ago, Archonw said: Hello, i want to use Swag, but when i start the container i got this in my logs: Domain: kino.abc.abc.de Type: connection Detail: 178.200.xxx.xxx: Fetching https://kino.abc.abc.de:4433/.well-known/acme-challenge/IoSe-bfuoX6cLtRG8TNnOVEyWwaP6BrwgSVj92q2Yvo: Invalid port in redirect target. Only ports 80 and 443 are supported, not 4433 Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet. Some challenges have failed. Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details. ERROR: Cert does not exist! Please see the validation error above. The issue may be due to incorrect dns or port forwarding settings. Please fix your settings and recreate the container In the Swag template i use "bridge" and port 443 and 80. I switched the Unraid Webui to port 8088 and 4433. Plus your A record on your dns for you domain must point to your wan IP too. See the Hint above. Cant connect for some reason ? did you port forward your router to the swag IP/port ? port 80 and 443 ? Try one of the open oprt checkers on the internet ? Quote Link to comment
Archonw Posted July 30 Share Posted July 30 Thanks @vw-kombi, there was indeed a wrong port forwarding. Don't know when and why this happend. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.