govperm Posted January 22 Share Posted January 22 20 hours ago, BigBoyMarky said: I replaced both the ssl.conf and nginx.conf files with the sample ones to update them since I did not make any custom modifications to either one of those and this resolved my issue. This worked for me too. Thank you. 1 Quote Link to comment
Todo88 Posted January 23 Share Posted January 23 Replaced the files and I'm back up and running, thanks! Quote Link to comment
dcreager Posted January 23 Share Posted January 23 My ngnix.conf had the include /etc/nginx/conf.d/*.conf; inside the http block, I moved it to outside at the beginning and all worked fine 1 3 Quote Link to comment
GravitySandwich Posted January 23 Share Posted January 23 55 minutes ago, dcreager said: My ngnix.conf had the include /etc/nginx/conf.d/*.conf; inside the http block, I moved it to outside at the beginning and all worked fine Thank you! That indeed worked. For me it was already auto filled at the top and i only had to remove it from the http block. All up and running again now. Quote Link to comment
Picha Posted January 23 Share Posted January 23 5 hours ago, dcreager said: My ngnix.conf had the include /etc/nginx/conf.d/*.conf; inside the http block, I moved it to outside at the beginning and all worked fine Thanks, this solved the problem Quote Link to comment
Outlawtorn Posted January 24 Share Posted January 24 On 1/23/2023 at 7:36 AM, dcreager said: My ngnix.conf had the include /etc/nginx/conf.d/*.conf; inside the http block, I moved it to outside at the beginning and all worked fine Thanks solved my issues as well! Quote Link to comment
Gragorg Posted January 25 Share Posted January 25 My swag is no longer working nothing on my end was changed and my log is spamming nginx: [emerg] "stream" directive is not allowed here in /etc/nginx/conf.d/stream.conf:3 Any help would be great. Quote Link to comment
DayspringGaming Posted January 25 Share Posted January 25 I'm getting the same error as well. So now all of those specific containers that use it are broken. Quote Link to comment
vw-kombi Posted January 25 Share Posted January 25 (edited) Strangely, I am not getting any of these issues and I update each time it asks. I take a deep breath each time, but it alwats starts fine. I installed swag about 6 months ago using the ibracorp youtube video. These are up there with spaceinvaders for 'education'. There must be something in spaceinvaders setup. Maybe re-create with the ibracorp guide ? I also added some extra stuff - geoblocking, custom jails etc. Edited January 25 by vw-kombi Quote Link to comment
alturismo Posted January 25 Share Posted January 25 30 minutes ago, Gragorg said: Any help would be great. 28 minutes ago, DayspringGaming said: I'm getting the same error as well. So now all of those specific containers that use it are broken. guys, may just look some posts above yours for a solution, in the future, when you may look at your docker logs from swag you will prolly see the messages which files are outdated and should be updated, consider it from time to time then this wouldnt have happened ... and as some of us (including me) do custom stuff in their files we dont want them to be replaced automatically, so yes, a wanted behaviour ... Quote Link to comment
alturismo Posted January 25 Share Posted January 25 18 minutes ago, vw-kombi said: I installed swag about 6 months ago using the ibracorp youtube video. Just now, alturismo said: in the future, when you may look at your docker logs from swag you will prolly see the messages which files are outdated and should be updated i think its almost 1 year now when the change was done ... so you can imagine how often others are checking their logs well, as the solution was pointed few posts above we also see how much time for a lookup was invested no offense, just wondering from time to time when i lookup and see its standing there ... 1 Quote Link to comment
Gragorg Posted January 25 Share Posted January 25 18 minutes ago, alturismo said: well, as the solution was pointed few posts above we also see how much time for a lookup was invested no offense, just wondering from time to time when i lookup and see its standing there ... I replaced both the ssl.conf and nginx.conf files with the sample ones however I seem to get the same results. The 3 subdomain.conf files I use I believe only had the server name changed. Its been a long time so am a bit lost. Quote Link to comment
Gragorg Posted January 25 Share Posted January 25 Ok thanks I didn't realize there was more than the two files to change. Changed all them in the outdated list and seem to be good. Thanks Quote Link to comment
Soulflyzz Posted January 25 Share Posted January 25 (edited) 11 hours ago, Gragorg said: My swag is no longer working nothing on my end was changed and my log is spamming nginx: [emerg] "stream" directive is not allowed here in /etc/nginx/conf.d/stream.conf:3 Any help would be great. Hello, I am having this same issue and I have found a temp solution. I went into the condole and deleted that file that was crashing the system. Then rebooted swag. everything came back online and is working for about 24 hours then that file came back and broke it again. have you or anyone sound a cause or solution to this issue yet? ***Before anyone spams me I have found the solution by continued reading in this tread. Delete if wanted or keep as a reference on please read before you post. Edited January 25 by Soulflyzz Quote Link to comment
shaunvis Posted January 25 Share Posted January 25 For the life of me I can't get. SWAG and Cloudflare working again. I just set this up this morning and had it working. I had one subdomain, sonarr. And I was and to connect just fine. Then I added another subdomain sonarr,plex and I restarted the container & it fails to get a cert now. I believe when I got it working earlier I had to turn off SSL on Cloudflare. But that doesn't work now. Nothing works it seems. I get: "Certbot failed to authenticate some domains (authenticator: dns-cloudflare). The Certificate Authority reported these problems:" And: " Hint: The Certificate Authority failed to verify the DNS TXT records created by --dns-cloudflare. Ensure the above domains are hosted by this DNS provider, or try increasing --dns-cloudflare-propagation-seconds (currently 10 seconds). Some challenges have failed." Any ideas? I"m banging my head against a wall here because I feel like I'm missing something simple Quote Link to comment
Gragorg Posted January 26 Share Posted January 26 21 hours ago, Soulflyzz said: have you or anyone sound a cause or solution to this issue yet? For me there was a chart in the swag log with all the files that were outdated (around 8 files for me). I replaced them all with the new sample files. I was using 3 .conf files that I had to edit to match my old server names from when I set it up. Do you have a list of out dated files in the log? You will likely have to restart Swag to see them as my log was spamming an error. 1 Quote Link to comment
tvd1 Posted January 27 Share Posted January 27 On 1/22/2023 at 12:32 PM, nraygun said: Confirming this worked for me too. Not sure I needed to replace both, but I did anyway and Swag and Nextcloud are both back and up and running. For noobs like me, here's what I did: 1. Stop the Swag container 2. Go to the /mnt/appdata/swag folder 3. Rename your ssl.conf to ssl.conf.old and nginx.conf to nginx.conf.old (just in case we to restore them) 4. Copy ssl.conf.sample to ssl.conf and nginx.conf.sample to nginx.conf 5. Start the container and you should be good. Thanks for this, i'm back up and running now too. (though my files were in /mnt/user/appdata/swag/nginx/ ) One odd thing, one of my web facing apps continued to work, even though its on the same proxy network as swag. I must have it misconfigured? Quote Link to comment
Cpt. Chaz Posted January 30 Share Posted January 30 (edited) On 1/22/2023 at 11:32 AM, nraygun said: Confirming this worked for me too. Not sure I needed to replace both, but I did anyway and Swag and Nextcloud are both back and up and running. For noobs like me, here's what I did: 1. Stop the Swag container 2. Go to the /mnt/appdata/swag folder 3. Rename your ssl.conf to ssl.conf.old and nginx.conf to nginx.conf.old (just in case we to restore them) 4. Copy ssl.conf.sample to ssl.conf and nginx.conf.sample to nginx.conf 5. Start the container and you should be good. For anyone experiencing this issue (for noobs, it doesn't matter if you still have this container called letsencrypt, directory structure is still the same), this is exactly the fix for it. Although it's worth pointing out these .conf files are in the nginx sub-folder for this container, so the full path is: /mnt/user/appdata/swag/nginx inside this folder, you'll find the nginx.conf and ssl.conf files. if you're using the terminal, use these commands: mv nginx.conf nginx.conf.bak mv ssl.conf ssl.conf.bak Then start the container. Step 4 above is unnecessary, when you start the container it'll generate new/updated .conf files. Thanks to @BigBoyMarky for pointing this out for all of us! Edited January 30 by Cpt. Chaz typo 1 Quote Link to comment
dehein2 Posted January 31 Share Posted January 31 (edited) Hi all, since the last update ( a week ago) a have the issue that swag stops working every night. SO each morning i have to manually restart the container and it works just fine again. I replaced the conf and ssl file as described above after having the same issue. Here's the latest error.log 2023/01/29 15:09:15 [crit] 417#417: *2403 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443 2023/01/29 17:24:29 [crit] 417#417: *3074 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443 2023/01/29 19:08:12 [crit] 417#417: *3552 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443 2023/01/30 01:40:04 [crit] 419#419: *5074 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443 2023/01/30 08:51:41 [error] 417#417: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 1245:1234:21:123:402:5123:1234:4123, server: nextcloud.*, request: "PROPFIND /remote.php/dav/files/dehein/ HTTP/1.1", upstream: "https://192.168.2.200:443/remote.php/dav/files/dehein/", host: "nextcloud.myserver.com" 2023/01/30 08:51:41 [error] 417#417: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 1245:1234:21:123:402:5123:1234:4123, server: nextcloud.*, request: "PROPFIND /remote.php/dav/files/dehein/ HTTP/1.1", upstream: "https://[1234:1234:1234:1234::5]:443/remote.php/dav/files/dehein/", host: "nextcloud.myserver.com" 2023/01/30 08:51:41 [error] 417#417: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 1245:1234:21:123:402:5123:1234:4123, server: nextcloud.*, request: "PROPFIND /remote.php/dav/files/dehein/ HTTP/1.1", upstream: "https://192.168.2.200:443/502.html", host: "nextcloud.myserver.com" 2023/01/30 08:51:41 [error] 417#417: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 1245:1234:21:123:402:5123:1234:4123, server: nextcloud.*, request: "PROPFIND /remote.php/dav/files/dehein/ HTTP/1.1", upstream: "https://[1234:1234:1234:1234::5]:443/502.html", host: "nextcloud.myserver.com" 2023/01/30 14:16:07 [crit] 419#419: *1532 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443 2023/01/30 15:28:52 [crit] 420#420: *1932 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443 2023/01/30 19:08:12 [error] 417#417: *2987 vault could not be resolved (3: Host not found), client: 1245:1234:21:123:402:5123:1234:4123, server: vault.*, request: "GET / HTTP/1.1", host: "vault.myserver.com" 2023/01/30 19:08:12 [error] 417#417: *2987 vault could not be resolved (3: Host not found), client: 1245:1234:21:123:402:5123:1234:4123, server: vault.*, request: "GET / HTTP/1.1", host: "vault.myserver.com" 2023/01/30 21:44:36 [crit] 417#417: *3459 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443 2023/01/30 22:08:55 [crit] 420#420: *3561 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443 2023/01/31 09:26:17 [crit] 419#419: *323 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443 Thanks helping Edited January 31 by dehein2 Quote Link to comment
akshunj Posted February 2 Share Posted February 2 On 1/23/2023 at 3:08 PM, Picha said: Thanks, this solved the problem confirming same here. Solved the problem for me Quote Link to comment
rutherford Posted February 4 Share Posted February 4 Is this important from the SWAG log? Quote /config/nginx/geoip2.conf exists. Please migrate to https://github.com/linuxserver/docker-mods/tree/swag-maxmind Quote Link to comment
alturismo Posted February 4 Share Posted February 4 37 minutes ago, rutherford said: Is this important from the SWAG log? Quote well, more or less self explaining ... where you using geoblocking ? the "old" version was configured in geoip2.conf which is deprecated, so either you migrate to maxmind or in case you never used it anyway, just wipe the file to get rid of this message. 1 Quote Link to comment
flyize Posted February 8 Share Posted February 8 (edited) How do I prevent SWAG from handing out an SSL certificate when someone visits my IP address? If someone views that cert, they can then see the domains its being used for and attempt to access them. I know 'security through obscurity' isn't great, but its at least another step for an attacker to have to take... edit: Answered my own question by adding this to the default.conf for NGINX ssl_reject_handshake on; Edited February 8 by flyize Quote Link to comment
Cybernaut Posted February 9 Share Posted February 9 Hi Folks. I apologize it this has already been addressed. I've been searching for a couple hours, and frankly, I haven't read this 238 page thread. I started receiving emails saying my letsencrypt certs are about to expire. Delving into it, it looks like the last log I have in the appdata/swag/log/letsencrypt folders is dated 11/23/22 (below). It looks like the cron job is no longer running? Appreciate any help. cronjob running on Wed Nov 23 02:08:00 MST 2022 Running certbot renew Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/my.domain.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Certificate not yet due for renewal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The following certificates are not due for renewal yet: /etc/letsencrypt/live/my.domain/fullchain.pem expires on 2023-02-13 (skipped) No renewals were attempted. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Quote Link to comment
Gragorg Posted February 9 Share Posted February 9 I am trying to get Swag on my primary server to open containers on my backup server which is in the same subnet. Does anyone have an example of how I would edit conf files to achieve this? I assume I don’t need to run a second instance of Swag on my backup server? 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.