Freigeben über

Microsoft Loves Linux Deep Dive #10: Managing the Software Configuration on Linux and UNIX Servers

  • Artikel

This post was written by Michael Kelley, Principal PM Manager, Cloud + Enterprise team

Introduction

This blog post is #10 in a series of technical posts about running and managing Linux and FreeBSD in your on-premises datacenter.  Other posts in the series are here:

Overview

Running Linux and FreeBSD as a guest operating system on Hyper-V

Managing Linux and UNIX using System Center and PowerShell DSC

Managing the Software Configuration on Linux and UNIX Servers

Configuration Manager (ConfigMgr) is a mature and widely used component of System Center for managing the software configuration of Windows desktops and laptops, as well as Windows Servers.  Starting with the System Center 2012 SP1 release, Configuration Manager can also manage the software configuration of Linux and UNIX servers.  ConfigMgr provides a dozen or more functional areas covering both client devices (desktops/laptop/smartphones/etc.) and servers.  For Linux and UNIX servers, ConfigMgr implements the core areas that are relevant for server software configuration management.  Functionality that is relevant mostly for client devices, and user-centric functionality, is not implemented for Linux/UNIX.  See the chart below:

The Linux and UNIX server functionality is implemented by a version of the Configuration Manager client that installs and runs on the managed Linux/UNIX server.  This client for Linux and UNIX communicates with the ConfigMgr server infrastructure exactly as a Windows client would, so the same server infrastructure is used to manage both Windows and Linux/UNIX clients.  No new site roles are needed.

The ConfigMgr client for Linux/UNIX consists of a process named “ccmexec.bin” (so long time ConfigMgr users will feel comfortable ), plus an instance of Open Management Infrastructure (OMI) and set of providers that implement hardware inventory classes.   As mentioned in a previous post in this series, OMI is an implementation of Common Information Model (CIM) standards, analogous to Windows Management Instrumentation (WMI) in Windows, and is available here as an open source project.  This is the same OMI component that is used in the System Center Operations Manager agent for Linux and UNIX.

The overall architecture of the ConfigMgr client for Linux/UNIX is shown here:

Inventory

For Windows, ConfigMgr implements two areas of inventory functionality, called hardware inventory and software inventory.  Additionally, the asset intelligence area builds on the inventory functionality to provide additional insight into the installed Windows software packages.   Interestingly, hardware inventory might more accurately be called “WMI inventory”, because it returns information from WMI classes on a Windows computer, which could include both hardware and software information.  Similarly, ConfigMgr’s software inventory function might more accurately be called “File Inventory” because it scans the Windows file system, looking for files that match a specified file name pattern.

The Linux/UNIX client implements hardware Inventory, but does not implement software inventory or asset intelligence.  For hardware inventory, the OMI providers bundled with the Linux/UNIX client implement CIM classes that correspond to the core WMI classes on Windows, such as Win32_BIOS, Win32_ComputerSystem, etc.  Consequently, the hardware inventory returned for Linux and UNIX is very consistent with the hardware inventory returned for Windows computers.  The inventory data is stored in exactly the same tables in the ConfigMgr site database, and can be viewed using the same tools used for Windows hardware inventory data.  Resource Explorer in the ConfigMgr console displays Linux/UNIX hardware inventory data for a single computer, and the ConfigMgr Reporting functional area is used to view and report on consolidated inventory data across multiple computers.

For hardware inventory on Windows, the WMI class Win32Reg_AddRemovePrograms class returns information from the local MSI database about software that was installed using the standard Windows MSI mechanism.  On Linux and UNIX, a corresponding OMI class returns information from the native package manager for each operating system.  For example, on Red Hat Enterprise Linux, this class returns information from rpm database, giving a list of all rpm packages installed on the operating system – several hundred entries.   On Debian and Ubuntu Linux, the class returns information from the deb database, and similarly on Solaris, from the pkg database.   So on Linux and UNIX servers, ConfigMgr provides an inventory of all packages installed using the native package manager.  Software installed using ‘tar’ or by just copying files is not inventoried since these tools bypass the native package manager.

Like with Windows clients, Linux/UNIX clients collect hardware inventory data on a scheduled interval that defaults to every 7 days.  This interval can be changed using ConfigMgr’s client settings mechanism.  Also, the hardware inventory mechanism for Linux/UNIX clients can be extended with custom inventory providers to collect additional information that is unique to your requirements.  This blog post provides details on creating customer inventory providers.

Collections

Most operations in ConfigMgr are performed against groups of computers in a collection.   While collection membership can be specified statically as one or more specific computers, IT administrators usually create collections with dynamic membership based on a query against inventory data.  If inventory data changes, the query causes collection membership to be updated based on the new inventory data. 

As an example, an IT administrator could build a collection of all computers with 16 Gb or more of memory.   Because hardware inventory data for Windows and Linux/UNIX computers is stored in the same site database tables, such a collection would contain both Windows and Linux/UNIX computers unless the query contained a qualifier based on the operating system.

