Cinc – Blog

Cinc Server: forking for the long haul

Sat, 13 Jun 2026 10:00:00 -0700

In November 2025, Progress announced that the open-source Chef Infra Server is being retired in favor of the Chef 360 platform. The community edition will receive no new code, features, or security fixes after October 2026, and will reach formal end-of-life in November 2026. Existing repositories will go read-only at that point.

This is similar in spirit to the upstream move to Habitat-only Workstation builds that triggered our Cinc Workstation fork earlier this year. And, like with Workstation, the Cinc Project intends to keep producing omnibus binary builds of Cinc Server for the foreseeable future — Chef 360 is Progress’s proprietary product, not something we’re going to chase.

Our plan

There are two parallel tracks:

Keep shipping 15.x for as long as it makes sense. We’ll continue to rebuild any 15.x releases Progress produces until their EOL in November 2026. Existing users on the 15.x line don’t need to change anything.
In parallel, start work on a proper fork. We’ve created a new consolidated repository at gitlab.com/cinc-project/distribution/cinc-server and are doing the early work to make Cinc Server self-sufficient. The first independent release will be Cinc Server 16.0.0, targeted to land around the upstream EOL. The current WIP can be followed on merge request !1.

The fork is intended to keep Cinc Server in maintenance mode. No major feature changes are planned. We’ll cherry-pick upstream commits that benefit the project for as long as the Chef GitHub repos remain readable, and we’ll continue to do the boring-but-important work after that: security updates, platform support, dependency upgrades.

What’s already in flight

A fair amount of the groundwork is already done in the new repository:

The consolidated cinc-server repo now contains the service source (oc_erchef, bookshelf, oc_bifrost, oc-id, chef-server-ctl), the omnibus build configuration, integration tests, and CI pipeline — all in one place
Erlang dependencies that previously lived under github.com/chef/ are being mirrored to gitlab.com/cinc-project/upstream/ and pinned to known-good commits, so we don’t lose the ability to build when those repos go read-only
Gecode 6.x compatibility patches and libffi / runit updates for Enterprise Linux 10 and Debian 13 are already merged
Telemetry to Progress Chef can be disabled; it will be removed entirely post-fork
Initial version is set to 16.0.0; CI is being restructured for the fork workflow

The maintenance plan — including the full list of upstream dependencies we’re mirroring, our security update policy, and the planned Ruby / PostgreSQL / Erlang upgrade roadmap — is published in the repository: CINC_MAINTENANCE_PLAN.md.

What this means if you run Cinc Server today

In short: nothing changes immediately, and your migration plan is “keep running Cinc Server.”

Your existing 15.x installs keep getting rebuilds for the rest of 2026
Cookbooks, knife configurations, chef-server-ctl automation — all continue to work unchanged
When 16.0.0 lands, it will be a drop-in continuation of the 15.x line. There are no planned breaking changes at the fork point
Configuration paths (/etc/cinc-project/cinc-server.rb) and binary names (cinc-server-ctl) stay the same

If you’ve been considering Chef 360, that’s between you and Progress; this post isn’t about that. But if you’d rather not switch to a commercial platform, Cinc Server will be there.

How to help

This is a meaningful expansion of the maintenance surface for the Cinc Project. We’d particularly welcome:

Erlang experience — the three core services (oc_erchef, bookshelf, oc_bifrost) are battle-tested but the long tail of Erlang dependencies needs care
Testing on more platforms — the build matrix already covers 12 platforms; expanding to ARM and more distros would be useful
Security review — extra eyes on the upgrade plan for OpenSSL, PostgreSQL, Ruby, and Erlang/OTP versions

Come find us in #community-distros on the Chef Community Slack, or open an issue / MR on GitLab.

Cinc as highly available cluster

Fri, 06 Dec 2024 22:00:33 +0100

Introduction

For most use cases a single instance of CINC will cover all your needs. It is a tool after all, and not a service that processes client traffic.

But, if for some of you out there, having a single instance of anything is not acceptable, or if in your infrastructure CINC plays a crucial role, there is a way to have CINC in a highly available clustered setup.

In this article we will go through setting up this on VM’s in your private cloud or with some cloud provider. We will need 6 to 10 VM’s. I will be setting it up on Rocky Linux 8.

Architecture

In order to achieve a highly available setup we’ll need to separate all services with persistent data to dedicated clusters.

We will move Opensearch to its own cluster.

PostgreSQL will also be an external cluster, with additional installations of etcd and Patroni for cluster management and failover.

Bookshelf service which stores Cinc cookbooks will be replaced with another object storage service, MinIO.

If you have your infrastructure in AWS cloud, you can use S3 bucket for this purpose as well. In this article we will be using MinIO.

Every cinc-client will need to be able to connect to your Cinc server to authenticate and upload data at the end of the run, as well as your object storage service to download cookbooks (MinIO/S3).

The cluster service schema looks something like this.

Frontend servers

On frontend we will be installing services without persistent data with cinc-server-ctl command on 2 servers.

Services: nginx, oc_bifrost, oc_id, opscode-erchef, redis_lb

frontend-1
frontend-2

Backend servers

Backend servers will host services with persistent data, each in clustered setup. We will install all of them on 4 servers, so each service cluster will have 4 members.

Services: opensearch, postgresql(+ etcd, patroni), minio

backend-1
backend-2
backend-3
backend-4

Balancers

If you are not running this in a public cloud you can use keepalived and haproxy.

If you are in a public cloud, you can replace this with cloud native balancers. So 4 servers less. If you’ll be using them, the first order of business is to deploy them and configure a virtual IP on keepaliveds to point to haproxies.

I won’t go into the details of haproxy and keepalived setup to keep the article focused, I will only go through relevant information for service balancing. Check references for details on balancers.

keepalived-1
keepalived-2
haproxy-1
haproxy-2

Certificates

In this setup we will make sure all communication inside the cluster of each service is encrypted. Each server will have a fully qualified domain name. If you don’t have a DNS server, you can add servers to /etc/hosts file.

Use openssl to generate your certificates from the same self-signed root CA and you can use the same ones for all your service clusters.

Make sure you add this root certificate to your servers trust store in order for certificates to be trusted.

If you don’t want to add this root certificate to all of your servers in infrastructure, you can use these self-signed certificates only for inside-cluster communication.

TLS termination for traffic from cinc-clients can happen on haproxy service, with publicly trusted certificates hosted there.

Opensearch

Installation

