Public Cloud Requirements

This section provides the requirements for installing Uyuni on public cloud infrastructure. We have tested these instructions on Amazon EC2, Google Compute Engine, and Microsoft Azure, but they should work on other providers as well, with some variation.

Before you begin, here are some considerations:

  • The Uyuni setup procedure performs a forward-confirmed reverse DNS lookup. This must succeed in order for the setup procedure to complete and for Uyuni to operate as expected. It is important to perform hostname and IP configuration before you set up Uyuni.

  • Uyuni Server and Proxy instances need to run in a network configuration that provides you control over DNS entries, but cannot be accessed from the internet at large.

  • Within this network configuration DNS resolution must be provided: hostname -f must return the fully qualified domain name (FQDN).

  • DNS resolution is also important for connecting clients.

  • DNS is dependent on the cloud framework you choose. Refer to the cloud provider documentation for detailed instructions.

  • We recommend that you locate software repositories, the server database, and the proxy squid cache on an external virtual disk. This prevents data loss if the instance is unexpectedly terminated. This section includes instructions for setting up an external virtual disk.

1. Network Requirements

When you use Uyuni on a public cloud, you must use a restricted network. We recommend using a VPC private subnet with an appropriate firewall setting. Only machines in your specified IP ranges must be able to access the instance.

Running Uyuni on the public cloud means implementing robust security measures. It is essential to limit, filter, monitor, and audit access to the instance. SUSE strongly advises against a globally accessible Uyuni instance that lacks adequate perimeter security.

To access the Uyuni Web UI, allow HTTPS when configuring the network access controls. This allows you to access the Uyuni Web UI.

In EC2 and Azure, create a new security group, and add inbound and outbound rules for HTTPS. In GCE, check the Allow HTTPS traffic box under the Firewall section.

2. Prepare Storage Volumes

We recommend that the repositories and the database for Uyuni are stored on separate storage devices from the root volume. This will help to avoid data loss and possibly increase performance.

The Uyuni container utilizes default storage locations. These locations should be configured prior to deployment for custom storage. For more information see Persistent container volumes

Do not use logical volume management (LVM) for public cloud installations.

The size of the disk for repositories storage is dependent on the number of distributions and channels you intend to manage with Uyuni. When you attach the virtual disks, they will appear in your instance as Unix device nodes. The names of the device nodes will vary depending on your provider, and the instance type selected.

Ensure the root volume of the Uyuni Server is 100 GB or larger. Add an additional storage disk of 500 GB or more, and choose SSD storage if you can. The cloud images for Uyuni Server use a script to assign this separate volume when your instance is launched.

When you launch your instance, you can log in to the Uyuni Server and use this command to find all available storage devices:

hwinfo --disk | grep -E "Device File:"

If you are not sure which device to choose, use the lsblk command to see the name and size of each device. Choose the name that matches with the size of the virtual disk you are looking for.

You can set up the external disk with the mgr-storage-server command. This creates an XFS partition mounted at /manager_storage and uses it as the location for the database and repositories:

/usr/bin/mgr-storage-server <devicename>