Re: (ITS#6672) OpenLDAP LDAP_R_COMPILE cleanup (LDAP_MUTEX_LOCK/LDAP_MUTEX_UNLOCK)
by hyc＠symas.com
doug.leavitt(a)oracle.com wrote:
> Full_Name: Douglas Leavitt
> Version: HEAD
> OS: OpenSolaris
> URL: http://cr.opensolaris.org/~djl/openldap-patch2/
> Submission from: (NULL) (192.18.43.225)
>
>
> This patch is part 2 of 3 of the original ITS #6625 effort.
> (aka openldap draft-zeilenga-ldap-c-api-concurrency)
>
> As discussed on openldap-devel(a)openldap.org, #6625 is to be split into 3
> distinct patches.
>
> This patch cleans up much of the LDAP_R_COMPILE ifdefs in libldap.
> The patch converts almost all
>
> #ifdef LDAP_R_COMPILE
> ldap_pvt_thread_mutex_[un]lock(...)
> #endif
>
> sequences to simpler
> LDAP_MUTEX_[UN]LOCK macros.
>
> No behavioral changes are introduced by this patch. It is strictly a
> code cleanup patch.
Thanks, committed.
>
> Regression testing (post conversion) performed using both
> 32-bit and 64-bit x86 compiles on an OpenSolaris system.
>
> IPR Notice
>
> This patch file is derived from OpenLDAP Software. All of the modifications to
> OpenLDAP Software represented in the following patch(es) were developed
> by Oracle Corporation. Oracle Corporation has not assigned rights and/or
> interest in this work to any party. I, Douglas Leavitt am authorized by Oracle
> Corporation, my employer, to release this work under the following terms.
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 11 months
(ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by arthur＠arthurdejong.org
Full_Name: Arthur de Jong
Version: 2.4.23
OS: Debian/unstable
URL:
Submission from: (NULL) (2001:888:1613:0:218:8bff:fe55:2c9f)
When a network connection to the LDAP server fails (is severed with iptables in
my set-up) the error is detected properly with ldap_result()
(LDAP_OPT_TIMELIMIT, LDAP_OPT_TIMEOUT and LDAP_OPT_NETWORK_TIMEOUT options are
set), however closing the connection with ldap_unbind() hangs indefinitely on a
read() operation (determined by strace) when using a ldaps:// connection.
If the connection is opened without TLS ldap_unbind() only writes some data on
the connection and then closes it but with TLS it expects some response back.
Since read() is used this blocks.
This is a backtrace of the thread that was hanging:
#0 0xb7fe2424 in __kernel_vsyscall ()
#1 0xb7f5809b in read () at ../sysdeps/unix/syscall-template.S:82
#2 0xb7e021bb in sb_stream_read (sbiod=0x8064630, buf=0x8083038, len=5)
at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:493
#3 0xb7e0132a in sb_debug_read (sbiod=0x807e250, buf=0x8083038, len=5)
at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:827
#4 0xb7fa0d27 in tlsg_recv (ptr=0x806fb50, buf=0x8083038, len=4294966784) at
tls_g.c:904
#5 0xb7c65aa2 in ?? () from /usr/lib/libgnutls.so.26
#6 0xb7c65f77 in ?? () from /usr/lib/libgnutls.so.26
#7 0xb7c611e7 in _gnutls_recv_int () from /usr/lib/libgnutls.so.26
#8 0xb7c626b8 in gnutls_bye () from /usr/lib/libgnutls.so.26
#9 0xb7fa0dc4 in tlsg_sb_close (sbiod=0x807e268) at tls_g.c:970
#10 0xb7e01831 in ber_int_sb_close (sb=0x80645a8)
at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:383
#11 0xb7f8d1a0 in ldap_free_connection (ld=0x8066418, lc=0x8065b60, force=1,
unbind=1) at request.c:768
#12 0xb7f83060 in ldap_ld_free (ld=0x8066418, close=1, sctrls=0x0, cctrls=0x0)
at unbind.c:93
#13 0xb7f83326 in ldap_unbind_ext (ld=0x8066418, sctrls=0x0, cctrls=0x0) at
unbind.c:52
#14 0xb7f8343f in ldap_unbind (ld=0x8066418) at unbind.c:69
#15 0x0804cfc0 in ?? ()
#16 0x0804e750 in ?? ()
#17 0x08057a9f in ?? ()
#18 0x0804bb8d in ?? ()
#19 0xb7f50955 in start_thread (arg=0xb7b92b70) at pthread_create.c:300
#20 0xb7ed0e7e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
More background information is available at [0].
As a workaround [1] I've used LDAP_OPT_DESC to get the file descriptor for the
connection and used setsockopt(SO_RCVTIMEO) and setsockopt(SO_SNDTIMEO) on it.
This fixes the problem for me at least but I'm not 100% this has no unwanted
side-effects.
[0] http://bugs.debian.org/596983
[1] http://arthurdejong.org/viewvc/nss-pam-ldapd?view=rev&revision=1264
12 years, 11 months
(ITS#6672) OpenLDAP LDAP_R_COMPILE cleanup (LDAP_MUTEX_LOCK/LDAP_MUTEX_UNLOCK)
by doug.leavitt＠oracle.com
Full_Name: Douglas Leavitt
Version: HEAD
OS: OpenSolaris
URL: http://cr.opensolaris.org/~djl/openldap-patch2/
Submission from: (NULL) (192.18.43.225)
This patch is part 2 of 3 of the original ITS #6625 effort.
(aka openldap draft-zeilenga-ldap-c-api-concurrency)
As discussed on openldap-devel(a)openldap.org, #6625 is to be split into 3
distinct patches.
This patch cleans up much of the LDAP_R_COMPILE ifdefs in libldap.
The patch converts almost all
#ifdef LDAP_R_COMPILE
ldap_pvt_thread_mutex_[un]lock(...)
#endif
sequences to simpler
LDAP_MUTEX_[UN]LOCK macros.
No behavioral changes are introduced by this patch. It is strictly a
code cleanup patch.
Regression testing (post conversion) performed using both
32-bit and 64-bit x86 compiles on an OpenSolaris system.
IPR Notice
This patch file is derived from OpenLDAP Software. All of the modifications to
OpenLDAP Software represented in the following patch(es) were developed
by Oracle Corporation. Oracle Corporation has not assigned rights and/or
interest in this work to any party. I, Douglas Leavitt am authorized by Oracle
Corporation, my employer, to release this work under the following terms.
12 years, 11 months
(ITS#6671) multi-master replication fails to delete objects from consumer
by bcolston＠xtec.com
Full_Name: Barry Colston
Version: 2.4.23
OS: Fedora 10
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (209.255.208.200)
When a "Refresh Present" phase is performed at a multi-master consumer, objects
that were deleted at the provider
while the consumer was down are not deleted from the multi-master consumer (if
the provider is brought down and back up after the consumer is down). This
problem can be duplicated as follows:
1. Start provider
2. Start consumer, which is configured as a multi-master server
3. Add 10 records to the provider and wait until the records are replicated to
the multi-master consumer
4. Stop the consumer
5. Delete 3 of the records that were added to the provider
6. Stop the provider
7. Start the provider
8. Start the consumer
9. After giving the consumer time to perform the refresh present phase, the 3
records that were deleted at the provider while the consumer was down
are still present on the consumer and were not deleted during the refresh
present phase
Note: the consumer database must have a contextCSN attribute value present for
itself (e.g., there should be 2 contextCSN attribute values
present in the consumer database, one for the provider (in my configuration,
this is serverID 000), and one value for the consumer
(in my configuration, this is serverID 001). An example of the contextCSN
values follows:
dn: dc=authentx
objectClass: top
entryUUID: 8eb6b259-ab66-49bd-b012-674c4f0fba8f
contextCSN: 20101012154030.379053Z#000000#000#000000
contextCSN: 20101012141508.956053Z#000000#001#000000
OpenLDAP 2.4.23 is being used, along with Berkeley 4.6.21 (plus patches).
Consumer log file from -d sync logging option:
@(#) $OpenLDAP: slapd 2.4.23 (Oct 11 2010 18:00:59) $
Barry@XTecVisaAdmin:/usr/src/openldap-2.4.23/servers/slapd
slapd starting
do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT
do_syncrep2: rid=001
cookie=rid=001,csn=20101012180219.072053Z#000000#000#000000
slap_queue_csn: queing 0x1841a30 20101012180219.072053Z#000000#000#000000
slap_graduate_commit_csn: removing 0x1841b18
20101012180219.072053Z#000000#000#000000
daemon: shutdown requested and initiated.
slapd shutdown: waiting for 1 operations/tasks to finish
slapd stopped.
Provider slapd.conf file:
#
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/authentx.schema
pidfile /usr/local/var/slapd.sync1.pid
argsfile /usr/local/var/slapd.sync1.args
allow bind_v2
threads 32
#loglevel 416
password-hash {SSHA}
serverID 000
database bdb
suffix "dc=authentx"
rootdn "cn=xroot,dc=authentx"
rootpw SECRET
directory /authentx/db/ldap/authentx-sync1
overlay syncprov
syncprov-checkpoint 100 15
syncprov-sessionlog 150000
# checkpoint <kbytes> <min>
checkpoint 128 20
#index for the objectclass
index objectClass eq,pres
index cid,eid,pid eq,pres
index gcoid eq,pres
index sysid,certid eq,pres
index imageid,bioid eq,pres
index addrid,emplid eq,pres
index acid,apid,aeid eq,pres
index acpid,agpid eq,pres
index deviceid eq,pres
index qid eq,pres
index scid eq,pres
index docid eq,pres
index procid eq,pres
index prochandlerid eq,pres
index ounit eq,pres
index credentials eq,pres
index entities eq,pres
index permissions eq,pres
index region eq,pres
index aliasedObjectName eq,pres
index proctype eq,pres
index procname eq,pres
index status eq,pres
index upi,ediident eq,pres
index xsync eq,pres
index role,xrole eq,pres
index eroid eq,pres
index esfunction eq,pres
index nippsector eq,pres
index ercog,ercoop eq,pres
index eropron eq,pres
index xsyncid eq,pres
index stockid eq,pres
index stocktypecode eq,pres
index lotserialin eq,pres
index lotserialout eq,pres
index entryCSN,entryUUID eq
index incl eq,pres
cachesize 10000
dncachesize 20000
idlcachesize 1000
sizelimit 500000
timelimit 36000
include /usr/local/etc/openldap/acl.authentx
database monitor
Consumer slapd.conf file:
#
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/authentx.schema
pidfile /usr/local/var/slapd.sync2.pid
argsfile /usr/local/var/slapd.sync2.args
allow bind_v2
threads 32
#loglevel 416
password-hash {SSHA}
serverID 001
database bdb
suffix "dc=authentx"
rootdn "cn=xroot,dc=authentx"
rootpw SECRET
directory /authentx/db/ldap/authentx-sync2
overlay syncprov
syncprov-checkpoint 100 15
syncprov-sessionlog 5000
# SLAVE server replication section
syncrepl rid=001
provider=ldap://localhost:3891
type=refreshAndPersist
retry="30 60 60 +"
searchbase="dc=authentx"
scope=sub
schemachecking=off
bindmethod=simple
binddn="cn=xroot,dc=authentx"
credentials="SECRET"
mirrormode on
# checkpoint <kbytes> <min>
checkpoint 128 20
#index for the objectclass
index objectClass eq,pres
index cid,eid,pid eq,pres
index gcoid eq,pres
index sysid,certid eq,pres
index imageid,bioid eq,pres
index addrid,emplid eq,pres
index acid,apid,aeid eq,pres
index acpid,agpid eq,pres
index deviceid eq,pres
index qid eq,pres
index scid eq,pres
index docid eq,pres
index procid eq,pres
index prochandlerid eq,pres
index ounit eq,pres
index credentials eq,pres
index entities eq,pres
index permissions eq,pres
index region eq,pres
index aliasedObjectName eq,pres
index proctype eq,pres
index procname eq,pres
index status eq,pres
index upi,ediident eq,pres
index xsync eq,pres
index role,xrole eq,pres
index eroid eq,pres
index esfunction eq,pres
index nippsector eq,pres
index ercog,ercoop eq,pres
index eropron eq,pres
index xsyncid eq,pres
index stockid eq,pres
index stocktypecode eq,pres
index lotserialin eq,pres
index lotserialout eq,pres
index entryCSN,entryUUID eq
index incl eq,pres
cachesize 10000
dncachesize 20000
idlcachesize 1000
sizelimit 100000
timelimit 36000
# the authentx database access control directives
include /usr/local/etc/openldap/acl.authentx
database monitor
12 years, 11 months
(ITS#6670) memberof overlay problem
by henjes＠informatik.uni-wuerzburg.de
Full_Name: Robert Henjes
Version: 2.4.23-4
OS: Debian Squeeze
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (132.187.12.89)
Hi,
while using memberof overlay I recognized the following problem in conjunction
with groupOfNames. If you try to add an empty group of names you have to set at
least one member attribute, since it is mandatory. One could have the idea to
point to the group dn itself. If having the memberof overlay active this leads
to a loop while executing an ldapadd. I assume this happens while the memberof
overlay is triggered. Tried to analyze the slapd debug output, but it stops,
after the addition is completed.
Example LDIF file:
dn: cn=stupid,ou=groups,dc=domain
objectClass: top
objectClass: groupOfNames
cn: stupid
member: cn=stupid,ou=groups,dc=domain
The slapd server seems proceed working, except the add process and the subtree
where the LDIF is gets added. You can not stop the slapd server in a normal way,
you just have to do a "kill -9". After that the LDIF file seems to be added, but
I assume, that the memberof overlay representation is inconsistent.
The memberof overlay should be aware of such situations, even if building loops
in dn references is in general not a good idea.
Best regards,
Robert
12 years, 11 months
Re: (ITS#5693) [enhancement] extension of slapo-translucent filtering approach
by wdh＠vasco.com
Hi Pierangelo,
I want to override the objectclass of a remote server to extend it with
the attribute posixAccount
This works but when I search on the attribute objectclass=* the only
result giving me back i the ones with the local defined objectclass.
Is it this issue?
If so, can we do something about it?
is here an easy fix?
Thanks
Wouter
12 years, 11 months
Re: (ITS#6669) SunOS4 LWP removal patch
by hyc＠symas.com
doug.leavitt(a)oracle.com wrote:
> Full_Name: Douglas Leavitt
> Version: HEAD
> OS: OpenSolaris
> URL: http://cr.opensolaris.org/~djl/openldap-patch1/
> Submission from: (NULL) (192.18.43.225)
>
>
> This is part 1 of 3 proposed patches pertaining to ITS #6625
> (aka draft-zeilenga-ldap-c-api-concurrency support)
> As discussed on openldap-devel(a)openldap.org, #6625 is to be split into 3
> distinct patches.
>
> This patch (#1) removes the SunOS 4 LWP threading API support from OpenLDAP.
Thanks, committed.
>
> SunOS4 LWP support has not been supported by Sun (now Oracle) in over a decade.
> Sun's records indicate the last patch was made to the SunOS 4.1.4 patch gate
> code base in 1999. The last major reelase was SunOS 4.1.3U in 1993, 4.1.1 in
> 1990, and SunOS 3.5 in 1988. There are known to be a small number of Solaris 2.6
> and 2.7 systems still running, but Solaris 2.5.1 or earlier are statistically
> very rare. Side note, Sun stops providing any support for Solaris 2.7 on August
> 15, 2008.
>
> Realistically speaking this code has likely not been in use in almost 10 years,
> so it's removal should have no negative effect.
>
>
>
> IPR Notice
>
> This patch file is derived from OpenLDAP Software. All of the modifications to
> OpenLDAP Software represented in the following patch(es) were developed
> by Oracle Corporation. Oracle Corporation has not assigned rights and/or
> interest in this work to any party. I, Douglas Leavitt am authorized by Oracle
> Corporation, my employer, to release this work under the following terms.
>
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 11 months
(ITS#6669) SunOS4 LWP removal patch
by doug.leavitt＠oracle.com
Full_Name: Douglas Leavitt
Version: HEAD
OS: OpenSolaris
URL: http://cr.opensolaris.org/~djl/openldap-patch1/
Submission from: (NULL) (192.18.43.225)
This is part 1 of 3 proposed patches pertaining to ITS #6625
(aka draft-zeilenga-ldap-c-api-concurrency support)
As discussed on openldap-devel(a)openldap.org, #6625 is to be split into 3
distinct patches.
This patch (#1) removes the SunOS 4 LWP threading API support from OpenLDAP.
SunOS4 LWP support has not been supported by Sun (now Oracle) in over a decade.
Sun's records indicate the last patch was made to the SunOS 4.1.4 patch gate
code base in 1999. The last major reelase was SunOS 4.1.3U in 1993, 4.1.1 in
1990, and SunOS 3.5 in 1988. There are known to be a small number of Solaris 2.6
and 2.7 systems still running, but Solaris 2.5.1 or earlier are statistically
very rare. Side note, Sun stops providing any support for Solaris 2.7 on August
15, 2008.
Realistically speaking this code has likely not been in use in almost 10 years,
so it's removal should have no negative effect.
IPR Notice
This patch file is derived from OpenLDAP Software. All of the modifications to
OpenLDAP Software represented in the following patch(es) were developed
by Oracle Corporation. Oracle Corporation has not assigned rights and/or
interest in this work to any party. I, Douglas Leavitt am authorized by Oracle
Corporation, my employer, to release this work under the following terms.
12 years, 11 months
Re: (ITS#6668) MemberOf Overlay
by wf＠bitplan.com
Howard,
thank you for your comments.
I'll happily make more details available since I have the feeling that
there is some value in doing so and
quite a few people might benefit from a clarification of:
http://www.openldap.org/doc/admin24/overlays.html#Member%20Of%20Configura...
which have been commented in
http://www.openldap.org/lists/openldap-technical/201001/msg00125.html
with "I think that the example in the docs is clear enough if you think
it over :)"
the example seems indeed to be clear. The configuration and
installation of the memberOf functionality is IMHO not.
My first bug assumption here is that a non installed memberOf overlay
should lead to
some kind of visible reaction in the logs or in an ldapsearch query at
least when using some verbose or debug
option. At least I did not find any mention of a way to make this
happen. So a system with a memberOf Overlay installed
might show results with a correct query where one that has none
installed will simply show no results.
So someone trying to tryout memberOf will not know whether the query is
incorrect or the overlay is simply not installed.
Even knowing that memberOf is an overlay is something people need to
find out. My feeling is that memberOf is a default installation
part in other ldap implementations. I think I have seen a request to
make it part of the default installation for openldap. I would support this
request given that this would make sure that distributions are forced to
contain it and that overlays are not considered to be optional.
If you look for the overlays in rpmseek you'll see that it seems to be
not-so-common to put them in to distros as it might look from your
response.
Wolfgang
Am 11.10.2010 11:43, schrieb Howard Chu:
> wf(a)bitplan.com wrote:
>> on
>> http://serverfault.com/questions/73213/how-do-i-configure-reverse-group-m...
>>
>>
>> one can see how the issue hit us. We have a Suse 11.2 machine where
>> the standard openldap configuration is slapd.conf based.
>> On another ubuntu 10.04 machine it's cn=config based.
>>
>> The memberOf function simply didn't work and there were not proper error
>> messages and googling the issue was a pain in the ****
>>
>> When we finally found out that we need an overlay no rpm was available.
>> So we went and tried everything on the ubuntu machine.
>
> Whatever mechanism your distro uses to package the overlays is not
> under our control. Whining about it here doesn't help anyone. If your
> distro didn't adequately document where to find the overlays, file a
> doc bug report with them.
>
>> But then there was this change of how everything is configured.
>> Basically we could start googling all over again. Many hours and
>> problems later we got the memberOf function working. What we know now is
>> that OpenLdap has joined the list of projects that have abandondend
>> simple configuration with a more complicated one. We've seen this with
>> grub2, gnome and other projects. In all cases in our opinion this is not
>> helping the majority of people using these projects. Many years of
>> Documentation on the internet is invalidated and worse there are now two
>> ways to do things that are incompatible and if you try to go back (as we
>> did on ubuntu trying to get a slapd.conf based version running) it does
>> not get any easier.
>
> Whining about the config mechanism is pointless. The slapd.conf
> mechanism still works exactly the same as before. The cn=config
> mechanism is the way forward because our large customers demanded a
> way to modify the config without requiring a server restart. If you
> can live with restarting every time you make a config change, you can
> keep using OpenLDAP 2.4 the same as you always have.
>
>> Please use the contact form on BITPlan's webpage if you'd like to get
>> our configuration script for memberOf - we won't publish it at this time
>> since it contains user data.
>
> I personally don't have time to go chasing hither and yon for relevant
> bug report data. If you can't provide a sanitized copy of the relevant
> details, then you're just wasting everyone's time.
>
--
BITPlan - smart solutions
Wolfgang Fahl
Pater-Delp-Str. 1, D-47877 Willich Schiefbahn
Tel. +49 2154 811-480, Fax +49 2154 811-481
Web: http://www.bitplan.de
BITPlan GmbH, Willich - HRB 6820 Krefeld, Steuer-Nr.: 10258040548, Geschäftsführer: Wolfgang Fahl
12 years, 11 months
Re: (ITS#6668) MemberOf Overlay
by hyc＠symas.com
wf(a)bitplan.com wrote:
> on
> http://serverfault.com/questions/73213/how-do-i-configure-reverse-group-m...
>
> one can see how the issue hit us. We have a Suse 11.2 machine where
> the standard openldap configuration is slapd.conf based.
> On another ubuntu 10.04 machine it's cn=config based.
>
> The memberOf function simply didn't work and there were not proper error
> messages and googling the issue was a pain in the ****
>
> When we finally found out that we need an overlay no rpm was available.
> So we went and tried everything on the ubuntu machine.
Whatever mechanism your distro uses to package the overlays is not under our
control. Whining about it here doesn't help anyone. If your distro didn't
adequately document where to find the overlays, file a doc bug report with them.
> But then there was this change of how everything is configured.
> Basically we could start googling all over again. Many hours and
> problems later we got the memberOf function working. What we know now is
> that OpenLdap has joined the list of projects that have abandondend
> simple configuration with a more complicated one. We've seen this with
> grub2, gnome and other projects. In all cases in our opinion this is not
> helping the majority of people using these projects. Many years of
> Documentation on the internet is invalidated and worse there are now two
> ways to do things that are incompatible and if you try to go back (as we
> did on ubuntu trying to get a slapd.conf based version running) it does
> not get any easier.
Whining about the config mechanism is pointless. The slapd.conf mechanism
still works exactly the same as before. The cn=config mechanism is the way
forward because our large customers demanded a way to modify the config
without requiring a server restart. If you can live with restarting every time
you make a config change, you can keep using OpenLDAP 2.4 the same as you
always have.
> Please use the contact form on BITPlan's webpage if you'd like to get
> our configuration script for memberOf - we won't publish it at this time
> since it contains user data.
I personally don't have time to go chasing hither and yon for relevant bug
report data. If you can't provide a sanitized copy of the relevant details,
then you're just wasting everyone's time.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 11 months
