37 lines
1.6 KiB
Markdown
37 lines
1.6 KiB
Markdown
+++
|
|
title = "no cfengine anymore"
|
|
date = "2014-03-16T10:51:52+00:00"
|
|
author = "Gibheer"
|
|
draft = false
|
|
+++
|
|
|
|
I thought I could write more good stuff about cfengine, but it had some pretty
|
|
serious issues for me.
|
|
|
|
The first issue is the documentation. There are two documents available. One for
|
|
an older version but very well written and a newer one which is a nightmare to
|
|
navigate. I would use the older version, if it would work all the time.
|
|
|
|
The second issue is that cfengine can destroy itself. cfengine is one of the
|
|
oldest configuration management systems and I didn't expect that.
|
|
|
|
Given a configuration error, the server will give out the files to the agents. As
|
|
the agent pulls are configured in the same promise files as the rest of the
|
|
system an error in any file will result in the agent not being able to pull any
|
|
new version.
|
|
|
|
Further is the syntax not easy at all and has some bogus limitations. For example
|
|
it is not allowed to name a promise file with a dash. But instead of a warning
|
|
or error, cfengine just can't find the file.
|
|
|
|
This is not at all what I expect to get.
|
|
|
|
What I need is a system, which can't deactivate itself or even better, just runs
|
|
on a central server. I also didn't want to run weird scripts just to get ruby
|
|
compiled on the system to setup the configuration management. In my eyes, that
|
|
is part of the job of the tool.
|
|
|
|
The only one I found which can handle that seems to be ansible. It is written
|
|
in python and runs all commands remote with the help of python or in a raw mode.
|
|
The first tests also looked very promising. I will keep posting, how it is going.
|