[Freeipa-users] Re: CA no certs being tracked?
I have not been able to renew the expired certificates yet. I would appreciate help if possible. Followup summary: Q: Seems like part of the problem is that the KDC was not running. Had you done ipactl stop prior to the upgrade? A: I could not get the KDC to stay running. So yes it was off during the upgrade. Q: Did it end up creating the tracking? Are there expired certs? A: I was able to get the upgrade to finish successfully, after restoring the server from VM snapshot, rolling back the system date, and trying the update again. It did create the cert tracking!!! Yes there are expired certs. Q: As an aside, I'd have suggest deferring the package upgrade until after the other things were sorted. It just adds another moving part. Water under the bridge now. A: Yes sorry. On 2/5/2019 11:18 AM, Rob Crittenden wrote: Chris Mohler wrote: Well... That was a mess. The ipa-server-upgrade didn't go so well. It failed and now my ca-replication master is broken. Here are the details. Any hope? Upgrading IPA:. Estimated time: 1 minute 30 seconds [1/11]: stopping directory server [2/11]: saving configuration [3/11]: disabling listeners [4/11]: enabling DS global lock [5/11]: disabling Schema Compat [6/11]: starting directory server [7/11]: updating schema [8/11]: upgrading server [9/11]: stopping directory server [10/11]: restoring configuration [11/11]: starting directory server Done. Update complete Upgrading IPA services Upgrading the configuration of the IPA services [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. CA did not start in 300.0s The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information Seems like part of the problem is that the KDC was not running. Had you done ipactl stop prior to the upgrade? Did it end up creating the tracking? Are there expired certs? As an aside, I'd have suggest deferring the package upgrade until after the other things were sorted. It just adds another moving part. Water under the bridge now. rob Here is a wall of errors from my /var/log/ipaupgrade.log Feb 4 17:47:33 ipa2 ns-slapd: [04/Feb/2019:17:47:33.947136504 -0500] - ERR - set_krb5_creds - Could not get initial credentials for principal [ldap/ipa2.domain@domain.com] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) Feb 4 17:47:33 ipa2 ns-slapd: [04/Feb/2019:17:47:33.953577522 -0500] - ERR - slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) Feb 4 17:47:33 ipa2 ns-slapd: [04/Feb/2019:17:47:33.958062514 -0500] - ERR - set_krb5_creds - Could not get initial credentials for principal [ldap/ipa2.domain@domain.com] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) Feb 4 17:47:33 ipa2 ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available (default cache: /tmp/krb5cc_389)) Feb 4 17:47:33 ipa2 ns-slapd: [04/Feb/2019:17:47:33.965496432 -0500] - ERR - slapi_ldap_bind - Error: could not bind id [cn=Replication Manager masterAgreement1-ipa2.domain.com-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) Feb 4 17:47:40 ipa2 server: WARNING: Exception processing realm com.netscape.cms.tomcat.ProxyRealm@3badc78b background process Feb 4 17:47:40 ipa2 server: javax.ws.rs.ServiceUnavailableException: Subsystem unavailable Feb 4 17:47:40 ipa2 server: at com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:137) Feb 4 17:47:40 ipa2 server: at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1356) Feb 4 17:47:40 ipa2 server: at org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5958) Feb 4 17:47:40 ipa2 server: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1542) Feb 4 17:47:40 ipa2 server: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552) Feb 4 17:47:40 ipa2 server: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552) Feb 4 17:47:40 ipa2 server: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1520) Feb 4 17:47:40 ipa2 server: at java.lang.Thread.run(Thread.java:748) Feb 4 17:47:41 ipa2 dhclient[598]: DHCPREQUEST on eth0 to 132.162.1.131 port 67 (xid=0x27e7db13) Feb 4 17:47:50 ipa2 server: WARNING: Exception processing realm com.netscape.cms.tomcat.ProxyRealm@3badc78b background process Feb 4 17:47:50 ipa2
[Freeipa-users] Re: Upgrading from V3 on Fedora to V4 on CentOS, CA promotion steps?
Jernej Jakob via FreeIPA-users wrote: > - Izvirno sporočilo - > Od: "Rob Crittenden" > Za: "FreeIPA users list" > Cc: "Jernej Jakob" > Poslano: Četrtek, 7. Februar 2019 17:05:47 > Zadeva: Re: [Freeipa-users] Upgrading from V3 on Fedora to V4 on CentOS, CA > promotion steps? > >> There is no 8 yet. > > There is the 8 beta, I was thinking I'd maybe wait for the release, but if > that isn't gonna happen till summer I'm going with 7. > >> You don't need to do all this. What you want to do is something like >> (mostly off the top of my head, definitely read the docs and come up >> with a full plan): >> >> - ensure you have a CA and that its certs are valid (getcert list | grep >> expires) > > Checks out, all are valid. > >> - ipa-replica-prepare >> - follow >> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/linux_domain_identity_authentication_and_policy_guide/#migrating-6-7-prereqs >> - on the new master ipa-replica-install --setup-ca >> (--setup-dns if you have it) >> >> Ensure everything is working: users are visible, clients can enroll, etc. >> >> Create another master from this new one, preferably also with a CA >> (avoid single point-of-failure). >> > > >> Get the current DNA configuration from the F19 master: >> >> $ ldapsearch -D 'cn=directory manager' -W -b "cn=Posix >> IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config" >> >> Decommission the old master. >> >> ipa-replica-manage dnarange-set to configure the uid ranges > > This is something new - not in the above migration guide. Does this need to > be set the same as it was on the old master? I forget when I added DNA range recovery when a master is removed. Doing the above will assure that you retain the original range which is something you wanted. It may not be absolutely necessary, I guess hopefully not. The ipa-replica-manage man page has more details on the dna range commands. > > >> >> THEN set the CA renewal master and CRL generator. >> >> This all does NOT need to be done incredibly quickly. You can create the >> new master and let it just run for a week. Once you are happy, then >> create the second, and so forth >> >> You probably don't want it to drag out too long, but this isn't >> something that needs to be done in a day. >> >> rob > > Thanks for the info, now I know. Knowing me I would've done it all in one go > :) > ___ > 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 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: Upgrading from V3 on Fedora to V4 on CentOS, CA promotion steps?
- Izvirno sporočilo - Od: "Rob Crittenden" Za: "FreeIPA users list" Cc: "Jernej Jakob" Poslano: Četrtek, 7. Februar 2019 17:05:47 Zadeva: Re: [Freeipa-users] Upgrading from V3 on Fedora to V4 on CentOS, CA promotion steps? > There is no 8 yet. There is the 8 beta, I was thinking I'd maybe wait for the release, but if that isn't gonna happen till summer I'm going with 7. > You don't need to do all this. What you want to do is something like > (mostly off the top of my head, definitely read the docs and come up > with a full plan): > > - ensure you have a CA and that its certs are valid (getcert list | grep > expires) Checks out, all are valid. > - ipa-replica-prepare > - follow > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/linux_domain_identity_authentication_and_policy_guide/#migrating-6-7-prereqs > - on the new master ipa-replica-install --setup-ca > (--setup-dns if you have it) > > Ensure everything is working: users are visible, clients can enroll, etc. > > Create another master from this new one, preferably also with a CA > (avoid single point-of-failure). > > Get the current DNA configuration from the F19 master: > > $ ldapsearch -D 'cn=directory manager' -W -b "cn=Posix > IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config" > > Decommission the old master. > > ipa-replica-manage dnarange-set to configure the uid ranges This is something new - not in the above migration guide. Does this need to be set the same as it was on the old master? > > THEN set the CA renewal master and CRL generator. > > This all does NOT need to be done incredibly quickly. You can create the > new master and let it just run for a week. Once you are happy, then > create the second, and so forth > > You probably don't want it to drag out too long, but this isn't > something that needs to be done in a day. > > rob Thanks for the info, now I know. Knowing me I would've done it all in one go :) ___ 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: is anyone running Debian as freeipa-client
Hello, thanks for al the work on this. In the mean time I guess the freeze is already there. So how does it go from here with Buster/freeipa? Grtz j. Op vr 11 jan. 2019 om 11:43 schreef Timo Aaltonen via FreeIPA-users < freeipa-users@lists.fedorahosted.org>: > On 11.1.2019 12.10, Alexander Bokovoy wrote: > > On pe, 11 tammi 2019, Timo Aaltonen via FreeIPA-users wrote: > >> On 10.1.2019 0.14, Eric Engstrom via FreeIPA-users wrote: > one option would be to only build freeipa-client, but that'd leave > anyone using the server out in the cold. > >>> > >>> Since some of us are running the server on different distros, what do > >>> you see as the blockers to getting freeipa-client into debian, > >>> presumably without -server? > >>> > >>> And, in the interest of moving this forward, where should I look to > >>> contribute to getting freeipa-client up on debian (buster, or ). > >> > >> Actually, nss-pem got accepted so the last (functional) blocker is now > >> kinda fixed for the client. > >> > >> The server is still blocked on other things, like Dogtag being broken > >> with current java even while everything builds and should work with it.. > > Timo, > > > > could you describe in more detail what is missing/blocked? > > What's missing is a working CA :) I sent a message to pki-users@ about > this. > > Other than that it needs update to 4.7.2 (now at 4.7.1), testing etc, so > the usual maintenance.. It's been a couple of months since I was able to > get a server up because of other components. And nss-pem is very fresh > on Debian. Once Dogtag is fixed I'm sure there will be new minor issues > since the last time. Still a month to go before Buster is frozen. > > One thing to mention separately is missing support for opendnssec 2.x, > since Fedora is still on 1.4.x... > https://pagure.io/freeipa/issue/6873 > > I'm not sure how much work is left to be done. Opendnssec got a new > maintainer this week, maybe we'll be able to sort this out together.. > > -- > t > ___ > 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 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: Upgrading from V3 on Fedora to V4 on CentOS, CA promotion steps?
Thanks Florence. That was the way I had intended to do it (I've studied the process quite some time ago, enough that the guide I was studying got deleted), only my mind slipped when writing up the mail. Still, I can't run: "getcert list -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca" | grep post-save" or the "getcert stop-tracking ..." steps as there is no /var/lib/pki-ca on my system. Only /var/lib/pki/pki-tomcat. I have CS.cfg in: /etc/pki/pki-tomcat/ca/CS.cfg /usr/share/pki/ca/conf/CS.cfg /var/log/pki/server/upgrade/10.0.5/1/oldfiles/var/lib/pki/pki-tomcat/conf/ca/CS.cfg /etc/pki/pki-tomcat contains both the ca and alias subdirs, if I substitute this and continue, I get to a different obstacle: "getcert list -d /var/lib/pki/pki-tomcat/alias -n "subsystemCert cert-pki-ca"" returns "No request found that matched arguments." Only if I run "getcert list" without arguments I get the long list and details about each certificate: getcert list | grep "subsystemCert cert-pki-ca" key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='' certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" This means this is the master? If there is such a difference in the behavior (output) of getcert on my system, how can I assume the other getcert commands in the process will work? (iow, they likely won't?) - Izvirno sporočilo - Od: "Florence Blanc-Renaud" Za: "FreeIPA users list" Cc: "Jernej Jakob" Poslano: Četrtek, 7. Februar 2019 16:50:03 Zadeva: Re: [Freeipa-users] Upgrading from V3 on Fedora to V4 on CentOS, CA promotion steps? [...] Hi, please find more information here: Migrating IdM from RHEL6 to 7 [1]. The direct upgrade from IdM 3.x to 4.x is not supported, the recommended path is to install a 4.x replica from the 3.x master (with all the needed services, for instance CA, DNS, etc...) then decommission the 6.x master. HTH, flo [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/migrate-6-to-7 [...] ___ 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: Upgrading from V3 on Fedora to V4 on CentOS, CA promotion steps?
Jernej Jakob via FreeIPA-users wrote: > Hi, > > I'm tasked with upgrading our current setup of 3.3.5 on F19 to something more > recent and stable (CentOS 7 or CentOS 8). There is no 8 yet. > > There were instructions at > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html > which is now 404 so I've searched around and found a thread on freeipa-users: > https://www.redhat.com/archives/freeipa-users/2016-April/msg00260.html > This thread also points to the above 404 link and another thread: > https://www.redhat.com/archives/freeipa-users/2016-April/msg00143.html > > When I was reading up on this a year or two ago, there were some guides still > up, and I recall there were some commands to check master/replica CA status > and promote/demote tha CAs in V3. I can't find these any more. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/linux_domain_identity_authentication_and_policy_guide/#updating-migrating > > There is a section "Procedure in FreeIPA < 4.0" here: > https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master > > But I do not have a /var/lib/pki-ca, only /var/lib/pki/pki-tomcat so that > doesn't work. > > This was originally a 2-server setup with master-replica, CA and DNS, but due > to a firewall misconfiguration after a system upgrade the replication was > disconnected for some time. When the split was detected due to us editing the > configuration on the master and it not being propagated, we reestablished the > connection but things never got back to fully working (I recall we could only > edit the configuration on the master, any changes on the replica got lost). > We then unenrolled the replica which left us with only the master that is > running currently. Everything including enrolling new clients works so IMO > this means we're left with the CA master, so we'd want to upgrade this to V4 > and have at least 2 replicas back ASAP. > > If I understand things correctly, first we need to check if all the > certificates are valid and if not renew them, then install a V3 replica, > promote/demote the CAs, check if things are working correctly, unenroll the > old V3 master, upgrade the replica (now master) to V4 and install additional > replicas. > > Since this is our production system with ~20 clients, DNS with custom zones, > HBAC, etc I'd not like to experiment a lot with it (we do have backups just > in case). > > I'd highly appreciate if anyone has any suggestions, instructions or an > archived upgrade guide somewhere... You don't need to do all this. What you want to do is something like (mostly off the top of my head, definitely read the docs and come up with a full plan): - ensure you have a CA and that its certs are valid (getcert list | grep expires) - ipa-replica-prepare - follow https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/linux_domain_identity_authentication_and_policy_guide/#migrating-6-7-prereqs - on the new master ipa-replica-install --setup-ca (--setup-dns if you have it) Ensure everything is working: users are visible, clients can enroll, etc. Create another master from this new one, preferably also with a CA (avoid single point-of-failure). Get the current DNA configuration from the F19 master: $ ldapsearch -D 'cn=directory manager' -W -b "cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config" Decommission the old master. ipa-replica-manage dnarange-set to configure the uid ranges THEN set the CA renewal master and CRL generator. This all does NOT need to be done incredibly quickly. You can create the new master and let it just run for a week. Once you are happy, then create the second, and so forth You probably don't want it to drag out too long, but this isn't something that needs to be done in a day. 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://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: Upgrading from V3 on Fedora to V4 on CentOS, CA promotion steps?
On 2/7/19 3:48 PM, Jernej Jakob via FreeIPA-users wrote: Hi, I'm tasked with upgrading our current setup of 3.3.5 on F19 to something more recent and stable (CentOS 7 or CentOS 8). There were instructions at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html which is now 404 so I've searched around and found a thread on freeipa-users: https://www.redhat.com/archives/freeipa-users/2016-April/msg00260.html This thread also points to the above 404 link and another thread: https://www.redhat.com/archives/freeipa-users/2016-April/msg00143.html When I was reading up on this a year or two ago, there were some guides still up, and I recall there were some commands to check master/replica CA status and promote/demote tha CAs in V3. I can't find these any more. There is a section "Procedure in FreeIPA < 4.0" here: https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master But I do not have a /var/lib/pki-ca, only /var/lib/pki/pki-tomcat so that doesn't work. This was originally a 2-server setup with master-replica, CA and DNS, but due to a firewall misconfiguration after a system upgrade the replication was disconnected for some time. When the split was detected due to us editing the configuration on the master and it not being propagated, we reestablished the connection but things never got back to fully working (I recall we could only edit the configuration on the master, any changes on the replica got lost). We then unenrolled the replica which left us with only the master that is running currently. Everything including enrolling new clients works so IMO this means we're left with the CA master, so we'd want to upgrade this to V4 and have at least 2 replicas back ASAP. If I understand things correctly, first we need to check if all the certificates are valid and if not renew them, then install a V3 replica, promote/demote the CAs, check if things are working correctly, unenroll the old V3 master, upgrade the replica (now master) to V4 and install additional replicas. Since this is our production system with ~20 clients, DNS with custom zones, HBAC, etc I'd not like to experiment a lot with it (we do have backups just in case). I'd highly appreciate if anyone has any suggestions, instructions or an archived upgrade guide somewhere... Hi, please find more information here: Migrating IdM from RHEL6 to 7 [1]. The direct upgrade from IdM 3.x to 4.x is not supported, the recommended path is to install a 4.x replica from the 3.x master (with all the needed services, for instance CA, DNS, etc...) then decommission the 6.x master. HTH, flo [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/migrate-6-to-7 Thanks. Jernej ___ 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 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: Failed to start 389 Directory Server
Hi, The IPA message are from Jan 28th (failing ipa backup ) while the restart failure is from Feb 2nd. Nothing in the ds error logs from Jan28th ? The first message "Detected Disorderly Shutdown" means that DS stopped abruptly (crash, assert,..). So at restart it runs a recovery of the database. Usually it works fine but here the recovery failed "libdb: BDB1546 unable to join the environment". You may check if there is a captured DS core file. Also would you provide ls -lR /var/lib/dirsrv/slapd-/db best regards thierry On 02/06/2019 10:43 AM, Florence Blanc-Renaud via FreeIPA-users wrote: On 2/3/19 8:08 AM, Zarko D via FreeIPA-users wrote: Hi there, this is ipa-server-4.4.0-12.0.1 with 389-ds-base-1.3.5.10-11 and suddenly daily backup has started to fail with messages: 2019-01-28T04:10:04Z INFO Backing up ipaca in REALM-COM to LDIF 2019-01-28T04:10:04Z INFO Waiting for LDIF to finish 2019-01-28T04:10:05Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_backup.py", line 300, in run self.db2ldif(instance, 'ipaca', online=options.online) File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_backup.py", line 425, in db2ldif shutil.move(ldiffile, os.path.join(self.dir, ldifname)) File "/usr/lib64/python2.7/shutil.py", line 301, in move copy2(src, real_dst) File "/usr/lib64/python2.7/shutil.py", line 130, in copy2 copyfile(src, dst) File "/usr/lib64/python2.7/shutil.py", line 82, in copyfile with open(src, 'rb') as fsrc: 2019-01-28T04:10:05Z DEBUG The ipa-backup command failed, exception: IOError: [Errno 2] No such file or directory: u'/var/ lib/dirsrv/slapd-REALM-COM/ldif/REALM-COM-ipaca.ldif' 2019-01-28T04:10:05Z ERROR [Errno 2] No such file or directory: u'/var/lib/dirsrv/slapd-REALM-COM/ldif/REALM-COM-ipaca.ldif' 2019-01-28T04:10:05Z ERROR The ipa-backup command failed. See /var/log/ipabackup.log for more information And service start fails with messages: [02/Feb/2019:22:47:37.889779410 -0800] 389-Directory/1.3.5.10 B2016.309.1527 starting up [02/Feb/2019:22:47:37.906422534 -0800] default_mr_indexer_create: warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match [02/Feb/2019:22:47:37.921288555 -0800] WARNING: userRoot: entry cache size 10485760 B is less than db size 16932864 B; We recommend to increase the entry cache size nsslapd-cachememsize. [02/Feb/2019:22:47:37.921943984 -0800] WARNING: ipaca: entry cache size 10485760 B is less than db size 1757741056 B; We recommend to increase the entry cache size nsslapd-cachememsize. [02/Feb/2019:22:47:37.922701343 -0800] WARNING: changelog: entry cache size 2097152 B is less than db size 82935808 B; We recommend to increase the entry cache size nsslapd-cachememsize. [02/Feb/2019:22:47:37.925215059 -0800] Detected Disorderly Shutdown last time Directory Server was running, recovering database. [02/Feb/2019:22:47:37.926177620 -0800] libdb: BDB1546 unable to join the environment thanks in advance for any help, Zarko Hi, You may get more help from 389-users mailing list, which I CC'ed. flo ___ 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 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 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] Upgrading from V3 on Fedora to V4 on CentOS, CA promotion steps?
Hi, I'm tasked with upgrading our current setup of 3.3.5 on F19 to something more recent and stable (CentOS 7 or CentOS 8). There were instructions at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html which is now 404 so I've searched around and found a thread on freeipa-users: https://www.redhat.com/archives/freeipa-users/2016-April/msg00260.html This thread also points to the above 404 link and another thread: https://www.redhat.com/archives/freeipa-users/2016-April/msg00143.html When I was reading up on this a year or two ago, there were some guides still up, and I recall there were some commands to check master/replica CA status and promote/demote tha CAs in V3. I can't find these any more. There is a section "Procedure in FreeIPA < 4.0" here: https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master But I do not have a /var/lib/pki-ca, only /var/lib/pki/pki-tomcat so that doesn't work. This was originally a 2-server setup with master-replica, CA and DNS, but due to a firewall misconfiguration after a system upgrade the replication was disconnected for some time. When the split was detected due to us editing the configuration on the master and it not being propagated, we reestablished the connection but things never got back to fully working (I recall we could only edit the configuration on the master, any changes on the replica got lost). We then unenrolled the replica which left us with only the master that is running currently. Everything including enrolling new clients works so IMO this means we're left with the CA master, so we'd want to upgrade this to V4 and have at least 2 replicas back ASAP. If I understand things correctly, first we need to check if all the certificates are valid and if not renew them, then install a V3 replica, promote/demote the CAs, check if things are working correctly, unenroll the old V3 master, upgrade the replica (now master) to V4 and install additional replicas. Since this is our production system with ~20 clients, DNS with custom zones, HBAC, etc I'd not like to experiment a lot with it (we do have backups just in case). I'd highly appreciate if anyone has any suggestions, instructions or an archived upgrade guide somewhere... Thanks. Jernej ___ 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 CS replication issues
Hi German, On Wed, 6 Feb 2019, German Parente via FreeIPA-users wrote: this is a bug in the product that might have been fixed already: Connectivity: left-right we cannot have these sort of connectivity. In ipa02 there's no replication agreement to ipa01 (for ipaca database). But as in ipa01 we see that the topology is showing "both" in the connectivity, I suggest to do export-import "off line" of the database. Then the topology subtree will be set in ipa02, exactly as in ipa01, and the topology plugin will create automatically the replication agreement that is missing now. export from ipa01 the backend ipaca and re-import it in ipa02. Then, start the server and check if now it's showing "both" in connectivity at ipa02 side. thank you for your hints. Unfortunately, I never did something like this before (and I can't access the article you cited below). According to the Directory Manager docs, it's probably something like --- db2ldif.pl -Z EXAMPLE-COM -D "cn=Directory Manager" -w - -n ipaca -a /tmp/foo.dif --- to export on running ipa1 and --- ldif2db -Z EXAMPLE-COM -n ipaca -i /tmp/foo.dif --- to import on ipa2 with IPA not running, right? Something else to be taken into account to not break something (these are production servers - my group is small but vigorous ;-) On Wed, Feb 6, 2019 at 4:57 PM dbischof--- via FreeIPA-users wrote: On Wed, 6 Feb 2019, German Parente via FreeIPA-users wrote: have you tried to use "ipa-csreplica-manage re-initialize --from " in replica1 ? Thanks for your answer. I already tried (on ipa2) --- $ ipa-csreplica-manage re-initialize --from ipa1.example.com --- which failed. Interestingly enough, the error message is --- unexpected error: Replication agreement for ipa1.example.com not found --- And indeed: --- $ ipa topologysegment-find ca -- 2 segments matched -- Segment name: ipa2.example.com-to-ipa1.example.com Left node: ipa2.example.com Right node: ipa1.example.com Connectivity: both Segment name: ipa1.example.com-to-ipa2.example.com Left node: ipa1.example.com Right node: ipa2.example.com Connectivity: left-right Number of entries returned 2 --- The Web UI topology graph doesn't reflect this, btw. Isn't the 2nd segment obsolete and probably causing my CS replication issues? Just remove it? You could also re-init off line by using this article: https://access.redhat.com/solutions/140483 only for ipaca backend. On Wed, Feb 6, 2019 at 11:31 AM dbischof--- via FreeIPA-users wrote: On Wed, 6 Feb 2019, dbischof--- via FreeIPA-users wrote: On Wed, 6 Feb 2019, Florence Blanc-Renaud via FreeIPA-users wrote: On 2/5/19 4:17 PM, dbischof--- via FreeIPA-users wrote: my IPA system consists of 2 masters (ipa1 and ipa2, both on FreeIPA 4.6.4) with their own self-signed CAs, one of them being the certificate renewal master (ipa1). The system has been running for years and has been migrated from an IPA 3 system. Both IPA servers are on domain level 1. Problem: CS replication failed, probably months ago. --- ipa1 --- $ ipa-csreplica-manage -v list ipa1.example.com ipa2.example.com last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00 -- $ ipa-csreplica-manage -v list ipa2.example.com [no output] Same on ipa2. Probably related: --- ERR - slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) --- Every 5 mins in /var/log/dirsrv/slapd-EXAMPLE-COM/errors. However, these error messages could refer to ipa3.example.com, a master i deleted long (> 2 years) ago: --- $ ipa-replica-manage list-ruv Replica Update Vectors: ipa2.example.com:389: 10 ipa1.example.com:389: 9 Certificate Server Replica Update Vectors: ipa2.example.com:389: 11 ipa1.example.com:389: 91 ipa2.example.com:7389: 96 ipa3.example.com:7389: 97 --- How do i track this down and resolve the problem? please find more information re. 389-ds troubleshooting: https://www.freeipa.org/page/Troubleshooting/Directory_Server I checked for the common problems described in that page already, but to no avail. I did, however, successfully manage to remove replication references to ipa3 using "ipa-replica-manage clean-dangling-ruv": --- $ ipa-replica-manage list-ruv Replica Update Vectors: ipa1.example.com:389: 9 ipa2.example.com:389: 10 Certificate Server Replica Update Vectors: ipa1.example.com:389: 91 ipa2.example.com:389: 11 --- The error message --- [06/Feb/2019:10:38:52.095489260 +0100] - ERR - slapi_
[Freeipa-users] Re: FreeIPA CS replication issues
Hi Rob, On Wed, 6 Feb 2019, Rob Crittenden via FreeIPA-users wrote: dbischof--- via FreeIPA-users wrote: On Wed, 6 Feb 2019, dbischof--- via FreeIPA-users wrote: On Wed, 6 Feb 2019, Florence Blanc-Renaud via FreeIPA-users wrote: On 2/5/19 4:17 PM, dbischof--- via FreeIPA-users wrote: my IPA system consists of 2 masters (ipa1 and ipa2, both on FreeIPA 4.6.4) with their own self-signed CAs, one of them being the certificate renewal master (ipa1). The system has been running for years and has been migrated from an IPA 3 system. Both IPA servers are on domain level 1. Problem: CS replication failed, probably months ago. --- ipa1 --- $ ipa-csreplica-manage -v list ipa1.example.com ipa2.example.com last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00 -- $ ipa-csreplica-manage -v list ipa2.example.com [no output] Same on ipa2. Probably related: --- ERR - slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) --- Every 5 mins in /var/log/dirsrv/slapd-EXAMPLE-COM/errors. However, these error messages could refer to ipa3.example.com, a master i deleted long (> 2 years) ago: --- $ ipa-replica-manage list-ruv Replica Update Vectors: ipa2.example.com:389: 10 ipa1.example.com:389: 9 Certificate Server Replica Update Vectors: ipa2.example.com:389: 11 ipa1.example.com:389: 91 ipa2.example.com:7389: 96 ipa3.example.com:7389: 97 --- How do i track this down and resolve the problem? please find more information re. 389-ds troubleshooting: https://www.freeipa.org/page/Troubleshooting/Directory_Server I checked for the common problems described in that page already, but to no avail. I did, however, successfully manage to remove replication references to ipa3 using "ipa-replica-manage clean-dangling-ruv": --- $ ipa-replica-manage list-ruv Replica Update Vectors: ipa1.example.com:389: 9 ipa2.example.com:389: 10 Certificate Server Replica Update Vectors: ipa1.example.com:389: 91 ipa2.example.com:389: 11 --- The error message --- [06/Feb/2019:10:38:52.095489260 +0100] - ERR - slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) --- on ipa1 is still in the logs. Additionally, while cleaning ruvs: --- [06/Feb/2019:10:32:31.029394375 +0100] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=cloneAgreement1-ipa1.example.com-pki-tomcat" (ipa2:7389) - Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) () --- The ldapsearch queries described in the above page can be carried out successfully on both servers: --- [...] # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1 --- Also, no DNS issues, wrong entries /etc/hosts, time differences or log messages related to SASL issues. Maybe a wrong key or certificate somewhere? update: ipa-checkcerts.py shows --- [...] Failures: ipa: INFO: Unable to find request for serial 268304391 Unable to find request for serial 268304391 ipa: INFO: Unable to find request for serial 268304394 Unable to find request for serial 268304394 ipa: INFO: Unable to find request for serial 268304393 Unable to find request for serial 268304393 ipa: INFO: Unable to find request for serial 268304392 Unable to find request for serial 268304392 ipa: INFO: Subject O=EXAMPLE.COM,CN=ipa2.example.com and template subject CN=ipa1.example.com,O=EXAMPLE.COM do not match for serial 57 Subject O=EXAMPLE.COM,CN=ipa2.example.com and template subject CN=ipa1.example.com,O=EXAMPLE.COM do not match for serial 57 --- So there is a certificate issue. Maybe. I haven't gotten confirmation from the dogtag team that these types of "issues" are actually a problem. What does ipa-replica-manage list -v `hostname` and ipa-csreplica-manage list -v `hostname` show? ipa-replica-manage list -v `hostname` is ok on both machines (I fixed a problem with Florence's help a while ago) - shows --- last update status: Error (0) Replica acquired successfully: Incremental update succeeded --- ipa-csreplica-manage list -v `hostname` is not ok, please cf. above. No output for one host, "Can't contact LDAP server (connection error)" for the other (queried on both hosts). If the issues reported by ipa-checkcerts.py may not indicate the root cause for my replication problem, the broken topology appears to be the more likley candidate, I guess (cf. other posts in this thread). Mit freundlichen Gruessen/With best regards, --Daniel. ___ FreeIPA-users mailing
[Freeipa-users] Re: Log into web UI with AD user?
On ke, 06 helmi 2019, Charles Ulrich via FreeIPA-users wrote: Hello, I'm setting up a test instance of FreeIPA with a one-way trust to the organization's AD. So far, that all appears to be working. I can run LDAP queries to look up users, I can log into the test instance via Kerberos, it's all golden. What I would like to next is to add certain external AD users to the "admins" FreeIPA group so that these users can log into the FreeIPA web UI and perform administrative actions the same as the built-in "admin" user can. So far I spent about a day reading docs, googling, and trying things out but haven't yet made this work. Here is what I've done so far: This is not supported in anything but RHEL 8.0 beta when you install yum module enable idm:DL1 yum module install idm:DL1/adtrust and then set things up for the trust to use as documented at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-beta/html/installing_identity_management_and_access_control/enabling-ad-user-to-administer-idm-fin-fin No other distribution has experimental support to manage IPA as Active Directory user. It is experimental because a number of things still don't work. -- / 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://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
