[Freeipa-users] Re: How to I get FreeIPA running in Docker Swarm?
On Fri, Sep 22, 2023 at 12:10:50PM -, Jay Smith via FreeIPA-users wrote:
> I have the following Setup.
>
> MK_INTERNAL_SUB_DOMAIN=example.test
> MK_FREEIPA_SERVER_REALM=EXAMPLE.TEST
> MK_FREEIPA_SERVER_DS_PASSWORD=password
> MK_FREEIPA_SERVER_ADMIN_PASSWORD=password
> MK_FREEIPA_SERVER_DNS_REVERSE_ZONE=0.18.172.in-addr.arpa
> MK_FREEIPA_SERVER_IP=172.18.0.10
> MK_FREEIPA_SERVER_DOMAIN_NAME=ipa.example.test
>
> docker service create \
> --hostname ${MK_FREEIPA_SERVER_DOMAIN_NAME} \
> --name ipa \
> --sysctl net.ipv6.conf.all.disable_ipv6=0 \
> -e "IPA_SERVER_HOSTNAME=${MK_FREEIPA_SERVER_DOMAIN_NAME}" \
> -e "IPA_SERVER_IP=${MK_FREEIPA_SERVER_IP}" \
> -e "DEBUG_NO_EXIT=1" \
> -e "DEBUG_TRACE=1" \
> --ip "${MK_FREEIPA_SERVER_IP}" \
> --add-host "${MK_FREEIPA_SERVER_DOMAIN_NAME}:${MK_FREEIPA_SERVER_IP}" \
> -p "443:443" \
> --privileged=true \
> freeipa/freeipa-server:fedora-38-4.10.2 \
> --skip-mem-check \
> --domain=${MK_INTERNAL_SUB_DOMAIN} \
> --realm=${MK_FREEIPA_SERVER_REALM} \
> --ds-password=${MK_FREEIPA_SERVER_DS_PASSWORD} \
> --ip-address=${MK_FREEIPA_SERVER_IP} \
> --admin-password=${MK_FREEIPA_SERVER_ADMIN_PASSWORD} \
> --no-host-dns \
> --unattended \
> --setup-dns \
> --allow-zone-overlap \
> --auto-reverse \
> --reverse-zone=${MK_FREEIPA_SERVER_DNS_REVERSE_ZONE} \
> --auto-forwarders \
> --no-ntp
>
> The first problem is I can't run the container in privileged mode
Which is a good news -- you shouldn't be doing that anyway.
> and --ip and --add-host options are missing.
Why do you need those? And if you think you need those, why do you try
to use the swarm mode when by very nature of the FreeIPA server you
will not be able to use swarm scaling.
--
Jan Pazdziora | OpenShift AI | Red Hat
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: Get running FreeIPA in Docker in Docker
On Fri, Sep 22, 2023 at 12:03:19PM -, Jay Smith via FreeIPA-users wrote:
> Thank you very much for your hint Ulf. That's working for me.
>
> docker run -it \
> -h ${MK_FREEIPA_SERVER_DOMAIN_NAME} \
> --name ipa \
> --sysctl net.ipv6.conf.all.disable_ipv6=0 \
> -v /tmp/freeipa-data/data:/data \
> -e "IPA_SERVER_HOSTNAME=${MK_FREEIPA_SERVER_DOMAIN_NAME}" \
> -e "IPA_SERVER_IP=${MK_FREEIPA_SERVER_IP}" \
> -e "DEBUG_TRACE=1" \
> -e "DEBUG_NO_EXIT=1" \
> --privileged=true \
Where did you find the guidance to use --privileged=true?
Is it actively harmful to the general security posture of the system
and should be avoided. It hasn't been needed for FreeIPA server
containers for ages.
> --ip "${MK_FREEIPA_SERVER_IP}" \
> --add-host "${MK_FREEIPA_SERVER_DOMAIN_NAME}:${MK_FREEIPA_SERVER_IP}" \
> -p "443:443" \
> freeipa/freeipa-server:fedora-38-4.10.2 \
> --skip-mem-check \
> --domain=${MK_INTERNAL_SUB_DOMAIN} \
> --realm=${MK_FREEIPA_SERVER_REALM} \
> --ds-password=${MK_FREEIPA_SERVER_DS_PASSWORD} \
> --ip-address=${MK_FREEIPA_SERVER_IP} \
> --admin-password=${MK_FREEIPA_SERVER_ADMIN_PASSWORD} \
> --no-host-dns \
> --unattended \
> --setup-dns \
> --allow-zone-overlap \
> --auto-reverse \
> --reverse-zone=${MK_FREEIPA_SERVER_DNS_REVERSE_ZONE} \
> --auto-forwarders \
> --no-ntp
--
Jan Pazdziora | OpenShift AI | Red Hat
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: Custom ssl cert for freeipa docker
On Fri, Aug 25, 2023 at 10:54:45AM -, Leo O via FreeIPA-users wrote:
> I thought I had it running correctly, at the beginning it was working, but
> unfortunately the certificates were not updated/replaced. So I got the
> expired certificate warning when trying to access the freeipa UI.
> I’m running on docker based freeipa-server:rocky-9-4.10.0 and tried the
> following setup/files.
>
> 1-get-ca-certs.sh file:
> #!/bin/bash
> mkdir -p /srv/freeipa/ssl/{live,ca}
> CERTS=("isrgrootx1.pem" "isrg-root-x2.pem" "lets-encrypt-r3.pem"
> "lets-encrypt-e1.pem" "lets-encrypt-r4.pem" "lets-encrypt-e2.pem")
> for CERT in "${CERTS[@]}"
> do
> curl -o /srv/freeipa/ssl/ca/$CERT "https://letsencrypt.org/certs/$CERT;
> done
>
> Then executed:
> . /1-get-ca-certs.sh
> podman cp /srv/freeipa/ssl/ freeipa-server:/tmp/
>
>
> 2-install-ca-certs.sh file:
> CERTS=("isrgrootx1.pem" "isrg-root-x2.pem" "lets-encrypt-r3.pem"
> "lets-encrypt-e1.pem" "lets-encrypt-r4.pem" "lets-encrypt-e2.pem")
> for CERT in "${CERTS[@]}"
> do
> podman exec freeipa-server ipa-cacert-manage install /tmp/ssl/ca/$CERT
> done
>
>
> Then executed:
> ./2-install-ca-certs.sh:
> podman exec freeipa-server ipa-certupdate
>
>
> ipa-server-certinstall.sh file:
> #!/bin/bash
> runuser -l MYUSER -c 'podman exec -i freeipa-server ipa-server-certinstall -w
> -d /tmp/ssl/live/my-domain.com.key /tmp/ssl/live/my-domain.com.cer'
>
>
> And an auto expect script, which was used in a cron job to utilise
> ipa-server-certinstall.sh. But obviously “podman cp /srv/freeipa/ssl/
> freeipa-server:/tmp/“ (copy over ssl files into the container) and
> ”/usr/bin/expect /root/ipa-server-certinstall.exp” (execute
> ipa-server-certinstall.sh) wasn’t enough otherwise the cert wouldn’t expire.
>
> When I execute it manually I get: “cannot connect to
> 'https://freeipa1.my-domain.com:443/acme/directory': [SSL:
> CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired
> (_ssl.c:1129)
> The ipa-server-certinstall command failed.”
>
> How can I renew the expired certificate?
Having googled around a bit, the debugging steps from
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/S5R6RWQM3H277SAZ3AFAUMAK7ZQIDDJF/
might be applicable for your case as well.
--
Jan Pazdziora | Sr. Principal Software Engineer | Red Hat
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: FreeIPA in Containers - Ready for Prod?
On Thu, Aug 17, 2023 at 09:20:22AM -, Jonas R via FreeIPA-users wrote: > Hello all, > we have setup a test system with FreeIPA running on a docker (swarm) host and > are very happy with the tool. Now we are moving forward towards the planning > for implementation and considering wthether to run in in Containers or VMs. > > On the FreeIPA website it says "the team also maintains PoC container release > of FreeIPA". That's why I am wondering, if running FreeIPA in containers is > generally considered as something for testing environments or PoC, but not > for production. Are there any experiences running it in containers for > production? Or is everybody using bare metal/VMs? We are planning an > environment with 40-50 clients on one site. > Based on the feedback and issues reported on the https://github.com/freeipa/freeipa-container repo, there are numerous people running FreeIPA containers in production. The biggest hurdles seem to be to get the container running and the ipa-server-install properly finished the first time the container is started. If you have infrastructure that is biased towards containers (for example Kubernetes all over), you might pick that. You might gain more flexibility in the setup and potentially a bit leaner solution. It's also easier to get things confused and broken. If it's easy for you to spin up VMs and deal with keeping the up-to-date and regularly restarted, go with VMs. Since for production deployment you will want to have a master plus a couple of replicas, you can even mix and match. On Thu, Aug 17, 2023 at 11:41:22AM +0200, Ronald Wimmer via FreeIPA-users wrote: > As I understood the devs the only option would be an all-in-one container as > splitting up the components would introduce several challenges that would > need to be solved. And everything in one container is exactly the opposite > what a container should be... > It is exacly the opposite of what the container purists say a container should be. Since the main value of FreeIPA is the integration of services under one umbrella, I question what value people would get if instead of one container they had ten containers and they had the freedom and means to mix'n'match their configuration in some docker-compose YAML. I assume people would end up with many more broken deployments than if they get it all in one systemd-based container. If only because you'd likely lose the ipa-server-install that sets many of the things for you. > So... we do not consider the current container solution as ready for > production. > The VM with IdM on RHEL might be preferred for production deployments but for completely different reason than having FreeIPA container an all-in-one setup. Handling of data persistence and upgrades might be the weakest point ... but you'd get that challenge even if you had the solution broken into multiple containers. -- Jan Pazdziora | Sr. Principal Software Engineer | Red Hat ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: Failure during ipa-server-install on ipa-client-install part in the container
On Wed, Jul 12, 2023 at 05:29:53AM -, dweller dweller via FreeIPA-users
wrote:
> Introduction: We are currently using the Altlinux system, and the freeipa
> package is maintained in the repository provided at
> https://packages.altlinux.org/en/p10/srpms/freeipa/. To meet our specific
> requirements, I decided to create a container package based on the Altlinux
> p10 distribution. However, I have now encountered a problem while trying to
> install ipa-client inside the container. It seems that I am not receiving a
> session cookie for some reason. Although the logs indicate that the Ticket
> Granting Ticket (TGT) is successfully issued and stored at
> /etc/ipa/.dns_ccache (TGT for the host principal), there is a warning stating
> that the ipa_session cookie cannot be found. As a result, the request to
> /ipa/json fails with a 401 error.
>
[...]
> >2023-07-12T03:50:08Z DEBUG failed to find session_cookie in persistent
> >storage for principal
> >'host/ipamaster.ipa-test.novalocal@IPA-TEST-NOTLIKEDOMAIN.NOVALOCAL'
> >2023-07-12T03:50:08Z DEBUG trying
> >https://ipamaster.ipa-test.novalocal/ipa/json
> >2023-07-12T03:50:08Z DEBUG Created connection
> >context.rpcclient_139827748309840
> >2023-07-12T03:50:08Z DEBUG [try 1]: Forwarding 'schema' to json server
> >'https://ipamaster.ipa-test.novalocal/ipa/json'
> >2023-07-12T03:50:08Z DEBUG ENTERING SINGLE_REQUEST
> >2023-07-12T03:50:08Z DEBUG HOST:i (ipamaster.ipa-test.novalocal)
> >2023-07-12T03:50:08Z DEBUG HANDLER: (/ipa/json)
> >2023-07-12T03:50:08Z DEBUG REQUEST_BODY: (b'{"method": "schema", "params":
> >[[], {"version": "2.170"}], "id": 0}')
> >2023-07-12T03:50:08Z DEBUG New HTTP connection (ipamaster.ipa-test.novalocal)
> >2023-07-12T03:50:08Z DEBUG HTTP connection destroyed
> >(ipamaster.ipa-test.novalocal)
> >Traceback (most recent call last):
> > File
> > "/usr/lib64/python3/site-packages/ipaclient/remote_plugins/__init__.py",
> > line 120, in get_package
> >plugins = api._remote_plugins
> >AttributeError: 'API' object has no attribute '_remote_plugins'
> >
> >During handling of the above exception, another exception occurred:
> >
> >Traceback (most recent call last):
> > File "/usr/lib64/python3/site-packages/ipalib/rpc.py", line 727, in
> > single_request
> >if not self._auth_complete(response):
> > File "/usr/lib64/python3/site-packages/ipalib/rpc.py", line 673, in
> > _auth_complete
> >raise errors.KerberosError(
> >ipalib.errors.KerberosError: No valid Negotiate header in server response
> >2023-07-12T03:50:08Z DEBUG Destroyed connection
> >context.rpcclient_139827748309840
> >2023-07-12T03:50:08Z DEBUG File
> >"/usr/lib64/python3/site-packages/ipapython/admintool.py", line 180, in
> >execute
Should I venture a guess, based on the same errors that we saw
reported in
https://github.com/freeipa/freeipa-container/issues?q=is%3Aissue+is%3Aclosed
you run the container as privileged. Remove the --privileged from
your podman / docker run command.
--
Jan Pazdziora | Sr. Principal Software Engineer | Red Hat
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: Custom ssl cert for freeipa docker
On Fri, Jan 27, 2023 at 03:39:01PM -, Leo O via FreeIPA-users wrote: > I'm a bit confused by the time stamps of the messages, is @Jan's approach > working, was the "it isn't that simple..." for me only? As for now If @Jan is > right, I would copy the certificates into the container via "/tmp" or "/data" > and then go into the container and execute only "ipa-server-certinstall -w -d > mysite.key mysite.crt" and restart the container. That's should be all right, > I don't need the other commands? > My reply focused on your question "how would this be done when using freeipa in a docker/podman container". Rob focused on your plan of integrating acme.sh / LE to your setup and implications thereof. Ideally you'd have your acme.sh / LE setup done and verified and working on a non-containerized FreeIPA setup (on a host or in a VM) first, ironing out all the aspects Rob points out, before adding another layer of complexity of doing the same with the FreeIPA server running in a container. -- Jan Pazdziora | Red Hat ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: Custom ssl cert for freeipa docker
On Thu, Jan 05, 2023 at 03:22:25AM -, Leo O via FreeIPA-users wrote: > Hello Guys, > > I'm would like to use custom ssl certificates for http and ldap, I saw the > following: > https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > > But I wonder how would this be done when using freeipa in a docker/podman > container. You should be able to copy (docker cp / podman cp) the certificates to the container (to /tmp or /data) and then docker exec / podman exec into the container and run the commands shown on the page. -- Jan Pazdziora | Red Hat ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: basic docker deploy failing
On Fri, Jun 28, 2019 at 06:04:22PM +, Conley, Sean L. - US via
FreeIPA-users wrote:
> Hello,
>
>
> I need some assistance getting a basic functional docker-based FreeIPA server
> deploy working. I am not sure what I am missing, but the install is
> consistently failing on the client setup portion at the end. I have tried a
> number of variations for install options, but always end up with the same
> result. Any assistance would be much appreciated.
>
>
> This is a good example of how I am bootstrapping the container:
>
>
> host=ipa
> domain=example.com
> realm=EXAMPLE.COM
> password=Secret123
> rm -rf /data/ipa/*
> cat << EOF > /data/ipa/ipa-server-install-options
> --setup-dns \
> --forwarder=10.2.0.2 \
> --allow-zone-overlap \
> --domain=${domain} \
> --realm=${realm} \
> --hostname=${host}.${domain} \
> --ds-password=${password} \
> --admin-password=${password} \
> --no-ntp \
> --verbose \
> --unattended
> EOF
> docker run -it --rm -e DEBUG_TRACE=1 -e DEBUG_NO_EXIT=1 --name ${host} -h
> ${host}.${domain} \
> -e PASSWORD=$password \
> -v /data/ipa:/data:Z -v /sys/fs/cgroup:/sys/fs/cgroup:ro --tmpfs /run --tmpfs
> /tmp \
> -p 53:53/udp -p 53:53 -p 80:80 -p 443:443 -p 389:389 -p 636:636 -p 88:88 -p
> 464:464 \
> -p 88:88/udp -p 464:464/udp -p 123:123/udp -p 7389:7389 -p 9443:9443 -p
> 9444:9444 -p 9445:9445 \
> --privileged --userns=host freeipa/freeipa-server
>
>
> It appears that most of the install runs as expected, but this is what I get
> in the end:
>
>
> No valid Negotiate header in server response
> The ipa-client-install command failed. See /var/log/ipaclient-install.log for
> more information
>
>
>
> Here are some additional details from the ipaclient-install.log:
>
>
> Traceback (most recent call last):
> File
> "/usr/lib/python3.7/site-packages/ipaclient/remote_plugins/__init__.py", line
> 126, in get_package
> plugins = api._remote_plugins
> AttributeError: 'API' object has no attribute '_remote_plugins'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "/usr/lib/python3.7/site-packages/ipalib/rpc.py", line 726, in
> single_request
> if not self._auth_complete(response):
> File "/usr/lib/python3.7/site-packages/ipalib/rpc.py", line 679, in
> _auth_complete
> message=u"No valid Negotiate header in server response")
> ipalib.errors.KerberosError: No valid Negotiate header in server response
> 2019-06-28T17:01:04Z DEBUG Destroyed connection
> context.rpcclient_140381178350560
Sorry for the late reply.
Could you retry without the --privileged option?
--
Jan Pazdziora
Senior Principal Software Engineer, Security Engineering, Red Hat
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Access IPA Vault from container
On Tue, May 07, 2019 at 02:47:59PM -, Dmitry Perets via FreeIPA-users wrote: > Hi, > > I have a use-case when an application needs to access the secret stored in > IPA Vault. The problem is that the application is containerized... > So what would be the best practice to authenticate to the Vault? > > The logic says we should use REST API, but how to authenticate to the IPA, > without having to put user/password in a file inside the container...? > Enroll the container with IPA and use Kerberos...? > Or mount a keytab file from the enrolled parent host and install Kerberos > package in the container to use it...? > > Does anyone have an experience with this? In general, you will want to authenticate somehow, which means proving identity. So the first question is -- what is the identity here? The service that the container provides? Or the host on which this container runs? If you scale the containers to run two in parallel, say in Kubernetes, do you want each container to have its own identity or act on behalf of a single one? After you decide what the identities should be, you can then create service principals for them in IPA and get credentials (keytabs), and then the question is, how do you want distribute the credentials. Depending on the layout of your container platform, you can put them to the host filesystem and mount to the container, or you can distribute them as secrets using (say) Kubernetes' secrets mechanism. We've even had setup in which the bearers of the identities were the actual hosts on which the containers were running, and we were able to delegate the access from the containers to the hosts ... but even then you need to deal with the initial question -- what is the identity? How do you distinguish one container from another? So overall, all the options that you mentioned are possible, it all depends on your environment and needs. -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, Red Hat ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA containerization status
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 ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA containerization status
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 ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA containerization status
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 ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] FreeIPA containerization status
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 ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Running FreeIPA server containers on Ubuntu docker setups / Travis CI
On Thu, Jul 05, 2018 at 02:20:48PM +0200, Jan Pazdziora via FreeIPA-users wrote: > On Thu, Jul 05, 2018 at 02:14:20PM +0200, Jan Pazdziora wrote: > > > > I can reproduce the problem on Fedora for example with > > > > docker run --security-opt=seccomp=unconfined --rm -ti -e > > DEBUG_NO_EXIT=true -e PASSWORD=Secret123 -h ipa.example.test > > freeipa/freeipa-server:fedora-27 -U -r EXAMPLE.TEST --no-ntp > > > > -- the seccomp=unconfined allows the first operation but due to > > lack of CAP_CHOWN, the second one then fails. > > I can "fix" this on Fedora with > > --privileged --security-opt=seccomp=unconfined > > but I don't consider it a good solution for obvious reasons. For the record, I went with --privileged in Travis CI for OSes that need it: https://github.com/freeipa/freeipa-container/blob/master/.travis.yml#L34 CentOS 7 and Fedora rawhide do not, so we are testing at least something unprivileged. -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, Red Hat ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/2HUHXPXO3LVZEARYCL2TJ7ALVE5MVEQY/
[Freeipa-users] Re: Running FreeIPA server containers on Ubuntu docker setups / Travis CI
On Thu, Jul 05, 2018 at 11:20:57AM +0300, Alexander Bokovoy wrote: > > the docker 17.09.0-ce behaviour on that system is and if seccomp can > > somehow be tweaked? > I cannot give you an answer on Ubuntu parts but may be you can instead > remove use of KEYRING ccache from krb5.conf, thus removing the reason > for seccomp modification? This is not about Kerberos caches using kernel keyring. This is about session keyring created by systemd: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1691096 https://github.com/systemd/systemd/issues/6281 https://bugzilla.redhat.com/show_bug.cgi?id=1492081 Presumably it assumed that if it can create the keyring, it will be able to chown it as well, leading to systemd[593]: pki-tomcatd@pki-tomcat.service: Failed at step KEYRING spawning /usr/sbin/pki-server: Permission denied On Fedora and RHEL with docker from distribution/Extras, docker is built and configured to use seccomp, and it prevents it from being able to being able to create the keyring in the first place, so things do not fail. I can reproduce the problem on Fedora for example with docker run --security-opt=seccomp=unconfined --rm -ti -e DEBUG_NO_EXIT=true -e PASSWORD=Secret123 -h ipa.example.test freeipa/freeipa-server:fedora-27 -U -r EXAMPLE.TEST --no-ntp -- the seccomp=unconfined allows the first operation but due to lack of CAP_CHOWN, the second one then fails. I believe Ubuntu used by Travis CI and the docker build that is there do not support seccomp, so things run similar to seccomp=unconfined on Fedora. Container run from the centos-7 image does not fail because systemd there did not have that logic yet, the fedora-rawhide image does not fail because the logic in systemd has been fixed since. -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, Red Hat ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/Z523Y6IN3OUAVJC5L5KXPOUZQ7UUFFRL/
[Freeipa-users] Running FreeIPA server containers on Ubuntu docker setups / Travis CI
Hello, I and Stanislav have been setting up Travis CI for the https://github.com/freeipa/freeipa-container repository. We now run docker build operations for pull requests and commits, and I've been trying to add docker run tests as well. Example Travis build https://travis-ci.org/adelton/freeipa-container/builds/400275700 from https://github.com/adelton/freeipa-container/commit/16ced918f8492e583ff024b5ab507eff9d3399ec seems to pass on CentOS and rawhide images but fails on other Fedoras. All the failures are in the Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes [1/28]: configuring certificate server instance [error] RuntimeError: CA configuration failed. step. I remember that due to the way systemd was handling KEYRING operations, seccomp:unconfined was one of the things that has been causing issues in our tests on Fedora hosts. Running docker info in Travis CI shows that it's running 17.09.0-ce and there are no Security Options listed, unlike on my Fedora 28's docker-1.13.1-59.gitaf6b32b.fc28.x86_64 which has Security Options: seccomp Profile: /etc/docker/seccomp.json selinux Are there people around with Ubuntu knowledge who could check what the docker 17.09.0-ce behaviour on that system is and if seccomp can somehow be tweaked? Thank you, -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, Red Hat ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/SXCN64HOM5IJDM6NCXKGBVVV6KJ6FQHY/
[Freeipa-users] Re: ipsilon
On Tue, May 22, 2018 at 02:38:11PM +, Andrew Meyer via FreeIPA-users wrote: > What about on CentOS 7? On Thu, May 17, 2018 at 07:45:34PM +, Andrew Meyer via FreeIPA-users wrote: > So I followed the directions to add it to my dev freeipa servers, restarted > the httpd. But when I go to log in at https://myserver/idp as admin or > myself, I get 401 Unauthorized no matter what. This is what I need to > install the server: > sudo ipsilon-server-install --openid --saml2 yes --ipa yes --info-nss yes CentOS 7 ships Ipsilon 1.0.0 while ipsilon-openidc (needed for the --openid option above) only started to be available with Ipsilon 2. How did you install Ipsilon on CentOS 7 so that the above ipsilon-server-install command passed for you? -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, Red Hat ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/RFLWXBTKCRFGJ2Z6Q57D4DCE4VPFFZOJ/
[Freeipa-users] Re: ipsilon
On Thu, May 17, 2018 at 10:53:13PM +0300, Alexander Bokovoy via FreeIPA-users wrote: > On to, 17 touko 2018, Andrew Meyer wrote: > > So I followed the directions to add it to my dev freeipa servers, > > restarted the httpd. But when I go to log in at > > https://myserver/idp as admin or myself, I get 401 Unauthorized no > > matter what. This is what I need to install the server: sudo > > ipsilon-server-install --openid --saml2 yes --ipa yes --info-nss yes > I do not run Ipsilon on the same machine as IPA master and do not > recommend that. Use a separate IPA client. It used to work fairly well in 2015: https://www.adelton.com/freeipa/freeipa-ipsilon-single-machine and I've used it for number of demos and testing. However, at least with Fedora 28, it will fail simply because FreeIPA is python3 and Ipsilon is python2, and wsgi does not like mixing the two. -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, Red Hat ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/HARK4W4OWO5M4DPBNL7C6OK5CY3JWCKD/