As another example, an IT administrator could build a collection of all computers with a particular version of OpenSSL, using the inventory data collected from the native Linux/UNIX package manager.  Such a collection could identify computers that need an updated version of OpenSSL to correct a security vulnerability.  Once the computer is updated to a new version and inventory information is updated, the collection membership is also updated.   When all updates are completed and no more computers have the problematic OpenSSL version, the collection membership should go to zero.

Software Distribution

You can distribute and install software on Linux and UNIX computers using the classic software distribution function in ConfigMgr.  The application model in ConfigMgr is not implemented for Linux/UNIX servers because it is oriented to distributing software to users on client devices and is not as relevant to servers that don’t typically have individual users logged in.  Using software distribution, you can accomplish a variety of useful scenarios for Linux/UNIX computers.  Examples include:

  • Pushing out a new version of the Java Runtime Environment (JRE) to Linux and UNIX computers
  • Update the version of OpenSSL in response to a security vulnerability being reported
  • Deploy a custom line-of-business application
  • Perform utility and maintenance operations by running arbitrary scripts

Software distribution is based on two concepts:  packages and programs.  The package is the content to be pushed to each targeted Linux/UNIX computer through ConfigMgr’s content distribution mechanism.  It could consist of a single file, such as an rpm or tar file, or it could be an entire directory structure with multiple files and subdirectories in any format.  ConfigMgr replicates the package onto one or more distribution points (DP) that are selected by the IT administrator.  Target computers that are installing the package via software distribution will fetch the package from the DP that is “nearest” from the standpoint of network topology.   A DP is a Windows computer that is part of the ConfigMgr infrastructure, and it may contain both Windows and Linux/UNIX packages.  Because the same DP can serve content targeted for Windows and Linux/UNIX computers, you do not have to set up special DPs for Linux/UNIX.

The program is the command line to be executed on each target computer to install the package.   The program may invoke a command or script that is already on the target computer, or it may invoke a command or script that is part of the package.   For example, in a simple case, the command line may be just an invocation of the rpm command to install an rpm file that is in the software distribution package.   The IT administrator constructs the command line, and can include whatever switches are appropriate for the particular rpm package being installed.  In a more complex case, the command line may be a shell script invocation that is part of the package, and the shell script performs a more complex set of operations to install the content that is in the package.   Because the command line can be anything specified by the IT administrator, it is a powerful mechanism that should be used with due caution. 

A software distribution action is kicked off by creating an advertisement (or deployment).  The advertisement specifies the package/program combination that is to be installed, and a collection of computers to target.   The information about the advertisement is communicated to the management points (MP) that are part of the ConfigMgr infrastructure.  The ConfigMgr client on each Linux/UNIX computer periodically checks in with its MP to see if any new advertisements are available.  Like with DPs, the same MPs can serve both Windows and Linux/UNIX computers.   When the ConfigMgr client on a Linux/UNIX computer determines that a new advertisement is available, it downloads the package content from the appropriate DP, and then executes the program to do the installation.  Finally, the ConfigMgr client sends a status message back to the MP indicating the success or failure of the operation.   For example, if an advertisement targets a collection with 50 computers, each computer will get the package content, do the installation, and report back a status message.  From the ConfigMgr console, the IT administrator can see the aggregate results across all 50 computers.  For example, he might see that 48 computers successfully installed the package, one computer failed, and one computer reported no results.  Using that information, he knows to investigate in detail what happened on the latter two computers.

The ConfigMgr client for Linux/UNIX implements maintenance windows, just like for Windows clients.  Maintenance windows allow an IT administrator to specify time windows during which configuration changes are allowed on a collection of computers.  When a software distribution operation is targeted at a server, the server waits until a maintenance window becomes open before actually doing the installation.  So even if a software distribution operation is initiated on Tuesday, the targeted servers might not perform the operation until Saturday night during the defined maintenance window.

The overall flow of software distribution is captured in the diagram below:

Reporting

As mentioned above, ConfigMgr has a reporting functional area.   Several hundred reports are provided out-of the-box, including interesting views on inventory data and the results of software distribution operations.  These reports work for Linux/UNIX computers just like they do for Windows computers.   You can also modify the pre-built reports, or build custom reports, to suit your particular requirements.

Summary

Configuration Manager is a powerful tool for distributing and configuring software on Linux/UNIX computers.  It is based on inventorying the Linux/UNIX computers, building appropriate collections, and then targeting software distribution operations to those collections.  You can distribute software in any packaging format or directory structure, or even just run a script to perform a maintenance function.  The paradigms are the same as for Windows computers, so you get consistency across Windows, Linux, and UNIX.

The next blog post will describe a new tool for managing Linux:  PowerShell Desired State Configuration (DSC) for Linux.  You might be familiar with PowerShell DSC on Windows, but it is now available for Linux, giving you consistent capabilities across Windows and Linux.