Getting “the Linux guys” to accept (or even tolerate) Windows-based management

I hear this same question over and over in the forums, email discussions and face to face with lots of different groups: “How do I convince the Linux admins in the company to work with us on implementing Operations Manager to monitor the Linux machines too? From a cost savings and compliance perspective, having a single management infrastructure is definitely a benefit to everyone involved. You only have “one pane of glass” to look through to see how your entire IT infrastructure is operating, whether it’s Windows, Linux or UNIX. This is the benefit of Operations Manager R2’s cross platform support for UNIX and Linux platforms. The problem is that there’s an inherent protectionism among Linux admins that puts up an invisible force field around the Linux servers so that “the Windows guys” don’t touch them. It’s not that the Linux guys are just being angry, spiteful admins – they just want to protect the machines they’re responsible for, and face it Windows guys, you just don’t know a lot about running a Linux server. Now it’s true that the Linux guys probably don’t eat lunch with the Windows guys, and they don’t pal around together after work, but they don’t hate you. Honest, they don’t.

When I started working on server deployment tools for HP about 10 years ago, we started talking about automating network switch configuration along with server deployment. Back then, it was the same thing…”How do I get the network guys to trust this tool? They have their own tools and don’t want some outside deployment process to go messing up the network.” The push-back was the same then as it is now, but I believe that the differences between Linux and Windows server management are much smaller than between server and network management differences. We all want to monitor the same things – overall system health, performance, disk space, utilization. The difference is the commands used and the location of information. Fundamentally, server management is server management, regardless of the OS. The only difference is in the fine details.

Ok, so how do I answer the question? How do I get the Linux guys to accept using Operations Manager as the default management tool? It has to be a top-down and a bottom-up approach. From the top down, management in the company has to issue an edict that there will be a single management infrastructure. They know this will save money, save admin resources, and make the overall health of the company’s infrastructure better, because everything will be transparent, through “one pane of glass”, and resources will be used to build and extend additions to that management infrastructure just once, not once for each management infrastructure in place. From the bottom up, you have to involve the Linux guys in planning and architecture. Have them provide an analysis of their current Linux tools versus the System Center capabilities, and feel free to say if there are things that their current tools do better. The goal here is getting everything out in the open. Once that happens, you can discuss how to extend or modify the System Center tools to suit the needs of Linux management. Many times, they’ll end up with something much better than what they had before.

One thing that always appeals to the Linux guys is when products are open source. Linux admins want to know that things aren’t hidden under the covers, and that if they want to change the way something works, they can (but most likely won’t) go modify code and make it act the way they want. The cross platform solutions for Operations Manager 2007 R2 leverage open source and open standards. We utilize OpenPegasus as the CIM server, which is completely open source. We’ve even submitted enhancements back to the Open Group to include in OpenPegasus 2.10 coming out next month. We also provide the source code for our CIM providers on our site on CodePlex and we’re also starting to build a community extensions project as well.

Aside from the purely social or political aspect of the issue, we can also address the technical side. Many times Linux admins object to the requirement that root privileges are required to run the agent and the CIM server, and also object to yet another agent on their machines. I’ve discussed root privilege requirements before, but suffice it to say that root requirements are nothing new. OpenPegasus itself requires root, the PAM requires root to authenticate other users, some kernel APIs require root in order to collect the performance / monitoring data needed, and the agent needs to impersonate other users (like when a low privilege user runs a command, a process is spawned as that user). All of these things that are relatively normal in monitoring require that we have root level access. That said, we are working to enable sudo access in more situations in the next release.

If the remaining objection is that they can’t use a Linux/UNIX-based tool to monitor these machines, we can also point them to our connector solutions for HP OVO, Tivoli, or even the universal connector that will let them share data with virtually anything.

More often than not, objections from teams in implementing anything new are caused by (1) fear of the unknown – they know their system and don’t want change, and (2) anger at not being involved in the decision-making – being told by “the Windows guys” that they will implement something and they don’t have a say. It’s too easy to get put into camps of IT administration with Windows on one side and Linux on the other. Let’s build some bridges and get people communicating! Above all, let’s be more efficient by working on a management system that crosses the boundaries between the different platforms.