IMPORTANT NOTICE

This is the website of KADEPLOY VERSION 2. The LATEST version of KADEPLOY is VERSION 3, whose web site is HERE.

Kadeploy v2: Installation Next Previous Contents

2. Installation

The goal of this part is to ease the deployment system installation steps and give information about all the relevant required tools and their configuration.

2.2 Database

This part presents the database used.

Why use a database ?

kadeploy uses a database to maintain the persistance of the information about the cluster composition and current state.

The cluster composition is described via :

the nodes and their features (name, mac address and ip address)
the type of hard disk drive (size and device name) and their partitions (size and number)
the environments available (registered) for deployment with all the relative needed information (path to image, kernel path, etc.)

The cluster state is described via :

a snapshot of the cluster state that describes for each partition of each disk and on each node, the partition state, the environment installed on (if any), the number of the last deployment done on it and a brief error description about this deployment (if any)
the history of the ordered deployment with their start and end dates and their state

How does the database evolve during a deployment execution ?

During a deployment execution, its state and the one of the partition involved changes in the database.

A deployment can be in one of the following states :

waiting (for the nodes)
deploying
terminated
error

By convention, there cannot be more than one deployment waiting for nodes.

A partition can be in one of the following states :

to deploy
deploying
rebooting
deployed
error

By convention, a node involved in a running deployment cannot take part in another deployment.

The two conventions above guarantee that a node cannot be involved in two different deployments at the same time even on different disks and/or partitions.

When a deployment ends :

if it has failed on (at least) one node, it is changed to error state. When possible, a brief description of what (or when it) happened is associated to the matching partition ; the ones for which the deployment ended successfully are switched to the 'deployed' state. Thus, during a same deployment, two failures that would occur on two different partitions for different reasons would have different error messages. This enables to know if a failure is due to a global problem or to different local ones.
on the contrary, if the deployment ended successfully on all the nodes, it is changed to the 'terminated' state. The nodes are ready to be used on the new and freshly deployed environment.

How to install the database ?

It is possible to create both databases manually. All you have to do is to run the command lines below. This will create the deploy and deploy_right databases and the appropriate users with read and/or write rights.

# mysql -u root -p < tools/db/deploy_db_creation.sql

Enter password: ********

# mysql -u root -p < tools/db/rights_db_creation.sql

Enter password: ********

Next step will be to fill in the database. That can be done easily using the kaaddnode command.

How to configure access to databse ?

In order for the deployment system to access to the database, correct information e.g. database name, login and password should be filled in the configuration file for each database. See the database part in the configuration file section for further details.

2.3 `PXE/TFTP`

This part explains how to configure PXE/TFTP to control the booting process on the cluster nodes.

Hardware specifications

The nodes' hardware must be PXE compliant, this means that the BIOS/EFI should allow to boot from the ethernet card. To ensure that, you must verify that the network interface is PXE compliant.

Required software

To be able to handle PXE requests from the booting nodes, the server should have a set of running servers, which must fit minimum requirements:

DHCP server, the easiest is to use the one developped by ISC in its third version. It is available in many distributions:
- Debian dhcp3-server
- Mandrake dhcp-server and you should ensure the package release is at least 3.0
TFTP server is not a simple tftp server, it should meet the PXE standard. So you must install the tftp-hpa server also available under package forms:
- Debian tftpd-hpa is necessary, because the simple tftpd package is not sufficient (cannot handle PXE requests)
- Mandrake tftp-server rpm in a minimum 0.29-1mdk version is required to take hpa support into account

`TFTP` structure

Here is an example of a TFTP structure:

/tftpboot/
   PXEClient/
      images_grub/
      pxelinux.cfg/
      pxelinux.0
      messages
      help.txt
   X86PC/
      linux/
         images_grub/
         pxelinux.cfg/
         linux.0
         nbplinux.0
         messages
         help.txt

This directory structure and allow to respond to different PXE request schemes. The slight differences are not our business here, you should refer to the different PXE standards for this part. Let's have a short look at this structure :

```
/tftpboot/
```
is TFTP root directory ; it is the directory served by the tftp server
```
/tftpboot/PXEClient/
```
is the tftp directory for non Intel NICs (set by tftp_repository in the configuration file)
```
/tftpboot/X86PC/linux/
```
is the tftp directory for Intel NICs (set by tftp_repository_intel in the configuration file)

These two last directories contain both about the same structure :

```
images_grub/
```
that will contain kadeploy generated grub bootloaders, to allow the nodes to boot on the deployed system image (set by tftp_relative_path in the configuration file)
```
pxelinux.cfg/
```
that links every node to its kernel/initrd pair to load and boot from network, an ensure that we can remotely control the way the nodes are booting (set by pxe_rep and pxe_rep_intel in the configuration file)

These four directories (two in each tftp directory) should be writtable by the deploy user, to allow kadeploy to control the way the nodes are booting.

2.4 System Requirements

Required privileges to execute kadeploy

kadeploy requires to perform some changes on the server, to control the way the nodes are booting. Some other tools like kaconsole or kareboot needs to connect to other computers. The purpose of this part is to define all the required privileges to ensure a smooth execution of kadeploy, and secure it by avoiding unnecessary privileges.

Next Previous Contents