openldap-devel

openldap-devel@openldap.org

1418 discussions

test suite data
by Howard Chu 18 Jun '08

18 Jun '08

I'm currently trying to run "make test" with back-ndb and most of the comparisons fail even though the backend is behaving correctly. 1) back-ndb always fills in all objectclasses in the objectclass chain, while the test.ldif files omit most of the superior classes. 2) back-ndb always returns attributes in the order they were defined in their corresponding objectclass definition, instead of preserving whatever order they were submitted in. Any thoughts on how to address this? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 8

managing OpenLDAP / back-config
by Ralf Haferkamp 17 Jun '08

17 Jun '08

With the great features that back-config provides to configure OpenLDAP servers at runtime it seems logical to start thinking about providing tools that could help to leverage those features. Currently to manage an OpenLDAP server through back-config you have the option to use either a generic LDAP Browser (JXplorer, Apache LDAP Studio, web2ldap), the OpenLDAP command line tools (ldapsearch, ldapmodify, ...) or homegrown software using one of the available LDAP APIs. I think it would be helpful to have some more sophisticated management tools (Commandline and/or GUI). In order to get there I think it could be helpful to create an API dedicated to provide an easy way to access the OpenLDAP configuration (databases, overlays, schema, access control, ...). This API could then be used to create different flavors of management tools. I have not yet spend too much time thinking about the design of such an API. Neither about the programming language that I'd use to implement something like this (Python, C, C++, ?). I first like to get a feeling how others think about this and if anybody is interested in collaborating on such an API. So please feel free to reply with your comments and suggestions :) -- regards, Ralf

7 24

Re: commit: ldap/contrib/slapd-modules README
by Hallvard B Furuseth 16 Jun '08

16 Jun '08

ghenry(a)OpenLDAP.org writes: > Read over, update using work from hallvard and spell check. Actually we both got that wrong. The posixgroup README says compile it as plugin acl-posixgroup. -- Hallvard

1 1

[Fwd: LDAP Content Synchronization Operation (rfc4533)]
by Gavin Henry 16 Jun '08

16 Jun '08

Another use outside the project. -------- Original Message -------- Subject: LDAP Content Synchronization Operation (rfc4533) Date: Sat, 14 Jun 2008 21:01:36 +0200 From: Mathieu PARENT <math.parent(a)gmail.com> To: perl-ldap(a)perl.org Hi, I have implemented LDAP Content Synchronization Operation (rfc4533) in perl-ldap (See the attached patch). This is used by the OpenLDAP server and provide features similar to Persistent Searches in a more consistent way. This is my first try in this code, any feedback is welcome. I don't know how to handle the Sync Info Message which is an LDAP Intermediate Response Message (see 2.5 in RFC). perl-ldap doesn't seems to support intermediate responses in response to LDAP::Search. What is the way to correct this ? thanks Mathieu Parent -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP.

1 0

Subschema missing entryCSN
by Michael Ströder 13 Jun '08

13 Jun '08

HI! Any particular reason why attribute type 'entryCSN' is still missing in the subschema? (testing with 2.4.10) Ciao, Michael.

1 0

Deleting overlays from cn=config
by Ralf Haferkamp 12 Jun '08

12 Jun '08

Hi, as back-config does currently not have support for the delete operation (config_back_delete() just returns LDAP_UNWILLING_TO_PERFORM currently) I am trying to figure out what is needed to get at least delete support for simple overlays (e.g. ppolicy or memberof) running. What I am currently doing is: - renumber the indexes of the siblings of the overlay that's going to be deleted - remove the CfEntryInfo of the overlay from the internal config tree - remove the Entry from the underlying LDIF database Additionally I need to remove the overlay's slap_overinst structure from the overlay list of the backend and in case it was the last overlay, restore the original BackendInfo structure and delete the SLAP_DBFLAG_GLOBAL_OVERLAY flag from the BackendDB structure of the underlying database (for global overlays). Currently I use the overlay_destroy_one() function for this task. This also calls the db_destroy() hook of the overlay which should take are of free resources held by the overlay. I am a bit unsure about the db_destroy() part. Is that enough or is it needed to call the db_close() hooks (when provided by the overlay) before calling db_destroy()? Did I miss something else? Is anybody else currently working on this? Up to now I am testing this only with some simpler overlays (memberof, pcache), I assume that deleting overlays that instantiate their own databases (like pcache, translucent(?)) might get a little more hairy. -- Ralf

7 17

contextCSN propagation problems
by Rein Tollevik 10 Jun '08

10 Jun '08

The worst problems we had after upgrading to 2.4.x seems to be over now, and the replication appear to work (at least mostly) as it should. One problem that still remains is that the contextCSN attributes themselves don't propagate as I wish they would. Before I start coding or filing more ITSes I would like to have comments as to whether my analysis of the problem seems correct or not. First, a description of our configuration is needed. I think a test script for this configuration would be nice to have, so I'm going to create that before I do anything else. I currently think of it as syncrepl-asymmetric, but suggestions for better names are welcome. Now the configuration, which is centered around a central master server. It has a glued database with a set of subordinates. The central master is the (sole) master for most of these subordinates, but there are also a set of remote site-masters that each has one subordinate database that they are the master for and that is replicated back to the central master. The site-masters has a similar glued configuration, and they replicates the glue entry from the central master. Different rootdn values on the subordinates managed by syncrepl and the one the site-master is the master for prevents syncrepl from wiping out the content of that database during the present phase. None of the site-masters receives all the subordinate databases the central master has, and which they receive varies. This is controlled by acl rules on the central master. On each of the sites (including where the central master is) there are search-only servers that replicates the glue suffix from their site-master (or the central master). The search servers has a single database (for historical reasons), but their layout shouldn't matter very much. All of the master servers uses syncprov on the glue database, and everyone except the central master uses syncrepl on the glue database. The central master cannot use it there, as that would have caused it to wipe out those subordinates that aren't on the site-master it replicates from during the refresh phase. Different serverIDs are used on the master servers, so an updated contextCSN set should include as many values as there are master servers. Now to the problem. If a modification is made (on the central master) to a subordinate database that isn't replicated to one of its consumers it will not receive the updated contextCSN value from the central master. Which means that I cannot monitor the contextCSN values to verify that the replication is working as it should. And the consumers will (after a restart) present an outdated contextCSN set during the refresh phase, even though their database content is up to date. But this will be corrected when/if an update is made to a subordinate db that is replicated to the consumer. A worse problem is when the modifications is made to a subordinate db the central master replicates from one of the site-masters. In this case there will never be any updates from that site-master that should be propagated. So the consumers will, until it restarts, be stuck with the contextCSN value matching that remote site-master which it received after the present phase. Or, oh well, that is not quite true... Due to a bug in syncprov it fails (on the central master) to detect and filter out the contextCSN update from syncrepl on a subordinate db. Which means that the central master will send an update of the glue entry to its consumers, so that the value is propagated from the central master to its immediate consumers. But it will not propagate further from the site-masters to the search servers on their site. As this bug makes things work at least partly as I wish I'm a bit reluctant to have it fixed yet... So far my proposed solution to this problem is that syncprov_matchops() should, when a modification fails to match the test_filter() nor is a deleted entry, send a sync info protocol message with the updated contextCSN in the newCookie field to its consumers. Does this sound like a valid solution? There seem to be support in syncrepl.c for receiving these messages, and in syncprov.c for sending them. But it never actually does it as far as I can see. -- Rein Tollevik Basefarm AS

1 0

demand slapindex after slapd.conf += index
by Hallvard B Furuseth 10 Jun '08

10 Jun '08

A suggestion for a vain attempt to kill a FAQ: To teach people to run sbin/slapindex after adding an index to slapd.conf, slapd can refuse to start if an index file is missing but dn2id.bdb exists. Same with other slap tools that need to open/create the index file. (At least slapadd, I don't know if there are others.) slapindex and slapcat, at least, will need to keep working. If database recovery can sabotage this feature or vice versa, recovery will of course have to take precedence. -- Hallvard

2 2

RE24 testing (again)
by Quanah Gibson-Mount 06 Jun '08

06 Jun '08

Pulled in a few more things, please re-sync and test. These were the last outstanding changes known for 2.4.10. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

7 6

Re: RE24 testing (again)
by Raphaël Ouazana-Sustowski 03 Jun '08

03 Jun '08

Hi, Le Mar 3 juin 2008 10:37, Jonathan Clarke a écrit : > Gavin Henry a écrit : >> <quote who="Howard Chu"> >>> Quanah Gibson-Mount wrote: >>>> Pulled in a few more things, please re-sync and test. These were the >>>> last >>>> outstanding changes known for 2.4.10. >>> All tests OK here. OpenSuSE 10.2, x86-64 >> >> Likewise. Fedora 8/9 i386/x86_64, Centos 5.2 i386/x86_64 and Debian Etch >> (4.0) i386/x86_64 > > Also OK for me on Ubuntu i386 and Debian x86_64. Idem here on Ubuntu/i386/dual core. Note that this time test050 (on hdb) ran more then 200 times without any problem. Regards, Raphaël Ouazana.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel