[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: schema checking cannot be disabled
- To: Michael Torrie <torriem@chem.byu.edu>
- Subject: Re: schema checking cannot be disabled
- From: matthew sporleder <msporleder@gmail.com>
- Date: Thu, 29 Sep 2005 15:01:42 -0400
- Cc: OpenLDAP software list <openldap-software@OpenLDAP.org>
- Content-disposition: inline
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tCpl/sKYmmICAr4wOfmxC8VbHzZoKQkaVsx/MBhVPY+u58ClfS0OLQFqG0XkM9+Wm2riNeC279wha+bSmBDVGgRU7/3e/794m1yzAuN2O1KCEmGwC9Smzq8v3ExsYBR7v0FecF2WT3fAofNoui19KdTMtc/pIA8AmAVZj1trRes=
- In-reply-to: <1128015301.7502.11.camel@isengard>
- References: <1128015301.7502.11.camel@isengard>
'schemacheck off'
if your slapd.conf? I'm not sure if this is still around, but it's
mentioned in some mailing list archives. schemachecking is an option
for syncrepl, but I don't think it will help you.
Also- you might be able to hack the schema file and make it look like
the redhat/osx server.
Good luck,
_Matt
On 9/29/05, Michael Torrie <torriem@chem.byu.edu> wrote:
> I need to run openldap with schema checking off. This is because in the
> real work, things are not always ideal. I have to be able to declare an
> object to be of objectClass posixGroup *and* GroupOfUniqueNames. This
> data is being imported from another directory service (Apple OS X
> server) and as such I can't just alter these group definitions
> arbitrarily.
>
> I've been doing a lot of research and it appears that RedHat's directory
> server is also implementing this, even though it is a schema violation.
> Apparently RFC 2307bis has died, which would have corrected this
> problem.
>
> Can OpenLDAP 2.2.28 be hacked to turn schema checking back off? Or
> better yet, how can I reconcile the posixGroup/groupOfUniqueNames
> objectClasses? I'm not opposed to altering the schemas, but altering an
> official schema (nis.schema or core.schema) could be problematic. How
> are people dealing with this problem?
>
> Michael
>
> --
> Michael Torrie <torriem@chem.byu.edu>
>