We will first start setting up our backend (data persistent) services.

Add opensearch repo. Currently supported version of Opensearch is 1.x. in Cinc 15.9.38 version. Before proceeding, check which one is supported in the version you will be using. In this setup we will be using 1.3.18.

curl -SL https://artifacts.opensearch.org/releases/bundle/opensearch/1.x/opensearch-1.x.repo -o /etc/yum.repos.d/opensearch-1.x.repo && dnf install opensearch -y

Once installed create a separate /data partition to make sure that data cannot fill out the root partition. We will use /data for all backend services. Then setup /data/opensearch dir and adjust ownership:

mkdir /data/opensearch && chown opensearch:opensearch /data/opensearch

Configuration

Once service is installed, we need to set up certificates. Here I will be using the ones we generated for server fqdns. You need to have 3 seperate files, one for full certificate chain, private key and root-ca certificate.

Additionally, you could generate one more certificate to be used for admin user authentication if you wish to do that. Referenced by admin_dn part of the configuration.

Put them in /etc/opensearch/ and make sure the opensearch user has permissions to read them.

Use this configuration as a template for configuring your opensearch cluster. Configure all 4 servers.

cluster.name: cinc-opensearch
node.name: backend-1.example.com
path.data: /data/opensearch
path.logs: /var/log/opensearch
network.host: 0.0.0.0
discovery.seed_hosts: [ "backend-1.example.com", "backend-2.example.com", "backend-3.example.com", "backend-4.example.com" ]
cluster.initial_master_nodes: [ "backend-1.example.com", "backend-2.example.com", "backend-3.example.com", "backend-4.example.com" ]
node.master: true
plugins.security.allow_default_init_securityindex: true
plugins.security.ssl.transport.pemcert_filepath: full-chain.crt
plugins.security.ssl.transport.pemkey_filepath: private.key
plugins.security.ssl.transport.pemtrustedcas_filepath: root-ca.pem
plugins.security.ssl.transport.enabled_protocols:
- "TLSv1.2"
plugins.security.ssl.transport.enforce_hostname_verification: false
plugins.security.restapi.roles_enabled: ["all_access", "security_rest_api_access"]
plugins.security.system_indices.enabled: true
plugins.security.system_indices.indices: [".opendistro-alerting-config", ".opendistro-alerting-alert*", ".opendistro-anomaly-results*", ".opendistro-anomaly-detector*", ".opendistro-anomaly-checkpoints", ".opendistro-anomaly-detection-state", ".opendistro-reports-*", ".opendistro-notifications-*", ".opendistro-notebooks", ".opendistro-asynchronous-search-response*", ".replication-metadata-store"]
plugins.security.authcz.admin_dn:
- "CN=A,OU=MyOrganizationalUnit,O=MyCompany,L=MyCity,ST=MyState,C=US"
plugins.security.ssl.http.enabled: true
plugins.security.ssl.http.pemcert_filepath: full-chain.crt
plugins.security.ssl.http.pemkey_filepath: private.key
plugins.security.ssl.http.pemtrustedcas_filepath: root-ca.pem
plugins.security.ssl.http.enabled_protocols:
- "TLSv1.2"
plugins.security.nodes_dn:
- "CN=backend-1.example.com,OU=MyOrganizationalUnit,O=MyCompany,L=MyCity,ST=MyState,C=US"
- "CN=backend-2.example.com,OU=MyOrganizationalUnit,O=MyCompany,L=MyCity,ST=MyState,C=US"
- "CN=backend-3.example.com,OU=MyOrganizationalUnit,O=MyCompany,L=MyCity,ST=MyState,C=US"
- "CN=backend-4.example.com,OU=MyOrganizationalUnit,O=MyCompany,L=MyCity,ST=MyState,C=US"
http.max_content_length: 1024mb

Then, not to have password for admin be admin(default), export the environment variable of initial password and start and enable service:

export OPENSEARCH_INITIAL_ADMIN_PASSWORD=newpassword && systemctl start opensearch && systemctl enable opensearch

I will be using this Opensearch cluster dedicated to Cinc only. If you were to share this cluster among multiple services best practice would be to have multiple users with granulated roles.

Let’s check the health of the cluster to make sure we have no issues.

curl -XGET -u $user:$pass -H "Content-Type: application/json" 'https://backend-1.example.com:9200/_cluster/health?pretty'

Additionally, if you have more than 10 000 nodes, you will need to expand max_result_window. More on this shortly.

curl -XPUT -u $user:$pass -H "Content-Type: application/json" https://backend-1.example.com:9200/chef/_settings -d '{ "index" : { "max_result_window" : 100000 } }'

Balancing

For balancing we will be using L4 balancing on keepalived forwarded to L7 balancing on haproxy. Here will also resolve an Opensearch optimization that shows up if you have more than 10 000 servers in your infrastructure. Knife search will return only 10k results. Opensearch, in order to speed up searches, capped all results to 10 000. If you want more results, you need to send track_total_hits=true with each request, and expand max_result_window as we did in the previous step.

You can fix this for now, until fixed permanently, by rewriting the search path on balancer.

We will also be using in all of our balancing configs Layer 7 checks to make sure each node is in ready state to receive traffic.

frontend cinc-opensearch-cluster
mode http
bind 10.0.0.100:9200 ssl crt /etc/ssl/haproxy
# Workaround of Opensearch limit of 10k search
acl is_search path_reg ^/chef/_search$
http-request set-path /chef/_search?track_total_hits=true if is_search
default_backend cinc-opensearch
backend cinc-opensearch
balance roundrobin
option httpchk GET /_plugins/_security/health
http-check expect status 200
server backend-1 backend-1.example.com:9200 check-ssl check ssl verify none
server backend-2 backend-2.example.com:9200 check-ssl check ssl verify none
server backend-3 backend-3.example.com:9200 check-ssl check ssl verify none
server backend-4 backend-4.example.com:9200 check-ssl check ssl verify none

PostgreSQL

Installation

For cluster management of PostgreSQL we will be using etcd and patroni.

Always check the Chef release notes which version of PostgreSQL is supported.

First you will need to download etcd binaries named etcd and etcdctl and place them in /usr/local/bin/ and give them proper permissions as well as create data and config dirs.

chown root:root /usr/local/bin/etcd* &&\
chmod 755 /usr/local/bin/etcd* &&\
mkdir -p /var/lib/etcd &&\
mkdir -p /etc/etcd &&\
groupadd --system etcd &&\
useradd -s /sbin/nologin --system -g etcd etcd &&\
chown -R etcd:etcd /var/lib/etcd /etc/etcd &&\
chmod 700 /var/lib/etcd

