For the hosts we manage, my boss has a vision of configuration management via versioned packages (in our particular case, fpm-built debian packages). This is to make:

  • host deployment easier
  • easier to track local changes
  • make bug tracking easier as in most cases, we can tag a version of software to a bug, whether it is a functional or configuration bug.

The other alternative is configuration management via Ansible, with their recommended layout as in their manual, which we are using currently. We install versioned packages of software (pretty much all web services), which would be responsible for it's own package-specific configuration, and leave Ansible to system-wide configuration. Updating hosts software is simply a matter of bumping version numbers and rerunning the scripts. We rely heavily on the "var_prompts" functionality of Ansible to ensure we keep sensitive information separate from the configuration.

In the "configuration management via versioned packages" case:

For deployment, we just bring up a minimal server (proxies etc) and use a package manager (apt in our case) to install a single umbrella package, that would install all the dependent packages. Making a change to any of the dependent packages would simply bump up the top most package version, making it easier to update existing deployments.

For configuration, each software package would have an accompanying "config" package, to allow changes to configuration only. Each package would have independent configuration files, to prevent conflicts between packages when we verify local changes on the host. Instead of running commands that generate config, we would ensure that we would have the generated files as part of the package, but still allow running of commands via the pre/post install scripts. AFAIK, there aren't a great number of cases where we have packages that will rely on the same configration file, but if that is the case (which would be the case for system configuration), we would have another package that would have a dependency on both. I can see this particular case getting out of control, but this could be controlled by always ensuring independent config files. In the end, each host would have their own unique config package. Obviously, all these files would be under source control, and we may spin up our own simple templating system, so that we can also have the flexibility of Ansible roles.

I am curious why I cannot find any information/analysis on this type of workflow for configuring and deploying hosts. Am I missing something fundamentally flawed with such an approach, in comparison to existing configuration management tools?

  • Have you not considered hosting your own repository internally?
    – eyoung100
    Dec 30, 2014 at 20:28
  • I would think it's because host management is a complex issue, and people tend to pick one specialised tool and stick to it (such as puppet or ansible), instead of mixing up approaches. I, however, do mix things up. My configuration packages set things up for some core settings and then leaves the rest to puppet.
    – muru
    Jan 1, 2015 at 15:51
  • @chuckus: I had the same idea for my private machines and implemented a minimalistic configuration management on top of the package manager: holocm.org (see github.com/majewsky/system-configuration for a complete example) Oct 14, 2015 at 9:39

1 Answer 1


Package managers are not really effective for configuration managment for a few reasons:

  1. Most packages contain a configuration when installed, so you'd have to make custom packages that have them removed.
  2. Package managers work under the assumption that the package installs a basic configuration that can be changed within the system. So if a package is reinstalled/upgraded, it usually prompts the user on what to do with the modified file (which is not an ideal behavior for a configuration manager).
  3. Package manager do not test the system against the package contents usually, and although some have that option, it's not efficient as it's not a feature that is often used.
  4. A package life-cycle is more complex and longer than most of the automated configuration tools, so it's more work to maintain such a setup.
  5. Package managers do not care about order of installation so if you have a case of package dependency of a->b->c and you have package c installed already and you install package a, package c will not be reinstalled and packages a and/or b may overwrite c's configuration.

If you insist on using package managers to maintain configurations, I'd suggest you'll check the option of using a standalone configuration management system like puppet or chef in their standalone mode with a package for their configuration, this way you'll have all of your configuration in a single versioned package but in a way that does not require the package manager to manage the configurations on disk, which can lead to problems as I listed and probably some more.

To clarify, it should be possible to do what you planned, just the package manager is not the ideal tool for this.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .