Hi, I just updated the JIRA.
https://issues.apache.org/jira/browse/DIRSERVER-1711?focusedCommentId=13255111#comment-13255111
Thanks for all you've done but I'm experiencing the same issue. I've rebuilt
the server from scratch from the trunk today at noon eastern time.
Again, I create a partitio
2012/4/16 لسٹ शिराज़ :
> Hi,
>
> Can one do the following actions in an embedded environment?
>
> 1. setting default attribute value of "nis" ldif schema to FALSE
yes, just create an LDIF entry with chageType: modify
> 2. importing own custom schema
> 3. creating the entries conforming to the above
Hi,
Can one do the following actions in an embedded environment?
1. setting default attribute value of "nis" ldif schema to FALSE
2. importing own custom schema
3. creating the entries conforming to the above (custom) schema
Since the embedded sample is very basic, if anyone can provide some
adv
many thanks Kiran!
After adding new nis dependency, i am able to import the schema now.
However can one change .schema file before to get the right ldif from
studio?
Cheers,
Shiraz
On Mon, Apr 16, 2012 at 2:31 PM, Kiran Ayyagari wrote:
> the schema uses caseExactIA5SubstringsMatch which is pa
Le 4/16/12 2:31 PM, Jim Willeke a écrit :
I have never seen a schema ldif file that looks like that.
The format that I have always used is:
This is because there are two ways to update the schema :
- either you update the cn=schema entry (which is basically the
SubschemaSubentry containing the
I have never seen a schema ldif file that looks like that.
The format that I have always used is:
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.5923.1.1.1.1
NAME 'eduPersonAffiliation'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY caseIgnoreMatch
SYN
the schema uses caseExactIA5SubstringsMatch which is part of the nis
schema, so enable nis schema
and then import.
otoh, the desriptions in the ldif file are being encoded as Base64
values by Studio cause of some unwanted
white space in .schema file, you may want to fix those as well,
however this
I do not think the schema has any dependencies, as it does not have any
m-dependencies attribute within. For more insight the logs have been pasted:
server console log: http://pastebin.com/RDEshSuY
the ldif, generated from openldap schema: http://pastebin.com/QmBUxph5
and the import log: http://
Ok Great! Just so you know, i've always created indexes before importing users.
Here are the steps i take:: Create partition and indexes then restart. ( the
attribute.db files show up in the file system with size 20KB). Then i import
the base dn and branches, restarting once more before importin
Making progress...
The index were deleted due to some regression introduced last year when
using alias and not OIDs when creating index.
Another issue is that the master tabl, containing all the entries, was
read fully for each index to create, instead of reading it only once,
and adding the
2012/4/16 لسٹ शिराज़ :
> Hi Kiran,
>
> Thanks for the reply and also helped a bit.
>
> I have imported the openldap schema file and exported as apache-ldap ldif
> schema with the schema editors. Thereafter tried to import into the DIT
> with LDAP browser while running the apacheds in parallel, howe
Hi Kiran,
Thanks for the reply and also helped a bit.
I have imported the openldap schema file and exported as apache-ldap ldif
schema with the schema editors. Thereafter tried to import into the DIT
with LDAP browser while running the apacheds in parallel, however
encountered several errors of s
12 matches
Mail list logo