This is part #5 of the Razor series. In the last post we looked at Policies, Tags and touched slightly on Installers. In this post we will go more into detail into what exactly the installer does.

1. Installing Razor - Yes the New Version..
2. Razor - DHCP and TFTP
3. Installing the Razor client and creating a repository
4. Installers, Policies and Tags
5. Razor - What Lies Within the installer?
6. Installing ESXi with Razor

The installers are located in the /opt/razor-server/installers directory. In this directory you will find a yaml file and folder - both with the same name.

During this post - we will go through 2 separate installers, the Redhat one and the ESXi installer. The yaml file contains the following

The contents are quite self-explanatory, os_version, label, description and lastly the boot_sequence. The boot_sequence is the set of instructions that will be passed to the microkernel, the first time (1:) - boot to the installer (boot_install), and on the other boots (default:), boot to the local disk (boot_local) and bypass the microkernel.

The folder contains the following files (remember the os_version - therefore all the files are under the 6 subfolder).

These files are the steps that will be executed, and as we saw in the redhat.yaml file the first boot will go to a boot_install.erb

This file holds the correct boot parameters for booting into the installation - including the contents of the kernel_args template which we will see shortly. There is also information echoed out to the screen such as the Installer Label, the node's url, and the repository's url.

The kernel_args - has the pointer to the kickstart.erb file and the instruction to boot from the network device.

The kickstart.erb file is mostly a standard kickstart file - with a few variables.

• url=<%= repo_url %> - will be translated to the url for the repository.
• rootpw <%= node.root_password %> - will be the password that you defined when you created the policy
• network --hostname <%= node.hostname %> - will be the hostname according to the pattern that you defined in the policy.

After the rest of the standard kickstart contents (in the %post section), there is some more razor stuff.

• %post --log=/var/log/razor.log - will log the rest of the process to /var/log/razor.log
• curl -s -o /root/razor_postinstall.sh <%= file_url("post_install") %> - the node retrieves the post_install file and saves it to /root/razor_postinstall.sh
• # Run razor_postinstall.sh on next boot via rc.local - this section is self explanatory.
• curl -s <%= stage_done_url("kickstart") %> - here a API call is sent to razor to announce that kickstart is finished - and therefore the subsequent boots will go to local disk (as was defined in the redhat.yaml file)

The post_install.erb (the one that was saved to /root/razor_postinstall.sh) has a few more operations that are performed.

• # Wait for network to come up when using NetworkManager - waits for the network to come up.
• <%= render_template("set_hostname") %> - is the piece of code that sets the hostname.
• <%= render_template("store_ip") %> - is the code that stores the IP address and reports back to razor server.
• <%= render_template("os_complete") %> - sends an API call to the Razor server to notify that the OS installation is now complete.

The boot_local, set_hostname, store_ip and the os_complete pieces of code are located in the
/opt/razor-server/installers/common/ directory.

The boot_local.erb has the instructions for the OS to boot to a local disk.

The set_hostname.erb has all regex magic that implants the hostname
(from the <%= node.hostname %> variable) into /etc/hosts.

The store_ip.erb - retrieves the node's IP address and then reports back to the Razor server.

The os_complete.erb updates the MOTD on the node, and removes the lines that razor added to the /etc/rc.d/rc.local file. It then goes back to the Razor server and invokes the broker.

If we were to look at the ESXi installation we would see something similar.

The contents of vmware_esxi.yaml file - the same format as before.

The contents of the vmware_esxi folder is slightly different.

The boot_install.erb file here holds the instructions on how to boot the ESXi kernel - which is slightly different than that of a traditional Linux.

The pxelinux_esxi.cfg.erb is the file that was called from the previous step

• KERNEL <%= repo_url('/mboot.c32') %> - the standard ESXi boot menu.
• APPEND -c <%= file_url('boot.cfg') %> - add in the boot.cfg file.

The boot.cfg.erb file modifies the boot string to point to the kickstart file on the Razor server.

The ks.cfg.erb file has the kickstart instructions for ESXi - with great thanks to William Lam

• rootpw --iscrypted <%= … %> - decodes the password that was defined in the policy.
• wget <%= stage_done_url("kickstart") %> - here an API call is sent to the Razor server to notify that the kickstart process has completed and that the default boot process should now be used.

The ks.cfg file can be customized according to your needs of course.

A few things that need to emphasized about the current ESXi kickstart process - it has some limitations.

1. The network configuration is DHCP only. There is no built in mechanism to accommodate static IP addresses at the present time. I will say that there is a method - which I will explain in a future post.
2. Hostname configuration - is not covered either, that same future post will explain how to deal with this problem as well.
3. There is no additional reporting on the node's state - besides the fact that kickstart has completed.

That is enough for this part. Next we will look at a full deployment.