Re: syncrepl w/ 2.3 and bdb 4.3 working great

I was wondering if BerkeleyDB 4.3.28 was suitable for production use with OL 2.3.7. There were some continuing issues with syncprov in 2.3.7 that are now fixed in HEAD. --Quanah Hmm, I haven't been seeing issues, but I'm interested in what those are. I was planning on moving 2.3.7 to

Re: Writing to cn=Subschema

$ ldapmodify -x -D cn=Manager,o=Example -w secret dn: cn=Subschema add: objectClasses objectClasses: ( 1.3.6.1.4.1.21924.99.1 NAME 'fooObjectClass' DESC 'Boo' SUP top STRUCTURAL MUST ( cn $ objectclass ) ) modifying entry cn=Subschema ldap_modify: Invalid syntax (21) additional

Re: syncrepl w/ 2.3 and bdb 4.3 working great

How is your testing doing with OL 2.3.7 and BerkeleyDB 4.3.28? I was wondering if BerkeleyDB 4.3.28 was suitable for production use with OL 2.3.7. So far, things are looking good with 2.3.7 and bdb 4.3.28. For my recent test, I did a dump on my production directory and imported it into my

SyncRepl stops after a few entries [auf Viren überprüft]

Hello! I installed two 2.3.4 server. In the first I added 33 MB of test data under ou=admindepot,ou=foo,o=bar (slapadd) and added the syncprovider-overlay conf in slapd.conf. In the second server I just add the initial ou=admindepot,ou=foo,o=bar entries und configured syncconsumer in

Re: Writing to cn=Subschema

Quanah Gibson-Mount wrote: modifying entry cn=Subschema ldap_modify: Invalid syntax (21) additional info: objectClasses: value #0 invalid per syntax It's objectClass, not objectClasses, last time I read a schema. Quanah, the attribute in the sub schema sub entry is indeed called

Re: Writing to cn=Subschema

Adam Pordzik wrote: $ ldapmodify -x -D cn=Manager,o=Example -w secret dn: cn=Subschema add: objectClasses objectClasses: ( 1.3.6.1.4.1.21924.99.1 NAME 'fooObjectClass' DESC 'Boo' SUP top STRUCTURAL MUST ( cn $ objectclass ) ) modifying entry cn=Subschema ldap_modify: Invalid syntax

Re: Problems with a new schema

Juan Carlos Sanchez Recio wrote: I have created new schema file, and it is giving me some problems. this is the schema file: # As this is an experimental definition we'll use OIDs under 1.1 # Attribute type jfvPerms attributetype ( 1.1.50.1.1 NAME 'jfvPerms' DESC 'Permissions value for

R: SyncRepl stops after a few entries [auf Viren uberpru ft]

Meybe I'm wrong: I'm quite new to this list, but is seems that the problem is due to limits to the size of the replication log file. It is probably better if you first setup the replication matters between the servers with an empty db, start both the servers and finally populate the db with

Re: syncrepl w/ 2.3 and bdb 4.3 working great

--On Monday, September 12, 2005 10:00 AM -0400 Dusty Doris [EMAIL PROTECTED] wrote: I was wondering if BerkeleyDB 4.3.28 was suitable for production use with OL 2.3.7. There were some continuing issues with syncprov in 2.3.7 that are now fixed in HEAD. --Quanah Hmm, I haven't been

Re: syncrepl w/ 2.3 and bdb 4.3 working great

--On Monday, September 12, 2005 9:58 AM -0400 Dusty Doris [EMAIL PROTECTED] wrote: How is your testing doing with OL 2.3.7 and BerkeleyDB 4.3.28? I was wondering if BerkeleyDB 4.3.28 was suitable for production use with OL 2.3.7. So far, things are looking good with 2.3.7 and bdb

slapd stops processing searches

Hi! I wonder if anyone has any pointers on what to look for when investigating why slapd stops processing search requests. It always stops after it's done 24 searches, no matter the order I do the search. The slapd is running thoug, no heavy load on the server and programs can connect, but

Re: requesting clarification of use of config backend

For docs, see http://www.openldap.org/doc/admin23/slapdconf2.html It is redundant to list the rootdn in any ACL clause; the rootdn always has full privileges and ignores all ACLs. Listing the rootdn merely makes ACL evaluation slower for regular users. The order of directives in your

OL 2.3.7 and password policy

Hi All, I am testing OL 2.3.7 on a Debian Sarge box. I would like to implement the password policy overlay. When I try to create a dn that would hold the password policy: [EMAIL PROTECTED]:~$ ldapmodify -vv -x -W -D uid=stran,ou=people,dc=example,dc=com -H ldap://localhost -f passwd_cn.ldif

Re: OL 2.3.7 and password policy

--On Monday, September 12, 2005 5:10 PM -0700 Howard Chu [EMAIL PROTECTED] wrote: It looks like slapd's objectIdentifierMatch rule doesn't understand descriptions (though it is supposed to). You'll have to use the numeric OID instead, until that is fixed. And file an ITS on this! :)

Re: Alias dereferencing

On Sunday 11 September 2005 20:23, Pierangelo Masarati wrote: Hallvard B Furuseth wrote: Apparently, yes: draft-ietf-ldapbis-models, section 2.6 An alias entry shall have no subordinates, so that an alias entry is always a leaf entry. /draft-ietf-ldapbis-models, section 2.6

Re: Alias dereferencing

What would be the best way? The best thing to do would be to take a step back and think about something else for a while. Then read through the LDAP specs and gain an understanding of what facilities are already provided, and how to use them to your advantage. Some things to think about -