linux-template

Creating a Linux Template

Linux Templates should be prepared using this documentation in order to prepare your linux Instances for Template deployment. For ease of documentation, the Instance which you are configuring the Template on will be referred to as "Main Template". The final product, as created and usable for deployment in Zergaw CloudStack, will be referred as "Final Template". This guide will cover cloud-init setup and scripted setups where available. It is assumed that openssh-server is installed during installation.

An overview of the procedure is as follow:

Upload your Linux ISO. For more information, see "Adding an ISO".
Create an Instance with this ISO. For more information, see "Creating Instances".
Prepare the Linux Instance
Create a Template from the Instance. For more information, see "Creating a Template from an Existing Instance".

System preparation for Linux

The following steps will provide basic Linux installation for templating of Centos and Ubuntu.

Update OS

The next step update the packages on the Main Template.: CentOS

yum update -y
reboot

~ Ubuntu

sudo -i
apt-get update
apt-get upgrade -y
apt-get install -y acpid ntp
reboot

Networking

Set Template Network interface configuration to DHCP so Cloudstack infrastructure can assign one on boot.

For CentOS, it is mandatory to take unique identification out of the interface configuration file /etc/sysconfig/network-scripts/ifcfg-eth0. Any entries starting with <VALUE> should be removed.

~ Centos
```
echo "DEVICE=eth0
TYPE=Ethernet
BOOTPROTO=dhcp
ONBOOT=yes" > /etc/sysconfig/network-scripts/ifcfg-eth0
```
Hostname Management

Set a generic name to the Template Instance during installation, this will ensure components such as LVM do not appear unique to a machine. It is recommended that the name of "localhost" is used for installation.
```
hostname localhost
echo "localhost" > /etc/hostname
```
Password management

It is a good practice to remove any non root Users that come with the OS (such as ones created during the Ubuntu installation). First ensure the root user Account is enabled by giving it a password and then login as root to continue.

Once logged in as root, any custom User can be removed.
```
deluser myuser --remove-home
```
User password management and reset capabilities in GUI are available
with:
- Cloud-init integration
- Adding Password Management to Your Templates /Legacy for non systemd systems only/
SSH keys management

Cloudstack can create key pair and push certificates to Instances. This feature is available with:
- Cloud-init integration
- Implementing a SSH-Key bash script
Partition management

Volumes can autorextend after reboot when partition is extended in the GUI. This feature is possible with Cloud-init integration.
User-data

Cloudstack can push user-data during Instance creation. This feature is possible with Cloud-init integration.
Template cleanup

Cleanup steps should be run when all Main Template configuration is
done and just before the shutdown step. After shut down Final
Template should be created. If the Main Template is started or
rebooted before Final Template creation all cleanup steps have to be
rerun.
- Remove the udev persistent device rules
  
  This step removes information unique to the Main Template such as Network MAC addresses, lease files and CD block devices, the files are automatically generated on next boot.
  
  CentOS
```
rm -f /etc/udev/rules.d/70*
rm -f /var/lib/dhclient/*
```
  ~ Ubuntu
```
rm -f /etc/udev/rules.d/70*
rm -f /var/lib/dhcp/dhclient.*
```
- Remove SSH Keys
  
  This step is to ensure all Templated Instances do not have the same SSH keys, which would decrease the security of the machines dramatically.
```
rm -f /etc/ssh/*key*
```
- Cleaning log files
  
  It is good practice to remove old logs from the Main Template.
```
cat /dev/null > /var/log/audit/audit.log 2>/dev/null
cat /dev/null > /var/log/wtmp 2>/dev/null
logrotate -f /etc/logrotate.conf 2>/dev/null
rm -f /var/log/*-* /var/log/*.gz 2>/dev/null
```
- Set User password to expire
  
  This step forces the User to change the password of the Instance after the Template has been deployed.
```
passwd --expire root
```
- Clearing User History
  
  The next step clears the bash commands you have just run.
```
history -c
unset HISTFILE
```
Shutdown the Instance

Shutdown the Main Template.
```
halt -p
```
Create the Template!

You are now ready to create the Final Template, for more information see creating-a-template-from-an-existing-virtual-machine

Linux with Cloud-init

These features can be implemented in “Linux Template creation process”. where they are executed just before the Template cleanup step.

Install and configure cloud-init

Install cloud-init and mentioned auxiliary packages.

CentOS
```
yum install -y cloud-init wget
```
~ Ubuntu
```
apt-get install -y cloud-init wget
```
Configure cloud-init to detect Cloudstack data source during runtime.

Cloud-init data sources can be specified in /etc/cloud/cloud.cfg.d/ directory. Add the following config in /etc/cloud/cloud.cfg.d/99_cloudstack.cfg.
```
datasource_list: [ ConfigDrive, CloudStack, None ]
datasource:
  CloudStack: {}
  None: {}
```
Password management

Zergaw Cloudstack integration with cloud-init set-passwords module will enable the platform to set a password for each Instance created from the Main Template. Additionally it will allow to reset the user password through the GUI.
- Enable set_passwords module on every boot
  
  By default the set-passwords module runs only on first boot of the Instance, change that to run on every boot.
```
sudo sed -i s/" - set[_|-]passwords"/" - [set_passwords, always]"/g /etc/cloud/cloud.cfg
```
- Specify the managed user
  
  Zergaw Cloudstack will create the user, set a password and reset it when requested. To do that set the following configuration in /etc/cloud/cloud.cfg.d/80_user.cfg
