Building a CentOS 4 AMI: Part 2 of 2

In my last post, I outlined the preparation of a virtual system to be used to create the AMI. Everything done here is on the virtual machine and references the exact settings in the previous post.

NOTE: If you have not signed up for an AWS account and agreed to the EC2 and S3 terms of agreement you won't get too far here. Your own private key, certificate, and AWS user id is required to complete all of these steps.

Here, I will describe the actual image creation, uploading and then starting the AMI in the cloud. The steps I outline are exerpts from a script I use to automate all the steps. If you copy all the steps below to your own script, it ought to work.

Like all systems, whether virtual or real, requires a disk or disk image. I've opted to create a 2 GB image. I recognize that this is not the only way and you can accomplish this through other processes and means.

# Making the image and formatting the file system
dd if=/dev/zero of=centos-4.7-i386.img bs=1M count=2000
mke2fs -F -j centos-4.7-i386.img

# Mounting the image file
mount -o loop centos-4.7-i386.img /mnt

NOTE: You may create a larger image to suit your needs and it may be more economical than downloading things after the instance is started but remember that Amazon charges not just for uploads but for monthly storage. Creating an image larger than what you need may cost you.

Next step is creating some necessary directories and device files in the image. These processes are basic though provide a foundation for the software installation and running system later. More information can be had from any one of the many build your own distribution web sites.

# Creating the necessary directories
mkdir /mnt/dev
mkdir /mnt/proc
mkdir /mnt/etc

# Creating some minimal device files
for i in console null zero
do
/sbin/MAKEDEV -d /mnt/dev -x $i
done

More system basics here. The fstab file needs to be created and the image's proc file system is also necessary for the loading of software.

# Create fstab
cat <<EOFSTAB > /mnt/etc/fstab
dev/sda1 / ext3 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
/dev/sda2 /mnt ext3 defaults 1 2
/dev/sda3 swap swap defaults 0 0
EOFSTAB

# Mount the image proc now
mount -t proc none /mnt/proc

I'm using yum to perform the installation. It's a great tool for automatically resolving software dependencies and installing what's needed without the need for searching countless Google hit pages, cruising RPMfind.net or hunting for your distribution installation images.

You can expand on the yum.conf file as needed to customize your image. What I've included here are the basics but you may add the configuration for any other bit of software.

# Custom yum.conf for our image
cat <<EOCONF > /tmp/yumec2.conf
[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
exlude=*-debuginfo
gpgcheck=0
obsoletes=1
reposdir=/dev/null

[base]
name=CentOS-4.7 - Base
mirrorlist=http://mirrorlist.centos.org/?release=4.7&arch=i386&repos=os
protect=1

[update]
name=CentOS-4.7 - Update
mirrorlist=http://mirrorlist.centos.org/?release=4.7&arch=i386&repos=updates
protect=1
EOCONF

NOTE: I would recommend for those who plan on using or tweaking their image to download all the packages you need from the distribution and create your own internal mirror site. Mirrors come and go and should your required version 1.2.3-5-EL4 get replaced and cause problems with package wyzzwg-4.3.2-1-EL4 then you may need to invest in Tylenol .

Finally, let's install some software. This may take a while depending on your internet connection. So, start now and go get some coffee or do your Christmas shopping... just not online. Go to the store. They're those big brick, stone or stucco buildings you see in real life alongside highways.

# Avoid a yum lock file error
mkdir -p /mnt/var/lock/rpm

# Install the base
yum -c /tmp/yumec2.conf --installroot=/mnt -y groupinstall Base

# Cleanup
yum -c /tmp/yumec2.conf --installroot=/mnt -y clean packages

Done? No errors? Das ist gut.

We're in the home stretch. We need to solve our access problems. I, as the rest of the world, should prefer nothing less than SSH for accessing systems. If you haven't generated a public-private key pair yet, please do so. This will store the key paid in /root/.ssh.

ssh-keygen -t dsa -C '' -N ''

The next few steps I've refined so our instance whenever started is ready for me to login. After all, this is like a freshly installed system and we can't expect it to know our password nor do we want some password stored out there in the S3-land.

# Make sure TLS is disabled
mv /mnt/lib/tls /mnt/lib/tls-disabled

# When this instance boots, the keys to the instance need to be there
if [ ! - d /mnt/root/.ssh ] ; then
mkdir -p /mnt/root/.ssh
chmod 700 /mnt/root/.ssh
fi

# Copy public key to instance
cp /root/.ssh/id_dsa.pub /mnt/root/.ssh/authorized_keys2
chmod 644 /mnt/root/.ssh/authorized_keys2

NOTE: No private keys installed. This is ultimately important. Like your password which does not exist in the /etc/shadow file on the image your private key should be kept out of the cloud.

The SSH daemon needs some tweaking to keep us from being shut out.

cat <<EOCONF >> /mnt/etc/ssh/sshd_config
UseDNS no
PermitRootLogin without-password
EOCONF

Our network configuration. Kinda pointless if we don't let the AMI have a network connection.

cat <<EOCONF > /mnt/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=localhost.localdomain
EOCONF
cat <<EOCONF > /mnt/etc/sysconfig/network-scripts/ifcfg-eth0
ONBOOT=yes
DEVICE=eth0
BOOTPROTO=dhcp
EOCONF

Let's not forget to unmount things. Hate to spend all this time creating a nice, neat image just to corrupt it later.

# Unmount image
sync
umount /mnt/proc
umount /mnt

Putting the ribbon around the image now. Here you can go crazy telling the instance on boot to use wget or curl to download your custom scripts, data, or whatever installing, running or just having it spin in circles. It's all completely customizable just by adding the scripts to the /etc/init.d director and appropriate links to the /etc/rc3.d directory. I believe run level 3 is the default.

NOTE: If you're going to put custom boot scripts in that leverage commands such as wget or curl then make sure they exist in the image. If they do not, just add some more yum command similar to what is above and you'll be all set.

Okay. This post ran a little long so my 2 post steps to building your AMI is going to spill over into a 3rd. Should give you time to customize your image and creates dreams of conquering the world.