Richard Hector wrote: > Hi all, > > I host a few websites, mostly Wordpress. > > I prefer to have the site files (mostly) owned by an owner user, and php-fpm > runs as a different user, so that it can't write its own code. For uploads, > those directories are group-writeable. > > Then for site developers (who might be contractors to my client) to be able > to update teh site, they need read/write access to the docroot, but I don't > want them all logging in using the same account/credentials. > > So I've set up bindfs ( https://bindfs.org/ ) with the following fstab line > (example at this stage): > > /srv/wptest-home/doc_root /home/richard/wptest-home/doc_root fuse.bindfs > --force-user=richard,--force-group=richard,--create-for-user=wptest-home,--create-for-group=wptest-home > 0 0 > > That means they can see their own 'view' of the docroot under their own home > directory, and they can create files as needed, which will have the correct > owner under /srv. I haven't yet looked at what happens with the uploaded and > cached files which are owned by the php user; hopefully that works ok. > > This means I don't need to worry about sudo and similar things, or > chown/chgrp - which in turn means I should be able to offer sftp as an > alternative to full ssh logins. It can probably even be chrooted. > > Does that sound like a sane plan? Are there gotchas I haven't spotted?
That's a solution which has worked in similar situations in the past, but it runs into problems with accountability and debugging. The better solution is to use a versioning system -- git is the default these days, subversion will certainly work -- and require your site developers to make their changes to the version controlled repository. The repo is either automatically (cron, usually) or manually (dev sends an email or a ticket) updated on the web host. Benefits: - devs don't get accounts on the web host at all - you can resolve the conflicts of two people working on the same site - automatic backups, assuming you have a repo not on this server - easy revert to a previous version - easy deployment to multiple servers for load balancing Drawbacks: - devs have to have a local webserver to test their changes - devs have to follow the process - someone has to resolve conflicts or decide what the deployed version is -dsr-
