Anthony Joseph Messina via FreeIPA-users wrote:
On Saturday, August 18, 2018 2:40:30 PM CDT Rob Crittenden wrote:
> Anthony Joseph Messina via FreeIPA-users wrote:
>> On Friday, August 17, 2018 1:34:03 PM CDT Rob Crittenden wrote:
>>> Anthony Joseph Messina via FreeIPA-users wrote:
>>>> I have two full (DNS, CA, KRA) FreeIPA instances still running F27 for
>>>> stability based on the recommendations at the time of the F28 release.
>>>> *this* FreeIPA release recommended for a full OS dnf upgrade from F27
>>> Yes, we pushed that to stable today. I am not aware of any upgrade
>>> issues. Be sure to verify that your certificates are valid before
>>> starting the upgrade. Better to work that out in F27 than in the middle
>>> of a F28 upgrade.
>>> You can optionally install new F28 machines and create replicas on them
>>> to replace the current F27 machines.
>> Thank you, Alexander and Rob.
>> I've used the "create replica" method of upgrading in the past, but
>> always run into trouble with the continuous splitting of id ranges and dna
>> ranges as new users are added.
> When deleting a replica an attempt is made to harvest any DNA range that
> the host had. The range has a "next range" setting that we try to merge
> and stuff values in to. You can use ipa-replica-manage to see the status
> of these and manually tweak ranges if you need.
>> I might give it another shot though--when adding a new replica in the
>> "managed toplogy" level and promoting a client to a master, is there a
>> way to "point" the about to be created replica to a certain master?
>> found that it seems to pick whatever existing master it wants to leading
>> to agreements that don't match between the domain and the ca.
> There is some limited support in 4.7.0 to try to maintain some
> "affinity" when setting up a new master but there are still some gaps.
> The CA host may be one of them but you should be able to manually tweak
> the topology post-install if it is still wonky.
>> I only run two masters, so I need to go from
>> MasterA (F27) <-> MasterB (F27)
>> MasterAA (F28) <-> MasterBB (F28)
>> I'll dig into the upgraded topology docs a bit to see if I can find more
>> clarification on promoting a client to master in a master in a topology-
>> managed environment, while upgrading the release at the same time.
> Cool, sounds good. Don't forget to reset the CRL generating master once
> you are done, and ensure that at least one new master has a DNA range.
Well, I ended up going with the F27 -> F28 dnf distro-sync as I had done in
the past. The sytem upgrade went well, though there was a failure in the
FreeIPA/dogtag upgrade portion:
pki-server: ERROR: /var/lib/pki/pki-tomcat/alias contains an incomplete
NSS database in SQL format
systemd: pki-tomcatd(a)pki-tomcat.service: Control process exited,
systemd: pki-tomcatd(a)pki-tomcat.service: Failed with result 'exit-code'.
systemd: Failed to start PKI Tomcat Server pki-tomcat.
The new cert9.db and key4.db files /var/lib/pki/pki-tomcat/alias were owned by
root instead of pkiuser and the pkcs11.txt file was missing.
Not knowing the required format for pkcs11.txt, I temporarily copied
pkcs11.txt from /etc/ipa/nssdb/ and changed the ownership of the files to
There also was a new certificate created in /var/lib/ipa/certs/httpd.crt with
an encrypted key in /var/lib/ipa/private/httpd.key which required me to
resubmit the request with the pinfile defined which I was lucky to find in
key pair storage: type=FILE,location='/var/lib/ipa/private/
This was all followed by ipa-server-upgrade which went well.
Both masters are now running freeipa-server-4.7.0-1.fc28.x86_64
At some point near the F29 release, I'll use the "create replica" method to
replace these two masters.
Thanks again for your help. -A
Glad you got it working!
I don't recall seeing those issues in our upgrade testing. I'll see