Cross Platform Configuration Management is Hard
Steve Murawski
Configuration management today is mess if you work in a heterogeneous platform.
There is tooling that takes a stab at it, and is getting better (from the *nix world – Puppet, CFEngine, and Chef and from the Windows world – System Center Configuration Manager, Group Policy, among other third party application deployment platforms). These tools are all well and good, but they fall down when reaching across the OS divide. Puppet, Chef, and CFEngine (there are others as well, but these are some of the more popular) all have some cross platform support, but it feels unnatural (especially in module or recipe development).
Why is this a mess?
Windows is traditionally described as having an API oriented management model, whereas *nix has a document based management model.
Well, that’s a load of crappy, crap, crap. What does that actually mean?
It means that the two operating systems offer two different management models. The two different models have different abstractions and idioms for operating system constructs. Let’s look at a concrete example, setting a static IP on a network interface (just the rough strokes.. I’m not going to spend too much time on the minutia). As I stated before, Linux uses a document oriented management model, so to configure my network interface, I’ll edit a document or two.
The Linux (Centos) example:
- Find the correct interface file under /etc/sysconfig/network-scripts
- Open it in your text editor of choice
- Edit it to contain your desired settings for the network interface and save the file
- If you need to add/modify DNS servers, find /etc/resolv.conf
- When done, you can bring your interface online with a command line call to
ifup eth0
You’ll have something that looks like this for your network configuration file:
DEVICE=eth0 IPADDR=192.168.10.80 NETMASK=255.255.255.0 NETWORK=192.168.10.0 BROADCAST=192.168.10.255 GATEWAY=192.168.10.1 ONBOOT=yes BOOTPROTO=none USERCTL=noAnd something like this for your resolv.conf:
domain serverfault.com search serverfault.com nameserver 192.168.10.60 nameserver 192.168.10.61That wasn’t so bad, and as an added benefit, they are just text files, so I could check them in to a revision control system (Versioning FTW!). Now, let’s look at what we’d need to do on the Windows side. Since this is a blog for a community of “professional” systems administrators, we are going to dispense with any GUI example for doing this.
The Windows Server (2008 R2) example:
- Use WMI to retrieve the network adapter interface index.
- Use WMI to retrieve the network adapter configuration by the index.
- Set the desired IP address, gateway, and DNS servers and suffix against the WMI object.
You can use the following PowerShell commands to make those changes:
$NetworkAdapter = Get-WMIObject Win32_NetworkAdapter -filter "NetConnectionID = 'Local Area Connection'" $NetworkAdapterConfiguration = Get-WMIObject Win32_NetworkAdapterConfiguration -filter "InterfaceIndex = $($NetworkAdapter.InterfaceIndex)" $NetworkAdapterConfiguration.EnableStatic('192.168.10.80','255.255.255.0') $NetworkAdapterConfiguration.SetGateways('192.168.10.1','1') $NetworkAdapterConfiguration.SetDNSServerSearchOrder('192.168.10.60','192.168.10.61') $NetworkAdapterConfiguration.SetDNSSuffixSearchOrder('192.168.10.60')and
The Windows Server (2012) example:
- Set the desired IP address and gateway based on the interface name.
- Set the DNS servers and with a few more PowerShell commands.
You can use the following PowerShell commands to make those changes:
$IPAddressParameters = @{ IPAddress = '192.168.10.80' InterfaceAlias = 'Local Area Connection' AddressFamily = 'IPv4' PrefixLength = 24 DefaultGateway = '192.168.10.1' } Set-NetIPAddress @IPAddressParameters Set-DNSClientServerAddress -InterfaceAlias 'Local Area Connection' -ServerAddresses '192.168.10.60','192.168.10.61'Both of these examples are interactive commands, but I could easily save them in a file and place that under version control (and I should).
So what?
The examples don’t look all too different, but they do illustrate the difference between similar operations. In both examples, I end up with an artifact, but one is for a one time application of the setting (the Windows side) and the other is the setting storage location (the Centos example).
On the Centos box, we had to edit a file where the configuration was read from. On the Windows servers, we updated settings via a WMI API (in both cases.. on Server 2012 there are more built in cmdlets, but many of them are thin wrappers over the WMI APIs) and not the actual end storage location.
This is what
Any configuration management tool that works in a cross platform capacity needs to understand these distinctions and check based on OS type which implementation to use when configuring a system. This means for most configuration types, you’d have a big “IF” block where *nix based OS’s follow this line of processing and Windows based machines follow the other line of processing. This can become a maintenance nightmare as OS versions change the API on the Windows side or modify location and or layout of the configuration files on the *nix side.
And it’s even worse…
Now, what happens when you have a model that doesn’t translate across both worlds?
For example, how do manage file permissions?
Posix style permissions (used on most *nix variants) assigns permissions are nowhere as discreet as NTFS file permissions. In addition on Windows, the file system auditing is also configured via the permissions configuration. In the reverse, on *nix files can be set as executable, where that is handled by file type mappings based on file extensions in Windows. This fragmentation leads to more complex implementations on the side of configuration management software developers or missing feature coverage. In either case, this is a loss for the sysadmin who maintains cross platform environments.
But what if….
there was a common method of interacting with operating systems, regardless of what was running underneath? What if this method used a common transport (open standard) and communications were defined by an open standard? This is the direction Microsoft is taking with CIM and WS-Management.
CIM (Common Information Model) is a DMTF (Distributed Management Task Force) standard for describing management information for systems, networks, applications, and services.
WS-Management is another DMTF standard for management communication, focused on CIM traffic.
Microsoft has contributed to an open source project hosted by the Open Group called OMI. OMI is a CIM server that communicates over WS-Management and is implemented to run on *nix based operating systems.
I’m personally interested in where this will go, given Microsoft’s market power (Cisco and Arista are working on incorporating OMI into their network switches). The idea of a shared management model is very appealing to me, as I work in a cross platform environment. I’m responsible for our Windows infrastructure, but I have to be able to work with our *nix infrastructure as well. If I could use one model for interacting with both, that’s a huge win for me and my team.
This wouldn’t eliminate any domain specific knowledge on either OS side, as you’d still need to know what buttons to push and knobs to tweak to get things going and do some deep troubleshooting. It does, however, make the idea standardizing how various OS components can be accessed, making basic configuration, monitoring, and troubleshooting much easier.
I’m interested because…
this pushes the implementation down to the OS provider (or the CIM provider provider) and gives vendors one target to hit for configuration standards. In the Microsoft case, they can say “Follow this standard and any Windows system can manage you with minimal effort.” If other OS’s support CIM and WS-MAN as well, it becomes easy to offer management interfaces there as well.
Obviously this would be huge change to the existing way of doing things for OS and application developers, not to mention systems administrators that are invested in their existing ways of doing things.
I don’t see another good alternative though, as the numbers and variety of systems continue to scale up and “cloud” becomes more of a factor in our environments, yet the number of admins is staying stagnant or being reduced. Simplifying the management and monitoring surface makes sense in today’s and likely tomorrow’s data center landscape.
It doesn’t solve every problem and vendors can still implement vendor specific extensions (and we know how well that’s worked with SNMP).
NOTE – Be sure to check out some clarifications and expanded discussion in my followup post.
-
Warren
-
stevenmurawski
-
Warren
-
stevenmurawski
-
-
-
-
Nils Hildebrand
-
stevenmurawski
-
Matt Finnigan
-
stevenmurawski
-
-
Nils
-
stevenmurawski
-
-
-
-
Eric Eisenhart
-
stevenmurawski
-
-
Jay Adams
-
stevenmurawski
-
-
Willard Dennis
-
stevenmurawski
-
-
Andrew
-
bob thomas
-
booromand
-
heshmat
-
gita
-
sayan
-
amir
-
sabz
-
saray