July 2024 - FreeIPA-users - Fedora mailing-lists

demo1.freeipa.org
by veck zuo 10 Jul '24

10 Jul '24

I am deploying the freeIPA demo follwing below link. https://www.freeipa.org/page/Demo [root@localhost ~]# ping www.google.com PING www.google.com (142.250.196.68) 56(84) bytes of data. 64 bytes from maa03s46-in-f4.1e100.net (142.250.196.68): icmp_seq=1 ttl=128 time=347 ms 64 bytes from maa03s46-in-f4.1e100.net (142.250.196.68): icmp_seq=2 ttl=128 time=348 ms ^C --- www.google.com ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 346.995/347.316/347.637/0.321 ms [root@localhost ~]# [root@localhost ~]# ipa-client-install --domain demo1.freeipa.org -p admin -w Secret123 This program will set up IPA client. Version 4.9.13 Skip ipa.demo1.freeipa.org: LDAP server is not responding, unable to verify if this is an IPA server Skip ipa.demo1.freeipa.org: LDAP server is not responding, unable to verify if this is an IPA server Provide your IPA server name (ex: ipa.example.com) ^CThe ipa-client-install command failed. See /var/log/ipaclient-install.log for more information

2 3

FreeIPA docker ccaches
by Paavo Nugin 09 Jul '24

09 Jul '24

