best configuration management tool for FreeBSD?

Matthew Pherigo hybrid120 at
Wed Apr 30 21:47:59 UTC 2014

> On Apr 15, 2014, at 5:33 PM, Aleksandr Miroslav <alexmiroslav at> wrote:

> hi,
> We have a few (~15) FreeBSD boxes that we are running here. They are
> all running 8.4, but they are up to date on their ports/patches.
> We have some custom shellscripts (along with rsync)  to deploy our
> code and and content, but we recently decided to use a proper
> configuration manager tool to run our cluster. Internally, we've had a
> lot of debate about that and have no clear winners (puppet seems to
> get the most votes though).
> What is the best configuration management tool for FreeBSD? We make
> heavy use of installing things from ports, so any tool that
> understands how to install upgrade stuff from ports would be great.
> Thank you.
> Alex
> _______________________________________________
> freebsd-questions at mailing list
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at"

Hey Alex,

There are several different options for that available. There's Puppet, Ansible, CFengine (much older than all the others), Chef, Salt, and a few others.

All of these things are going to handle at least 90% of what you could want to do with your systems with only some very specific features being present or not present. With that in mind, however, a big part of choosing the right solution is not just what features are built-in, but considering what the external factors are. The external factors that I'm thinking of specifically are add-ons, and community(which both heavily influence each other). If it is easy to develop add-ons for the software (add-ons meaning specifications for configuration management of certain applications or environments), and there is a large community, then that means there'll be a lot of add-ons posted online that you can use, and therefore not have to develop.

With that said, that's why my preferred choice is Puppet. Puppet has a lot of interest behind it, and it's accelerating pretty rapidly. You tell puppet what you want on a server by putting it in a "manifest", which is a file which declares what the server should be configured like. For example, you might write something like this:

node '' {
  package {
      ensure => present,
  file {
      ensure => present,
      source => 'puppet:///files/httpd.conf',
  service {
      ensure => running

By using declarative language instead of instructional language, you are telling puppet what the server should look like; when this configuration is applied, puppet will do the things it needs to do to make sure the server looks right, and nothing more. For example, if the package "Apache" is already installed, then Puppet won't try to install it again (as opposed to, say, a shell script).

It also has a git-based website called the Puppet Forge, where people can post modules for use in puppet; for example, a module which allows you to easily declare an Nginx server to be set up on a certain machine, like:

class { nginx: } # installs nginx if not present

nginx::resource::vhost { '': 
  www_root => '/var/www/',

Since puppet has so much interest from so many people, it has quite a lot of modules. Most of the things that you're going to want to use in the production environment will have a module already made for them, if it wasn't already built in as part of Puppet itself. I use a ruby gem called librarian-puppet that manages modules and dependencies for me.

All this isn't to say that you shouldn't research all the other systems; they all have strengths and weaknesses, and will be easier to use depending on what language they have their roots in (Puppet is based on Ruby). But, if you don't find any preference towards any particular one, my advice is to go for Puppet since it has the community and growth behind it.

Sorry for writing such a long email. ¯\_(ツ)_/¯

More information about the freebsd-questions mailing list