On 2/7/19 5:20 PM, Jernej Jakob via FreeIPA-users wrote:

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.

IIRC in RHEL6 PKI version 9 was used and the instance was installed in /var/lib/pki-ca, while in RHEL7 PKI 10 is used and the instance is in /etc/pki/pki-tomcat/ca.

What's important in the steps is to make sure that the RHEL6 node does not act as renewal master any more.

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:

/var/lib/pki/pki-tomcat/alias is a symlink to /etc/pki/pki-tomcat/alias.

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='xxxxxxxxxxxx' 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?

Yes, the renewal master is using renew_ca_cert as postsave command while the clones are using restart_pkicad.

HTH, flo

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" flo@redhat.com Za: "FreeIPA users list" freeipa-users@lists.fedorahosted.org Cc: "Jernej Jakob" jernej.jakob@abak.si 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/htm... [...] _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...

----- Izvirno sporočilo ----- Od: "Rob Crittenden" rcritten@redhat.com Za: "FreeIPA users list" freeipa-users@lists.fedorahosted.org Cc: "Jernej Jakob" jernej.jakob@abak.si 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 <your_new_master>
• follow

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...

• on the new master ipa-replica-install <prepare-file> --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 :)