Hestia 1.2. Homedir perms, and php_value

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.

  1. 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.
    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.

  2. 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.

I am on mobile atm so to be short

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

  1. 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

1 Like

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.

For one we maybe could consider a switch in Hestia.conf that we disable the sftp jail on demand

One final point, I think you need to add this to the default nginx configs to block direct access
location ~ /.us {return 404;}