[Support] Linuxserver.io - SWAG - Secure Web Application Gateway (Nginx/PHP/Certbot/Fail2ban)


Recommended Posts

4 hours ago, aptalca said:

Post a log

Here's the log from letsencrypt. 

Screenshot_2018-12-09-11-37-51.png

 

I did install the nginx container by itself with same ports and it is up and running. I am able to get to "Welcome to our server" page using same ports and by using my domain. The problem seems to be with letsencrypt not starting up nginx?

Edited by jeiroq
Additional info for diagnosing.
Link to comment

sorry to butt in, but could someone tell me what I have to do to increase the max upload limit with letsencypt and Wordpress?
I added the following to both a php.ini file that I created inside the wp-admin folder, as well as adding it to the php-local.ini file inside letsencrypt/php, and restarting letsencrypt:

upload_max_filesize = 2048M
post_max_size = 2048M
max_execution_time = 3600

Wordpress still limits me to a max upload size of 2MB, though. What am I doing wrong?

Link to comment
10 hours ago, jeiroq said:

Here's the log from letsencrypt. 

Screenshot_2018-12-09-11-37-51.png

 

I did install the nginx container by itself with same ports and it is up and running. I am able to get to "Welcome to our server" page using same ports and by using my domain. The problem seems to be with letsencrypt not starting up nginx?

With letsencrypt, you're trying the https address, right?

Log suggests nginx is started and there are no errors. 

What happens when you try to connect? 

Link to comment
9 hours ago, tillkrueger said:

sorry to butt in, but could someone tell me what I have to do to increase the max upload limit with letsencypt and Wordpress?
I added the following to both a php.ini file that I created inside the wp-admin folder, as well as adding it to the php-local.ini file inside letsencrypt/php, and restarting letsencrypt:

upload_max_filesize = 2048M
post_max_size = 2048M
max_execution_time = 3600

Wordpress still limits me to a max upload size of 2MB, though. What am I doing wrong?

Is wordpress set up in the letsencrypt container or are you reverse proxying? 

 

I have them set to 64MB the same way and it works

Link to comment
7 hours ago, H2O_King89 said:

I'm starting to have a long boot time and it's stopping at this on logs

 


Non-interactive renewal: random delay of 380 seconds

Update.. Todays update fix the long start up time.

That was an annoying forced change by letsencrypt done to reduce their server load at peak times. I guess they forgot that many people have scripts that are not run by cron. 

 

We pushed an emergency update last night to remove cert renewal during container start

  • Like 1
Link to comment
40 minutes ago, aptalca said:

With letsencrypt, you're trying the https address, right?

Log suggests nginx is started and there are no errors. 

What happens when you try to connect? 

If I go to https://requests.mydomain.com or http:// I get a refused connection/this site can't be reached. Now if I use https://192.168.1.10:1443 I get "your connection to this site isn't secure" due to not being able to validate certificate. So, this is progress! If I select to continue, I can then get "welcome to our server". 

 

I guess a follow up here would also be how to be able to type in "requests.mydomain.com" and get https automatically? First need to figure out the certificate issue though. 

 

Edit: made 2 changes in the container settings. Validation was changed from http to https, and AppData config path was changed from appdata/letsencrypt/config to just appdata/letsencrypt/ - I can now access ombi through https://requests.mydomain.com - now I need to find how to force https now so it doesn't have to be manually typed in. 

 

Thank you for your patience and great wealth of knowledge, it's much appreciated. 

Edited by jeiroq
Updated information
Link to comment
If I go to https://requests.mydomain.com or http:// I get a refused connection/this site can't be reached. Now if I use https://192.168.1.10:1443 I get "your connection to this site isn't secure" due to not being able to validate certificate. So, this is progress! If I select to continue, I can then get "welcome to our server". 
 
I guess a follow up here would also be how to be able to type in "requests.mydomain.com" and get https automatically? First need to figure out the certificate issue though. 
 
