Infrastructure Software

by Avi Miller and Ginny Henningsen

This article describes how administrators can use Spacewalk to manage the lifecycle of Oracle Linux systems. It explains core concepts and common best practices for a Spacewalk deployment. The article also highlights how Spacewalk can perform initial Oracle Linux provisioning with Kickstart and then automate subsequent software maintenance operations through system lifecycles such as Development, Test, Acceptance, and Production (DTAP).

Introduction

IT administrators face a tough challenge in provisioning systems and keeping them up to date with the latest patches and operating system updates. If errata are deemed critical from a security perspective, it's especially urgent to conduct testing and apply patches to reduce the risk of systems compromise or data exposure. As data centers expand and administrators are tasked to manage greater numbers of physical servers and virtual machines, it's clear that automation is a necessity for efficient and cost-effective systems management. Spacewalk is open source software that helps to automate Linux systems management, allowing administrators to control the system software lifecycle—from initial Linux installation through maintenance, software configuration, and upgrades.

Getting Started with Spacewalk

Spacewalk simplifies a number of management tasks: installations of systems and virtual guests, applying patches and software updates, software configuration, and system auditing using OpenSCAP profiles (Figure 1).

Figure 1. Spacewalk automates frequently performed Linux system management tasks across the full system lifecycle.

Spacewalk is the upstream project for Red Hat Satellite and SUSE Manager (see the Fedora project page). It relies on a database (either PostgreSQL or Oracle Database) to store software packages, configuration files, and system state information.

Oracle Linux Premier Support and Oracle Linux Basic Support contracts include support for Spacewalk implementations deployed with Oracle Database (and include a limited-use license for Oracle Database 12_c_ Enterprise Edition for use with Spacewalk). Documentation for installing and configuring Spacewalk with Oracle Database on Oracle Linux 6 is available in the Oracle Linux 6 documentation repository. Such a Spacewalk implementation can automate management for Oracle Linux 5 and Oracle Linux 6 (i386 and x86_64) systems as well as Oracle Linux 7 (x86_64) systems. When deployed on Oracle Linux, Spacewalk can also manage other Linux releases such as Fedora, CentOS, SLES, and Debian although Spacewalk management of these systems is unsupported.

Spacewalk provides automated management capabilities at no additional cost. Oracle support for this open source project is especially valuable for administrators transitioning to Oracle Linux who are already familiar with Red Hat Satellite or SUSE Manager. Some IT organizations might prefer to implement Oracle Enterprise Manager because it provides a comprehensive management solution that extends beyond Linux systems management. The Oracle Enterprise Manager product family supports management of the entire Oracle software stack including hardware, hypervisors, operating systems and Oracle Database, Oracle middleware, and even Oracle software applications.

Spacewalk Architecture

Spacewalk uses a distributed client/server architecture in which registered client systems subscribe to various software channels that reside on a Spacewalk server (Figure 2). Server functionality can be distributed to meet an organization's needs, especially for geographically disperse environments.

A simple deployment might have a single master to serve a pool of client systems; adding a proxy server enables client access in the event the master is unreachable. In larger deployments, configuring multiple Spacewalk masters and proxies can accelerate provisioning and software download speeds; in a distributed configuration, clients will likely have higher network bandwidth access to servers in close proximity.

Because the Spacewalk architecture is flexible and scalable, an almost infinite number of deployment configurations are feasible. Engaging Oracle consultants can help your organization design an optimal Spacewalk solution, especially if you need to manage a large, geographically dispersed environment of client systems and servers.

Figure 2. Spacewalk supports distributed master and proxy servers to enhance provisioning speed and availability.

Client systems—whether physical servers or virtual guests—first register with a Spacewalk server to subscribe to software channels and obtain packages from the Spacewalk server. Spacewalk can be used with Kickstart, a technology that automates Oracle Linux installations using software packages from a networked installation server. When Spacewalk and Kickstart are used to provision new client systems, the Spacewalk server automatically registers the Kickstart clients if they are properly configured. (A new client system is automatically registered as a Spacewalk client if it has an activation key associated with its Kickstart profile and the Spacewalk Client software is installed. Oracle Linux 7 Update 1 and Oracle Linux 6 Update 7 do not necessarily require the Spacewalk client software, although Oracle recommends installing the client software to obtain full Spacewalk client management capabilities.) This allows administrators to manage the new client systems right away, simplifying subsequent patching, configuration management, and security auditing.