```
system_info:
  default_user:
    name: cloud-user
    lock_passwd: false              # disable user password login - true/false
    sudo: [\"ALL=(ALL) ALL\"]       # User permissions
disable_root: 0                     # root remote login is 0 - enabled, 1 - disabled
ssh_pwauth: 1                           # password login is 0 - disabled, 1- enabled
```
SSH keys management

Cloud-init ssh module can automatically install new SSH keys when set or reset from the UI.
By default the module runs once during Instance creation and will fetch Cloudstack keys without any additional configuration.
To enable Cloudstack reset SSH keys feature configure cloud-init ssh module to run on every boot.
```
sudo sed -i s/" - ssh$"/" - [ssh, always]"/g /etc/cloud/cloud.cfg
```

WARNING

If the cloud-init ssh module is set to run every boot, it will regenerate the certificate fingerprint of the host. This will cause a warning to anyone that logs in the system and also bring trouble to anyone trying to automate ssh access.

Disable cloud-init regenerating host certificates on boot. If Template certificates are deleted they will be regenerated by the OS on instance first boot.

echo "ssh_deletekeys: false" > /etc/cloud/cloud.cfg.d/49_hostkeys.cfg

Note that if this instance is moved or snapshotted, it will be vulnerable to man-in-the-middle attacks if the behavior is not re-enabled first.

Partition management

Cloud-init can detect and resize one or more existing partitions automatically after reboot. This guide will cover root partition and volume.
First install the Growpart module as it is not shipped with cloud-init.

~ Centos
```
yum install cloud-utils-growpart -y
```
~ Ubuntu
```
apt-get install cloud-initramfs-growroot -y
```
- Detect and extend MBR partitions
  
  Locate the root partition.
  
  NOTE
  
  Root partition can differ per OS type, version and partition setup.
```
[root@localhost ~]# lvs
LV   VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
root centos -wi-ao---- <17.00g
swap centos -wi-ao----   2.00g
[root@localhost ~]# vgs
VG     #PV #LV #SN Attr   VSize   VFree
centos   1   2   0 wz--n- <19.00g    0
[root@localhost ~]# pvs
PV         VG     Fmt  Attr PSize   PFree
/dev/xvda2 centos lvm2 a--  <19.00g    0
```
  On the current setup root is on /dev/xvda2 partition. Define the configuration below in /etc/cloud/cloud.cfg.d/50_growpartion.cfg
```
growpart:
  mode: auto
  devices:
    - \"/dev/xvda2\"
  ignore_growroot_disabled: false
```
  Now on every boot growpart will check and extend /dev/xvda2 if there is change in size.
- Extend Physical volume, Volume group and root lvm
  
  After partition is extended the upper layers should also be resized. This can be automated with cloud-init runcmd module . Set the configuration below in /etc/cloud/cloud.cfg.d/51_extend_volume.cfg.
  
  CentOS
  CentOS root volume is /dev/centos/root if no changes are done during installation. Change the value accordingly if setup is different.
```
runcmd:
  - [ cloud-init-per, always, grow_VG, pvresize, /dev/xvda2 ]
  - [ cloud-init-per, always, grow_LV, lvresize, -l, '+100%FREE', /dev/centos/root ]
  - [ cloud-init-per, always, grow_FS, xfs_growfs, /dev/centos/root ]
```
  ~ Ubuntu
  Ubuntu 20 root volume is /dev/ubuntu-vg/ubuntu-lv if no changes are done during installation. Change the value accordingly if setup is different.
```
runcmd:
  - [ cloud-init-per, always, grow_VG, pvresize, /dev/xvda3 ]
  - [ cloud-init-per, always, grow_LV, lvresize, -l, '+100%FREE', /dev/ubuntu-vg/ubuntu-lv ]
  - [ cloud-init-per, always, grow_FS, xfs_growfs, /dev/ubuntu-vg/ubuntu-lv ]
```
  WARNING
  
  The example code above is based on XFS partition type. If ext4 partitioning is utilized replace xfs_growfs with resize2fs in the last code line.
  It is possible to also use cloud-init resize2fs module .
- Enable autoresize on every boot
  
  By default cloud-init runcmd module executes defined commands on first boot only.
  Commands will run on every boot only if both runcmd and user-scripts modules are configured to run on every boot.
```
sudo sed -i s/" - runcmd"/" - [runcmd, always]"/g /etc/cloud/cloud.cfg
sudo sed -i s/" - scripts-user"/" - [scripts-user, always]"/g /etc/cloud/cloud.cfg
```
User-data

Cloud-init can parse and execute user-data form Zergaw Cloudstack during Instance creation. This feature works as is without additional configuration.
Network configuration with ConfigDrive
Cloud-init can fetch network configuration from ConfigDrive. To enable this,
ensure network configuration is not disabled in cloud-init configuration.
```
echo -e "\nnetwork: {}" >> /etc/cloud/cloud.cfg
```
NOTE

Adding/removing nic to/from an instance or updating the ip address of a nic
will not be reflected in the instance if the instance is already running. To
do so, run cloud-init clean –machine-id -s to clean the machine id and
seed data. Then reboot the instance to apply the changes.
Cleanup

Once desired cloud-init features are implemented, clean cloud-init tracker files.
```
cloud-init clean
```
Or do it manually.
```
rm -rf /var/lib/cloud/*
```
If Password management feature is used clean /etc/sudoers from any cloud-init user setups.
```
rm -rf /etc/sudoers.d/*
```
Finalize Template

Proceed with “Linux Template creation process” continuing with Template cleanup step.

Creating a Linux Template

System preparation for Linux

Linux with Cloud-init

WARNING

NOTE

WARNING

NOTE