Edit: made 2 changes in the container settings. Validation was changed from http to https, and AppData config path was changed from appdata/letsencrypt/config to just appdata/letsencrypt/ - I can now access ombi through https://requests.mydomain.com - now I need to find how to force https now so it doesn't have to be manually typed in. 
 
Thank you for your patience and great wealth of knowledge, it's much appreciated. 

For http to https its in the site config at the top. It say to remove the # for http to https.


Sent from my iPhone using Tapatalk Pro
Link to comment
1 hour ago, aptalca said:

Is wordpress set up in the letsencrypt container or are you reverse proxying? 

 

I have them set to 64MB the same way and it works

I set WP up inside the www folder of the letsencrypt folder, so that means it's set up in the container, right? I still don't really understand what reverse proxy is and does, but shall research that soon...comes up so often, here, that it must be something I will also have to deal with sooner or later.

not sure why it works for you and not for me...is the syntax I used correct? 2048M would be 2GB, and that is how I would write it, right?
and 3600 would be an hour in seconds, correct? just trying to prepare for some rather large video renders that need to be uploaded from time to time.

hmm, what else could I do to trouble-shoot this? restarting the Docker is usually enough to activate changes made in the ini files, correct?

do I need to change both the php-local.ini *and the php.ini file that I created, or will php-local.ini override the php.ini file inside of the wp-admin folder anyway?

Link to comment
8 hours ago, jeiroq said:

If I go to https://requests.mydomain.com or http:// I get a refused connection/this site can't be reached. Now if I use https://192.168.1.10:1443 I get "your connection to this site isn't secure" due to not being able to validate certificate. So, this is progress! If I select to continue, I can then get "welcome to our server". 

 

I guess a follow up here would also be how to be able to type in "requests.mydomain.com" and get https automatically? First need to figure out the certificate issue though. 

 

Edit: made 2 changes in the container settings. Validation was changed from http to https, and AppData config path was changed from appdata/letsencrypt/config to just appdata/letsencrypt/ - I can now access ombi through https://requests.mydomain.com - now I need to find how to force https now so it doesn't have to be manually typed in. 

 

Thank you for your patience and great wealth of knowledge, it's much appreciated. 

?? You didn't mention you already made changes to enable reverse proxy. That requires a whole another set of troubleshooting methods. 

 

Https is not a valid option for validation. Check the docs

Link to comment
7 hours ago, tillkrueger said:

I set WP up inside the www folder of the letsencrypt folder, so that means it's set up in the container, right? I still don't really understand what reverse proxy is and does, but shall research that soon...comes up so often, here, that it must be something I will also have to deal with sooner or later.

not sure why it works for you and not for me...is the syntax I used correct? 2048M would be 2GB, and that is how I would write it, right?
and 3600 would be an hour in seconds, correct? just trying to prepare for some rather large video renders that need to be uploaded from time to time.

hmm, what else could I do to trouble-shoot this? restarting the Docker is usually enough to activate changes made in the ini files, correct?

do I need to change both the php-local.ini *and the php.ini file that I created, or will php-local.ini override the php.ini file inside of the wp-admin folder anyway?

What php.ini did you create? Only modify the php local and restart. You don't need anything else

Link to comment
8 minutes ago, aptalca said:

?? You didn't mention you already made changes to enable reverse proxy. That requires a whole another set of troubleshooting methods. 

 

Https is not a valid option for validation. Check the docs

I guess my noobness is showing. I hadn't realized I did this? Sorry for the confusion.

Link to comment

 

EDIT:  Sometimes typing something out can REALLY help.  It occurred to me no more than 10 minutes after publishing this post that these lines jumped out at me:

 

		#auth_basic "Restricted";
		#auth_basic_user_file /config/nginx/.htpasswd;

I commented out those extra authentication steps and IT WORKS!  I guess I was close and not as stupid as I thought--would love to hear best practices moving forward and if this approach in sites-conf/default is preferable to /proxy-conf/app.subdomain.conf and what the distinction is.  Leaving this here in case it helps someone down the road.

 

