Combining the basic installation obtained through the ISO image of a CentOS 6.5 Linux machine published in the Open-DAI website with modules published on the Open-DAI GitHub repository you can create the master machine. In the figure below is shown the installation pipeline.


In the following sections the automatic process of the master machine configuration is explained in details.

Puppet Master kickstart

The first stage of the Puppet Master VM creation is based on the ks.cfg configuration file available on GitHub or within the master machine ISO. With kickstart automated installation method, the administrator defines a basic configuration of the system, setting up the root user, the timezone, the network interface, and installing some packages such as openssh, wget, curl and acpid.

During this stage the /etc/odailock.lck file is generated in order to prevent that the initial set up scripts are executed again in case of virtual machine reboot.

After the execution of initial scripts, the configuration of the Open-DAI Puppet Master machine begins with the download of the bash script available on GitHub at:

Puppet Master installation

The second stage involves components required for specific features of the Puppet Master VM in the Open-DAI architecture.

The start-opendai function changes permissions of ssh keys, adds necessary repositories to install Puppet, MCollective, Zabbix and other core components, and then retrieve $userdata through the full-featured RESTful API of CloudStack. Below are available script lines that enable the latter operation:

log "Cloudstack stuff"
#First cloudstack recover virtual router IP
server_ip=$(cat /var/lib/dhclient/dhclient-eth0.leases | grep dhcp-server-identifier | tail -1| awk '{print $NF}' | tr '\;' ' ')
log "Cloudstsack virtual router" $server_ip2
userdata=$(curl http://$server_ip2/latest/user-data)
log "userdata:" $userdata

#transform userdata in env vars
eval $userdata

$userdata is a specific feature of the Open-DAI project that consists in a data structure associated with a CloudStack guest virtual machine that can be:

  1. used to set up the system of the virtual machine itself;
  2. loaded into a collection of custom Puppet facts.

$userdata is formatted as key/value pairs (one pair per line), therefore we can transform this data structure in a list of environment variables. For this reason we assume that in the script lines below $timezone is retrieved from $userdata and used to set up the time zone of the virtual machine:

# could be from Cloudstack or have to have a default value
if [[ -z "$timezone" ]]; then timezone='Rome'; fi

Loading $userdata into custom Puppet facts includes a different mechanism. “Facts” are a collection of information about the system, like operating system, Linux distribution, or MAC address, and Facter is a cross-platform library for retrieving these system facts.

Before requesting a catalog from the Puppet Master, the Puppet Node will run Facter to collect information about the system. The Puppet Master receives this information as facts, that can be used anywhere in the Puppet manifests as pre-set variables. Exploiting facts, Puppet decides, for instance, which tools to install or which configurations to apply on a specific Linux distribution.

For catalogs distribution Puppet can use both the built-in core facts and any custom facts in the manifests. As will be explained in the section “Puppet Node and the virtual machine role assignment”, a custom fact defined $role is used to understand the role of a virtual machine in the cloud environment with the aim to install appropriate tools.

At this stage some components are installed and configured. In details:

  • Network Time Protocol (NTP)
  • Fail2ban for security
  • Augeas
  • Apache
  • Postgresql (necessary for PuppetDB)
  • PHP

Then, the configuration of Puppet, PuppetDB, and MCollective begins. In this phase the script sets an autosign mechanism to automatically authenticate each Puppet Node that requests a specific catalog in the cloud environment. This operation is enabled by the following lines:

#create autosign.conf in /etc/puppet/
echo -e "*.$(if [[ -z "$(facter domain)" ]]; then echo "*"; else echo $(facter domain);fi)" > /etc/puppet/autosign.conf
log "edited autosign.conf"

# append in file /etc/puppet/auth.conf
############## GOES BEFORE last 2 rows
echo -e "path /facts\nauth any\nmethod find, search\nallow *" >> /etc/puppet/auth.conf
log "appended stuff in puppet/auth.conf"

Puppet environment

In order to set up Puppet environment, r10k_install.pp file is retrieved from GitHub at:

Environments are isolated groups of Puppet Nodes. A Puppet Master can serve each environment with completely different main manifests and module paths. In the Open-DAI architecture, the environment setting consists of two operation:

  1. download and copy in the Puppet Master directory the manifests to create and configures all the nodes of the cloud environment;
  2. download and copy the Hiera files, that provide a hierarchical representation of each node configuration.

The Puppet Master environment includes a “base” module that allows a dynamic creation of the virtual machines of the Open-DAI platform. Based on its specific role (defined in $role variable in case of Open-DAI or in the hostname in case of cloud environments that are not able to define and send the role attribute), the virtual machine receives a specific configuration.

As obvious, in order to automatically complete the initial set up of the Puppet Master VM, each Open-DAI installation uses default passwords. For these reasons a configuration script for changing the system passwords is provided and and can be launched during this stage. This configuration script is available on GitHub at: