Public Cloud

Some public cloud environments provide images for Uyuni Server and Proxy. This section discusses what you will need for running Uyuni in a public cloud, and how to set up your installation.

Public clouds provide Uyuni under a Bring Your Own Subscription (BYOS) model. This means that you must register them with the SUSE Customer Center. For more information about registering Uyuni with SUSE Customer Center, see installation:general-requirements.adoc.

Depending on the public cloud network you are using, you can locate the Uyuni installation images by searching for the keywords suse, manager, proxy, or BYOS.

For SUSE Manager Server in Azure, see administration:public-cloud-azure.adoc.

Instance Requirements

Select a public cloud instance that meets the hardware requirements in installation:hardware-requirements.adoc.

In addition, be aware of these considerations:

  • The Uyuni setup procedure performs a forward-confirmed reverse DNS lookup. This must succeed in order for the setup procedure to complete successfully and for Uyuni to operate as expected. Therefore, it is important to perform hostname and IP configuration prior to running the Uyuni setup procedure.

  • Uyuni Server and Proxy instances are expected to run in a network configuration that provides you control over DNS entries, but cannot access the wider internet. 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 service 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. Instructions for setting up an external virtual disk are contained in this section.

Network Setup

On a public cloud service, you must run Uyuni within a restricted network, such as VPC private subnet with an appropriate firewall setting. The instance must only be able to be accessed by machines in your specified IP ranges.

A world-accessible Uyuni instance violates the terms of the Uyuni EULA, and it will not be supported by SUSE.

To access the Uyuni Web UI, allow HTTPS when you set up your networking environment.

Set the Hostname

Uyuni requires a stable and reliable hostname. Changing the hostname at a later point can create errors.

In most public cloud environments, the method shown in this section will work correctly. However, you will have to perform the same modification for every client.

You might prefer to manage DNS resolution by creating a DNS entry in your network environment instead.

You can also manage hostname resolution by editing the /etc/resolv.conf file. Depending on the order of your setup, if you start the Uyuni instance prior to setting up DNS services the file may not contain the appropriate search directive. Check that the proper search directive exists in /etc/resolv.conf and add it if it is missing.

Procedure: Setting the hostname locally
  1. Disable hostname setup by editing the DHCP configuration file at /etc/sysconfig/network/dhcp, and adding this line:

    DHCLIENT_SET_HOSTNAME="no"
  2. Set the hostname locally with the hostnamectl command. Ensure you use the system name, not the FQDN. For example, if the FQDN is system_name.example.com, the system name is system_name, and the domain name is example.com.

    # hostnamectl set-hostname system_name
  3. Create a DNS entry in your network environment for domain name resolution, or force correct resolution by editing the /etc/hosts file. You can find the IP address by checking your public cloud web console, or from the command line:

    • Amazon EC2 instance:

      # ec2metadata --local-ipv4
    • Google Compute Engine:

      # gcemetadata --query instance --network-interfaces --ip
    • Microsoft Azure:

      # azuremetadata --internal-ip

      In the following command, replace <ip_address> with IP address you retrieve from the command line above:

      # echo "<ip_address> suma.cloud.net suma" >> /etc/hosts

Set up DNS Resolution

You will need to update the DNS records for the instance within the DNS service of your network environment. Refer to the cloud service provider documentation for detailed instructions:

If you run a Uyuni Server instance, ensure the external storage is attached and prepared correctly, and that DNS resolution is set up as described. Start the susemanager_setup with YaST:

# /sbin/yast2 susemanager_setup

The Uyuni setup procedure in YaST is designed as a one pass process with no rollback or cleanup capability. Therefore, if the setup procedure is interrupted or ends with an error, it is not recommended that you repeat the setup process or attempts to manually fix the configuration. These methods are likely to result in a faulty Uyuni installation. If you experience errors during setup, start a new instance, and begin the setup procedure again on a clean system.

If you receive a message that there is not enough space available for setup, ensure that your root volume is at least 20 GB and double check that the instructions in Using Separate Storage Volume have been completed correctly.

Prior to registering instances started from on demand images remove the following packages from the instance to be registered: …​ cloud-regionsrv-client …​ For Amazon EC2

+ regionServiceClientConfigEC2

+ regionServiceCertsEC2 …​ For Google Compute Engine

+ cloud-regionsrv-client-plugin-gce

+ regionServiceClientConfigGCE

+ regionServiceCertsGCE …​ For Microsoft Azure

+ regionServiceClientConfigAzure

+ regionServiceCertsAzure

+ If these packages are not removed it is possible to create interference between the repositories provided by Uyuni and the repositories provided by the SUSE operated update infrastructure.

+ Additionally remove the line from the /etc/hosts file that contains the susecloud.net reference. ** If you run a Uyuni Proxy instance

+ Launch the instance, optionally with external storage configured. If you use external storage (recommended), prepare it according to Using Separate Storage Volume. It is recommended but not required to prepare the storage before configuring Uyuni proxy, as the suma-storage script will migrate any existing cached data to the external storage. After preparing the instance, register the system with the parent SUSE Manager, which could be a Uyuni Server or another Uyuni Proxy. See the installation:proxy-setup.adoc for details. When registered, run