Then you will need to download the repo and run the installation.

dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm &&\
dnf -qy module disable postgresql &&\
dnf install -y postgresql13-server-13.14 patroni patroni-etcd

Configuration

Once installed, create /data/postgresql dir and adjust ownership:

mkdir /data/postgresql && chown postgres:postgres /data/postgresql && chmod 700 /data/postgresql

Next, we will configure the systemd file /etc/systemd/system/etcd.service for etcd, edit the values to reflect your setup for each server in the cluster. Here is an example of it:

[Unit]
Description=etcd
Documentation=https://github.com/etcd-io/etcd
After=network.target
After=network-online.target
Wants=network-online.target
[Service]
Type=notify
User=etcd
ExecStart=/usr/local/bin/etcd \
--name backend-1.example.com \
--data-dir=/var/lib/etcd \
--initial-advertise-peer-urls https://10.0.0.1:2380 \
--listen-peer-urls https://10.0.0.1:2380 \
--listen-client-urls https://10.0.0.1:2379,http://127.0.0.1:2379 \
--advertise-client-urls https://10.0.0.1:2379 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster backend-1.example.com=https://backend-1.example.com:2380,backend-2.example.com=https://backend-2.example.com:2380,backend-3.example.com=https://backend-3.example.com:2380,backend-4.example.com=https://backend-4.example.com:2380 \
--initial-cluster-state new --auto-tls --peer-auto-tls
[Install]
WantedBy=multi-user.target

Then configure patroni and postgresql inside it. Use the following configuration as template.

scope: cinc_pgsql_cluster
namespace: /service/
name: backend-1
restapi:
listen: 10.0.0.1:8008
connect_address: 10.0.0.1:8008
allowlist_include_members: true
certfile: /etc/ssl/server-cert.pem
keyfile: /etc/ssl/private.key
cafile: /etc/ssl/root-ca.pem
ctl:
insecure: true
etcd3:
hosts: 10.0.0.1:2379,10.0.0.2:2379,10.0.0.3:2379,10.0.0.4:2379
protocol: https
bootstrap:
dcs:
ttl: 30
loop_wait: 10
retry_timeout: 10
maximum_lag_on_failover: 1048576
postgresql:
use_pg_rewind: true
use_slots: true
parameters:
max_connections: 400
initdb:
- encoding: UTF8
- data-checksums
pg_hba:
- host replication replicator 127.0.0.1/32 md5
- host replication replicator 10.0.0.1/32 md5
- host replication replicator 10.0.0.2/32 md5
- host replication replicator 10.0.0.3/32 md5
- host replication replicator 10.0.0.4/32 md5
- host all all 0.0.0.0/0 md5
users:
admin:
password: $pass
options:
- createrole
- createdb
postgresql:
listen: 0.0.0.0:5432
connect_address: 10.0.0.1:5432
data_dir: /data/postgresql/
bin_dir: /usr/pgsql-13/bin
pgpass: /tmp/pgpass
authentication:
replication:
username: replicator
password: "$pass"
superuser:
username: postgres
password: "$pass"
parameters:
max_connections: 400
tags:
nofailover: false
noloadbalance: false
clonefrom: false
nosync: false

That is it, make sure to enable etcd and partoni to start on boot. Patroni will be the one managing PostgreSQL, starting and stopping it. Run this on all nodes.

systemctl start etcd && systemctl start patroni && systemctl enable etcd && systemctl enable patroni

Check that data is properly placed and that there is elected leader:

# patronictl -c /etc/patroni/patroni.yml list

+ Cluster: cinc_pgsql_cluster (7416721032775114149) -+----+-----------+
| Member | Host | Role | State | TL | Lag in MB |
+----------------+-------------+---------+-----------+----+-----------+
| backend-1 | 10.0.0.1 | Leader | running | 4 | |
| backend-2 | 10.0.0.2 | Replica | streaming | 4 | 0 |
| backend-3 | 10.0.0.3 | Replica | streaming | 4 | 0 |
| backend-4 | 10.0.0.4 | Replica | streaming | 4 | 0 |
+----------------+-------------+---------+-----------+----+-----------+

Balancing

For PostgreSQL we will be using L4 balancing on keepalived with L7 checks, checking for leader and sending it r/w requests. As mentioned before, you could use cloud native network balancer as well.

###########################
# cinc-postgresql-cluster #
###########################
virtual_server 10.0.0.100 5432 {
delay_loop 2
lb_algo rr
lb_kind DR
protocol TCP
real_server 10.0.0.1 5432 {
weight 1
SSL_GET {
connect_timeout 2
connect_port 8008
url {
path /read-write
status_code 200
}
}
}
real_server 10.0.0.2 5432 {
weight 1
SSL_GET {
connect_timeout 2
connect_port 8008
url {
path /read-write
status_code 200
}
}
}
real_server 10.0.0.3 5432 {
weight 1
SSL_GET {
connect_timeout 2
connect_port 8008
url {
path /read-write
status_code 200
}
}
}
real_server 10.0.0.4 5432 {
weight 1
SSL_GET {
connect_timeout 2
connect_port 8008
url {
path /read-write
status_code 200
}
}
}
}

MinIO

MinIO replaces Bookshelf service as another object storage. Here you could also use S3 bucket for this. We will choose Minio as an on-premise solution. Bookshelf stores cookbooks and if you don’t have some shared disk between frontend servers, you need to have all the info in one place so all frontends can have consistent responses.

Installation

First we will need to install the service on all servers and create a user and disk. Consult official docs.

wget https://dl.min.io/server/minio/release/linux-amd64/archive/minio-20240913202602.0.0-1.x86_64.rpm -O minio.rpm &&\
dnf install minio.rpm -y &&\
groupadd -r minio-user &&\
useradd -M -r -g minio-user minio-user &&\
mkdir -p /data/minio/dir{1..4} &&\
chown -R minio-user:minio-user /data/minio

Configuration

MinIO in clustered setup requires each server to have 4 disks. You could configure them using LVM or simply use 4 directories. I’ve chosen the second option as coobook data is also stored on git and is not critical.

As a consequence of using directories, the minio command (mc) might not show proper disk usage.

The configuration will be done on /etc/default/minio through env variables and should look something like this:

