Re: bindfs for web docroot - is this sane?

[Dan Ritter <dsr@randomstring.org>]

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-