Move PHP settings to PHP config files + Split Nginx config into SSL/non-SSL #1191
Conversation
...as e.g. enabling caching for CLI has no effect inside webserver config, which is not asked by CLI requests, e.g. by cron. We just leave the critical opcache size inside webserver config, in case hard coding 128M, so this will not allow other web services to full the cache and cause swapping.
";" at end of directive
| grep -q 'opcache.interned_strings_buffer=' $FP_PHP_BASE_DIR/mods-available/opcache.ini && sed -i '/opcache.interned_strings_buffer=/c\opcache.interned_strings_buffer=8' $FP_PHP_BASE_DIR/mods-available/opcache.ini || echo 'opcache.interned_strings_buffer=8' >> $FP_PHP_BASE_DIR/mods-available/opcache.ini | ||
| grep -q 'opcache.max_accelerated_files=' $FP_PHP_BASE_DIR/mods-available/opcache.ini && sed -i '/opcache.max_accelerated_files=/c\opcache.max_accelerated_files=10000' $FP_PHP_BASE_DIR/mods-available/opcache.ini || echo 'opcache.max_accelerated_files=10000' >> $FP_PHP_BASE_DIR/mods-available/opcache.ini | ||
| grep -q 'opcache.save_comments=' $FP_PHP_BASE_DIR/mods-available/opcache.ini && sed -i '/opcache.save_comments=/c\opcache.save_comments=1' $FP_PHP_BASE_DIR/mods-available/opcache.ini || echo 'opcache.save_comments=1' >> $FP_PHP_BASE_DIR/mods-available/opcache.ini | ||
| grep -q 'opcache.revalidate_freq=' $FP_PHP_BASE_DIR/mods-available/opcache.ini && sed -i '/opcache.revalidate_freq=/c\opcache.revalidate_freq=1' $FP_PHP_BASE_DIR/mods-available/opcache.ini || echo 'opcache.revalidate_freq=1' >> $FP_PHP_BASE_DIR/mods-available/opcache.ini |
There was a problem hiding this comment.
Or should we also do that just inside webserver config, as it is set to "60" during PHP installation, which is also totally fine for CLI requests.
|
What do we do on removing Nextcloud with the PHP settings? For now these settings inside these files are not changed on any ofter dietpi-software installation, so we can simply remove the related lines. |
MichaIng
changed the title
|
About https://github.com/Fourdee/DietPi/issues/1067#issuecomment-337935644: Added nginx conf again by this PR. Indeed the nginx nextcloud.config contains settings (fastcgi_param HTTPS on; and HSTS) that are just relevant/valid for SSL enabled systems. If I understand right, fastcgi_param needs to be in case set for every sub location, so we can't set all of this in the default nginx ssl config, as it is possible with apache. So we need 2 versions of the nextcloud config file, one for ssl enabled systems (how do we test?) and one for systems without ssl. Or maybe we can create a delta config that just adds the ssl relevant parts to to the nextcloud location directives, which can be then enabled and disabled, without the need to directly rewrite the basic (non-ssl) nginx nextcloud.config? |
Legend, thanks 👍
This should be the default item. The only instance of SSL enabled (in DietPi at least), is when the user uses http://dietpi.com/phpbb/viewtopic.php?f=8&t=5&p=1061#p1062. Although, not sure if Nginx is implemented yet, will need to check. I'd stick with non-SSL for now. We can always |
|
@Fourdee So I would directly prepare and additional SSL conf, but yeah non-SSL by default of course. Need to find out a good check, if SSL is enabled or not, for related webservers and then sed the config file, use an additional one, or include one, that just adds all ssl relevant directives: |
MichaIng
changed the title
MichaIng
changed the title
Would be great if we could make this possible, however, 99.9% of routers these days have port 80 disabled to internal devices, unless port forwarded by the user in router settings, in which case its their responsibility :) |
|
Hehe yeah of course opening/forwarding the ports of course still needs to be done manually. I just mean the SSL configuration by e.g. python-certbot-nginx/apache package and things like this 😉. Btw. NextcloudPi uses some UPnP method to automatically forward the ports, but it does not work on every system/with every router of course. |
|
Do you know, which directives depend on SSL? And how do we check reliable, if SSL is active? Check for some active nginx config with "listen 443" inside seems not too reliable for me? Better, if we could do something like a curl request on you own 443 port or something, but I don't know how to realize this 😅. |
I have no idea, sorry. My SSL knowledge and site config knowledge is minimal. |
|
Thanks for cleaning this up 👍 |
...as e.g. enabling caching for CLI has no effect inside webserver config, which is not asked by CLI requests, e.g. by cron.
We just leave the critical opcache size inside webserver config, in case hard coding 128M, so this will not allow other web services to full the cache and cause swapping.