Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]

4 SUSE Manager in the Public Cloud: SUSE Manager Server and SUSE Manager Proxy in the Public Cloud

SUSE Manager delivers best-in-class Linux server management capabilities. For detailed information about the product please refer to the SUSEManager documentation.

The SUSE Manager Server and SUSE Manager Proxy images published by SUSE in selected Public Cloud environments are provided as Bring Your Own Subscription (BYOS) images. SUSE Manager Server instances need to be registered with the SUSE Customer Center (SCC). Subscriptions of SUSE Manager Proxy instances are handled through their parent SUSE Manager Server. After an instance is launched, SUSE Manager needs to be set up and configured following the procedure in the SUSE Manager documentation.

4.1 Instance Requirements

Select an instance size that meets the system requirements as documented in the SUSE Manager documentation.

  • Minimal main memory: >12G

  • 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 that the hostname and IP configuration be performed prior to running the SUSE Manager setup procedure.

  • SUSE Manager Server and SUSE Manager Proxy instances are expected to run in a network configuration that provides you control over DNS entries and that is shielded from the Internet at large. Within this network configuration DNS (Domain Name Service) resolution must be provided, such that hostname -f returns the FQDN (Full Qualified Domain Name). The DNS resolution is not only important for the SUSE Manager Server procedure but is also important when clients are configured to be managed via SUSE Manager. Configuring DNS is Cloud Framework dependent, please refer to the cloud service provider documentation for detailed instructions.

  • Minimal free disk space for SUSE Manager 15G.

    For Public Cloud instances we recommend that the repositories and the SUSE Manager Server database, and respectively the SUSE Manager Proxy squid cache, be located on an external virtual disk. The details for this setup are provided in Section 4.2.1, “Using Separate Storage Volume”.

    Storing the database and the repositories on an external virtual disk ensures that the data is not lost should the instance need to be terminated for some reason.

Please ensure that the selected instance type matches the requirements listed above. Although we recommend that the database and the repositories are stored on a separate device it is still recommended to set the root volume size of the instance to 20G.

4.2 Setup

Run an instance of the SUSE Manager Server or SUSE Manager Proxy image as published by SUSE. The images are identifiable by the suse, manager, server or proxy, and byos keywords in each public cloud environment. The SUSE Manager instance must run in a network access restricted environment such as the private subnet of a VPC or with an appropriate firewall setting such that it can only be accessed by machines in the IP ranges you use. A generally accessible SUSE Manager instance violates the terms of the SUSE Manager EULA. Access to the web interface of SUSE Manager requires https.

SUSE Manager requires a stable and reliable hostname, changing the hostname can create errors. In this procedure, all commands need to be executed as the root user.

Procedure: Setting the Hostname
  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 using the hostnamectl command. Ensure you use the system name, not the fully qualified domain name (FQDN). The FQDN is set by the cloud framework; for example if cloud_instance.cloud.net is the FQDN, cloud_instance is the system name and cloud.net is the domain name:

    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:

    $ echo "${local_address} suma.cloud.net suma" >> /etc/hosts

    You can locate the local address by checking your public cloud web console, or from the command line using these commands:

    • Amazon EC2 instance:

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

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

      $ azuremetadata --internal-ip

Forcing DNS resolution by modifying the /etc/hosts file will work correctly in most environments. However, you will have to perform the same modification for any client that is to be managed with this SUSE Manager instance. In most cases, it will be easier to manage the DNS resolution by creating a DNS entry in your network environment.

One other method for managing hostname resolution is by editing the /etc/resolv.conf file. Depending on the order of your setup, for example if you started the SUSE Manager instance prior to setting up DNS services the file may not contain the appropriate search directive. Double check that the proper search directive exists in /etc/resolv.conf. In our example the directive would be search cloud.net. If the directive is missing add it to the file.

For an update of the DNS records for the instance within the DNS service of your network environment, refer to the cloud service provider documentation for detailed instructions: * DNS setup on Amazon EC2 * DNS setup on Google Compute Engine * DNS setup on Microsoft Azure

If you run a SUSE Manager Server instance, you can run YaST after the instance is launched to ensure the external storage is attached and prepared according to Section 4.2.1, “Using Separate Storage Volume”, and the DNS resolution is set up as described:

$ /sbin/yast2 susemanager_setup

Note that the setup of SUSE Manager from this point forward does not differ from the documentation in the SUSE Manager Guide.

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 20GB and double check that the instructions in Section 4.2.1, “Using Separate Storage Volume” have been completed correctly.

SUSE Manager Server for the Public Cloud comes with a bootstrap data module pre-installed. The bootstrap module contains optimized package lists for bootstrapping instances started from SUSE Linux Enterprise images published by SUSE. If you intend to register such an instance, when you creatr the bootstrap repository run the mgr-create-bootstrap-repo script using this command, to create a bootstrap repository suitable for SUSE Linux Enterprise 12 SP1 instances.

$ mgr-create-bootstrap-repo --datamodule=mgr_pubcloud_bootstrap_data -c SLE-12-SP1-x86_64

See Creating the SUSE Manager Tools Repository for more information on bootstrapping.

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 Section 4.2.1, “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 SUSE Manager Proxy Setup guide for details. Once 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 4.1: Account credentials for admin user
Amazon EC2Google Compute EngineMicrosoft 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.

4.2.1 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.

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

  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

4.3 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
  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.

  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 minion 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 minion, 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 SystemCommands

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

Once you have deleted the minion ID file, re-run the bootstrap script, and restart the minion to see the cloned system in SUSE Manager with the new ID.

Print this page