389-ds-base

Clone
Source Code
GIT

#51009 Ticket 50933 - rfc2307compat.ldif - conflict with 60nis.ldif
Closed 3 years ago by spichugi. Opened 4 years ago by firstyear.
firstyear/389-ds-base 50933-rfc2307compat-fix  into  master

file modified
+1 
@@ -194,6 +194,7 @@ 
 

    1.3.6.1.1.1.1.30 NAME 'nisDomain'
 

    DESC 'NIS domain'
 

    EQUALITY caseIgnoreIA5Match
 

+   SUBSTR caseIgnoreIA5SubstringsMatch

It is valid but why is it useful ?
I would expect that this attribute takes eq/sub/order from the syntax (IA5). Is it a safety setting or did you notice it was not using IA5substring ?

 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 

    )
 

  attributeTypes: (

file modified
+39 -31 
@@ -6,35 +6,41 @@ 
 

  #
 

  ################################################################################
 

  #
 

- attributeTypes: (
 

-   1.3.6.1.1.1.1.28
 

-   NAME 'nisPublickey'
 

-   DESC 'nisPublickey'
 

-   EQUALITY caseIgnoreIA5Match
 

-   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 

-   )
 

+ # == NOW FROM 10rfc2307compat.ldif
 

+ #
 

+ # attributeTypes: (
 

+ #   1.3.6.1.1.1.1.28
 

+ #   NAME 'nisPublickey'
 

+ #   DESC 'nisPublickey'
 

+ #   EQUALITY caseIgnoreIA5Match
 

+ #   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 

+ #   )
 

  #
 

  ################################################################################
 

  #
 

- attributeTypes: (
 

-   1.3.6.1.1.1.1.29
 

-   NAME 'nisSecretkey'
 

-   DESC 'nisSecretkey'
 

-   EQUALITY caseIgnoreIA5Match
 

-   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 

-   )
 

+ # == NOW FROM 10rfc2307compat.ldif
 

+ #
 

+ # attributeTypes: (
 

+ #   1.3.6.1.1.1.1.29
 

+ #   NAME 'nisSecretkey'
 

+ #   DESC 'nisSecretkey'
 

+ #   EQUALITY caseIgnoreIA5Match
 

+ #   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 

+ #   )
 

  #
 

  ################################################################################
 

  #
 

- attributeTypes: (
 

-   1.3.6.1.4.1.1.1.1.12
 

-   NAME 'nisDomain'
 

-   DESC 'NIS domain'
 

-   SUP name
 

-   EQUALITY caseIgnoreIA5Match
 

-   SUBSTR caseIgnoreIA5SubstringsMatch
 

-   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 

-   )
 

+ # == NOW FROM 10rfc2307compat.ldif
 

+ #
 

+ # attributeTypes: (
 

+ #   1.3.6.1.4.1.1.1.1.12
 

+ #   NAME 'nisDomain'
 

+ #   DESC 'NIS domain'
 

+ #   SUP name
 

+ #   EQUALITY caseIgnoreIA5Match
 

+ #   SUBSTR caseIgnoreIA5SubstringsMatch
 

+ #   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 

+ #   )
 

  #
 

  ################################################################################
 

  #
 
@@ -89,14 +95,16 @@ 
 

  #
 

  ################################################################################
 

  #
 

- objectClasses: (
 

-   1.3.1.6.1.1.1.2.15
 

-   NAME 'nisDomainObject'
 

-   DESC 'nisDomainObject'
 

-   SUP top
 

-   AUXILIARY
 

-   MUST ( nisDomain )
 

-   )
 

+ # == NOW FROM 10rfc2307compat.ldif
 

+ #
 

+ # objectClasses: (
 

+ #   1.3.1.6.1.1.1.2.15
 

+ #   NAME 'nisDomainObject'
 

+ #   DESC 'nisDomainObject'
 

+ #   SUP top
 

+ #   AUXILIARY
 

+ #   MUST ( nisDomain )
 

+ #   )
 

  #
 

  ################################################################################
 

  #

Bug Description: In the process of adding rfc2307compat, it was noticed
by users of the optional 60nis.ldif schema that it also included some
incompatible definitions. This removes those in favoure of the rfc2307compat
versions.

Fix Description: Remove the conflicting definitions from 60nis.ldif in
favour of rfc2307compat.ldif. This may require intervention from users
of this optional schema to manage this update.

https://pagure.io/389-ds-base/issue/50933

Author: William Brown william@blackhats.net.au

Review by: ???

It is valid but why is it useful ?
I would expect that this attribute takes eq/sub/order from the syntax (IA5). Is it a safety setting or did you notice it was not using IA5substring ?

@tbordaz If you look at 60nis.ldif it defines the substring rule, so I wanted to keep that as compatability.

This change is valid but before pushing it we need to have a clear understanding how we will fix the problem found with nisDomain from rfc2307/compat. This PR is somehow blocked by rfc2307/compat status.

I don't actually think there has been any evidence yet that FreeIPA conflicts with this schema change - every issue has been development only related to not cleaning the rfc2307.ldif when the rfc2307compat.ldif goes in the same directory. So my vote is we make this change, and then if we have to make compat optional (which would be the worst outcome and defeat the whole point ....) then we make it so that 2307compat is a requirement of 60nis.ldif.

IMO we merge this, and if there is actually a real issue in FreeIPA, then they need to resolve that themself, and if that's not possible, we can revert and make this optional and put ryc2307.ldif as the default. Is that reasonable?

Please see discussion on https://pagure.io/389-ds-base/issue/50933 (also regarding FreeIPA). The issues are really everywhere, not just FreeIPA.

Pull-Request has been closed by firstyear
3 years ago

I have an alternate approach to this.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/4062

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.

Pull-Request has been closed by spichugi
3 years ago
Metadata
None
No Tags
Changes Summary 2
+1 -0
file changed
ldap/schema/10rfc2307compat.ldif
+39 -31
file changed
ldap/schema/60nis.ldif
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.