What is the best practise to allow individual developers to work on sites on a BOA.

Make sure to read:

- http://omega8.cc/shell-and-ftps-extra-accounts-per-aegir-client-226

The ssh/ftps users are created automatically when creating a user in Aegir. However, the users will not be notified about their server accounts. You need to to that manually.

The main account for an Octopus instance, it seems is /home/ox.ftp where x is the instance number. And it is in /home/ox.ftp/usesr you will find the files with the users passwords, if you want to grant the users access to their own sites.

Also, it is good to know, that the users are not granted platform wide permissions. They are restricted to their own sites-directories. And in the site specific modules and themes diretories only custom modules should reside. Read http://omega8.cc/managing-your-code-in-the-aegir-style-110 and http://cms.about.com/od/drupal-multisite/a/How-To-Organize-Your-Modules-.... If the developer needs to add changes to the core of a platform, a new platform should be added (or a new octopus instance could be created, so the developer has more permissions over the platforms).

Original issue post:

I spoke with Grace about this and some suggestions were very interesting but I never enventuated to setting anything up to make this manageable.

I have constantly battled with the problem of using an account other than 'aegir' to modify theme files, in particular so other devs can update files without using the main 'aegir' user account so we can not only track their changes by the account provided but we can also lock them down to only the sites we want them to work on and not waltz into other platforms or sites.

Please could you point me in the direction of your best practice for configuring this easily?
Hope I didn't miss this somewhere in the documentation.

Thanks in advance.

Comments

omega8cc’s picture

There are bundled scripts to create FTP or shell accounts with access per site or per platform:

http://drupalcode.org/project/barracuda.git/tree/HEAD:/aegir/tools/user

Note that shell user will be able to access also other sites on the same Aegir instance, because SFTP (FTP over SSH) doesn't respect limited shell settings (they work only on command line), so if you prefer true "per site" access, you should add only FTP accounts.

snlnz’s picture

Thanks for your reply and reference to the scripts. Could you perhaps explain each script a little, I'm sure others will be interested to know this also. Are there specifics for Octopus and Barracuda instances here? Why would you use each script in various scenarios?

I would presume on barracuda standalone instances that add_ftp_user_standard.sh.txt would apply?

snlnz’s picture

Status: Active » Closed (fixed)
HyperGlide’s picture

Status: Closed (fixed) » Active

Waned to answer @snlnz request for mor help on the scripts for future users.

  1. You need to copy each script to your server.
  2. $nano ''what_you_want_to_name_the_script.sh"
  3. copy and paste the script from the 'raw' display on git.
  4. edit each variable as noted below based on your needs.
  5. Only need to edit items under ### Config
  6. _ADMIN=admin The administrator account. -- I did not make any changes to this value
  7. _USER=user The name of the user you want to create. (i.e. joe)
  8. _SITE=domain The name of the domain. It must match the BOA domain name for the site.
  9. _SITE_DIR="/path/to/platform/sites/$_SITE" The full path to the platform where the site is hosted. You should leave the $_SITE at the end. The script will updated based on what site you have listed in the previous step.
  10. Now need to run the scripts
  11. $bash what_you_want_to_name_the_script.sh
  12. Look at the auto generated password.
  13. $cd /home/admin/$_Site
  14. $cat sitename
  15. done.

Try to connect with your favorite FTP Client -- Know that the user name is "user.ftp" or in the example "joe.ftp"

Also - Perhaps off topic but - When a new user is added do not receive email reports for successful login as do for root account.

omega8cc’s picture

Status: Active » Fixed
snlnz’s picture

Status: Fixed » Active

So these scripts create the user account all fine and you can restrict the user to just the site which is excellent. But when logged, I am unable to browse folders further up the tree such as sites/all or /profiles for some customizations.
I just get warnings of a forbidden path, plus indication that another two warnings will log me out.

How do I go about assigning the appropriate permissions for access to an entire platform rather than just a site?

