Setup VirtualBox Hardware
Start VirtualBox and build a new guest “hardware” profile:
- Base Memory: 2048MB
- Processors: 2
- Boot Order: CD/DVD , Hard Disk
- Acceleration: VT-x/AMD-V , Nested Paging , PAE/NX
- Display: 32MB Video Memory , 3D Acceleration
- Network: Intel PRO/1000 MT Desktop (NAT)
- Drive: SATA with 20GB pre-allocated fixed disk
- CD/DVD : IDE Secondary Master Empty
- No USB, Audio, or Shared Folders
Base Box “Unbest” Practice
These base settings do not fall within the Vagrant Base Box best practices, however I need something a bit different than the typical Vagrant box configuration which is why I am building my own. I build my boxes with a full GUI which enables me to spin up the virtual environment, login to the GUI, and have my entire development environment in a self-contained portable setting. There are “lightweight” ways to accomplish this but I do have my reasons for building out my WordPress development environment this way which has been outlined in previous posts.
Adding the Operating System
Now that I have the base box setup it is time to layer on the CentOS 6.5 operating system. I setup my box for the English language with a time zone of New York (United States EST, UTC+5), no kernel dump abilities, full drive allocated to the operating system. It is built as a “Desktop” server which gives me the full GUI login which makes it easier to setup my GUI dev environment further on down the road. It does add some GUI apps I don’t need very often but it is nice to have things like a simple GUI text editor and GUI system management tools for the rare cases when I want them and am too lazy to jump out to my host box to do the work.
Per Vagrant standards the box profile is setup with the root password of “vagrant” and with a base user for daily use with an username and password also set to “vagrant”.
After a couple of reboots the system is ready for a GUI login, but not quite ready for full production.
Adding VirtualBox Guest Additions
One of the first things to do with a VirtualBox install running a GUI is to get VirtualBox Guest Additions installed. It helps the guest communicate with the host in a more efficient manner which greatly improves the display and the mouse tracking. Without it the mouse lag in the guest is horrid and is likely responsible for at least 300 of the 3,000 missing hair follicles on my big bald head.
While this SHOULD be a simple operation, the CentOS desktop installation makes it a multi-step process. Selecting “insert Guest Additions CD” from the VirtualBox server menu after starting up the new box will mount the disk. It will prompt to autorun the disk and then ask for the root user credentials. The shell script starts running through the Guest Additions setup but it always falls while building the main Guest Additions module. The reason is that kernel build kits are needed and they are not installed by default. I will outline the typical user process here as a point of reference, though most often the first commands I run to fix the issue are those listed at the end of this section. I’ve done this enough times to know what happens and don’t usually execute the autorun until AFTER I setup the kernel build kit. You may want to do the same.
Here is what the output looks like after a default CentOS desktop install followed by an autorun of the Guest Additions CD:
With the mouse tracking driving me nuts I toggle over to the text console with ctrl-alt-F1 and login as root on there. You can learn what broke the Guest Addition install by going to the log files:
The typical CentOS desktop build fails the Guest Additions install with this log:
/tmp/vobx.0/Makefile.include.header:97: *** Error: unable to find the sources of your current Linux kernel. Specify KERN_DIR= and run Make again. Stop.<br />Creating user for the Guest Additions.<br />Creating udev rule for the Guest Additions kernel module.<br />
With Guest Additions disabled and the VirtualBox not fully configured it is time to do some basic maintenance and get the kernel build environment available for Guest Additions. Since I am logged in as root via the console I can start by getting yum updated, however the network connection does not always start up before Guest Additions is available. The steps for getting the kernel dev in place:
Turn on the network interface eth0 (zero not oh) running:
Make sure all of the installed software is updated to the latest revision:
Install the Linux kernel development files which are needed for the Guest Additions installation:
yum install kernel-devel
Install the development tool kit including compilers and other items needed to Guest Additions to hook into the kernel:
yum groupinstall "Development Tools"
Once you have the updates installed reboot the system with a shutdown -r now command while logged in as root.
The Guest Additions CD can now be mounted and autorun without error.
After running Guest Additions, reboot the server.
Turn On The Network At Boot
Now that the GUI is running and the mouse is tracking I can log in as the vagrant user and turn on the network connections. Login, go to System / Preferences / Network Connections on the main menu. Check off “Connect Automatically” on the System eth0 connection.
Now the network will be enabled on boot. That’s useful.
Provide SSH Insecure Keypair To Vagrant
Best practices for Vagrant base boxes is to add an insecure keypair to the vagrant user. While logged in as vagrant go to Applications/Systems Tools/Terminal to get to the command line. Go the .ssh subdirectory and create the authorized_keys file by copying the public key from the Vagrant keypair repository into the authorized_keys file.
I use vim and copy the keypair content and paste it into the file. You can use cat or other tools as well to get the content into the file. Make sure not to introduce new whitespace in the middle of the key or it will not work.
Change the permissions of the authorized_keys file by using chmod, permission settings are very important for the file:
chmod 0600 authorized_keys
Give Unrestricted Super Powers To Vagrant
Most users expect the vagrant login to have unrestricted access to all system commands. This is handled via the sudo application. CentOS restricts access by default and requires some updates to get it working per Vagrant best practices. Log back in to the command line console as root and edit the sudo file.
This brings up the vim editor with the sudo config file. Find the requiretty line and comment it out by adding a # before it. Then add the following line to the bottom of the file:
vagrant ALL=(ALL) NOPASSWD: ALL
Logout of the vagrant and root sessions and log back in as vagrant from the GUI. You should be able to open a terminal and run any sudo commands without a password prompt. You should also be able to run sudo commands “remotely” via the ssh connection to the system.
Make SSH Faster When DNS Is Not Available
If the host and/or virtual box cannot connect to the Internet the SSH access into the Vagrant virtual box will be slow. Editing the sshd_config file and turning off DNS lookups will fix that. Now that you have “vagrant super powers” you can do this by logging in as the vagrant user and opening the terminal:
sudo vim /etc/ssh/sshd_config
Add this line to the bottom of the file:
Host To Guest SSH Access
Connecting from the host system to the guest system WITHOUT using the graphical login or console takes a couple of extra steps. To test the SSH connection I go back to my favorite SSH tool, PuTTY. Before testing the connection the port forwarding needs to be setup on VirtualBox Manager.
- Go to the new system listed on the VirtualBox Manager.
- Right-click and select Settings.
- Select Network.
- Click the Port Forwarding button.
- Add the following rule:
- Name: SSH Local To Guest
- Protocol: TCP
- Host IP: 127.0.0.1
- Host Port: 4567
- Guest IP: leave this blank
- Guest Port: 22
Save the settings. Open PuTTY and connect to hostname 127.0.0.1 and change the port to be 4567. You should get a login prompt. Login with user vagrant.
The issue with logging in with the vagrant private key file is that PuTTY only supports the proprietary PuTTY Private Key format. You can download puttygen to convert the Vagrant private key file to the PuTTY Private Key file format (click to download the converted OpenSSH key in PPK format).
To use SSH keys in PuTTY, start a new session, enter 127.0.01 as the host and 4567 as the port, then set the PuTTY Private Key:
- Click on “connection / SSH” in the left side menu to expand that selection.
- Click on “Auth”.
- Under Authentication parameters browse to your saved PPK file in the “Private key file for authentication” box.
Now you can connect with PuTTY and login by simply supplying a username. This tells us that the remote vagrant command line should be able to execute all of the scripted setup commands without any issues.
Building A Box
Now that the basic system is in place it is time to “build the box”. Vagrant has a command for doing this and if you’ve read my previous articles on setting up Vagrant you will know that I have a Windows command line shortcut that runs in my WP Development Kit folder. With Vagrant already installed building a box is a one-line command. I only need my machine name, which I’ve shorted to “CentOS6.5 GUI Base Box”. Start up the Windows command line and run this:
vagrant package --base "CentOS6.5 GUI Base Box"
It will run for a while and eventually create a packaged Vagrant box ready for distribution. By default the file will be named package.box. I’ve renamed mine to centos6_5-gui-base.box for distribution purposes. You can find it on my Vagrant Cloud account.
You can learn more about the box-building process via the Vagrant Creating A Base Box page.
Launching The Box
To launch the new box hosted on Vagrant Cloud I go to my local folder and execute these commands:
Download the image (stored on my Google Drive account) using Vagrant Cloud as a proxy:
vagrant box add charlestonsw/centos6.5-gui-base-box
Create the vagrantfile that assists in the box startup command sequence:
vagrant init charlestonsw/centos6.5-gui-base-box
Start the box on VirtualBox:
By default, Vagrant starts boxes in headless mode, meaning no active console. I want the GUI login so I shut down the box and find the vagrantfile to add the GUI startup line. The command is already in the file and only needs a few lines to be uncommented to allow a GUI startup with a console. Edit the vagrantfile and look for these lines:
config.vm.provider "virtualbox" do |v| v.gui = true end
There are few other comments in the default vagrantfile, you can leave the limits tweaks commented. You will end up with a vagrantfile section that looks like this:
# Provider-specific configuration so you can fine-tune various # backing providers for Vagrant. These expose provider-specific options. # Example for VirtualBox: # config.vm.provider "virtualbox" do |vb| # Don't boot with headless mode vb.gui = true # # Use VBoxManage to customize the VM. For example to change memory: # vb.customize ["modifyvm", :id, "--memory", "1024"] end
Save the file and restart the box with the vagrant up box.
That’s it… a new Vagrant box. Now on to the system tweaks to get my WP Dev Kit setup.