Hello! I'm trying to migrate away from our old IPA server running on Centos 7. After solving multiple problems I've reached the following setup: ipa.domain - old centos 7 VM ipa1.domain - new replica, rocky 8 freeipa docker container running on Ubuntu 22.04 (because AFAIK it's not supported to go straight from 7 to 9) ipa2.domain - new replica, rocky 9 freeipa docker container running on Ubuntu 22.04 Mostly everything seems to work fine, I can authenticate against any of 3 servers but I've hit annoying problem that I've haven't yet solved despite extensive google-fu. So scenario is as follows: 1) kinit on my laptop - works ok (ubuntu 22.04) 2) use firefox to access https://ipa2.domain - SSO works perfectly without asking any credentials. 3) restart ipa2.domain container 4) hit f5 in firefox - login screen, asks for username and password - not working quite as expected. No amount of kdestroy or kinit against any of 3 servers will solve it (I don't have IPA DNS setup and set servers manually in krb5.conf). I can login with entering username and password manually but SSO won't work (but SSO works perfectly against ipa.domain and ipa1.domain). Same scenario is happening with ipa1.domain when I restart it. I'm not really eager to restart ipa.domain since our users are using it but I'm 99% sure that it wont have the same problem since it's not running in container and previous restarts have not produced such issue. What helps - deleting cookies in browser - then SSO starts to work again - until next restart of container. httpd/error_log: [Tue Jul 09 14:51:00.648879 2024] [wsgi:error] [pid 322:tid 550] [remote myIP:38914] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Tue Jul 09 14:51:00.649030 2024] [wsgi:error] [pid 322:tid 550] [remote myIP:38914] ipa: DEBUG: WSGI jsonserver_i18n_messages.__call__: [Tue Jul 09 14:51:00.649309 2024] [wsgi:error] [pid 322:tid 550] [remote myIP:38914] ipa: DEBUG: WSGI jsonserver.__call__: [Tue Jul 09 14:51:00.649343 2024] [wsgi:error] [pid 322:tid 550] [remote myIP:38914] ipa: DEBUG: WSGI WSGIExecutioner.__call__: [Tue Jul 09 14:51:00.655929 2024] [wsgi:error] [pid 322:tid 550] [remote myIP:38914] ipa: DEBUG: raw: i18n_messages(version='2.253') [Tue Jul 09 14:51:00.656035 2024] [wsgi:error] [pid 322:tid 550] [remote myIP:38914] ipa: DEBUG: i18n_messages(version='2.253') [Tue Jul 09 14:51:00.660245 2024] [wsgi:error] [pid 322:tid 550] [remote myIP:38914] ipa: INFO: [jsonserver_i18n_messages] UNKNOWN: i18n_messages(version='2.253'): SUCCESS [Tue Jul 09 14:51:00.660291 2024] [wsgi:error] [pid 322:tid 550] [remote myIP:38914] ipa: DEBUG: [jsonserver_i18n_messages] UNKNOWN: i18n_messages(version='2.253'): SUCCESS etime=10778664 [Tue Jul 09 14:51:00.801704 2024] [:warn] [pid 326:tid 408] [client myIP:38908] KRB5CCNAME file (/run/ipa/ccaches/myuser@DOMAIN-8gyvGu) lookup failed!, referer: https://ipa2.domain/ipa/ui/ [Tue Jul 09 14:51:00.802729 2024] [wsgi:error] [pid 321:tid 553] [remote myIP:38908] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Tue Jul 09 14:51:00.802792 2024] [wsgi:error] [pid 321:tid 553] [remote myIP:38908] ipa: DEBUG: WSGI jsonserver_session.__call__: [Tue Jul 09 14:51:00.802861 2024] [wsgi:error] [pid 321:tid 553] [remote myIP:38908] ipa: DEBUG: Valid Referer https://ipa2.domain/ipa/ui/ [Tue Jul 09 14:51:00.806518 2024] [wsgi:error] [pid 321:tid 553] [remote myIP:38908] ipa: DEBUG: ccache expired or invalid, deleting session, need login [Tue Jul 09 14:51:00.806570 2024] [wsgi:error] [pid 321:tid 553] [remote myIP:38908] ipa: DEBUG: 401 Unauthorized need login [Tue Jul 09 14:51:00.818339 2024] [:warn] [pid 466:tid 486] [client myIP:38914] KRB5CCNAME file (/run/ipa/ccaches/myuser@DOMAIN-8gyvGu) lookup failed!, referer: https://ipa2.domain/ipa/ui/ [Tue Jul 09 14:51:00.819251 2024] [wsgi:error] [pid 324:tid 556] [remote myIP:38914] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Tue Jul 09 14:51:00.819313 2024] [wsgi:error] [pid 324:tid 556] [remote myIP:38914] ipa: DEBUG: WSGI KerberosLogin.__call__: [Tue Jul 09 14:51:00.819378 2024] [wsgi:error] [pid 324:tid 556] [remote myIP:38914] ipa: DEBUG: Valid Referer https://ipa2.domain/ipa/ui/ [Tue Jul 09 14:51:00.822213 2024] [wsgi:error] [pid 324:tid 556] [remote myIP:38914] ipa: DEBUG: ccache expired or invalid, deleting session, need login [Tue Jul 09 14:51:00.822279 2024] [wsgi:error] [pid 324:tid 556] [remote :38914] ipa: DEBUG: 401 Unauthorized need login /run/ipa/ccaches/ folder is indeed empty. When I delete cookies and are able to log on then I see files created in that folder but they disappear after container restart. docker command that I used to setup up replica is slight modification to one described in: https://hub.docker.com/r/freeipa/freeipa-server/ docker run -ti --dns=IP1 --dns=IP2 --name freeipa-server -h ipa2.domain --read-only -v /var/lib/ipa-data:/data:Z -v /etc/localtime:/etc/localtime:ro -v /etc/timezone:/etc/timezone:ro -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 freeipa/freeipa-server:rocky-9 ipa-replica-install --password 'random-password' --server=ipa1.domain --domain=domain Any ideas how to overcome this problem? BR, Paavo

3 3

zone_journal_compact: could not get zone size: not found
by Kees Bakker 09 Jul '24

09 Jul '24