thanks in advance.

omega8cc’s picture

This is by design. Just specify a path you wish to open for user as an entry level in the structure. The _SITE_DIR can be any directory level.

snlnz’s picture

Admittedly I did try this by specifying the full platform path for example:
_SITE_DIR="/data/disk/oct/distro/001/uberdrupal-6.22"

However, when login with the newly create user, I try to cd to the symlink created by the script ($_SITE) and get the same error forbidden path message.

Is there a specific syntax in the script that I might be missing? Specifically _SITE_DIR directive?

omega8cc’s picture

Status: Active » Closed (works as designed)

The path _SITE_DIR="/data/disk/oct/distro/001/uberdrupal-6.22" looks fine and the extra user should have an access to entire /data/disk/oct/distro/001/uberdrupal-6.22/sites/* space. Note however that it will not allow the access to other platform level directories because they are symlinked and their real paths are in the different, shared tree. This means that it will give the user access to the entire platform tree only for custom platform, not to those installed by Octopus, unless you will add the symlinked tree also for this user in the /etc/lshell.conf config file.

omega8cc’s picture

@HyperGlide - lfd sends login alerts for SSH logins only. You may want to check your spam folder as they may be filtered by your e-mail server or client.

HyperGlide’s picture

@omega8cc -- yes I know this. There is no problem. This is more a feature request for consideration.

snlnz’s picture

Server is Xen fresh BOA install Debian Squueze Percona

A few related problems I am experiencing are:
I've tried all of the following scripts:

add_ftp_user_standard.sh.txt
add_lshell_user_master.sh.txt
add_lshell_user_standard.sh.txt

in an attempt to setup an account that has the ability to
ssh in - this works ok and I can see the symlink to the site dir
cd to the site dir which is identical to what is set in $_SITE directive in the script - this fails with the below error:

user.ftp:~$ cd sitename.com
*** forbidden path -> "/data/disk/oct/distro/001/ubercart-6.x-2.7-6.22/sites/sitename.com"
*** You have 2 warning(s) left, before getting logged out.
This incident has been reported.
user.ftp:~$ 

I've tried quite a few combinations of this now but none seem to allow me to get access to the site that had been setup in the Script config section:

### Config
_ADMIN=admin
_USER=user
_SITE=sitename.com
_SITE_DIR="/data/disk/oct/distro/001/ubercart-6.x-2.7-6.22/sites/$_SITE"

Would be great to know what is happening here.

A problem I came across along the way, is removing the account cleanly and setting up a new one.
Are there any scripts that reverse the process and remove the accounts cleanly ie, pull the added info from /etc/lshell.conf, remove the /home/admin/domain.com entry and delete the home dir for the created user?

Then I figured, hell I'll just drop a pubkey file in the oct.ftp user account as all the developers I work with are trusted enough to login to any site and make changes and if we cease projects I can always revoke the pubkey. However I'm not sure where the default *.ftp user account password is stored after a clean octopus install? I found the default octopus user but not the secondary *.ftp account pass.

Your help here would be greatly appreciated. I have so just setup a new account added the user to the users group and granted ssh/pubkey access that way but would be nice if the best practise method worked for us!

Thanks!

omega8cc’s picture

All three scripts filenames are pretty self-explanatory, so you should have no problem with understanding which one can be used for basic shell+ftp, o1.ftp-like shell+ftp or ftp-only account.

There is no "clean" script. It is expected that you know how to manage users on the system and you know about commands like deluser.

Properly used will never display forbidden alarm for allowed path to the site. We use them a lot and it just works.

The default USER.ftp user password is stored in the /data/disk/USER/log/pass.txt file.

snlnz’s picture

I thought so too. Funny I still get the issue of forbidden path no matter where I point the _SITE_DIR directive.

I certainly understand the account process well and I thought if you had a script that created the accounts it would make as much sense to have a reverse script. I ended up putting something together to do this after all the testing of creating and deleting accounts to see what the heck was going wrong! Even the file permissions are all ok on the symlinks in the ftp users home dir so I'm lost as to what the problem is. I'm assuming it's something to do with lshell but have not used it enough to know this for sure.

I'd prefer the "by design" method to work as it is obviously best practise and I like the idea of jailing them to specific sites but don't want to break the server trying!

Thanks anyway.

HyperGlide’s picture

Reopening this issue as related to the same issue "best practice for allowing other developers to work on sites in aegir" but now on BOA 2.0.3

Using the information within the FAQ: http://groups.drupal.org/node/163784

Create limited shell and FTPS access for developers

You can easily grant limited shell and FTPS access for developers, simply by creating "Clients" in the Aegir control panel and define them as 'owners' of one or more sites. Their access will be limited to only sites they can manage, but only if you will send them their access credentials, which are independent of their Aegir control panel credentials and stored in the ~/users/ directory in your main account. You will find there files with passwords for every "Client" with at least one site attached. For example ~/users/o1.username file means that this Client's username for SSH and FTPS access is 'o1.username' while his password is stored in this file. This means that SSH/FTPS access is not granted automatically, but you can decide who should receive it. How to change any extra user's password? Simply delete his ~/users/o1.username file and wait up to 5 minutes - the system will re-create his account with new password. And how to delete the user completely? Simply delete this user "Client" account in the Aegir control panel and allow the system to delete also his SSH/FTPS access in the next 5 minutes.

-- --

However we are looking to:

  1. Allow the developer to have access to the sites/all/* folders so their work can impact all sites on that platform.
  2. Be able to git commit, git push, git pull, etc.

Additionally if the user is 'o1.username' any files they create will not be owned by the default account 'o1' as we understand is an important piece for BOA to function properly.

Thank you in advance for help and advice.

HyperGlide’s picture

Status: Closed (works as designed) » Active

Forgot to change the status to "active".

omega8cc’s picture

Project: Barracuda » Octopus

Files tend to be owned by the owner, that is how Unix works. Extra users should follow the same best practices, or there will be files you can't edit until BOA will fix them next morning.

Extra users are NOT intended to manage the code on the platform level, only on the site level. See also #1663512: confusing doc on sites/sitename/modules

It is against the logic to open access to platform level code when the access is created/managed *per site*, as you can't make a client an owner of the platform, only owner of the site.

Maybe we should document even obvious things better.

If you really want to open platform level access, you should simply create separate Octopus instance. That is what Octopus is for.

omega8cc’s picture

I agree that it could be nice to add platform level access, but there is nothing in Aegir which could sync with this level of privileges separation, so you need to use either extra users created automatically, or use (wisely) scripts to add them manually: http://drupalcode.org/project/barracuda.git/tree/HEAD:/aegir/tools/usr

And yes, those scripts allow you to define any path as allowed, so you can also create users with access limited to one or more platforms (not just sites), if you wish.

HyperGlide’s picture

Status: Active » Closed (works as designed)

Appreciate the reply and guidance.

I aslo feel -- Managing your code in the Aegir Style is an important read for a new developer.

In our use case we are a single company that uses BOA to help with code management and testing of upgrades (new platforms) so a separate octopus instance may not be the best thing for us.

Knowing we are using this out of the box we wil continue to use the scripts. I had thought they were removed as part of the 2.0.3 big upgrade from my read of the release notes. Thanks for the link again.

Thanks,
Hg

Closing issue again.

lsolesen’s picture

Issue summary: View changes

Added info to make it easier to quickly get an answer.

lsolesen’s picture

Issue summary: View changes

Improved.

that0n3guy’s picture

Version: » 6.x-2.x-dev

I know this is an old and closed thread, but stuff has changed a lot since the above posts and the scripts are no longer in the repo.

How are platform only access users created now?

that0n3guy’s picture

Issue summary: View changes

Improved