Previously installed systems can also be registered to a Spacewalk server so they can be managed; Spacewalk provides the rhnreg_ks utility for this purpose. (See "Registering Client Systems" in the Spacewalk 2.2 for Oracle Linux 6 Client Life Cycle Management Guide for instructions.)

Basic Terminology and Concepts

It's helpful to understand some basic Spacewalk terminology and concepts before continuing. Note that the terms repository and channel, defined below, have slightly different meanings in a Spacewalk context.

• Repositories. Spacewalk repositories are used to provision channels from an upstream source (spacewalk-repo-sync is the command-line interface [CLI] command). There are two upstream sources available to populate Spacewalk repositories for Oracle Linux: the Oracle public yum server (public-yum.oracle.com) and the Unbreakable Linux Network (ULN, linux.oracle.com). Some repository content, such as content for the update-level specific patch and Ksplice channels, is available from ULN but not from the Oracle public yum server, while other repository content, such as content for the Spacewalk Client and Spacewalk Server channels, can be populated from the Oracle public yum server but not from ULN.

  Note that Spacewalk provides a ULN plugin that allows its repositories to be synchronized with ULN without having to register the Spacewalk server directly with ULN. Unless you are an experienced Spacewalk administrator, it's recommended that you associate only one repository with a channel for obtaining upstream packages—otherwise the channel will try to pull RPMs from multiple sources.

  Oracle often uses the term repository to refer to the software repository on the Oracle public yum server. A Spacewalk repository refers more generally to the data store that connects to an upstream source.

• Channels. Client systems subscribe to Spacewalk channels to obtain software packages and errata. A base channel represents packages for a specific architecture and Oracle Linux release. A base channel can have a number of child channels that contain additional packages. Here's an example of a base and child channel configuration for the Oracle Linux 7 (x86_64) release:

  oraclelinux7-x86_64-base |-- oraclelinux7-x86_64-addons |-- oraclelinux7-x86_64-ksplice |-- oraclelinux7-x86_64-optional |-- oraclelinux7-x86_64-patch |-- oraclelinux7-x86_64-spacewalk22-client |-- oraclelinux7-x86_64-uek-r3
  

  In practice, repository content for the base and patch channels listed above could be synchronized with ULN, while content for the Spacewalk client channel could be populated from the Oracle public yum upstream source. Oracle recommends that channels be populated manually during the initial channel configuration process, and subsequently synchronized on a daily basis—the synchronization can be automated through Spacewalk scheduling or by using a cron job.

  Oracle often uses the term channel to refer to software distribution channels available through ULN. In a Spacewalk context, a channel is the subscription mechanism by which clients can obtain software packages, patches, and updates.

• Organizations. Organizations provide a useful way to tier or segment a Spacewalk implementation. By defining multiple organizations, you can establish Spacewalk management entities that correspond to different corporate divisions or administrative groups. Organizations provide a way to logically delegate system management responsibilities and allocate entitlements. Depending on organizational trust relationships, organizations can also share system and software entitlements.

  Important: Best practice is to define at least one Spacewalk organization up front.

  It's strongly recommended to define at least one Spacewalk organization as soon as the Spacewalk server is installed, even if you think your deployment doesn't require organizations. This is because it's extremely difficult to retrofit organizations into a Spacewalk implementation after the fact.

• Entitlements. By default, Spacewalk assigns 20,000 entitlements per Spacewalk server instance. When creating organizations, the administrator can explicitly allocate a certain number of entitlements to each organization. This in effect limits the number of client systems each organization can register to a Spacewalk server, because each registered client consumes an entitlement. (A second Spacewalk server could enable an additional 20,000 entitlements if more were needed.) When client systems are decommissioned, the Spacewalk administrator should free up those systems' entitlements so that they can be reused.

• Activation keys. Activation keys are tokens that an administrator can create. When a client system is registered to a Spacewalk server, an activation key allows servers to be registered without requiring a Spacewalk username and password. The activation key also provides certain characteristics that the client inherits, such as the software channels to which the client is subscribed. A Universal Default activation key allows all clients in an organization to register and inherit the predefined properties of that key.