I've been running letsencrypt perfectly with Nextcloud for years now thanks to this awesome community---I've recently decided to try more dockers than just Plex & Nextcloud (specifically Bitwarden but my questions are primarily around letsencrypt) and I'm trying to learn how to publish more than one docker.  I've jumped back to square one and learning about the configs etc (from watching spaceinvader videos and reading articles at linuxserverio) and feel like I'm SUPER close but missing something subtle somewhere (or maybe just think I'm closer than I actually am).

 

I've got DNS working for a custom domain (was already working for nextcloud) for bitwarden, created the new docker network and moved the containers over to that network for communications (as I understand it is necessary) and then passing the bitwarden subdomain to letsencrypt successfully after working with the nginx/proxy-confs and creating a bitwarden.subdomain.conf file and then realizing there's default in nginx/site-confs that looks like the following and when I would hit bw.mydomain.com externally I'd land on the nextcloud landing page.

 

server {
	listen 80;
	
	listen 443 ssl;
	
	root /config/www;
	index index.html index.htm index.php;
	
	server_name nextcloud.mydomain.com;
	
	
	###SSL Certificates
	ssl_certificate /config/keys/letsencrypt/fullchain.pem;
	ssl_certificate_key /config/keys/letsencrypt/privkey.pem;
	
	###Diffie–Hellman key exchange ###
	ssl_dhparam /config/nginx/dhparams.pem;
	ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
	

        ###Extra Settings###
	ssl_prefer_server_ciphers on;
	ssl_session_cache shared:SSL:10m;

        ### Add HTTP Strict Transport Security ###
	add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
	add_header Front-End-Https on;

	client_max_body_size 0;

	location / {
    proxy_pass https://172.23.1.31:444/;
  }
}

So I tried several things from that point:

1) added a line to reference the proxy-confs (with the *.subdomain.conf file I created) with an include statement in the site-confs/default (which ended up in errors in letsencrypt log on startup).

2) ignored the proxy-confs all together and added the following to my sites-confs/default after the above code:

 

server {
	
	listen 80;
	
	listen 443 ssl;
	
	server_name bw.mydomain.com;
	
	include /config/nginx/ssl.conf;
	
	client_max_body_size 0;


	location / {
		auth_basic "Restricted";
		auth_basic_user_file /config/nginx/.htpasswd;
		include /config/nginx/proxy.conf;
		resolver 127.0.0.11 valid=30s;
		set $upstream_Bitwarden Bitwarden;
		proxy_pass http://172.23.1.31:8343;
  }
}

I no longer land on the nextcloud landing page but get a generic prompt for a username and password for authentication and get no further (I can access the docker internally no problem).  I've tweaked more than a few 

 

I'm curious what best practice is?  Is it to use the proxy-confs or to use site-confs to address the various services?  In my research I've seen it done both ways...thanks in advance for any and all advice/help!

Edited by talmania
Solved--leaving to help out others
Link to comment
3 hours ago, aptalca said:

What php.ini did you create? Only modify the php local and restart. You don't need anything else

I followed instructions on a Wordpress forum about how to increase the upload limit for a single site (since I am planning to set it up as multi-site), which said that one should create a php.ini file in the wp-anim folder.

So, I deleted that one and restarted the docker, and lo and behold, it says Maximum upload file size: 2 GB
although I now wonder whether it said that even on my last restart, because I was about to write "it says "2MB" again, because my eyes saw 2MB when really it said 2GB.

does php-local.ini always override any other php.ini? I am asking because I'd like to assign different upload limits to different sites which will be hosted under WP multi-site.

thanks for your help, aptalca!

Link to comment

I have three A-records (empty, *, and "www"), and deleting the A-record for "www" did not lead to the desired result...typing in just mydomainname.com resolves to www.mydonmainname.com.

How can I avoid that? I just selected for Wordpress multi sites to go into subfolders, rather than subdomains...not my preferred way of doing this, but so be it, for now.

I'd still like to know how to have it resolve to my domain name without the www, though, if anyone knows.

Link to comment
1 hour ago, tillkrueger said:

