What I like most is who decides, and how little there is to decide. Your host puts the Client’s name on one line in a file only root can write; no button in the panel and no file of a tenant’s has a say in it, and every three minutes the worker which looks after all the limited shells on the box walks the Client’s sites, finds the platforms they sit on, and then reads each platform itself: every site directory on it must resolve into that Client’s own farm of links, and a site which appears in no Client’s farm at all, the host’s own site say, counts as somebody else’s, never as “not there”. So the test fails closed; a platform with one foreign site on it is simply left out, the log says which site kept it out, and when that site moves elsewhere the platform comes back on the next pass with nobody touching anything. The grant is re-derived every pass, which is the part the “add a collaborator” button never tells you, and it means that on a BOA server you can read the whole of a developer’s access in one file and one log, and so can we when you ask.
I keep coming back to cars in these posts, so here is the picture. The ordinary extra login is the key to the boot (the boot where, as an earlier post had it, the uploads ride): the developer can load and unload what is in there, the uploads, the theme, a small custom module of their own, and that is genuinely all a lot of jobs need, which is why it has been the default for years and stays so. The new login is the key to the engine bay of one car, yours, and only while nobody else’s luggage is in that car; the mechanic gets the bay, not the garage, and certainly not the keys of the other cars parked in it.
Back to the blog »
The developer lands in the same fenced shell every tenant here gets, with the same file tools and Git, plus Composer, plus drush8 where the platform is Drupal 7 or Backdrop, plus the Drush which ships inside each platform they were granted, and a platforms folder in their home with one link per codebase, which SFTP sees too. Their writing rights are yours, no more and no less: inside a site the places you can write yourself, the uploads folder and the private one, the site’s own modules and its themes, and the codebases you put on the server with your own hands, top to bottom; a codebase the control panel installed is nobody’s to write, you included, and neither is a site’s settings file, which is not a limit we added for them but the rule the whole box lives by, so there the developer reads, asks Composer questions, and drives Drush, and on your own codebases they run their composer update like on their laptop, only on the server which serves the site.
The leaving is as quick as the arrival was: your host takes the name off the line, or you delete the Client, or move its sites elsewhere, and within three minutes the login is gone, its home archived rather than deleted, and not one byte of yours touched, because the code they wrote sits in your account and the login only ever reached it. Deleting the password file in your users folder forces a fresh password on the spot, exactly as with the ordinary login; there is nothing of yours to clean up, and no password of yours was ever shared; the one loose end is the line itself, because a name left on it for a Client which is gone goes on reporting itself to your host, once a day, until somebody takes it off, so if you ended it by deleting the Client or by moving its sites away, say so to your host as well.
Have you ever handed a freelancer your one and only SSH login, the one which reaches every site you host, because the job was “just the theme, on that one site”, and then spent the evening after the invoice changing that password everywhere and wondering, a little, what else they had a look at while they were in? Or, if you live on a platform of the button-and-seat kind, added a collaborator to a project with one click and never quite found out what the seat they got can actually do, whether they can run Composer on the codebase or only poke at files through a web console somebody else designed for them?
The question which comes up first is of course the obvious one: what about the platform which carries three of my sites, and the developer needs all three? Give the Client all three sites and the next pass grants the platform, or split them off onto a platform of their own; but what happens to that grant on the day one of the three sites is handed to a Client of its own, how quickly, and who gets told, is exactly the kind of thing the operator page keeps a table for, the symptom on one side and the remedy on the other, in the manner of the service manual nobody opens until the light on the dashboard comes on, which is the hour it was written for anyway.
If you run the box yourself, this is the evening you stop having: the second login you made for a contractor with a sudo rule you meant to take out afterwards, the password you changed when they left, the ownership you fixed at midnight because their composer run left half of the files as the wrong user. If you live on a platform it is the collaborator seat you know, with two differences, that the seat is a plain Unix account whose grant you can read in one file and whose every window is one line in a log, and that the grant lives on your own box, in one line you can have read back to you, or taken off on your word, and not in a roles matrix you never saw and cannot change.
So how do you give an outside developer exactly the door they need and not one priviledge more? On a BOA server a Client, which is the control panel’s word for “these sites belong to this person”, gets its own limited login built for it automatically, a login which sees only that Client’s sites and their files, with no Drush, no Composer and no database client, because files and themes is what such a login is for; and now your host can turn on another login for that same Client, a platform-level one, which reaches the whole codebase of every platform whose sites are all that Client’s, with Composer and the Drush which ships inside the platform, and which refuses any platform where somebody else’s site is parked as well. The gentle version, for the account owner and for the developer, is on the extra accounts page, and the operator’s step by step is on the platform developer account page; what follows here is the why, and the edges.
Now the edge, and it is an edge worth knowing about before you tell anybody. A platform of Drupal 8 or later on an Ægir server is kept locked between uses for Ægir’s own Drush 8, the one which drives every task in the panel, and it turns out that a modern Drush and that lock cannot live in the same codebase at all once PHP 8 is in the picture, so vdrush is dead for the developer on a locked platform whatever you do to the file modes; we tried the cheap way first, flipping the execute bits the way the panel’s own cache rebuild does it, and measured on a test box that it opens precisely nothing on a Drupal 10 platform. So the window is a real unlock: the developer touches one file in their home, within three minutes every platform they were granted is unlocked for an hour, touching it again buys another hour, and at expiry the worker locks back exactly those platforms it had found locked, with the whole thing written in the log. The price is honest too: while the hour runs, a task you start from the panel on a site of those platforms may fail, and a Verify on any of them puts the lock back (the next pass takes it off again while the hour lasts), so the two of you agree on a time, the way you would with a mechanic who needs the car on the lift.