Hi, At the moment I have three FreeIPA systems (replicas), recently installed with CentOS 9-Stream. All three of these show this message at irregular intervals. Jul 03 07:50:44 iparep5.example.com named[541]: zone example.com/IN: zone_journal_compact: could not get zone size: not found Jul 03 07:50:51 iparep5.example.com named[541]: zone 16.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 07:51:03 iparep5.example.com named[541]: zone 17.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 07:51:34 iparep5.example.com named[541]: zone 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 07:52:12 iparep5.example.com named[541]: zone 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:03:51 iparep5.example.com named[541]: zone example.com/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:04:52 iparep5.example.com named[541]: zone 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:06:30 iparep5.example.com named[541]: zone 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:18:42 iparep5.example.com named[541]: zone example.com/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:20:19 iparep5.example.com named[541]: zone 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:26:23 iparep5.example.com named[541]: zone 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:34:12 iparep5.example.com named[541]: zone example.com/IN: zone_journal_compact: could not get zone size: not found Jul 03 08:34:50 iparep5.example.com named[541]: zone 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone size: not found After posting this on the bind-users mailing list I did a bit more debugging. It turns out that the message is caused by the fact that bind-dyndb-ldap does not implement the getsize method. Now why didn't I see this message on my CentOS 8-Stream system? Well, it is because the bind package went from 9.11.26 to 9.16.23. In that newer version a new function zone_journal_compact was added which does the following: zone.c: journalsize= zone->journalsize; if(journalsize== -1) { journalsize= DNS_JOURNAL_SIZE_MAX; dns_db_currentversion(db, &ver); result= dns_db_getsize(db, ver, NULL, &dbsize); dns_db_closeversion(db, &ver, false); if(result!= ISC_R_SUCCESS) { dns_zone_log(zone, ISC_LOG_ERROR, "zone_journal_compact: " "could not get zone size: %s", isc_result_totext(result)); } elseif(dbsize< DNS_JOURNAL_SIZE_MAX/ 2) { journalsize= (int32_t)dbsize* 2; } } and dns_db_getsize executes this: isc_result_t dns_db_getsize(dns_db_t*db, dns_dbversion_t*version, uint64_t*records, uint64_t*bytes) { REQUIRE(DNS_DB_VALID(db)); REQUIRE(dns_db_iszone(db)); if(db->methods->getsize!= NULL) { return((db->methods->getsize)(db, version, records, bytes)); } return(ISC_R_NOTFOUND); } However, the getsize method is not implemented. Thus you'll get the above mentioned messages. I'm surprised that nobody reported this. Everybody with FreeIPA + DNS + CentOS 9-Stream should be getting these messages. The messages are colored in red in journalctl, as if this is a serious problem. Is it? Or can I ignore this message? -- Kees

2 1

Disable user password expiration immediately after password reset.
by luckydog xf 07 Jul '24

07 Jul '24

Once the admin changes the user password, it will expire immediately. Can we disable this policy?

3 3

Re: ipa upgrade failed
by Johannes Falke 07 Jul '24

07 Jul '24

How did you actually manage to resolve this issue? I'm seeing the same thing trying to upgrade either f35->f37 or f35->f36 (and NO ldap errors). On f35, freeipa says it's healthy.

3 5

`ipactl restart` fails with `Unknown error when retrieving list of services from LDAP: not enough values to unpack (expected 2, got 1)`
by Andrea Stacchiotti 05 Jul '24

05 Jul '24

Hello everyone, freshly installed ipa server on Oracle Linux 9, via the ansible role at https://github.com/freeipa/ansible-freeipa/blob/master/roles/ipaserver/READ… The installation goes apparently well, but if I try restarting the service I get the error in the subject, which prevents dirsrv from starting, a debug log is at the end. This is apparently a known issue, as https://access.redhat.com/solutions/5268961 exists to address it, but I don't have a subscription and I found no other results on the internet. It seems to be an issue finding services, but `ipa service-find` finds HTTP and ldap as expected. Can someone help? Thanks ------------ [root@ipa-innovation opc]# ipactl start -d ipa: DEBUG: importing all plugin modules in ipaserver.plugins... ipa: DEBUG: importing plugin module ipaserver.plugins.aci [...] Starting Directory Service ipa: DEBUG: Starting external process ipa: DEBUG: args=['/bin/systemctl', 'start', 'dirsrv(a)PRIVATE-ACUS-EU.service'] ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: Starting external process ipa: DEBUG: args=['/bin/systemctl', 'is-active', 'dirsrv(a)PRIVATE-ACUS-EU.service'] ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout=active ipa: DEBUG: stderr= ipa: DEBUG: wait_for_open_ports: localhost [389] timeout 120 ipa: DEBUG: waiting for port: 389 ipa: DEBUG: SUCCESS: port: 389 ipa: DEBUG: Start of dirsrv(a)PRIVATE-ACUS-EU.service complete ipa: DEBUG: Starting external process ipa: DEBUG: args=['/bin/systemctl', 'is-active', 'dirsrv(a)PRIVATE-ACUS-EU.service'] ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout=active ipa: DEBUG: stderr= Failed to read data from service file: Unknown error when retrieving list of services from LDAP: not enough values to unpack (expected 2, got 1) Shutting down ipa: DEBUG: Starting external process ipa: DEBUG: args=['/bin/systemctl', 'stop', 'dirsrv(a)PRIVATE-ACUS-EU.service'] ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: Stop of dirsrv(a)PRIVATE-ACUS-EU.service complete ipa: DEBUG: File "/usr/lib/python3.9/site-packages/ipaserver/install/installutils.py", line 781, in run_script return_value = main_function() File "/usr/lib/python3.9/site-packages/ipaserver/install/ipactl.py", line 735, in main ipa_start(options) File "/usr/lib/python3.9/site-packages/ipaserver/install/ipactl.py", line 398, in ipa_start raise IpactlError(rval=e.rval) ipa: DEBUG: The ipactl command failed, exception: IpactlError:

