Hi,
I’ve been playing with a new install of Hestia 1.2 on a Digital Ocean Ubuntu 20.04 droplet. All seems to be OK, however I’ve noticed a couple of things are different.
User home directories are not writable. Well they are and they arent. Existing files can be edited. But new files and directories can’t be created. I’ve found a github Issue about it. https://github.com/hestiacp/hestiacp/issues/580
I can’t quite work with it myself, as I make a lot of files on the server. Notes to myself and other devs, scripts, db dumps and backups, so what I did was change the directory owner from root. eg
chown admin:admin /home/admin/
I’m still processing this one, but it seems a strange decision. For the record I didn’t install the FTP server.
A couple of sites I transferred over had php_value directives in their .htaccess files. These now break the site dramatically (Error 500), and must be removed. I guess this is part of the Apache re-jig I’ve been hearing about.
What is the recommended solution for setting these php_values on a site-by-site basis? I tried setting a .user.ini file, but that wasn’t read. I guess I could try writing a template with the directives but that seems a bit clumsy, and I’d like devs to be able to handle their own sites, in the same way as editing .htaccess. Not all sites will need max_upload_size set to 128Mb for eg.
As stated in #580 issue from Github. The root:root user permission is required by th e sftp jail to prevent users accessing w up directories as explained.
There is currently there is no easy solution for it. You could create the required file as root and chown to the user show he can modified it. How ever a easy fix when there are multiple users
What setup are you using? Nginx only?
Nginx + Apache combo or Apache single it should work
Others wise you could try for every domain a siddert php template see /usr/local/Hestia/templates/web/php-dom
OK, I found time to look into this. As for point 1, I understand why you changed things. Personally I can’t work with it, and everyone accessing the server is trusted, so my solution was to chown the home directories back. I was just reporting what worked for me.
Point 2, is a little sneakier. So to answer your question, yes, I was running Nginx+apache mode, and it was fairly obvious, as every time I added a php_value to .htaccess the website went down! Commenting it out, and the website ran again.
Now, it seems that the reason this is happening is because you’ve moved from mpm_worker to mpm_event. Now the libapache-mod-phpx.x module isn’t being loaded and isn’t even installed. If you DO install it, that instantly triggers a switch from mpm_event back to mpm_worker.
The solution, it turns out, is to use the .user.ini file to load the directives. I had tried this in my previous testing, but it didn’t seem to pick up the file, so I thought I it must not be in use. However, it turns out that you have to add the directives to .user.ini, and ALSO realise they’re in a different format!
So “php_value upload_max_filesize 128M” in .htaccess should be entered as “upload_max_filesize = 128M”. Note the = sign. That’s why my previous investigation failed!
So case closed on this one. For mpm_event, use a .user.ini file. Either comment out the values in .htaccess or surround them with an IfModule mod_php7.c statement.