Configuring and managing cloud-init for RHEL 8

1. Select the optimal cloud provider for your use case, based on your requirements and the current offer on the market.

   The cloud providers currently certified for running RHEL instances are:

   • Amazon Web Services (AWS)

     • For more information, see Deploying RHEL 8 on Amazon Web Services.

   • Google Cloud Platform (GCP)

     • For more information, see Deploying RHEL 8 on Google Cloud Platform.

   • Microsoft Azure

     • For more information, see Deploying RHEL 8 on Microsoft Azure.
2. Create a RHEL cloud instance on your chosen cloud platform. For more information, see Methods for creating RHEL cloud instances.
3. To keep your RHEL deployment up-to-date, use Red Hat Update Infrastructure (RHUI).

1. Generator stage: By using the systemd service, this phase determines whether to run cloud-init utility at the time of boot.
2. Local stage: cloud-init searches local datasources and applies network configuration, including the DHCP-based fallback mechanism.
3. Network stage: cloud-init processes user data by running modules listed under cloud_init_modules in the /etc/cloud/cloud.cfg file. You can add, remove, enable, or disable modules in the cloud_init_modules section.
4. Config stage: cloud-init runs modules listed under cloud_config_modules section in the /etc/cloud/cloud.cfg file. You can add, remove, enable, or disable modules in the cloud_config_modules section.
5. Final stage: cloud-init runs modules and configurations included in the cloud_final_modules section of the /etc/cloud/cloud.cfg file. It can include the installation of specific packages, as well as triggering configuration management plug-ins and user-defined scripts. You can add, remove, enable, or disable modules in the cloud_final_modules section.

1. The network phase (cloud_init_modules)
2. The configuration phase (cloud_config_modules)
3. The final phase (cloud_final_modules)

Procedure

1. Create a directory named cloudinitiso and set is as your working directory:

   $ mkdir cloudinitiso
   $ cd cloudinitiso

2. Create the meta-data file and add the following information:

   instance-id: citest
   local-hostname: citest-1

3. Create the user-data file and add the following information:

   #cloud-config
   password: cilogon
   chpasswd: {expire: False}
   ssh_pwauth: True
   ssh_authorized_keys:
     - ssh-rsa AAA...fhHQ== sample@redhat.com

   Note

   The last line of the user-data file references an SSH public key. Find your SSH public keys in ~/.ssh/id_rsa.pub. When trying this sample procedure, modify the line to include one of your public keys.

4. Use the genisoimage command to create an ISO image that includes user-data and meta-data:

   # genisoimage -output ciiso.iso -volid cidata -joliet -rock user-data meta-data
   
   I: -input-charset not specified, using utf-8 (detected in locale settings)
   Total translation table size: 0
   Total rockridge attributes bytes: 331
   Total directory bytes: 0
   Path table size(bytes): 10
   Max brk space used 0
   183 extents written (0 MB)

5. Download a KVM Guest Image from the Red Hat Customer Portal to the /var/lib/libvirt/images directory.

6. Create a new VM from the KVM Guest Image using the virt-install utility and attach the downloaded image to the existing image:

   # virt-install \
       --memory 4096 \
       --vcpus 4 \
       --name mytestcivm \
       --disk /var/lib/libvirt/images/rhel-8.1-x86_64-kvm.qcow2,device=disk,bus=virtio,format=qcow2 \
       --disk /home/sample/cloudinitiso/ciiso.iso,device=cdrom \
       --os-type Linux \
       --os-variant rhel8.0 \
       --virt-type kvm \
       --graphics none \
       --import

7. Log on to your image with username cloud-user and password cilogon:

   citest-1 login: cloud-user
   Password:
   [cloud-user@citest-1 ~]$

Procedure

1. Depending on the requirements of your datasource, edit the user-data file or add the following directive to the cloud.cfg.d directory:

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Change the line chpasswd: {expire: False} to chpasswd: {expire: True}:

   #cloud-config
   password: mypassword
   chpasswd: {expire: True}
   ssh_pwauth: True
   ssh_authorized_keys:
     - ssh-rsa AAA...SDvz user1@yourdomain.com
     - ssh-rsa AAB...QTuo user2@yourdomain.com

   This works to expire the password because password and chpasswd operate on the default user unless you indicate otherwise.

   Note

   This is a global setting. When you set chpasswd to True, all users you create need to change their passwords when they log in.

