this string breaks Laravel sites
/usr/local/hestia/data/templates/web/apache2/default.tpl: php_admin_value open_basedir %docroot%:%home%/%user%/tmp
why use %docroot% as open_basedir value? why not the …/public_html dir?
we have got sudden site failure recently - somehow hestia apllied the template open_basedir parameter and break our laravel site, which worked good for years
We replace it to:
/home/xx/web/xxxxxx/public_html:/home/xxxx/web/xxxx/private:/home/xxx/web/xxxx/public_shtml:/home/xxxx/tmp:/tmp:/var/www/html:/bin:/usr/bin:/usr/local/bin:/usr/share:/opt
Please tell me the difference between
…/public_html
and
/home/xx/web/xxxxxx/public_html
Also I use multiple Laravel sites with out any issues
I know some scripts including opencart have some times issues with there template system where they also check / first
yes, I mean /home/xx/web/xxxxxx/public_html
What is then the issue it should work fine with set up and I am sure we can’t use relative paths…
I mean the default template would break any Laravel site
I am using the default template with Laravel without any issues…
what is the open_basedir value in the default template on your server?
I use the default hestia config …
/home/xx/web/xxxxxx/public_html:/home/xxxx/web/xxxx/private:/home/xxx/web/xxxx/public_shtml:/home/xxxx/tmp:/tmp:/var/www/html:/bin:/usr/bin:/usr/local/bin:/usr/share:/opt
OK
but we have got Laravel site failure with open_basedir profibit public_html out of a sudden, why? today it happened again, one month after previous time, and I finally found it is Hestia problem
I guess if HestiaCP itself breaks our working site - it is a problem with Hestia default behaviour, or what?
If you site doesn’t work with the default template
You can create a template that suits your needs:
For example:
But it offers a way to relax open base dir policy…
As told I have seen alot sites that hand templates and cacheing wrong and the default folder they check is always /. Why I don’t know …
OK, thanks
I’ll check this but still I see the problem with HestiaCP if we had long working site which suddenly broken by HestiaCP itself - do you agree?
I’m not sure if it was any HestiaCP update, I’m not familiar with Hestia
please, don’t get me wrong, I am grateful to Hestia community and I want to find why this happened and eliminate the problem in the Hestia upstream
We haven’t changed any thing we only released new version and we usually restart the services and in rare cases we rebuilld the config files…
OK, could you please hint how to find then origin of the problem? any logs I should check?
btw, the config file had modify timestamp 07:13 both time site was broken
/home/user/conf/web/xxxx/apache2.conf
I doubt it was human modified manually at the same clock time
btw, I’ve found the origin of apache2.conf change open_basedir value - it is in admin’s cron
13 7 * * * sudo /usr/local/hestia/bin/v-update-sys-hestia-all
That is the update function in hestia…
So probally you did make manually config changes and then got over written…
; origin-src: deb/templates/web/php-fpm/default.tpl
;#=========================================================================#
;# Default Web Domain Template #
;# DO NOT MODIFY THIS FILE! CHANGES WILL BE LOST WHEN REBUILDING DOMAINS #
;# Web Templates and FastCGI/Proxy Cache | Hestia Control Panel #
;#=========================================================================#
so after this manual config change the template was overwritten with an update of default.tpl file,
but the updates are not regular, but from time to time?
@Vasya
You should turn the update function off on production site to avoid self-created surprises and problems. The execute this update function first on testing server. If everything goes well, repeat it on the production server.
Regardless of this, you need to create a new template for that specific account in which you want custon configuration. Then, rebuild the domains and have the new template active.
During the updating, your custom template will remain activated even if the default configuration is overwritten.
Based on above, you are then no longer dependend on changes in the dafult templates and not even updates.
interesting, thanks