2:53 a.m.
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.
--
Jan Pazdziora
Senior Principal Software Engineer, Security Engineering, Red Hat
2:36 p.m.
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.
--
Jan Pazdziora
Senior Principal Software Engineer, Security Engineering, Red Hat
5:39 a.m.
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.
--
Jan Pazdziora
Senior Principal Software Engineer, Security Engineering, Red Hat
1:15 p.m.
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).
--
Jan Pazdziora
Senior Principal Software Engineer, Security Engineering, Red Hat
1:39 p.m.
New subject: ipa commands and Web UI login failing with trusted AD domain
Hi,
ipa commands and the web ui login work fine with ipa accounts -
$ ssh -p 2222 user1(a)192.168.87.90
user1(a)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(a)LOCAL.LAN
Valid starting Expires Service principal
23/12/18 19:16:20 24/12/18 19:16:20 krbtgt/LOCAL.LAN(a)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(a)192.168.87.90
user3@windocker.jackland.demon(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)LOCAL.LAN [23/Dec/2018:19:16:43 +0000] "POST
/ipa/json HTTP/1.1" 200 90140
192.168.96.2 - user1(a)LOCAL.LAN [23/Dec/2018:19:16:44 +0000] "POST
/ipa/session/json HTTP/1.1" 200 278
192.168.96.2 - user3(a)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(a)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(a)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(a)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
1951
days inactive
1978
days old
freeipa-users@lists.fedorahosted.org
4 comments
2 participants
participants (2)
-
Bob Hinton -
Jan Pazdziora