Puppet rspec testing and hiera

Rspec testing your puppet modules supports you in having stable and functional modules.
For a couple of weeks there is hiera integration in rspec-puppet.

OpenNebula Puppet Module

Within my actual project we implemented OpenNebula on CentOS.
The big picture is a self service where developers can startup virtual machines by themselves.

The team that worked on the OpenNebula implementation is heavily using automation for many tasks. Therefore we decided to also automate the OpenNebula installation and configuration using Puppet.

Restart puppet using puppet

If you want to ensure puppet upgrade via a puppet manifest you may run into trouble when it comes to puppet service restart.

When puppet stops the service it will kill the actual running puppet process.
Afterwards puppet does not do the start command.




You can solve this by using the following service resource:

service { 'puppet':
  enable   => true,
  ensure   => running,
  restart  => '/usr/bin/nohup /etc/init.d/puppet restart &',
}

This will fork a puppet restart command in background.

Puppet 2.7.x and Debian ruby 1.9.1

According to puppetlabs one should stay with ruby 1.8.7 when running puppet - Puppet FAQ and supported Ruby versions.

Most things work, but the CA and SSL has an issue when running ruby 1.9.x - Mixing and matching ruby versions for puppetmasterd and puppetd causes a "certificate verify failed" error.

The solution is to create a symlink in the ssl certs directory as described here.

Puppetlabs removes dynamic variable scoping

When you run puppet 2.7.12 or higher you will see a warning message, telling you that dynamic variable scope look-up will be removed in puppet 2.8.x.

What to do if you have variables defined in a node definition?

1. switch to hiera
2. write a mockup

A mockup can be build in the following way:

1. write a new module with a define
2. use the define and add the proper parameter

Why do you have to do it that ugly way? Is there no way to give the scope of a node definition?

No. Nodes do not have any scope. Scope is limited to modules and classes.

class base_variable ( stage = first, dummyvariable ) {
  case $dummyvariable {
     'live': { $truevariable = 'live' }
     'testing': { $truevariable = 'testing' }
     'testing2': { $truevariable = 'testing2' }
  }
}

In node definition you can now use the define:

node 'default.server.domain.tld' {
        include stages
        class { base_variable:
                dummyvariable => 'testing2',
        }
        include base::dev
        ....
}

Debian/GNU Squeeze with Xen 4.0 - Part 1 - base system

This is the first post regarding Debian/GNU Linux running Xen 4.0 on a new piece of hardware.

This posting will cover base OS installation:
- Preparation/Partitioning
- Base Debian/GNU Linux installation on Dom0
- Xen packages installation
- Make Xen-Kernel default for Grub2

Upcoming posts will cover the following items:

- Installation of Debian/GNU Linux as DomU
- Installation of Windows Vista as DomU (using HVM)
- Installation of OpenSolaris 11 as DomU (using HVM)
- Installation of BDS systems as DomU



Hardware description:

Motherboard: Intel DQ57TM
CPU: Intel Core i7
RAM: 16 GB RAM
HDD: 2x500 GB SATA (internal)

Cost (Aug 2010): 1400 Euro

Partitioning:

I want RAID 1 (mirroring) on both disks.
I want RAID 1 for / file system and swap
I want LVM on RAID 1 for all Virtual Guest systems

Trouble:

The normal Debian/GNU Linux Lenny (stable) network installation CD does not recognize the network interface (e10000).
Base installation required Debian /GNU Linux Squeeze testing network installation cdrom.

During Partitioning:

- Create empty DOS partition label on both disks
- Add RAID Partition for /
- Add RAID Partition for swap
- Add RAID Partition for LVM

/dev/sd[a|b]1 - 15 GB - Linux raid autodetect
/dev/sd[a|b]2 - 1 GB - Linux raid autodetect
/dev/sd[a|b]3 - 471 GB - Linux raid autodetect

Within the Debian installer I choosed to not use any partitions on my empty LVM volume.
Logical Volumes will be created after Xen setup.

Finish base installation. Do not select any default installation method in taksel.

Installation of Xen Kernel


After first boot into new installed system I installed xen-linux-system-2.6.32-5-xen-amd64:

apt-get install xen-linux-system-2.6.32-5-xen-amd64

Now I rebooted into Xen Kernel. Since Debian/GNU Linux Version squeeze uses grub2 I reviewed the list of available Kernels and wrote down the number of the Xen Kernel.

Then I added "GRUB_DEFAULT=6" into /etc/default/grub and run update-grub afterwards.

Network Configuration

Since I want my Virtual Systems to be available from remote I decided to use Bridging on the network interface.

In /etc/network/interfaces I setup eth0 as bridge slave.
Then I added a new bridge interface with name xenbr0.

In /etc/xen/xend-config.spi I disabled the bridge-network section by giving /bin/true as parameter.

KDE 4.2 on Debian/GNU Lenny

I was eagerly waiting for KDE 4.2.

Compared to Versoin 4.1 the new version seems far more stable.

The only "semi-official" way to install KDE 4.2 on Lenny is by putting experimental in your sources list and make use of apt-pinning.

Personally I do not like apt-pinning.

Therefor I made a backport.


Put the following into your source.list:

   deb http://www.debian-desktop.org/pub/linux/kde42 lenny kde42


If you like to review the sources:

   deb-src http://www.debian-desktop.org/pub/linux/kde42 lenny kde42

The packages are - yet - unsigned.
Hopefully I will have some time within the next weeks to also sign the packages.