What is Enterprise Linux Manager (ELM)?

We can build the same dev and prod pair for all three repositories, so the whole fleet has the same structure underneath it. With the content structure in place, we map it onto the actual fleet. We're going to create two host groups, dev and prod. The dev group gets the three dev views. The prod group gets the three prod views. Then, we assign the hosts, a couple to prod, a couple to dev. This is exactly how a real team splits up a fleet. Same three repositories, a different pin tier per group, one clean line between what is being tested and what is running on production. Each host talks to ELM through a small agent.

One thing worth pointing out why we install it, ELM will not serve the agent installer over plain HTTP. The packages are signed and it refuses to hand a signed installer down an unencrypted connection. Security is not an afterthought here. It is the default. We pull the installer over TLS, run it, and check the host in. Quickly, it shows up in ELM with its agent version and check-in time. And on the host itself, the managed repositories are now the ones its group was assigned. We have built the whole structure. Now, let's use it. Say we need to pull a package out of the fleet. We exclude it from a dev view and then recompose.

On a dev host, we search for that package, and look, it's gone. Dev took the change. Now, the exact same search on a production host. The package is still right there. Production did not take the change. This is the same fleet, same repositories. Two different answers to the same search. That is not a lag catching up. That is production holding because it has been pinned. Here is what is happening underneath. Every time you compose the dev view, you get a snapshot. A frozen point in time. Production is not chasing dev. It is pinned to one snapshot that you picked and you tested. Promotion is the moment you decide a newer snapshot is ready. You point production at it and recompose.

You are not rebuilding production and you are not going package by package. You are choosing which tested snapshot production is allowed to trust. That is a real patch approval step. Dev sees a change first. Production gets it only when you decide to promote it. ELM controls the content life cycle. It does not try to be everything to you. When there's an automation to run against these same hosts, we built ELM to hand off easily to Ascender. So you manage your content in ELM, but you manage your automation in Ascender. Use the right tool for the right job, but make sure they can interact cleanly with each other.

And by the way, this is not locked to just a single release. Adding a brand new OS is the same motion as everything else. We can create a source for RLC 10, point it to a depot, and then let it start mirroring. From here, it is the same workflow you just watched. Mirror, content views, host groups, promote. You can run multiple releases side by side and manage every one of them the same way. Let's review what we built. A source of truth on storage that you own. Content views that can freeze what exactly your hosts can install. Host groups that split dev from prod. We have an agent that keeps every host in line.

And then we built a promote workflow that moves a tested release into production the moment that you decide and not 1 second before. And remember, ELM comes with RLC Pro. If you'd like to learn more or have a guided demo of ELM in action, visit ciq.com today and sign up for more information.