Introduction
This article will cover the initial steps I take to use Gentoo in the Rackspace public cloud environment. These steps involve taking the stock Gentoo image that Rackspace provides, updating and customizing it, then creating a personal image for further use.
Creating the Initial Instance
Launch an initial instance using the stock Gentoo 13.1 image. If you're able to afford the cost, I recommend launching an instance type with 4 or more vCPUs. This will cut down on the compile time. This entire process takes around 4 to 5 hours, so running a 4 vCPU instance will cost approximately $2.50.
When the instance is ready to be converted into an image, resize it to the smallest possible size. This way, you're able to launch the image in as many possible sizes. If you do not resize the instance, you will only be able to launch the instance in sizes greater than or equal to the original size.
Updating and Customizing the Instance
Portage Update
First, run emerge --sync
to update the packages in the portage database. One of the packages with an available update was probably Portage itself. Update it by doing:
Initial Packages
Next, since the default Gentoo image does not come with a text editor, one should be installed:
Since this is a remote session, using a terminal manager like tmux
will allow you to resume sessions if you get disconnected:
Once installed, switch into tmux
.
make.conf Changes
Make some changes to /etc/portage/make.conf
:
First, increase the number of jobs defined in MAKEOPTS
. The number should be: (the amount of CPUs that your instance has) + (one):
Second, define version targets for both Python and Ruby:
Finally, set any global USE flags. I only set vim-syntax
for the master image:
I wouldn't recommend setting values for variables like CFLAGS
or MARCH
since the CPU could vary from compute node to compute node.
Update World
Next, update all packages:
This will probably take a few hours – most of the time will be devoted to updating gcc
. On a 4 vCPU instance, the total running time was:
Global Packages
Now it's time to start applying global configurations and packages that will be used for all instances based off of this image. For example:
Once eix
is installed, perform a sync:
I like having Puppet installed on everything:
Kernel Update
Next, update the kernel. First, see what kernels are available:
For example, the output might look like:
Select the latest kernel:
This modifies the /usr/src/linux
symlink to the proper /usr/src/linux-*
directory.
Next, create a .config
file with the currently running kernel's configuration:
Next, run:
You'll be prompted to answer questions for any new features that were added between the currently running kernel and the new kernel you are configuring. I usually just choose the defaults.
Next, use genkernel
to build the kernel:
Once the kernel is done building, add an entry to the beginning of /boot/grub/menu.lst
similar to the following:
Finally, cross your fingers and reboot. While it's rebooting, ping the IP address in another terminal. If it begins responding to pings, the kernel upgrade worked.
One thing I have noticed is that the instance will successfully boot, but the network interfaces will be down. To fix, log in to the Console via the Rackspace dashboard and:
Final Steps
This section could also be called "A Growing List of Miscellanous Steps".
- Instead of relying on the randomly generated password that is issued each time you launch an instance, copy a public SSH key to
/root/.ssh/authorized_keys
. - Edit the
/etc/hosts
file and remove the entries of the currently running instance. - Remove all of the
*.bak~
files from/etc
:
- Make sure
/etc/conf.d/nova-agent
is empty as it will append UUIDs rather than replace the current one:
Finally, use the dashboard to create an image from the running instance.
Notes
Some last things to note:
- I've had one issue where my instance had two IPv4 addresses: one that was previously assigned to the instance used to build the image and another that was assigned to the instance. I have not been able to continuously reproduce this issue. As a precaution, this is why I document removing the
*.bak~
files.
Conclusion
This article covered the basic steps needed to update and customize the stock Gentoo image found in the Rackspace public cloud. I plan to do further work with this when I get time: such as building an expandable distcc system that builds Gentoo packages or writing a scheduled script that does all of this work on a periodic basis so I always have an up-to-date image available.
I'm interested to hear if any of the above steps can be done in a better way – particularly if there is a better Gentoo-ish way.
Comments
comments powered by Disqus