freeipa / freeipa-openshift-container

FreeIPA container for OpenShift 4

FreeIPA Server

FreeIPA allows Linux administrators to centrally manage identity, authentication and access control aspects of Linux and UNIX systems by providing simple to install and use command line and web based management tools.

FreeIPA is built on top of well known Open Source components and standard protocols with a very strong focus on ease of management and automation of installation and configuration tasks.

FreeIPA can seamlessly integrate into an Active Directory environment via cross-realm Kerberos trust or user synchronization.

Benefits

FreeIPA:

• Allows all your users to access all the machines with the same credentials and security settings
• Allows users to access personal files transparently from any machine in an authenticated and secure way
• Uses an advanced grouping mechanism to restrict network access to services and files only to specific users
• Allows central management of security mechanisms like passwords, SSH Public Keys, SUDO rules, Keytabs, Access Control Rules
• Enables delegation of selected administrative tasks to other power users
• Integrates into Active Directory environments

Components

The FreeIPA project provides unified installation and management tools for the following components:

• LDAP Server - based on the 389 project
• KDC - based on MIT Kerberos implementation
• PKI based on Dogtag project
• Samba libraries for Active Directory integration
• DNS Server based on BIND and the Bind-DynDB-LDAP plugin

Project Website

Releases, announcements and other information can be found on the IPA server project page at http://www.freeipa.org/ .

Documentation

The most up-to-date documentation can be found at http://freeipa.org/page/Documentation .

Quick Start

To get started quickly, start here: http://www.freeipa.org/page/Quick_Start_Guide

For developers

• Building FreeIPA from source
  • http://www.freeipa.org/page/Build
  • See the BUILD.txt file in the source root directory

Licensing

Please see the file called COPYING.

Contacts

• If you want to be informed about new code releases, bug fixes, security fixes, general news and information about the IPA server subscribe to the freeipa-announce mailing list at https://www.redhat.com/mailman/listinfo/freeipa-interest/ .
• If you have a bug report please submit it at: https://pagure.io/freeipa/issues
• If you want to participate in actively developing IPA please subscribe to the freeipa-devel mailing list at https://lists.fedoraproject.org/archives/list/[email protected]/ or join us in IRC at irc://irc.libera.chat/freeipa

freeipa-openshift-container's Issues

[BUG] Pipeline build failing for fedora-32

Description

Failing container image build for fedora-32 when applying the list of patches.

Frequency

[x] Always

Wrong behaviour

The container build fail on the step which apply the patches.

Expected behaviour

The container build properly all the stages.

Additional information

https://travis-ci.org/github/freeipa/freeipa-openshift-container/builds/722950449

Upgrade from Free-IPA 4.9.x to 4.10.0 fails due to renamed gssproxy config file

Steps to reproduce:

1. Create the OKD/OpenShift image from freeipa/freeipa-server:fedora-36-4.9.10
2. Start a container for this image to initialize a fresh data volume
3. Create the OKD/OpenShift image from freeipa/freeipa-server:fedora-rawhide-4.10.0, also applying these patches:

• from PR #38 for issue #39
• from PR #41 for issue #40
• from PR #43 for issue #42

4. Start a container for the updated image using the existing data volume

Wrong behaviour:

• Free-IPA fails to start because gssproxy cannot be started. Reason: gssproxy complains about redundant configuration files 99-nfs-client.conf and 99-network-fs-clients.conf in its /etc/gssproxy (linked into data volume as /data/etc/gssproxy/)

Reason:

This commit renamed the config file. After the update, the old file still exists in the data volume. Also, I find that the new file is generated during the update procedure. In consequence, gssproxy find two files with redundant entries and it does not want to start. This leads to the whole Free-IPA failing to start (as it depends on the gssproxy service).

Workaround:

Do the "partial" update as in the steps 1 to 4 above. Then delete the old and obsolete gssproxy config file and restart the POD.

Build failure: manifest unknown

Description

Build is failing because the SHA reference to the parent image does not exists.

Steps to replay

• Just build the image.

Current results

The build fails with the message:

error creating build container: Error initializing source docker://***/freeipa-server@sha256:87d9615924dd1ca02a99222a621759ba3d1d9c2206ff55919e75a50a93fdc3a1: Error reading manifest sha256:87d9615924dd1ca02a99222a621759ba3d1d9c2206ff55919e75a50a93fdc3a1 in ***/freeipa-server: manifest unknown: manifest unknown

Expected result

The image build success.

Additional information

https://github.com/freeipa/freeipa-openshift-container/runs/4909340105?check_suite_focus=true