MINIO_VOLUMES="https://backend-{1...4}.example.com:9900/data/minio/dir{1...4}"
MINIO_OPTS="--console-address :9001 --address 0.0.0.0:9900"
MINIO_ROOT_USER=minioadmin
MINIO_ROOT_PASSWORD=$pass
MINIO_PROMETHEUS_AUTH_TYPE=public

Here we are using a dedicated MinIO cluster so we can use admin user. In case you have more buckets for other services, you will need to granulate role access per bucket.

Then let’s configure certificates. We will be using the same self-signed ones. By default it uses path /home/minio-user/.minio/certs/CAs, but this can be overridden with environment variables. We’ll use the default, so let’s create directory:

mkdir -p /home/minio-user/.minio/certs/CAs &&\
chown -R minio-user:minio-user /home/minio-user/

Your file structure should look something like this and minio-user should own all these files:

# ll /home/minio-user/.minio/certs/
CAs
private.key
public.crt
# ll /home/minio-user/.minio/certs/CAs
backend-1.crt
backend-2.crt
backend-3.crt
backend-4.crt
root-ca.crt

I will use admin user in Minio since there will be no other users or buckets in this cluster, just CINC. Make sure cert file ownership is correct.

Start and enable the service:

systemctl start minio && systemctl enable minio

You will need to create a bucket at the end of the setup, once you have the entire setup complete and you have created the organization. You can configure MC(minio client) to do this or login to your server URL on port 9001(https) in the browser and add it there.

The bucket name you will need to create is organization-$org-id, for example organization-928a25c3cce4bc623572df8a7764c185.

The ID is the guid under which organization was created in Cinc, so you will need to look that up with command after you create your organization:

# knife org show my-org
full_name: My Organization
guid: 928a25c3cce4bc623572df8a7764c185
name: my-org

Another important thing to note: When you specify in settings that the AWS S3 bucket is replacing the Bookshelf, it will follow the AWS bucket naming convention. So in cinc-server.rb below the following 2 settings will point to url cinc-minio-cluster.example.com

bookshelf['external_url'] = 'https://example.com'
opscode_erchef['s3_bucket'] = 'cinc-minio-cluster'

Balancing

Use L4/L7 balancing, and configure on haproxy L7 healthcheck like this:

frontend cinc-minio-cluster
mode http
bind 10.0.0.100:443 ssl crt /etc/ssl/haproxy
default_backend cinc-minio
backend cinc-minio
balance roundrobin
option httpchk /minio/health/live
http-check expect status 200
server backend-1 backend-1.example.com:9900 check-ssl check ssl verify none
server backend-2 backend-2.example.com:9900 check-ssl check ssl verify none
server backend-3 backend-3.example.com:9900 check-ssl check ssl verify none
server backend-4 backend-4.example.com:9900 check-ssl check ssl verify none

CINC frontend services

Installation and configuration

Run the omnitruck script to perform initial installation.

curl -L https://omnitruck.cinc.sh/install.sh | sudo bash -s -- -P cinc-server

We can use here for nginx certificates we generated in /etc/cinc-project or we can have them be auto-generated during install.

Then using official docs we will compose config /etc/cinc-project/cinc-server.rb for our usecase:

#PostgreSQL
postgresql['external'] = true
postgresql['vip'] = 'cinc-postgresql-cluster.example.com'
postgresql['db_superuser'] = '$user'
postgresql['db_superuser_password'] = '$pass'
#Opensearch
opensearch['external'] = true
opensearch['external_url'] = 'https://cinc-opensearch-cluster.example.com:9200'
opscode_erchef['search_auth_username'] = '$user'
opscode_erchef['search_auth_password'] = '$pass'
opscode_erchef['search_ssl_verify'] = false
#MinIO
bookshelf['enable'] = false
bookshelf['vip'] = 'cinc-minio-cluster.example.com'
bookshelf['external_url'] = 'https://example.com'
bookshelf['access_key_id'] = '$user'
bookshelf['secret_access_key'] = '$pass'
opscode_erchef['s3_bucket'] = 'cinc-minio-cluster'
#Nginx certificates in case you don't want to use auto-generated(optional)
nginx['ssl_certificate'] = '/etc/cinc-project/server.pem'
nginx['ssl_certificate_key'] = '/etc/cinc-project/server.key'
#Nginx optimizations
nginx['client_max_body_size'] = '500m'
nginx['worker_processes'] = 10
nginx['worker_connections'] = 10240
nginx['keepalive_requests'] = 200
nginx['keepalive_timeout'] = '60s'

Then run the command to deploy and configure local services and configure backend services:

cinc-server-ctl reconfigure

That will install local services, connect to opensearch and postgresql, create databases, users, indexes etc.

In case you use your own certificates make sure they are owned by user cinc after this step.

First frontend node has been added.

Add more frontend VM’s

In order to bootstrap another frontend node, you will need to first run the omnitruck script on the new node, then after that is done you will need to transfer the following files from bootstrapped node to new node on the same location:

/etc/cinc-project/cinc-server.rb
/etc/cinc-project/dark_launch_features.json
/etc/cinc-project/pivotal.pem
/etc/cinc-project/pivotal.rb
/etc/cinc-project/private-chef.sh
/etc/cinc-project/private-cinc-secrets.json
/etc/cinc-project/webui_priv.pem
/etc/cinc-project/webui_pub.pem
/var/opt/cinc-project/bootstrapped
/var/opt/cinc-project/upgrades/migration-level

Then run the cinc-server-ctl reconfigure and this way it will skip creating users and it will have their credentials and see they are already created. More nodes can be added this way.

Create balancing for the nodes on Haproxy.

Balancing

The balancing is very simple as well to configure. You could use directly keepalived or if you want some more logging or traffic manipulation features, haproxy is a very easy software to do this with. I will be using it here as well.

frontend cinc-server-cluster
mode http
bind 10.0.0.101:443 ssl crt /etc/ssl/haproxy
default_backend cinc-server
backend cinc-server
balance roundrobin
server frontend-1 frontend-1.example.com:443 check ssl verify none
server frontend-2 frontend-1.example.com:443 check ssl verify none

Conclusion

Additionally you can deploy Prometheus exporters and monitor the whole cluster with Prometheus/Grafana. You are now ready to create your organization or restore data from existing. Before uploading cookbooks don’t forget to also create buckets in MinIO with proper naming as discussed before. Your Cinc is now a highly available cluster. Check out references for additional information.

Additional resources

MinIO Multi-Node Multi-Drive

Opensearch Getting Started

PostgreSQL+Patroni+etcd

Keepalived basics

Haproxy Docs

Config.rb optional settings

Migrating from Chef to Cinc

Mon, 05 Feb 2024 10:42:00 +1000

Intro

Many users already in the Chef ecosystem may have reason to migrate from Chef Infra Server to Cinc server. Thankfully, this is a relatively painless process and all cookbooks, users, data bags, roles, environments, etc. can be retained during the migration process. This blog post documents the migration process from Chef Infra Server to Cinc Server in Red Hat Enterprise Linux 8.

Cinc Server Setup

In order to create your new Cinc Server, stand up a new server on your OS of choice by following the steps detailed at Server Installation.

Once the Cinc server has been configured, you must configure the admin user:

cinc-server-ctl user-create #{username} #{first_name} #{last_name} #{email} #{password} --filename #{output_file_name}

for example…

cinc-server-ctl user-create cincadmin cinc admin cincadmin@dev.local thisisasecret --filename /tmp/cincadmin.pem

Workstation Setup

Backup / Restore operations are performed via a 3rd machine rather than on the source or destination servers. This machine will be used as a workstation on which Chef object-based backups can be created. I deployed an RHEL8 server for this purpose with enough disk space to store the backup. For reference purposes, our server with 17 users, 63 environments, 481 roles, and 539 cookbooks (each with many versions) consumed 9.2GB for the backup. This is a relatively small environment - others may require far more storage to create the backup.

After deployment of the workstation, the following tasks were completed:

Install Cinc Workstation, knife-ec-backup, knife-tidy, and pre-reqs

Use the commands below to install the required tools:

curl -L https://omnitruck.cinc.sh/install.sh | sudo bash -s -- -P cinc-workstation -v 22
sudo yum -y install gcc postgresql-devel
chef gem install knife-ec-backup
chef gem install knife-tidy

The following files were then created on the server:

# /chef_backups/conf/knife_src_server.rb (Source Server Knife Config)
log_level :info
log_location STDOUT
client_key '/chef_backups/conf/knife_src.pem'
chef_server_url 'https://chef.domain.local'
node_name 'berks'

# /chef_backups/conf/knife_dst_server.rb (Destination Server Knife Config)
log_level :info
log_location STDOUT
client_key '/chef_backups/conf/knife_dst.pem'
chef_server_url 'https://cinc.domain.local'
node_name 'cincadmin'
ssl_verify_mode :verify_none

Copy the Destination Server client_key

Copy /tmp/cincadmin.pem from the Cinc Server to /chef_backups/conf/knife_dst.pem on the Workstation.

Copy the Source Server WebUI Private Key

Copy /etc/opscode/webui_priv.pem from the source Chef Infra Server to /chef_backups/conf/webui_priv_src.pem on the Workstation.

Destination Server WebUI Private Key

Copy /etc/cinc-project/webui_priv.pem from the destination Chef Infra Server to /chef_backups/conf/webui_priv_dst.pem on the Workstation.

Source Certificate Trust

Run the following command to trust SSL certificates for the source Chef server.

knife ssl -c knife_src_server.rb fetch

I was not able to do this for the destination server in my environment since it was configured to use the same FQDN as my source server and DNS was still pointing at the source server. If you are in the same position, then SSL checks for the destination server can be disabled in /chef_backups/conf/knife_dst_server.rb by setting ssl_verify_mode to :verify_none.

Backing Up Chef Infra Server

OK, assuming everything above has gone well, it is now time to backup your Chef server! From your Workstation, run the command below to start the backup:

knife ec -c /chef_backups/conf/knife_src_server.rb backup /chef_backups/ --webui-key /chef_backups/conf/webui_priv_src.pem --concurrency 10

Set concurrency to whatever your source server can handle. I have seen some people recommend 5, but we had enough overhead to go with 10 and honestly, I could have probably gone higher. This took several hours the first time. Subsequent backup runs seem to capture the deltas and took 30-45 mins each time.

Knife Tidy

Theoretically, you should be able to use knife tidy at this point to remove unused cookbook versions, clients, etc, however this didn’t work in my testing and frankly, I didn’t feel comfortable doing this at the same time as the server migration. See the knife-tidy git repo for more information on this utility.

Data Restoration

Once the backup is done, run the following command to perform a dry-run of the backup to the destination server. The dry-run will still create the Chef Organization on the destination server, but will not copy nodes, clients, roles, environments, acls, cookbooks, etc.

knife ec -c /chef_backups/conf/knife_dst_server.rb restore /chef_backups/ --webui-key /chef_backups/conf/webui_priv_dst.pem --dry-run

Once that has been done, run the following command on the destination Cinc server to associate the cincadmin user with the newly created organization:

cinc-server-ctl org-user-add myOrgName cincadmin

Now you can restore the data to the destination server:

knife ec -c /chef_backups/conf/knife_dst_server.rb restore /chef_backups/ --webui-key /chef_backups/conf/webui_priv_dst.pem

Local Testing

Cinc offers a build in method for running automated tests against the server. The following was done on the Cinc server:

If DNS does not yet resolve the intended FQDN to the IP address of the Cinc server, then update /etc/hosts so that your desired FQDN resolves to the IP address of the Cinc server.
Run cinc-server-ctl test

The following output was observed:

Pending: (Failures listed here are expected and do not affect your suite's status)
1) opscode-account user association user not in org can be invited to the org by an admin when the inviting admin is removed from the org, invites issued by that admin cannot be accepted
# Known failure: passes w/ 200 b/c no USAG cleanup performed for deleted user
# ./spec/api/account/account_association_spec.rb:662
2) opscode-account user association user not in org can be invited to the org by an admin when the inviting admin is removed from the system, invites issued by that admin can't by accepted
# Known failure: passes w/ 200 b/c no USAG or other group cleanup performed for deleted user
# ./spec/api/account/account_association_spec.rb:671
Finished in 54.85 seconds (files took 3.85 seconds to load)
173 examples, 0 failures, 2 pending

In our case, I built our new Cinc server using a cookbook on our Chef server, so I was able to run chef-client on the Cinc server to ensure that the server was able to execute a Chef client run against itself (remember, we previously updated /etc/hosts to make this possible).

Remote Testing

The following remote tests were performed to ensure other existing clients were able to connect and execute their Chef runs against the Cinc server…

