Ok, I can import now,
I also noticed that importing:
objectclass ( 1.3.6.1.4.1.17416.0.255.0.14 NAME 'hivosMailAccount' SUP top
AUXILIARY
DESC 'Mail account object as used by Hivos'
MUST ( mail $ homeDirectory $ mailbox $ userPassword )
MAY ( quota $ subscribeToSharedFolder $ isSharedFolder $ hivosIsIn $
horoAanwezig $ horoInDienst $ horoThuis ) )
Did not work, it compained about the DESC line, to make it work I had to
change it to:
objectclass ( 1.3.6.1.4.1.17416.0.255.0.14
NAME 'hivosMailAccount'
DESC 'Mail account object as used by Hivos'
SUP top AUXILIARY
MUST ( mail $ homeDirectory $ mailbox $ userPassword )
MAY ( quota $ subscribeToSharedFolder $ isSharedFolder $ hivosIsIn $
horoAanwezig $ horoInDienst $ horoThuis ) )
It seems to be very strich about the order, is this also in the protocol
specification?
Regards,
Jeroen.
On Fri, May 9, 2008 at 11:35 AM, Alex Karasulu <[EMAIL PROTECTED]> wrote:
> Lowercase the objectClass to objectclass. Same with attributeType make
> sure
> it is all lowercase. We followed the protocol specification with this.
> OpenLDAP schemas used to have more liberty but they're changing it too.
> Just take a look at their latest schema files. They are using the proper
> order and case now.
>
> Alex
>
> On Fri, May 9, 2008 at 3:48 AM, Jeroen Vriesman <[EMAIL PROTECTED]>
> wrote:
>
> > Hi,
> >
> > treid to import schema's from openldap.
> >
> > The import function seems to be very strict.
> >
> > First, I got the error:
> > The file '/root/schema/hivos.schema' can not be read correctly.
> > Line: 23, Column: 9, Cause: unexpected token: NAME
> >
> > When I look in the schema file:
> > attributetype ( 1.3.6.1.4.1.17416.0.255.1.4
> > DESC 'absolute shared folder location'
> > NAME 'sharedFolderLocation'
> > EQUALITY caseExactIA5Match
> > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
> >
> > That one works when I change it to:
> > attributetype ( 1.3.6.1.4.1.17416.0.255.1.4
> > NAME 'sharedFolderLocation'
> > DESC 'absolute shared folder location'
> > EQUALITY caseExactIA5Match
> > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
> >
> > So the import function always expects the NAME first, openldap doesn't
> care
> > about that.
> >
> > After correcting this, I get the error:
> > The file '/root/schema/hivos.schema' can not be read correctly.
> > Line: 121, Column: 1, Cause: expecting "END", found 'objectClass'
> >
> > In the openldap schema file this is where the objectclasses start:
> > attributetype ( 1.3.6.1.4.1.17416.0.255.1.19
> > NAME 'horoThuis'
> > DESC 'True if person is not coming from an internal IP'
> > EQUALITY booleanMatch
> > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
> > SINGLE-VALUE )
> >
> > objectClass ( 1.3.6.1.4.1.17416.0.255.0.14 NAME 'hivosMailAccount' SUP
> top
> > AUXILIARY <----- line 121
> > DESC 'Mail account object as used by Hivos'
> > MUST ( mail $ homeDirectory $ mailbox $ userPassword )
> > MAY ( quota $ subscribeToSharedFolder $ isSharedFolder $ hivosIsIn
> $
> > horoAanwezig $ horoInDienst $ horoThuis ) )
> >
> > The number of ( and )'s are correct in the file, so I don't see what it
> > actually expects.
> >
> > Regards,
> > Jeroen.
> >
> >
> >
> >
> >
> >
> >
> > On Fri, May 9, 2008 at 8:02 AM, Emmanuel Lecharny <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Stefan Seelmann wrote:
> > >
> > >>
> > >> and most of the time admins don't want to start huge complex
> > >>> interfaces to add or edit a schema, working with simple text files is
> > (at
> > >>> least for me) the easyest way.
> > >>>
> > >>>
> > >>>
> > >>
> > >> That is right. Perhaps we should try to extract the schema import and
> > >> export to a separate library, then we could use it for CLI and GUI.
> > >>
> > >>
> > > The best idea, and we already discussed about it, would be to simply
> drop
> > > the new schema into a directory, and either restart the server, or use
> a
> > CLI
> > > to ask the server to load this new schema, or to send an extended
> request
> > to
> > > the server to tell it to load the file.
> > >
> > > We have everything we need to do that, except the glue...
> > >
> > >> Regards,
> > >> Stefan
> > >>
> > >>
> > >>
> > >
> > >
> > > --
> > > --
> > > cordialement, regards,
> > > Emmanuel Lécharny
> > > www.iktek.com
> > > directory.apache.org
> > >
> > >
> > >
> >
>
