If you read my previous article, WordPress Workflow : Automated Virtual Box Creation , you have an idea of what I am trying to accomplish with improving my WordPress development work flow. The short version, I want to be able to create a fresh install of a virtual machine that has my entire development system intact with minimal input on my part. The idea is to run a few commands, wait for the installs and updates, and be coding on a “clean” machine shortly after. Once I get my own work flow updated I will also be able to share my scripts and tools via a git repository with the remote developers that are now working on Store Locator Plus add-on packs and hopefully simplify their development efforts or at least get all of us on a similar baseline of tools to improve efficiency in our efforts.
Here are my notes from the first virtual development box efforts via PuPHPet, Vagrant, and Puppet. This build was done with recent “off-the-shelf” versions of each of these tools and using a base configuration with a handful of options from the PuPHPet site.
The VirtualBox machine appears to be created as a “headless” box, meaning no monitor or other display device is active. I will need to tweak that as I work “on the box” with GUI development tools. I know that I can install all of my development tools on my host system and read/write from a shared directory to get all of my work onto the virtual machine, but that is not my methodology. Having worked with a team of developers I know all too well that eventually the host hardware will die. A laptop will need to be sent off for repair. Guess what happens? You lose half-a-day, or more, setting up a new host with a whole new install of development tools.
The better solution, for my work flow, is to keep as much of the development environment “self contained” within the virtual box as possible. This way when I backup my virtual disk image I get EVERYTHING I need in an all-in-one restore point. I can also replicate and share my EXACT environment to any location in the world and be fully “up and running” in the time it takes to pull down a 20GB install file. In today’s world of super-fast Internet that is less of an issue than individually pulling down and installing a half-dozen working tools and hoping they are all configured properly.
What does this all mean? I need to figure out how to get the PuPHPet base configuration tweaked so I can start up right from the VirtualBox console with a full Linux console available. I’ll likely need to update Puppet as well to make sure it pulls down the Desktop package on CentOS.
I wonder if I can submit a build profile via a git pull request to PuPHPet.
Out-Of-Box Video Memory Too Low
The first hurdle with configuring a “login box” with monitor support will be adjusting the video RAM. My laptop has 4GB of dedicated video RAM on a Quadro K3100M GPU. It can handle a few virtual monitors and has PLENTY of room for more video RAM. Tweaking the default video configuration is in order.
Since Vagrant “spins up” the box when running the vagrant up command the initial fix starts by sending an ACPI shutdown request to the system. Testing the video RAM concept is easy. Get to the VirtualBox GUI, right-click the box and select properties. Adjust the video RAM to 32MB and turn on 3D accelerator (it makes the GUI desktop happy) and restart.
Looks like I can now get direct console login. Nice!
The second issue, which I realized after seeing the login prompt, is that I have NO IDEA what the login credentials are for the system. This doesn’t matter much when you read/write the shared folders on your host to update the server and only “surf to” the box on port 8080 or SSH in with a pre-shared key, but for console login a username and password are kind of important. And I have no clue what the default is configured as. Time for some research. First stop? The vagrantfile that built the beast.
Buried within that vagrantfile, which looks just like Ruby syntax (I’m fairly certain it is Ruby code), is a user name “vagrant”. My first guess? Username: vagrant, password: vagrant. Looks like that worked just fine. Now I have a console login that “gets me around”, but it is not an elevated permissions user level such as root. However, a simple sudo su – resolves that issue granting me full “keys to the kingdom”.
[box type=”info” size=”large” style=”rounded”]Vagrant Boxes Credentials are username vagrant, password vagrant[/box]
A good start. Now to wreak some havoc to see what is on this box and where so I can start crafting some Puppet rule changes. Before I get started I want to get a GUI desktop on here.
To get a GUI desktop on CentOS you typically run the yum package installer with yum groupinstall Desktop. A visit under sudo su and executing that command gets yum going and pulling down the full X11/Gnome desktop environment.
A quick reboot with shutdown -r now from the root command line should bring up the desktop this time around… but clearly I missed a step as I still have a console login. Most likely a missing startx command or something similar in the boot sequence of init.d.
A basic startx & from the command line after logging back in as vagrant/vagrant and my GUI desktop is in place, so clearly I need to turn on the GUI login/boot loader.
Tweaking PuPHPet Box Parameters
Now that I know what needs to change I need to go and create that environment via the PuPHPet/Vagrant/Puppet files so I can skip the manual tweaking process. After some digging I found the config.yaml file. When you use PuPHPet this file will be put in the .zip download you receive at the end of the PuPHPet process. It is in the <boxid>/puphpet/ directory.
While some of the box parameters can be adjusted in these files, it appears much of the hardware cannot be manipulated. There is a site called “Vagrant Cloud” that has multiple boxes that can be configured. To switch boxes you can edit the config.yaml file and replace the box_url line to point to one of the other variants that may be closer to your configuration. Since I don’t see one that is close to my needs it looks like I will have to build my own box profile to be hosted in the cloud. That is content for another article.