If necessary, update /etc/hosts on an existing machine so that the FQDN of the Cinc server resolves to the IP address of the Cinc server.
If the FQDN of your Cinc server is different than that of the existing Chef server, then update client.rb and knife.rb accordingly.
Run chef-client
Run the following to ensure the Cinc server saw the test client run: knife status --run-list

To ensure our pipelines for Roles, Environments, Cookbooks, etc were still working, I temporarily modified the jobs to update /etc/hosts so that chef.domain.local resolved to the Cinc server IP, and then executed each job to ensure they were successfully able to create and update their respective objects.

I then executed knife commands with the option -c /chef_backups/conf/knife_dst_server.rb to ensure I could see the updates on the destination Cinc server.

For example…

# knife role show myUpdatedRole -c /chef_backups/conf/knife_dst_server.rb
# knife cookbook show myUpdatedCookbook -c /chef_backups/conf/knife_dst_server.rb
# knife environment show myUpdatedEnvironment -c /chef_backups/conf/knife_dst_server.rb

Examining the New Environment

The following commands can be used to examine the new environment and ensure it matches the source environment. If you receive errors regarding the cincadmin user not having access to the org, just re-run the following command on the destination server:

cinc-server-ctl org-user-add orgName cincadmin

List all cookbooks (and versions)

knife cookbook list -c /chef_backups/conf/knife_dst_server.rb

List all nodes

knife node list -c /chef_backups/conf/knife_dst_server.rb

Show details for a single node

knife node show myNodeName -c /chef_backups/conf/knife_dst_server.rb

List all nodes and their last checkin date

knife status -c /chef_backups/conf/knife_dst_server.rb

Get last checkin date for a specific node

knife status "hostname:anyExistingServerName" -c /chef_backups/conf/knife_dst_server.rb

Node Migration

Migrating nodes is a simple operation since the newly built server has retained client keys for each node. If the new Cinc server has the same FQDN as the Chef server that it is replacing then all that needs to be done is a DNS update so that the FQDN now resolved to the IP address of the Cinc server. If the Cinc server has a new FQDN, then you must update client.rb and knife.rb on each client machine to perform the migration.

References

See the following links for more information on the above process:

Free products

Thu, 02 Nov 2023 21:48:55 -0400

Here’s the short list of changes people migrating solutions can expect to look into (updated 2023-11-02):

Chef Infra™ client –> Cinc-client
Chef Infra™ server –> Cinc-server or Goiardi
Chef Inspec™ –> Cinc-auditor
Chef Habitat™ –> see Cinc-project friends biome.sh
- Cinc’s own Habitat distro is considered low priority by the project in the presence of such a great alternative.
Chef Workstation –> Cinc-Workstation
Chef Automate -> Looking for contributors to help building it.
- Alternative to get an overview of a cinc server: chefbrowser

Cinc Server is now Stable

Wed, 20 Apr 2022 14:07:31 -0700

Thanks to our various contributors, we are excited to announce that Cinc Server 14.14.1 is the first release that is now considered stable! You can find additional information on how to install and use Cinc Server here.

Cinc and Kitchen Dokken

Wed, 01 Dec 2021 14:44:33 +0800

Why use Kitchen Dokken?

In a word, speed. The kitchen-dokken plugin is designed to make testing your Cinc/Chef code as fast as possible. As you can probably determine from the name, the plugin uses containers to speed up the process, both for the OS being provisioned and for the Cinc/Chef client.

There are of course some trade-offs required to achieve this speed, firstly the plugin is Chef/Cinc specific (not really an issue if you are reading this!). Second, the OS containers are not like for like when compared to a full VM installation, so there may be some things you can’t test properly in the container.

You can read more about the project here: https://github.com/test-kitchen/kitchen-dokken

Configuring Kitchen Dokken for Cinc

Configuring Test Kitchen to work with Cinc was covered in the Cooking with Cinc post, here just the provisioner needed to updated to get it to work. For kitchen-dokken however, we will also need to update the driver as this references the client container to use.

The basic configuration for Dokken when using Chef is:

driver:
 name: dokken
 chef_version: latest

transport:
 name: dokken

provisioner:
 name: dokken

verifier:
 name: inspec

platforms:
 - name: rockylinux-8
 driver:
 image: dokken/rockylinux-8

suites:
 - name: default
 run_list:
 - recipe[testing::default]

To change the client container that’s used, we need to update both the image and the tag that are pulled. As an example to use the latest 17 version of the official Cinc container we would change the driver section to be:

driver:
 name: dokken
 chef_image: cincproject/cinc
 chef_version: 17

Next we need to update the provisioner so that it knows how to run the Cinc client. This differs from the settings used in Cooking with Cinc in that the client is not downloaded as part of the provisioner any more, that was handled by the driver in this case, so we just need to update the product and client binary names:

provisioner:
 name: dokken
 product_name: cinc
 chef_binary: /opt/cinc/bin/cinc-client

And that’s it! Our completed example now looks like this:

driver:
 name: dokken
 chef_image: cincproject/cinc
 chef_version: 17

transport:
 name: dokken

provisioner:
 name: dokken
 product_name: cinc
 chef_binary: /opt/cinc/bin/cinc-client

verifier:
 name: inspec

platforms:
 - name: rockylinux-8
 driver:
 image: dokken/rockylinux-8

suites:
 - name: default
 run_list:
 - recipe[testing::default]

Running kitchen converge will pull any missing containers the first time it’s run and from then on will be considerably faster.

Breaking changes for redistributors

Sun, 10 May 2020 12:41:55 -0400

The short version

This blog post is intended specifically for other folks that are building their own distributions of Chef Software’s product, and folks leveraging the tip from my previous blog in their cookbooks.

We’re preparing to completely rewrite the current implementation of dist.rb in both Chef Infra and Chef Inspec. The short version is that we’re moving all the constants like Chef::Dist::PRODUCT to a new namespace and gem, respectively ChefUtils::Dist in the chef-utils gem. By moving dist.rb in there, we can effectively maintain all the trademark constants in a single, central gem.

Do note this only applies to Ruby-based tools. Go-based tools will continue using the code generator.

The long version

One of the Cinc Project’s defined goals is to make Chef Software Inc’s products easily distributable under a configurable name. We’ve dubbed the feature simply “dist” for short. The initial dist implementation was done a little bit haphazardly as both the project and Chef’s product teams were exploring this new reality of trademark compliance. When we started, as most projects do, we didn’t quite know how this would all turn out.