+

$ /usr/sbin/configure-proxy.sh

+ to configure your Uyuni Proxy instance. . After the completion of the configuration step, Uyuni should be functional and running. For Uyuni Server, the setup process created an administrator user with following user name:

+ * User name: admin

+

Table 1. Account credentials for admin user
Amazon EC2 Google Compute Engine Microsoft Azure

Instance-ID

Instance-ID

Instance-Name-suma

+ The current value for the Instance-ID or Instance-Name in case of the Azure Cloud, can be obtained from the public cloud Web console or from within a terminal session as follows: ** Obtain instance id from within Amazon EC2 instance

+

$ ec2metadata --instance-id
  • Obtain instance id from within Google Compute Engine instance

    $ gcemetadata --query instance --id
  • Obtain instance name from within Microsoft Azure instance

    $ azuremetadata --instance-name

    After logging in through the Uyuni Server Web UI, change the default password.

    Uyuni Proxy does not have administration access to the Web UI. It can be managed through its parent Uyuni Server.

Using Separate Storage Volume

We recommend that the repositories and the database for Uyuni be stored on a virtual storage device. This best practice will avoid data loss in cases where the Uyuni instance may need to be terminated. These steps must be performed prior to running the YaST Uyuni setup procedure.

  1. Provision a disk device in the public cloud environment, refer to the cloud service provider documentation for detailed instructions. The size of the disk is dependent on the number of distributions and channels you intend to manage with Uyuni. For sizing information refer to SUSE Manager sizing examples. A rule of thumb is 25 GB per distribution per channel.

  2. Once attached the device appears as Unix device node in your instance. For the following command to work this device node name is required. In many cases the attached storage appears as /dev/sdb. In order to check which disk devices exists on your system, call the following command:

    $ hwinfo --disk | grep -E "Device File:"
  3. With the device name at hand the process of re-linking the directories in the filesystem Uyuni uses to store data is handled by the suma-storage script. In the following example we use /dev/sdb as the device name.

    $ /usr/bin/suma-storage /dev/sdb

    After the call all database and repository files used by SUSE Manager Server are moved to the newly created xfs based storage. In case your instance is a Uyuni Proxy, the script will move the Squid cache, which caches the software packages, to the newly created storage. The xfs partition is mounted below the path /manager_storage. .

  4. Create an entry in /etc/fstab (optional)

    Different cloud frameworks treat the attachment of external storage devices differently at instance boot time. Please refer to the cloud environment documentation for guidance about the fstab entry.

    If your cloud framework recommends to add an fstab entry, add the following line to the /etc/fstab file.

    /dev/sdb1 /manager_storage xfs defaults,nofail 1 1

Registration of Cloned Systems

Uyuni cannot distinguish between different instances that use the same system ID. If you register a second instance with the same system ID as a previous instance, Uyuni will overwrite the original system data with the new system data. This can occur when you launch multiple instances from the same image, or when an image is created from a running instance. However, it is possible to clone systems and register them successfully by deleting the cloned system’s ID, and generating a new ID.

Procedure: Registering Cloned Systems
  1. Clone the system using your preferred hypervisor’s cloning mechanism.

  2. On the cloned system, change the hostname and IP addresses, and check the /etc/hosts file to ensure you have the right host entries.

  3. On traditional clients, stop the rhnsd daemon with /etc/init.d/rhnsd stop or, on newer systemd-based systems, with service rhnsd stop. Then service osad stop.

  4. For SLES 11 or Red Hat Enterprise Linux 5 or 6 clients, run these commands:

    # rm /var/lib/dbus/machine-id
    # dbus-uuidgen --ensure
  5. For SLES 12 or Red Hat Enterprise Linux 7 clients, run these commands:

    # rm /etc/machine-id
    # rm /var/lib/dbus/machine-id
    # dbus-uuidgen --ensure
    # systemd-machine-id-setup
  6. If you are using Salt, then you will also need to run these commands:

    # service salt-minion stop
    # rm -rf /var/cache/salt
  7. If you are using a traditional client, clean up the working files with:

    # rm -f /etc/sysconfig/rhn/{osad-auth.conf,systemid}

The bootstrap should now run with a new system ID, rather than a duplicate.

If you are onboarding Salt client clones, then you will also need to check if they have the same Salt minion ID. You will need to delete the minion ID on each cloned client, using the rm command. Each operating system type stores this file in a slightly different location, check the table for the appropriate command.

Minion ID File Location

Each operating system stores the minion ID file in a slightly different location, check the table for the appropriate command.

Operating System Commands

SLES 12

rm /etc/salt/minion_id

rm -f /etc/zypp/credentials.d/{SCCcredentials,NCCcredentials}

SLES 11

rm /etc/salt/minion_id

suse_register -E

SLES 10

rm -rf /etc/{zmd,zypp}

rm -rf /var/lib/zypp/ Do not delete /var/lib/zypp/db/products/

rm -rf /var/lib/zmd/

Red Hat Enterprise Linux 5, 6, 7

rm -f /etc/NCCcredentials

When you have deleted the minion ID file, re-run the bootstrap script, and restart the client to see the cloned system in Uyuni with the new ID.