Here's a scenario. Among the systems administrators (SAs) in your company, you're the exception, not the rule. You cut your teeth on Unix, you keep up your Unix skills, and you still favor Unix in many respects.
But you're also a pragmatist, and probably a parent with mouths to feed, so as Microsoft has become more and more prevalent on the server side of the network, you have added to your skill set by joining the hundreds of thousands of other Microsoft-Certified Professionals worldwide. The reason why you're an exception at your company is because most of your SA peers have limited, if any, Unix experience - most are strictly Microsoft Certified.
One day your boss comes to you with a "special project." He's aware of your Unix background and of the similarity between Linux and Unix, and he noticed that you left the office before midnight two days in a row. Concluding that you have some spare time, he asks you to research and report back to him on the feasibility of migrating your company's network services from Microsoft to Linux. Most likely you answer with the following: "Boss, we can definitely save money in licensing fees by moving these services to Linux, but there will be a significant cost to train our team on Linux administration or to go out and hire some new people who already have these skills. And oh, by the way, finding these people may not be easy, since there are about 10 times as many Microsoft-Certified engineers as there are Linux-Certified engineers."
This scenario is validated by the major studies of IT infrastructure total cost of ownership. For example, IDC provides a good summary of the cost/benefit analysis IT executives face when considering migrating to Linux.
There are many reasons why Linux is an increasingly attractive choice for users. One is cost of acquisition: if hardware and software costs are critical decision factors, Linux solutions on Intel architecture can offer attractive price points, particularly when compared with RISC/Unix system configurations.
On the other hand, if administration, operations, training, and other staffing costs are critical factors, Linux may or may not be mature enough for deployment. IDC notes that organizations having strong Unix expertise will be immediately comfortable with Linux and will likely find the cost of ongoing support to be similar to or less than that of a Unix platform. But organizations with deep experience in a Windows environment may not be as comfortable with the approaches used by Linux and may therefore face a steep learning curve.
"Expanding Linux Systems Configurations for Enterprise Deployment." An IDC White Paper Sponsored by Veritas and IBM, 2003.
While the results of this analysis will certainly vary from company to company depending on the number of services they plan to migrate to Linux and the depth of Linux/Unix experience on their IT bench, one conclusion that seems certain is this: in order for Linux server deployments to continue to grow at the pace set in 2003 and in 2004, Linux has to grow not just in lieu of Unix sales, but increasingly instead of Windows. To do this, new tools are needed so that IT groups with a predominantly Windows skill base can quickly become comfortable managing a Linux infrastructure.
Still, in medium, large, and/or distributed IT environments, there is a gap in functionality. Once the Linux server applications are deployed, the dependencies checked, and the patches applied, there is an ongoing need to provide SAs with an intuitive way to implement configuration changes to the services running on their Linux servers. Historically, the Linux space has lacked the tools that enable centralized, GUI-based configuration management with such features as the ability to group distributed servers and then apply configuration changes to one server, a group of servers, or all servers simultaneously. This functionality gap is depicted in Table 1.
Today, for example, if an admin has a trusted GUI for Sendmail, any configuration change can only be made to one server at a time. If the change must be made to multiple servers, as with clusters or with regional/global configuration changes, the exact same change must be made to each and every server. If the administrator does not use a GUI but rather edits the .conf/ file manually, this too must be done on all the servers to which the change is to be applied. Not only is this approach time-consuming, but if an error should be made, the process of finding and fixing it can be equally, if not more, time-consuming.
Some experienced Linux/Unix administrators write custom scripts to lessen the time required to make changes across multiple servers. While this approach can work well, one downside is that unless the scripts are widely understood across the company's IT department, the scripts designed to make the IT staff's job easier can become a major disruption if/when the admin who wrote them leaves the company, gets sick, or goes hiking in the Himalayas for a week. In addition, while scripts can be very useful for the SAs who write and use them, they generally don't provide IT management with the auditing, control, or rollback capabilities that are becoming increasingly important.
A new kind of tool that we refer to as enterprise-class configuration management can satisfy the Linux, Unix, and Microsoft Administrators' need for a simple way to make changes across multiple Linux servers, while providing IT management with the control, auditing, and rollback capabilities they need. Granted - the term "enterprise class" is to IT solutions as "tough on crime" is to politicians - everyone says they are, but what does it really mean? Here's what we mean: flexible to adapt to your organization (not vice versa); secure so you can control, audit, and rollback changes; and powerful to enable you to make configuration changes to one server, a group of servers, or all servers, and to let you implement the changes immediately or sometime later. As a result of these capabilities, enterprise-class configuration management tools deliver the following benefits:
Wade Olson, CIO of application integration and wireless data collection firm Core Function and long-time Linux user and advocate agrees, saying:
As strong proponents of the broader use of Linux and other open source technologies in corporate environments ourselves, we find the development of centralized configuration management solutions to be a very positive advancement. The lack of such configuration management solutions has been a major hurdle in achieving a broader level of corporate adoption for Linux. The fact that robust solutions of this type are now becoming available represents a huge step forward for Linux and for the open source movement on the whole.
When a particular configuration change causes or coincides with an undesired result, the ability to roll back to previous configurations must exist. In addition, as IT departments conform to new regulatory mandates, such as Sarbanes-Oxley and HIPPA, the auditing capabilities of configuration management tools take on even greater importance. In light of the new regulatory scrutiny of network operations, IT managers also need an easy way to ensure that administrators are only given permission to implement changes on the services and/or servers for which they are responsible. This capability is often referred to as role-based login, and it's vital for managing accountability and to ease the establishment of audit trails.
Part of the flexibility requirement is also satisfied through extensibility. Take this typical situation: a university IT manager would like to leverage more of his staff in the beginning of each semester to add new students to the network. Unfortunately, he has no way to abstract the complexity of LDAP, e-mail, DHCP, Samba, and Apache in order to enable his less experienced administrators to contribute to the twice-a-year onslaught. An extensible configuration management solution with open APIs would let him write a custom interface that would largely mask the complexities associated with providing the Class of 200x with e-mail, file and print permissions, Internet and intranet access, and so on. With this interface in place, more of his IT staff could help out with the biannual New Student Network Access Add-athon, thereby saving the expertise and sanity of his senior systems administrators for more strategic activities.
Obviously, these two meanings are oceans apart, even though they're being applied to exactly the same term. Though we probably have a long time to wait before the industry settles on a common set of terms and definitions, the important thing is to get past labels and really understand what the tools you're considering actually do.
A Word on Price
When looking at tools to help you manage a Linux network, make sure the tools aren't so expensive as to undo the savings gained from adopting Linux and open source in the first place. On this point, price is clearly of primary importance, but you also want to look closely at the tool's licensing model to make sure it's simple. A simple licensing model is always preferred over a complex one, but it takes on special importance here since one of the major soft cost advantages of Linux and open source is the freedom they give you from having to count users. Don't undo this benefit by purchasing a tool that imposes a complicated or otherwise onerous licensing scheme on you.
SIDEBAR
Emu Software's NetDirector centralizes, simplifies, and secures the configuration management of Linux servers running open source applications for HTTP, DNS, DHCP, Samba, e-mail, and FTP. Future releases will add management support for databases, OpenLDAP, NFS, and Cups. The tool, which is based on a scalable and secure client/server model, has three primary components: server agents that reside on each server under management and are responsible for receiving and implementing configuration changes, a server manager that maintains the status of each server agent and receives and relays user commands for configuration changes, an intuitive GUI that allows the grouping of servers according to virtually any organizational criteria (e.g., geography, service, or workgroup), and the simultaneous editing of configurations across any number of servers and/or groups of servers.
For example, a system administrator may need to decrease the default lease time-outs for their DHCP servers in the Northeast in response to a recent corporate acquisition and the resulting surge of clients requiring IP addresses. With NetDirector, this is a simple three-step process. First the administrator selects DHCP from the service list. NetDirector then displays only the DHCP servers in the server list, where he selects the server group Northeast. The administrator can now reduce the default lease time-outs to the desired new setting and when he hits apply, the change or changes will be implemented across all the DHCP servers in the Northeast network segment. In the event of a misconfiguration, NetDirector logs all changes and enables rollback to the last known good one.