3 5

CentOS 7 - named-pkcs11 crashes / won't start after patches/security upgrades
by Braden McGrath 05 Jul '24

05 Jul '24

See subject... I have 3 CentOS 7 VMs running as FreeIPA Servers. I ran a standard "yum update" as root; these packages were included as part of that update: bind.x86_64 32:9.11.4-26.P2.el7_9.16 bind-dyndb-ldap.x86_64 11.1-7.el7_9.1 bind-export-libs.x86_64 32:9.11.4-26.P2.el7_9.16 bind-libs.x86_64 32:9.11.4-26.P2.el7_9.16 bind-libs-lite.x86_64 32:9.11.4-26.P2.el7_9.16 bind-license.noarch 32:9.11.4-26.P2.el7_9.16 bind-pkcs11.x86_64 32:9.11.4-26.P2.el7_9.16 bind-pkcs11-libs.x86_64 32:9.11.4-26.P2.el7_9.16 bind-pkcs11-utils.x86_64 32:9.11.4-26.P2.el7_9.16 bind-utils.x86_64 32:9.11.4-26.P2.el7_9.16 Previously, bind-dyndb-ldap had been on 11.1-7.el7 (no "_9.1" suffix) And the rest had been on the exact same versions as above, but ending in .15. After the upgrade, named-pkcs11 crashes when started by systemctl, with the following journalctl output (server domain has been anonymized but everything else was untouched): Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: ../../../lib/dns-pkcs11/name.c:1114: REQUIRE((target != ((void *)0) && (__builtin_expect(!!((target) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(target))->magic == (0x42756621U)), 1))) || (target == ((void *)0) && (__builtin_expect(!!((name->buffer) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(name->buffer))->magic == (0x42756621U)), 1)))) failed, back trace Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #0 0x561df47e5130 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #1 0x7fac0362b48a in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #2 0x7fac03930b7b in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #3 0x7fabfb6efb78 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #4 0x7fabfb6effee in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #5 0x7fabfb6f198b in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #6 0x7fabfb6f1b89 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #7 0x7fabfb6fb528 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #8 0x7fac03650713 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #9 0x7fac0365128b in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #10 0x7fac01726ea5 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #11 0x7fac00799b0d in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: exiting (due to assertion failure) Jul 02 19:39:19 ipa3.example.net systemd[1]: named-pkcs11.service: main process exited, code=killed, status=6/ABRT Jul 02 19:39:19 ipa3.example.net systemd[1]: Unit named-pkcs11.service entered failed state. Jul 02 19:39:19 ipa3.example.net systemd[1]: named-pkcs11.service failed. I was able to get named to start again by running a "yum downgrade" of the above list of bind-related packages. Obviously, now the server is "behind" on patches though. I'm not sure how to report this further to get it investigated/fixed, or if any action will even be taken at this point now that CentOS7 is EOL. I'm happy to provide additional details if requested. Regards, Braden McGrath braden(a)big-geek.net

4 4

Unable to access LDAP server - ipa-server-install
by Meikel Bloch 04 Jul '24

04 Jul '24

