I am experimenting with replacing an existing LAMP stack with LEMP, and boa seemed like a good way to get started.
I have two questions that I can't grok even after reading through all the scripts and trying it out on a test instance.
1) What is the intended usage of Master and Satellite instances of Aegir?
In my past experience I've set up a single Aegir instance for a single server, and put all platforms in there. I'm not sure from the documentation what the use case for the Satellite ("octopus") instances is supposed to be. Is this a level of access control? Would you make a satellite for each client, or would you group them together somehow? (By what criteria?)
2) You must be logged in as root. Or sudo -i first.
Why is this the case? IMO, the only acceptable commands to run as root are 'useradd', 'vigr' and 'visudo'. Everything else is what sudo is for. Yea, this is a totally pedantic complaint.
Comments
Re: 1 I still plan to publish
Re: 1
I still plan to publish some article on the subject, but in the meantime you could read all comments here: http://groups.drupal.org/node/200783
Re: 2
To make things simple from the UX point of view, BOA is a set of scripts running in the non-interactive mode behind the scene, unless user input is explicitly required, and it operates on the true root level, so running it via sudo is both not supported and doesn't really make any sense.
but we recommend to use
Ah, but that is the exact opposite of what I want to do. I want learn how to use BOA and Aegir properly, so that I can apply them in my own environment.
Welcome to the club, we've got jackets
I feel you on exactly what your saying here. I run a small cloud application hosting company where we take every kind of voice and interactive collaboration (CMS stuff) Drupal like project and build it mostly on open source stuff. Getting BOA up and running in the environment gave us a huge step forward in the since of providing traditional infrastructure components, that are infinitely configurable in nature across multiple platforms, and made them available under a single Linux VM instance. The trade off/learning curve for us, was to dive in hard and learn a bunch of something about proper Linux admin and some shell scripting to automate it. BOA is really that thing we always wanted in a highly automated, consolidated, and managed web service platform. By deciding on being self sufficient with it, like you are stating here, it pushed us in the direction of being very responsible administrator to a multi-tenant Drupal platform.
Peace,
Michael Clendening
Both POVs work for me
I share both approaches to the use cases/advantages of BOA .. Like Michael, it represents a drop-in for a hosting solution (it even offers to install webmin for you!!!) .. and like Brian, I really would want a system that I understood the internal architecture very well, so I can mould it the way I want, and I am also able to easily troubleshoot failures or issues.
The thinking behind Aergis, Barracuda, Octopus, BOA is very very sound and very much appreciated.
Now, how can more of us contribute to the effort, even towards improved architectural documentation? omega8cc, any suggestions on thge most effective ways we can all individually contribute towards continuing improvement of the platforms?
For features
For features requests/discusion we have issue queues, both for Barracuda and Octopus. For documentation and free discussion we have this group. There are already a few docs pages written in this group, and if there will be more of them, we will link them at the top of the group homepage. It is a wiki so it is easy to contribute docs, fork us on github or here on d.o and make a pull requests to improve the code etc. Any help and patches are more than welcome.