tech notes » linux

how to create a new kvm image for eucalyptus UEC

admin — Sun, 15 Nov 2009 13:29:51 +0000

Eucalyptus is a new cloud management software available with the latest version of ubuntu (karmic koala). It’s compatible with Amazon’s EC2 (in terms of images and CLI tools) and it’s opensource so anyone can build a EC2 like service. That is… when it becomes a little bit more stable…

Eucalyptus comes with 2 images you can use to create vm instances on it – a 64 bit and 32 bit versions of ubuntu. These images are very well prepared and well integrated with EC2/Eucalyptus. But what if you want to run a different linux distro in your Eucalyptus based lab? Here’s a quick howto on creating a simple CentOS image on a ubuntu box with kvm installed:

Creating a new disk Image

This will be the main hdd in your virtual image, so make sure to give it as much space as you think you’ll need. Since we’re building a kvm image, we can use a qcow2 format for disk images. Qcow2 is an expandable image format, so it’ll only take as much storage space as it’s actually used withing the image.

kvm-img create -f qcow2 image.img 20G

OS Installation

Fetch an .iso of the distribution you want installed in the image.

wget http://www.mirrorservice.org/sites/mirror.centos.org/5.4/isos/x86_64/CentOS-5.4-x86_64-netinstall.iso

and start the installation process:

sudo kvm -m 256 -cdrom Centos-5.4-x86_64-netinstall.iso -drive file=image.img,if=scsi,index=0 -boot d -curses -net
nic,vlan=0,model=e1000,macaddr=00:16:3e:de:ad:01 -net tap

if your installation process requires more than 256MB of RAM change the -m option, and if you need more processors available, you can use the ‘-c’ option.

The command above will boot a new kvm instance, with the disk image you’ve created as the primary hdd and the iso as the first bootable device. Also the ‘-curses’ option will make the kvm display all console output to your ssh session. (I’m assuming here, you’re creating this image over a remote connection, if you’re not you can probably skip the -curses option and kvm should use sdl drivers instead)

After finishing the installation you can test the new virtual machine by running:

sudo kvm -m 256 -drive file=image.img,if=scsi,index=0,boot=on -boot c -curses -net nic,vlan=0,model=e1000,macaddr=00:16:e3:de:ad:01 -net tap

At this point you can add all the packages you want to have installed, all users, any settings that need to be present in your new UEC instances.

Now it’s also a good time to copy the kernel and the initrd image from your new vm image some place outside. They will be used later on to create and upload an complete virtual image to your UEC.

Before you shut your new shiny image down there’s one more step to be done:

Integration with UEC

Your new image needs to know what IP it has when started in UEC and also, it needs to know the public bit of the ssh key allowed to access it. The way it’s done in UEC (and EC2?) is via a restful interface provided by the cloud. The interface is available under this URL: http://169.254.169.254/latest/meta-data. You can use wget to see what information is provided:

wget -q -O – http://169.254.169.254/latest/meta-data/

What’s interesting for us here is the public key data which is available here:

http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key

As we need to automate the whole process a bit, let’s put it all into an init.d script:

#!/bin/bash
#
. /etc/rc.d/init.d/functions

RETVAL=0

start()
{
fetch_ssh_key
regenerate_ssh_keys
}

stop()
{
echo “nothing to stop…”
}

regenerate_ssh_keys()
{
rm -f /etc/ssh/ssh_host_key /etc/ssh/ssh_host_rsa_key /etc/ssh_ssh_host_dsa_key
[ -f /etc/ssh/ssh_host_key ] || (ssh-keygen -f /etc/ssh/ssh_host_key -t rsa1 -C ‘host’ -N ” | logger -s -t “ec2″)
[ -f /etc/ssh/ssh_host_rsa_key ] || (ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -C ‘host’ -N ” | logger -s -t “ec2″)
[ -f /etc/ssh/ssh_host_dsa_key ] || (ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -C ‘host’ -N ” | logger -s -t “ec2″)

echo “—–BEGIN SSH HOST KEY FINGERPRINTS—–” |logger -s -t “ec2″
ssh-keygen -l -f /etc/ssh/ssh_host_key.pub |logger -s -t “ec2″
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub |logger -s -t “ec2″
ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub |logger -s -t “ec2″
echo “—–END SSH HOST KEY FINGERPRINTS—–” |logger -s -t “ec2″
}

