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:
$ emerge -a --oneshot portage
Initial Packages
Next, since the default Gentoo image does not come with a text editor, one should be installed:
$ emerge -a vim
Since this is a remote session, using a terminal manager like tmux
will allow you to resume sessions if you get disconnected:
$ emerge -a tmux
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):
MAKEOPTS="-j5"
Second, define version targets for both Python and Ruby:
# Python targets
PYTHON_TARGETS="python2_7 python3_2"
PYTHON_SINGLE_TARGET="python2_7"
USE_PYTHON="2.7"
# Ruby
RUBY_TARGETS="ruby19"
Finally, set any global USE flags. I only set vim-syntax
for the master image:
USE="vim-syntax"
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:
$ emerge -DNua --with-bdeps=y world
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:
real 82m2.860s
user 95m4.966s
sys 63m23.733s
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:
$ emerge -a git genkernel gentoolkit eix
Once eix
is installed, perform a sync:
$ eix-sync
I like having Puppet installed on everything:
$ echo "=sys-apps/net-tools-1.60_p20120127084908 old-output" > /etc/portage/package.use
$ emerge -a puppet
Kernel Update
Next, update the kernel. First, see what kernels are available:
$ eselect kernel list
For example, the output might look like:
Available kernel symlink targets:
[1] linux-3.7.10-gentoo *
[2] linux-3.8.13-gentoo
Select the latest kernel:
$ eselect kernel set 2
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:
$ cd /usr/src/linux
$ zcat /proc/config.gz > .config
Next, run:
$ make oldconfig
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:
$ genkernel --install --no-mrproper --makeopts="-j5" all
Once the kernel is done building, add an entry to the beginning of /boot/grub/menu.lst
similar to the following:
title Gentoo Linux 3.8.13-gentoo
root (hd0,0)
kernel /boot/kernel-genkernel-x86_64-3.8.13-gentoo root=/dev/xvda1 ro console=hvc0
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:
$ rc-update add net.eth0 boot
$ rc-update add net.eth1 boot
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
:
$ find /etc -name \*.bak~ -delete
- Make sure
/etc/conf.d/nova-agent
is empty as it will append UUIDs rather than replace the current one:
$ echo > /etc/conf.d/nova-agent
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