- openldap-bugs - openldap.org

Re: (ITS#4728) accesslog dont write attributes removing
by hyc＠symas.com 31 Oct '06

31 Oct '06

surnu(a)alkohol.ee wrote: > Full_Name: Andres Kahk > Version: 2.3.28 > OS: Gentoo Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.80.105.102) > > > if i change attribute, everythings are fine i got: > reqMod: > autoReply:= FALSE > entryCSN:= 20061031104835Z#000000#00#000000 > modifiersName:= > modifyTimestamp:= 20061031104835Z > > but if i remove attribute from object then i got: > reqMod: > entryCSN:= 20061031104852Z#000000#00#000000 > modifiersName:= > modifyTimestamp:= 20061031104852Z > > There is no entry to remove. That means the entry is removed in write server, > but it still exists in read server > > If you got any info or patch to fix this and get syncrepl work correctly, please > send it :) It works fine here. Does test043 in the test suite succeed or fail for you? It succeeds here, and it also performs modifications that delete an attribute from an entry. You'll have to provide more information, e.g. your slapd configuration would be a good start. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4728) accesslog dont write attributes removing
by surnu＠alkohol.ee 31 Oct '06

31 Oct '06

Full_Name: Andres Kahk Version: 2.3.28 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.80.105.102) if i change attribute, everythings are fine i got: reqMod: autoReply:= FALSE entryCSN:= 20061031104835Z#000000#00#000000 modifiersName:= modifyTimestamp:= 20061031104835Z but if i remove attribute from object then i got: reqMod: entryCSN:= 20061031104852Z#000000#00#000000 modifiersName:= modifyTimestamp:= 20061031104852Z There is no entry to remove. That means the entry is removed in write server, but it still exists in read server If you got any info or patch to fix this and get syncrepl work correctly, please send it :)

1 0

