Rudder 7.0 release notes

We now have our own dedicated configuration DSL. This gives more flexibility in the way the configurations are defined, allows to define configurations directly as code, and easily share techniques.

This language is declarative and focuses on the policies correctness, by validating as much as possible during policy generation.

This language is compiled (or more precisely transpiled) into configuration code by a new rudderc program written in Rust.

We will give more details in a dedicated blog post soon.

The rules page has been rewritten, following our new UI scheme (initiated with the groups page). Is is now based on a tree on the left and a visualization and edition zone with tabs on the right, which will avoid a lot of scrolling compared to the previous layout, and will present information in a more structured manner.

This part is a first step, the ultimate goal being to make the configuration policies fully reproducible (like in reproducible builds), i.e. to be able to explore and/or apply the configuration of any point in the past. This requires archiving the full history of inventory, properties, etc.

We also want to be able to mix different versions of the same item (e.g. of one directive), to allow progressive deployments of changes.

The 7.0 release contains:

Techniques can now contain blocks which are groups of methods with a common condition, and the ability to configure compliance computing logic. Blocks can even be nested, and drag-and-drop works as usual.

It is possible to use one of three variants for compliance computation:

This allows getting more comprehensive compliance reports, with more meaningful numbers.

It is now possible to disable reporting for any method, and hence ignore it in the compliance. This is particularly useful for methods used as tests, for example if you want to test the present of a package with Package present, and use it as a condition to trigger other actions. Instead of having to resort to Condition from command for every test, you can now use any existing method directly.

You can now have multiple technique drafts, give them a name and access them in the techniques list. This allows switching context without losing what you were doing.

We added a new feature allowing to define secret variables, which means their value will be provided at creation, but not re-displayed in the interface afterwards. This allows preventing the involuntary display of passwords in Rudder interface.

The server roles have been removed in favor of a simpler mechanism based on settings in the application configuration file. It is now easy to use an external PostgreSQL database with a Rudder server.

relayd, the component handling agent-server communication, now has a prometheus endpoint, including:

This is a first step, and more observability tooling will continue to get added in next versions.

Augeas is a framework providing a tree-like view of a lot of different configuration file formats (through syntax definitions called lenses). This unified interface allows hassle-free advanced editions. Augeas is now embedded with the agent when not available as a system dependency.

The ports used for both communication channels (by default 443 and 5309) are now fully configurable. This will make setups in constrained environments easier. It is now also easy to use different ports and certificates for public HTTP used for Web and public API access and agent-server internal communications.

We now have a consistent homogeneous security mechanism across both communication channels, with the removal of syslog communication and the automatic setup of HTTPS certificate verification. We use Trust On First Use by default, but you can pin server keys at node provisioning too.

With the move of Red Hat to CentOS Stream (and the end of life of CentOS 8) for the end of the year, other alternatives have emerged or gained popularity. As a consequence, we now have full support (including relay and server) for AlmaLinux, Rocky Linux and Oracle Linux.

We added server support for Debian 11 (agent support was added in 6.2) and dropped SLES 12, RHEL/CentOS 7 and Debian 9, following our usual maintenance policy.

The agent comes with a more readable rudder agent info output.

We added a configure script for the agent build. This makes it more flexible (compared to our previous static Makefile) and adding support for new platforms becomes a lot easier.

We also improved our C hardening flags on modern compilers with fstack-protector-strong and D_FORTIFY_SOURCE=2 when possible, in addition to existing full relro and pie.

Elm has been our language of choice for frontend work for its great reliability and maintainability for a few years, and the transition is continuing with the technique editor rewrite (from AngularJS) and the new rules page.

rudder-relayd, the component handling communications with agents on server and relays is written in Rust and more precisely based on tokio, a fast and reliable asynchronous runtime. It has been migrated from tokio 0.1 to the 1.0 version, which comes with the (not so) Rust async/await syntax. It provides better development experience, better performance (with a new scheduler), and long-term maintenance of the library for 5 years minimum.

Compliance computations and display has been made more efficient, by using caches for both computed compliance and expected reports. It lowers the number of expensive database queries, and makes compliance computations much faster.

relayd also now handles more steps of reports handling, which is possible thanks to the syslog reporting removal. This lowers the load on the webapp and database and makes the whole process more efficient.

Our code tests, which all run on our Jenkins server also responsible for building our packages, were migrated from manually configured jobs to Jenkinsfile code (for example in the main rudder repository). This allows defining the tests along with the code, and eases jobs maintenance across branches.

Tests are now all run automatically on every pull requests (except for heavy multi-platform tests which only run daily on maintained branches).

In addition we improved our test suite in most repositories, with linters for various ecosystems (shellcheck, pylint, etc.), and added automated checks for known vulnerabilities in our dependencies across various ecosystems. Most tests now run in Docker containers defined by Dockerfiles in the repositories, allowing for more consistent and reproducible test environments.

Server system techniques are the part of system techniques that handle configuration and management of the server components (webapp, relayd, ldap server, etc.). We did a major refactoring of these techniques, which have been split in separate techniques for each configured service, for improved reliability and maintainability.

As usual in our major releases, most dependencies have been upgraded. In particular, we now require PostgreSQL ≥10 for Rudder servers.