fetch_ssh_key()
{
if [ ! -d /root/.ssh ] ; then
mkdir -p /root/.ssh
chmod 700 /root/.ssh
fi

curl -f http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /tmp/ssh-key
if [ $? -eq 0 ] ; then
cat /tmp/ssh-key >> /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys
rm /tmp/ssh-key
# disable password logging
sed -i.bkp ’s/^PasswordAuthentication yes/PasswordAuthentication no/’ /etc/ssh/sshd_config
fi
}

case “$1″ in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
condrestart)
echo “not implemented”
;;
status)
echo “not implemented”
;;

*)
echo $”Usage: $0 {start|stop|restart|reload|condrestart|status}”
RETVAL=1
esac

exit $RETVAL

Enable this script in your boot process. The script will not only download and install this key on root account. It also regenerates your instance’ keys and displays their fingerprints on the console (so you can see them by doing euca-get-console-output i-instance_number)

This script is just a simple example, you can also take the python uec backend available in ubuntu and use it to do the same thing i a slightly better and cleaner way.

Uploading to UEC

The last step is uploading your image to UEC:

bundle and upload the previously copied kernel first:

euca-bundle-image -i kvm-kernel/vmlinuz-2.6.28-11-generic –kernel true
euca-upload-bundle -k mybucket -m /tmp/vmlinuz-2.6.28-11-generic.manifest.xml
euca-register mybucket/vmlinuz-2.6.28-11-generic.manifest.xml

save the k-* output produced by the last command above and proceed with initrd:

euca-bundle-image -i kvm-kernel/initrd.img-2.6.28-11-generic
euca-upload-bundle -b mybucket /tmp/initrd.img-2.6.28-11-generic.manifest.xml
euca-register mybucket/initrd.img-2.6.28-11-generic.manifest.xml

as above, save the i-* output and upload the image now:

euca-bundle-image -i image.img –kernel $PREVIOUSLY_SAVED_KERNELID –ramdisk $PREVIOUSLY_SAVED_IMAGERD
euca-upload-bundle -b mybucket -m /tmp/image.img.manifest.xml
euca-register mybucket/image.img.manifest.xml

All done, your new image should be visible after euca-describe-images -a.

RPM build environment on CentOS

admin — Wed, 02 Sep 2009 21:42:23 +0000

Just a quick note on how to build RPMs

setting up build environment

RPMs should be built from a ”’standard user”’ account, ”’not root”’. This saves a lot of trouble when something goes wrong during package preparation/installation and keeps the build environment clean.

Here’s how to setup build environment in your home directory:

mkdir -p ~/build/{BUILD,RPMS,S{OURCES,PECS,RPMS}}

These directories are for:

BUILD – that’s the place where your source package will get untargzipped, patched and compiled
RPMS – will contain your RPMS when done
SOURCES – upload all source .tar.gz’s and your patches here
SPECS – .spec files with instructions on how to build your packages
SRPMS – source RPMS, a bit more about them below

Now you need to tell rpm-build where to look for these directories:

echo “%_topdir $HOME/build” > ~/.rpmmacros

and finally you need to install some software:

sudo yum install rpm-build redhat-rpm-config mock

(Keep in mind, that the list above is not complete as it doesn’t contain any compilers, libtools, automakes etc, that might be required to actually build your source package.)

and create a ’special’ user for the mock package (this is to allow fakeroot builds):

sudo useradd -M -d / -s /sbin/nologin mockbuild

building from SRPMs (easy!)

SRPMS (source RPMS) contain the .spec file and all necessary source files and patches needed to build a binary package. This can be usefull if there’s no binary package available for your platform but there’s a source one available for a similar one (redhat.srpms to build packages for centos).

One way to build a binary package from a source one is to:

rpmbuild –rebuild package-1.0.src.rpm

This will do all the magic and (hopefully) put a binary package in build/RPMS/$arch/

Other way is to install (as user, it will put all sources and patches to build/SOURCES and the spec file to build/SPECS) the source package first and then use rpmbuild:

rpm -i package-1.0.src.rpm
rpmbuild -ba ~/build/SPECS/package-1.0.spec

According to the documentation you can build RPMs from .tar.gzs if they contain a .spec file. You would do it by using -ta option for rpmbuild instead of -ba.

building from source

This means creating your own package from scratch. There’s how to do it:

First see if the package builds from source without any tweaking. Check if it (or the resulting package you want built) requires any special options to be passed to either ./configure or make. Also at this point think of any modifications to the original source code you’d like to have (changes in default config files, additional modules compiled in or removed from the package etc etc).

If you do need some changes done, this is a good time to make all the patches.
Make a clean and untouched copy of the untargzipped package:

tar xvfz moosoft-1.0.tar.gz
cp -Rvp moosoft-1.0 moosoft-1.0.orig

now make all the required changes in the moosoft-1.0 directory and generate patch or a set of patches:

diff -uNr moosoft-1.0.orig moosoft-1.0 > moosoft-1.0.bigpatch.patch
# or:
diff -uNr moosoft-1.0.orig/etc/moo.conf moosoft-1.0/etc/moo.conf >
moosoft-1.0.config.patch
diff -uNr moosoft-1.0.orig/doc/ moosoft-1.0/doc >
moosoft-1.0.documentation.patch
# etc… to generate multiple patches

Copy these patches and the original moosoft-1.0.tar.gz file to ~/build/SOURCES.

The last thing to do is to prepare a recipe for rpmbuild how to build your package. Create moosoft-1.0.spec file in ~/build/SPECS:

#                  _____________________________
#         (__)    /                             \
#         (oo)   ( This is an example .spec file )
#  /-------\/  --'\_____________________________/
# / |     ||
#*  ||----||
#   ^^    ^^
####
# package preamble
# one line description of the package
Summary: Very important Unix tool
Name: moo
Version: 1.0
# this marks the internal release version: moo-1.0-1.666.x86_64.rpm
Release: 1.666
License: BSD
# group you want your package in, mostly for GUI package browsers
# some example groups used by vendors:
# http://www.rpmfind.net/linux/RPM/Groups.html
Group: Networking/Daemons
# your name for example
Packager:
#
Source: http://full.url.to.the/package/%{name}-%{version}.tar.gz
Source1: moo.init
# list all your patches here:
Patch0: moo-1.0.etc.patch
Patch1: moo-1.0.documentation.patch
# list all packages required to build this package
BuildRequires: openssl-devel
Provides:
# list all packages that conflict with this one:
Conflicts: bse
BuildRoot: %{_tmppath}/%{name}-%{version}-build

####
# full length description
%description

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc eros elit,
pretium eu vestibulum vel, blandit vel nisl. Fusce mattis volutpat
pellentesque. Etiam sit amet magna eget dui faucibus rutrum. Aliquam a ligula
erat. Proin metus tortor, sollicitudin et accumsan quis, hendrerit non leo.
Curabitur egestas neque sed nulla vulputate vel bibendum sapien tristique.
Vivamus malesuada, magna et semper iaculis, magna lorem adipiscing erat, vel
euismod enim nulla vel tortor. Vestibulum accumsan placerat sagittis. Sed
commodo pretium lectus et dignissim. Ut nec orci tellus.

#####
# this prepares a fresh build directory in ~/build/BUILD, useful macros here
# are:
# %setup - cleans any previous builds and untargzips the source
# %patch - applies patches
# any other commands here are executed as standard sh commands
%prep

%setup
%patch
%patch1

./configure --enable-something --with-something-else

#####
# this tells rpmbuild how to build your package, rpmbuild runs it as a sh
# script
%build
make