Re: (ITS#4727) back-perl builds with modular back_perl broken
by quanah＠OpenLDAP.org 31 Oct '06

31 Oct '06

This can be closed, the problem was tracked down to a broken build of libltdl in Debian Sarge 64-bit. sigh. --Quanah -- Quanah Gibson-Mount QA Engineer <http://www.openldap.org>

1 0

Re: (ITS#4725) back-perl not calling bind method
by quanah＠stanford.edu 31 Oct '06

31 Oct '06

--On Monday, October 30, 2006 11:09 AM +0000 mike(a)arishi.com wrote: > Full_Name: Mike Woods > Version: 2.3.28 > OS: FreeBSD 6.1 RELEASE 4 > URL: http://geofront.co.uk/GlueTest.pm > Submission from: (NULL) (207.138.125.56) > > > When using back-perl openldap fails to call the bind methog on > connection, i've tried this with the 2.2 branch and 2.3.28 to the same > effect. > > The failure to call bind essentialy renders back-perl useless. > > I've written and attached a basic "test" module so I can see what > openldap is doing. I am unable to reproduce this issue with 2.3.28. How are you testing this? For me: ldapsearch -LLL -x -h ldap-uat00 -b o=anyorg,c=us -D "uid=quanah,o=anyorg,c=us" -w test tribes:~> And the log clearly shows bind being called: Oct 30 18:38:13 ldap-uat00 slapd[24803]: conn=3 fd=8 ACCEPT from IP=171.64.19.55:41385 (IP=0.0.0.0:389) Oct 30 18:38:13 ldap-uat00 slapd[24803]: conn=3 op=0 BIND dn="uid=quanah,o=anyorg,c=us" method=128 Oct 30 18:38:13 ldap-uat00 Glue: Bind --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4727) back-perl builds with modular back_perl broken
by quanah＠OpenLDAP.org 31 Oct '06

31 Oct '06

Full_Name: Quanah Gibson-Mount Version: 2.3.28 OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) In working to test other bugs, I found that building slapd static allows you to use back-perl, but building slapd with modular back_perl it fails to resolve symbols. Investigation ongoing. This is with perl 5.8.8. --Quanah

1 0

(ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by covener＠gmail.com 31 Oct '06

31 Oct '06

Full_Name: Eric Covener Version: 2.4.3 OS: ppc linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.33.49.251) I'm using 2.4.3 and trying to set SSL client certificates on a per-connection basis. A call to ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, &newctx) fails in my simple test application because ldap_pvt_tls_init hasn't had a chance to call SSLeay_add_ssl_algorithms() yet. I'm not familiar enough w/ openldap to track down how this path occurs, but it seems like the code in tls.c that handles the SSL_CTX_new() in the event of LDAP_OPT_X_TLS_NEWCTX should make sure the initializer has been run by calling ldap_pvt_tls_init() (My simple test app works when I add SSLeay_add_ssl_algorithms() before ldap_set_option). The failure without the call is TLS: could not allocate default ctx (336236705).

1 0

(ITS#4725) back-perl not calling bind method
by mike＠arishi.com 30 Oct '06

30 Oct '06

Full_Name: Mike Woods Version: 2.3.28 OS: FreeBSD 6.1 RELEASE 4 URL: http://geofront.co.uk/GlueTest.pm Submission from: (NULL) (207.138.125.56) When using back-perl openldap fails to call the bind methog on connection, i've tried this with the 2.2 branch and 2.3.28 to the same effect. The failure to call bind essentialy renders back-perl useless. I've written and attached a basic "test" module so I can see what openldap is doing.

1 0

Re: (ITS#4724) Case-insensitive search on unicode strings fail in 2.3.x
by hyc＠symas.com 30 Oct '06

30 Oct '06

katuev(a)dvbank.ru wrote: > Full_Name: Konstantin Katuev > Version: 2.3.28 > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.137.171.26) > > > When using unicode (russian) strings for DNs & attribute values, all sofwtare > that searches thru LDAP directory returns no results when case of letters does > not match. > If case of letters matches, everything is OK. On ASCII strings search works > fine. > Older versions (2.2.x) work good. > I've upload sample data > (ftp://ftp.openldap.org/incoming/case-unicode-test.ldiff) > and simple perl script (ftp://ftp.openldap.org/incoming/case-unicode-test.pl) > that can reproduce this behavior. Script will find 1 record when run against > 2.2.x server and nothing on 2.3.x. Thanks for the report. This is now fixed in CVS HEAD libraries/liblunicode/ucdata/ ucgendat.c 1.40 uctable.h 1.6 -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4724) Case-insensitive search on unicode strings fail in 2.3.x
by katuev＠dvbank.ru 30 Oct '06

30 Oct '06

Full_Name: Konstantin Katuev Version: 2.3.28 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.137.171.26) When using unicode (russian) strings for DNs & attribute values, all sofwtare that searches thru LDAP directory returns no results when case of letters does not match. If case of letters matches, everything is OK. On ASCII strings search works fine. Older versions (2.2.x) work good. I've upload sample data (ftp://ftp.openldap.org/incoming/case-unicode-test.ldiff) and simple perl script (ftp://ftp.openldap.org/incoming/case-unicode-test.pl) that can reproduce this behavior. Script will find 1 record when run against 2.2.x server and nothing on 2.3.x.

1 0

Re: (ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 27 Oct '06

27 Oct '06

> I have no idea what t_delete is but it seems to be dying in your malloc > library. Assuming it's not out of memory, you'll probably need some kind of > malloc debugger (like efence) that can detect heap corruption. Hmm, yeah. Out of memory is unlikely; the core is only a couple hundred MB on a dedicated 2GB box. t_delete is in the depths of the Solaris malloc implementation. I'll ask Sun if they can make anything out of "malloc(35)" causing a SEGV; doesn't exactly sound like documented behavior. You're right that without a memory debugger it's tough to trust any of this. But it's also tough to run a memory debugger in production...they generally slow things down a bit more than I'd like.

1 0

Re: (ITS#4723) SEGV in syncprov search
by hyc＠symas.com 27 Oct '06

27 Oct '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026_2-backtrace.txt > Submission from: (NULL) (68.196.250.61) > > > What a day. I've never had to "_2" dated backtraces ever before... > > Syncprov search, SEGV'd. See "t@13" thread in linked backtrace. I have no idea what t_delete is but it seems to be dying in your malloc library. Assuming it's not out of memory, you'll probably need some kind of malloc debugger (like efence) that can detect heap corruption. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 27 Oct '06

27 Oct '06

Full_Name: Aaron Richton Version: 2.3.28 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026_2-backtrace.txt Submission from: (NULL) (68.196.250.61) What a day. I've never had to "_2" dated backtraces ever before... Syncprov search, SEGV'd. See "t@13" thread in linked backtrace.

1 0

Re: (ITS#4721) thr_stub.c needs do nothing ldap_pvt_thread_pool_tid()
by ando＠sys-net.it 26 Oct '06

26 Oct '06

rk(a)owen.sj.ca.us wrote: > Here is the trivial patch rkowen-061026.patch > Thanks for the fix. It's in HEAD now. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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

(ITS#4722) crash in daemon.c
by quanah＠stanford.edu 26 Oct '06

26 Oct '06

Full_Name: Quanah Gibson-Mount Version: 2.3.27/HEAD OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) With the latest updates, I hit a assert in daemon.c (from HEAD). It appears there is still a possible race condition. The assert hit was: daemon.c:551 assert( SLAP_SOCK_IS_ACTIVE( s )); in slapd_clr_write called from: connection.c:808 slapd_clr_write( sd, 1 ); in connection_closing It looks like the write needs to be cleared before the mutex is unlocked. --Quanah

1 0

(ITS#4721) thr_stub.c needs do nothing ldap_pvt_thread_pool_tid()
by rk＠owen.sj.ca.us 26 Oct '06

26 Oct '06

Full_Name: R.K. Owen Version: Anon-CVS OS: Ubuntu-6.05 Linux URL: ftp://ftp.openldap.org/incoming/rkowen-061026.patch Submission from: (NULL) (66.87.79.68) After trying to "configure --without-threads ...", the build resulted in the following error message: connection.o: In function `connection_operation':/home/owen/rk/nim/openldap/openldap-cvs/servers/slapd/connection.c:1044: undefined reference to `ldap_pvt_thread_pool_tid' connection.o: In function `connection_fake_init':/home/owen/rk/nim/openldap/openldap-cvs/servers/slapd/connection.c:1955: undefined reference to `ldap_pvt_thread_pool_tid' This can be resolved by creating the trivial do-nothing ldap_pvt_thread_pool_tid() function in thr_stub.c Here is the trivial patch rkowen-061026.patch

1 0

Re: (ITS#4720) hdb deadlock
by hyc＠symas.com 26 Oct '06

26 Oct '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026-backtrace.txt > Submission from: (NULL) (68.193.253.190) > > > Solaris 9, BDB 4.2.52+4, OL 2.3.28. > > ldapadd submitted, deadlocked one hdb suffix. Other hdb's remained fine. Fixed now in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4720) hdb deadlock
by hyc＠symas.com 26 Oct '06

26 Oct '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026-backtrace.txt > Submission from: (NULL) (68.193.253.190) > > > Solaris 9, BDB 4.2.52+4, OL 2.3.28. > > ldapadd submitted, deadlocked one hdb suffix. Other hdb's remained fine. > Backtrace of dead slapd at > > https://www.nbcs.rutgers.edu/~richton/richton-20061026-backtrace.txt > > and db_stat -CA of affected database at > > https://www.nbcs.rutgers.edu/~richton/richton-20061026-dbstatCA.txt > > > I have the core file saved if you need any variables out, but this was > production so I had to restart the service/no opportunity for live debugging. For an immediate workaround, turn off syncprov's contextCSN checkpointing. It will only checkpoint during a clean shutdown, but that shouldn't be a problem. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4720) hdb deadlock
by richton＠nbcs.rutgers.edu 26 Oct '06

26 Oct '06

Full_Name: Aaron Richton Version: 2.3.28 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026-backtrace.txt Submission from: (NULL) (68.193.253.190) Solaris 9, BDB 4.2.52+4, OL 2.3.28. ldapadd submitted, deadlocked one hdb suffix. Other hdb's remained fine. Backtrace of dead slapd at https://www.nbcs.rutgers.edu/~richton/richton-20061026-backtrace.txt and db_stat -CA of affected database at https://www.nbcs.rutgers.edu/~richton/richton-20061026-dbstatCA.txt I have the core file saved if you need any variables out, but this was production so I had to restart the service/no opportunity for live debugging.

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by bgmilne＠staff.telkomsa.net 25 Oct '06

25 Oct '06

--nextPart6645744.gz20WZ6vTg Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 24 October 2006 21:00, quanah(a)stanford.edu wrote: > --On Tuesday, October 24, 2006 6:52 PM +0000 Kurt(a)OpenLDAP.org wrote: > > At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: > >> quanah(a)stanford.edu wrote: > >>> It would be nice if you could pass -u and -g options to run as another > >>> user/group so that on systems where OpenLDAP is running as another us= er > >>> or group, the files created by slapadd & slapindex have the correct > >>> ownerships (rather than root, for example). > >> > >> OK for slapadd; for slapindex and other tools, what about using > >> user/group info from the file(s) itself? > > > > Why not just use su(1)? the only reason slapd(8) has -u/-g options > > is because it changes root after some initialization. > > Because some people are brain dead, and because other people set up > application accounts that don't actually have a shell. And some brain-dead OS's have an su without a -s flag ? > It also makes=20 > things more consistent behavior wise. I personally don't have this issue > because I run openldap as root anyway, but I've seen list traffic about > this on more than one occasion, and am seeing people hit it on the debian > openldap list as well. Debian doesn't have a brain-dead su, so 'su -s /bin/bash -c "slapadd ...."'= =20 etc. is feasible. One of my colleagues has a sticker on his monitor which says: Social Engineering Specialist: because there is no patch for stupidity. I haven't seen the need for this myself (but then I don't use back-config, = and=20 my initscript parses slapd.conf to find all database directories, and check= s=20 ownership on all of them). Regards, Buchan =2D-=20 Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592) --nextPart6645744.gz20WZ6vTg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFPwhOrJK6UGDSBKcRApYPAKCecAu2I8CXqMin3Uz9a1MQv8cUEgCfZFPm TLqaOhPzhqr0KV8Y0W7fNR4= =93Bl -----END PGP SIGNATURE----- --nextPart6645744.gz20WZ6vTg--

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by ahasenack＠terra.com.br 24 Oct '06

24 Oct '06

On Tue, Oct 24, 2006 at 12:46:30PM -0700, Quanah Gibson-Mount wrote: > >>Because some people are brain dead, and because other people set up > >>application accounts that don't actually have a shell. It also makes > >>things more consistent behavior wise. I personally don't have this > >>issue because I run openldap as root anyway, but I've seen list traffic > >>about this on more than one occasion, and am seeing people hit it on > >>the debian openldap list as well. > > > >The slapd initscript should/could chown the files whenever slapd is > >(re)started. > > And how would the init script know the locations of X number of databases, > particularly if back-config is used? With back-config things get more complicated, but with slapd.conf it's just a bunch of greps. What about storing this info inside the config file itself (i.e., "slapd_user ldap", "slapd_group ldap")? Chicken and egg problem?

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by quanah＠stanford.edu 24 Oct '06

24 Oct '06

--On Tuesday, October 24, 2006 7:16 PM +0000 ahasenack(a)terra.com.br wrote: > On Tue, Oct 24, 2006 at 07:00:40PM +0000, quanah(a)stanford.edu wrote: >> >> >> --On Tuesday, October 24, 2006 6:52 PM +0000 Kurt(a)OpenLDAP.org wrote: >> >> > At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: >> >> quanah(a)stanford.edu wrote: >> >>> It would be nice if you could pass -u and -g options to run as >> >>> another user/group so that on systems where OpenLDAP is running as >> >>> another user or group, the files created by slapadd & slapindex have >> >>> the correct ownerships (rather than root, for example). >> >>> >> >> OK for slapadd; for slapindex and other tools, what about using >> >> user/group info from the file(s) itself? >> > >> > Why not just use su(1)? the only reason slapd(8) has -u/-g options >> > is because it changes root after some initialization. >> >> Because some people are brain dead, and because other people set up >> application accounts that don't actually have a shell. It also makes >> things more consistent behavior wise. I personally don't have this >> issue because I run openldap as root anyway, but I've seen list traffic >> about this on more than one occasion, and am seeing people hit it on >> the debian openldap list as well. > > The slapd initscript should/could chown the files whenever slapd is > (re)started. And how would the init script know the locations of X number of databases, particularly if back-config is used? --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by ahasenack＠terra.com.br 24 Oct '06

24 Oct '06

On Tue, Oct 24, 2006 at 07:00:40PM +0000, quanah(a)stanford.edu wrote: > > > --On Tuesday, October 24, 2006 6:52 PM +0000 Kurt(a)OpenLDAP.org wrote: > > > At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: > >> quanah(a)stanford.edu wrote: > >>> It would be nice if you could pass -u and -g options to run as another > >>> user/group so that on systems where OpenLDAP is running as another user > >>> or group, the files created by slapadd & slapindex have the correct > >>> ownerships (rather than root, for example). > >>> > >> OK for slapadd; for slapindex and other tools, what about using > >> user/group info from the file(s) itself? > > > > Why not just use su(1)? the only reason slapd(8) has -u/-g options > > is because it changes root after some initialization. > > Because some people are brain dead, and because other people set up > application accounts that don't actually have a shell. It also makes > things more consistent behavior wise. I personally don't have this issue > because I run openldap as root anyway, but I've seen list traffic about > this on more than one occasion, and am seeing people hit it on the debian > openldap list as well. The slapd initscript should/could chown the files whenever slapd is (re)started.

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by hyc＠symas.com 24 Oct '06

24 Oct '06

Kurt(a)OpenLDAP.org wrote: > At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: >> quanah(a)stanford.edu wrote: >>> It would be nice if you could pass -u and -g options to run as another >>> user/group so that on systems where OpenLDAP is running as another user or >>> group, the files created by slapadd & slapindex have the correct ownerships >>> (rather than root, for example). >>> >> OK for slapadd; for slapindex and other tools, what about using >> user/group info from the file(s) itself? > > Why not just use su(1)? the only reason slapd(8) has -u/-g options > is because it changes root after some initialization. Agreed. As for using info from the files themselves - that requires per-backend functions to return the user/group info. Seems like unnecessary effort. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by quanah＠stanford.edu 24 Oct '06

24 Oct '06

--On Tuesday, October 24, 2006 6:52 PM +0000 Kurt(a)OpenLDAP.org wrote: > At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: >> quanah(a)stanford.edu wrote: >>> It would be nice if you could pass -u and -g options to run as another >>> user/group so that on systems where OpenLDAP is running as another user >>> or group, the files created by slapadd & slapindex have the correct >>> ownerships (rather than root, for example). >>> >> OK for slapadd; for slapindex and other tools, what about using >> user/group info from the file(s) itself? > > Why not just use su(1)? the only reason slapd(8) has -u/-g options > is because it changes root after some initialization. Because some people are brain dead, and because other people set up application accounts that don't actually have a shell. It also makes things more consistent behavior wise. I personally don't have this issue because I run openldap as root anyway, but I've seen list traffic about this on more than one occasion, and am seeing people hit it on the debian openldap list as well. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by ando＠sys-net.it 24 Oct '06

24 Oct '06

quanah(a)stanford.edu wrote: >> OK for slapadd; for slapindex and other tools, what about using >> user/group info from the file(s) itself? >> > > What file(s)? Assuming this is a new (and only) index? I guess the __db.* > files? or the id2entry file? Just trying to see specifically where you are > going on this. :) > I mean: if slapadding a brand new db, -u/-g (but -g is already in use by glue stuff) is fine. If slapadding/slapindexing an existing db, get the info from the existing file, if any, or from id2entry.bdb. I'd use a specific option, though, and bail out if no definite answer can be gathered (e.g. -H means use ownership from file, -HH use ownership from file, or from id2entry.bdb if file does not exist). Note that it would make sense to have the -HH behavior as the default... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by Kurt＠OpenLDAP.org 24 Oct '06

24 Oct '06

At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: >quanah(a)stanford.edu wrote: >> It would be nice if you could pass -u and -g options to run as another >> user/group so that on systems where OpenLDAP is running as another user or >> group, the files created by slapadd & slapindex have the correct ownerships >> (rather than root, for example). >> >OK for slapadd; for slapindex and other tools, what about using >user/group info from the file(s) itself? Why not just use su(1)? the only reason slapd(8) has -u/-g options is because it changes root after some initialization.

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by quanah＠stanford.edu 24 Oct '06

24 Oct '06

--On Tuesday, October 24, 2006 8:49 PM +0200 Pierangelo Masarati <ando(a)sys-net.it> wrote: > quanah(a)stanford.edu wrote: >> It would be nice if you could pass -u and -g options to run as another >> user/group so that on systems where OpenLDAP is running as another user >> or group, the files created by slapadd & slapindex have the correct >> ownerships (rather than root, for example). >> > OK for slapadd; for slapindex and other tools, what about using > user/group info from the file(s) itself? What file(s)? Assuming this is a new (and only) index? I guess the __db.* files? or the id2entry file? Just trying to see specifically where you are going on this. :) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by ando＠sys-net.it 24 Oct '06

24 Oct '06

quanah(a)stanford.edu wrote: > It would be nice if you could pass -u and -g options to run as another > user/group so that on systems where OpenLDAP is running as another user or > group, the files created by slapadd & slapindex have the correct ownerships > (rather than root, for example). > OK for slapadd; for slapindex and other tools, what about using user/group info from the file(s) itself? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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

(ITS#4719) Support for running slapadd/slapindex as a user
by quanah＠stanford.edu 24 Oct '06

24 Oct '06

Full_Name: Quanah Gibson-Mount Version: All OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) It would be nice if you could pass -u and -g options to run as another user/group so that on systems where OpenLDAP is running as another user or group, the files created by slapadd & slapindex have the correct ownerships (rather than root, for example).

1 0

Re: (ITS#4718) Option 'network-timeout' missing from slapd-meta man pages
by ando＠sys-net.it 24 Oct '06

24 Oct '06

damonmo(a)gmail.com wrote: > The option 'network-timeout' used to stablish a socket-level timeout on meta > backend is missing on slapd-meta man pages. > Fixed in HEAD/re23. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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

(ITS#4718) Option 'network-timeout' missing from slapd-meta man pages
by damonmo＠gmail.com 24 Oct '06

24 Oct '06

Full_Name: Daniel Montero Motilla Version: 2.3.27 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.203.12) The option 'network-timeout' used to stablish a socket-level timeout on meta backend is missing on slapd-meta man pages.

1 0

Re: (ITS#4696) Assert core in connection.c
by quanah＠stanford.edu 23 Oct '06

23 Oct '06

--On Monday, October 23, 2006 7:13 PM +0000 richton(a)nbcs.rutgers.edu wrote: > I just got bit with this c_writewaiter assert. This is 2.3.27 with patch > for #4708 and #4695. See > https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt for > *c (full backtrace included for good measure). I'll note an important difference between your hitting this issue and my hitting this issue. In my case: (a) I was using connection.c code from HEAD (b) c_writewaiter was zero, and not one. The issue in my case I believe was due to two things: (1) An optimization bug in gcc, because once I rebuilt with gcc 4.1.1, I never got this issue, and (2) A race condition that existed in the HEAD code, that was recently fixed. I no longer experience this problem with the updated HEAD code and gcc 4.1.1 as the compiler. I'd actually say that your report on this issue is a new ITS. ;) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4696) Assert core in connection.c
by Kurt＠OpenLDAP.org 23 Oct '06

23 Oct '06

At 12:13 PM 10/23/2006, richton(a)nbcs.rutgers.edu wrote: >I just got bit with this c_writewaiter assert. This is 2.3.27 with patch >for #4708 and #4695. See >https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt for >*c (full backtrace included for good measure). Try 2.3.28.

1 0

Re: (ITS#4696) Assert core in connection.c
by richton＠nbcs.rutgers.edu 23 Oct '06

23 Oct '06

I just got bit with this c_writewaiter assert. This is 2.3.27 with patch for #4708 and #4695. See https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt for *c (full backtrace included for good measure).

1 0

Re: (ITS#4716) syncrepl - consumer missed some delete
by Paolo.Rossi.con＠h3g.it 23 Oct '06

23 Oct '06

--Apple-Mail-2-751178356 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > Are you patched for ITS#4708 and ITS#4695? Those are my current > "don't try to syncrepl without it" for RE23... No, I was using 2.3.27 "pure" I'll give a try, THX > > Is this refreshAndPersist, or refreshOnly? delta-syncrepl? Do you > use a session log? Maybe just post the relevant config entirely... Right, and sorry It is a syncrepl with RefresAndPersist, with "retry 600 +" The enviroment is the same of ITS#4702 with 1m entry DB Paolo --Apple-Mail-2-751178356 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 <HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = -khtml-line-break: after-white-space; "><DIV><BLOCKQUOTE = type=3D"cite"></BLOCKQUOTE><BR><BLOCKQUOTE type=3D"cite"><DIV = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; ">Are you patched for ITS#4708 and ITS#4695? Those are = my current "don't try to syncrepl without it" for = RE23...</DIV></BLOCKQUOTE><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>No, I was using 2.3.27 = "pure"=A0</DIV><DIV>I'll give a try, THX</DIV><BR><BLOCKQUOTE = type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; = margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; ">Is this refreshAndPersist, or refreshOnly? = delta-syncrepl? Do you use a session log? Maybe just post the relevant = config entirely...</DIV> </BLOCKQUOTE></DIV><BR><DIV>Right, and = sorry</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>It is a = syncrepl with RefresAndPersist, with "retry 600 +"</DIV><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>The enviroment is the same = of ITS#4702 with 1m entry DB</DIV><DIV><SPAN class=3D"Apple-style-span" = style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = rgb(0, 0, 0); font-family: Helvetica; font-size: 15px; font-style: = normal; font-variant: normal; font-weight: normal; letter-spacing: = normal; line-height: normal; text-align: auto; = -khtml-text-decorations-in-effect: none; text-indent: 0px; = -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = white-space: normal; widows: 2; word-spacing: 0px; "><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>Paolo=A0</DIV></SPAN></DIV><B= R></BODY></HTML>= --Apple-Mail-2-751178356--

1 0

Re: (ITS#4717) Efficient handling of response lists in C-API
by Kurt＠OpenLDAP.org 22 Oct '06

22 Oct '06

At 10:14 AM 10/22/2006, ando(a)sys-net.it wrote: >Full_Name: Pierangelo Masarati >Version: HEAD >OS: irrelevant >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (81.72.89.40) >Submitted by: ando > > >In proxies, we occasionally need to mark some response messages as "don't care". > This is slightly different than "abandon", in the sense that, for performance >and band occupation, an abandon would likely get too late to the remote server, >but if the response is not removed from the list that would grow and waste >resources. > >In realistic cases we profiled proxies that spend 50-60% of the CPU time running >the list of messages to check if any of them has been abandoned. > >The proposed fix consists in: > >- keeping abandoned msgid's sorted, so that a bisection algorithm can be used to >check if a msgid has been abandoned > >- add a ldap_int_abandon() call that marks a message as "abandoned" without >actually sending an "abandon" operation. This call is, by now, private >(ldap_int_) since its use in normal clients would make little sense. However, >whenever it does make sense, there's no objection in making the call public >(sort of ldap_abandon_mark()). I rather not name this "abandon" as it doesn't send an Abandon request. Maybe name this "discard" instead. E.g., ldap_int_discard(). >With this change, the overall CPU used to check response list in the very same >test cases dropped to less than 1%. > >p.

1 0

(ITS#4717) Efficient handling of response lists in C-API
by ando＠sys-net.it 22 Oct '06

22 Oct '06

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando In proxies, we occasionally need to mark some response messages as "don't care". This is slightly different than "abandon", in the sense that, for performance and band occupation, an abandon would likely get too late to the remote server, but if the response is not removed from the list that would grow and waste resources. In realistic cases we profiled proxies that spend 50-60% of the CPU time running the list of messages to check if any of them has been abandoned. The proposed fix consists in: - keeping abandoned msgid's sorted, so that a bisection algorithm can be used to check if a msgid has been abandoned - add a ldap_int_abandon() call that marks a message as "abandoned" without actually sending an "abandon" operation. This call is, by now, private (ldap_int_) since its use in normal clients would make little sense. However, whenever it does make sense, there's no objection in making the call public (sort of ldap_abandon_mark()). With this change, the overall CPU used to check response list in the very same test cases dropped to less than 1%. p.

1 0

Re: (ITS#4716) syncrepl - consumer missed some delete
by richton＠nbcs.rutgers.edu 21 Oct '06

21 Oct '06

Are you patched for ITS#4708 and ITS#4695? Those are my current "don't try to syncrepl without it" for RE23... Is this refreshAndPersist, or refreshOnly? delta-syncrepl? Do you use a session log? Maybe just post the relevant config entirely...

1 0

Re: (ITS#4715) proxy retries anonymously
by ando＠sys-net.it 20 Oct '06

20 Oct '06

ashish(a)ratboy.net wrote: > I tried the rebind-as-user approach and that works :) > Will try out the HEAD soon. > Good. I'll rework the documentation accordingly. Cheers, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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

Re: (ITS#4715) proxy retries anonymously
by ashish＠ratboy.net 20 Oct '06

20 Oct '06

> I see that the connection is retried anonymously, which is incorrect. > This issue is known, and it has been fixed in HEAD code by using identity > assertion to retry non-anonymous connections. Another option would be to > set "rebind-as-user", so that user credentials are saved and used to retry > non-anonymous connections. I tried the rebind-as-user approach and that works :) Will try out the HEAD soon. Thank you. Ashish Gawarikar

1 0

Re: (ITS#4715) proxy retries anonymously
by ando＠sys-net.it 20 Oct '06

20 Oct '06

> Either you provide an all-OpenLDAP setup, consisting of proxy, remote > server and operation sequence that clearly shows the issue, so that we can > reproduce and track it, or you should rather investigate what's happening > between the proxy and the remote server, e.g. by providing a tcpdump of > the communications resulting in the error you reported. Sorry, I missed your intermediate posting with a trace of the problem (either I didn't get that message or I simply overlooked it; I've found it right now on the ITS). I see that the connection is retried anonymously, which is incorrect. This issue is known, and it has been fixed in HEAD code by using identity assertion to retry non-anonymous connections. Another option would be to set "rebind-as-user", so that user credentials are saved and used to retry non-anonymous connections. Personally, I'd prefer the idassert approach, but "rebind-as-user" could be useful in case the remote server does not support proxyAuthz, or in case your applications need to use proxyAuthz themselves. Can you try either (or both) approaches? The former requires you to build HEAD (or re24, since last night it was sync'ed with HEAD) code. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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

Re: (ITS#4715) proxy retries anonymously
by ando＠sys-net.it 20 Oct '06

20 Oct '06

> Attaching the relevant slapd.conf I don't think this is by any means relevant. I've run some basic checks, as I said, and nothing at the proxy side seems to be able to cause the error you report. Either you provide an all-OpenLDAP setup, consisting of proxy, remote server and operation sequence that clearly shows the issue, so that we can reproduce and track it, or you should rather investigate what's happening between the proxy and the remote server, e.g. by providing a tcpdump of the communications resulting in the error you reported. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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

Re: (ITS#4702) out-of-memory on huge DB ?
by Paolo.Rossi.con＠h3g.it 19 Oct '06

19 Oct '06

Hi, today I'm finally succeed to export the huge DB with the 64bit build, solaris8/sparc, shminfo_shmmax=536870912 DB_CONFIG whit set_cachesize 0 384000000 1 and using slapcat -f slapd.conf -l producer_dump.ldif FYI, here the final memory allocation and output ldif file: PID RSS VSZ %MEM TIME STIME COMMAND 10294 7491744 7497840 93.1 02:22:27 10:35:37 slapcat ls -la -rw-r--r-- 1 test other 10486259712 Oct 19 13:16 producer_dump.ldif therefore, about 7,5 GB of RAM for ca. 10 GB of ldif Any suggestion, cue? Paolo

1 0

Re: (ITS#4716) syncrepl - consumer missed some delete
by Paolo.Rossi.con＠h3g.it 19 Oct '06

19 Oct '06

I've do some other test: I've shutdown consumer (desynched), and I've do about 10000 random modify on producer, then I've set loglevel -1 on producer (due to find something wrong) and started consumer. After a night, I've restarted the cluster again (producer and consumer) setting a relaxed loglevel on producer, but this time consumer was resynched! Also the deleted DN ignored previously, are now in sych. very strange. Paolo

1 0

Re: (ITS#4715) proxy retries anonymously
by ashish＠ratboy.net 18 Oct '06

18 Oct '06

This is a multi-part message in MIME format. --------------040702090906080801050004 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attaching the relevant slapd.conf --------------040702090906080801050004 Content-Type: text/plain; name="slapd.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="slapd.conf" pidfile /var/run/ldap/slapd.pid argsfile /var/run/ldap/slapd.args # Logging is disabled by default. Enable logging when necessary. # (May significantly affect performance, depending on the level of # server activity.) # To enable logging of access, read, modify, and deletions, # set the loglevel to 256 loglevel none # disallow bind_anon gentlehup on # The sizelimit restriction controls the potential to which the directory # contents may be exploited. Directory queries can only return *this* # many responses. # #sizelimit unlimited sizelimit 200 # Limit the amount of time the server will spend performing # a single query # #timelimit unlimited timelimit 3600 allow bind_v2 ####################################################################### # SASL: ####################################################################### # # SMD is configured with SASL support for most environments. # See the provided slapd.conf man page for additional information. # ## sasl-secprops: # Used to specify Cyrus SASL security properties. The "none" value # by itself causes the default "noanonymous,noplain" to be cleared. sasl-secprops none # ## sasl-host: # Used to specify the fully qualified domain name # used for SASL processing. #sasl-host <fqdn> # ## sasl-realm: # Specify the SASL realm. Default is empty. #sasl-realm <realm> ####################################################################### # schema information ####################################################################### include /usr/local/example/smd-4.0/schema/syntax.defs include /usr/local/example/smd-4.0/schema/core.schema include /usr/local/example/smd-4.0/schema/cosine.schema include /usr/local/example/smd-4.0/schema/inetorgperson.schema include /usr/local/example/smd-4.0/schema/openldap.schema include /usr/local/example/smd-4.0/schema/nis.schema include /usr/local/example/smd-4.0/schema/messageRecipient.schema include /usr/local/example/smd-4.0/schema/smi.schema include /usr/local/example/smd-4.0/schema/sieve.schema include /usr/local/example/smd-4.0/schema/sendmail.schema # All user-customized schema additions must be made in the files # stored under /etc/mail/openldap/schema. include /etc/mail/openldap/schema/custom.schema ####################################################################### # ldap database definitions ####################################################################### database ldap lastmod off suffix "" # The proxy cache function requires that the 'rootdn' parameter is set. # Note that with the password configured below, it cannot be used to bind rootdn "cn=Manager" rootpw {SHA}example-proxycache ###################################################################### # Back-LDAP connection settings ###################################################################### # # Two settings are necessary: # A) Optional TLS settings, used with all ldap:// connections. # This setting must appear before the LDAP URI. # B) LDAP URI list, with hosts separated by spaces # # To require TLS on ldap:// connections, use "tls start" # To try TLS (but not require) on ldap:// connections, use "tls try-start" # # tls start # tls try-start # # This URI example has two LDAP replica servers to try, using ldaps and ldap #uri "ldaps://rep1.domain.com ldaps://rep2.domain.com ldap://rep1.domain.com" uri ldap://ldap.smi.example.com ###################################################################### # Proxycache settings ###################################################################### overlay pcache ########## <database> <max_entries> <numattrsets> <entry_limit> <cc_period> proxycache bdb 10000 3 1 600 proxycachequeries 10000 # Important proxycache notes: # - You may have multiple queries per cache set # - The same query can appear in multiple cache sets # - Only one proxyattrset definition may appear for any cache set # - A given attribute may only appear in one proxyattrset. # - Taking all four conditions above, if multiple queries need access # to the same attribute in their result, the queries must appear # within the same cache set. Also, the attrset for that cache set # must contain a list of all attributes returned from any of the # queries in that set. # - All attributes used in search queries must be defined in the schema. # Sendmail has pre-defined schema including the vendor-specific attributes. # - Additional application and target directory server notes appear # below the cache definitions # - An entry will be cached once for each different search query that # is being used to find it. This means that the actual number of # LDAP entries which may be cached is not the value set in MAX_ENTRIES # above, but instead is this value divided by the number of distinct # LDAP queries being used. # Cache set 0 is used for Flow Control, Authentication, LDAP routing, Proxy lookups proxyattrset 0 DN mail mailRoutingAddress mailHost imapHost popHost objectClass smiAuthDisabled # # Cache set 1 is used for distribution list expansion proxyattrset 1 mgrpRFC822MailMember objectClass # # Cache set 2 is used for Sieve lookups proxyattrset 2 messageStoreUserFilter objectClass # Set_# ttl neg-ttl # # SMD: proxytemplate (|(mailLocalAddress=)(objectClass=)) 0 900 120 proxytemplate (|(mailRoutingAddress=)(objectClass=)) 0 900 120 proxytemplate (&(objectClass=)(mailRoutingAddress=)) 1 900 120 proxytemplate (mailRoutingAddress=) 2 900 120 # # AD: proxytemplate (|(mail=)(proxyAddresses=)(userPrincipalName=)(objectClass=)) 0 900 120 # # Domino: proxytemplate (|(mail=)(uid=)(&(uid=)(mailDomain=))) 0 900 120 # # Novell: proxytemplate (mail=) 0 900 120 # # Netscape/ iPlanet / SunOne / Fedora proxytemplate (|(mail=)(mailAlternateAddress=)(objectClass=)) 0 900 120 proxytemplate (&(objectClass=)(|(mail=)(mailAlternateAddress=))) 1 900 120 proxytemplate (|(mail=)(mailAlternateAddress=)(objectClass=)) 2 900 120 ###################################################################### # BDB Settings # Proxycache uses BDB to store its local information ###################################################################### directory /var/example/ldap/smd-proxycache dbconfig set_cachesize 0 8388608 0 dbconfig set_lg_max 10485760 dbconfig set_flags db_log_autoremove dbconfig set_flags DB_TXN_NOSYNC dbconfig set_lg_bsize 2097152 cachesize 10000 idlcachesize 10100 cachefree 20 dbnosync index queryid,objectClass,mail,mailLocalAddress,mailRoutingAddress eq index uid,mailDomain,userPrincipalName,proxyAddresses,mailAlternateAddress eq ###################################################################### # TLS information, required to enable TLS and LDAPS connections ###################################################################### TLSCipherSuite ALL:!EXP:!LOW:!ADH:@STRENGTH TLSCertificateFile /etc/mail/openldap/ssl/certs/ashish.smi.example.com/default.crt TLSCertificateKeyFile /etc/mail/openldap/ssl/certs/ashish.smi.example.com/default.key --------------040702090906080801050004--

1 0

Re: (ITS#4707) patch: option to bind client socket to an address
by rtsai＠ironport.com 18 Oct '06

18 Oct '06

On Wed, Oct 18, 2006 at 12:23:03PM -0700, Kurt D. Zeilenga wrote: > At 12:12 PM 10/18/2006, hyc(a)symas.com wrote: > >rtsai(a)ironport.com wrote: > >> Full_Name: Robert Tsai > >> Version: 2.3.27 > >> OS: FreeBSD 6.1-RELEASE > >> URL: ftp://ftp.openldap.org/incoming/openldap-2.3.27-bindaddr.patch.txt > >> Submission from: (NULL) (63.251.108.100) > >> > >> This is a patch that provides a mechanism to bind the LDAP client > >> connection to a desired address via ldap_set_option(..., > >> LDAP_OPT_BINDADDR). This call saves some state which is then used > >> by ldap_int_prepare_socket to bind the socket before opening a > >> connection to the LDAP server. > > > >I can't think of any good reason to need such a feature. Can you > >give some background on why anyone would use it? > > I can see a few cases where a client might want to bind the local > address, for instance, to ensure use of a particular network > interface. Yes, this was the need addressed by the patch. The client host has two interfaces to two separate networks. We could have simply configured a host route to the LDAP server, but that would have been too coarse-grained (all traffic, instead of just the LDAP traffic). > However, my concern with patch is one of the approach taken to > accommodate this binding. I'm thinking it might be better to > provide an alternative to ldap_initialize(3) which takes a connected > descriptor instead of a URL. Then calling program can do whatever > it pleases before its used by slapd(8). That would probably work for me. Contributing from the "outside", I was hesitant to propose adding another interface into the library, so I just crammed it into ldap_set_option :). -- Robert Tsai | IronPort Systems | http://www.ironport.com/ | 650-989-2063

1 0

Re: (ITS#4707) patch: option to bind client socket to an address
by Kurt＠OpenLDAP.org 18 Oct '06

18 Oct '06

At 12:12 PM 10/18/2006, hyc(a)symas.com wrote: >rtsai(a)ironport.com wrote: >> Full_Name: Robert Tsai >> Version: 2.3.27 >> OS: FreeBSD 6.1-RELEASE >> URL: ftp://ftp.openldap.org/incoming/openldap-2.3.27-bindaddr.patch.txt >> Submission from: (NULL) (63.251.108.100) >> >> >> This is a patch that provides a mechanism to bind the LDAP client connection to >> a desired address via ldap_set_option(..., LDAP_OPT_BINDADDR). This call saves >> some state which is then used by ldap_int_prepare_socket to bind the socket >> before opening a connection to the LDAP server. > >I can't think of any good reason to need such a feature. Can you give >some background on why anyone would use it? I can see a few cases where a client might want to bind the local address, for instance, to ensure use of a particular network interface. However, my concern with patch is one of the approach taken to accommodate this binding. I'm thinking it might be better to provide an alternative to ldap_initialize(3) which takes a connected descriptor instead of a URL. Then calling program can do whatever it pleases before its used by slapd(8). -- Kurt

1 0

Re: (ITS#4715) proxy retries anonymously
by ando＠sys-net.it 18 Oct '06

18 Oct '06

hyc(a)symas.com wrote: > The proxycache has nothing to do with the connections to the remote > server. That's handled by the back-ldap or whatever backend you're > using. Since you haven't provided any of the relevant config info from > your slapd.conf there's no way to tell what you're doing there. > > In fact your log shows that a Bind was performed on the retry, but it > was done anonymously. So it may be something as simple as a missing > config keyword (like rebind-as-user in back-ldap). Or it may possibly be > related to a bug in back-ldap's retry handling as Pierangelo mentioned > in his reply to you. > > There is no proxycache bug here. At the moment, without further details, > it doesn't seem there's any OpenLDAP software bug here at all. > I've made a couple of checks with re23 making connections timeout at the remote server's side, and retry works as expected. As far as I remember, the retry issues I mentioned were essentially related to non-search ops, or to ops involving identity assertion. Unless the poster of the issue can provide a clear way to reproduce his problem, there seems to be no evidence of a bug neither in proxy cache nor in back-ldap. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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

Re: (ITS#4707) patch: option to bind client socket to an address
by hyc＠symas.com 18 Oct '06

18 Oct '06

rtsai(a)ironport.com wrote: > Full_Name: Robert Tsai > Version: 2.3.27 > OS: FreeBSD 6.1-RELEASE > URL: ftp://ftp.openldap.org/incoming/openldap-2.3.27-bindaddr.patch.txt > Submission from: (NULL) (63.251.108.100) > > > This is a patch that provides a mechanism to bind the LDAP client connection to > a desired address via ldap_set_option(..., LDAP_OPT_BINDADDR). This call saves > some state which is then used by ldap_int_prepare_socket to bind the socket > before opening a connection to the LDAP server. I can't think of any good reason to need such a feature. Can you give some background on why anyone would use it? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4715) proxy retries anonymously
by hyc＠symas.com 18 Oct '06

18 Oct '06

The proxycache has nothing to do with the connections to the remote server. That's handled by the back-ldap or whatever backend you're using. Since you haven't provided any of the relevant config info from your slapd.conf there's no way to tell what you're doing there. In fact your log shows that a Bind was performed on the retry, but it was done anonymously. So it may be something as simple as a missing config keyword (like rebind-as-user in back-ldap). Or it may possibly be related to a bug in back-ldap's retry handling as Pierangelo mentioned in his reply to you. There is no proxycache bug here. At the moment, without further details, it doesn't seem there's any OpenLDAP software bug here at all. Ashish Gawarikar wrote: > > ------------------------------------------------------------------------ > > The problem is that the connection to the backend server drops and the proxy > cache has to reestablish it. Doing this, it doesn't do a BIND again and thus > the query is executed with anonymous privileges and fails. See log file from > the backend server: -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs