Rolling Out the Red Carpet for Software Management: Red Carpet EnterPrise 2.0
Articles and Tips: article
01 Mar 2004
Administrators have long trusted ZENworks for Windows and NetWare resource management tasks, but until recently they haven't had an enterprise- class tool for managing a large deployment of Linux systems. Resource management tools are especially important for Linux systems, given that open source software is often released on an accelerated schedule, requiring more frequent upgrades. And even though Linux has a justly deserved reputation for stability and security, no administrator can afford to be complacent about security updates. Most Linux distributions include an update tool, but that only updates the distribution itself. Deployments with third-party or custom-built software products then require additional updating and maintenance work on the part of administrators. It's no wonder that many Linux administrators spend 5-10 hours a week per user just updating systems.
To address the Linux software management problem, Novell offers Red Carpet Enterprise, the market-leading Linux management tool and a component of the Novell Resource Management solution. Red Carpet Enterprise is one of the products that came into the Novell solution lineup with the acquisition of Ximian. Red Carpet Enterprise provides a centralized management console to handle software updates, new installs and removals from any number of Linux systems. It comes in two pieces:
Red Carpet Client
The Red Carpet client is a daemon (rcd) with command-line (rug) and graphical (red-carpet) control tools. All three parts of the client software are free and open source, and function as basic updaters for individual systems.
Red Carpet Enterprise Server
The back end can be manipulated through the rcman command or the Web interface. It communicates with clients through SSLencrypted HTTP connections.
What Can Red Carpet Enterprise Do for You?
Suppose you have in your organization a large number of Linux machines, a large number of individual software packages and several network administrators. Red Carpet Enterprise lets you sort and organize them, and set the access that they have to each other. In the language of the Red Carpet Enterprise database, each is an object. For each object, you may set permissions: View, Modify or Grant Access. For example, if you have two groups of machines, you may want some administrators to work with the first group, and other administrators to handle the second. The administrators will have the ability to View all machines, and permission to Modify only the machines they administer. But they can't Grant Access to those machines, so they don't create security holes by giving everyone permission to change software in your server farm.
Similarly, you can divide software into channels and make each channel available to one or more groups of machines that are administered by one or more administrator accounts. Each channel is also available for one or more specific operating system and/or hardware combinations such as Red Hat 8.0 and 9 on x86 hardware.
As you add more machines, you can assign profiles so that they fall neatly into the organizational scheme you've already set up. A profile consists of the settings applied to a given machine when it registers with the server, such as membership in a group of machines, access to channels, participation in scheduled updates or assignment to an administrator.
Once you have organized your network and set the various access levels, you can start delivering software through the channels to the individual machines. Each delivery of software is called a transaction and there are three kinds:
Basic Transactions install or update software. They can occur one time or on a regular schedule.
Rollback Transactions revert to a previously installed version of software.
Pre-Position transactions let you set a download time apart from the install time, so you know that installation will occur exactly on schedule, and won't flood the network with downloads all at once.
Packages, Channels, Machines, Transactions
All packages come in channels, to which individual machines can be granted access. To create a channel, all you need is a name. To add a package to the channel, simply upload it and provide the names of the operating systems and hardware platforms on which you want to make it available. You can also use the rcmirror tool to copy software channels from Ximian or other vendors and distribute it from your centrally managed server.
Similarly, individual machines can be arranged into groups, and all you need to create a group is a name to apply to the machines. Alternately, you can search through some or all of the available machines and create an ad-hoc or temporary group. (See Figure 1.) Because selecting a set of machines is so central to resource management, the machine search tool is available on the front page of the Red Carpet Enterprise Web interface.
Individual machines can be arranged into groups, and all you need to create a group is a name to apply to the machines. Alternately, you can search through some or all of the available machines and create an ad-hoc or temporary group.
Figure 1
To use the machine search tool, define a rule in the drop-down lists. Add additional rules by clicking the Add button on the right side of the page. A search rule might be as simple as the host name containing the word "server," or as complex as finding i386 systems with less than 256MB RAM which are running Evolution 1.5, the Ximian e-mail client.
After selecting systems and software, all that remains is the transaction. To create a transaction, go to the Transactions page in the Web interface, click New, and follow the instructions to select a transaction type, start time, and the channels and packages to update or install. (See Figure 2.)
To create a transaction, go to the Transactions page in the Web interface, click New, and follow the instructions to select a transaction type, start time, and the channels and packages to update or install.
Figure 2
TIP Check and test your shell scripts carefully before you upload them, because they run as root. It's best to write scripts that work in a general case, because once they are uploaded you can keep them for use in future transactions.
Suppose a particular combination of kernel, drivers and graphics card is causing instability in some 3D graphics workstations. The network administrator has determined that a new kernel will solve the problem, but doesn't want to install the new kernel on all workstations- just the ones using the unstable graphics cards.
The first step is to place the kernel package in a channel, which is simple enough to create. Because this is a one-time update, the administrator creates a single channel, rather than adding the kernel to a frequently used channel, which might eventually lead to an accidental install. When the administrator adds the package to the channel, Red Carpet Enterprise recognizes it as a kernel package and marks it for special installation treatment, updating the bootloader and keeping the previous kernel package in case it is needed later.
In addition to installing the package, the administrator needs to make sure the machines use the kernel once it is in place, i.e., ensure that the machines reboot after the install. Instead of logging in to each machine, or worse, walking over and physically pushing buttons, the administrator uses a simple shell script:
#!/bin/bash /sbin/reboot;
TIP Note that Red Carpet Enterprise does not manage the users of a network. It is the administrator's responsibility to alert users to an upcoming upgrade, reboot or software change.
With the channel created, the administrator can search for the affected systems and add them to a temporary group. The next step is to add a transaction to that group. After choosing the start time and noting that the transaction is not to be repeated, the administrator selects the sole package for installation, and the previously uploaded script for execution after the transaction runs its course.
When the transaction runs, the server sends a message to each individual machine, stating that it has transactions ready to be deployed. To avoid jumping on the server all at once, the machines begin downloading at randomized intervals within a few minutes of the selected start time. After download and install, the systems reboot.
Variations on the Transaction Theme
A simple transaction sends a package out to one or more clients, but transactions have a much greater variety of capabilities. The first you should know about is the ability to distinguish between an update and a new install. The difference is that an update installs a new version only if a previous version is already installed. To install software where no previous version has gone before, you need to specify a new installation. You can perform both new installs and updates in the same transaction.
You can use this distinction to your advantage to deliver security updates only to users who need them without having to specify each update individually. In the previous example, the administrator performed a search for all systems with a particular piece of hardware, and then updated those machines. However, if you have a steady stream of updates for a large number of packages, it may become inconvenient to set up new groups each time.
Imagine two groups of machines, one for general office use and one for software development. Both groups use the same distribution, but have different applications installed. On the engineering side, the individual users have root access and install software at will. To update individual applications in the same way as the previous example would mean checking each system's software against a list of new updates, then creating temporary groups and transactions for each security update.
Instead of doing each update individually, you can create a transaction to update all the software in the channel on a regular basis. Given a channel containing your base operating system packages, create a transaction to update that entire channel and set it to recur each night after the office closes. Then, when a new software update becomes available, you only have to add it to the server. If an individual machine has the old version installed, it will update to the new version. If an individual machine does not have the software installed, or if it already has an equal or newer version, nothing will happen.
Another use for repeating transactions is to enforce a particular set of packages on a group of machines. Especially in development or testing labs, users might spend a day mucking with systems, installing new or unstable software, removing core packages and generally trying to find out how to break their perfectly good configurations. At the end of the day, you can schedule transactions to revert unauthorized upgrades, installs or removals.
TIP Dependency resolution is normally performed by the client, but if you prefer to keep the load off your clients, you can pre-determine the validity of a particular set of packages on the server side. Server-side validation is part of the transaction creation process. For more information, see the Transaction section of the Red Carpet Enterprise manual.
Package Sets
You can sort software into a channel, such as SUSE LINUX 9.0 or Ximian Desktop, but channels do not provide a way to interact with multiple packages at once. If you want to be sure that a specific group of packages are handled as though they were a single package, you need to use package sets as well as channels.
A package set is somewhat similar to a "task" in meta-packages from the Debian distribution. As the name implies, it consists of several packages bundled together. In addition, the administrator can add more metadata to the set, so that the machine installing it will have to satisfy all of the requirements for the individual component packages, and also the requirements set by the administrator.
Package sets help enforce version requirements, so you can be sure that everyone is on the same page. For example, if you put Python 2.1 in a package set, Red Carpet will ignore available upgrades to Python 2.2 unless the client's root user deliberately upgrades that specific package, or the network administrator changes the version specified in the package set.
You can also use package sets to prevent people installing particular programs or classes of programs. Simply require the installation of a package set which conflicts with the programs you don't want. The package set doesn't even need to have any actual packages in it.
Of course, a user with root access to a machine could remove the package set and install prohibited software, but the network administrator can easily switch the system back by reinstalling the package set if it is absent. If you create a scheduled transaction requiring package removal, be sure to select the "Allow Package Removal" check box in the Transaction Creation screen because transactions that require removals will fail automatically under normal conditions. After the scheduled transaction time, you can confirm that your transaction worked properly by using the Report tool.
Reports
The Red Carpet Enterprise Report tool helps keep track of the machines in your network. The software includes a set of pre-built reports for the most common tasks: keeping track of the recent transaction successes and failures, for example, or alerting you when disk space runs low. You can also build custom reports that display an almost infinite range of data about individual systems.
To create a report you define a set of columns and a set of filter rules. The rows are always represented by client machines. Columns determine the sort of data displayed about the machines, and the filter rules determine which machines have information in the report.
For example, you might choose to display machine names, IP addresses and disk space as columns. By creating a filter, you could show systems which have an address in a particular block, or which have a particular percentage of disk space free. Machines which don't match your filter rule don't appear in the report.
Or, as a more practical example, you might have a 16-seat license for an expensive piece of proprietary software. You want to make sure that only 16 copies of the program are installed anywhere in your network. Therefore, you create a report showing machine names, IP addresses, and administrators, so you know how to find the machines and who is responsible for them. You can then filter the report so that it displays only machines which have the software program installed, and count the results to find out if you're in compliance with your license.
Dependency Analysis by Hand with Rug and Rcd
As an administrator, you may at some point want to ssh into a particular client and work directly with the rcd and rug tools. In those cases, you'll be resolving problems like dependencies that aren't declared in package metadata, or requirements that aren't always available on your server.
When you need detailed package information, the default package query tools in rpm can be cryptic and difficult to remember. Instead, you can use the rug commands, such as info-provides, info-conflicts, info-requirements and what-provides. Enter the command below for a complete list of rug commands:
rug --help
For example, if you need to install a Web server, but aren't sure of the exact package name you need to install, you can search for software that meets that requirement. The command below will tell you that, for SUSE LINUX 9, you can install apache, apache2 or thttpd to get a Web server.
rug what-provides http_daemon
Be careful when using this command: only apache2 and apache are listed as providing httpd, so once you find a program you want to install, use the command below to see if there is another value for which you should search.
rug info-provides
Once you know the package or provided feature, try using the command below.
rug solvedeps
The standard rug install and rug remove commands allow you to pick a package, but rug solvedeps also lets you name libraries and executables that you want installed or removed. It does this by creating a virtual package within the rcd resolver, then trying to resolve any conflict or dependency problems that result. After resolving the problems, the resolver removes the virtual package, leaving the changes in place.
For example, you can specify a particular version of any program, in this case Nautilus 2.2.3, with the following command.
rug solvedeps "nautilus = 2.2.3"
Alternately, you can specify version relationships like package dependency data does as in the following command.
rug solvedeps "nautilus > 2.2.4"
The Future of Novell Resource Management
Whether it's a simple OS update or a complex deployment of thirdparty and in-house software, Red Carpet Enterprise offers easy-to-use, low-cost resource management for a range of Linux distributions and network architectures. (See Figure 3.) The future is even better. The next release of Red Carpet Enterprise, code-named "Birdman," will include several major new features, including deployment of Linux operating systems from scratch, configuration and preferences lockdown.
Whether it's a simple OS update or a complex deployment of thirdparty and in-house software, Red Carpet Enterprise offers easy-to-use, low-cost resource management for a range of Linux distributions and network architectures.
Figure 3
Most important, the integration with ZENworks forms a complete resource management solution for Windows, NetWare and Linux. The world of software updates never stops, but Novell Resource Management offers a complete and effective way to manage change, opening up the agility and freedom of Linux for your enterprise.
A Word About Packaging Systems
Most Linux software is packaged in RPM or DEB format which is an archive containing a particular set of files, plus metadata describing where they go on the system, and a list of any required or conflicting software. For example, the libxml 1.8 package on SUSE LINUX 9 contains 32 files installed in the /usr/lib and /usr/share directories; requires the core C library glibc, the compression library zlib, and the bash shell; and conflicts with any version of the libxml-devel package other than 1.8.
Every library and program in a contemporary Linux system is part of a similar package that declares its dependencies and conflicts in the same way, and the packaging system enforces those dependencies. The dependency resolution requirement for packages prevents unexpected or unexplained software failures known in the Windows world as "DLL Hell," but introduces the new problem of resolving nearly impenetrable dependency trees.
If you want to install a package that has unmet requirements, or conflicts with another program you have installed, you have two options: solve the resolution puzzle or force the package to install. Solving the puzzle can be time-consuming, but forcing an install, like forcing a piece into a jigsaw puzzle, is usually a bad idea.
Fortunately, the dependency puzzle is essentially a big math problem that can be handled by a clever piece of software rather than by painstakingly searching for each required package. The Red Carpet resolution mechanism resolves conflicts and dependencies, automatically "pulling in" required packages from a repository. For an individual, that repository is the Ximian Red Carpet server, but for an organization with its own strictly defined needs, it's an internal Red Carpet Enterprise server.
Open Carpet: A Non-Eenterprise Server for ISVs and Power Users
If the repository run by Ximian or your Red Carpet Enterprise deployment doesn't ship the software you want, you can go outside the system to servers running the open source Open Carpet server. Similar to Debian's apt servers, Open Carpet serves packages and conflict resolution metadata, but has no centralized management tools. Instead of being a centralized management system, it is intended to be a convenient way to offer software and updates to the general public. For details on the project, visit www.open-carpet.org.
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.