Procedure

1. Depending on the requirements of your datasource, edit the user-data file or add the following directive to the cloud.cfg.d directory:

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Add the line user: <username>, replacing <username> with the new default user name:

   #cloud-config
   user: username
   password: mypassword
   chpasswd: {expire: False}
   ssh_pwauth: True
   ssh_authorized_keys:
     - ssh-rsa AAA...SDvz user1@yourdomain.com
     - ssh-rsa AAB...QTuo user2@yourdomain.com

Procedure

1. Depending on the requirements of your datasource, edit the user-data file or add the following directive to the cloud.cfg.d directory:

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Create a user list in the chpasswd section of the file:

   Note

   White space is significant. Do not include white space before or after the colon in your user list. If you include white space, the password is set with a space in it.

   #cloud-config
   ssh_pwauth: True
   ssh_authorized_keys:
     - ssh-rsa AAA...SDvz user1@yourdomain.com
     - ssh-rsa AAB...QTuo user2@yourdomain.com
   chpasswd:
     list: |
        root:myrootpassword
        cloud-user:mypassword
     expire: False

   Note

   If you use this method to set the user password, you must set all passwords in this section.

Procedure

1. Depending on the requirements of your datasource, edit the user-data file or add the following directive to the cloud.cfg.d directory:

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Add or modify the users section to add users.

   • If you want cloud-user to be the default user created along with the other users you specify, ensure that you add default as the first entry in the section. If it is not the first entry, cloud-user is not created.

   • By default, users are labeled as unconfined_u if there is not an selinux-user value.

     #cloud-config
     users:
       - default
       - name: user2
         gecos: User N. Ame
         selinux-user: staff_u
         groups: users,wheel
         ssh_pwauth: True
         ssh_authorized_keys:
           - ssh-rsa AA..vz user@domain.com
     chpasswd:
       list: |
         root:password
         cloud-user:mypassword
         user2:mypassword2
       expire: False

     Note
     • The example places the user user2 into two groups, users and wheel.

Procedure

1. Depending on the requirements of your datasource, edit the user-data file or add the following directive to the cloud.cfg.d directory:

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Add the sections for bootcmd and runcmd; include commands you want cloud-init to execute.

   #cloud-config
   users:
     - default
     - name: user2
       gecos: User N. Ame
       groups: users
   chpasswd:
     list: |
       root:password
       fedora:myfedpassword
       user2:mypassword2
     expire: False
   bootcmd:
    - echo New MOTD >> /etc/motd
   runcmd:
    - echo New MOTD2 >> /etc/motd

Procedure

1. Depending on the requirements of your datasource, edit the user-data file or add the following directive to the cloud.cfg.d directory:

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Add a sudo entry and specify the user access. For example, sudo: ALL=(ALL) NOPASSWD:ALL allows a user unrestricted user access.

3. Add a groups entry and specify the groups that include the user:

   #cloud-config
   users:
     - default
     - name: user2
       gecos: User D. Two
       sudo: ["ALL=(ALL) NOPASSWD:ALL"]
       groups: wheel,adm,systemd-journal
       ssh_pwauth: True
       ssh_authorized_keys:
         - ssh-rsa AA...vz user@domain.com
   chpasswd:
     list: |
       root:password
       cloud-user:mypassword
       user2:mypassword2
     expire: False

1. Depending on the requirements of your datasource, edit the user-data file or add the following directive to the cloud.cfg.d directory:

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Add a network-interfaces section.

   network:
     version: 1
     config:
       - type: physical
         name: eth0
         subnets:
           - type: static
             address: 192.0.2.1/24
             gateway: 192.0.2.254

Procedure

1. Depending on the requirements of your datasource, edit the user-data file or add the following directive to the cloud.cfg.d directory:

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Create an entry for the user root in the users section.

   The simple example that follows includes a users section with only the name option.

   users:
     - name: root
   chpasswd:
     list: |
       root:password
     expire: False

3. Optionally, set up SSH keys for the root user.

   users:
     - name: root
       ssh_pwauth: True
       ssh_authorized_keys:
         - ssh-rsa AA..vz user@domain.com

Procedure