• System groups. A Spacewalk administrator can organize client systems into a system group, allowing management operations to be performed on multiple systems at once. Administrators can arbitrarily organize systems into groups using whatever logic makes sense: according to function (for example, web, application, or database servers), according to physical location, or by responsible administrator. In practice, system groups generally share a common Linux release, system architecture, and Kickstart profile.

The Spacewalk release supplies a comprehensive GUI interface (Figure 3) as well as a CLI. The utility spacecmd is an interactive CLI that administrators can use to perform many common Spacewalk operations. Spacewalk also features an extensive and powerful API that enables complex scripting; if you have Spacewalk already installed, the API documentation is available at:

https://<your_spacewalk_server>/rhn/apidoc/index.jsp

Figure 3. Example of the Spacewalk GUI showing the interface for managing channels.

Initial Configuration: Creating and Populating Channels

Before you can use Spacewalk and Kickstart to provision client systems, you must first define channels and populate them with software packages. Channels are populated either by pulling RPM packages from a repository (using the GUI or spacewalk-repo-sync) or pushing RPMs directly to the Spacewalk server using rhnpush. An administrator might use the utility rhnpush, for example, to pull packages from an ISO image or to upload internally developed RPMs to an in-house software channel.

Creating a channel through the GUI is easy: simply navigate to Channels -> Manage Software Channels and click + create new channel (as shown in the upper right of Figure 3). Then specify a name, label, parent (enter "none" for a base channel), and GPG key information for the channel (see "Working with Software Channels").

For example, if you plan to provision systems with Oracle Linux Release 6 Update 7, you might create a base channel with the label ol6u7_x86_64_base and then create child channels for patch, Spacewalk client, and Unbreakable Enterprise Kernel R3 from Oracle, as follows:

ol6u7_x86_64_base |-- ol6u7-x86_64_patch |-- ol6u7-x86_64_spacewalk22-client |-- ol6u7-x86_64_uek-r3

