Hello,
in the past couple of week I've pushed multiple changes to the
https://github.com/freeipa/freeipa-container
repository, fixing and enabling Fedora 28 and Fedora 29 Dockerfiles, adding Travis CI configuration where we currently test IPA master and replica setups in images of Fedoras from 23 to rawhide and on CentOS 7:
https://travis-ci.org/freeipa/freeipa-container/branches
Testing on Travis' Ubuntus allowed me to reproduce and fix some issues that people have observed on non-RHEL/CentOS/Fedora docker hosts. One of the results is that docker run's --privileged or --cap-add SYS_ADMIN options should not be needed anymore, making things more confined and more secure. In fact, it's quite likely that running the FreeIPA server containers as privileged will result in
https://github.com/freeipa/freeipa-container/issues/254
... so just don't do it.
Another focus of the effort was to make it possible to run the containers as read-only (docker run --read-only), making all the changes that are done during the initial ipa-server-install or during runtime properly confined to the /data volume, or pointed to discardable /tmp. While things pass in my local read-only tests, in Travis CI the initial ipa-server-install phase runs fine but starting the read-only container afterwars seems to hang:
https://travis-ci.org/adelton/freeipa-container/builds/459418370
Any help with investigating why this is happening would be appreciated.
On Mon, Nov 26, 2018 at 09:53:16AM +0100, Jan Pazdziora via FreeIPA-users wrote:
Hello,
in the past couple of week I've pushed multiple changes to the
https://github.com/freeipa/freeipa-container
repository, fixing and enabling Fedora 28 and Fedora 29 Dockerfiles, adding Travis CI configuration where we currently test IPA master and
Hello,
slightly related to the FreeIPA containerization effort, I've now updated
Web application authentication developer setup https://pagure.io/webauthinfra https://github.com/adelton/webauthinfra
to use Fedora 28. The developer setup shows the use of FreeIPA and Ipsilon IdP for GSSAPI and SAML authentication in Web applications, and it can be used as an example of IPA-enrolled client containers.
I've also added Travis CI configuration for the setup and it seems it's working fine:
https://travis-ci.org/adelton/webauthinfra
The multi-container CI setup can hopefully also serve as an example that people can reuse.
On Thu, Dec 13, 2018 at 09:36:57PM +0100, Jan Pazdziora via FreeIPA-users wrote:
On Mon, Nov 26, 2018 at 09:53:16AM +0100, Jan Pazdziora via FreeIPA-users wrote:
Hello,
in the past couple of week I've pushed multiple changes to the
https://github.com/freeipa/freeipa-container
repository, fixing and enabling Fedora 28 and Fedora 29 Dockerfiles, adding Travis CI configuration where we currently test IPA master and
Hello,
slightly related to the FreeIPA containerization effort, I've now updated
Web application authentication developer setup https://pagure.io/webauthinfra https://github.com/adelton/webauthinfra
to use Fedora 28. The developer setup shows the use of FreeIPA and Ipsilon IdP for GSSAPI and SAML authentication in Web applications, and it can be used as an example of IPA-enrolled client containers.
I've also added Travis CI configuration for the setup and it seems it's working fine:
https://travis-ci.org/adelton/webauthinfra
The multi-container CI setup can hopefully also serve as an example that people can reuse.
I've looked at the possibility of updating the Web application authentication developer setup to Fedora 29 so that we go with the latest greatest Fedora release.
We are hitting
https://bugzilla.redhat.com/show_bug.cgi?id=1660067
there, so that blocks us a bit. Thanks to Jakub H. for helping me isolate the issue so that we have it at least tracked.
Also, Ipsilon being Python 2 only prevents us moving the www-with-app container to Python 3, which would mean we'd have to support both Django 1.11 and Django 2.1. It likely is not a big deal to do so but it'd be nice to phase out Python 2 completely.
If anyone has spare cycles to help porting Ipsilon to Python 3, it'd be useful -- the issue for that request is
https://pagure.io/ipsilon/issue/309
So for now the setup is based on Fedora 28 and depending on the Ipsilon future, I will either update it to Fedora 29 later, or look at the possibility of using Keycloak instead. If people are interested in Keycloak and can show patch which would use that, I'd be happy to review and add it to the setup.
On Mon, Nov 26, 2018 at 09:53:16AM +0100, Jan Pazdziora via FreeIPA-users wrote:
Another focus of the effort was to make it possible to run the containers as read-only (docker run --read-only), making all the changes that are done during the initial ipa-server-install or during runtime properly confined to the /data volume, or pointed to discardable /tmp. While things pass in my local read-only tests, in Travis CI the initial ipa-server-install phase runs fine but starting the read-only container afterwars seems to hang:
I've resolved all issues that I saw with read-only containers and enabled testing --read-only run containers in .travis.yml.
If you are on Fedora/RHEL/CentOS where oci-systemd-hook package is installed and enabled, the container can be read-only out of box, except if you include DNS in your FreeIPA server container, you need to setup the resolv.conf in the container (likely via --dns option to docker run) as the container will not be able to modify that configuration from within.
If you don't have oci-systemd-hook, you may need to create and bind-mount /etc/machine-id to the container from the host because again, the container will not be able to create that file after it has started. You can check tests/run-master-and-replica.sh for example how it's done in Travis CI.
Running the container read-only means that all the writes that the container does both during initialization (ipa-server-install / ipa-replica-install) and in runtime are now properly routed either to the data volume (mounted to /data) or to temporary volume (tmpfs under /tmp).
In Travis CI, we still run a bunch of build with read-write setup, with followup docker diff checks, to catch potential future situations when new version of packages (FreeIPA or any of the dependent ones) starts to use some new location for its configuration or data. Hopefully that way we'll be notified about such situation early and update the image definition (possibly just volume-data-list or volume-tmp-list).
Hi,
ipa commands and the web ui login work fine with ipa accounts -
$ ssh -p 2222 user1@192.168.87.90 user1@192.168.87.90's password: Last login: Sun Dec 23 16:12:32 2018 from 192.168.87.90 -sh-4.2$ klist Ticket cache: KEYRING:persistent:1060800015:krb_ccache_Y8lD56F Default principal: user1@LOCAL.LAN
Valid starting Expires Service principal 23/12/18 19:16:20 24/12/18 19:16:20 krbtgt/LOCAL.LAN@LOCAL.LAN -sh-4.2$ ipa trust-find --------------- 1 trust matched --------------- Realm name: windocker.jackland.demon.co.uk Domain NetBIOS name: WINDOMAIN Domain Security Identifier: S-1-5-21-3550747279-381245828-2166630727 ---------------------------- Number of entries returned 1 ---------------------------- -sh-4.2$
However, these don't work with AD users -
$ ssh -p 2222 user3@windocker.jackland.demon.co.uk@192.168.87.90 user3@windocker.jackland.demon@192.168.87.90's password: Last login: Sun Dec 23 17:59:26 2018 from 192.168.87.90 -sh-4.2$ klist Ticket cache: KEYRING:persistent:638401138:krb_ccache_pjehZUI Default principal: user3@WINDOCKER.JACKLAND.DEMON.CO.UK
Valid starting Expires Service principal 23/12/18 19:21:23 24/12/18 05:21:23 krbtgt/WINDOCKER.JACKLAND.DEMON.CO.UK@WINDOCKER.JACKLAND.DEMON.CO.UK renew until 24/12/18 19:21:22 -sh-4.2$ ipa trust-find ipa: ERROR: cannot connect to 'https://ipa001.local.lan/ipa/json': Internal Server Error -sh-4.2$ klist Ticket cache: KEYRING:persistent:638401138:krb_ccache_pjehZUI Default principal: user3@WINDOCKER.JACKLAND.DEMON.CO.UK
Valid starting Expires Service principal 23/12/18 19:21:54 24/12/18 05:21:23 HTTP/ipa001.local.lan@LOCAL.LAN renew until 24/12/18 19:21:22 23/12/18 19:21:49 24/12/18 05:21:23 krbtgt/LOCAL.LAN@WINDOCKER.JACKLAND.DEMON.CO.UK renew until 24/12/18 19:21:22 23/12/18 19:21:23 24/12/18 05:21:23 krbtgt/WINDOCKER.JACKLAND.DEMON.CO.UK@WINDOCKER.JACKLAND.DEMON.CO.UK renew until 24/12/18 19:21:22 -sh-4.2$
The access_log on the ipa server contains for these -
192.168.96.2 - user1@LOCAL.LAN [23/Dec/2018:19:16:43 +0000] "POST /ipa/json HTTP/1.1" 200 90140 192.168.96.2 - user1@LOCAL.LAN [23/Dec/2018:19:16:44 +0000] "POST /ipa/session/json HTTP/1.1" 200 278 192.168.96.2 - user3@WINDOCKER.JACKLAND.DEMON.CO.UK [23/Dec/2018:19:21:54 +0000] "POST /ipa/json HTTP/1.1" 500 527
.. and ther error_log -
[Sun Dec 23 19:15:18.812726 2018] [wsgi:error] [pid 9113:tid 139948548441856] [remote 192.168.96.3:43412] mod_wsgi (pid=9113): Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'. [Sun Dec 23 19:15:18.812857 2018] [wsgi:error] [pid 9113:tid 139948548441856] [remote 192.168.96.3:43412] TypeError: sequence of byte string values expected, value of type int found [Sun Dec 23 19:16:43.723255 2018] [wsgi:error] [pid 9112:tid 139948548441856] [remote 192.168.96.2:51012] ipa: INFO: [jsonserver_kerb] user1@LOCAL.LAN: schema(known_fingerprints=('145a5999',), version='2.170'): SUCCESS [Sun Dec 23 19:16:44.277967 2018] [:warn] [pid 9452:tid 139948665587456] [client 192.168.96.2:51024] failed to set perms (3140) on file (/var/run/ipa/ccaches/user1@LOCAL.LAN)!, referer: https://ipa001.local.lan/ipa/xml [Sun Dec 23 19:16:44.530489 2018] [wsgi:error] [pid 9113:tid 139948548441856] [remote 192.168.96.2:51024] ipa: INFO: [jsonserver_session] user1@LOCAL.LAN: trust_find/1(None, version='2.229'): SUCCESS [Sun Dec 23 19:21:55.463003 2018] [wsgi:error] [pid 9112:tid 139948548441856] [remote 192.168.96.2:51142] mod_wsgi (pid=9112): Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'. [Sun Dec 23 19:21:55.463144 2018] [wsgi:error] [pid 9112:tid 139948548441856] [remote 192.168.96.2:51142] TypeError: sequence of byte string values expected, value of type int found
I've tried adding settings for windocker.jackland.demon.co.uk to /etc/krb5.conf on the ipa master (both LOCAL.LAN and WINDOCKER.JACKLAND.DEMON.CO.UK), but neither choices made any difference.
[domain_realm] .local.lan = LOCAL.LAN local.lan = LOCAL.LAN ipa001.local.lan = LOCAL.LAN
.windocker.jackland.demon.co.uk = LOCAL.LAN windocker.jackland.demon.co.uk = LOCAL.LAN
The version is -
-sh-4.2$ ipa --version VERSION: 4.6.4, API_VERSION: 2.229 -sh-4.2$
For testing both the client and server are currently Docker containers running Centos 7.
Can anyone please explain how to fix this ?
Thanks
Bob Hinton
freeipa-users@lists.fedorahosted.org
-
Bob Hinton -
Jan Pazdziora