best configuration management tool for FreeBSD?

Aleksandr Miroslav alexmiroslav at
Fri May 2 20:47:04 UTC 2014

Thanks for the great info. I settled on ansible a few weeks ago,
mostly because it was so easy to run out of the box and also because
the configuration file format looks sane. Someone also mentioned to me
in passing that ansible is the best supported config magnement tool on
BSD systems.

On Wed, Apr 30, 2014 at 5:47 PM, Matthew Pherigo <hybrid120 at> wrote:
> 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 {
>     apache:
>       ensure => present,
>   }
>   file {
>     '/usr/www/httpd.conf':
>       ensure => present,
>       source => 'puppet:///files/httpd.conf',
>   }
>   service {
>     'httpd':
>       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. ¯\_(ツ)_/¯
> --Matt

More information about the freebsd-questions mailing list