Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Updating attributetypes in schema is unpredictable #5366

Open
rcritten opened this issue Jul 13, 2022 · 0 comments
Open

Updating attributetypes in schema is unpredictable #5366

rcritten opened this issue Jul 13, 2022 · 0 comments
Labels
needs triage The issue will be triaged during scrum

Comments

@rcritten
Copy link
Contributor

Issue Description

Background: IPA loads some PKI schema as part of its upgrade process. This is in the context of a slew of potential changes to CA configuration. If any change is detected as having been made a CA restart is done. This is slow-ish and we try to avoid it where possible.

It turns out that the X-ORIGIN is the root cause for the restarts. This is being detected by our code:

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' )

Note that it detects that the current X-ORIGIN is duplicated and it wants to flip it back to a single value.

The update we generate, and I'm not 100% sure why yet, consists only of a MOD_ADD. The change is "successful" in that an error isn't returned but X-ORIGIN isn't changed so next time we run an upgrade this will happen again.

So I tried this with ldapmodify. I tried changing the SYNTAX for this from 1.3.6...26 to 1.3.6...25. And X-ORIGIN is tweaked as well.

# ldapmodify -x -d 'cn=Directory Manager' -W
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( authorityKeyNickname-oid NAME 'authorityKeyNickname' DESC 'Authority key nickname' SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 SINGLE-VALUE X-ORIGIN 'user-defined' )

# ldapsearch -Q -Y GSSAPI -LLL -b cn=schema -o ldif_wrap=no attributetypes objectclasses |grep authorityKeyNickname
attributetypes: ( authorityKeyNickname-oid NAME 'authorityKeyNickname' DESC 'Authority key nickname' SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 SINGLE-VALUE X-ORIGIN ( 'user-defined' 'user defined' ) )

It changed to 25!? But X-ORIGIN remains the same. I can reverse back to 26 and it updates again. I haven't played with any other schema syntax like match, sort, etc.

Package Version and Platform:

  • Platform: Fedora
  • Package and version: 389-ds-base-2.0.15-1.fc35.x86_64
@rcritten rcritten added the needs triage The issue will be triaged during scrum label Jul 13, 2022
rcritten added a commit to rcritten/freeipa that referenced this issue Aug 1, 2022
@rcritten
upgrades: Don't restart the CA on ACME and profile schema change
bbf9fde 
There are currently three sets of CA schema changes applied
in ipa-server-upgrade:

* addition of ACME schema
* addition of certificate profile schema
* addition of lightweight CA schema

None of these require a restart of the CA to be supported.

There is an issue in schema parsing such that it doesn't handle
X-ORIGIN properly. A difference is detected and a change applied
but no change is recorded in LDAP so every time upgrade is
run it thinks a CA restart is needed. The CA is not quick to
restart so avoiding one is best, particularly when the update is
run as part of an rpm transaction where a user with an itchy finger
may think things have hung and break out of it.

389ds/389-ds-base#5366 was
filed to track this.

Related: https://pagure.io/freeipa/issue/9204

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
@rcritten rcritten mentioned this issue Aug 1, 2022
Closed
abbra pushed a commit to freeipa/freeipa that referenced this issue Aug 16, 2022
@rcritten @flo-renaud
upgrades: Don't restart the CA on ACME and profile schema change
45b351f 
There are currently three sets of CA schema changes applied
in ipa-server-upgrade:

* addition of ACME schema
* addition of certificate profile schema
* addition of lightweight CA schema

None of these require a restart of the CA to be supported.

There is an issue in schema parsing such that it doesn't handle
X-ORIGIN properly. A difference is detected and a change applied
but no change is recorded in LDAP so every time upgrade is
run it thinks a CA restart is needed. The CA is not quick to
restart so avoiding one is best, particularly when the update is
run as part of an rpm transaction where a user with an itchy finger
may think things have hung and break out of it.

389ds/389-ds-base#5366 was
filed to track this.

Related: https://pagure.io/freeipa/issue/9204

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
flo-renaud pushed a commit to flo-renaud/freeipa that referenced this issue Aug 16, 2022
@rcritten @flo-renaud
upgrades: Don't restart the CA on ACME and profile schema change
6a7e511 
There are currently three sets of CA schema changes applied
in ipa-server-upgrade:

* addition of ACME schema
* addition of certificate profile schema
* addition of lightweight CA schema

None of these require a restart of the CA to be supported.

There is an issue in schema parsing such that it doesn't handle
X-ORIGIN properly. A difference is detected and a change applied
but no change is recorded in LDAP so every time upgrade is
run it thinks a CA restart is needed. The CA is not quick to
restart so avoiding one is best, particularly when the update is
run as part of an rpm transaction where a user with an itchy finger
may think things have hung and break out of it.

389ds/389-ds-base#5366 was
filed to track this.

Related: https://pagure.io/freeipa/issue/9204

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
flo-renaud pushed a commit to flo-renaud/freeipa that referenced this issue Aug 16, 2022
@rcritten @flo-renaud
upgrades: Don't restart the CA on ACME and profile schema change
ce1100f 
There are currently three sets of CA schema changes applied
in ipa-server-upgrade:

* addition of ACME schema
* addition of certificate profile schema
* addition of lightweight CA schema

None of these require a restart of the CA to be supported.

There is an issue in schema parsing such that it doesn't handle
X-ORIGIN properly. A difference is detected and a change applied
but no change is recorded in LDAP so every time upgrade is
run it thinks a CA restart is needed. The CA is not quick to
restart so avoiding one is best, particularly when the update is
run as part of an rpm transaction where a user with an itchy finger
may think things have hung and break out of it.

389ds/389-ds-base#5366 was
filed to track this.

Related: https://pagure.io/freeipa/issue/9204

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
abbra pushed a commit to freeipa/freeipa that referenced this issue Aug 16, 2022
@rcritten @flo-renaud
upgrades: Don't restart the CA on ACME and profile schema change
aaf5718 
There are currently three sets of CA schema changes applied
in ipa-server-upgrade:

* addition of ACME schema
* addition of certificate profile schema
* addition of lightweight CA schema

None of these require a restart of the CA to be supported.

There is an issue in schema parsing such that it doesn't handle
X-ORIGIN properly. A difference is detected and a change applied
but no change is recorded in LDAP so every time upgrade is
run it thinks a CA restart is needed. The CA is not quick to
restart so avoiding one is best, particularly when the update is
run as part of an rpm transaction where a user with an itchy finger
may think things have hung and break out of it.

389ds/389-ds-base#5366 was
filed to track this.

Related: https://pagure.io/freeipa/issue/9204

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
abbra pushed a commit to freeipa/freeipa that referenced this issue Aug 16, 2022
@rcritten @flo-renaud
upgrades: Don't restart the CA on ACME and profile schema change
459b81b 
There are currently three sets of CA schema changes applied
in ipa-server-upgrade:

* addition of ACME schema
* addition of certificate profile schema
* addition of lightweight CA schema

None of these require a restart of the CA to be supported.

There is an issue in schema parsing such that it doesn't handle
X-ORIGIN properly. A difference is detected and a change applied
but no change is recorded in LDAP so every time upgrade is
run it thinks a CA restart is needed. The CA is not quick to
restart so avoiding one is best, particularly when the update is
run as part of an rpm transaction where a user with an itchy finger
may think things have hung and break out of it.

389ds/389-ds-base#5366 was
filed to track this.

Related: https://pagure.io/freeipa/issue/9204

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
needs triage The issue will be triaged during scrum
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@rcritten