Implement in S6 (Rather than systemd)

[ccravens]

Going through these images, it seems like there's a lot of shenanigans to get systemd working so that we can run so many services in a single image (understandably).

I feel that FreeIPA would be a perfect candidate for something like S6, which was designed for this very purpose. Seems like it would make for a much cleaner container with better service management?

https://github.com/just-containers/s6-overlay

The s6-overlay-builder project is a series of init scripts and utilities to ease creating Docker images using s6 as a process supervisor.

S6 Feature Overview:

• A simple init process which allows to the end-user execute tasks like initialization (cont-init.d), finalization (cont-finish.d) as well as fixing ownership permissions (fix-attrs.d).
• The s6-overlay provides proper PID 1 functionality
• You'll never have zombie processes hanging around in your container, they will be properly cleaned up.
• Multiple processes in a single container
• Able to operate in "The Docker Way"
• Usable with all base images - Ubuntu, CentOS, Fedora, and even Busybox.
• Distributed as a single .tar.gz file, to keep your image's number of layers small.
• A whole set of utilities included in s6 and s6-portable-utils. They include handy and composable utilities which make our lives much, much easier.
• Log rotating out-of-the-box through logutil-service which uses s6-log under the hood.
• Some support for Docker's USER directive, to run your whole process tree as a specific user. Not compatible with all features, details in the notes section.

Have the maintainers of freeipa-container considered or tried this out yet? I'm probably going to see if I can start implementing a conversion of the FreeIPA container to S6.

[adelton]

One of the great advantages of FreeIPA are its ipa-server-install / ipa-replica-install utilities to configure all necessary components. These in turn call systemctl in the process. How would S6 help in this situation?

By the way, can you be more specific about the shenanigans that you see as the problem and the base reason for your proposal? If there is a way to make the images more streamlined, by all means let's focus on removing any cruft we can.

I'm not particularly happy that freeipa-container depends on systemd but the proper solution would be to make FreeIPA itself configurable across multiple hosts / VMs, in other words FreeIPA natively offering itself for containerized split, including any configuration and setup tools. In freeipa-container project we just consume FreeIPA in the way matching its deployment on hosts (outside of containers), based on packaging for the specific OS versions (RHEL, CentOS, Fedora).

[ccravens]

wow, ok so the shenanigans I'm referring to are not with freeipa-container, but with Docker and the fact that it's difficult to configure a container to run multiple processes and manage those processes. I'm amazed that the contributors to this project were successful with it and am grateful and applaud what has been done.

S6 is useful for a lot of things that I feel could benefit the freeipa-container not only for better management of multiple processes but a lot of other process management utilities. Yes, I've reviewed a lot of the helper scripts and FreeIPA is not designed to run in containers, so a lot of work would have to be done to do this. In fact it's not until recent kubernetes releases that we can even configure an FQDN as a hostname in the container for FreeIPA, so getting something legacy like FreeIPA to run "cloud-native" is no small feat.

Anyways, apologies if any offense was taken regarding the suggestion, I'll go ahead and close the issue.

[abbra]

@ccravens FYI, FreeIPA components are intended to be run in the same namespace to allow UNIX domain socket connectivity. This might be achieved with multiple containers in the same pod but you'd soon discover there are quite a few things where we depend on systemd features beyond just process tracking functionality. For example, OTP integration in Kerberos is using UNIX domain socket activation feature and several other components heavily rely on D-BUS connectivity.

FQDN requirement is of a less issue with FreeIPA 4.9 which supports deployment with hostname without FQDN.

We run CI for FreeIPA project with Docker composes and systemd for about two years now in Azure Pipelines for every PR in git master, ipa-4-9, and ipa-4-8 branches. It mostly works fine. For Kubernetes deployments like OpenShift, we have a separate effort in https://github.com/freeipa/freeipa-openshift-container and https://github.com/freeipa/freeipa-operator. The only real issue with Docker and k8s right now is inability to use user namespaces to fully run IPA servers in rootless containers. We can do that with podman on Fedora since F32 already but k8s distributions lag behind and do not yet support user namespaces in the right way.

[adelton]

FQDN requirement is of a less issue with FreeIPA 4.9 which supports deployment with hostname without FQDN.

@abbra Would you have a link to more information about this possibility? I see https://pagure.io/freeipa/issue/4979 was closed wontfix, and there is https://pagure.io/freeipa/issue/8501 with freeipa/freeipa#5107 but it's not clear to me what the practical implication of that change is (if any, for deployments without FQDN).

[abbra]

deploying short-named client should work with the client and server code that includes PR#5107 changes. @frasertweedale and @tiran would be able to tell more details about the server side, though.

[frasertweedale]

(broader context because this is world-visible): at Red Hat we have a small team working on support for FreeIPA in OpenShift / Kubernetes. Our current efforts are focused around a systemd-based container running all the FreeIPA services, rather than splitting FreeIPA into multiple containers. There are now only a few gaps to this being possible.

Some other container runtimes, such as podman, already support systemd-based containers very well.

I also echo Alexander's comments about particular systemd-specific behaviours relied on in the FreeIPA system.

So at this time there is no plan to move to an alternative process supervisor. A split-service IPA system is a possible approach, if the current "monolithic" systemd-based approach fails for some reason.

That said, I am always happy to learn about alternative possibilities. Better to know about it than not!

[adelton]

@frasertweedale Is the change in freeipa/freeipa#5107 expected to make FreeIPA 4.9 server work on environments without FQDN? I am getting

The ipa-server-install command failed, exception: ScriptError: Invalid hostname 'ipa', must be fully-qualified.

when I try it with 4.9.6.