Home / server / Questions / 197834
In Process
Rob Spieldenner
Asked: 2010-11-04 10:04:24 +0800 CST

What configuration management solutions exist in a non-networked environment?

  • 772

My servers exist in an environment without outside network connectivity (this is a requirement), so when I deploy updates all packages, binaries, config files, etc. must be included on the delivered media. And of course I want some sort of configuration management so I can tell what has and hasn't been installed.

So I was wondering if people had experience with chef, puppet, or another configuration management type tool for dealing with this type of environment. Worst case I deploy my updates as an RPM.

EDIT:

My setup has both Linux servers and Windows servers.

puppet configuration-management cfengine chef

4 Answers

  1. I've personally used Puppet and cfEngine are have found both to be good tools for this kind of task and I believe them to currently be the major players in the field. Puppet requires a little more care when you start trying to scale it but has a nicer syntax, cfEngine scales well but it can take a bit more time to learn the voodoo. If the no outside network connectivity includes any other servers you can control, both are capable of caching their catalog/configuration in the case they can't reach a master server, being their own master server, or of running only on demand, so they should both handle the no-network requirement. If it's okay for them to reach an internally managed server, this is definitely not a problem.

    A guy I work with swears by bcfg2, but I haven't done any work with it. We're currently using Puppet at my place of work, for whatever that's worth.

    Each has it's strengths and weaknesses and your choice should largely depend on any other requirements you might have. You could take a look here for a basic run-down of the more common and more obscure options you have.

    • 3

  2. I'm assuming you've got a large chunk of servers running in an offline environment for security reasons (these reasons becoming more and more common). Having encountered a very similar situation myself. The real answer to the question it dependendes what your architecture looks like.

    All the usual players (Chef, Puppet, CF-Engine, Salt, Annsible) will all work in an offline environment however certain things that work normally won't and will get in your way (e.g. puppet auto downloading module requirements from the forge won't work). However depending on what versions of the software you are using there are workarounds. For Puppet (if your using v3) I would suggest using r10k to help mitigate the problem (I believe v4 has it included).

    What @David has said for puppet is also very good advise. Now matter what you are using I would suggest the following that I've found will make your life so much easier:-

    • Try to avoid hard codding data into configuration (i.e. if your using puppet use hiera).
    • Do as much dev on a networked environment as you can (that way then you don't need to worry about dependency problems when your developing
    • If you can use client-server mode for most systems do so, as the local running modes do create some additional complexity that's a pain if you can't avoid it.
    • (Chef/Puppet) If you've got a local repository server see if you can get it set up to serve the cookbooks/modules in-place of an internet connection (like you would with Maven)

    From the windows perspective (assuming your using a recent version) have a look at using Windows DSC + Powershell, as at least Chef and Puppet have cookbooks/modules that can interact with it to configure windows components (and anything else you can do with Powershell).

    If it helps have a look at my answer for my own question here, as this was one of the "other" deciding factors.

    In general you'll to evaluate each tool against your own needs, but most cases I've found that there does seem to be some community solutions for any of the problems that mitigate anything issues you might have.

    • 1

  3. I've been playing with disconnected Puppet recently for remote environments where I can't have a master server. In particular, this article has been helpful to me and it's probably worth a look for you if you decide to go the Puppet route.

    You can set up a normal Puppet structure under /etc/puppet and then run puppet manually. So far I haven't figured out how good the logging and reporting would be without a master.

    This has been my best friend during development/testing:

    puppet -d -v --modulepath=/etc/puppet/modules /etc/puppet/manifests/site.pp
    • 0

  4. Salt allows you to provide alternate locations for your packages.

    mypkgs:
  pkg.installed:
    - sources:
      - foo: salt://rpms/foo.rpm
      - bar: http://somesite.org/bar.rpm
      - baz: ftp://someothersite.org/baz.rpm
      - qux: /minion/path/to/qux.rpm

    In this example these packages will be installed from the indicated location:

    • foo will be installed from the rpm on the Salt file server
    • bar will be installed from an http location
    • baz will be installed from an ftp location
    • qux will be installed from the local file system
    • 0