1. Depending on the requirements of your datasource, edit the user-data file or add the following directive to the cloud.cfg.d directory:

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Add or modify the write_files module to include the path to the container-storage-setup utility.

   The following example sets the size of the root logical volume to 6 GB rather than the default 3 GB.

   write_files:
     - path: /etc/sysconfig/docker-storage-setup
       permissions: 0644
       owner: root
       content: |
       ROOT_SIZE=6G

   Note

   Prior to RHEL 7.4, container-storage-setup was called docker-storage-setup. If you are using OverlayFS for storage, as of RHEL 7.4 you can now use that type of file system with SELinux in enforcing mode.

Procedure

1. Depending on the requirements of your datasource, edit the meta-data file. You can also add the following directive to the cloud.cfg file or the cloud.cfg.d directory:
2. Add the locale directive, specifying the location. The following sample sets the locale to ja_JP (Japan) with UTF-8 encoding.

Procedure

1. Edit the /etc/cloud/cloud.cfg file, for example:

   # vi /etc/cloud/cloud.cfg

2. Comment out or remove the configuration that you do not want cloud-init to update when you restore your instance. For example, to avoid updating the SSH key file, remove -ssh from the cloud_init_modules section.

   cloud_init_modules:
    - disk_setup
    - migrator
    - bootcmd
    - write-files
    - growpart
    - resizefs
    - set_hostname
    - update_hostname
    - update_etc_hosts
    - rsyslog
    - users-groups
    # - ssh

Procedure

1. Log in to your VM.
2. Add or change directives, for example, modify the cloud.cfg file in the /etc/cloud directory or add directives to the /etc/cloud/cloud.cfg.d directory.

3. Run the cloud-init clean command to clean directories so that cloud-init can rerun. You can also run the following commands as root to clean the VM:

   rm -Rf /var/lib/cloud/instances/
   rm -Rf /var/lib/cloud/instance
   rm -Rf /var/lib/cloud/data/

   Note

   You can save the cleaned image as a new image and use that image for multiple VMs. The new VMs will use updated cloud-init configuration to run cloud-init.

4. Rerun cloud-init or reboot the VM.

   cloud-init reruns, implementing the configuration changes you made.

Procedure

1. Create and launch an instance for the OpenStack Platform. For information about creating instances for OpenStack, see Creating an instance. In this example, the virtual machine (VM) includes cloud-init, which runs upon boot of the VM.
2. Add or change directives. For example, modify the user-data.file file that is stored on the OpenStack HTTP server.

3. Clean the virtual machine. Run the following commands as root.

   # rm -rf /etc/resolv.conf /run/cloud-init
   # userdel -rf cloud-user
   # hostnamectl set-hostname localhost.localdomain
   # rm /etc/NetworkManager/conf.d/99-cloud-init.conf

   Note

   You can save the cleaned image as a new image and use that image for multiple virtual machines. The new virtual machines run cloud-init, using your updated cloud-init configuration.

4. Rerun cloud-init or reboot the virtual machine.

   Cloud-init reruns, implementing the configuration changes you made.

Procedure

1. Review the cloud-init configuration files:

   1. Examine the /etc/cloud/cloud.cfg configuration file. Check which modules are included under cloud_init_modules, cloud_config_modules, and cloud_final_modules.
   2. Check directives (*.cfg files) in the /etc/cloud/cloud.cfg.d directory.

2. Review the /var/log/cloud-init.log and /var/log/cloud-init-output.log files for details on a specific issue. For example, if the root partition was not automatically extended, check log messages for the growpart utility. If the file system was not extended, check log messages for resizefs. For example:

   # grep resizefs /var/log/cloud-init.log

   Note

   growpart does not support LVM. If your root partition is based in LVM, the root partition is not automatically extended upon first boot.

3. Rerun cloud-init commands as root:

   1. Rerun cloud-init with only the init modules:

      # /usr/bin/cloud-init -d init

   2. Rerun cloud-init with all modules in the configuration:

      # /usr/bin/cloud-init -d modules

   3. Delete the cloud-init cache and force cloud-init to run after boot:

      # rm -rf /var/lib/cloud/ && /usr/bin/cloud-init -d init

   4. Clean directories and simulate a clean instance:

      # rm -rf /var/lib/cloud/instances/
      # rm -rf /var/lib/cloud/instance
      # rm -rf /var/lib/cloud/data/
      # reboot

   5. Rerun the cloud-init utility:

      # cloud-init init --local
      # cloud-init init