#####
# all the steps necessary to install your package into $RPM_BUILD_ROOT
# first step is to clear $RPM_BUILD_ROOT
%install
[ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
#install all files under RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT

# now you can remove uneeded stuff
rm -f $RPM_BUILD_ROOT{_prefix}/sbin/rc.moo

#####
# NOTE: this section is optional
# commands run just before the package is installed
%pre
/usr/sbin/useradd -c "moo user" -r -s /bin/false -u 666 -d / moo 2> /dev/null
|| :

#####
# NOTE: this section is optional
# commands run before uninstalling the software
%preun
/sbin/service moo stop > /dev/null 2>&1
/sbin/chkconfig --del moo

#####
# NOTE: this section is optional
# commands run after installing the package
%post
/sbin/chkconfig -add moo
touch /var/log/moo

#####
# NOTE: this section is optional
# commands run after unistalling the package
%postun
/sbin/service moo stop
/usr/sbin/userdel moo

#####
# list all the files that are part of the package. If a file is not in the
# list rpmbuild won't put it in the package
# see below on how to automate the process of creating this list.
# some useful macros here:
# %doc filename - installs filename into /usr/share/doc/moo-1.0/
# %doc /path/to/filename - installs filename into /path/to/filename and marks
# it as being documentation
# %config /etc/config_file - similar for configuration files
# %attr(mode, user, group) file - lets you specify file attributes applied
# during installation, use - if you want to use defaults
%files
/usr/bin/moo
/usr/sbin/moomoo
# this will package the dir and all directories inside it
/example/of/a/dir
# this will package only the 'dir' directory
%dir /example/of/a/dir

#####
# document changes between package releases
%changelog
* Wed Jul 8 2009 Your Name Here
- another version of the package

* Mon Jul 6 2009 Your Name Here
- initial version of the package

To get the list of all installed files do

rpmbuild -bi ~/build/SPECS/moo-1.0.spec

this will go through prep, build and install steps of the spec file and install all files under $RPM_BUILD_ROOT, which in this case should be /var/tmp/moo-1.0-build.

ls -R1 /var/tmp/moo-1.0-build

and use the output to populate the %files section

Now the package can be build by running:

rpmbuild -ba ~/build/SPECS/moo-1.0.spec

building with modules

Sometimes it’s helpful to split one package into multiple modules. Here’s an example .spec file for a library, it will produce two packages: libmoo (with the shared objects provided by the library) and libmoo-devel (with all headers and static libraries)

#                  _____________________________
#         (__)    /                             \
#         (oo)   ( This is an example .spec file )
#  /-------\/  --'\_____________________________/
# / |     ||
#*  ||----||
#   ^^    ^^
####
# package preamble
# one line description of the package
Summary: An Example library
Name: libmoo
Version: 1.0
# this marks the internal release version: libmoo-1.0-1.666.x86_64.rpm
Release: 1.666
License: BSD
# group you want your package in, mostly for GUI package browsers
# some example groups used by vendors:
# http://www.rpmfind.net/linux/RPM/Groups.html
Group: Development/Libraries
# your name for example
Packager:
#
Source: http://full.url.to.the/package/%{name}-%{version}.tar.gz
# list all your patches here:
Patch0: moo-1.0.etc.patch
Patch1: moo-1.0.documentation.patch
# list all packages required to build this package
BuildRequires: openssl-devel
Provides:
# list all packages that conflict with this one:
Conflicts: bse
BuildRoot: %{_tmppath}/%{name}-%{version}-build

####
# changes in the preamble for libmoo-devel package
%package devel
Summary: libmoo development files and headers
Group: Development/Libraries
# -devel requires the main package
Requires: %name = %version

####
# full length description
%description

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc eros elit,
pretium eu vestibulum vel, blandit vel nisl. Fusce mattis volutpat
pellentesque. Etiam sit amet magna eget dui faucibus rutrum. Aliquam a ligula
erat. Proin metus tortor, sollicitudin et accumsan quis, hendrerit non leo.
Curabitur egestas neque sed nulla vulputate vel bibendum sapien tristique.
Vivamus malesuada, magna et semper iaculis, magna lorem adipiscing erat, vel
euismod enim nulla vel tortor. Vestibulum accumsan placerat sagittis. Sed
commodo pretium lectus et dignissim. Ut nec orci tellus.

####
# full description of the -devel package
%description devel

static libraries and headers for libmoo 

#####
# this prepares a fresh build directory in ~/build/BUILD, useful macros here
# are:
# %setup - cleans any previous builds and untargzips the source
# %patch - applies patches
# any other commands here are executed as standard sh commands
%prep

%setup
%patch
%patch1

./configure --enable-something --with-something-else

#####
# this tells rpmbuild how to build your package, rpmbuild runs it as a sh
# script
%build
make

#####
# all the steps necessary to install your package into $RPM_BUILD_ROOT
# first step is to clear $RPM_BUILD_ROOT
%install
[ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
#install all files under RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT

# now you can remove uneeded stuff
rm -f $RPM_BUILD_ROOT{_prefix}/sbin/rc.moo

#####
# NOTE: this section is optional
# commands run just before the package is installed
%pre
/usr/sbin/useradd -c "moo user" -r -s /bin/false -u 666 -d / moo 2> /dev/null
|| :

#####
# NOTE: this section is optional
# commands run before uninstalling the software
%preun
/sbin/service moo stop > /dev/null 2>&1
/sbin/chkconfig --del moo

#####
# NOTE: this section is optional
# commands run after installing the package
%post
/sbin/ldconfi

#####
# NOTE: this section is optional
# commands run after unistalling the package
%postun
/sbin/ldconfig

#####
# list all the files that are part of the package. If a file is not in the
# list rpmbuild won't put it in the package
# see below on how to automate the process of creating this list.
# some useful macros here:
# %doc filename - installs filename into /usr/share/doc/moo-1.0/
# %doc /path/to/filename - installs filename into /path/to/filename and marks
# it as being documentation
# %config /etc/config_file - similar for configuration files
# %attr(mode, user, group) file - lets you specify file attributes applied
# during installation, use - if you want to use defaults
%files
%defattr(-,root,root,0755)
%attr(755,root,root) %_prefix/lib/lib*.so.*
%doc INSTALL ChangeLog

#####
# separate list of files for the -devel modules
%files devel
%defattr(-,root,root,0755)
%attr(755,root,root) %_prefix/lib/lib*.so
%attr(644,root,root) %_prefix/lib/*.a
#exclude *.la files
%exclude %_prefix/lib/*.la

#####
# document changes between package releases
%changelog
* Wed Jul 8 2009 Your Name
- another version of the package

* Mon Jul 6 2009 Your Name
- initial version of the package

building the package with rpmbuild -ba libmoo-1.0.spec will produce two files:

libmoo-1.0-1.666.arch.rpm and libmoo-devel-1.0-1.666.arch.rpm

Nagios plugin template in python

admin — Wed, 29 Apr 2009 08:49:10 +0000

A template for nagios plugins I use:

#!/usr/bin/env python
import sys, getopt
nagios_codes = {‘OK’: 0, 

                ‘WARNING’: 1, 

                ‘CRITICAL’: 2,

                ‘UNKNOWN’: 3,

                ‘DEPENDENT’: 4}
def usage():

    """ returns nagios status UNKNOWN with 

        a one line usage description

        usage() calls nagios_return()

    """

    nagios_return(‘UNKNOWN’, 

            "usage: {0} -h host".format(sys.argv[0]))
def nagios_return(code, response):

    """ prints the response message

        and exits the script with one

        of the defined exit codes

        DOES NOT RETURN 

    """

    print code + ": " + response

    sys.exit(nagios_codes[code])
def check_condition(host):

    """ a dummy check

        doesn’t really check anything 

    """

    return {"code": "OK", "message": host + " ok"}
def main():

    """ example options processing

        here we’re expecting 1 option "-h"

        with a parameter

    """

    if len(sys.argv) < 2:

        usage()
    try:

        opts, args = getopt.getopt(sys.argv[1:], "h:")

    except getopt.GetoptError, err:

        usage()
    for o, value in opts:

        if o == "-h":

            host = value

        else:

            usage()
    result = check_condition(host)

    nagios_return(result[‘code’], result[‘message’])
if __name__ == "__main__":

    main()

fixing sound on ubuntu 8.10 intrepid and dell dimension e520

admin — Fri, 30 Jan 2009 14:52:05 +0000

First check what version of the sound card you have in your dell:

# grep ‘Codec’ /proc/asound/card0/codec#*

the command should return with “Codec: SigmaTel STAC9227″. If that’s the case add this line to your /etc/modprobe.d/alsa-base file:

options snd-hda-intel model=dell-3stack

and reboot.

missing eth0 interface when moving between vmware hosts

admin — Wed, 10 Dec 2008 17:19:20 +0000

This problem only happens when one uses udev to manage device node files and names of the network interfaces present in the system.

What can happen is that the eth0 interface present when running the server under one vmware instance can become missing after moving to another vmware host. Instead, the system will create a new eth interface – eth1.

This is because udev caches network attributes to interface name assignments to keep network interface names consistent between reboots. The problem is network card parameters (MAC address) can change with different instances of vmware. If the cached version doesn’t match the actual state udev creates a new device -> name assignment.

To fix this in debian and debian-like distribution just delete this file: /etc/udev/rules.d/z25_persistent-net.rules

The file will be generated again after rebooting (or restarting udev).

recovering deleted files on an ext3 file system

admin — Fri, 21 Nov 2008 16:49:22 +0000

To my surprise this is actually possible. Moreover, it’s much easier than restoring files from ext2 partitions, where you have tools like foremost and photorec. With these tools you can restore contents of your files by looking for certain patterns in raw disk data. Restoring directory structure and file names isn’t that easy. The situation is a bit different with ext3 – all thanks to this great tool – ext3grep.

All one needs to restore deleted data is to unmount your hdd as soon as possible (or remount it ro) and take a copy of it using dd.

Download ext3grep from http://code.google.com/p/ext3grep/ , untargzip it and compile. The easies way to use it I’ve found is to give it a date to undelete all files removed after.

ext3grep /dev/sdb1 –restore-all –after=1226937993

It will create a RESTORED_FILES directory and create all recovered files and directores there. It does take some time to do that, but after all it’s a bit complicated process A very interesting and detailed document about the internals of ext3, file recovery and ext3grep (with more examples) is here.