I noticed that upgrades were taking a long time during development and discovered that the CA is being restarted every time ipa-server-upgrade is executed. This code contains any any() that will generate a restart if any important change is detected.
any()
The change is detected in ca_upgrade_schema() with the PKI-provided ACME schema files:
/usr/share/pki/server/conf/schema-authority.ldif /usr/share/pki/acme/database/ldap/schema.ldif
In related but slightly different ways, both related to X-ORIGIN
The schema-authority.ldif:
Replace: ( authorityKeyNickname-oid NAME 'authorityKeyNickname' DESC 'Authority key nickname' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE X-ORIGIN ( 'user-defined' 'user defined' ) ) with: ( authorityKeyNickname-oid NAME 'authorityKeyNickname' DESC 'Authority key nickname' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE X-ORIGIN 'user-defined' )
schema.ldif:
Replace: ( acmeCreated-oid NAME 'acmeCreated' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE X-ORIGIN ( 'IPA v4.11.0.dev202207111721+gitf8da5bfbe' 'user defined' ) ) with: ( acmeCreated-oid NAME 'acmeCreated' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE X-ORIGIN 'IPA v4.11.0.dev202207111721+gitf8da5bfbe' )
Note that the version in X-ORIGIN can also cause a restart because the value will be detected as different on version upgrades. Schema is not meant to contain a versioning system.
I'm not yet sure what is injecting the duplicate user-defined value and the embedded parens.
IPA v4.11.0.dev202207111721+gitf8da5bfbe
I'm not sure what is generating the difference in X-ORIGIN. It may be that the schema files should be tweaked. These are provided by the PKI team and it may be that 389-ds is modifying it so it treats it as different each time. I doubt the CA team re-loads these files post-install.
The alternative is to just skip these if they are already loaded via a state variable.
From what I can tell the modlist for these double X-ORIGIN consists only of the MOD_ADD for the correct attributetype but no MOD_DEL for the "bad" one. Is 389-ds treating it as a no-op since the attributetype exists?
I next tried changing the SYNTAX of an attribute and that was changed using ipa-ldap-updater -S <schema_file>
Next I tried using just ldapmodify for the schema and was able to replace attributetypes with only an ADD.
At one point I tried twiddling with just the X-ORIGIN and I could easily flip between the single 'user defined' and double ( 'user-defined' 'user-defined' ) formats. I can't reproduce that now.
So I'm back to being confused.
The schema_pdate method add_x_origin() seems a bit funky and I think is the root cause of the duplication. I just haven't nailed down why yet.
add_x_origin()
I chatted briefly with Mark on IRC and ended up opening https://github.com/389ds/389-ds-base/issues/5366
The plan is to remove ca_upgrade_schema(ca) from the restart list. A schema update should not require a CA restart by itself and these are unlikely to change.
PR https://github.com/freeipa/freeipa/pull/6386
master:
ipa-4-9:
ipa-4-10:
Metadata Update from @frenaud: - Issue tagged with: tracker
The fix (upgrades: Don't restart the CA on ACME and profile schema change) makes sure the CA is not restarted but the original issue is still present on 389ds side. Keeping this ticket open as a tracker.
Log in to comment on this ticket.