$DEPLOYER and $DEPLOY_USER_NAME confusingly similair

[MarkBennett]

$DEPLOYER is used by Plow when provisioning sentinel. $DEPLOY_USER_NAME is used by Capistrano and when running the app on the server.

A better might be something like $PLOW_USER?

[mm53bar]

I wouldn't want to inject the "plow" name into a user's .env file. It makes plow feel like a dependency and not a tool.

Is Capistrano standardized on $DEPLOY_USER_NAME? Or is it just the cap that's in the sentinel project? If $DEPLOY_USER_NAME is a general standard then I would definitely use that.

[MarkBennett]

I really see these as two different users. One which provisions the box and the other which is used to deploy and run the app.

For example in the case of sentinel, the provisioned box has an "ubuntu" user with sudo access which is used when running plow. The actual app uses a different user called "deploy" with locked down permissions. It can only be used to deploy the app and run unicorn or other worker processes. Merging these into a user that runs the app with sudo priveleges seems like asking for trouble.

With sentinel right now, here's the relevant lines from our .env.staging:

DEPLOYER=ubuntu
DEPLOY_USER_NAME=deploy

I wouldn't want to combine these into a single user, but would be open to suggestions for how to make the names clearer.

Another option would be to have a hierarchy of names that plow looks for. So it would look for $PLOW_USER if it's defined and if not it would fall back to $DEPLOYER. This would let you use one user for both, while not requiring them to be the same if you don't want the user that runs your app also able to access sudo.

[MarkBennett]

Just to follow up on that last comment. An ideal config for me would look like this in our .env:

PLOW_USER(or alternative)=ubuntu
DEPLOYER=deploy

[mm53bar]

Gotcha - that's a disconnect between how I use plow and how you guys are using plow. My $DEPLOYER is set to the user that deploys my app, not the user that provisions the app. For me, deployment is the common use case so I set that user in my .env.production file.

The uncommon use case is provisioning. That's where I use the USER argument in plow. So, when I'm provisioning, I run plow like this:

bin/plow production --user ubuntu --sudo build_essential nginx

Specifying the user as a command-line argument overrides the $DEPLOYER that is set in the .env.production file.

[MarkBennett]

Interesting. Alright, I'll try updating the recipes to run with USER set to the provisioning user and with DEPLOYER set to deploy.

Off-hand do you know if the recipes can access the $USER variable? We're adding to the provisioners authorized_keys so that we can maintain a set of identities able to provision and admin the box, rather than just the one key we can set with Amazon when the instance spins up.

[mm53bar]

That's going to be problematic. You're probably provisioning as root rather than ubuntu. So $USER will be root. Unfortunately, root doesn't have ssh access - ubuntu does. I would probably add PROVISIONER=ubuntu variable to the .env.production file so that the recipe uses the proper authorized_keys.