I have three A-records (empty, *, and "www"), and deleting the A-record for "www" did not lead to the desired result...typing in just mydomainname.com resolves to www.mydonmainname.com.

How can I avoid that? I just selected for Wordpress multi sites to go into subfolders, rather than subdomains...not my preferred way of doing this, but so be it, for now.

I'd still like to know how to have it resolve to my domain name without the www, though, if anyone knows.

Check your site config. You probably have a redirect somewhere

Link to comment

I see...ok, here is what's in mine...my un-schooled eyes don't see something that looks like a re-direct in there, though:

 

## Version 2018/09/12 - Changelog: https://github.com/linuxserver/docker-letsencrypt/commits/master/root/defaults/default

# listening on port 80 disabled by default, remove the "#" signs to enable
# redirect all traffic to https
#server {
#    listen 80;
#    server_name _;
#    return 301 https://$host$request_uri;
#}

# main server block
server {
    listen 443 ssl default_server;

    root /config/www;
    index index.html index.htm index.php;

    server_name _;

    # enable subfolder method reverse proxy confs
    include /config/nginx/proxy-confs/*.subfolder.conf;

    # all ssl related config moved to ssl.conf
    include /config/nginx/ssl.conf;
    
    # enable for ldap auth
    #include /config/nginx/ldap.conf;

    client_max_body_size 0;

    location / {
        try_files $uri $uri/ /index.html /index.php?$args =404;
    }

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        include /etc/nginx/fastcgi_params;
    }

# sample reverse proxy config for password protected couchpotato running at IP 192.168.1.50 port 5050 with base url "cp"
# notice this is within the same server block as the base
# don't forget to generate the .htpasswd file as described on docker hub
#    location ^~ /cp {
#        auth_basic "Restricted";
#        auth_basic_user_file /config/nginx/.htpasswd;
#        include /config/nginx/proxy.conf;
#        proxy_pass http://192.168.1.50:5050/cp;
#    }

}

# sample reverse proxy config without url base, but as a subdomain "cp", ip and port same as above
# notice this is a new server block, you need a new server block for each subdomain
#server {
#    listen 443 ssl;
#
#    root /config/www;
#    index index.html index.htm index.php;
#
#    server_name cp.*;
#
#    include /config/nginx/ssl.conf;
#
#    client_max_body_size 0;
#
#    location / {
#        auth_basic "Restricted";
#        auth_basic_user_file /config/nginx/.htpasswd;
#        include /config/nginx/proxy.conf;
#        proxy_pass http://192.168.1.50:5050;    
#    }
#}

# sample reverse proxy config for "heimdall" via subdomain, with ldap authentication
# ldap-auth container has to be running and the /config/nginx/ldap.conf file should be filled with ldap info
# notice this is a new server block, you need a new server block for each subdomain
#server {
#    listen 443 ssl;
#
#    root /config/www;
#    index index.html index.htm index.php;
#
#    server_name heimdall.*;
#
#    include /config/nginx/ssl.conf;
#
#    include /config/nginx/ldap.conf;
#
#    client_max_body_size 0;
#
#    location / {
#        # the next two lines will enable ldap auth along with the included ldap.conf in the server block
#        auth_request /auth;
#        error_page 401 =200 /login;
#
#        include /config/nginx/proxy.conf;
#        resolver 127.0.0.11 valid=30s;
#        set $upstream_heimdall heimdall;
#        proxy_pass https://$upstream_heimdall:443;
#    }
#}

# enable subdomain method reverse proxy confs
include /config/nginx/proxy-confs/*.subdomain.conf;
# enable proxy cache for auth
proxy_cache_path cache/ keys_zone=auth_cache:10m;
 

Link to comment
9 hours ago, tillkrueger said:

I see...ok, here is what's in mine...my un-schooled eyes don't see something that looks like a re-direct in there, though:

 

## Version 2018/09/12 - Changelog: https://github.com/linuxserver/docker-letsencrypt/commits/master/root/defaults/default

# listening on port 80 disabled by default, remove the "#" signs to enable
# redirect all traffic to https
#server {
#    listen 80;
#    server_name _;
#    return 301 https://$host$request_uri;
#}

# main server block
server {
    listen 443 ssl default_server;

    root /config/www;
    index index.html index.htm index.php;

    server_name _;

    # enable subfolder method reverse proxy confs
    include /config/nginx/proxy-confs/*.subfolder.conf;

    # all ssl related config moved to ssl.conf
    include /config/nginx/ssl.conf;
    
    # enable for ldap auth
    #include /config/nginx/ldap.conf;

    client_max_body_size 0;

    location / {
        try_files $uri $uri/ /index.html /index.php?$args =404;
    }

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        include /etc/nginx/fastcgi_params;
    }

# sample reverse proxy config for password protected couchpotato running at IP 192.168.1.50 port 5050 with base url "cp"
# notice this is within the same server block as the base
# don't forget to generate the .htpasswd file as described on docker hub
#    location ^~ /cp {
#        auth_basic "Restricted";
#        auth_basic_user_file /config/nginx/.htpasswd;
#        include /config/nginx/proxy.conf;
#        proxy_pass http://192.168.1.50:5050/cp;
#    }

}

# sample reverse proxy config without url base, but as a subdomain "cp", ip and port same as above
# notice this is a new server block, you need a new server block for each subdomain
#server {
#    listen 443 ssl;
#
#    root /config/www;
#    index index.html index.htm index.php;
#
#    server_name cp.*;
#
#    include /config/nginx/ssl.conf;
#
#    client_max_body_size 0;
#
#    location / {
#        auth_basic "Restricted";
#        auth_basic_user_file /config/nginx/.htpasswd;
#        include /config/nginx/proxy.conf;
#        proxy_pass http://192.168.1.50:5050;    
#    }
#}

# sample reverse proxy config for "heimdall" via subdomain, with ldap authentication
# ldap-auth container has to be running and the /config/nginx/ldap.conf file should be filled with ldap info
# notice this is a new server block, you need a new server block for each subdomain
#server {
#    listen 443 ssl;
#
#    root /config/www;
#    index index.html index.htm index.php;
#
#    server_name heimdall.*;
#
#    include /config/nginx/ssl.conf;
#
#    include /config/nginx/ldap.conf;
#
#    client_max_body_size 0;
#
#    location / {
#        # the next two lines will enable ldap auth along with the included ldap.conf in the server block
#        auth_request /auth;
#        error_page 401 =200 /login;
#
#        include /config/nginx/proxy.conf;
#        resolver 127.0.0.11 valid=30s;
#        set $upstream_heimdall heimdall;
#        proxy_pass https://$upstream_heimdall:443;
#    }
#}

# enable subdomain method reverse proxy confs
include /config/nginx/proxy-confs/*.subdomain.conf;
# enable proxy cache for auth
proxy_cache_path cache/ keys_zone=auth_cache:10m;
 

That seems totally stock. I'm assuming your wordpress is being served in the www folder. You must have a redirect in wordpress. Did you set the website url as www.domain.com in wordpress settings? 

 

There could also be browser cache when 301 redirects are involved. Try a new browser or incognito

Link to comment
2 hours ago, tillkrueger said:

When going to mydomain.com in a Safari private window, it still resolves to www.mydomain.com.

Yes, WP is set up in the root of the letsencrypt www folder. I don't remember explicitly telling WP to use "www.mydomain.com" during install. If I inadvertently did, where would I be able to check and change that?

Go to WordPress admin, settings, general and you'll see two fields for wp address and site address. My guess is they are set up with www

  • Like 1
Link to comment

so, going by their instructions, anywhere in the db tables they pointed out (wp_blogs | wp_options | wp_site | wp_sitemeta) where I now see https://www.mydomainname.com", I can just delete the www. and save the table, and that should solve my issue?

I just exported the database, as it is now, which should allow me to re-import it, should anything not work right anymore, afterwards, right?

well, here we go...crossing my fingers that this will do it.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.