Reference Manual
- About This Guide
- 1 Available Documentation
- 2 Feedback
- 3 Documentation Conventions
- 4 Special Uyuni Documentation Conventions
- 5 Overview and Navigation
- 6 Navigation
- 7 Systems
- 8 Autoinstallation
- 9 Salt
- 10 Images
- 11 Patches
- 12 Software
- 13 Audit
- 14 System Security via OpenSCAP
- 15 Configuration
- 16 Schedule
- 17 Users
- 18 Admin
- 19 Help
18 Admin
The › pages allows Uyuni customers to manage the basic configuration, including creating and managing multiple organizations. Only the Uyuni administrator can access the › pages.
18.1 › › #
Setting up Uyuni typically requires some extra steps after installation for common configuration tasks.
The › › link is displayed when the Uyuni Web UI is used for the fist time and can be accessed later at any time by clicking › › . On the three tabs configure the HTTP proxy server, organization credentials, and SUSE products.
If needed configure a proxy server that Uyuni will use to access SCC (SUSE Customer Center) and other remote servers here. Use
hostname:portsyntax in the › field if the proxy port is not 8080. Clearing the fields disables proxy.
Select › › › then enter user name and password to give another organization/user access to SUSE Customer Center.
After saving, a new credential card will be displayed. Buttons below the credential card allow you to:
Check credential validation status (green tick or red cross icon). To re-check the credential with SCC, click the icon.
Set the primary credentials for inter-server synchronization (yellow star icon).
List the subscriptions related to a certain credential (list icon).
Edit the credential (pencil icon).
Delete the credential (trash can icon).
- › ›
On the › › page, select product-specific channels you are entitled to.
The products displayed are directly linked to your organization credentials and your SUSE subscriptions. Product extension and module lists are shown when you click the to the left of the product description. This is a cascading mechanism and allows to unfold several levels according to the integration of the extensions and modules in the base product.
Products based on SUSE Linux Enterprise 15 or higher have a toggle button named . When the toogle button is enabled on a base product, recommended extensions and modules are automatically selected for synchronization. Once the button is enabled, you may uncheck product child channels you are not interested in syncing. Recommended channels are labeled accordingly. You cannot disable required channels.
If you click the icon in a row of a product, a popup lists the underlying channels (repositories) that build the product.
In the row above the product listing two filter options are available:
Search by the product description. The filter limits the search to base products.
Filter by architecture. Click in the search field (or press Enter ) and then select from drop-down menu. You can repeat this as often as necessary. To remove an architecture either click the “x” symbol (or press Backspace ).
Once you have made your selection(s), click in the upper right area. This is equivalent to running
mgr-sync add productsormgr-syncwithout any arguments.View the synchronization progress in the status bar field to the right.
Note: Synchronization Time
Channel synchronization will start and might take several hours. When finished the corresponding channels can be used in Uyuni.
Important: If Synchronization Fails
SUSE does not automatically trust 3rd party GPG keys. If a reposync fails check if an untrusted GPG key is the cause by viewing the log files located in:
/var/log/rhn/reposync
Look for lines similar to the following:
['/usr/bin/spacewalk-repo-sync', '--channel', 'sle-12-sp1-ga-desktop- nvidia-driver-x86_64', '--type', 'yum', '--non-interactive'] ChannelException: The GPG key for this repository is not part of the keyring. Please run spacewalk-repo-sync in interactive mode to import it.
Alternatively, you can add listed channels immediately by clicking the button in the status column. A progress bar will be displayed. The main product will expand, and then you may select add-on products belonging to the product that is currently added. To overview required channels, select the list icon in the › column. Once a product has finished downloading, the status bar state will change from a filled percentage value to › .
18.2 › › #
The organizations feature allows Uyuni administrators to create and manage multiple organizations across Uyuni. Administrators can control an organization’s access to system management tasks.
If you click the name of an organization, the Organization Details page appears.
18.2.1 › #
The › page lists the details of the selected organization.
The following details are available:
› : String (between 3 and 128 characters). This is the only value that you can change here. When done, confirm with clicking the button.
› : Number
› : Number. Clicking this number will open the › tab.
› : Number
› : Number
› : Number
› : Number
› : Number
18.2.2 › #
List of all the users of an organization.
You can modify the user details if you belong to that organization and have organization administrator privileges.
18.2.3 › #
Here establish trust between organizations.
Such a trust allows sharing contents and migrate systems between these two organizations. You may add a trust by checking the box next to an organization (or remove a trust by unchecking it) and clicking the button.
18.2.4 › #
Allow the Organization Administrator to manage Organization configuration, configure the organization to use staged contents (“pre-fetching” packages, etc.), set up software crash reporting, and upload of SCAP files.
- SUSE Manager Configuration
Enable › if desired.
- Organization Configuration
›
›
›
›
›
›
›
›
›
When settings are done, confirm with clicking the button.
- Enable Staging Contents
The clients will download packages in advance and stage them. This has the advantage that the package installation action will take place immediately, when the schedule is actually executed. This “pre-fetching” saves maintenance window time, which is good for service uptime.
For staging contents (“pre-fetching”), edit on the client /etc/sysconfig/rhn/up2date:
stagingContent=1 stagingContentWindow=24
stagingContentWindow is a time value expressed in hours and determines when downloading will start.
It is the number of hours before the scheduled installation or update time.
In this case, it means 24 hours before the installation time.
The start time for download depends on the selected contact method for a system.
The assigned contact method sets the time for when the next rhn_check will be executed.
Next time an action is scheduled, packages will automatically be downloaded but not installed yet. When the scheduled time comes, the action will use the staged version.
- Minion Content Staging
Every Organization administrator can enable Content Staging from the Organization configuration page › › › › .
Staging content for minions is affected by two parameters.
salt_content_staging_advance:expresses the advance time, in hours, for the content staging window to open with regard to the scheduled installation/upgrade time.salt_content_staging_window:expresses the duration, in hours, of the time window for Salt minions to stage packages in advance of scheduled installations or upgrades.
A value of salt_content_staging_advance equal to salt_content_staging_window results in the content staging window closing exactly when the installation/upgrade is scheduled to be executed. A larger value allows separating download time from the installation time.
These options are configured in /usr/share/rhn/config-defaults/rhn_java.conf
and by default assume the following values:
salt_content_staging_advance: 8 hourssalt_content_staging_window: 8 hours
Note
These parameters will only have an effect when Content Staging is enabled for the targeted Organization.
18.2.5 › #
From the › › page you can assign State to all systems in an organization. For example, this way it is possible to define a few global security policies or add a common admin user to all machines.
18.3 › › #
To view and manage all users of the organization you are currently logged in to, click › › in the left navigation bar.
The table lists user name, real name, organization and whether the user is organization or Uyuni administrator.
To modify administrator privileges, click any user name with administrator privileges to get to the › page.
For more information, see:
Section 17.1.4, “User Details”.
18.4 › › #
The › › page is split into tabs which allow you to configure many aspects of Uyuni.
18.4.1 › #
This page allows you to adjust basic Uyuni administration settings.
E-mail address of the Uyuni administrator.
Host name of the Uyuni server.
- Uyuni Proxy Configuration
Configure proxy data via the following fields:
›
›
›
›
The HTTP proxy settings are for the communication with a Uyuni parent server, if there is any. The HTTP proxy should be of the form:
hostname:port; the default port8080will be used if none is explicitly provided. HTTP proxy settings for client systems to connect to this Uyuni can be different, and will be configured separately, for example via: Section 18.4.2, “ › ”.
The directory where RPM packages are mirrored. By default:
/var/spacewalk.For secure communication, use SSL.
When done, confirm with .
18.4.2 › #
The › page allows you to generate a bootstrap script that registers the client systems with Uyuni and disconnects them from the remote SUSE Customer Center.
Important: SLES 15 and Python 3
SLES 15 utilizes Python 3 as its default system version. Due to this change any older bootstrap scripts(based on python 2) must be re-created for SLES 15 systems. Attempting to register SLES 15 systems with SUSE Manager using Python 2 versions of the bootstrap script will fail.
This generated script will be placed within the /srv/www/htdocs/pub/bootstrap/ directory on your Uyuni server.
The bootstrap script will significantly reduce the effort involved in reconfiguring all systems, which by default obtain packages from the SUSE Customer Center.
The required fields are pre-populated with values derived from previous installation steps.
Ensure this information is accurate.
- SUSE Manager server hostname
The name of the SUSE Manager server where you want to register the client (pre-populated).
- SSL cert location
Location and name of the SSL certificate (pre-populated).
- Bootstrap using Salt
To bootstrap traditional clients, uncheck › . For more information, see: Section 5.4, “Registering Traditional Clients”.
- Enable SSL
It is advised keeping SSL enabled. If enabled the corporate public CA certificate will be installed on the client. If disabled the user must manage CA certificates to be able to run the registration (
rhnreg_ks).- Enable Client GPG checking
GNU Privacy Guard (GPG)
- Enable Remote Configuration
Enable remote configuration management and remote command acceptance of the systems to be bootstrapped to the Uyuni. Both features are useful for completing client configuration. For more information, see: Chapter 15, Configuration and Section 7.3.1.3, “ › › ”.
- Client HTTP Proxy
Client HTTP proxy settings if you are using an HTTP proxy server.
When finished, click .
18.4.3 › #
The › page contains details about the organizations feature of Uyuni, and links for creating and configuring organizations.
18.4.4 › #
The › page comprises the final step in configuring Uyuni.
Click the button to restart Uyuni and incorporate all of the configuration options added on the previous screens. It will take between four and five minutes for a restart to finish.
18.4.5 › #
On the › page you can run the Cobbler synchronization by clicking .
Cobbler synchronization is used to repair or rebuild the contents of /srv/tftpboot or /srv/www/cobbler when a manual modification of the cobbler setup has occurred.
18.4.6 › #
Here you can add unprovisioned ("bare-metal") systems capable of booting using PXE to an organization.
First click . Those systems then will appear in the › › list, where regular provisioning via autoinstallation is possible in a completely unattended fashion.
Only AMD64/Intel 64 systems with at least 1 GB of RAM are supported. Uyuni server will use its integrated Cobbler instance and will act as TFTP server for this feature to work, so the network segment that connects it to target systems must be properly configured. In particular, a DHCP server must exist and have a next-server configuration parameter set to the Uyuni server IP address or hostname.
When enabled, any bare-metal system connected to the SUSE Manager server network will be automatically added to the organization when it powers on. The process typically takes a few minutes; when it finishes, the system will automatically shut down and then appear in the › › list.
Note
New systems will be added to the organization of the administrator who enabled this feature. To change the organization, disable the feature, log in as an administrator of a different organization and enable it again.
Provisioning can be initiated by clicking the tab. In case of bare-metal systems, though, provisioning cannot be scheduled, it will happen automatically when it is completely configured and the system is powered on.
It is possible to use › › with bare-metal systems, although in that case some features will not be available as those systems do not have an operating system installed. This limitation also applies to mixed sets with regular and bare-metal systems: full features will be enabled again when all bare-metal systems are removed from the set.
18.5 › › #
Inter-Server Synchronization (ISS) allows Uyuni synchronizing content and permissions from another Uyuni instance in a peer-to-peer relationship.
18.5.1 Configuring the Master Uyuni Server #
The following will help you set up a master ISS server.
Click › › › . In the top right-hand corner of this page, click :
Fill in the following information:
Slave Fully Qualified Domain Name (FQDN)
Allow Slave to Sync? Selecting this checkbox will allow the slave Uyuni to access this master Uyuni. Otherwise, contact with this slave will be denied.
Sync All Orgs to Slave? Checking this field will synchronize all organizations to the slave Uyuni.
Note
Marking the › checkbox on the › page will override any specifically selected organizations in the local organization table.
Click . Optionally, click any local organization to be exported to the slave Uyuni then click .
Note: Enabling Inter-server Synchronization in Uyuni 2.1
ISS is enabled by default in Uyuni 3.1 and later.
To enable the inter-server synchronization (ISS) feature in Uyuni 2.1, edit the /etc/rhn/rhn.conf file and set: disable_iss=0.
Save the file and restart the httpd service with service httpd restart.
For synchronization timeout settings, see: Section 17.4, “RPC Connection Timeout Settings”.
18.5.2 Configuring Slave Servers #
Slave servers receive content synchronized from the master server.
To securely transfer content to the slave servers, the ORG-SSL certificate from the master server is needed. Click › › . In the top right-hand corner, click .
› › and fill in the following information:
Master Fully Qualified Domain Name (FQDN)
Filename of this Master’s CA Certificate: use the full path to the CA Certificate. For example:
/etc/pki/trust/anchors
Default Master?
Click .
Once the master and slave servers are configured, start the synchronization on the Master server by executing mgr-inter-sync:
mgr-inter-sync -c`YOUR-CHANNEL`
18.5.3 Mapping Uyuni Master Server Organizations to Slave Organizations #
A mapping between organizational names on the master Uyuni allows for channel access permissions being set on the master server and propagated when content is synchronized to a slave Uyuni. Not all organization and channel details need to be mapped for all slaves. Uyuni administrators can select which permissions and organizations can be synchronized by allowing or omitting mappings.
To complete the mapping, log in to the Slave Uyuni as administrator. Click › › and select a master Uyuni by clicking its name. Use the drop-down box to map the exported master organization name to a matching local organization in the slave Uyuni, then click .
On the command line, issue the synchronization command on each of the custom channels to obtain the correct trust structure and channel permissions:
mgr-inter-sync -c`YOUR-CHANNEL`
18.6 › › #
Under › › all predefined task bunches are listed.
Click a › to open its › where you can disable it or change the frequency. Click to update the schedule with your settings. To delete a schedule, click in the upper right-hand corner.
Warning
Only disable or delete a schedule if you are absolutely certain this is necessary as they are essential for Uyuni to work properly.
If you click a bunch name, a list of runs of that bunch type and their status will be displayed. Clicking the start time links takes you back to the › .
For example, the following predefined task bunches are scheduled by default and can be configured:
(Re)generates repository metadata files.
Cleans up stale package change log and monitoring time series data from the database.
Clears task engine (taskomatic) history data older than a specified number of days, depending on the job type, from the database.
Synchronizes distribution and profile data from Uyuni to Cobbler. For more information on Cobbler, see Chapter 10, Cobbler.
Compares configuration files as stored in configuration channels with the files stored on all configuration-enabled servers. To review comparisons, click the › tab and click the system of interest. Go to › . For more information, refer to: Section 7.3.3.5, “ › › ”.
Updates internal pre-computed CVE data that is used to display results on the › › page. Search results in the › › page are updated to the last run of this schedule). For more information, see: Section 13.1, “CVE Audit”.
Sends daily report e-mails to relevant addresses. To learn more about how to configure notifications for specific users, see: Section 17.1.4.5, “ › ”
Updates internal patch cache database tables, which are used to look up packages that need updates for each server. Also, this sends notification emails to users that might be interested in certain patches. For more information on patches, see: Chapter 11, Patches.
Queues automatic updates (patches) for servers that are configured to receive them.
Cleans up stale kickstart session data.
Generates Cobbler files corresponding to Kickstart profiles created by the configuration wizard.
Calls the
mgr-registercommand, which synchronizes client registration data with NCC (new, changed or deleted clients' data are forwarded).the default time at which the start of synchronization with SUSE Customer Center (SCC) takes place (
mgr-sync-refresh).deletes stale package files from the file system.
any reboot actions pending for more than six hours are marked as failed and associated data is cleaned up in the database. For more information on scheduling reboot actions, see: Section 7.3.4.2, “ › › ”.
cleans up › configuration parameter (3 days by default). Sandbox files are those imported from systems or files under development. For more information, see: Section 7.3.3.3, “ › › ”
cleans up stale Web interface sessions, typically data that is temporarily stored when a user logs in and then closes the browser before logging out.
prompts clients to check in with Uyuni via SSH if they are configured with a › .
deletes expired repository tokens that are used by Salt minions to download packages and metadata.
18.7 › › #
This is a status report of the various tasks running by the Uyuni task engine.
Next to the task name you find the date and time of the last execution and the status.
18.8 › › #
Here the Uyuni admin user has access to the Tomcat log file located at /var/log/rhn/rhn_web_ui.log.
No root privileges are required.
