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.
>>> Is
>>> *this[1]* FreeIPA release recommended for a full OS dnf upgrade from F27
>>> to
>>> F28?
>>
>> 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.
>>
>> rob
>
> Thank you, Alexander and Rob.
>
> I've used the "create replica" method of upgrading in the past, but
have
> 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?
I've
> 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)
>
> to
>
> 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.
rob
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[468]: ERROR: /var/lib/pki/pki-tomcat/alias contains an incomplete
NSS database in SQL format
systemd[1]: pki-tomcatd(a)pki-tomcat.service: Control process exited,
code=exited status=1
systemd[1]: pki-tomcatd(a)pki-tomcat.service: Failed with result 'exit-code'.
systemd[1]: 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
pkiuser.
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
/var/lib/ipa/passwds/ipa-host.example.com-443-RSA
key pair storage: type=FILE,location='/var/lib/ipa/private/
httpd.key',pinfile='/var/lib/ipa/passwds/ipa1.ipa.example.com-443-RSA'
certificate: type=FILE,location='/var/lib/ipa/certs/httpd.crt'
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
--
Anthony -
https://messinet.com
F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6