Customizing your BOSH VM’s root user profile

Ever wanted to get your own aliases, or vim/emacs settings inside BOSH VMs? With the root-env-boshrelease, now you can!

I spend a significant amount of time inside bosh VMs troubleshooting releases or template changes. It wasn’t long before I wished I had my .inputrc, .vimrc, and aliases that I’m used to having at the command line. To address this, I created the root-env-boshrelease, which takes a tarball of environment settings, and unpacks them into the root user’s home directory inside BOSH VMs.

How does it work?

When you apply the root-env job to a BOSH VM, it will save the original root home directory (if for some reason you decide to ditch the custom root environment), download the environment you specify, and unpack it into a new root home directory.

If you want to update root’s user profile, simply provide a new tarball to the root-env job, and run a bosh deploy. The root-env job will do a complete replacement of the root environment. This is a complete replacement of the /root directory structure, but that’s nor a problem, because you haven’t been creating important files you, inside the local filesystem of a BOSH VM, right?

That’s great and all, but I want a step by step guide!

1. Add the release to your BOSH installation. # Download the root-env release $ git clone https://github.com/cloudfoundry-community/root-env-boshrelease $ cd root-env-boshrelease # Upload the BOSH release $ bosh upload release releases/root-env/latest.yml
2. Edit the your deployment manifest to add the root-env release. releases: - name: myrelease version: 42 # Here's the important stuff: - name: root-env version: latest
3. Edit the jobs in your manifest to add the root-env job. jobs: - name: my_job_z1 templates: - name: myjob release: myrelease # Here's the important stuff: - name: root-env release: root-env Lather, rinse, repeat as needed.
4. Edit the deployment manifest properties to specify the tarball
   to use in root-env. properties: myjob: mysetting: is cool, but root-env is better # And again, the important stuff: root-env: env_tarball: http://github.com/geofffranks/env/archive/v1.1.tar.gz # or any tarball you want
5. Deploy! $ bosh deploy

I want to make my own profile

The settings provided in my tarball is great…for me. You may not be so happy with some of my choices. But that’s no problem, all you need to do is make a gzipped tarball containing all the environment files you want, and stick it on the internet somewhere – S3, github, or literally any other public webserver.

For reference on how to structure the tarball, here’s the layout of mine:

$ tar -tzf v1.1.tar.gz
env-1.1/
env-1.1/.bash_logout
env-1.1/.bashrc
env-1.1/.gitconfig
env-1.1/.inputrc
env-1.1/.modulemaker_defaults
env-1.1/.profile
env-1.1/.proverc
env-1.1/.ssh/
env-1.1/.ssh/config
env-1.1/.vim/
env-1.1/.vim/autoload/
env-1.1/.vim/autoload/pathogen.vim
env-1.1/.vimrc
env-1.1/README.md
env-1.1/bin/
env-1.1/bin/gitprompt.pl
env-1.1/bin/setup_ssh_agent

Can I host it somewhere privately?

Right now, the only supported transports for retrieving the tarball are HTTP and HTTPS. Additionally, the BOSH VMs must have access to download it directly. Unfortunately, no authentication is supported.

If you want to host the tarball inside the same private network as your BOSH VMs, that should work. You could even use the new static_buildpack support in CloudFoundry on an internal-only domain to host a private user profile tarball.

If that’s not workable for your environment, pull requests are totally welcome!

That doesn’t seem very BOSH-y

You’re right! root-env-boshrelease is a quick and dirty hack to get things up and runnning as fast as possible (for both development + adoption). Please don’t create BOSH releases that rely on external dependencies the way this one does. At some point I may take time to refactor it to store the profile tarball in the BOSH blobstore, allowing the VMs to retrieve it from there.