1:16 p.m.
Hi! This is meant for the good future of freeipa, a package I've
appreciated for some years, so across the user cultures and languages
please understand it as supportive and not a complaint!
For all freeipa's 'master-master' replica technology, there remain
'some instances more primary than others' even if the topology diagrams
claim equivalence. Lose 'that one that's even more primary' and (absent
high-learning-curve, on-site capability, and intervention that calls for
high-bar mastery of seldom used subsystems) -- you're on a track to
breakage. Why? Because it's when, not if, that 'primary' system will
need a major OS point release (8 to 9 in the present situation). In
that case, there is as yet no 'just works' upgrade path. With 'not the
super special 'even more master than other' master replicas, it's easy
and 'it just works'... but 'for that one...' freeipa is not ready for
'prime time'.
For example, should site admins 'just know' whether there is a current
kasp.db maintained in more than one place? How many know about
ipa-crlgen-manage, or whether /etc/pki/pki-tomcat/ca/CS.cfg should or
shouldn't have ca.certStatusUpdateInterval=0, or have the command ipa
config-mod --ca-renewal-master-server at the top of their mind? SID
range assignments?
Fundamentally, the fair question is: Which freeipa subsystems that I
don't happen to have studied in dev-level detail have similar 'deep
gotchas that are obvious to the one who specializes in that, but opaque
to everyone else'? Not even the freeipa devs who write the docs collect
all the steps in one place. While there are 'characterizations of
worries' those come without steps, the advice doesn't say what steps
will work, just what won't. ('don't leapp upgrade').
The way forward I think is fairly doable. First is to have each 'dev
that's an expert in their thing' (dns, kra, etc. etc.) make sure all
'master' level replicas have, updated, whatever 'special files' might be
necessary, even if they aren't 'the extra special primary replica', and
may never get used.
Second is an 'orchestration' command, to be run on a master-replica that
is 'the latest os', that will, 'all in one', do all the magic to become
'the extra special primary master' and take those options off 'the old
primary', even if it means installing trust/dns/etc subsystems extant on
the 'old master' but missing from the 'soon to be new primary master'.
An orchestration command that manages everything from moving which fqdn
is authoritative in SOA records, to magic tiny entries in CA.cfg files.
When that command is done, the 'old primary' becomes 'just another
master replica that happens to be using an older os'. Then the 'old
primary' can be discarded and replaced with the latest os and a fresh
install as a master replica. At that point, it's optional whether to
move the 'special primary' status 'back' to the 'now new OS master
system'.
The admin pain involved at present 'for that one system that's the extra
special primary' at os major release upgrade time -- it sets too high an
education bar, obviously higher than even one freeipa-dev has, as the
docs prove-- and as such needs a team approach to address,, before OS 9
to 10 please!
Thanks for all you've done so far!
Harry Coin