Hey everyone, just tried to install freeipa on a hetzner cloud server cause i'm actually looking for alternative to UCS. I still dont get it, why FreeIPA is in need to be reachable on a public net, but thats not the point here. I have a clean, fresh Fedora 40 with running network, hostname resolves, also reverse dns - behind a OPNsense NAT Gateway with its own ipv4 public ip. I have opened the Ports 389 & 636 When trying to run ipa-server-install, the following error occurs, where i cant understand why it cant access the LDAP server. I've checked up with nmap - port is open. Further LDAP service seems to run. Maybe someone has an idea whats going on? INFO: Loading PKI Tomcat config: /usr/share/pki/etc/tomcat.conf INFO: Connecting to LDAP server at ldap://fsn-ipa.domain.tld:389 ERROR: Unable to access LDAP server: ldap://fsn-ipa.domain.tld:389 Traceback (most recent call last): File "<frozen runpy>", line 198, in _run_module_as_main File "<frozen runpy>", line 88, in _run_code File "/usr/lib/python3.12/site-packages/pki/server/pkispawn.py", line 987, in <module> main(sys.argv) File "/usr/lib/python3.12/site-packages/pki/server/pkispawn.py", line 560, in main check_ds() File "/usr/lib/python3.12/site-packages/pki/server/pkispawn.py", line 722, in check_ds verify_ds_configuration() File "/usr/lib/python3.12/site-packages/pki/server/pkispawn.py", line 58, in verify_ds_configuration deployer.ds_bind() File "/usr/lib/python3.12/site-packages/pki/server/deployment/__init__.py", line 2442, in ds_bind self.ds_connection.simple_bind_s( File "/usr/lib64/python3.12/site-packages/ldap/ldapobject.py", line 248, in simple_bind_s msgid = self.simple_bind(who,cred,serverctrls,clientctrls) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.12/site-packages/ldap/ldapobject.py", line 242, in simple_bind return self._ldap_call(self._l.simple_bind,who,cred,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.12/site-packages/ldap/ldapobject.py", line 128, in _ldap_call result = func(*args,**kwargs) ^^^^^^^^^^^^^^^^^^^^ ldap.SERVER_DOWN: {'result': -1, 'desc': "Can't contact LDAP server", 'errno': 107, 'ctrls': [], 'info': 'Transport endpoint is not connected'} 2024-06-29T10:58:32Z CRITICAL Failed to configure CA instance 2024-06-29T10:58:32Z CRITICAL See the installation logs and the following files/directories for more information: 2024-06-29T10:58:32Z CRITICAL /var/log/pki/pki-tomcat 2024-06-29T10:58:32Z DEBUG Traceback (most recent call last): File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 686, in start_creation run_step(full_msg, method) File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 672, in run_step method() File "/usr/lib/python3.12/site-packages/ipaserver/install/cainstance.py", line 678, in __spawn_instance DogtagInstance.spawn_instance( File "/usr/lib/python3.12/site-packages/ipaserver/install/dogtaginstance.py", line 227, in spawn_instance self.handle_setup_error(e) File "/usr/lib/python3.12/site-packages/ipaserver/install/dogtaginstance.py", line 609, in handle_setup_error raise RuntimeError( RuntimeError: CA configuration failed. 2024-06-29T10:58:32Z DEBUG [error] RuntimeError: CA configuration failed. 2024-06-29T10:58:32Z DEBUG Removing /root/.dogtag/pki-tomcat/ca 2024-06-29T10:58:32Z DEBUG File "/usr/lib/python3.12/site-packages/ipapython/admintool.py", line 180, in execute return_value = self.run() ^^^^^^^^^^ File "/usr/lib/python3.12/site-packages/ipapython/install/cli.py", line 344, in run return cfgr.run() ^^^^^^^^^^ File "/usr/lib/python3.12/site-packages/ipapython/install/core.py", line 360, in run return self.execute() ^^^^^^^^^^^^^^ File "/usr/lib/python3.12/site-packages/ipapython/install/core.py", line 386, in execute for rval in self._executor(): File "/usr/lib/python3.12/site-packages/ipapython/install/core.py", line 435, in __runner exc_handler(exc_info) File "/usr/lib/python3.12/site-packages/ipapython/install/core.py", line 468, in _handle_execute_exception self._handle_exception(exc_info) File "/usr/lib/python3.12/site-packages/ipapython/install/core.py", line 458, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python3.12/site-packages/six.py", line 719, in reraise raise value File "/usr/lib/python3.12/site-packages/ipapython/install/core.py", line 425, in __runner step() File "/usr/lib/python3.12/site-packages/ipapython/install/core.py", line 419, in step_next return next(self.__gen) ^^^^^^^^^^^^^^^^ File "/usr/lib/python3.12/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python3.12/site-packages/six.py", line 719, in reraise raise value File "/usr/lib/python3.12/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) ^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.12/site-packages/ipapython/install/core.py", line 663, in _configure next(executor) File "/usr/lib/python3.12/site-packages/ipapython/install/core.py", line 435, in __runner exc_handler(exc_info) File "/usr/lib/python3.12/site-packages/ipapython/install/core.py", line 468, in _handle_execute_exception self._handle_exception(exc_info) File "/usr/lib/python3.12/site-packages/ipapython/install/core.py", line 526, in _handle_exception self.__parent._handle_exception(exc_info) File "/usr/lib/python3.12/site-packages/ipapython/install/core.py", line 458, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python3.12/site-packages/six.py", line 719, in reraise raise value File "/usr/lib/python3.12/site-packages/ipapython/install/core.py", line 523, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python3.12/site-packages/ipapython/install/core.py", line 458, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python3.12/site-packages/six.py", line 719, in reraise raise value File "/usr/lib/python3.12/site-packages/ipapython/install/core.py", line 425, in __runner step() File "/usr/lib/python3.12/site-packages/ipapython/install/core.py", line 419, in step_next return next(self.__gen) ^^^^^^^^^^^^^^^^ File "/usr/lib/python3.12/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python3.12/site-packages/six.py", line 719, in reraise raise value File "/usr/lib/python3.12/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) ^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.12/site-packages/ipapython/install/common.py", line 65, in _install for unused in self._installer(self.parent): File "/usr/lib/python3.12/site-packages/ipaserver/install/server/__init__.py", line 608, in main master_install(self) File "/usr/lib/python3.12/site-packages/ipaserver/install/server/install.py", line 278, in decorated func(installer) File "/usr/lib/python3.12/site-packages/ipaserver/install/server/install.py", line 960, in install ca.install_step_0(False, None, options, custodia=custodia) File "/usr/lib/python3.12/site-packages/ipaserver/install/ca.py", line 607, in install_step_0 ca.configure_instance( File "/usr/lib/python3.12/site-packages/ipaserver/install/cainstance.py", line 515, in configure_instance self.start_creation(runtime=runtime) File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 686, in start_creation run_step(full_msg, method) File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py", line 672, in run_step method() File "/usr/lib/python3.12/site-packages/ipaserver/install/cainstance.py", line 678, in __spawn_instance DogtagInstance.spawn_instance( File "/usr/lib/python3.12/site-packages/ipaserver/install/dogtaginstance.py", line 227, in spawn_instance self.handle_setup_error(e) File "/usr/lib/python3.12/site-packages/ipaserver/install/dogtaginstance.py", line 609, in handle_setup_error raise RuntimeError( 2024-06-29T10:58:32Z DEBUG The ipa-server-install command failed, exception: RuntimeError: CA configuration failed. 2024-06-29T10:58:32Z ERROR CA configuration failed. 2024-06-29T10:58:32Z ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information

4 3

Really old (expired) certificates showing up in ipa service-find and in the web ui
by Thomas Boroske 04 Jul '24

04 Jul '24

Dear Mailing List, we are running a freeipa installation using two ipa master servers. Neither the dns feature nor the CA feature are being used. VERSION: 4.6.8, API_VERSION: 2.237 Both ipa servers have ssl/tls certs associated with them that are signed by an external CA. Since these certs expire after 12 month, I had to install new certificates multiple times, and I have been doing that using ipa-server-certinstall -w -d ipa1.p12 This usually works. as in, the new cert shows up in the IPA web ui and the ipa tools (at least some of which work via the https interface) also continue to work. However, I just noticed that the certificates being displayed for the ipa servers both in ipa service-find and in the IPA web UI are old certs that are long expired (in 2021). So my question is a) Why is this the case, isn't ipa-serrver-certinstall supposed to take care of it? b) Why is it still working like that? c) Why are the certs that are actually used for the web interface not visible anywhere, or where are they? Do I maybe need to use the option -k (for kdc) too when doing ipa-server-certinstall? If so, can I fix it now by just re-running with that option? Are there risks in doing so? My understanding if FreeIPA is spotty I have to say as there are multiple complex technologies put together (kerberos, ldap, ...). Many thanks for any help, Thomas

2 1

freeIPA HSM Test Day in Fedora
by Rob Crittenden 03 Jul '24

03 Jul '24

We have scheduled test days for HSM in IPA for next week, https://fedoraproject.org/wiki/Test_Day:Test_Day:2024-07-09_IPA_HSM If you have some time to run through a couple of the scenarios it would be very helpful. If you have access to a hardware HSM even more so. thanks rob

1 0

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users July 2024