[Fwd: [Fwd: [!! SPAM] Re: Syncrepl-Consumer deletes entries]]
by Joachim Hergeth
Hello Ralf,
i changed the slapd.conf file to include logging for the sync process,
so lets see in the next few days what happens.
I also tried to update the OpenLDAP server from the address you
mentioned (http://software.opensuse.org/download/OpenLDAP/SLE_10/) but
this site at least today refuses to connect, so I have to stay with the
current version. May be you could send me a working link, if this
downtime is not only temporarily.
Thanks in advance
Joachim
-------- Original-Nachricht --------
Betreff: [!! SPAM] Re: Syncrepl-Consumer deletes entries
Datum: Fri, 13 Apr 2007 10:48:26 +0200
Von: Ralf Haferkamp <rhafer(a)suse.de>
An: <openldap-software(a)openldap.org>
Referenzen: <461DF00E.8070809(a)freenet.de>
On Thursday 12 April 2007 10:38, Joachim Hergeth wrote:
> Hello list,
>
> I have an OpenLDAP provider/consumer installation on two SLES10 systems.
> One is set up as a provider LDAP, the second is a consumer LDAP using
> "refreshOnly" synrepl synchronization. The LDAP provides user
> information for a Samba installation.
>
> The initial synchronization of the consumer works as expected. All LDAP
> entries are copied to the consumer directory. But after some time,
> usually when users log in into the Samba running with the provider LDAP,
> nearly 50% of all LDAP entries on the consumer are deleted. This happens
> without any change on the provider LDAP!
I guess that you are testing this with the OpenLDAP Version that shipped
with
SLES10? Would you mind try a newer Version, e.g. the RPMs from
http://software.opensuse.org/download/OpenLDAP/SLE_10/ and check if the
problem is there as well? Note, that we have an update in the queue for
SLES10 to bring it to a more recent version.
Some general comments regarding you configuration (I guess you special
problem
is not related to those):
- The provider config has a line "schemacheck on" this is not a valid
slapd.conf statement (IIRC it is from OpenLDAP 2.0.X times or even older)
- To debug syncrepl Problems it is most helpful to have the loglevel "sync"
enabled. You can to that by just adding "sync" to you "loglevel" line.
- The "backend bdb" statement is superfluous
- The "syncprov-sessionlog 1" begins with whitespaces, might be a copy 'n
paste error in the mail. If it also begins with whitespaces in your
slapd.conf you should remove the whitespace. Otherwise it would be
treated
as the continuation of the previous line (which is wrong). Additionally a
sessionlog of "1" operation doesn't make much sense IMO. I suggest you
either remove that option or set it to a more reasonable value.
- I don't know how large you database is (how many entries) but I should
make
sure that the syncrepl consumer does not hit the sizelimit of your
provider.
As you have not configure any sizelimit the default is used which is 500.
You can adjust the sizelimit with the "sizelimit" or the "limits"
directive
in slapd.conf (see slapd.conf man-page for details).
> Checking the logs I found, that delete-messages can be found in the
> consumers system log.
>
> I do not understand the source of the problem. No entries in the
> provider LDAP are deleted, so no entries should be deleted in the consumer.
Checking if it works with a more recent Version and logfiles with syncrepl
logging enabled might help to clear up the issue.
> To check the installation, I set up a second consumer in a VMWare
> environment. And also in this system, which had been set up from scratch
> and only holds the OpenLDAP-consumer, the entries are deleted at the
> same time when they are deleted in the "real" OpenLDAP consumer system.
>
> When I change an attribute of an entry in the provider LDAP which has
> been deleted from the consumer by this process, like adding a
> description, this change is forwarded to th consumer and the entry
> "reappears" in the LDAP of the consumer.
--
Ralf
16 years, 1 month
slapd won't start and problems with syslog
by Tim Garton
All,
Running OpenLDAP 2.3.32 on Ubuntu 6.06.1 x86. slapd fails to start.
If anyone could shed some light on why that would be great. Below is
strace output. It looks like it is having some problems with syslog.
Is there anyway to have slapd use some other logging mechanism?
strace output:
root@ssdelta:/var/run/slapd# strace slapd -h 'ldap:/// ldaps:/// ldapi:///'
execve("/usr/sbin/slapd", ["slapd", "-h", "ldap:/// ldaps:///
ldapi:///"], [/* 19 vars */]) = 0
uname({sys="Linux", node="ssdelta", ...}) = 0
brk(0) = 0x8143000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7f73000
.
. (lines omitted for brevity sake)
.
open("/root/ldaprc", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/root/.ldaprc", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("ldaprc", O_RDONLY) = -1 ENOENT (No such file or
directory)
socket(PF_FILE, SOCK_DGRAM, 0) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
connect(3, {sa_family=AF_FILE, path="/dev/log"}, 16) = 0
time([1175874880]) = 1175874880
open("/etc/localtime", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
fstat64(4, {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f70000
read(4, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"...,
4096) = 1017
close(4) = 0
munmap(0xb7f70000, 4096) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
send(3, "<167>Apr 6 08:54:40 slapd[28178"..., 145, MSG_NOSIGNAL
and slapd hangs at this point.
16 years, 1 month
replog not generating
by James Tran
Hi i'm having a problem creating a slave slapd/slurpd
I can't get my master to generate a replog for some reason
Here's my config:
########################################################################
# Schema Settings
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
# General Settings
replogfile /var/lib/slapd/replica.log
replica host=slapd-test.test.com:389
binddn="cn=admin,dc=test,dc=com"
bindmethod=simple credentials=secret
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel 1
modulepath /usr/lib/ldap
moduleload back_bdb
sizelimit 500
tool-threads 1
backend bdb
checkpoint 512 30
database bdb
# Base LDAP address
suffix "dc=test,dc=com"
# Where database is stored
directory "/var/lib/ldap"
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
index objectClass eq
lastmod on
# Include Access List
include /etc/ldap/slapd.access
########################################################################
help appreciated thx
16 years, 1 month
LDAP entry metadata
by Rob Shepherd
Is it possible to make queries to internal data, as well as directory
entry attributes?
I want to query when an attribute was added to the directory, without
having to make an external repository for this info, in another database
or file, or supplementary descriptive
Cheers
Rob
Is there a backend way to make attributes expire?
Thanks
Rob
--
Rob Shepherd BEng PhD | Computer and Network Engineer | CAST Ltd
Technium CAST | LL57 4HJ | http://www.techniumcast.com
rob(a)techniumcast.com | 01248 675024 | 077988 72480
16 years, 1 month
referral connection problem
by Framed Melon
Hi,
I operate three openldap servers, a master and two slaves, all on debian x86.
My problem is that when a connection is made to the referral for an update, the connection is immediately closed.
the problem seems to be there :
Apr 12 15:42:14 master slapd[31190]: connection_read(11): input error=-2 id=0, closing.
but it does not mean anything to me.
The complete connection logs logs (loglevel 4095 !!) :
Apr 12 15:42:14 master slapd[31190]: daemon: activity on 1 descriptors
Apr 12 15:42:14 master slapd[31190]: daemon: new connection on 11
Apr 12 15:42:14 master slapd[31190]: conn=0 fd=11 ACCEPT from IP=2.2.2.2:38841 (IP=0.0.0.0:389)
Apr 12 15:42:14 master slapd[31190]: daemon: added 11r
Apr 12 15:42:14 master slapd[31190]: daemon: activity on:
Apr 12 15:42:14 master slapd[31190]:
Apr 12 15:42:14 master slapd[31190]: daemon: select: listen=6 active_threads=0 tvp=NULL
Apr 12 15:42:14 master slapd[31190]: daemon: select: listen=7 active_threads=0 tvp=NULL
Apr 12 15:42:14 master slapd[31190]: daemon: activity on 1 descriptors
Apr 12 15:42:14 master slapd[31190]: daemon: activity on:
Apr 12 15:42:14 master slapd[31190]: 11r
Apr 12 15:42:14 master slapd[31190]:
Apr 12 15:42:14 master slapd[31190]: daemon: read activity on 11
Apr 12 15:42:14 master slapd[31190]: connection_get(11)
Apr 12 15:42:14 master slapd[31190]: connection_get(11): got connid=0
Apr 12 15:42:14 master slapd[31190]: connection_read(11): checking for input on id=0
Apr 12 15:42:14 master slapd[31190]: ber_get_next on fd 11 failed errno=0 (Success)
Apr 12 15:42:14 master slapd[31190]: connection_read(11): input error=-2 id=0, closing.
Apr 12 15:42:14 master slapd[31190]: connection_closing: readying conn=0 sd=11 for close
Apr 12 15:42:14 master slapd[31190]: connection_close: conn=0 sd=11
Apr 12 15:42:14 master slapd[31190]: daemon: removing 11
Apr 12 15:42:14 master slapd[31190]: conn=0 fd=11 closed
Apr 12 15:42:14 master slapd[31190]: daemon: select: listen=6 active_threads=0 tvp=NULL
Apr 12 15:42:14 master slapd[31190]: daemon: select: listen=7 active_threads=0 tvp=NULL
Apr 12 15:42:14 master slapd[31190]: daemon: activity on 1 descriptors
Apr 12 15:42:14 master slapd[31190]: daemon: select: listen=6 active_threads=0 tvp=NULL
Apr 12 15:42:14 master slapd[31190]: daemon: select: listen=7 active_threads=0 tvp=NULL
Apr 12 15:42:28 master slapd[31190]: daemon: shutdown requested and initiated.
(aliases and IP have been replaced)
Could anyone please help me with that problem ? I couldn't find any clue by searching the web and this mailing list ?
Don't hesitate to ask if you need more details.
Thank you very much
The melon
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
____________________________________________________________________________________
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
16 years, 1 month
[Fwd: [!! SPAM] Re: Syncrepl-Consumer deletes entries]
by Joachim Hergeth (GTS)
Thanks for that answer!
It could really help me, specially because I did not have a working way
to debug the syncrepl process.
I also saw some of those flaws in the config file, but I wanted to
present the file without any changes.
I would like to try a newer version of OpenLDAP, but after running the
SUSE updater I did not get a more recent version. Actually the version
after the update was different to the one before but had the same
version number and only in the start up message of slapd in the log I
saw a different compile time and user. So it seems the same version
compiled some hours later....
I will change the config files according to your suggestions. Debugging
the problem takes some time as it only shows up in the morning when a
large number of users are logging in (in a 20 employee company this
number is still quite small....).
Thanks for your suggestions,
I will follow up as soon as new information is available.
J. Hergeth
-------- Original-Nachricht --------
Betreff: [!! SPAM] Re: Syncrepl-Consumer deletes entries
Datum: Fri, 13 Apr 2007 10:48:26 +0200
Von: Ralf Haferkamp <rhafer(a)suse.de>
An: <openldap-software(a)openldap.org>
Referenzen: <461DF00E.8070809(a)freenet.de>
On Thursday 12 April 2007 10:38, Joachim Hergeth wrote:
> Hello list,
>
> I have an OpenLDAP provider/consumer installation on two SLES10 systems.
> One is set up as a provider LDAP, the second is a consumer LDAP using
> "refreshOnly" synrepl synchronization. The LDAP provides user
> information for a Samba installation.
>
> The initial synchronization of the consumer works as expected. All LDAP
> entries are copied to the consumer directory. But after some time,
> usually when users log in into the Samba running with the provider LDAP,
> nearly 50% of all LDAP entries on the consumer are deleted. This happens
> without any change on the provider LDAP!
I guess that you are testing this with the OpenLDAP Version that shipped
with
SLES10? Would you mind try a newer Version, e.g. the RPMs from
http://software.opensuse.org/download/OpenLDAP/SLE_10/ and check if the
problem is there as well? Note, that we have an update in the queue for
SLES10 to bring it to a more recent version.
Some general comments regarding you configuration (I guess you special
problem
is not related to those):
- The provider config has a line "schemacheck on" this is not a valid
slapd.conf statement (IIRC it is from OpenLDAP 2.0.X times or even older)
- To debug syncrepl Problems it is most helpful to have the loglevel "sync"
enabled. You can to that by just adding "sync" to you "loglevel" line.
- The "backend bdb" statement is superfluous
- The "syncprov-sessionlog 1" begins with whitespaces, might be a copy 'n
paste error in the mail. If it also begins with whitespaces in your
slapd.conf you should remove the whitespace. Otherwise it would be
treated
as the continuation of the previous line (which is wrong). Additionally a
sessionlog of "1" operation doesn't make much sense IMO. I suggest you
either remove that option or set it to a more reasonable value.
- I don't know how large you database is (how many entries) but I should
make
sure that the syncrepl consumer does not hit the sizelimit of your
provider.
As you have not configure any sizelimit the default is used which is 500.
You can adjust the sizelimit with the "sizelimit" or the "limits"
directive
in slapd.conf (see slapd.conf man-page for details).
> Checking the logs I found, that delete-messages can be found in the
> consumers system log.
>
> I do not understand the source of the problem. No entries in the
> provider LDAP are deleted, so no entries should be deleted in the consumer.
Checking if it works with a more recent Version and logfiles with syncrepl
logging enabled might help to clear up the issue.
> To check the installation, I set up a second consumer in a VMWare
> environment. And also in this system, which had been set up from scratch
> and only holds the OpenLDAP-consumer, the entries are deleted at the
> same time when they are deleted in the "real" OpenLDAP consumer system.
>
> When I change an attribute of an entry in the provider LDAP which has
> been deleted from the consumer by this process, like adding a
> description, this change is forwarded to th consumer and the entry
> "reappears" in the LDAP of the consumer.
--
Ralf
16 years, 1 month
deferring operation: pending operations
by Ben Beuchler
I'm getting a ton of these errors in a row, all on the same connection:
Apr 5 11:32:48 swizzle slapd[1626]: connection_input: conn=6232680
deferring operation: pending operations
Apr 5 11:32:51 swizzle slapd[1626]: connection_input: conn=6232680
deferring operation: pending operations
Apr 5 11:32:51 swizzle slapd[1626]: connection_input: conn=6232680
deferring operation: pending operations
Apr 5 11:32:52 swizzle slapd[1626]: connection_input: conn=6232680
deferring operation: pending operations
What does "deferring operation: pending operations" actually indicate?
Thanks!
16 years, 1 month
slapd crashing "randomly?"
by daniel＠ncsu.edu
Hi folk,
I want to start this message by saying, what I'm about to describe is
completely vague and I don't expect to get a solution response. ;)
Basically, I'm out of ideas and am looking for some suggestions as to how
to debug the issue I'm running into.
Starting about half a year ago, slapd started "just dieing" out of the
blue. Not a think in the logs shows up to indicate what might have caused
it. The last query that I see in the logs before a crash always seems to
be nothing special. I don't even see a core dump being generated yet, but
then that may just be because I don't have the proper setup to get a core
dump at this time. We were running the last 2.2 and upgraded to the
latest release of 2.3 to make sure it wasn't an "old version" issue.
Unfortunately, slapd still dies a fair amount on us. It appears to be
fairly unpredictable. I've seen it crash within 1 minute of starting up
slapd (then a subsequent startup 'takes' just fine). I've seen it crash
when there were a number of network issues going on. I've seen it crash
out of the blue when nothing appeared to be going on. I don't really have
the drive space to turn on max debug logging 24/7 until the problem
occurs.
We're thinking about setting up something to watch all of the network
traffic going to one of the boxes until it dies. (assuming we can find
something with the resources to do that)
That all said... since I have nothing solid to present, do you all have
any suggestions of what would be the best way to track down what's going
on? I'm literally out of ideas unless my berkeley db config is somehow
causing the problem or something like that.
I apologize for the vagueness. =/ Any ideas/suggestions?
Daniel
16 years, 1 month
acl problem
by Bernhard D Rohrer
Hi folks
I am trying to get an acl for an address book to work.
the relevant acl statements are:
access to attrs=userPassword,userPKCS12
by dn="cn=admin,dc=graylion,dc=net" write
by anonymous auth
by self write
by * none
access to dn.base=""
by * read
access to dn.regex="cn=([^,]+),ou=personal,ou=contacts,dc=graylion,dc=net$"
by dn="uid=$1,ou=users,dc=graylion,dc=net" write
by dn.regex="cn=admin,dc=graylion,dc=net" read
by users none
access to *
by dn="cn=admin,dc=graylion,dc=net" write
by * read
I have also tried using
by dn.regex="uid=$1,ou=users,dc=graylion,dc=net" write
but in all cases I get (when I try to add something to my personal
address book):
Apr 12 12:59:32 collab slapd[17093]: do_add
Apr 12 12:59:32 collab slapd[17093]: >>> dnPrettyNormal:
<uid=0430d7cb45d65818410b30ff9c9a130a,cn=graylion,ou=personal,ou=contacts,dc=graylion,dc=net>
Apr 12 12:59:32 collab slapd[17093]: <<< dnPrettyNormal:
<uid=0430d7cb45d65818410b30ff9c9a130a,cn=graylion,ou=personal,ou=contacts,dc=graylion,dc=net>,
<uid=0430d7cb45d65818410b30ff9c9a130a,cn=graylion,ou=personal,ou=contacts,dc=graylion,dc=net>
Apr 12 12:59:32 collab slapd[17093]: conn=72 op=2 ADD
dn="uid=0430d7cb45d65818410b30ff9c9a130a,cn=graylion,ou=personal,ou=contacts,dc=graylion,dc=net"
Apr 12 12:59:32 collab slapd[17093]:
bdb_dn2entry("uid=0430d7cb45d65818410b30ff9c9a130a,cn=graylion,ou=personal,ou=contacts,dc=graylion,dc=net")
Apr 12 12:59:32 collab slapd[17093]: => bdb_dn2id(
"uid=0430d7cb45d65818410b30ff9c9a130a,cn=graylion,ou=personal,ou=contacts,dc=graylion,dc=net"
)
Apr 12 12:59:32 collab slapd[17093]: <= bdb_dn2id: get failed:
DB_NOTFOUND: No matching key/data pair found (-30990)
Apr 12 12:59:32 collab slapd[17093]: bdb_referrals: op=104
target="uid=0430d7cb45d65818410b30ff9c9a130a,cn=graylion,ou=personal,ou=contacts,dc=graylion,dc=net"
matched="cn=graylion,ou=personal,ou=contacts,dc=graylion,dc=net"
Apr 12 12:59:32 collab slapd[17093]: oc_check_required entry
(uid=0430d7cb45d65818410b30ff9c9a130a,cn=graylion,ou=personal,ou=contacts,dc=graylion,dc=net),
objectClass "inetOrgPerson"
Apr 12 12:59:32 collab slapd[17093]: oc_check_required entry
(uid=0430d7cb45d65818410b30ff9c9a130a,cn=graylion,ou=personal,ou=contacts,dc=graylion,dc=net),
objectClass "mozillaAbPersonAlpha"
Apr 12 12:59:32 collab slapd[17093]: oc_check_allowed type "uid"
Apr 12 12:59:32 collab slapd[17093]: oc_check_allowed type "objectClass"
Apr 12 12:59:32 collab slapd[17093]: oc_check_allowed type "cn"
Apr 12 12:59:32 collab slapd[17093]: oc_check_allowed type "givenName"
Apr 12 12:59:32 collab slapd[17093]: oc_check_allowed type "sn"
Apr 12 12:59:32 collab slapd[17093]: oc_check_allowed type "displayName"
Apr 12 12:59:32 collab slapd[17093]: oc_check_allowed type "c"
Apr 12 12:59:32 collab slapd[17093]: oc_check_allowed type
"structuralObjectClass"
Apr 12 12:59:32 collab slapd[17093]: oc_check_allowed type "entryUUID"
Apr 12 12:59:32 collab slapd[17093]: oc_check_allowed type "creatorsName"
Apr 12 12:59:32 collab slapd[17093]: oc_check_allowed type
"createTimestamp"
Apr 12 12:59:32 collab slapd[17093]: oc_check_allowed type "entryCSN"
Apr 12 12:59:32 collab slapd[17093]: oc_check_allowed type "modifiersName"
Apr 12 12:59:32 collab slapd[17093]: oc_check_allowed type
"modifyTimestamp"
Apr 12 12:59:32 collab slapd[17093]:
bdb_dn2entry("uid=0430d7cb45d65818410b30ff9c9a130a,cn=graylion,ou=personal,ou=contacts,dc=graylion,dc=net")
Apr 12 12:59:32 collab slapd[17093]: => bdb_dn2id(
"uid=0430d7cb45d65818410b30ff9c9a130a,cn=graylion,ou=personal,ou=contacts,dc=graylion,dc=net"
)
Apr 12 12:59:32 collab slapd[17093]: <= bdb_dn2id: get failed:
DB_NOTFOUND: No matching key/data pair found (-30990)
Apr 12 12:59:32 collab slapd[17093]: => access_allowed: write access to
"cn=graylion,ou=personal,ou=contacts,dc=graylion,dc=net" "children"
requested
Apr 12 12:59:32 collab slapd[17093]: => dn: [2]
Apr 12 12:59:32 collab slapd[17093]: => dnpat: [3]
cn=([^,]+),ou=personal,ou=contacts,dc=graylion,dc=net$ nsub: 1
Apr 12 12:59:32 collab slapd[17093]: => acl_get: [3] matched
Apr 12 12:59:32 collab slapd[17093]: => acl_get: [3] attr children
Apr 12 12:59:32 collab slapd[17093]: => acl_mask: access to entry
"cn=graylion,ou=personal,ou=contacts,dc=graylion,dc=net", attr
"children" requested
Apr 12 12:59:32 collab slapd[17093]: => acl_mask: to all values by
"uid=graylion,ou=users,dc=graylion,dc=net", (=n)
Apr 12 12:59:32 collab slapd[17093]: <= acl_mask: no more <who> clauses,
returning =n (stop)
Apr 12 12:59:32 collab slapd[17093]: => access_allowed: write access
denied by =n
Apr 12 12:59:32 collab slapd[17093]: bdb_add: no write access to parent
Apr 12 12:59:32 collab slapd[17093]: send_ldap_result: conn=72 op=2 p=3
Apr 12 12:59:32 collab slapd[17093]: send_ldap_response: msgid=3 tag=105
err=50
Apr 12 12:59:32 collab slapd[17093]: conn=72 op=2 RESULT tag=105 err=50
text=no write access to parent
now
dnpat: [3] cn=([^,]+),ou=personal,ou=contacts,dc=graylion,dc=net$ nsub: 1
seems to tell me that the regex gets matched correctly but on the other
hand it totally seems to not find
'by dn="uid=$1,ou=users,dc=graylion,dc=net" write'
I seem to be missing something obvious. what is it?
thanks
Bernhard
--
Graylion's Fetish & Fashion Store
Goth and Kinky Boots, Clothing and Jewellery
http://www.graylion.net
16 years, 1 month
Re: OpenLDAP 2.3.35 available
by Howard Chu
OpenLDAP Project wrote:
> OpenLDAP 2.3.35 is now available for download as detailed
> on our download page:
> http://www.openldap.org/software/download/
>
> and should soon be available on all official mirrors:
> ftp://ftp.openldap.org/pub/OpenLDAP/MIRRORS
>
> This is a maintenance release and is made available for
> general use. Users of OpenLDAP Software are encouraged
> to upgrade.
>
> Significant contributors to this release include:
> Quanah Gibson-Mount (Stanford)
> Pierangelo Masarati (SysNet)
> Howard Chu (Symas)
>
> -- The OpenLDAP Project
>
>
> OpenLDAP 2.3.35 Release (2007/04/09)
> Fixed ldapmodify to use correct memory free functions (ITS#4901)
> Fixed slapd acl set minor typo (ITS#4874)
> Fixed slapd entry consistency check in str2entry2 (ITS#4852)
> Fixed slapd ldapi:// credential issue (ITS#4893)
ITS#4893 addresses security implications on HPUX. If you're using
ldapi:// on HPUX 11 it is possible for regular users to bind to the
directory with the credentials of Unix root. Similar exploits may be
possible on AIX 5.1 and older, and Solaris 2.9 and older. This release
disables the insecure credential passing mechanism on these OS versions;
if you were relying on SASL/EXTERNAL authentication with ldapi:// on the
affected platforms that mechanism will no longer work after you install
this release.
We may re-enable these mechanisms in a later update, depending on user
demand. In the meantime, if you're using ldapi:// on these platforms,
you need to stop or upgrade to this release ASAP. Workarounds are still
being tested and will be made available as they become ready.
--
-- 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/
16 years, 1 month
