Last year we had a look at managing local groups with the custom groups promise type. As you may or may not recall, we used JSON-strings to imitate CFEngine bodies. This was due to the fact that the promise module protocol did not support bodies at that time. Today, on the other hand, we’re happy to announce that as of CFEngine 3.20, this will no longer be the case. In this blog post we’ll introduce the long awaited feature; custom bodies.
CFEngine and Ansible are two complementary infrastructure management tools. Findings from our analysis show that they can be combined and used side by side with joint forces to handle all areas in the best possible way. Part of infrastructure management is hosts deployment, either when building a brand new infrastructure or when growing one by adding new hosts.
Last year, we released PagerDuty Rundeck Actions, a PagerDuty add-on product that connects responders to automated diagnostics and remediation for common problems directly in the PagerDuty incident response workflow. After working with our customers and listening to the community, we are excited to announce that PagerDuty Rundeck Actions now integrates with PagerDuty’s Slack integration.
Which cultural values empower businesses to thrive today? That's an open question, of course. But I suspect most employees, managers, and analysts would include items like collaboration, transparency, and creativity on the list of essential ingredients in business success. Indeed, you could argue that these values are at the core of a variety of modern organizational and technical innovations, from DevOps (which is all about collaboration) to open source software (which centers on collaboration and transparency) and the creator/maker movement (which is, of course, all about creativity).
We’ve said it before, and we’ll say it again: Security Orchestration, Automation and Response (SOAR) platforms are great tools for helping teams work smarter, faster, and more efficiently against security risks. But, used on their own, SOARs are far from perfect for meeting the full security needs of the modern organization.
With the recent release of build.cfengine.com and cfbs I have been thinking about the process of converting a traditionally manged policy set. I consider a traditionally manged policy set one where you have a repo with the root of masterfiles being the root of the repository, or even having no repository at all and managing masterfiles by editing directly in the distribution point (e.g. /var/cfengine/masterfiles).