As a result, there was a lack of coherence in naming and each repo had it’s own implementation of the dist constants that we use to substitute Chef’s trademarks. In chef/chef, we even ended up with 2 distinct implementations of dist.rb. In short, it had slowly evolved into something difficult to maintain, both for us as main contributors on the feature and for the maintainers, despite the concept’s simplicity.

chef-utils is a fairly recent addition to the Chef Infra codebase. While it’s source lives in chef/chef, it is a distinct rubygem published alongside chef. It’s intended to be a “foundations” ruby library use by Chef Software for low level helpers that are common in the ecosystem like .windows?. That made it the perfect place to unify all our constants.

Thankfully, we’d already done the work of substituting all references in code to trademarks with unique constants. This allowed aggressive strategies in migrating to the new implementation. I used codemod, a mass refactor CLI tool, to accomplish this quickly while still getting a human’s attention on each change.

The resulting unified implementation can be seen here: https://github.com/chef/chef/pull/9834

As I’m writing this, that PR is marked as WIP to prevent it being merged before this blog post has a chance to be read by our intended audience. Once we have it merged (That should happen before Chef Infra 16.1 is released upstream), we’ll proceed to modifying every other ruby Chef Software repo where we’ve implemented dist to use chef-utils, so be aware that there may be more breaking changes in the dist implementation of other products Cinc redistributes. This should all be confined to a short time span, and we hope this will be the final implementation of dist.

This of course doesn’t mean that we’re done with upstream contributions! We still find the occasional wordmark that slipped by, or was erroneously introduced since we first did all this, so we have to remain vigilant.

I sincerely hope this won’t cause any issues for anyone, but if so please visit the PR I linked above and make it known.

April 2020 update

Fri, 03 Apr 2020 21:48:55 -0400

What’s new with Cinc?

We’ve been busy! Since my last post in january, the team has not only kept up with releases of Cinc-Client and Cinc-Auditor but also improved many aspects of the project.

With the release of Chef Infra 16 approaching fast, we’ve started getting Cinc-Client 16 builds ready. There’s also been significant work on our Cinc-Workstation pipeline, which now outputs artifacts of all but Windows builds, and those are in progress too.

Our pipelines have been significantly refactored to simplify the way we manage our patching process and allow easily embedding our gems into otherwise standard Omnibus packages. We now use a git merge based strategy as opposed to maintaining patch files. If you were maintaining your own distribution based on our work you’ll want to have a look at the new format for our pipelines.

You may also notice some improvements on this very website: We have the first implementation of our RSS feed that went live recently. We’re interested in feedback on the format and content of the feed. Another less noticeable change is the addition of a robots.txt and sitemap.

You may also be interested to know that work has begun on Cinc-Server. While there isn’t much more to report on that topic yet we have a very motivated contributor who’s picked it up and is actively working on it.

In related news, Cinc-project friend and contributor CT has been hard at work on his own implementation of the Chef Infra™ server API, Goiardi, in order to address some of the last missing pieces for full Chef Infra™ server 13 compliance.

Contributors new and old

Project contributors have changed a bit these past months. Most notably, one of our founding members, Artem Sidorenko, has left the project to pursue some exciting life opportunities. Artem is the man behind Cinc-Auditor, for which he both did the work upstream and created the build pipelines. We can’t thank you enough for your deep involvement in the Cinc Project and we wish you all the best!

We also have a few new faces. We’d like to welcome Vern Burton (tarcinil). He brings some much needed Golang skills to the project team, skills that he’s already been putting to good use in the repos that constitute the Workstation. He’s been working at implementing the Go code generator created by Salim Afiune in relevant Workstation projects. Thanks to his contributions we’re confident our first release of Cinc-Workstation is just around the corner. Welcome aboard!

Just arrived in the Chef Community a few weeks ago, we have Josh Gitlin (jgitlin), who’s wasted no time and started work on Cinc-Server roughly 5 minutes about hearing about Cinc! Such enthusiasm is more than welcome and we look forward to celebrating the first PRs against the Chef Server repos to implement configurable distribution names. Welcome aboard!

We’re also seeing an increase in traffic on our Gitlab, with small but helpful contributions such as opening issues, providing feedback, helping keep docs up to date, and correcting my horrible grammar and vocabulary on this very blog o.O Free Open Source Software projects live by such small contributions and we encourage everyone reading this to pitch in however they can. Visit the contributing page for some ideas of how you can help too.

Chef free products EOL

We knew the day was coming, now it’s just around the corner: Unless there’s a drastic turn of events, on May 1st 2020 most of Chef’s free binaries will have reached end of life and will no longer be receiving updates from Chef Software. This will leave a lot of folks with 2 options: get a commercial agreement with Chef Software, or move to other solutions.

Cinc being the exact same code, barring trademark related changes, you can confidently migrate to our binaries. Existing automation should continue functioning thanks to our wrappers around the upstream binaries, and so will your muscle memory if you’ve been typing chef-client for a decade. If this statement proves to be inaccurate please open an issue, we’ll do our best to address it.

Here’s the short list of changes people migrating solutions can expect to look into:

Chef Infra™ client –> Cinc-client
Chef Infra™ server –> Goiardi
- Cinc-server is being worked on
- Chef Server 12 is not actually going EOL yet
Chef Inspec™ –> Cinc-auditor
Chef Habitat™ –> see Cinc-project friends biome.sh
- Cinc’s own Habitat distro is considered low priority by the project in the presence of such a great alternative.
Chef Workstation –> Cinc-Workstation
- Experimental builds are available, but currently not compliant with Chef’s trademark policy
  - Windows builds have proven to be more difficult and are not currently available, but we’re working on it.
- Under the Chef EULA, you may still use our workstation for testing purposes, and we’d certainly welcome the feedback!
- We’re looking for someone with expertise in Rust to contribute. If you want to help come see us on Gitlab or the Chef Community Slack.

That’s some big updates

Absolutely! As I write this a significant proportion of the world population is in self-imposed quarantine including project members. I can only assume it will take it’s toll on our own working pace, but we’re not stopping on account of some pandemic. We still hope to have Cinc-Workstation ready for May 1st so no one gets stuck with EOL software.

This concludes this update. Try out the new RSS feed to get future updates delivered to you. Take care of yourselves and each other, especially in these strange times.

Cooking with Cinc

Tue, 28 Jan 2020 15:31:30 -0500

So what’s cooking?

