What’s the best way to collect information when troubleshooting something with CFEngine?
Cody and Nick chat with Craig about cf-support a new tool shipping in the latest (and future) versions of CFEngine.
Video The video recording is available on YouTube:
At the end of every webinar, we stop the recording for a nice and relaxed, off-the-record chat with attendees. Join the next webinar to not miss this discussion.
Recently we introduced new feature where you can trigger agent runs and report collection from the Mission Portal UI.
This required our daemon cf-execd to behave a bit differently when periodic agent runs occur. Previously the daemon would create a new thread in which to run cf-agent, capture output, wait for completion and move on.
We changed the behavior so that the daemon forks itself and then fork/execs cf-agent as before, with the forked cf-execd processing agent run output. When the agent is finished the forked cf-execd process is left a zombie/defunct. The daemon wakes up every minute to see if it should do an agent run. The next time the original daemon cf-execd “wakes up” it will clean up that defunct forked cf-execd.
If you are debugging issues with a host, it is quite common to want to make changes to CFEngine policy, and speed up the process of fetching, evaluating and reporting for that host. You can do this by running cf-runagent and cf-hub from the command line, now we’ve brought this functionality into Mission Portal:
You can see the feature in action, here:
I have a setup at home where I keep a local git server running on a Raspberry Pi 3 which contains personal/work journal, dotfiles and a personal policy repository. It was set up manually so before adding a new git repository for a family password store I set about retrofiting the configuration in CFEngine. The goal in this blog is to ensure that what I have already is managed by CFEngine and that what I want to add, /srv/git/passwords.git, is created.