Re: bindfs for web docroot - is this sane?
On 12/10/22 00:26, Dan Ritter wrote:
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.
I agree that a git-based deployment scheme would be good. However, I
understand that it's considered bad practice for the docroot to itself
be a git repo, which means writing scripts to check out the right
version and then deploy it (which might also help with setting the right
permissions).
I'm also not entirely comfortable with either a cron or ticket-based
trigger - I'd want to look into either git hooks (but that's on the
wrong machine), or maybe a webapp with a deploy button.
And then there's the issue of what is in git and what isn't, and how to
customise the installation after checkout - eg setting the site name/url
to distinguish it from the dev/staging site or whatever, setting db
passwords etc. More stuff for the deployment script to do, I guess.
So I like this idea, but it's a lot more work. And I have to convince my
clients and/or their devs to use it, which might require learning git.
And I'm not necessarily good enough at git myself to do that teaching well.
- devs don't get accounts on the web host at all
They might need it anyway, for running wp cli commands etc (especially
given the privilege separation which means that installing plugins via
the WP admin pages won't work - or would you include the plugins in the
git repo?)
- you can resolve the conflicts of two people working on the
same site
True.
- automatic backups, assuming you have a repo not on this server
I have backups of the web server; backups of the repo as well would be good.
- easy revert to a previous version
True.
- easy deployment to multiple servers for load balancing
True, though I'm not at that level at this point.
Drawbacks:
- devs have to have a local webserver to test their changes
Yes, or a dev server/site provided by me
- devs have to follow the process
And have to know how, yes
- someone has to resolve conflicts or decide what the deployed
version is
True anyway
Note that this method doesn't stop the dev(s) using git anyway.
In summary, I think I want to offer a git-based method, but I think it
would work ok in combination with this, which is initially simpler.
It sounds like there's nothing fundamentally broken about it, at least :-)
Cheers,
Richard
Reply to: