Alternatives

What are the options for Chef users who have now lost their automator because of the scenario just described? Some may feel tempted at the first moment to fire up a compiler themselves. Where there is no plaintiff, there is no judge – and Progress Software might not even care whether the specially compiled packages use /opt/chef/ as their as path or something else, as long as you don't redistribute the binaries. This approach only seems attractive at first glance. Anyone who has ever maintained packages of any kind for a Linux distribution will be aware that if you want to build high-quality packages, this strategy will regularly cause overhead on a scale that many companies probably cannot afford.

This is where Cinc [1] enters the scene. Cinc (or CINC) is the acronym for "Cinc is not Chef" and jokingly refers to itself as the "free-as-in-beer distribution" of Chef [2]. Free-as-in-free-beer is a stock phrase in the FLOSS community: Former Free Software Foundation (FSF) boss Richard Stallman regularly used the term to explain which meaning of "free" was meant.

One way or another, Cinc wants to establish itself on the market as a binary-compatible Chef distribution, without incurring costs for admins and avoiding the general wailing and gnashing of teeth provoked by Progress Software. To achieve this goal, the creators behind the project are proceeding in phases, taking on the various components of Chef one by one.

What Chef Is Made Of

It takes a little detour into Chef's structure to understand in more detail how much progress Cinc has made thus far. Anyone looking at the vendor's portfolio is faced with a large number of components: Chef Automate, Chef Infra, Chef Workstation, Chef InSpec – it's easy to lose track. So, which tool does exactly what in the Chef circus?

First, you would do well to focus on Chef Infra, the successor to what admins simply knew as Chef (Figure 4). Before the automation suite started to add factors such as continuous integration and continuous delivery (CI/CD), the predecessor of today's Chef Infra was basically Chef: It included the Chef server and the client. In combination with cookbooks, these components were all you needed in Chef to automate the provisioning of large fleets with a complete configuration. Chef has always used a server-client model, although local changes on individual systems can also be imported with the Chef components.

Figure 4: Chef Infra comprises the server, the client, and the workstation. It is joined by the InSpec compliance tester with the Habitat CI/CD tool. © Chef

Chef Infra comprises three subcomponents. (1) The server is at the core of an automation environment based on Chef. It contains all configuration parameters for all servers in the environment. The cookbooks, which provide the target systems with a specific configuration, are also available here. The Chef server can be queried with a centralized API. It also stores the policy component, which provides a schema for authorizations and processes in Chef. Last but not least, Chef Server is connected to a directory by the Supermarket, from which additional cookbooks or other components can be installed.

The Chef server corresponds to the Chef Infra Client, which runs as an agent on each individual system and receives commands defined by the Chef Server for the respective host so that it can execute them locally. The Chef Workstation, which is itself part of the solution, forms a kind of link between the admin and Chef Infra and is where you will find familiar tools such as Knife, which is used to store the appropriate configurations for each host on the Chef Infra server.

What Cinc Does

Currently, Cinc cannot cover the complete toolset of Chef Infra with its own tools. At the time of writing in early 2022, the Cinc developers had their own versions of Chef Infra Client and a preproduction version of Chef Infra Workstation in their portfolio. In the background, work on a Cinc counterpart to Chef Infra Server was in full swing, so full compatibility with the "real" Chef should be achieved soon.

It's important to remember that building a Chef community distribution that has the official blessing of Progress Software is anything but a trivial and enjoyable experience. In fact, the Cinc people started from scratch with every component. To begin, you need to build packages with customized paths that no longer clash with the official Chef packages. Next, the "Chef" brand has to be removed wherever it could insinuate to the end user that it is an official Progress Software product.

Once again, a comparison with Iceweasel in Debian comes to mind. The amount of work the project had to invest in debranding Firefox at the time was huge – especially in light of the fact that for many years it had to be repeated every time a new version was released. The Cinc makers face a similar task. The people behind Cinc vehemently insist that they are not affiliated with Progress Software in any way, and who could blame them?

I need to state explicitly again that Cinc is looking to be as compatible as possible with Chef, to the extent that this is legally permissible. The developers intend for cookbooks designed for a specific Chef version to work with the same version of Cinc. There are limits to compatibility, however, in places such as filesystem paths, precisely because they are required to differ from the paths used by Chef. In this respect, Cinc cannot become a drop-in replacement.