Not Running VMware Capacity Planner as root on Linux

I’ve recently been working with VMware Capacity Planner project in my organization. It’s a useful tool in proving what I already know: that the physical hosts in my data center don’t do anything. 🙂

The Capacity Planner Data Manager is a software component that you install at your site on a Windows host (in my case a virtual machine). It gathers data from your hosts, sanitizes it, and relays it or stores it for relaying to VMware’s data warehouse (where it’s analyzed). One of Data Manager’s features is that it’s agentless, and will just SSH into my Linux hosts and gather what it needs.

Problem with that, though, is that it wants to log in as root. All the documentation says to have it log in as root. But on my hosts nobody logs in as root, unless there’s some big crisis happening.

So I started messing around with it. As it turns out, at least under Red Hat Enterprise Linux, most everything that the Data Manager needs to do can be run as a normal user. The few commands it needs to run that require root are ethtool, mii-tool, and dmidecode. So you have a few options:

1. Grant the user sudo rights and change the scripts that run to use sudo for just those commands. On the Data Manager machine the scripts are all stored in C:Program FilesVMwareVMware Capacity Plannerscripts by default, and you can just edit them to use sudo. Depending on how you do your user and rights management this could be either very easy or very hard.

2. Make those commands setuid for the duration of the exercise. Doing something like “chmod +s /usr/sbin/dmidecode” will make it run as its owner, which by default is root. When the data gathering is over you can just “chmod -s” those utilities again. This is more risky than allowing sudo rights, especially if you have a lot of users on your machines, because suddenly users can change network settings, etc. or even worse, trick dmidecode into doing something as root that it shouldn’t do. In my case I have very few local users on my hosts, and they’re all fellow admins with sudo rights, so the risk is a lot lower.

Another option is that you could make these setuid, do the inventory, remove the setuid bits, and then deactivate the Data Manager daily inventory job. No problem.

3. You can also copy the Capacity Planner scripts out to the hosts, and tell Data Manager where to find them via the Options. This might open up some options, as you could mess with the permissions on the scripts, either via chmod/chown/chgrp or via ACLs, to make them setuid but not readable/runnable by anybody but your Capacity Planner user.

There are some definite pros and cons to each, and a lot of it depends heavily on your environment. Personally, I was looking for an easy way to make this work and be able to revert any changes once we were done. It’s like “Leave No Trace” camping, only with servers.

Beyond figuring out how I was going to let it run dmidecode, ethtool, and mii-tool, I did the following:

1. On all my hosts I added a user with the same username and password so that I wouldn’t have to mess with entering hundreds of separate username/password pairs. This also means I can run one command via Capistrano to add the user, and in a month I’ll run one command to remove it again.

2. I use the pam_access.so module in /etc/pam.d/sshd so I added a line to my /etc/security/access.conf to restrict where the logins could come from:

-:vmcap:ALL EXCEPT 192.168.100.15 192.168.100.16 192.168.100.17

This denies the ‘vmcap’ user from logging in anywhere but those IP addresses.

3. I instructed VMware Capacity Planner Data Manager to sanitize the data it sends to the Capacity Planner dashboard, so that IP addresses and names and the like are stripped out.

As a result of all of this I am okay with, and more importantly, my security officers are okay with having Capacity Planner running in our data center for a month.

I’m pretty new to Capacity Planner overall, and a lot of my knowledge of it is derived from dissecting the inventory and performance gathering scripts, as well as trial and error. As always, if I missed something here or there’s a better way to do something let me know in the comments. Thanks!