directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DIRAPI-154) Implement "online" OpenLDAP schema parsing in DefaultSchemaLoader
Date Thu, 08 Jan 2015 18:59:35 GMT

     [ https://issues.apache.org/jira/browse/DIRAPI-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Emmanuel Lecharny updated DIRAPI-154:
-------------------------------------
    Description: 
The constructor in DefaultSchemaLoader has the following comment:

{code}
  // TODO Handle schema loading on other LDAP servers
{code}

For OpenLDAP this would require searching subtree under cn=schema,cn=config and handling attributes
like:

{code}
  olcAttributeTypes: {1}( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (family) name(s)
for which the entity is known by' SUP name )

  olcObjectClasses: {4}( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL
MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
{code}

Note that there is also an 'olcObjectIdentifier' attribute type that seems to be used to create
macros for interpolation in OID's used in other attributes:

{code}
  olcObjectIdentifier: OLcfg 1.3.6.1.4.1.4203.1.12.2
  olcObjectIdentifier: OLcfgAt OLcfg:3
  olcObjectIdentifier: OLcfgOvAt OLcfgAt:3
  olcObjectIdentifier: OMsyn 1.3.6.1.4.1.1466.115.121.1
  olcObjectIdentifier: OMsBoolean OMsyn:7

  olcAttributeTypes: ( OLcfgOvAt:10.4 NAME 'olcUniqueStrict' DESC 'Enforce uniqueness of null
values' EQUALITY booleanMatch SYNTAX OMsBoolean SINGLE-VALUE )
{code}

However this additional complexity seems to only be used for the internal/vendor-specific
schema itself (not 'core', 'nis', etc.).

Attached is LDIF output of from searching {{cn=schema,cn=config}}.

Mailing List reference: https://mail-archives.apache.org/mod_mbox/directory-api/201308.mbox/%3CCABzFU-eOfmwiFpR1w0Fd-JhNFBVLO0NkHKa5w61ReFBEq%3DWkaw%40mail.gmail.com%3E

  was:
The constructor in DefaultSchemaLoader has the following comment:

{code}
  // TODO Handle schema loading on other LDAP servers
{code}

For OpenLDAP this would require searching subtree under cn=schema,cn=config and handling attributes
like:

{code}
  olcAttributeTypes: {1}( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (family) name(s)
for which the entity is known by' SUP name )

  olcObjectClasses: {4}( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL
MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
{code}

Note that there is also an 'olcObjectIdentifier' attribute type that seems to be used to create
macros for interpolation in OID's used in other attributes:

{code}
  olcObjectIdentifier: OLcfg 1.3.6.1.4.1.4203.1.12.2
  olcObjectIdentifier: OLcfgAt OLcfg:3
  olcObjectIdentifier: OLcfgOvAt OLcfgAt:3
  olcObjectIdentifier: OMsyn 1.3.6.1.4.1.1466.115.121.1
  olcObjectIdentifier: OMsBoolean OMsyn:7

  olcAttributeTypes: ( OLcfgOvAt:10.4 NAME 'olcUniqueStrict' DESC 'Enforce uniqueness of null
values' EQUALITY booleanMatch SYNTAX OMsBoolean SINGLE-VALUE )
{code}

However this additional complexity seems to only be used for the internal/vendor-specific
schema itself (not 'core', 'nis', etc.).

Attached is LDIF output of from searching cn=schema,cn=config.

Mailing List reference: https://mail-archives.apache.org/mod_mbox/directory-api/201308.mbox/%3CCABzFU-eOfmwiFpR1w0Fd-JhNFBVLO0NkHKa5w61ReFBEq%3DWkaw%40mail.gmail.com%3E


> Implement "online" OpenLDAP schema parsing in DefaultSchemaLoader
> -----------------------------------------------------------------
>
>                 Key: DIRAPI-154
>                 URL: https://issues.apache.org/jira/browse/DIRAPI-154
>             Project: Directory Client API
>          Issue Type: Improvement
>    Affects Versions: 1.0.0-M20
>            Reporter: Gerald Turner
>             Fix For: 1.0.0-M29
>
>         Attachments: loadSchema.log, openldap-schema.ldif
>
>
> The constructor in DefaultSchemaLoader has the following comment:
> {code}
>   // TODO Handle schema loading on other LDAP servers
> {code}
> For OpenLDAP this would require searching subtree under cn=schema,cn=config and handling
attributes like:
> {code}
>   olcAttributeTypes: {1}( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (family)
name(s) for which the entity is known by' SUP name )
>   olcObjectClasses: {4}( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL
MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
> {code}
> Note that there is also an 'olcObjectIdentifier' attribute type that seems to be used
to create macros for interpolation in OID's used in other attributes:
> {code}
>   olcObjectIdentifier: OLcfg 1.3.6.1.4.1.4203.1.12.2
>   olcObjectIdentifier: OLcfgAt OLcfg:3
>   olcObjectIdentifier: OLcfgOvAt OLcfgAt:3
>   olcObjectIdentifier: OMsyn 1.3.6.1.4.1.1466.115.121.1
>   olcObjectIdentifier: OMsBoolean OMsyn:7
>   olcAttributeTypes: ( OLcfgOvAt:10.4 NAME 'olcUniqueStrict' DESC 'Enforce uniqueness
of null values' EQUALITY booleanMatch SYNTAX OMsBoolean SINGLE-VALUE )
> {code}
> However this additional complexity seems to only be used for the internal/vendor-specific
schema itself (not 'core', 'nis', etc.).
> Attached is LDIF output of from searching {{cn=schema,cn=config}}.
> Mailing List reference: https://mail-archives.apache.org/mod_mbox/directory-api/201308.mbox/%3CCABzFU-eOfmwiFpR1w0Fd-JhNFBVLO0NkHKa5w61ReFBEq%3DWkaw%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message