Where are the Enterprise Management Tools for Linux on the Desktop?
On January 5, Doc Searls asked What would you use Exchange for? A good question and based on the number of comments, it is generating a lot of discussion. As someone currently embedded in a primarily Windows environment, I want to know where the enterprise management tools for the Linux desktop are?
About every three months, some new vulnerability in Windows or a key subsystem spurs new traffic across a variety of forums along the lines of if you ran Linux, you wouldn't have these problems. The self appointed prophets, zealots or kooks are generally saying this from the position of a single platform or small install base. However, when the scale of installation exceeds the number of machines you can manage manually (and that depends on how dedicated you are, in most cases it seems to be about 10 desktops) and begins to approach a number where you need a staff to manage them, then Linux as a desktop solution begins to lose its luster. This is not to say that Linux as a desktop OS is not possible, but, the management and maintenance of the desktop environment becomes the proverbial long pole in the tent and begins to chew up resources, in terms of manpower and costs.
Doc argues that Exchange has the advantage because it is good. I would disagree that it is good, but that 1) it combines a number of useful tools into a single suite application with a common UI and 2) it has several supplemental programs, such as Blackberry support written for it and thus makes it a lock in technology. When it comes to desktop management however, there are as many options in the Windows world as there are email systems in the Linux world. Sadly, there are not a lot of homogenous options for desktop management in the Linux world. This is not to say there are not any, but there is not one or two that meet most of the needs of management when they are looking for a desktop management system and fewer tools in general that support the baseline requirements or share a common UI.
I have the extra burden of having to work under what is known as the Federal Desktop Core Configuration, a series of setting applied by Group Policy to my Windows desktops. The FDCC is only one part of a much broader secure computing architecture that will soon be a requirement for all operating platforms used in the United States government. As I was walking through the process of building and implementing the FDCC image and settings, I began to think about the issues I have had over my twenty years in the industry and the requirements for managing desktops. I would argue that the following requirements always seem to keep cropping up: Patching and the verification of patches being applied; configuration managed desktop; automated application installation and verification; remote hardware and software inventory. I could dive down through the FDCC and pull up more stuff, but this gives us a framework of some of the most immediate needs.
Is there anything more important or difficult to manage than patching? In the Linux environment there are several ways to manage patching, either through external or internal repositories. But patching is more than just applying them. In an enterprise, you need to test the patch against a number of representative test stations and in many cases, wait for the howls of stuff breaking. You hope that the patch will not negatively affect anyone important, even after your rigorous testing. But in an enterprise, pushing, or making the patch available is only the beginning. You have to then close the loop and ensure that the patch has been deployed. RedHat’s new Satellite system is beginning to make inroads into this area of ensuring that the patches install but there is still a shortage of tools to do this with in the Linux world at the enterprise level and in many cases it is critical for management and security to know how many of their systems are at risk, and at what sort of risk, either in terms of gross numbers or percentage per site.
Both puppet and its grandfather, cfengine are flexible tools that manage a number of settings and configurations successfully. But certainly not easily. As we are constantly tasked to do more with less and as we continue to find even scarce resources disappearing, ease of implementation and operation is critical to the success of any management system. Being able to configure large numbers of systems quickly and correctly the first time is a critical goal.
Automated application installation
I have not done an extensive search to find tools to install applications remotely in Linux and I would like to hear about them and how successful they are. Again, like patching, deploying the application is only half the battle. You still have to report out on who got it, when, what version etc, and most importantly it has to work. It is also critical that the creation of the package not be more complicated than the application being installed. This has been one of the major knocks against using RPM-based installs for custom application deployment.
Remote Hardware Inventory
How many people have SNMP running on the workstations? All of their workstations? SNMP is one of the easiest ways to gather information about hardware but the bandwidth requirements for reporting hardware inventories, and software for that matter, could overwhelm most production networks depending on the frequencies and security requirements you have. But SNMP has its own set of problems from sketchy MIB support on marginal hardware to overwhelming MIB support on others. Finding the happy medium and the right OID can lead to sleepless nights for developer and manager alike. And then there are the security arguments for not using SNMP at all.
In all of these cases, separate tools might exist to do some of these tasks. In other cases, there are no tools to do the tasks but there are ways to get around that, either with scripts, custom programs or other creative uses of existing tools designed for other purposes. Which, in the spirit of Linux is a good thing, but in the real world of enterprise management is not so good and getting worse each day and still lacks a common UI for doing everything under one instance.
For Linux to be a player in the desktop space, especially the enterprise desktop, we need a cohesive tool suite that will do not only the work to make our jobs easier, but provide the reports that management says they not only want, but in many cases require for compliance and other legal reporting requirements. In the Federal space, it becomes even more critical and as many government contractors begin implementing the Federal Standard, it will become harder for Linux to compete on the desktop.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Three More Lessons
- Django Models and Migrations
- August 2015 Issue of Linux Journal: Programming
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Huge Package Overhaul for Debian and Ubuntu
- General Relativity in Python
- Embed Linux in Monitoring and Control Systems