These four channels—base, patch, Spacewalk client, and Unbreakable Enterprise Kernel R3—are typical of what an administrator might configure for clients that will be provisioned through Kickstart. (For the Oracle Linux Release 6 Update 7 and Oracle Linux 7 releases, Spacewalk client packages are not required to register these clients. However, Oracle recommends installing the Spacewalk client channel packages either before or after registration to take full advantage of Spacewalk's management capabilities, including provisioning and auditing.)

There are a number of ways to populate the created software channels with packages. An easy way to populate a software channel initially so that it can be used with Kickstart is to mount an ISO image on the server and use rhnpush. (Alternatively, you can synchronize channels from the ULN or Oracle public yum repositories or from another Spacewalk server using satellite-sync.) After mounting an ISO image on the server, packages can be pushed from an ISO distribution, for example:

# mount -o loop /var/ISOs/V77197-01.iso /var/distro-trees/ol6u7-x86_64-server  # rhnpush -v --channel=ol6u7_x86_64_base --server=http://spwk.mydom.com \  --dir=/var/distro-trees/ol6u7-x86_64-server

There are some nuances worth mentioning with respect to creating and populating channels:

• Differences between channels on the Oracle public yum and ULN repositories. There are differences in the upstream repositories to consider. ULN provides base and patch channels for each update of an Oracle Linux release. The Oracle public yum server provides a public_olN_latest repository that includes all packages for an entire release—the Oracle public yum server has no separate patch channel. Consider the case of populating these four channels:

  ol6u7_x86_64_base |-- ol6u7-x86_64_patch |-- ol6u7-x86_64_spacewalk22-client |-- ol6u7-x86_64_uek-r3
  

  While the base and Unbreakable Enterprise Kernel channels can be initially populated from an ISO image, the patch channel is available only on ULN, and the Spacewalk client channel is available only through the Oracle public yum repository. If you populate channels from ULN, Oracle recommends that you configure separate base and patch channels for each update (for example, ol6u6_x86_64_base and ol6u6_x86_64_patch for Oracle Linux 6 Update 6; ol6u7_x86_64_base and ol6u7_x86_64_patch for Oracle Linux 6 Update 7, and so forth).

• Channel synchronization speed. Populating base channels for an Oracle Linux release from an ISO image is generally faster than pulling the base packages from an upstream repository. (It can take several days to synchronize an Oracle Linux "latest" channel from the Oracle public yum repository.)

  After channels have been created and initially populated from an ISO image, you can then synchronize them with the Oracle public yum server and ULN to bring the channels up to date. The Oracle public yum server is mirrored on a number of servers globally, so it might be faster to synchronize base channels with the Oracle public yum server and then subsequently synchronize patch channels with ULN.

• Storage for channels. Spacewalk requires significant disk space because it maintains all available versions of all packages in each software channel. (see "Storage Requirements" in the installation guide for capacity recommendations.) However, Spacewalk intelligently conserves space—if the same package is a part of multiple channels, it is stored only once (the metadata simply links to the same instance of the package).

  As an example, the addons channel for Oracle Linux Release 6 Update 5 is the same as for Oracle Linux Release 6 Update 6 and Oracle Linux Release 6 Update 7. A typical channel configuration would have a separate base channel for each release and an addons child channel associated with each base (that is, ol6u5_x86_64_addons, ol6u6_x86_64_addons, and ol6u7_x86_64_addons). In this case, the Spacewalk database would store a single set of RPMs for all three addons channels.

Provisioning New Systems with Spacewalk and Kickstart

Administrators can use Spacewalk in conjunction with Kickstart to automate Oracle Linux client installations. When Spacewalk is used for provisioning, Kickstart gets software packages for the clients from channels on the Spacewalk server instead of from a networked Kickstart installation server.

There are three key steps for configuring Spacewalk and Kickstart to install systems (the steps are summarized here; see "Provisioning Client Systems" in the documentation for detailed instructions):

1. Configure distribution trees on the Spacewalk server.

   First configure the Spacewalk server with the appropriate distribution trees—one for each Oracle Linux release and system architecture combination that you want to provision. Each distribution tree must contain an installation kernel and RAM-disk image that the client uses at boot. By mounting the ISO image to /var/distro-trees/ol6u7-x86_64-server (done previously to populate the channel), Kickstart can access the kernel and RAM-disk image in the subdirectory images/pxeboot in the distribution tree.

2. Define a Kickstart distribution in Spacewalk using the Spacewalk GUI or the spacecmd distribution_create command.

   Enter a name for the distribution, the path of the Kickstart tree, and the base channel that will be associated with the distribution.

3. Configure a Kickstart profile using the Spacewalk GUI or the spacecmd kickstart_create command.

   The Kickstart profile generates a Kickstart file containing all installation details (base channel, Kickstart tree, software preferences, root password, locale, partitions, activation keys, preinstallation and postinstallation scripts, and so on). If you have an existing predefined Kickstart file, you might want to upload it into Spacewalk, because the GUI can be used only to edit Kickstart profiles managed by Spacewalk. After reviewing the Kickstart profile and making any modifications, save it to the Spacewalk server.

4. (Optional) Install the OSA daemon.

   Specifying the installation of the OSA daemon (osad) in the Kickstart profile means that the Spacewalk server will apply updates and actions to client systems immediately rather than every four hours (as dictated by the default rhnsd daemon). Note that osad can sometimes experience connection issues that can be largely avoided by stopping it, deleting its database, and restarting it once a day via a cron job. (Refer to the discussion of this issue in the Spacewalk project wiki, "Jabber and OSAD client connection issues.")

From a saved profile, Spacewalk produces a Kickstart file that can then be used during the installation of client systems. From a practical perspective, many administrators find it advantageous to have a small core Kickstart file that they use for the majority of installations. This promotes consistency across installed client systems. Administrators can then use Spacewalk to subscribe clients to updates and customized software channels that are centrally managed.

The Spacewalk GUI supplies an easy way to kick-start a client system using DHCP/PXE boot. Experienced administrators might prefer to use Cobbler on the command line (see "Configuring Cobbler and DHCP to Support Network Booting"). Figure 4 illustrates a Kickstart process that uses DHCP/PXE.

Figure 4. Using Kickstart automates initial client installation, pulling RPM packages from Spacewalk channels.

Maintaining Spacewalk Software Channels

After provisioning new client systems using Spacewalk and Kickstart, administrators must properly maintain these systems. As new security errata are released, administrators must apply updates to protect systems, applications, and data. Spacewalk shines in this respect: when client systems are registered to a Spacewalk server and subscribed to a channel, Spacewalk makes the updated software packages available to the clients as soon as the channel is updated.

There are an endless number of ways to configure Spacewalk channels and maintain systems, and almost every organization (and system administrator) has their own approach. In configuring your Spacewalk environment, it helps to think about how you want updates to occur. Do you want to update systems automatically with the latest errata as soon as patches are released? Do you want explicit control over which errata are applied to which systems?

Spacewalk is extremely flexible and channels can be configured to meet a variety of deployment scenarios. Again, Oracle consulting can help organizations analyze operational requirements and design an optimal Spacewalk configuration to meet system security and maintenance policies. Here are a few simple channel configuration ideas:

• Scenario #1: Create base and patch channels for each release from ULN.

  This article has already pointed out one common strategy for channel creation: creating a base and patch channel for each Oracle Linux release and update level and then regularly synchronizing these channels with ULN. By periodically synchronizing the patch channel, an administrator can pull the most recent errata. Spacewalk offers effective mechanisms (via the GUI and CLI) to view and manage errata, including cloning errata for certain channels.

• Scenario #2: Create an Oracle Linux Ksplice channel.

  A Spacewalk server can also be configured to mirror the Oracle Linux Ksplice channels on ULN, downloading the latest Ksplice update packages to a software channel. Using the Ksplice Offline Client software, Spacewalk clients can then install the kernel updates from the Spacewalk server without rebooting the clients and incurring any downtime (see "Configuring Ksplice Offline Client for Client Systems").

• Scenario #3: Maintain the "latest" channels for applying errata to systems locked to earlier updates.

  Some organizations have application requirements or policies that cause them to keep some systems on a particular operating system release. As an example, perhaps certain production machines are locked to Oracle Linux 6 Update 6. However, when Oracle releases new errata and patches, they are released for the latest release, Oracle Linux 6 Update 7. If an upgrade to the latest release is not feasible for your systems, Oracle strongly recommends applying the latest security errata to avoid compromise to systems running earlier release updates.

  One strategy is to maintain the "latest" channels (with the latest errata) separately—perhaps without even subscribing any systems to these channels. Administrators can then copy the errata packages (and dependencies) from the "latest" channel to other channels (for example, to a release- and update-specific patch channel) to make the latest fixes available.

Managing a Development, Test, Acceptance, and Production Lifecycle Using Channel Cloning

Many Oracle Linux environments implement an application and system software lifecycle known as DTAP (Development, Test, Acceptance, and Production). Spacewalk supports software channel cloning that simplifies the process of promoting software configurations from development to test, test to acceptance, and acceptance to production.

Cloning an existing channel creates a new channel that reflects the state of the original channel's packages and errata at a particular point in time. An administrator can modify a channel before cloning it, perhaps applying errata of a certain date or a set of errata that the administrator has specifically selected. The cloned channel then provides a stable base for development and testing prior to release into production.

Spacewalk keeps track of all registered client systems and the software channels to which they are subscribed. Updates are available to client systems when subscribed channels are updated. Alternatively an administrator can subscribe clients to a different channel, such as a cloned channel containing the new errata that has undergone testing. Cloning helps administrators more precisely control software configurations and establish a methodical workflow that reduces the risk of production problems in mission-critical application environments.

Spacewalk provides both CLI and GUI methods for cloning channels. The GUI allows an administrator to specify a single source channel to be cloned, either the current channel state including all errata or the original state with no errata or with a selected set of errata.

The interactive CLI spacecmd command provides a way to clone a single channel:

# spacecmd {SSM:0}> softwarechannel_clone -s ol6u6-x86_64 -x "s/$/-clone/" -o

Or, to clone a channel tree (that is, a base channel with all of its children), use the following command:

# spacecmd {SSM:0}> softwarechannel_clonetree -s ol6u6-x86_64 -p "clone-"

Because cloning duplicates entries in the Spacewalk database metadata and does not duplicate the packages themselves, cloning is usually very fast. Keeping channels small in size also helps to accelerate channel cloning.

Note that cloning the base and patch channels for an Oracle Linux release is significantly faster than cloning a release's latest channel—this is because the latest channel for an Oracle Linux release contains every version of every package ever distributed, from the initial release date to the present date. In contrast, a base channel for an Oracle Linux release contains exactly what was shipped on the release's ISO image, and the patch channel contains the updates made available since the ISO image was first created. For this reason, base and patch channels are preferred sources for channel cloning.

In establishing a DTAP workflow, some administrators might want to clone channels based on a particular date. The spacewalk-clone-by-date utility (available in the spacewalk-utils package) creates a new channel with packages and errata up to and including a specified date.

For example, the following command clones both a base channel and a patch child channel up to August 7, 2015:

# spacewalk-clone-by-date --username=swadmin --password=swpasswd \  --channels=ol6-x86_64-base ol6-x86_64-base-150807 \  --channels=ol6-x86_64-patch ol6-x86_64-patch-150807 \  --to_date=2015-08-07

It's also possible to blacklist or remove certain packages, and to choose types of errata to include or exclude.

One of the more powerful aspects of spacewalk-clone-by-date is its ability to perform channel cloning based on a given configuration file. You can create a sample configuration file using the --sample_config option, and then edit the file accordingly.

The test.conf configuration file shown below, when issued with spacewalk-clone-by-date -d 2015-08-07 -c test.conf, clones base and patch channels up to August 7, 2015. In addition, it removes any packages involving sendmail:

{ "username":"admin ", "passwd": "spacepw", "assumeyes":true, "skip_depsolve":false, "security_only":false, "blacklist": {        }, "removelist": {        "ALL":["sendmail"]        }, "channels":[        {        "ol6-x86_64-base":"ol6-x86_64-base-150807",        "ol6-x86_64-patch":"ol6-x86_64-patch-150807",        }        ] }

In a DTAP environment, an administrator might use spacewalk-clone-by-date to clone Oracle Linux base and patch channels on a periodic schedule, such as monthly or weekly, as shown in Figure 5. The figure illustrates a common DTAP workflow in which the Spacewalk server pulls packages and the latest errata from the ULN repository for the base development channels. Because integration testing requires less than five days in this hypothetical scenario, Spacewalk is configured to clone the updated development channels automatically each week, creating channel clones for testing. After the test channels have passed all quality assurance tests and been accepted, the Spacewalk administrator can manually clone them into production channels.

To maintain the proper workflow, the administrator must only create development channels using the upstream ULN or Oracle public yum repositories—test and production channels must be cloned from development and test channels, respectively, and must not be associated with any upstream repositories.

Figure 5. Spacewalk cloning helps administrators construct stable and consistent system configurations for DTAP lifecycles.

After cloning the test channels into production channels, an administrator can subscribe production systems to those channels to put the accepted software configuration into production. Using the GUI to navigate to the Systems -> Software Channel Subscriptions page, an administrator can subscribe client systems to the production software channels. Alternatively an administrator can use the command spacecmd system_setbasechannel to change client base channels:

spacecmd {SSM:0}> system_setbasechannel svr5.mydom.com ol7u1-x86_64

To change the base channel for multiple production systems, the administrator can specify the change using channel names, mapping an existing base channel for production systems to a new base channel, as in the following:

# spacecmd {SSM:0}> system_setbasechannel channel:ol7u1-x86_64-QAr1-base \  ol7u1-x86_64-QAr2-base

Using System Groups to Standardize Configurations

Grouping provides an automated way to make changes to many systems at once, applying errata, updating packages, or changing channels. By taking advantage of system groups, administrators can more easily standardize system software configurations, creating cookie-cutter systems that feature consistent releases and patch levels. In large-scale deployments, grouping helps to automate systems management tasks.

An administrator can create a systems group by using the GUI to navigate to Systems -> System Groups, or by using the spacecmd group_create and add_systems commands.

The following commands add all systems that currently subscribe to a certain channel to the group grp-prod-db-mke:

# spacecmd {SSM:0}> group_create grp-prod-db-mke "Prod DB Servers Milwaukee"# spacecmd {SSM:0}> add_systems grp-prod-db-mke channel:ol7u1-x86_64-20150807

To change the base channel for this system group, the administrator can specify the group name as system_setbasechannel:

# spacecmd {SSM:0}> system_setbasechannel group:grp-prod-db-mke \  ol7u1-x86_64-QAr2-base

In this way, an administrator can change the base channel to which the systems are subscribed (for example, promoting systems that subscribe to test channels to production channels). An administrator can perform Spacewalk management operations on a single Spacewalk system group or on the union or intersection of two or more groups (see "Configuring System Groups to Manage Client Systems").

Applying Errata to Systems and System Groups

Spacewalk gives administrators excellent visibility into available errata and precise control in applying errata to systems. To display the relevant errata available for a selected system or system group, use the GUI to navigate to Systems -> Software -> Errata. Filtering the output allows you to display only noncritical, bug fix advisory, product enhancement advisory, or security advisory errata.

The spacecmd system_listerrata command provides similar functionality:

# spacecmd {SSM:0}> system_listerrata svr1.mydom.com 

The spacecmd erratadetails command outputs additional information about a given erratum:

# spacecmd {SSM:0}> errata_details ELSA-2015-1115

The Spacewalk administrator can name a system group with the spacecmd system_applyerrata command to apply errata to multiple systems at once:

# spacecmd {SSM:0}> system_applyerrata group:grp-prod-db-mke ELSA-2015-1115

If you've configured the OSA daemon on the clients in addition to the default rhnsd daemon, then the erratum will be applied right away. If the client systems are not configured with Ksplice (that is, they are not supported under an Oracle Linux Premier Support contract), they must be rebooted for a kernel change to take effect. Without downtime, client systems that use Ksplice technology can take advantage of kernel changes resulting from a channel change.

Conclusion

It's challenging for administrators to provision and maintain large numbers of physical servers and virtual machines across large deployments that span departments and data centers. Yet keeping Linux systems up to date with stable software configurations, the latest security errata, and consistent patch levels is critical to user productivity and a company's day-to-day business operations.

This article introduced some basic concepts and simple commands to help you get started in using Spacewalk to manage Oracle Linux systems. It highlighted just a few of Spacewalk's many capabilities—there are additional efficiencies that a Spacewalk implementation can bring, for example:

• Spacewalk can be used to automatically run OpenSCAP audits against industry-standard security checklists and evaluation profiles.
• Administrators can create Spacewalk channels to distribute internally developed software packages.
• Advanced users can use the Spacewalk API, which offers powerful and extensive scripting, to provide a sophisticated and comprehensive way to further automate management tasks.

Spacewalk provides an effective set of tools for managing the Oracle Linux software lifecycle, especially in large deployments. Spacewalk helps administrators automate Kickstart installations as well as patching, configuration, and maintenance tasks, allowing administrators to rapidly deploy proven and consistent software configurations for Oracle Linux systems.

See Also

• To learn more about Spacewalk technology, Oracle maintains Spacewalk documentation in the Oracle Linux 6 documentation repository.
• Many of the examples given in this article are excerpted from the Spacewalk 2.2 for Oracle Linux 6 Client Life Cycle Management Guide, which is a great resource that contains additional instructions for performing typical administrative operations with Spacewalk.
• For additional details about Spacewalk, visit the Spacewalk open source project page: fedorahosted.org/spacewalk/.

About the Authors

Avi Miller is a product management director for Oracle Linux. He is responsible for managing several of the open source tools management tools available for Oracle Linux, including Spacewalk and Docker. He has also spoken about Oracle Linux management using Spacewalk at Oracle OpenWorld.

Ginny Henningsen has worked for the last 17 years as a freelance writer developing technical collateral and documentation for high-tech companies. Prior to that, Ginny worked for Sun Microsystems, Inc. as a Systems Engineer in King of Prussia, PA and Milwaukee, WI. Ginny has a BA from Carnegie-Mellon University and an MSCS from Villanova University.

| Revision 1.0, 09/15/2015 |

Follow us:
Blog | Facebook | Twitter | YouTube