FAQ: docker run fails with IPv6 error message

On Fedora 32 host Docker / moby-engine fails with an IPv6 related error message:

$ docker run ... freeipa-server
systemd v245.6-2.fc32 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=unified)
Detected virtualization container-other.
Detected architecture x86-64.
Set hostname to <ipa.example.test>.
IPv6 stack is enabled in the kernel but there is no interface that has ::1 address assigned. Add ::1 address resolution to 'lo' interface. You might need to enable IPv6 on the interface 'lo' in sysctl.conf.
The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information
Tue Aug  4 13:25:49 UTC 2020 /usr/sbin/ipa-server-configure-first 

Workaround: https://docs.docker.com/config/daemon/ipv6/

• Edit /etc/docker/daemon.json to enable IPv6 support

{
  "ipv6": true,
  "fixed-cidr-v6": "2001:db8:1::/64"
}

• systemctl restart docker

Image build for fedora-rawhide failed on 2021-04-30

This issue was automatically created by GitHub Action

https://github.com/freeipa/freeipa-openshift-container/actions/runs/798308140.

[Fedora Rawhide - pre 37] running free-ipa in OKD/OpenShift fails since "systemd hardening efforts" were implemented

This commit introduces "systemd hardening efforts" to 389ds. Namely, they are:

# https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort
ProtectSystem=full
# Protectsystem full mounts /etc ro, so we need to allow /etc/dirsrv to be writeable here.
ReadWritePaths=/etc/dirsrv
ProtectHome=true
PrivateDevices=true
ProtectHostname=true
ProtectClock=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectKernelLogs=true
ProtectControlGroups=true
RestrictRealtime=true

These special protection measures require special privileges which a systemd-based container does not have when running inside OKD/Openshift - at least with the SCC defined here

Nightly upstream image build for fedora-rawhide failed on 2021-07-28

This issue was automatically created by GitHub Action

https://github.com/freeipa/freeipa-openshift-container/actions/runs/1076562198.

FAQ: empty /etc/machine-id causes dbus-broker-launch to fail with "No medium found"

When /etc/machine-id is empty and systemd has no permission to write to or bind mount over the file, dbus-broker is failing with an unhelpful error message:

dbus-broker-launch[1898]: ERROR launcher_run_child @ ../src/launch/launcher.c +325: No medium found

The problem causes the installation to fail when certmonger is started for the first time. The problem Failed to mount /etc/machine-id: Operation not permitted indirectly causes D-Bus to fail, which eventually fails the installation.

$ docker run ... freeipa-server ...
systemd v245.6-2.fc32 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=unified)
Detected virtualization container-other.
Detected architecture x86-64.
Set hostname to <ipa.example.test>.
Initializing machine ID from random generator.
Failed to mount /etc/machine-id: Operation not permitted

The log file for this installation can be found in /var/log/ipaserver-install.log
==============================================================================
...
  [13/31]: configure certmonger for renewals
  [error] CalledProcessError: CalledProcessError(Command ['/bin/systemctl', 'start', 'certmonger.service'] returned non-zero exit status 1: 'Job for certmonger.service failed because the control process exited with error code.\nSee "systemctl status certmonger.service" and "journalctl -xe" for details.\n')

Workaround: bind mount /etc/machine-id into container.

Upgrading existing data volumes to newer versions fails

I would like to use the freeipa-openshift-container with a persistent volume. As of now, I cannot upgrade to newer image versions because the upgrade job fails.

Steps to reproduce:

• Start with a fresh data volume
• Initialize volume with an older image (say for free-ipa 4.9.8)
• Stop old container and start a new container derived from a newer image (say for free-ipa 4.9.10).
• The container will notice that it has to run an upgrade but it fails midway due to missing systemd requirements (since systemd-tmpfiles was removed/replaced)

I provided a fix in !38

[Fedora Rawhide - pre 37] tmpfiles.py fails to generate/verify symlinks specified in /etc/tmpfiles.d/...

Steps to reproduce:

• derive openshift image from quay.io/freeipa/freeipa-server:fedora-rawhide ( tested with image sha256:639242245443f45bc9c658b8b6cba647ab5f5c25390b491256fdaeb538447178 )
• start a container from this image

Wrong behaviour:

when evaluating /usr/lib/tmpfiles.d/gssproxy.conf, tmpfiles.py runs into error:

FileExistsError: [Errno 17] File exists: '/run/gssproxy.default.sock' -> '/var/lib/gssproxy/default.sock'

(This is just the first error, there are other /usr/lib/tmpfiles.d/*.conffor which the generation fails.)