Public Cloud

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

Public clouds provide SUSE Manager 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 SUSE Manager with SUSE Customer Center, see installation:general-requirements.adoc.

Depending on the public cloud network you are using, you can locate the SUSE Manager 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 SUSE Manager setup procedure performs a forward-confirmed reverse DNS lookup. This must succeed in order for the setup procedure to complete successfully and for SUSE Manager to operate as expected. Therefore, it is important to perform hostname and IP configuration prior to running the SUSE Manager setup procedure.
SUSE Manager 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 SUSE Manager 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 SUSE Manager instance violates the terms of the SUSE Manager EULA, and it will not be supported by SUSE.

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

Set the Hostname

SUSE Manager 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 SUSE Manager 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

Disable hostname setup by editing the DHCP configuration file at /etc/sysconfig/network/dhcp, and adding this line:
```
DHCLIENT_SET_HOSTNAME="no"
```
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
```
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 SUSE Manager 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 SUSE Manager 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 SUSE Manager 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 SUSE Manager 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 SUSE Manager 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 SUSE Manager 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 SUSE Manager Server or another SUSE Manager Proxy. See the installation:proxy-setup.adoc for details. When registered, run

$ /usr/sbin/configure-proxy.sh

+ to configure your SUSE Manager Proxy instance. . After the completion of the configuration step, SUSE Manager should be functional and running. For SUSE Manager 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 SUSE Manager Server Web UI, change the default password.

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

Using Separate Storage Volume

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

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 SUSE Manager. For sizing information refer to SUSE Manager sizing examples. A rule of thumb is 25 GB per distribution per channel.
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:"
```
With the device name at hand the process of re-linking the directories in the filesystem SUSE Manager 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 SUSE Manager 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. .
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

SUSE Manager 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, SUSE Manager 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

Clone the system using your preferred hypervisor’s cloning mechanism.
On the cloned system, change the hostname and IP addresses, and check the /etc/hosts file to ensure you have the right host entries.
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.
For SLES 11 or Red Hat Enterprise Linux 5 or 6 clients, run these commands:
```
# rm /var/lib/dbus/machine-id
# dbus-uuidgen --ensure
```

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

If you are using Salt, then you will also need to run these commands:
```
# service salt-minion stop
# rm -rf /var/cache/salt
```
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

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`

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 SUSE Manager with the new ID.