openldap-devel

openldap-devel@openldap.org

1418 discussions

'countryName' in core.schema (was : (ITS#5236) core.ldif differs from core.schema)
by Michael Ströder 12 Dec '07

12 Dec '07

HI! following up on this because some older schema files reference 'countryName' (and worked with RE23). Howard Chu wrote: > I'm puzzled why RFC4519 drops the 'countryName' alias for this type > from the RFC2256 definition. Me too... How to deal with that (except changing the schema files of other vendors)? Ciao, Michael.

2 3

Issues with migration 2.3 to RE24 with slapcat/slapadd
by Michael Ströder 12 Dec '07

12 Dec '07

HI! When migrating data extracted from a 2.3.39 server via slapcat into a RE24 server I had two issues: 1. Option -q of slapadd resulted in a seg fault. 2. I had to remove the entryCSN attributes from the LDIF data. Probably this is somewhat related to the 2.3-2.4 replication issue. Ciao, Michael.

3 6

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

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