Closed slominskir closed 8 months ago
We do not test such configuration at all. However, did you enable systemd operations at all in wsl? See https://devblogs.microsoft.com/commandline/systemd-support-is-now-available-in-wsl/
Thanks. After entering my WSL Ubuntu 20.04.6 LTS distro shell and adding systemd=true
to the WSL distro config and restarting everything the freeipa-container now works. Would be useful to document all this in README for other Windows users.
Step 1: Stop Docker Desktop. Step 2: Configure WSL distro and shut it down:
C:\Users\RyanS>bash
ryans@COMPUTER:/mnt/c/Users/RyanS$ echo -e "[boot]\nsystemd=true" | sudo tee -a /etc/wsl.conf > /dev/null
ryans@COMPUTER:/mnt/c/Users/RyanS$ exit
wsl --shutdown
Step 3: Start Docker Desktop Step 4: Run docker compose up where docker-compose.yml is:
services:
ipa:
image: freeipa/freeipa-server:rocky-9-4.10.2
hostname: ipa.example.com
container_name: ipa
sysctls:
- net.ipv6.conf.all.disable_ipv6=0
environment:
IPA_SERVER_INSTALL_OPTS: '-r EXAMPLE.COM -N -U'
PASSWORD: password
volumes:
- /sys/fs/cgroup:/sys/fs/cgroup:ro
Note: I guess the /sys/fs/cgroup
mount is actually mounting into WSL distro, and not local windows filesystem?
Thank you for the update, @slominskir. May be you can submit a pull request that modifies the README?
Note: I guess the
/sys/fs/cgroup
mount is actually mounting into WSL distro, and not local windows filesystem? correct. This is pulling the Linux host's cgroup view into the container.
PR created. Odd README -> README.md setup! Means GitHub webpage doesn't preview README changes.
Historically I don't think I've ever used absolute volume bind mounts before now and relative ones work as you'd intuitively expect: it's relative to the project directory on the Windows filesystem (which perhaps is simply cloned into the WSL filesystem). Absolute paths starting in the WSL filesystem does make sense though. Thanks.
The contention between who's software has the privilege and responsibility to manage Linux PID 1 tasks in a container, systemd vs containerd, is interesting. Sounds like major reason Podman was created.
Note that containerd is rarely run in a container (unless you are doing something like container in container).
The systemd in the FreeIPA container image(s) is simply there, it is set in the ENTRYPOINT to be run by default, and without it the container will not reasonably function. The WSL systemd=true
configuration has nothing to do with the systemd in the container.
The systemd you enabled in the WSL is likely only needed to establish the /sys/fs/cgroup
mountpoint and as I commented in https://github.com/freeipa/freeipa-container/pull/579#issuecomment-1889784434, I wonder if technically you even need systemd on the WSL Linux machine, if having things mounted wouldn't be enough.
The example compose above didn't work until I added the magic Alexander suggested, which was setting systemd=true
inside the wsl.conf of my WSL distro.
I trust you. I just tried to clarify what you've actually configured.
At the same time, the fact that this particular configuration caused the correct change of behaviour in your setup does not necessarily mean that this is the only or the best approach to do that in general.
In https://github.com/freeipa/freeipa-container/pull/579 we discussed what the recommendation should be and while systemd=true
, it seems to configure cgroups v1 and the setup was a bit volatile.
I'm looking for a Docker Compose example of launching freeipa-container that works on Windows. Here is an example that doesn't work:
ipa.yml
Fails with:
I've tried various other configurations, but I haven't found the magic combination yet. I'm wondering if it may not work as I've seen discussions suggesting freeipa-container requires systemd and systemd in containers has historically been problematic and still may be in Docker Desktop on Windows. I'm not sure if the volume
/sys/fs/cgroup
is even doing what is expected as the volume may be mounting in Windows.I can override the entrypoint to something like:
And then the container starts fine and I can poke around with:
Not sure what to look for though. If I try running the original entrypoint I see:
Environment: Fully patched Windows 11 with latest Docker Desktop: