openldap-devel

openldap-devel@openldap.org

1416 discussions

Avoid use of hardcoded paths in test suite
by Buchan Milne 11 Dec '07

11 Dec '07

Please replace the hardcoded testrun in test024 with ${TESTDIR}. This avoids the need for the user running the test suite to have write access to the installed test suite (as is the case when shipping the test suite as a package). The attached patch fixes this on 2.4.6. If *really* necessary, I'll file an ITS ... Regards, Buchan

1 0

2.3 and 2.4 syncrepl
by Howard Chu 10 Dec '07

10 Dec '07

I just hacked up test018 in RE24 to use a 2.3 consumer, and the final comparison fails. It's mostly benign, the entryUUID occurs in a different position in the 2.3 output. But it looks like 2.3 is doing something funny with the (longer) 2.4 contextCSN. I'll have to play with this some more. Haven't tried the reverse yet either. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 1

Reg JLDAP
by Nachiappan Palaniappan 10 Dec '07

10 Dec '07

Hi, There have been a lot of opinions on Novell being not committed to the JLDAP project off late and there have been not much of contribution from Novell either. I understand these and as I told earlier the problem is from our side in not monitoring / participating much in the forums or bugs. Not to justify our mistakes, but to inform you the fact that jldap has been contributed long back to the community, there has been a lot of ownership changes (in fact a lot of geographical changes) in between and we guys who work on LDAP SDK projects also work on various other projects as well and hence not able to focus much here. These were also the reasons for the issue. Please understand that I'm not trying to make excuses. However, leaving the past beside, I can assure the following from now on: 1. We've started working on the pending ITS bugs and we'll try to resolve as many issues as possible quickly. 2. We'll start participating in the mailing lists actively. 3. Regarding the enhancements and the deprecated JLDAP classes, I won't commit any date. But we'll start working on that as well and it would be great if other JLDAP developers like Marc and Jon too work together in a collaborative model. Please share your thoughts on these and let me know, if I'm erring anywhere or I missed out something. Thanks, Palaniappan.

3 3

Re: logging
by Hallvard B Furuseth 09 Dec '07

09 Dec '07

[Moving from -software to -devel] Howard Chu writes: > There was an effort to introduce various log levels back in the > OpenLDAP 2.1 timeframe but it turned out to be too cumbersome and we > eventually gave up on it. If someone else wants to take a stab at it, > they're welcome to give it a go. If I remember that effort correctly, one mistake may have been to stuff everything into a global log system (which needed to know about the various modules), instead of having the modules keep track of their desired log levels and severity levels. Each module could optionally maintain its own struct with {module name, mapping of loglevel/'-d' level => severity level} or whatever, similar to what we have a global structure for now. A pointer to it would be passed as a new argument to the log macros. For that matter, slapd.conf's "loglevel" could then be database-specific. Source files which mostly log about a single module could #define some standardized macro to refer to that module's log struct too. Then a set of log macros (with the same names as the current ones of course) can use that macro as the argument for the module pointer. -- Regards, Hallvard

2 1

test008 failed in HEAD
by Hallvard B Furuseth 07 Dec '07

07 Dec '07

http://folk.uio.no/hbf/test008out2.tbz ldapsearch.flt = ldif.flt + cn=James A Jones 4,ou=People,dc=example,dc=com

4 19

'monitoring disabled' message
by Hallvard B Furuseth 07 Dec '07

07 Dec '07

RE24 slapadd complains: bdb_monitor_db_open: monitoring disabled; configure monitor database to enable I prefer slapadd to be silent unless there is something wrong. "database monitor" in slapd.conf shuts it up (which makes the message misleading, first I thought I had done --disable-monitor). But is there some reason why one ought to add database monitor to slapd.conf? Where is it documented? -- Hallvard

3 3

Re: 'monitoring disabled' message
by Gavin Henry 07 Dec '07

07 Dec '07

<quote who="Pierangelo Masarati"> > > >> It's not, but it should be, as you can add things to it via back-config >> according to Ando. >> >> Didn't he add new monitoring info for bdb caching? > > Back-monitor allows the programmatical addition of custom monitoring > information. Back-bdb and back-hdb by default add specific monitoring > information, mostly related to cache usage and missing indexing searches, > unless disabled by "monitor FALSE" (or something like that). So, by > default, when back-bdb is in use monitoring should be available ("database > monitor"). OK, one for the docs/man page in back-monitor. Will check if it's in there or not. > > I think the informative warning is issued to inform the administrator of > the opportunity is missing. In a GUI-based system this would probably > qualify as a "tip-of-the-day" rather than a warning... ;-) Is this an OpenLLDAP standard technique? > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > >

1 0

Empty DN ("") String Value?
by Marc Boorshtein 06 Dec '07

06 Dec '07

I wanted to get an opinion from the other java ldap projects. Should the toString() method of a class that represents a DN return null or an empty string? I would think an empty string but JLDAP returns null. Anyone have an opinion on the matter? Thanks Marc

6 8

LDAP/Samba 4 summary
by Andrew Bartlett 04 Dec '07

04 Dec '07

(please forgive the cross-posting to subscriber-only lists) Howard Chu helpfully wrote up this summary of the meeting we held at the CIFS Workshop on how Samba4 should work with an LDAP backend. The background is that Samba4 increasingly needs some things that an LDAP server could provide for us. In the short term, we need to add subtree renames to ldb_tdb, but OpenLDAP's hdb already provides this for us. Likewise, we have a desperate need for replication (because any site in need of Samba4's features will want multiple DCs) - and Fedora DS's replication seems like a very good, solid answer. (Sadly it doesn't give us subtree renames...). Another feature we don't yet do schema validation in Samba4, beyond checking that the objectClass list is valid. We need to extend that, but perhaps the LDAP server could do that validation for us? Finally, in the long term, we would like to have Samba4 play nice in a multi-use directory, and this presents a schema mapping problem. We agreed to get together and try and work out a schema that is compatible to Microsoft's extensions, without being too painful to see from a traditional client. I hope to put together a discussion on this in the near future. I expect we will continue to use and support ldb_tdb as a backend on Samba4, but for some features (which they will want), users should be directed to use LDAP as an important backend. Andrew Bartlett -------- Forwarded Message -------- From: Howard Chu <hyc(a)symas.com> To: OpenLDAP-devel(a)openldap.org Subject: [Fwd: LDAP/Samba 4 summary] Date: Fri, 28 Sep 2007 10:42:22 -0700 Yesterday afternoon at the CIFS Workshop we had a meeting to discuss Samba 4's use of LDAP going forward, and what obstacles remained. Among the attendees that I can remember were Andrew Bartlett, Andrew Tridgell, Simo Sorce, Stefan Metzmacher, and (one more, I've forgotten the name) from the Samba team. Nicole Jacque and another (sorry, don't remember the name) from Apple/OpenDirectory, Pete Rowley from FedoraDS, and myself and Marty Heyman for OpenLDAP and Symas. The upshot is that both the Samba and the LDAP sides have work to do, but there are no major roadblocks. LDAP will be Samba 4's default/recommended data store. As for OpenLDAP, most of what Samba 4 needs is either already implemented, or in progress. Schema design tends to still be a stumbling block; in a separate conversation we discussed some design issues in MIT's new Kerberos schema as well as missing features in Heimdal's existing Kerberos schema. That's a bit outside this openldap-devel scope but I've committed to working with the Samba and Kerberos communities to draft some changes to unify these two Kerberos schemas. -------- Forwarded Message -------- From: Howard Chu <hyc(a)symas.com> To: Andrew Bartlett <abartlet(a)samba.org> Subject: LDAP/Samba 4 summary Date: Thu, 27 Sep 2007 22:41:23 -0700 Missing features / wishlist bitwise ops. already in OpenLDAP, recently added to FedoraDS(?) USNs partially implemented in OpenLDAP, need more complete spec LDAP Transaction support draft-zelenga-ldap-txn - partially implemented in OpenLDAP some concerns because Samba's definition of transaction is not the canonical ACID definition. More like ACI, no Durability guarantee, doesn't play well with LDAP Multimaster Replication. We all agreed that if Samba doesn't care, neither do we. All that matters is that it provides tidy, painless rollback in event of intermediate failures. Access Controls my suggestion re: OpenLDAP - we support modular ACL engines, we should just write a module for native NT ACLs in OpenLDAP AD schema - we agreed that a new schema is necessary no matter how you slice it, we will all collaborate to define a superset of AD that everyone can support. Authentication mechanisms - generally Samba will handle this itself validation - Samba4 + LDAP must pass everything under Samba's "make test" suite. Transactions again - we may need things like memberOf and other linked attributes to be managed internally in the server. No problem, both OpenLDAP and FDS have memberOf plugins already available. Subtree renames - MS tools assume subtree renames work. Supported in OpenLDAP already (back-hdb, back-ldif, will be in back-tdb). Unfortunately not supported in FedoraDS, might be able to kludge it, but it will require additional mapping layers. And kludging will break base-scope searches, referential integrity, etc... -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com

5 11

ordered indexing for integers
by Howard Chu 02 Dec '07

02 Dec '07

I was looking at adding support for ordered indexing for Integer attributes. This would be an incompatible format change for index databases. In fact I'd need to change the Presence index key as well, so it would affect all index databases, not just those for Integer attributes. Currently the Presence index uses a hardcoded 4 byte key of 0x00000001. I want to change it to a 2 byte key of 0x0000 instead, to prevent it from colliding with the Integer key space. So far, 2.4 and 2.3 have totally identical database formats. Is it worthwhile to break this compatibility to gain this feature, or better to preserve compatibility and ignore this feature for now? Any thoughts on going ahead with it here in RE24? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

8 52

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel