[Freeipa-users] Re: FreeIPA would freeze and require a service restart
Many thanks, I'll look into it. _M On Mon, Feb 5, 2024 at 8:00 AM Rob Crittenden wrote: > Marcelo Carvalho via FreeIPA-users wrote: > > FreeIPA would periodically freeze and would require a service restart - > sudo ipactl restart. > > > > This has happened on freeipa-01 and freeipa-02. When it freezes, CLI > commands would timeout and we would not be able to join systems to the > FreeIPA domain. > > > > NOTE: I have only caught FreeIPA frozen up while joining systems to > the domain. > > > > Anyone with similar experience? Any root cause related to the above? > > > > Please advise. > > Define "freeze". I'll assume hung. > > You'll want to try to identify the process that is hung and get a pstack > from it, preferably with the debuginfo packages installed. That should > help identify what is going on. > > rob > > -- This email and any attachments may contain Astranis confidential and/or proprietary information governed by a non-disclosure agreement, and are intended solely for the individual or entity specified by the message. -- ___ 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 would freeze and require a service restart
Marcelo Carvalho via FreeIPA-users wrote: > FreeIPA would periodically freeze and would require a service restart - sudo > ipactl restart. > > This has happened on freeipa-01 and freeipa-02. When it freezes, CLI commands > would timeout and we would not be able to join systems to the FreeIPA domain. > > NOTE: I have only caught FreeIPA frozen up while joining systems to the > domain. > > Anyone with similar experience? Any root cause related to the above? > > Please advise. Define "freeze". I'll assume hung. You'll want to try to identify the process that is hung and get a pstack from it, preferably with the debuginfo packages installed. That should help identify what is going on. rob -- ___ 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 would freeze and require a service restart
Running on RHEL-9, up to version ipa --version VERSION: 4.10.2, API_VERSION: 2.252 -- ___ 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] FreeIPA would freeze and require a service restart
FreeIPA would periodically freeze and would require a service restart - sudo ipactl restart. This has happened on freeipa-01 and freeipa-02. When it freezes, CLI commands would timeout and we would not be able to join systems to the FreeIPA domain. NOTE: I have only caught FreeIPA frozen up while joining systems to the domain. Anyone with similar experience? Any root cause related to the above? Please advise. Many thanks, Marcelo Carvalho IT Senior System Administrator Astranis Space Technologies Corp. mcarva...@astranis.com https://www.astranis.com/ -- ___ 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] FreeIPA replicas introducing third replica - only one CA
I'm trying to setup a third replica server using the ansible_freeipa.ipareplica role. The role fails on the following step: "[freeipa.ansible_freeipa.ipaclient : Install - Join IPA]": "servers": [ "192.168.1.100", (replica1.example.com "192.168.1.101" (replica2.example.com ] "msg": "Cannot obtain CA certificate\nHTTP certificate download requires --force" Following playbook: roles: - role: freeipa.ansible_freeipa.ipareplica vars: ipareplica_servers: ["replica1.example.com", "replica1.example.com"] replica1 (master with CA) and replica2 already exists. I introduced replica2 to the ipareplica_servers variable, as seen above. If I remove replica2, I'm able to install and setup replica3, but from my understanding I'll be stuck with following topology: replica2 <---> replica1 <---> replica3 When I in reality want: replica2 <---> replica1 <---> replica3 ^--^ I've also experienced a lot of errors with Install - Setup DS, after an uninstall: /usr/sbin/ipa-getkeytab Failed to parse result: Insufficient access rights\\n\\nFailed to get keytab!. Doesn't seem like the role cleans up properly. I struggle to understand this error, since the topology shows only Domain in the UI. -- ___ 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: Cannot create users on platform migration: sambaSID failure
Thanks for the suggestions so far! I'm documenting this on this thread because I found out why the previous system had the custom sambaSamAccount attributes: They seem to be necessary to authenticate SMB shares when FreeIPA is the LDAP backend to a Synology NAS. If I try to set LDAP authentication now, I get this error on Synology DSM: > Issue Details: The LDAP server does not support Samba schema. > ... > Recommended action: Enable CIFS plain text password authentication. [and if you do], this DSM cannot be the remote mount target of CIFS. Some past threads on freeipa-users (mostly for TrueNAS) suggest that the Samba schema attributes are deprecated in favour of something using Kerberos, but I do not get that option in Synology at all. I believe the previous sysadmins of our shop must have followed this guide by Markus Opolka, or a similar HOWTO: https://blog.cubieserver.de/2018/synology-nas-samba-nfs-and-kerberos-with-freeipa-ldap/ That would explain why I couldn't create users with the Web interface in my new FreeIPA (4.11) instance; this guide necessitates manual setting of the Samba attributes via command-line `ipa user-add` flags. However, it is then a mystery to me why user account creation worked via Web interface in the old (4.5) instance. I'm not sure how to proceed here since CIFS mounting is one of our users' primary uses of LDAP in the first place. Maybe I'll recreate the Samba attributes after all, try to restore the previous values from backups, and document properly how to create users with the command-line options. []s Am Mo., 29. Jan. 2024 um 14:52 Uhr schrieb Alexander Bokovoy < aboko...@redhat.com>: > On Пан, 29 сту 2024, Melissa Ferreira da Silva Boiko via FreeIPA-users > wrote: > >Seems like it has "ipaUserObjectClasses: sambasamaccount" which I see > >mentioned in very old threads about Samba support only. Here's the > >full config: > > Thanks. You can remove sambaSamAccount by running > > $ ipa config-mod --delattr=ipaUserObjectClasses=sambaSamAccount > > Same applies to shadowAccount which we don't use by default either. > > > > >``` > > dn: cn=ipaConfig,cn=etc,dc=example,dc=local > > ipamaxusernamelength: 32 > > ipahomesrootdir: /home > > ipadefaultloginshell: /bin/bash > > ipadefaultprimarygroup: ipausers > > ipadefaultemaildomain: example.com > > ipasearchtimelimit: 2 > > ipasearchrecordslimit: 100 > > ipausersearchfields: uid,givenname,sn,telephonenumber,ou,title > > ipagroupsearchfields: cn,description > > ipamigrationenabled: FALSE > > ipacertificatesubjectbase: O=EXAMPLE.LOCAL > > ipapwdexpadvnotify: 4 > > ipaconfigstring: AllowNThash > > ipaconfigstring: KDC:Disable Last Success > > ipaselinuxusermaporder: > guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 > > ipaselinuxusermapdefault: unconfined_u:s0-s0:c0.c1023 > > ipakrbauthzdata: MS-PAC > > ipakrbauthzdata: nfs:NONE > > ipauserauthtype: disabled > > ipauserauthtype: password > > cn: ipaConfig > > ipaGroupObjectClasses: top > > ipaGroupObjectClasses: groupofnames > > ipaGroupObjectClasses: nestedgroup > > ipaGroupObjectClasses: ipausergroup > > ipaGroupObjectClasses: ipaobject > > ipaMaxHostnameLength: 64 > > ipaUserObjectClasses: top > > ipaUserObjectClasses: person > > ipaUserObjectClasses: organizationalperson > > ipaUserObjectClasses: inetorgperson > > ipaUserObjectClasses: inetuser > > ipaUserObjectClasses: posixaccount > > ipaUserObjectClasses: krbprincipalaux > > ipaUserObjectClasses: krbticketpolicyaux > > ipaUserObjectClasses: ipaobject > > ipaUserObjectClasses: ipasshuser > > ipaUserObjectClasses: sambasamaccount > > ipaUserObjectClasses: shadowAccount > > objectClass: nsContainer > > objectClass: top > > objectClass: ipaGuiConfig > > objectClass: ipaConfigObject > > objectClass: ipaUserAuthTypeClass > > objectClass: ipaNameResolutionData > >``` > > > >Thanks! > >-- > >___ > >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 > > > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > > -- ___ 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:
[Freeipa-users] Re: CentOS 7 FreeIPA upgrade, 4.5 to 4.6.8: certmonger hanger
Oh I'm not touching the original instance, it's still up and I'll leave it there for the foreseeable future. Attempts to upgrade CentOS in-place all ran into tricky problems. (The way I tested this was: I prepared snapshots *and* backups of the VM, then tried to upgrade, and when it broke I rolled it all back.) What I did was to create replicas; as you've seen in my story, the winning combination was a temporary CentOS 8 Stream / FreeIPA 4.9 replica as a stepping-stone from 4.5, and from there a definitive replica with Fedora 39 / FreeIPA 4.11. This was mostly done with commands like ipa-replica-install --server very-old-instance.example.com -n example.com -r EXAMPLE.COM --setup-ca --no-ntp -w "$adminpass" (--no-ntp because our instances are all LXC containers and the clock is set by the host machine.) Our installation uses the CA feature but not the DNS server. Once I got a FreeIPA 4.11 replica working with a functional CA, I promoted it to CA "renewal master" as instructed in https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master . That also seems to have worked without a hitch. I now changed our FreeIPA client configs, Ansible, and various LDAP clients to point to the new replica. So far it appears to work. If a couple months go uneventfully, I'll shut down the old instance and probably leave it like that for a few months more, until finally I'm convinced everything is working properly, and then unenroll the old instance from the replica list (but still leave the VM there, shut down but not deleted. just in case.) Good luck with your systems! []s Am Mo., 5. Feb. 2024 um 15:15 Uhr schrieb Kevin Vasko : > Melissa, > > I’ve been following your thread here as I also have a 4.5.x system that > _really_ needs to be updated, but I’m nervous to touch it since it “works”. > > How you testing this without breaking the instance? Im nervous I have > issues like you are experiencing and it breaks everything. I would like to > test and validate that the upgrade works before going all in. Care to share > your process? > > -Kevin > > On Feb 5, 2024, at 7:21 AM, Melissa Ferreira da Silva Boiko via > FreeIPA-users wrote: > > > Thanks for the suggestion! > > I spun a new CentOS 7 image with 7.9.2009 / FreeIPA 4.6.8 (which involved > setting up the incus server to cgroups v1). Then I tried creating a > replica from the 4.5. It again broke on pki-tomcatd, but with a somewhat > baffling error that I didn't know what to do about: > > [3/30]: creating ACIs for admin > [4/30]: creating installation admin user > [5/30]: configuring certificate server instance > [error] IOError: [Errno 13] Permission denied: '/tmp/tmpRJcwYV' > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > This appears to be related to > https://bugzilla.redhat.com/show_bug.cgi?id=1677027 > Which apparently was fixed on FreeIPA 4.7. > > I couldn't find a release with 4.7 so I tried again with a VM with CentOS > 8-Stream, which is supposed to have 4.9. Only yum/dnf couldn't find the > ipa-server package at all; they'd list ipa-client, but not server. I'm not > familiar with RPM-based systems so it took a lot of digging (including > trying my hand at Rocky Linux and localinstall from manual RPM downloads, > which led to problems with dependencies) until I found out I had to add > module_hotfixes=1 in the appstream.repo file. > > With FreeIPA 4.9 once again the CA setup failed, with a new error: > [28/30]: importing IPA certificate profiles > Lookup failed: Preferred host vm-ipa-half-3.intra.viaboxxsystems.de does > not provide CA. > Lookup failed: Preferred host vm-ipa-half-3.intra.viaboxxsystems.de does > not provide CA. > [error] RemoteRetrieveError: Failed to authenticate to CA REST API > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > There were some hard-to-read HTTP errors on the install log so I was > already getting ready to give up and try to create a replica from Docker or > something. But just as a hail-mary I run the uninstall scripts, rebooted, > and tried again, and to my surprise this time pki-tomcatd install worked! > I got a warning then on the KDC step: > > Configuring Kerberos KDC (krb5kdc) > [1/1]: installing X509 Certificate for PKINIT > PKINIT certificate request failed: Certificate issuance failed > (CA_UNREACHABLE: Server at https://vm-ipa-half-3.intra.vi > aboxxsystems.de/ipa/json failed request, will retry: 4035 (Request failed > with status 500: Non-2xx response from CA REST > API: 500. ).) > Failed to configure PKINIT > Full PKINIT configuration did not succeed > The setup will only install bits essential to the server functionality > You can enable PKINIT after the setup completed using 'ipa-pkinit-manage' > > But ipa-replica-install finished with status: successful for the first > time, and "ipa-pkinit-manage enable" worked. I now have a FreeIPA
[Freeipa-users] Re: CentOS 7 FreeIPA upgrade, 4.5 to 4.6.8: certmonger hanger
Melissa,I’ve been following your thread here as I also have a 4.5.x system that _really_ needs to be updated, but I’m nervous to touch it since it “works”.How you testing this without breaking the instance? Im nervous I have issues like you are experiencing and it breaks everything. I would like to test and validate that the upgrade works before going all in. Care to share your process?-KevinOn Feb 5, 2024, at 7:21 AM, Melissa Ferreira da Silva Boiko via FreeIPA-users wrote:Thanks for the suggestion!I spun a new CentOS 7 image with 7.9.2009 / FreeIPA 4.6.8 (which involved setting up the incus server to cgroups v1). Then I tried creating a replica from the 4.5. It again broke on pki-tomcatd, but with a somewhat baffling error that I didn't know what to do about: [3/30]: creating ACIs for admin [4/30]: creating installation admin user [5/30]: configuring certificate server instance [error] IOError: [Errno 13] Permission denied: '/tmp/tmpRJcwYV' Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.This appears to be related tohttps://bugzilla.redhat.com/show_bug.cgi?id=1677027Which apparently was fixed on FreeIPA 4.7.I couldn't find a release with 4.7 so I tried again with a VM with CentOS 8-Stream, which is supposed to have 4.9. Only yum/dnf couldn't find the ipa-server package at all; they'd list ipa-client, but not server. I'm not familiar with RPM-based systems so it took a lot of digging (including trying my hand at Rocky Linux and localinstall from manual RPM downloads, which led to problems with dependencies) until I found out I had to add module_hotfixes=1 in the appstream.repo file.With FreeIPA 4.9 once again the CA setup failed, with a new error: [28/30]: importing IPA certificate profilesLookup failed: Preferred host vm-ipa-half-3.intra.viaboxxsystems.de does not provide CA.Lookup failed: Preferred host vm-ipa-half-3.intra.viaboxxsystems.de does not provide CA. [error] RemoteRetrieveError: Failed to authenticate to CA REST APIYour system may be partly configured.Run /usr/sbin/ipa-server-install --uninstall to clean up.There were some hard-to-read HTTP errors on the install log so I was already getting ready to give up and try to create a replica from Docker or something. But just as a hail-mary I run the uninstall scripts, rebooted, and tried again, and to my surprise this time pki-tomcatd install worked! I got a warning then on the KDC step:Configuring Kerberos KDC (krb5kdc) [1/1]: installing X509 Certificate for PKINITPKINIT certificate request failed: Certificate issuance failed (CA_UNREACHABLE: Server at https://vm-ipa-half-3.intra.viaboxxsystems.de/ipa/json failed request, will retry: 4035 (Request failed with status 500: Non-2xx response from CA REST API: 500. ).)Failed to configure PKINITFull PKINIT configuration did not succeedThe setup will only install bits essential to the server functionalityYou can enable PKINIT after the setup completed using 'ipa-pkinit-manage'But ipa-replica-install finished with status: successful for the first time, and "ipa-pkinit-manage enable" worked. I now have a FreeIPA 4.9.13 replica with CA; hopefully 4.11 will replicate from that without issues and then I can promote it to primary CA.---In summary, these are the issues I found so far trying to upgrade from FreeIPA 4.5.0:Upgrade FreeIPA 4.5 / CentOS7 to the last CentOS 7 / FreeIPA 4.6: breaks due to certmonger timeout.Replicate to current FreeIPA 4.11 / Fedora 39: breaks due to hash incompatibility.Replicate to FreeIPA 4.6 / fresh CentOS 7: breaks due to systemd /tmp permissions error.Replicate to FreeIPA 4.7: couldn't find lxc containers with this version.Replicate to Freeipa 4.9 / CentOS 8-Stream: had to downgrade incus host to cgroups v1; first couple attempts failed, but eventually it worked.[]sAm Do., 1. Feb. 2024 um 17:07 Uhr schrieb Rob Crittenden:Melissa Ferreira da Silva Boiko via FreeIPA-users wrote: > Hello all. > > I'm trying to replace an ancient FreeIPA 4.5.0 master (and primary CA > master) on CentOS 7.4. I am having problems trying to make replicas > with FreeIPA 4.11, and past threads suggest the errors are due to > incompatibility of password hash algorithms, which are supposed to be > fixed on the older releases rather than the newer. > > Therefore I'm trying to upgrade the old server to the current version in > the CentOS 7 repos, 4.6.8, to try to create fresh replicas from there. > But I'm having issues with the certmonger systemd service hanging, and > breaking ipa-server-upgrade--whether I update the whole CentOS to > 7.9.2009, or just ipa-server and its dependencies, the result is the same. > > This is where ipa-server-upgrade breaks: > > [Verifying that root certificate is published] > [Migrate CRL publish directory] > CRL tree already moved > [Verifying that CA proxy configuration is correct] > IPA server upgrade failed: Inspect
[Freeipa-users] Re: Installing CA certificate isuue
mskaraca--- via FreeIPA-users wrote: > Hi > I have the exact same case. > can you share how can I loose the policy or get a certificate with a > stronger signature algorithm # update-crypto-policies --set DEFAULT:SHA1 It is recommended to reboot afterward. Or you have to request stronger hashing from whoever issued the certificate. rob -- ___ 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: Issues with sudo permissions
Sent with Proton Mail secure email. On Friday, February 2nd, 2024 at 10:36, slek kus via FreeIPA-users wrote: > Hi Jochen, nsswitch.conf checks local files and sss. Below is the contents of > etc/pam.d/sudo: > > > #%PAM-1.0 > > # Set up user limits from /etc/security/limits.conf. > session required pam_limits.so > > @include common-auth > @include common-account > @include common-session-noninteractive > > > sudo -l: > > > ansible@debclient1:~$ sudo -l > [sudo] password for ansible: > Sorry, user ansible may not run sudo on debclient1. > > > sssd_[domain].log: > https://privatebin.net/?e841ce0e62791e1b#CU9EhpDrajzQXEihhp2jmjbD92RtG8YZ6Sw4FxaZw1Zx > > sssd_sudo.log: > https://privatebin.net/?40e60858ff984c15#HcQQK2u8wCTYzA6tcttnaiQMsoQ1mVbjCnAovkvDpY6V > > > I have created a new testuser, placed this one in the same hbac rules group. > also no sudo access. > Added this new test user to the local sudo group, and access has been > granted. It shouldn't be nessecary to add IPA users to local groups, or am I > wrong here. > > kind regards. > -- > ___ > 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 Hi Jochen, thanks for taking the time to help. While done the sudo debug and not finding anything, I tried and enabled the default "allow_all" rule and it worked. Then disabled allow_all again and it continued working as there's a dedicated policy. No idea why it functions now. Issue has been solved and today it still is OK. kind regards. -- ___ 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: CentOS 7 FreeIPA upgrade, 4.5 to 4.6.8: certmonger hanger
Thanks for the suggestion! I spun a new CentOS 7 image with 7.9.2009 / FreeIPA 4.6.8 (which involved setting up the incus server to cgroups v1). Then I tried creating a replica from the 4.5. It again broke on pki-tomcatd, but with a somewhat baffling error that I didn't know what to do about: [3/30]: creating ACIs for admin [4/30]: creating installation admin user [5/30]: configuring certificate server instance [error] IOError: [Errno 13] Permission denied: '/tmp/tmpRJcwYV' Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. This appears to be related to https://bugzilla.redhat.com/show_bug.cgi?id=1677027 Which apparently was fixed on FreeIPA 4.7. I couldn't find a release with 4.7 so I tried again with a VM with CentOS 8-Stream, which is supposed to have 4.9. Only yum/dnf couldn't find the ipa-server package at all; they'd list ipa-client, but not server. I'm not familiar with RPM-based systems so it took a lot of digging (including trying my hand at Rocky Linux and localinstall from manual RPM downloads, which led to problems with dependencies) until I found out I had to add module_hotfixes=1 in the appstream.repo file. With FreeIPA 4.9 once again the CA setup failed, with a new error: [28/30]: importing IPA certificate profiles Lookup failed: Preferred host vm-ipa-half-3.intra.viaboxxsystems.de does not provide CA. Lookup failed: Preferred host vm-ipa-half-3.intra.viaboxxsystems.de does not provide CA. [error] RemoteRetrieveError: Failed to authenticate to CA REST API Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. There were some hard-to-read HTTP errors on the install log so I was already getting ready to give up and try to create a replica from Docker or something. But just as a hail-mary I run the uninstall scripts, rebooted, and tried again, and to my surprise this time pki-tomcatd install worked! I got a warning then on the KDC step: Configuring Kerberos KDC (krb5kdc) [1/1]: installing X509 Certificate for PKINIT PKINIT certificate request failed: Certificate issuance failed (CA_UNREACHABLE: Server at https://vm-ipa-half-3.intra.vi aboxxsystems.de/ipa/json failed request, will retry: 4035 (Request failed with status 500: Non-2xx response from CA REST API: 500. ).) Failed to configure PKINIT Full PKINIT configuration did not succeed The setup will only install bits essential to the server functionality You can enable PKINIT after the setup completed using 'ipa-pkinit-manage' But ipa-replica-install finished with status: successful for the first time, and "ipa-pkinit-manage enable" worked. I now have a FreeIPA 4.9.13 replica with CA; hopefully 4.11 will replicate from that without issues and then I can promote it to primary CA. --- In summary, these are the issues I found so far trying to upgrade from FreeIPA 4.5.0: Upgrade FreeIPA 4.5 / CentOS7 to the last CentOS 7 / FreeIPA 4.6: breaks due to certmonger timeout. Replicate to current FreeIPA 4.11 / Fedora 39: breaks due to hash incompatibility. Replicate to FreeIPA 4.6 / fresh CentOS 7: breaks due to systemd /tmp permissions error. Replicate to FreeIPA 4.7: couldn't find lxc containers with this version. Replicate to Freeipa 4.9 / CentOS 8-Stream: had to downgrade incus host to cgroups v1; first couple attempts failed, but eventually it worked. []s Am Do., 1. Feb. 2024 um 17:07 Uhr schrieb Rob Crittenden < rcrit...@redhat.com>: > Melissa Ferreira da Silva Boiko via FreeIPA-users wrote: > > Hello all. > > > > I'm trying to replace an ancient FreeIPA 4.5.0 master (and primary CA > > master) on CentOS 7.4. I am having problems trying to make replicas > > with FreeIPA 4.11, and past threads suggest the errors are due to > > incompatibility of password hash algorithms, which are supposed to be > > fixed on the older releases rather than the newer. > > > > Therefore I'm trying to upgrade the old server to the current version in > > the CentOS 7 repos, 4.6.8, to try to create fresh replicas from there. > > But I'm having issues with the certmonger systemd service hanging, and > > breaking ipa-server-upgrade--whether I update the whole CentOS to > > 7.9.2009, or just ipa-server and its dependencies, the result is the > same. > > > > This is where ipa-server-upgrade breaks: > > > > [Verifying that root certificate is published] > > [Migrate CRL publish directory] > > CRL tree already moved > > [Verifying that CA proxy configuration is correct] > > IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and > > run command ipa-server-upgrade manually. > > Unexpected error - see /var/log/ipaupgrade.log for details: > > CalledProcessError: Command '/bin/systemctl start > > certmonger.service' returned non-zero exit status 1 > > The ipa-server-upgrade command failed. See > > /var/log/ipaupgrade.log for more information > > > > This is because
[Freeipa-users] Re: Upgrade issues from 4.9.11 to 4.10.2 pki-tomcatd fails to start
Hi Rob, Cheers, I looked in those logs as well, but nothing in particular is standing out as an error. After a week trying to find a solution, I think we'll build new servers and migrate the data from working servers as a way to move forward. It seems a safer option upgrading from el9 to el9 anyways. Many Thanks, Tania -- ___ 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