As part of a private project I’m looking to deploy a Goiardi server, and what better way to do so than with Cinc Client? My first stop was, as always, the Chef Supermarket, where one can find excellent cookbooks to feed into Cinc. There I found this cookbook by Matt Whiteley.

It’s a little bit dated, but that’s an easy issue to solve; We’ll update it! The new trend in community cookbooks is to write ‘resource cookbooks’, that is cookbooks that define custom resources and libraries but no recipes. I therefor set out to write a custom resource to install and manage a goiardi instance.

Cinc + Test Kitchen

After a bit of keyboard smashing I was ready for some kitchen magic. I didn’t need any new plugins or gems, just a few lines in my cookbook’s kitchen.yml:

Edit

Users of Cinc Workstation will need to use the following syntax:

provisioner:
 name: chef_zero
 product_name: cinc
 download_url: https://omnitruck.cinc.sh/install.sh

Chef Workstation users can continue using the following until such time as Cinc Workstation stable builds are available:

provisioner:
 name: chef_zero
 require_chef_omnibus: true
 chef_omnibus_url: https://omnitruck.cinc.sh/install.sh
 chef_omnibus_root: /opt/cinc

Using the usual chef-zero provisioner, I simply point kitchen to the Cinc Project’s Omnitruck and to the correct folder. Then when I run kitchen test:

-----> Installing Chef install only if missing package
Downloading https://omnitruck.cinc.sh/install.sh to file /tmp/install.sh
Trying curl...
Download complete.
el 7 x86_64
Getting information for cinc stable for el...
downloading https://omnitruck.cinc.sh/stable/cinc/metadata?v=&p=el&pv=7&m=x86_64
to file /tmp/install.sh.4088/metadata.txt
[...]
Updating / installing...
1:cinc-15.5.15-1.el7 ################################# [100%]
Symlinking chef-apply command to cinc-wrapper for compatibility...
Symlinking chef-client command to cinc-wrapper for compatibility...
Symlinking chef-shell command to cinc-wrapper for compatibility...
Symlinking chef-solo command to cinc-wrapper for compatibility...
Thank you for installing Cinc Client, the community build based on Chef Infra Client!
Transferring files to <remove-centos-7>
Redirecting to cinc-client...
Starting Cinc Client, version 15.5.15

And now we’re testing with Cinc! You’ll note there was no license prompt, as you’d expect from a free as in freedom distribution.

But now my files are full of lies

One thing I like to do in my file and template resources is to add a “This is a Chef generated file” type disclaimer. But this isn’t a Chef generated file, it’s a Cinc generated file! If I just put Cinc, then it shows Cinc to a Chef Infra™ user too. Thankfully that’s another easy solve. We can call on the distribution constants implemented by the Cinc Project upstream like so:

require 'chef/dist'

file '/tmp/a_file' do
 content "This file was generated by #{Chef::Dist::PRODUCT}"
 action :create
end

Now when my cookbook writes /tmp/a_file, it’ll output the name of the product you’re using, whether that’s Cinc, Chef Infra™ or MyOrgPrivateDistroOfChefInfraClient (please don’t name it that, for the sanity of your users o.O ). You can find a complete list of these distribution constants in https://github.com/chef/chef/blob/master/lib/chef/dist.rb (don’t forget to navigate to the appropriate tag for your version!).

Do note this is the first implementation of distro constants and unlikely to be the last. While I’m excited to share this little trick with you all I also feel I should warn against using it just yet without some sort of safeguard against having a constant pulled from under you. Said safeguard can be as simple as:

require 'chef/dist'
product = Chef::Dist::PRODUCT || 'A Configuration Manager'
log "This log resource is being executed by #{product}"

Back to my cookbook!

So I wrote a resource called goiardi_install, tested it with Cinc in test-kitchen, and adjusted my templates so they output the correct product name to all the cookbook’s users. What’s left? Publishing of course! The initial intent was to PR the resources to the goiardi cookbook but following some discussions on Slack we opted to release it as cinc-goiardi and to officially support it, since we currently recommend Goiardi as a FOSS Chef Infra™ server alternative. With the resources published, I wrote a quick and dirty wrapping recipe:

# Recipe my_goiardi::default

goiardi_install 'goiardi' do
 version '0.11.10'
end

And voila! We can run that through Chef Infra™ or Cinc Client seamlessly.

Cinc Client is live

Wed, 04 Dec 2019 16:05:34 -0500

The Cinc project is proud to announce the initial release of Cinc Client

It’s been a long time coming, but the Cinc team is finally ready to announce it’s first official release of Cinc Client for Linux. While we have been distributing it for some time, it came with all kinds of disclaimers about compliance with Chef Software’s policy on trademarks. No longer!

Chef Software has reviewed Cinc Client and deemed it compliant with it’s policy as reported on Chef’s Community Slack. Sadly it’s not a paid Slack, so it will eventually vanish in the backlog, so we took a nice screenshot for posterity: https://gitlab.com/cinc-project/client/issues/10

A big thanks to the folks at Chef Software for taking the time to review our builds so we can publish them with confidence.

GimmeGimme!

Checkout our Installation pages for some basic instructions, or just jump right in by using our omnitruck implementation curl -L https://omnitruck.cinc.sh/install.sh | sudo bash

Prefer plain old packages? We got you covered too! Checkout our download page of skip right ahead to the latest releases of Cinc Client!

Test-kitchen is where you like to try out your new toys? Put this in your kitchen file’s provisioner section:

Edit

Cinc Workstation users should use this new syntax:

provisioner:
 name: chef_zero
 product_name: cinc
 download_url: https://omnitruck.cinc.sh/install.sh

Chef Workstation users should continue using the existing syntax until such time as stable Cinc Workstation builds are available:

provisioner:
 name: chef_zero
 require_chef_omnibus: true
 chef_omnibus_url: https://omnitruck.cinc.sh/install.sh
 chef_omnibus_root: /opt/cinc

We do not have hart packages available at this time, but it’s only a matter of time. If you’re in a hurry, as always we welcome contributions.

What next?

Work is already well underway to producing a fully compliant Cinc Client for Windows platforms, and we expect a first official release in the near future. In the meantime feel free to download our test builds and provide feedback through the usual channels.

Cinc Auditor is also ready for evaluation and the Cinc project has requested that Chef Software take a look at it too. We already distribute test builds so we can gather feedback from the community, but we do not recommend using them for any commercial purposes at this time.

Stay tuned to this blog to find out when more binaries get evaluated!