Reloading shell environment


#1

Hi,

I have a chef wrapper cookbook & recipe setup that’s provisioning our whole
development environment.

What I want to do though is also include the currently manual steps of
setting up the application at the end:

  • Clone from private Github repo
  • Drop in database.yml
  • gem update --system
  • gem install bundler
  • bundle install

What I need to do though is:

a) Get access to the private github repo

b) Execute as the correct user, as on vagrant it will be vagrant and on
normal installs it might be something else - and if chef is invoked
manually it will be running from the user with sudo or if it’s invoked by
vagrant, it’s run as root.

c) Load chruby into the environment so all the gem stuff is done under the
correct Ruby.

How do others handle these issues?

I’m thinking that getting access to the private repo could be done using
deploy keys included with the chef repo which gives read only access to
that single repo.

I’m thinking the target user could be by way of a node attribute (and could
check for the presence of a vagrant user to set the default).

The environment thing I guess I could go through the chruby script and see
what environment variables it sets and set ENV[‘PATH’], ENV[‘GEM_HOME’] etc
etc, but that’s ugly and prone to breakage in the future.

Interested in advice or to hear from anyone who’s been here before and has
stuff executing under certain rubies which were setup earlier in the
provision.

Thanks,

Ian


#2

On Thursday, July 4, 2013 at 2:20 AM, Ian Chilton wrote:

Hi,

I have a chef wrapper cookbook & recipe setup that’s provisioning our whole development environment.

What I want to do though is also include the currently manual steps of setting up the application at the end:

  • Clone from private Github repo
  • Drop in database.yml
  • gem update --system
  • gem install bundler
  • bundle install

What I need to do though is:

a) Get access to the private github repo

b) Execute as the correct user, as on vagrant it will be vagrant and on normal installs it might be something else - and if chef is invoked manually it will be running from the user with sudo or if it’s invoked by vagrant, it’s run as root.

c) Load chruby into the environment so all the gem stuff is done under the correct Ruby.

How do others handle these issues?

I’m thinking that getting access to the private repo could be done using deploy keys included with the chef repo which gives read only access to that single repo.

I’m thinking the target user could be by way of a node attribute (and could check for the presence of a vagrant user to set the default).

The environment thing I guess I could go through the chruby script and see what environment variables it sets and set ENV[‘PATH’], ENV[‘GEM_HOME’] etc etc, but that’s ugly and prone to breakage in the future.

Interested in advice or to hear from anyone who’s been here before and has stuff executing under certain rubies which were setup earlier in the provision.

Thanks,

Ian

Adding a --login flag to the bash resource will handle sourcing rc scripts as described in the “invocation” section of the bash man page.


Daniel DeLeo