Hi guys, im triying to use a nginx directive with the merge option (as the manual says) on a subdomain (vhost) and do not work.. for example: location @php { ##merge## fastcgi_read_timeout 300; } after the process is done, if i check the vhost file on the file system the directive is not merged the weird thing is that this same directive works of normal website... Anyone know what could be happening here ?
Check the nginx sites-enabled folder if there is a config file for this vhost subdomain with .err file ending.
Hi till, thank you for your quick response, i appreciate that. Looking the nginx folder, i dont have any file with that extension. The version of ISPConfig is: (Ubuntu 22.04.3 LTS (Jammy Jellyfish)) ISPConfig 3.2.11p1
Ok, that's good so far. When you look into the host of that site, is the directive you added in there at all but not merged? or is it missing completely?
The standart block is there, but the part that is supposed to be merged is missing.. I dont know if there is any logs where i can find more information about this.. Attached a couple of screenshots: - First is the directive that i have on the ISPconfig panel - Second is the resulting file that i get
Please try if it works with this: Code: location @php {##merge## fastcgi_read_timeout 300; } I removed one whitespace.
I've just tested it here using the snippet from post #7, and it works fine; I've been using ISPConfig 3.2.11p1 on that system.
Mmm that's weird.. bc i have the standart installation, there is any place where i can see the logs for this and debug a little bit more ?
You can try using debug mode. https://www.faqforge.com/linux/debugging-ispconfig-3-server-actions-in-case-of-a-failure/ It will likely not show much about merging the nginx directive, but maybe it shows some errors or says it can't write or update the config, or shows that it is not updating the config at all. So its wort a try doing it and posting the result here that you get in debug mode while applying the config. And just to be sure, double-check that you have not accidentally entered the snippet into the custom php.ini field on options tab instead of the nginx directives field.
I'm encountering a similar issue where changes to the ISPConfig website settings don't seem to update the vhost for the website. To better understand the problem, I enabled debug mode and captured the output: Interestingly, even when I introduce an error intentionally, there are no updates or changes reflected. However, the Proxy Directives appear to function as expected.
Please post the debug log output you get when running server.sh after changing something in the website. Copy/paste the text from your terminal instead of making a screenshot.
Code: root@tesseract:~# /usr/local/ispconfig/server/server.sh 29.01.2024-18:46 - DEBUG [plugins.inc:155] - Calling function 'check_phpini_changes' from plugin 'webserver_plugin' raised by action 'server_plugins_loaded'. 29.01.2024-18:46 - DEBUG [server:177] - Found 1 changes, starting update process. 29.01.2024-18:46 - DEBUG [plugins.inc:118] - Calling function 'ssl' from plugin 'nginx_plugin' raised by event 'web_domain_update'. 29.01.2024-18:46 - DEBUG [plugins.inc:118] - Calling function 'update' from plugin 'nginx_plugin' raised by event 'web_domain_update'. 29.01.2024-18:46 - DEBUG [system.inc:2430] - safe_exec cmd: chattr -i '/var/www/clients/client1/web53' - return code: 0 29.01.2024-18:46 - DEBUG [system.inc:2430] - safe_exec cmd: chattr +i '/var/www/clients/client1/web53' - return code: 0 29.01.2024-18:46 - DEBUG [system.inc:2430] - safe_exec cmd: df -T '/var/www/clients/client1/web53'|awk 'END{print $2,$NF}' - return code: 0 29.01.2024-18:46 - DEBUG [system.inc:2430] - safe_exec cmd: which 'setquota' 2> /dev/null - return code: 0 29.01.2024-18:46 - DEBUG [system.inc:2430] - safe_exec cmd: setquota -u 'web53' '0' '0' 0 0 -a &> /dev/null - return code: 1 29.01.2024-18:46 - DEBUG [system.inc:2430] - safe_exec cmd: setquota -T -u 'web53' 604800 604800 -a &> /dev/null - return code: 1 29.01.2024-18:46 - DEBUG [system.inc:2430] - safe_exec cmd: chattr +i '/var/www/clients/client1/web53' - return code: 0 29.01.2024-18:46 - DEBUG [nginx plugin.inc:1397] - SSL Disabled. id.fmi-plovdiv.org 29.01.2024-18:46 - DEBUG [system.inc:2430] - safe_exec cmd: nginx -V 2>&1 | grep 'built with OpenSSL' | sed 's/.*built\([a-zA-Z ]*\)OpenSSL \([0-9.]*\).*/\2/' - return code: 0 29.01.2024-18:46 - DEBUG [system.inc:2430] - safe_exec cmd: nginx -V 2>&1 | grep 'running with OpenSSL' | sed 's/.*running\([a-zA-Z ]*\)OpenSSL \([0-9.]*\).*/\2/' - return code: 0 29.01.2024-18:46 - DEBUG [system.inc:2430] - safe_exec cmd: which 'nginx' 2> /dev/null - return code: 0 29.01.2024-18:46 - DEBUG [nginx plugin.inc:1621] - Enable TLS 1.3 for: id.fmi-plovdiv.org 29.01.2024-18:46 - DEBUG [nginx plugin.inc:1914] - Writing the vhost file: /etc/nginx/sites-available/id.fmi-plovdiv.org.vhost 29.01.2024-18:46 - DEBUG [nginx plugin.inc:2015] - nginx status is: running 29.01.2024-18:46 - DEBUG [services.inc:56] - Calling function 'restartHttpd' from module 'web_module'. 29.01.2024-18:46 - DEBUG [system.inc:2083] - Trying to use Systemd to restart service 29.01.2024-18:46 - DEBUG [system.inc:2430] - safe_exec cmd: systemctl is-enabled 'nginx' 2>&1 - return code: 0 29.01.2024-18:46 - DEBUG [web module.inc:236] - Checking nginx configuration... 29.01.2024-18:46 - DEBUG [web module.inc:239] - nginx configuration ok! 29.01.2024-18:46 - DEBUG [web module.inc:246] - Restarting httpd: systemctl restart nginx.service 29.01.2024-18:47 - DEBUG [nginx plugin.inc:2018] - nginx restart return value is: 0 29.01.2024-18:47 - DEBUG [nginx plugin.inc:2025] - nginx online status after restart is: running 29.01.2024-18:47 - DEBUG [modules.inc:240] - Processed datalog_id 695 29.01.2024-18:47 - DEBUG [server:217] - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock finished server.php. root@tesseract:~# Debian GNU/Linux 11 (bullseye) ISPConfig Version: 3.2.11p1
I've noticed another specific issue: when the redirect option is set to 'Proxy' in the Redirect settings, the Nginx Directives seem to have no effect and do not influence the vhost file at all. It's as if enabling this type of redirect causes the Nginx configurations to be completely bypassed or ignored.
According to debug log, the config has been written correctly. Yes, that's possible as the traffic gets proxied in this case and is not being processed any further locally, so directives do not get applied then. If you need some kind of special proxy config, then define it as a directive snippet and use that instead of using the proxy redirect. And you must be aware that you can not use directive snippets and custom directives together, so when you created a directive snippet and assigned dit by selecting it on the first tab of the site, then any nginx directives on options tab will be ignored.
Certainly, it would be helpful if this limitation were mentioned somewhere, or if the Nginx Directive section became unavailable (grayed out) when a directive snippet is in use, to avoid confusion.
