Scalability is an important feature of any infrastructure management solution. Either the to-be-managed infrastructure is big already or it is expected to grow as the business grows. Over time more and more resources are needed for CI/CD pipelines and more customers use the product(s). Generally, growing a business means more traffic and requests need to be handled by the infrastructure. Hence, scalability is an important metric for comparing infrastructure management tools when deciding which one to use. Or which ones. Read our latest white paper, benchmarking and comparing the scalability of Ansible and CFEngine for large scale infrastructure management:
Ansible and CFEngine are two configuration management tools and at first glance they look like competitors - two tools dealing with the same problem, in very different ways. But are they? Maybe they are actually not dealing with the same problem and are not as incompatible as it seems. Read our Ansible|CFEngine white paper providing an analysis of this area to learn more:
Introduction In the CFEngine Core team, we have recently been working on a fix for our WaitForCriticalSection() function. In short, the function checks a timestamp in a chunk of (lock) data stored in a local LMDB database and if the timestamp is too old, it writes a new chunk of (lock) data with the new timestamp. However, this used to be done in separate steps - read the data from the DB and close DB, check the data and potentially write the new data into the DB. So, there was a race condition because if multiple processes did the same steps at the same time, they could have read and checked the same timestamp value and then write their own data with their new timestamps one after another. On the high-level perspective that meant multiple processes could have entered the critical section at the same time.
Problem to solve When working on the new Federated Reporting feature for CFEngine we had to solve the problem of collecting data from multiple CFEngine hubs (feeders) on a single hub (superhub). CFEngine hubs are using PostgreSQL to store data, so, more specifically, the problem was how to collect data from multiple PostgreSQL databases in one PostgreSQL database. And because we are talking about ~1 GiB of SQL data per feeder hub and for example 10 feeders connected to a superhub here, the initial and trivial solution using basically this ETL (Extract Transform Load) pipeline - pg_dump | gz | ssh | gunzip | psql - provided really poor performance. The problem was in the last part of the pipeline - importing data using psql. Reading and writing 10 GiB of data of course takes a while, but we soon realized that I/O speed was not the bottleneck in this case.
Description The CFEngine engineering team has recently discovered a severe security issue in the CFEngine Enterprise product. CFEngine is using some internal secrets for authentication to the Mission Portal API and the PostgreSQL database when running background maintenance tasks. These internal secrets are randomly generated during the installation process and stored in files which only the root user has access to. Unfortunately, the commands that generate and store the secrets were being logged to the /var/log/CFEngineHub-Install.log installation log which was world-readable and thus accessible for any user logged in to the system (on the hub machine). Please note that this only affects the hub hosts, agent hosts don’t generate and use such internal secrets.
