- openldap-bugs - openldap.org

Fwd: Solaris 10 test000 root dse bus error (ITS#5140)
by james.hartley＠gmail.com 20 Sep '07

20 Sep '07

------=_Part_32258_11773747.1190318929506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ---------- Forwarded message ---------- From: James Hartley <james.hartley(a)gmail.com> Date: Sep 20, 2007 11:38 AM Subject: Re: Solaris 10 test000 root dse bus error (ITS#5140) To: Quanah Gibson-Mount <quanah(a)zimbra.com> ok I used the 2.4 beta wth the same result on tests. here is the configure command and the output of make test. Not sure if I should back up to Berkeley 4.5 and openldap2.3.38... Since that will require rebuilding the DB then SASL then LDAP... do you know someone that might have build and tested openldap for solaris 10 that I can confer with directly. here is the output env LD_LIBRARY_PATH="/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.6/lib:/usr/lib/sasl2" LDFLAGS="-L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.6/lib -L/usr/lib/sasl2 -R/usr/local/lib -R/usr/local/ssl/lib -R/usr/local/BerkeleyDB.4.6/lib -R/usr/lib/sasl2" CPPFLAGS="-I/usr/local/include -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.6/include -I/usr/local/include/sasl" ./configure --enable-bdb --enable-crypt --with-tls --with-cyrus-sasl make[1]: Entering directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.4.5beta /tests' make[2]: Entering directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.4.5beta/tests' Initiating LDAP tests for BDB... ./run: ./schema: does not exist Running ./scripts/all... >>>>> Executing all LDAP tests for bdb >>>>> Starting test000-rootdse ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... 24854 Bus Error - core dumped Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ./scripts/test000-rootdse: kill: no such process ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>> Test failed >>>>> ./scripts/test000-rootdse failed (exit 255) make[2]: *** [bdb-yes] Error 255 make[2]: Leaving directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap- 2.4.5beta /tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.4.5beta /tests' make: *** [test] Error 2 --(hartleyj@sunv420)-(~/sunv420ldapconstruction_latest/openldap- 2.4.5beta )-- P.S. I have some scripts that you might be interested in the maintain usr/local and help construct packages for solaris... On 9/20/07, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > > --On Thursday, September 20, 2007 3:54 PM +0000 james.hartley(a)gmail.com > wrote: > > > ------=_Part_30794_27537250.1190303647870 > > Content-Type: text/plain; charset=ISO-8859-1 > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > > > > Humm no real help here!! no obvious errors. here is the last few lines > > of the slapd.1.conf file. in tests. > > > > Do you have any other Ideas > > Use a supported version of BDB. OpenLDAP 2.3 series works with BDB 4.2, > 4.4, and 4.5. OpenLDAP 2.4 series works with BDB 4.2, 4.4, 4.5, and 4.6. > Since you built 2.3 against 4.6, you are trying to do something that is > not > supported. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > ------=_Part_32258_11773747.1190318929506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ---------- Forwarded message ---------- From: James Hartley <<a href="mailto:james.hartley@gmail.com">james.hartley(a)gmail.com</a>> Date: Sep 20, 2007 11:38 AM Subject: Re: Solaris 10 test000 root dse bus error (ITS#5140) To: Quanah Gibson-Mount <<a href="mailto:quanah@zimbra.com">quanah(a)zimbra.com</a>> ok I used the 2.4 beta wth the same result on tests.   here is the configure command and the output of make test.   Not sure if I should back up to Berkeley 4.5 and openldap2.3.38...  Since that will require rebuilding the DB then SASL then LDAP... do you know someone that might have build and tested openldap for solaris 10 that I can confer with directly. here is the output env LD_LIBRARY_PATH="/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.6/lib:/usr/lib/sasl2" LDFLAGS="-L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.6/lib -L/usr/lib/sasl2 -R/usr/local/lib -R/usr/local/ssl/lib -R/usr/local/BerkeleyDB.4.6/lib -R/usr/lib/sasl2" CPPFLAGS="-I/usr/local/include -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.6/include -I/usr/local/include/sasl" ./configure --enable-bdb --enable-crypt --with-tls --with-cyrus-sasl make[1]: Entering directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.4.5beta/tests' make[2]: Entering directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap- 2.4.5beta /tests' Initiating LDAP tests for BDB... ./run: ./schema: does not exist Running ./scripts/all... >>>>> Executing all LDAP tests for bdb >>>>> Starting test000-rootdse ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... 24854 Bus Error - core dumped Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ./scripts/test000-rootdse: kill: no such process ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>> Test failed >>>>> ./scripts/test000-rootdse failed (exit 255) make[2]: *** [bdb-yes] Error 255 make[2]: Leaving directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap- 2.4.5beta/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.4.5beta/tests' make: *** [test] Error 2 --(hartleyj@sunv420)-(~/sunv420ldapconstruction_latest/openldap- 2.4.5beta)-- P.S.  I have some scripts that you might be interested in the maintain usr/local and help construct packages for solaris... <div>On 9/20/07, Quanah Gibson-Mount <<a href="mailto:quanah@zimbra.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">quanah(a)zimbra.com</a>> wrote:<div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> --On Thursday, September 20, 2007 3:54 PM +0000 <a href="mailto:james.hartley@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">james.hartley(a)gmail.com</a> wrote: > ------=_Part_30794_27537250.1190303647870 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > Humm no real help here!!  no obvious errors.  here is the last few lines > of the slapd.1.conf file. in tests. > > Do you have any other Ideas Use a supported version of BDB.  OpenLDAP 2.3 series works with BDB 4.2, 4.4, and 4.5.  OpenLDAP 2.4 series works with BDB 4.2, 4.4, 4.5, and 4.6. Since you built 2.3 against 4.6, you are trying to do something that is not supported. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra ::  the leader in open source messaging and collaboration </blockquote></div></div> ------=_Part_32258_11773747.1190318929506--

1 0

Re: (ITS#5149) config.status aborts with error
by hyc＠symas.com 20 Sep '07

20 Sep '07

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.186.237) > > > Hi config.status aborts with error, thus portable.h and other files are not > generated by configure You need to use "cvs upd -d " to get the back-sock directory. No bug here, this ITS will be closed. > config.status:842: creating servers/slapd/back-sock/Makefile > config.status:902: error: cannot find input file: > servers/slapd/back-sock/Makefile.in > .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.--.-.- > > -Dieter > > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5149) config.status aborts with error
by dieter＠dkluenter.de 20 Sep '07

20 Sep '07

Full_Name: Dieter Kluenter Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.186.237) Hi config.status aborts with error, thus portable.h and other files are not generated by configure config.log .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- config.status:842: creating Makefile config.status:842: creating doc/Makefile config.status:842: creating doc/man/Makefile config.status:842: creating doc/man/man1/Makefile config.status:842: creating doc/man/man3/Makefile config.status:842: creating doc/man/man5/Makefile config.status:842: creating doc/man/man8/Makefile config.status:842: creating clients/Makefile config.status:842: creating clients/tools/Makefile config.status:842: creating include/Makefile config.status:842: creating libraries/Makefile config.status:842: creating libraries/liblber/Makefile config.status:842: creating libraries/libldap/Makefile config.status:842: creating libraries/libldap_r/Makefile config.status:842: creating libraries/liblunicode/Makefile config.status:842: creating libraries/liblutil/Makefile config.status:842: creating libraries/librewrite/Makefile config.status:842: creating servers/Makefile config.status:842: creating servers/slapd/Makefile config.status:842: creating servers/slapd/back-bdb/Makefile config.status:842: creating servers/slapd/back-dnssrv/Makefile config.status:842: creating servers/slapd/back-hdb/Makefile config.status:842: creating servers/slapd/back-ldap/Makefile config.status:842: creating servers/slapd/back-ldif/Makefile config.status:842: creating servers/slapd/back-meta/Makefile config.status:842: creating servers/slapd/back-monitor/Makefile config.status:842: creating servers/slapd/back-null/Makefile config.status:842: creating servers/slapd/back-passwd/Makefile config.status:842: creating servers/slapd/back-perl/Makefile config.status:842: creating servers/slapd/back-relay/Makefile config.status:842: creating servers/slapd/back-shell/Makefile config.status:842: creating servers/slapd/back-sock/Makefile config.status:902: error: cannot find input file: servers/slapd/back-sock/Makefile.in .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.--.-.- -Dieter

1 0

(ITS#5148) Segmentation Fault
by Russell.Mosemann＠cune.edu 20 Sep '07

20 Sep '07

quanah(a)zimbra.com said: > OpenLDAP 2.3 does not support BDB 4.6. Thank you. That answers my question. This ticket may be closed. -- Russell Mosemann, Ph.D. Associate Professor of Computer Science

1 0

Re: Solaris 10 test000 root dse bus error (ITS#5140)
by hyc＠symas.com 20 Sep '07

20 Sep '07

james.hartley(a)gmail.com wrote: > ------=_Part_30794_27537250.1190303647870 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > Humm no real help here!! no obvious errors. here is the last few lines of > the slapd.1.conf file. in tests. > > Do you have any other Ideas Don't send HTML email to the ITS. You didn't specify which version of BDB 4.6 you're using, but I suspect your answer is here: http://www.openldap.org/lists/openldap-software/200708/msg00344.html -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Solaris 10 test000 root dse bus error (ITS#5140)
by quanah＠zimbra.com 20 Sep '07

20 Sep '07

--On Thursday, September 20, 2007 3:54 PM +0000 james.hartley(a)gmail.com wrote: > ------=_Part_30794_27537250.1190303647870 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > Humm no real help here!! no obvious errors. here is the last few lines > of the slapd.1.conf file. in tests. > > Do you have any other Ideas Use a supported version of BDB. OpenLDAP 2.3 series works with BDB 4.2, 4.4, and 4.5. OpenLDAP 2.4 series works with BDB 4.2, 4.4, 4.5, and 4.6. Since you built 2.3 against 4.6, you are trying to do something that is not supported. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5148) Segmentation Fault
by hyc＠symas.com 20 Sep '07

20 Sep '07

Russell.Mosemann(a)cune.edu wrote: > Full_Name: Russell Mosemann > Version: 2.3.38 > OS: Linux 2.6.19.1 > URL: > Submission from: (NULL) (192.160.64.49) > > > Debian 3.1 > bdb 4.6.19 > OpenLDAP 2.3.38 > configure --disable-ipv6 --without-cyrus-sasl --without-tls --enable-crypt \ > --enable-wrappers --enable-hdb > gcc version 4.2.1 (Debian 4.2.1-3) > > slapcat and slapadd function without errors when loading or exporting the > database. The following segmentation fault happens on the first query to slapd. This is expected. http://www.openldap.org/lists/openldap-software/200708/msg00344.html BerkeleyDB 4.6.19 is not compatible with OpenLDAP 2.3. Use OpenLDAP 2.4 if you want to use BDB 4.6.19, or use BDB 4.6.3 or older if you want to stay on OpenLDAP 2.3. This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5148) Segmentation Fault
by quanah＠zimbra.com 20 Sep '07

20 Sep '07

--On Thursday, September 20, 2007 3:44 PM +0000 Russell.Mosemann(a)cune.edu wrote: > Full_Name: Russell Mosemann > Version: 2.3.38 > OS: Linux 2.6.19.1 > URL: > Submission from: (NULL) (192.160.64.49) > > > Debian 3.1 > bdb 4.6.19 > OpenLDAP 2.3.38 OpenLDAP 2.3 does not support BDB 4.6. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: Solaris 10 test000 root dse bus error (ITS#5140)
by james.hartley＠gmail.com 20 Sep '07

20 Sep '07

------=_Part_30794_27537250.1190303647870 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Humm no real help here!! no obvious errors. here is the last few lines of the slapd.1.conf file. in tests. Do you have any other Ideas slapd startup: initiated. backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=include{0}" config_build_entry: "cn=include{1}" config_build_entry: "cn=include{2}" config_build_entry: "cn=include{3}" config_build_entry: "cn=include{4}" config_build_entry: "cn=include{5}" config_build_entry: "cn=include{6}" config_build_entry: "cn=include{7}" config_build_entry: "cn=include{8}" config_build_entry: "cn=include{9}" config_build_entry: "cn=schema" config_build_entry: "cn={0}core" config_build_entry: "cn={1}cosine" config_build_entry: "cn={2}corba" config_build_entry: "cn={3}java" config_build_entry: "cn={4}inetorgperson" config_build_entry: "cn={5}misc" config_build_entry: "cn={6}nis" config_build_entry: "cn={7}openldap" config_build_entry: "cn={8}dyngroup" config_build_entry: "cn={9}ppolicy" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" config_build_entry: "olcDatabase={1}bdb" config_build_entry: "olcDatabase={2}monitor" backend_startup_one: starting "o=OpenLDAP Project,l=Internet" bdb_db_open: o=OpenLDAP Project,l=Internet bdb_db_open: Warning - No DB_CONFIG file found in directory ./testrun/db.1.a: (2) Expect poor performance for suffix o=OpenLDAP Project,l=Internet. bdb_db_open: dbenv_open(./testrun/db.1.a) On 9/20/07, Gavin Henry <openldap-its(a)openldap.org> wrote: > > > Full_Name: james hartley > > Version: 2.3.27 > > OS: Solaris 10 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (204.140.46.100) > > > > > > built with gcc 3.4.6 using the following configure command. > > > > $env > LD_LIBRARY_PATH="/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.6/lib:/usr/lib/sasl2" > > LDFLAGS="-L/usr/local/lib -L/usr/local/ssl/lib > -L/usr/local/BerkeleyDB.4.6/lib > > \-L/usr/lib/sasl2 -R/usr/local/lib -R/usr/local/ssl/lib > > -R/usr/local/BerkeleyDB.4.6/lib -R/usr/lib/sasl2" > CPPFLAGS="-I/usr/local/include > > -I/usr/local/ssl/include \ -I/usr/local/BerkeleyDB.4.6/include > > -I/usr/local/include/sasl" ./configure --enable-bdb --enable-crypt > --with-tls > > --with-cyrus-sasl > > > > compile looks good... However I get the following errors during make > test... > > I could not find anything in the archives that pointed to a > solution. Only > > others asking the same question for earlier versions of solaris ,, > specifically > > solaris 8. > > > > Can anyone give me a good lead in how to proceed. BTW I have run tests > before > I > > installed the software and after I installed the software... After the > first > > test I installed the software anyway. > > > > Thanks for any help. > > > > cd tests; make test > > make[1]: Entering directory > > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37 > /tests' > > make[2]: Entering directory > > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37 > /tests' > > Initiating LDAP tests for BDB... > > Cleaning up test run directory leftover from previous run. > > Running ./scripts/all... > >>>>>> Executing all LDAP tests for bdb > >>>>>> Starting test000-rootdse ... > > running defines.sh > > Starting slapd on TCP/IP port 9011... > > Using ldapsearch to retrieve the root DSE... > > Waiting 5 seconds for slapd to start... > > 11851 Bus Error - core dumped > > Waiting 5 seconds for slapd to start... > > Waiting 5 seconds for slapd to start... > > Waiting 5 seconds for slapd to start... > > Waiting 5 seconds for slapd to start... > > Waiting 5 seconds for slapd to start... > > ./scripts/test000-rootdse: kill: no such process > > ldap_bind: Can't contact LDAP server (-1) > >>>>>> Test failed > >>>>>> ./scripts/test000-rootdse failed (exit 1) > > make[2]: *** [bdb-yes] Error 1 > > make[2]: Leaving directory > > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37 > /tests' > > make[1]: *** [test] Error 2 > > make[1]: Leaving directory > > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37 > /tests' > > make: *** [test] Error 2 > > > > After running make test, look at the files in the "testrun" folder. That > will > tell you the reasons why it failed. > ------=_Part_30794_27537250.1190303647870 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Humm no real help here!!  no obvious errors.  here is the last few lines of the slapd.1.conf file. in tests.  Do you have any other Ideas slapd startup: initiated. backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=include{0}" config_build_entry: "cn=include{1}" config_build_entry: "cn=include{2}" config_build_entry: "cn=include{3}" config_build_entry: "cn=include{4}" config_build_entry: "cn=include{5}" config_build_entry: "cn=include{6}" config_build_entry: "cn=include{7}" config_build_entry: "cn=include{8}" config_build_entry: "cn=include{9}" config_build_entry: "cn=schema" config_build_entry: "cn={0}core" config_build_entry: "cn={1}cosine" config_build_entry: "cn={2}corba" config_build_entry: "cn={3}java" config_build_entry: "cn={4}inetorgperson" config_build_entry: "cn={5}misc" config_build_entry: "cn={6}nis" config_build_entry: "cn={7}openldap" config_build_entry: "cn={8}dyngroup" config_build_entry: "cn={9}ppolicy" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" config_build_entry: "olcDatabase={1}bdb" config_build_entry: "olcDatabase={2}monitor" backend_startup_one: starting "o=OpenLDAP Project,l=Internet" bdb_db_open: o=OpenLDAP Project,l=Internet bdb_db_open: Warning - No DB_CONFIG file found in directory ./testrun/db.1.a: (2) Expect poor performance for suffix o=OpenLDAP Project,l=Internet. bdb_db_open: dbenv_open(./testrun/db.1.a) <div>On 9/20/07, Gavin Henry <<a href="mailto:openldap-its@openldap.org"> openldap-its(a)openldap.org</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Full_Name: james hartley > Version: 2.3.27 > OS: Solaris 10 > URL: <a href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> > Submission from: (NULL) (<a href="http://204.140.46.100">204.140.46.100</a>) > > > built with gcc 3.4.6 using the following configure command. > > $env LD_LIBRARY_PATH="/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.6/lib:/usr/lib/sasl2" > LDFLAGS="-L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.6/lib > \-L/usr/lib/sasl2 -R/usr/local/lib -R/usr/local/ssl/lib > -R/usr/local/BerkeleyDB.4.6/lib -R/usr/lib/sasl2" CPPFLAGS="-I/usr/local/include > -I/usr/local/ssl/include \ -I/usr/local/BerkeleyDB.4.6/include > -I/usr/local/include/sasl" ./configure --enable-bdb --enable-crypt --with-tls > --with-cyrus-sasl > > compile looks good... However I get the following errors during make test... > I could not find anything in the archives that pointed to a solution.  Only > others asking the same question for earlier versions of solaris ,, specifically > solaris 8. > > Can anyone give me a good lead in how to proceed. BTW I have run tests before I > installed the software and after I installed the software... After the first > test I installed the software anyway. > > Thanks for any help. > > cd tests; make test > make[1]: Entering directory > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap- 2.3.37/tests' > make[2]: Entering directory > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37/tests' > Initiating LDAP tests for BDB... > Cleaning up test run directory leftover from previous run. > Running ./scripts/all... >>>>>> Executing all LDAP tests for bdb >>>>>> Starting test000-rootdse ... > running defines.sh > Starting slapd on TCP/IP port 9011... > Using ldapsearch to retrieve the root DSE... > Waiting 5 seconds for slapd to start... > 11851 Bus Error - core dumped > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > ./scripts/test000-rootdse: kill: no such process > ldap_bind: Can't contact LDAP server (-1) >>>>>> Test failed >>>>>> ./scripts/test000-rootdse failed (exit 1) > make[2]: *** [bdb-yes] Error 1 > make[2]: Leaving directory > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap- 2.3.37/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37/tests' > make: *** [test] Error 2 > After running make test, look at the files in the "testrun" folder. That will tell you the reasons why it failed. </blockquote></div> ------=_Part_30794_27537250.1190303647870--

1 0

(ITS#5148) Segmentation Fault
by Russell.Mosemann＠cune.edu 20 Sep '07

20 Sep '07

Full_Name: Russell Mosemann Version: 2.3.38 OS: Linux 2.6.19.1 URL: Submission from: (NULL) (192.160.64.49) Debian 3.1 bdb 4.6.19 OpenLDAP 2.3.38 configure --disable-ipv6 --without-cyrus-sasl --without-tls --enable-crypt \ --enable-wrappers --enable-hdb gcc version 4.2.1 (Debian 4.2.1-3) slapcat and slapadd function without errors when loading or exporting the database. The following segmentation fault happens on the first query to slapd. gdb slapd (gdb) run -d 255 ... >>> dnPrettyNormal: <qmailgid=306,ou=accounts,o=cune> => ldap_bv2dn(qmailgid=306,ou=accounts,o=cune,0) <= ldap_bv2dn(qmailgid=306,ou=accounts,o=cune)=0 => ldap_dn2bv(272) <= ldap_dn2bv(qmailGID=306,ou=accounts,o=cune)=0 => ldap_dn2bv(272) <= ldap_dn2bv(qmailGID=306,ou=accounts,o=cune)=0 <<< dnPrettyNormal: <qmailGID=306,ou=accounts,o=cune>, <qmailGID=306,ou=accounts ,o=cune> do_bind: version=3 dn="qmailGID=306,ou=accounts,o=cune" method=128 ==> hdb_bind: dn: qmailGID=306,ou=accounts,o=cune bdb_dn2entry("qmailGID=306,ou=accounts,o=cune") Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1561621616 (LWP 27395)] 0xb7f0a471 in __lock_get_internal () from /usr/lib/libdb-4.6.so (gdb) bt full #0 0xb7f0a471 in __lock_get_internal () from /usr/lib/libdb-4.6.so No symbol table info available. #1 0xb7f0afaf in __lock_get () from /usr/lib/libdb-4.6.so No symbol table info available. #2 0xb7f3caf5 in __db_lget () from /usr/lib/libdb-4.6.so No symbol table info available. #3 0xb7eafc67 in __bam_get_root () from /usr/lib/libdb-4.6.so No symbol table info available. #4 0xb7eb003e in __bam_search () from /usr/lib/libdb-4.6.so No symbol table info available. #5 0xb7ea0b0a in __bamc_init () from /usr/lib/libdb-4.6.so No symbol table info available. #6 0xb7ea1b9e in __bamc_init () from /usr/lib/libdb-4.6.so No symbol table info available. #7 0xb7f2eb9d in __dbc_get () from /usr/lib/libdb-4.6.so No symbol table info available. #8 0xb7f37d6b in __dbc_get_pp () from /usr/lib/libdb-4.6.so No symbol table info available. #9 0x080f2332 in hdb_id2entry (be=0x8230d58, tid=0x0, locker=7, id=136227432, e=0xa2eb8018) at id2entry.c:125 bdb = <value optimized out> db = (DB *) 0x0 key = {data = 0xa2eb7f74, size = 4, ulen = 0, dlen = 0, doff = 0, app_data = 0x0, flags = 4} data = {data = 0x0, size = 0, ulen = 0, dlen = 0, doff = 0, app_data = 0x0, flags = 8} cursor = (DBC *) 0xa333cabc bv = {bv_len = 136515576, bv_val = 0x1 <Address 0x1 out of bounds>} rc = -1208315332 nid = 2517172224 #10 0x080ea2ba in hdb_cache_find_id (op=0x81ecc80, tid=0x0, id=2454, eip=0xa2eb8058, islocked=1, locker=7, lock=0xa2eb80a4) at cache.c:760 bdb = (struct bdb_info *) 0x8230e60 ep = (Entry *) 0x0 rc = 0 load = 1 ei = {bei_parent = 0x0, bei_id = 2454, bei_lockpad = 0 '\0', bei_state = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_rdn = {bv_len = 0, bv_val = 0x0}, bei_modrdns = 0, bei_ckids = 0, bei_dkids = 0, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = { __next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, bei_lrunext = 0x0, bei_lruprev = 0x0} #11 0x080ed857 in hdb_dn2entry (op=0x81ecc80, tid=0x0, dn=0x81ecc9c, e=0xa2eb80b8, matched=1, locker=7, lock=0xa2eb80a4) at dn2entry.c:68 ei = (EntryInfo *) 0x81ed428 rc = 0 ---Type <return> to continue, or q <return> to quit--- rc2 = <value optimized out> #12 0x080e821f in hdb_bind (op=0x81ecc80, rs=0xa2eb81c4) at bind.c:68 e = <value optimized out> a = <value optimized out> ei = <value optimized out> password = (AttributeDescription *) 0x81c88d8 locker = 7 lock = {off = 134060, ndx = 905, gen = 13, mode = DB_LOCK_WRITE} __PRETTY_FUNCTION__ = "hdb_bind" #13 0x08078cf9 in fe_op_bind (op=0x81ecc80, rs=0xa2eb81c4) at bind.c:405 mech = {bv_len = 6, bv_val = 0x813b828 "SIMPLE"} bd = (BackendDB *) 0x818cee0 #14 0x08079ab1 in do_bind (op=0x81ecc80, rs=0xa2eb81c4) at bind.c:200 ber = (BerElement *) 0x81ebd70 version = 3 method = 128 mech = {bv_len = 0, bv_val = 0x0} dn = {bv_len = 31, bv_val = 0x81ecc42 "qmailgid=306,ou=accounts,o=cune"} tag = <value optimized out> be = (Backend *) 0x0 #15 0x0805de3d in connection_operation (ctx=0xa2eb8248, arg_v=0x81ecc80) at connection.c:1133 curelm = <value optimized out> rc = <value optimized out> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} tag = 96 opidx = SLAP_OP_BIND conn = (Connection *) 0xa32b9f80 memctx = (void *) 0x81ece78 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #16 0x08110662 in ldap_int_thread_pool_wrapper (xpool=0x81c9c28) at tpool.c:478 ctx = (ldap_int_thread_ctx_t *) 0x81ec650 ltc_key = {{ltk_key = 0x80a2830, ltk_data = 0x81ece78, ltk_free = 0x80a23a0 <slap_sl_mem_destroy>}, {ltk_key = 0x81eaa68, ltk_data = 0x7, ltk_free = 0x80e8be0 <bdb_locker_id_free>}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 30 times>} tid = 2733345680 i = 680 hash = <value optimized out> #17 0xb7e212d3 in start_thread () from /lib/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- No symbol table info available. #18 0xb7da72fe in clone () from /lib/libc.so.6 No symbol table info available.

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by rhafer＠suse.de 20 Sep '07

20 Sep '07

Please note that test020 currently fails in HEAD sometime. I think this depends on the order in which the results for queries that hit the sizelimit are returned. Testout put is: ------------------ ... ... Successfully verified answerability Filtering ldapsearch results... Filtering original ldif... Comparing filter output... Comparison failed ------------------ # diff testrun/ldif.flt testrun/ldapsearch.flt 233,235c233,235 < dn: cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc=example,dc < =com < mail: bjorn(a)mailgw.example.com --- > dn: cn=Barbara Jensen,ou=Information Technology Division,ou=People,dc=example, > dc=com > mail: bjensen(a)mailgw.example.com # -- Ralf

1 0

Re: (ITS#5113) pcache returns incomplete results
by rhafer＠suse.de 20 Sep '07

20 Sep '07

Should be fixed in HEAD now. -- Ralf

1 0

Re: ITS#5112
by rhafer＠suse.de 20 Sep '07

20 Sep '07

This should now be fixed in HEAD. The changer however cause test020-proxycache to fail currently. But that seems to be related to the ITS#5113 issue (the cache is used before it is completely populated). Working on that next. -- Ralf

1 0

Re: (ITS#4860) Sets' enhancement
by raphael.ouazana＠linagora.com 20 Sep '07

20 Sep '07

Hi, Le Jeu 13 septembre 2007 22:47, ando(a)sys-net.it a écrit : > Should be fixed now in HEAD/re24/re23. Please test. p. Thank you for that and for the various fixes (/-*, documentation). We are going to test your fixes as soon as possible. Regards, Raphael Ouazana.

1 0

Re: (ITS#5146) slapo-ppolicy
by hyc＠symas.com 19 Sep '07

19 Sep '07

tonni(a)hetnet.nl wrote: > I'd like to see ppolicy refuse to accept a multi-value userPassword. Agreed, this problem is already highlighted in the current code. (See the FIXME comment in ppolicy.c around line 1556.) We just haven't decided on a proper solution yet. It appears that the RFC3112 authPassword suffers from the same problem. If I were to design all of this today I would have made these attributes single-valued, and used attribute tags to specify the password hash mechanism. E.g., authPassword;crypt: 0123456789abcd authPassword;sha1: xxxxxxxxxxxxxx Since the Password Policy draft *does* include provisions for applying policies to multiple password attributes, then this problem would no longer exist. Of course now that userPassword and authPassword already exist, all the good attribute names are already gone. ;) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5146) slapo-ppolicy
by tonni＠hetnet.nl 19 Sep '07

19 Sep '07

Full_Name: Tony Earnshaw Version: 2.3.38 OS: Red Hat derived: Fedora FC6 and RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.10.163.78) I'm adopting ppolicy for the enterprise site I manage as far as OpenLDAP is concerned. It's running on RHEL5, has a 2.3 provider and 3 delta-syncrepl consumers. Main application software is Samba PDC (100+ Windows XP users), LTSP (Linux Terminal Server Project) for around 80 terminals and email (smtp and IMAP). Up to now, after 4 years, the site's password policy has been to force all users to accept new passwords that Admin generates for them with apg (good passwords). Each uid and password is (thanks to OpenLDAP), valid for every service offered by the site. We are going to change our password policy to that of Semersheim and force users to change their own policy at regular intervals, according to slapo-ppolicy. I'm doing lab tests on my own Fedora FC6 machine prior to implementing. Everything OpenLDAP supplies works, no complaint. Even Windows passwords get changed in sync, if the correct interface (in our case pam) is chosen. That's not the subject of this ITS. My complaint is, that by changing our ACLs to allow users write access to necessary attributes, ppolicy opens up a can of worms. Specifically, the attribute userPassword is multi value. That is, given a suitable utility (examples are phpldapadmin and gq), a user with write rights can enter multiple passwords for his account. Each of these extra passwords *works* and the superfluous passwords bypass ppolicy's pwdHistory, never get recorded, are always valid. IOTW, a user who has many passwords can validate with any of them and none but one is subject to ppolicy pwdHistory constraints. I've temporarily solved this by patching servers/slapd/schema_prep.c such that userPassword becomes SINGLE-VALUE. But this is obviously not the way to go. If the rfcs decree that userPassword has to be multi-value, then it has to be multi-value, however downright *STUPID* the rfc. Someone else has to change that. I'd like to see ppolicy refuse to accept a multi-value userPassword. "But that's not part of Semersheim", you enjoinder. Well, eff Semersheim, that's a draft, accepting multi-value userPassword is (somewhere) an rfc.

1 0

(ITS#5145) Contrib: Automatic groups overlay
by michal.szulczynski＠altkom.pl 19 Sep '07

19 Sep '07

Full_Name: Michał Szulczyński Version: OS: URL: ftp://ftp.openldap.org/incoming/michal.szulczynski-autogroup-070919.tar.gz Submission from: (NULL) (87.204.26.249) The autogroup overlay allows automated updates of group membership which meet the requirements of any filter contained in the group. The filters are build from the LDAP URI-valued attributes. Any time an object is added/deleated/updated, it is tested for compilance with the filters, and its membership is accordingly updated. For searches and compares it behaves like a static group.

1 0

imporvement to slapo-constraint (ITS#4987)
by manu＠netbsd.org 18 Sep '07

18 Sep '07

Here are improvements: 1) Instead of matching against an individual attribute, match against a set of values returned by an LDAP URI: ftp://ftp.openldap.org/incoming/manu-070918.patch 2) a man page for slapo-constraint(5) ftp://ftp.openldap.org/incoming/manu-pkg-070919.tgz -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by donn＠u.washington.edu 18 Sep '07

18 Sep '07

On Sep 18, 2007, at 4:35 PM, Howard Chu wrote: > donn(a)u.washington.edu wrote: >> On Aug 23, 2007, at 2:56 PM, Howard Chu wrote: >> [ ... re attribute value matching ... ] >>> The only way to do this right, without dying on an O(n^2) >>> algorithm, is to sort both arrays first and then walk through >>> them in order as the original code did. If you want to submit >>> such a patch, please do. I don't have a lot of time to focus on >>> this at the moment. >> I did look at this, and the attached patch is what I came up with, >> relative to HEAD 1.356. I have tested it, but unfortunately the > > Thanks but I already went ahead with a different fix for this since > I didn't hear back from you. Yes, I know, I understand that to be the O(n^2) option you mention above. It's certainly the simplest way. Donn Cave, donn(a)u.washington.edu

1 0

Re: (ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by hyc＠symas.com 18 Sep '07

18 Sep '07

donn(a)u.washington.edu wrote: > --Apple-Mail-4--750948447 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > charset=US-ASCII; > delsp=yes; > format=flowed > > > On Aug 23, 2007, at 2:56 PM, Howard Chu wrote: > [ ... re attribute value matching ... ] >> The only way to do this right, without dying on an O(n^2) >> algorithm, is to sort both arrays first and then walk through them >> in order as the original code did. If you want to submit such a >> patch, please do. I don't have a lot of time to focus on this at >> the moment. > > I did look at this, and the attached patch is what I came up with, > relative to HEAD 1.356. I have tested it, but unfortunately the Thanks but I already went ahead with a different fix for this since I didn't hear back from you. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by donn＠u.washington.edu 18 Sep '07

18 Sep '07

--Apple-Mail-4--750948447 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Aug 23, 2007, at 2:56 PM, Howard Chu wrote: [ ... re attribute value matching ... ] > > The only way to do this right, without dying on an O(n^2) > algorithm, is to sort both arrays first and then walk through them > in order as the original code did. If you want to submit such a > patch, please do. I don't have a lot of time to focus on this at > the moment. I did look at this, and the attached patch is what I came up with, relative to HEAD 1.356. I have tested it, but unfortunately the results are confounded by other problems - a crash (syncprov thread queue entry so->s_qtask wasn't in slapd_rq, and some pointer values in the former structure were 0x30303030), and in the end the replica was missing a lot of attribute deletions. Wouldn't think either was related to attr_cmp(), but I am out of time to look at these problems and keep trying to demonstrate a 100% successful syncrepl replication. I didn't sort the arrays. I tried that (quicksort algorithm), and it was very expensive. If there's reason to hope that the old and new values will be mostly in the same order, then it is much cheaper in this case to start with a simple pairwise walk through, as in the older code, and then clean up with a full O(n^2) match on what's left. The implementation is also simpler. Actual performance depends on the data, but with the data I used for tests of the algorithms, I found that this approach outperforms the original 2.4.4 implementation, in terms of bvmatch counts. That's because the 2.4.4 needed to look ahead through the rest of the value array in a couple of places in the loop. Performance will be worst where many values are changed, i.e., many adds and deletes - many adds and few deletes, or vice versa, will be significantly faster. I think this is good for most real world situations. I restored variable names from 2.4.4 because they returned to their original usage, likewise with the sml_values handling, and dedicated a variable to the modtail logic at the end of attr_cmp(). I haven't looked into it, but happened to notice just this afternoon a comment in dn_callback(): "We assume that attributes are saved in the same order in the remote and local databases. So ..." Donn Cave, donn(a)u.washington.edu --Apple-Mail-4--750948447 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name=syncrepl.c Content-Disposition: attachment; filename=syncrepl.c --- servers/slapd/syncrepl.c.orig 2007-09-18 15:10:52.000000000 -0700 +++ servers/slapd/syncrepl.c 2007-09-18 15:57:33.000000000 -0700 @@ -2673,17 +2673,98 @@ return rc; } +/* Remove null elements. */ +static int +nonulls( struct berval **a, int na ) +{ + int i, n; + for ( i = n = 0; i < na; ++i ) { + if ( a[i] ) { + if ( i > n ) + a[n] = a[i]; + ++n; + } + } + return n; +} + +/* +** Secondary difference: remove any remaining matching elements, +** by brute force M*N comparison. +*/ +static void +ixpurge( struct berval **iva, int niva, int *nivap, + struct berval **ivb, int nivb, int *nivbp ) +{ + int ia, ib; + for ( ia = 0; ia < niva; ++ia ) { + for ( ib = 0; ib < nivb; ++ib ) { + if ( ivb[ib] && bvmatch( iva[ia], ivb[ib] ) ) { + iva[ia] = 0; + ivb[ib] = 0; + break; + } + } + } + *nivap = nonulls( iva, niva ); + *nivbp = nonulls( ivb, nivb ); +} + +/* +** Compare two lists of berval strings that are supposed to be in +** similar order, and return list of indices to old (delete) and +** new (add) elements of the respective lists. If of significantly +** different sizes, the smaller should be first for optimal performance. +*/ +static void +diff1( + struct berval *bva, + int na, + struct berval *bvb, + int nb, + struct berval **dva, + int *ndvap, + struct berval **dvb, + int *ndvbp +) +{ + int ia, ib, ib0, ndva, ndvb, ndvar, ndvbr; + ndva = ndvb = 0; + for ( ia = ib0 = 0; ia < na; ++ia ) { + /* Find a/b match, starting from last b anchor. */ + for ( ib = ib0; ib < nb && !bvmatch( &bva[ia], &bvb[ib] ); ++ib ) + ; + if ( ib < nb ) { + /* Found. Record non-matching b's, reset anchor. */ + for ( ; ib0 < ib; ++ib0 ) + dvb[ndvb++] = &bvb[ib0]; + ++ib0; + } else { + /* Not found, record non-matching a. */ + dva[ndva++] = &bva[ia]; + } + } + /* Record remaining unmatched b's. */ + for ( ; ib0 < nb; ++ib0 ) + dvb[ndvb++] = &bvb[ib0]; + /* Clean up spurious non-matches, in case order assumptions invalid. */ + ixpurge( dva, ndva, &ndvar, dvb, ndvb, &ndvbr ); + *ndvap = ndvar; + *ndvbp = ndvbr; +} + static void attr_cmp( Operation *op, Attribute *old, Attribute *new, Modifications ***mret, Modifications ***mcur ) { - int i, j; + int tails; + int i; Modifications *mod, **modtail; modtail = *mret; if ( old ) { - int n, o, nn, no; + int n, o, a, d; struct berval **adds, **dels; /* count old and new */ for ( o=0; old->a_vals[o].bv_val; o++ ) ; @@ -2692,105 +2773,83 @@ /* there MUST be both old and new values */ assert( o != 0 ); assert( n != 0 ); - j = 0; adds = op->o_tmpalloc( sizeof(struct berval *) * n, op->o_tmpmemctx ); dels = op->o_tmpalloc( sizeof(struct berval *) * o, op->o_tmpmemctx ); - for ( i=0; i<o; i++ ) dels[i] = &old->a_vals[i]; - for ( i=0; i<n; i++ ) adds[i] = &new->a_vals[i]; - - nn = n; no = o; - - for ( i=0; i<o; i++ ) { - for ( j=0; j<n; j++ ) { - if ( !adds[j] ) - continue; - if ( bvmatch( dels[i], adds[j] ) ) { - no--; - nn--; - adds[j] = NULL; - dels[i] = NULL; - break; - } - } - } + if ( o > n ) + diff1( new->a_vals, n, old->a_vals, o, adds, &a, dels, &d ); + else + diff1( old->a_vals, o, new->a_vals, n, dels, &d, adds, &a ); + tails = 0; - i = j; /* all old values were deleted, just use the replace op */ - if ( no == o ) { - i = j-1; - } else if ( no ) { + if ( d == o ) { + tails = 1; + } else if ( d ) { /* delete some values */ mod = ch_malloc( sizeof( Modifications ) ); mod->sml_op = LDAP_MOD_DELETE; mod->sml_flags = 0; mod->sml_desc = old->a_desc; mod->sml_type = mod->sml_desc->ad_cname; - mod->sml_values = ch_malloc( ( no + 1 ) * sizeof(struct berval) ); + mod->sml_values = ch_malloc( ( d + 1 ) * sizeof(struct berval) ); if ( old->a_vals != old->a_nvals ) { - mod->sml_nvalues = ch_malloc( ( no + 1 ) * sizeof(struct berval) ); + mod->sml_nvalues = ch_malloc( ( d + 1 ) * sizeof(struct berval) ); } else { mod->sml_nvalues = NULL; } - j = 0; - for ( i = 0; i < o; i++ ) { - if ( !dels[i] ) continue; - ber_dupbv( &mod->sml_values[j], &old->a_vals[i] ); + for ( i = 0; i < d; i++ ) { + ber_dupbv( &mod->sml_values[i], dels[i] ); if ( mod->sml_nvalues ) { - ber_dupbv( &mod->sml_nvalues[j], &old->a_nvals[i] ); + ber_dupbv( &mod->sml_nvalues[i], dels[i] ); } - j++; } - BER_BVZERO( &mod->sml_values[j] ); + BER_BVZERO( &mod->sml_values[i] ); if ( mod->sml_nvalues ) { - BER_BVZERO( &mod->sml_nvalues[j] ); + BER_BVZERO( &mod->sml_nvalues[i] ); } *modtail = mod; modtail = &mod->sml_next; - i = j; + tails = 0; } op->o_tmpfree( dels, op->o_tmpmemctx ); /* some values were added */ - if ( nn && no < o ) { + if ( a && d < o ) { mod = ch_malloc( sizeof( Modifications ) ); mod->sml_op = LDAP_MOD_ADD; mod->sml_flags = 0; mod->sml_desc = old->a_desc; mod->sml_type = mod->sml_desc->ad_cname; - mod->sml_values = ch_malloc( ( nn + 1 ) * sizeof(struct berval) ); + mod->sml_values = ch_malloc( ( a + 1 ) * sizeof(struct berval) ); if ( old->a_vals != old->a_nvals ) { - mod->sml_nvalues = ch_malloc( ( nn + 1 ) * sizeof(struct berval) ); + mod->sml_nvalues = ch_malloc( ( a + 1 ) * sizeof(struct berval) ); } else { mod->sml_nvalues = NULL; } - j = 0; - for ( i = 0; i < n; i++ ) { - if ( !adds[i] ) continue; - ber_dupbv( &mod->sml_values[j], &new->a_vals[i] ); + for ( i = 0; i < a; i++ ) { + ber_dupbv( &mod->sml_values[i], adds[i] ); if ( mod->sml_nvalues ) { - ber_dupbv( &mod->sml_nvalues[j], &new->a_nvals[i] ); + ber_dupbv( &mod->sml_nvalues[i], adds[i] ); } - j++; } - BER_BVZERO( &mod->sml_values[j] ); + BER_BVZERO( &mod->sml_values[i] ); if ( mod->sml_nvalues ) { - BER_BVZERO( &mod->sml_nvalues[j] ); + BER_BVZERO( &mod->sml_nvalues[i] ); } *modtail = mod; modtail = &mod->sml_next; - i = j; + tails = 0; } op->o_tmpfree( adds, op->o_tmpmemctx ); } else { /* new attr, just use the new mod */ - i = 0; - j = 1; + tails = 1; } /* advance to next element */ mod = **mcur; if ( mod ) { - if ( i != j ) { + if ( tails ) { **mcur = mod->sml_next; *modtail = mod; modtail = &mod->sml_next; --Apple-Mail-4--750948447--

1 0

Re: (ITS#5065) out of order ctxcsn from old entryCSN
by donn＠u.washington.edu 18 Sep '07

18 Sep '07

On Aug 29, 2007, at 12:55 AM, Pierangelo Masarati wrote: > >> Old entryCSN values imported into the data from another server, >> can crash >> replicas. > > The ITS reports that this is now fixed in HEAD. I would appreciate > if you > feedback using a fresh HEAD build, since the CSN syntax is now more > thoroughly checked, although it is supposed to allow the old one in > input. I did test this, and it didn't crash. Thanks Donn Cave, donn(a)u.washington.edu

1 0

Re: (ITS#5143) com.novell.ldap.Connection(timeout) doesn't use LDAPSocketFactory that is set with setSocketFactory()
by tan7f＠virginia.edu 18 Sep '07

18 Sep '07

--Apple-Mail-8--754823881 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I, Tim Nowaczyk, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. --- openldap-jldap.orig/com/novell/ldap/Connection.java 2006-09-07 02:18:29.000000000 -0400 +++ openldap-jldap/com/novell/ldap/Connection.java 2007-09-18 16:15:56.000000000 -0400 @@ -196,6 +196,8 @@ { myTimeOut = timeout; + mySocketFactory = socketFactory; + if( Debug.LDAP_DEBUG) { synchronized(nameLock) { name = "Connection(" + ++connNum + "): "; --Apple-Mail-8--754823881 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPujCCBIIw ggNqoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZ8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJn aW5pYTEYMBYGA1UEBxMPQ2hhcmxvdHRlc3ZpbGxlMR8wHQYDVQQKExZVbml2ZXJzaXR5IG9mIFZp cmdpbmlhMRswGQYDVQQDExJVVkEgVVNIRVIgUEtQIENBIDExJTAjBgkqhkiG9w0BCQEWFnBraW1h c3RlckB2aXJnaW5pYS5lZHUwHhcNMDcwNzEyMjEyNzE0WhcNMjYwMjI1MDAwMDAwWjCBrzELMAkG A1UEBhMCVVMxETAPBgNVBAgTCFZpcmdpbmlhMRgwFgYDVQQHEw9DaGFybG90dGVzdmlsbGUxHzAd BgNVBAoTFlVuaXZlcnNpdHkgb2YgVmlyZ2luaWExJTAjBgkqhkiG9w0BCQEWFnBraW1hc3RlckB2 aXJnaW5pYS5lZHUxKzApBgNVBAMTIlVWQSBTdGFuZGFyZCBBc3N1cmFuY2UgVVNIRVIgU0tQIDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDbO90WPYQnSOSvhwkIlhh3fLVaHi6X2v2+ kJ7njhzZg8zYoTwMa/sag84dgGu9CCmkzvYryD23mwdQ5oZX58ZyrYCETkcuV5Aycbi70ekTrQPP 1b4x4/sK3PDFSn2S2RB1sNlYy15DI6sIO5mVrV16ML+DGBSJbwGoJRjd+2L5MxkhPJraw5+k2us7 ABxvRpFgaA4TXwJiM8/idtsTNMv2XTR6zUJ9FPq8uOMLtiupbWe2K2tXDDeBSzBu7Z7RzNzxSsZz 72PjtEHhuNQ4I1hsKx/HT2gdxrCb6KxSyGo+QbYxwj5znRkIAFNEQPh6U6EPeDuzJbY/VuFfpsil 3tPZAgMBAAGjgbYwgbMwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFAGp d8MuTIwww/Lbfd5nlCrBvuQZMB8GA1UdIwQYMBaAFDdB3axEwhAHmpxMkx2UHyiXRyUxMFMGA1Ud IARMMEowSAYJKwYBBAG0dgEBMDswOQYIKwYBBQUHAgEWLWh0dHA6Ly93d3cucGtpLnZpcmdpbmlh LmVkdS9zdGFuZGFyZC9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEAfEvJKxRHr9gy0MufEFva x+QQs2dUN8oocl8jxWsQrQt5Hc6Azzfn2Zp3es10iYkCGNOqj+cRtwoljuWv2yVWm869+xgxskjn uHPnaat84VzXN85i8ILbBZkVYPk1bO2SHjL97RrGvUqi2bJf8cSlzO7g+yTX9/yX0r0QKL4UNHdI p3l3OeTZ0PBLKNhlr1wb6LRpl5+lRZQPWeCij/4e3wA7v9OmWXvevT9YprYTwEmCypPUbnjFeMnP F+hwSgCC+Yov12kP3M+kDwXWpidFGk5p6nQ5c/cGGPd+x8Ek4VjjCw+7TfumwxEJSIX0NmjM+lDx ykVtAMDS11nQ65/VEjCCBVwwggREoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMC VVMxITAfBgNVBAoTGFVTIEhpZ2hlciBFZHVjYXRpb24gUm9vdDEMMAoGA1UECxMDQ0ExMRUwEwYD VQQDEwxVU0hFUiBDQTEgdjEwHhcNMDcwNzExMjIyOTQ3WhcNMjYwMjI2MTgwMDAwWjCBnzELMAkG A1UEBhMCVVMxETAPBgNVBAgTCFZpcmdpbmlhMRgwFgYDVQQHEw9DaGFybG90dGVzdmlsbGUxHzAd BgNVBAoTFlVuaXZlcnNpdHkgb2YgVmlyZ2luaWExGzAZBgNVBAMTElVWQSBVU0hFUiBQS1AgQ0Eg MTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZpcmdpbmlhLmVkdTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANnbscQ3ClhftaALCDqjnqvzU1MVfDmnSNFjSBcGyRRKxNEduA/O4/iD CQ3lKJkRdjhIXN5e5UTe6LsmMY14uPBJOVINmFPiGfsi22LxslYiaGMStWIj3lNF+ZawyUX53WDD IrjlYaBn3wi/m0tkWPLzsgeiRIovL0KVG4XRlkJ70upNCIv6GHP4W6rsa2hqC/gU1QdL+V2XJzE7 sT7l6CysRr01FiyRTOxdoSz+jJFmTTt892sWVry8B7nocD/ltffQ1pQJta4Ve/xWT+TvRPF3X7jn ggOPIYbq0mYRAhWduV1BzlBA8bkTc8AHf8ukjRGydCAPc4OXMamhJ4uETCECAwEAAaOCAeowggHm MA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQ3Qd2sRMIQB5qcTJMd lB8ol0clMTB9BgNVHSMEdjB0gBQmnSLq7LAPayEK9tkvIMplUOwb06FZpFcwVTELMAkGA1UEBhMC VVMxITAfBgNVBAoTGFVTIEhpZ2hlciBFZHVjYXRpb24gUm9vdDEMMAoGA1UECxMDQ0ExMRUwEwYD VQQDEwxVU0hFUiBDQTEgdjGCAQQweAYIKwYBBQUHAQEEbDBqMDMGCCsGAQUFBzAChidodHRwOi8v aDEudXNoZXJjYS5vcmcvYWlhL2NhMS1jZXJ0cy5wN2IwMwYIKwYBBQUHMAKGJ2h0dHA6Ly9oMi51 c2hlcmNhLm9yZy9haWEvY2ExLWNlcnRzLnA3YjBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vaDEu dXNoZXJjYS5vcmcvY3JsL2NhMS5jcmwwJ6AloCOGIWh0dHA6Ly9oMi51c2hlcmNhLm9yZy9jcmwv Y2ExLmNybDBOBgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0cHM6Ly93d3cudXNo ZXJjYS5vcmcvcHJhY3RpY2VzL2NhMS9jcHMucGRmMA0GCSqGSIb3DQEBBQUAA4IBAQCHbtcZxR5o 9B0MgMds0g3g9DBLZSJEi6kRY6heNocsmSsRxEsqE37R6gVtRg3xfTcjJG9E4J4fClB8EK5EDPRo UAJZExJE47aHNXT7KtHgYKqU5dQUXlGi/ZyPpJOA5Nm8xQ+wiDw3kg8AAnM1WrPNnTUiTCYEUqBI KY8AABaJ9CwVHsnu0wV04z4DtbiZgEhxBOczp8L+AveIsJhCTRc3VNlDmHPu9bh4VoyMnbzwlYKk ItLkehDC5xE2ZPTMfC0VYtL+LEDlbGfR0YpzbTzxP3X3dxsmFbIyXAfNvj5gTqViDcgN9CTzblDv oseZLtO0Te+e/YFeTRUBe/CcmUlmMIIF0DCCBLigAwIBAgIDAgQUMA0GCSqGSIb3DQEBBQUAMIGv MQswCQYDVQQGEwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxs ZTEfMB0GA1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFz dGVyQHZpcmdpbmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBT S1AgMTAeFw0wNzA4MDgxMzAzMDBaFw0wODA4MDgxMzAzMDBaMIGVMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTEeMBwGA1UECxMVVVZBIFN0YW5kYXJkIFBLSSBV c2VyMSEwHwYJKoZIhvcNAQkBFhJ0YW43ZkB2aXJnaW5pYS5lZHUxIjAgBgNVBAMTGVRpbW90aHkg QWxsZW4gTm93YWN6eWsgMTMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKEo43l7/lWiNKOe vtraIMIje77qJCSifhZ0CtrBT15E8HPQajBcFnqJ3U//6vvrEeN79de3Gvwygia0SwkgzjtFEsh8 /fLHKvYUDDlhyJxgbaVw3Ay1Ii9cHTyA8hopglAhyVweu08hwrnmSUDBsV+ugqV3AANQ0QwkXPDs WbIbAgMBAAGjggKPMIICizALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBSt9bmjP/g2cbvyzw+7IfnWfnDliDAJBgNVHRMEAjAAMB8GA1UdIwQYMBaA FAGpd8MuTIwww/Lbfd5nlCrBvuQZMEEGA1UdEQQ6MDigIgYKKwYBBAGCNxQCA6AUDBJ0YW43ZkBW aXJnaW5pYS5FRFWBEnRhbjdmQFZpcmdpbmlhLkVEVTCCAXgGA1UdHwSCAW8wggFrMH2ge6B5hnds ZGFwOi8vd3d3LnBraS52aXJnaW5pYS5lZHUvYz1VUyxvPVVuaXZlcnNpdHklMjBvZiUyMFZpcmdp bmlhLG91PVVWQSUyMFN0YW5kYXJkJTIwQXNzdXJhbmNlJTIwVVNIRVIlMjBTS1AlMjAxLGNuPTAy MDQxNDB9oHugeYZ3bGRhcDovL3d3dy5wa2kudmlyZ2luaWEuZWR1L2NuPTAyMDQxNCxvdT1VVkEl MjBTdGFuZGFyZCUyMEFzc3VyYW5jZSUyMFVTSEVSJTIwU0tQJTIwMSxvPVVuaXZlcnNpdHklMjBv ZiUyMFZpcmdpbmlhLGM9VVMwa6BpoGeGZWh0dHA6Ly93d3cucGtpLnZpcmdpbmlhLmVkdS9jZ2kt YmluL2dldC1jcmw/b3U9VVZBJTIwU3RhbmRhcmQlMjBBc3N1cmFuY2UlMjBVU0hFUiUyMFNLUCUy MDEmY249MDIwNDE0MFMGA1UdIARMMEowSAYJKwYBBAG0dgEBMDswOQYIKwYBBQUHAgEWLWh0dHA6 Ly93d3cucGtpLnZpcmdpbmlhLmVkdS9zdGFuZGFyZC9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOC AQEAY0SUBCrlT0E9VPUQy3lTVDYNQ+ewR3dPa+D4U+gqThk3mbOWSXWEOsYTw9BYOljv4UClAY5M Uhp1Iyj7twzIG8lJnZhVP3G/ToU+8fkCCPUdAH+MJ6eshdZaeEEA/a2RzB0XvvmAfYK5x3e2yYLM tOvfBHrRAl6m5O7wU2t6iykU6vGdL+MB9iqlylY2bxQ0x0NaW5KPL0XuPLgwxVvcds7eIDGOoy7+ WMDaY0miUqsq4PKjg98dnY5BaSUwGFyxhFocw8xtTVdls5VKh3jEvhYyq9ejTHFv49dEnXdmSZ1Y Z3p98sEfQ12+CtFUbzlwphhJELXdC4nm71zFPcXg8zGCA1cwggNTAgEBMIG3MIGvMQswCQYDVQQG EwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxsZTEfMB0GA1UE ChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZpcmdp bmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBTS1AgMQIDAgQU MAkGBSsOAwIaBQCgggH1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA3MDkxODIyMDczN1owIwYJKoZIhvcNAQkEMRYEFHAQ0BEeX/opld1qL/e7p15VsNS0MIHIBgkr BgEEAYI3EAQxgbowgbcwga8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJnaW5pYTEYMBYGA1UE BxMPQ2hhcmxvdHRlc3ZpbGxlMR8wHQYDVQQKExZVbml2ZXJzaXR5IG9mIFZpcmdpbmlhMSUwIwYJ KoZIhvcNAQkBFhZwa2ltYXN0ZXJAdmlyZ2luaWEuZWR1MSswKQYDVQQDEyJVVkEgU3RhbmRhcmQg QXNzdXJhbmNlIFVTSEVSIFNLUCAxAgMCBBQwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYD VQQGEwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxsZTEfMB0G A1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZp cmdpbmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBTS1AgMQID AgQUMA0GCSqGSIb3DQEBAQUABIGAbpjioCdW4nLos556WyQRsjrjrZnjY2L25a5jl2mKGsHPWpe4 6B11HSa0RyttrMo0pT9Gz3LWBxt76tE/kzPoQ9FRaczCZ927tDEEGTEQwTmojiamuPJpftDNEtrS UVhyZTnGaFJBSEp2aT4C1bL3pSMOPNQukATDRq5vrG76ojUAAAAAAAA= --Apple-Mail-8--754823881--

1 0

Re: (ITS#5142) NullPointerException in com.novell.ldap.Connection.setSocketTimeOut
by tan7f＠virginia.edu 18 Sep '07

18 Sep '07

--Apple-Mail-7--754879607 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I, Tim Nowaczyk, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. --- openldap-jldap.orig/com/novell/ldap/Connection.java 2006-09-07 02:18:29.000000000 -0400 +++ openldap-jldap/com/novell/ldap/Connection.java 2007-09-18 15:56:17.000000000 -0400 @@ -689,7 +689,7 @@ { try { - socket.setSoTimeout(timeout); + if (socket != null) socket.setSoTimeout(timeout); myTimeOut = timeout; } catch(SocketException e) {} return; -- Timothy Nowaczyk Network Systems Engineer University of Virginia - ITC tan7f(a)virginia.edu --Apple-Mail-7--754879607 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPujCCBIIw ggNqoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZ8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJn aW5pYTEYMBYGA1UEBxMPQ2hhcmxvdHRlc3ZpbGxlMR8wHQYDVQQKExZVbml2ZXJzaXR5IG9mIFZp cmdpbmlhMRswGQYDVQQDExJVVkEgVVNIRVIgUEtQIENBIDExJTAjBgkqhkiG9w0BCQEWFnBraW1h c3RlckB2aXJnaW5pYS5lZHUwHhcNMDcwNzEyMjEyNzE0WhcNMjYwMjI1MDAwMDAwWjCBrzELMAkG A1UEBhMCVVMxETAPBgNVBAgTCFZpcmdpbmlhMRgwFgYDVQQHEw9DaGFybG90dGVzdmlsbGUxHzAd BgNVBAoTFlVuaXZlcnNpdHkgb2YgVmlyZ2luaWExJTAjBgkqhkiG9w0BCQEWFnBraW1hc3RlckB2 aXJnaW5pYS5lZHUxKzApBgNVBAMTIlVWQSBTdGFuZGFyZCBBc3N1cmFuY2UgVVNIRVIgU0tQIDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDbO90WPYQnSOSvhwkIlhh3fLVaHi6X2v2+ kJ7njhzZg8zYoTwMa/sag84dgGu9CCmkzvYryD23mwdQ5oZX58ZyrYCETkcuV5Aycbi70ekTrQPP 1b4x4/sK3PDFSn2S2RB1sNlYy15DI6sIO5mVrV16ML+DGBSJbwGoJRjd+2L5MxkhPJraw5+k2us7 ABxvRpFgaA4TXwJiM8/idtsTNMv2XTR6zUJ9FPq8uOMLtiupbWe2K2tXDDeBSzBu7Z7RzNzxSsZz 72PjtEHhuNQ4I1hsKx/HT2gdxrCb6KxSyGo+QbYxwj5znRkIAFNEQPh6U6EPeDuzJbY/VuFfpsil 3tPZAgMBAAGjgbYwgbMwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFAGp d8MuTIwww/Lbfd5nlCrBvuQZMB8GA1UdIwQYMBaAFDdB3axEwhAHmpxMkx2UHyiXRyUxMFMGA1Ud IARMMEowSAYJKwYBBAG0dgEBMDswOQYIKwYBBQUHAgEWLWh0dHA6Ly93d3cucGtpLnZpcmdpbmlh LmVkdS9zdGFuZGFyZC9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEAfEvJKxRHr9gy0MufEFva x+QQs2dUN8oocl8jxWsQrQt5Hc6Azzfn2Zp3es10iYkCGNOqj+cRtwoljuWv2yVWm869+xgxskjn uHPnaat84VzXN85i8ILbBZkVYPk1bO2SHjL97RrGvUqi2bJf8cSlzO7g+yTX9/yX0r0QKL4UNHdI p3l3OeTZ0PBLKNhlr1wb6LRpl5+lRZQPWeCij/4e3wA7v9OmWXvevT9YprYTwEmCypPUbnjFeMnP F+hwSgCC+Yov12kP3M+kDwXWpidFGk5p6nQ5c/cGGPd+x8Ek4VjjCw+7TfumwxEJSIX0NmjM+lDx ykVtAMDS11nQ65/VEjCCBVwwggREoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMC VVMxITAfBgNVBAoTGFVTIEhpZ2hlciBFZHVjYXRpb24gUm9vdDEMMAoGA1UECxMDQ0ExMRUwEwYD VQQDEwxVU0hFUiBDQTEgdjEwHhcNMDcwNzExMjIyOTQ3WhcNMjYwMjI2MTgwMDAwWjCBnzELMAkG A1UEBhMCVVMxETAPBgNVBAgTCFZpcmdpbmlhMRgwFgYDVQQHEw9DaGFybG90dGVzdmlsbGUxHzAd BgNVBAoTFlVuaXZlcnNpdHkgb2YgVmlyZ2luaWExGzAZBgNVBAMTElVWQSBVU0hFUiBQS1AgQ0Eg MTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZpcmdpbmlhLmVkdTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANnbscQ3ClhftaALCDqjnqvzU1MVfDmnSNFjSBcGyRRKxNEduA/O4/iD CQ3lKJkRdjhIXN5e5UTe6LsmMY14uPBJOVINmFPiGfsi22LxslYiaGMStWIj3lNF+ZawyUX53WDD IrjlYaBn3wi/m0tkWPLzsgeiRIovL0KVG4XRlkJ70upNCIv6GHP4W6rsa2hqC/gU1QdL+V2XJzE7 sT7l6CysRr01FiyRTOxdoSz+jJFmTTt892sWVry8B7nocD/ltffQ1pQJta4Ve/xWT+TvRPF3X7jn ggOPIYbq0mYRAhWduV1BzlBA8bkTc8AHf8ukjRGydCAPc4OXMamhJ4uETCECAwEAAaOCAeowggHm MA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQ3Qd2sRMIQB5qcTJMd lB8ol0clMTB9BgNVHSMEdjB0gBQmnSLq7LAPayEK9tkvIMplUOwb06FZpFcwVTELMAkGA1UEBhMC VVMxITAfBgNVBAoTGFVTIEhpZ2hlciBFZHVjYXRpb24gUm9vdDEMMAoGA1UECxMDQ0ExMRUwEwYD VQQDEwxVU0hFUiBDQTEgdjGCAQQweAYIKwYBBQUHAQEEbDBqMDMGCCsGAQUFBzAChidodHRwOi8v aDEudXNoZXJjYS5vcmcvYWlhL2NhMS1jZXJ0cy5wN2IwMwYIKwYBBQUHMAKGJ2h0dHA6Ly9oMi51 c2hlcmNhLm9yZy9haWEvY2ExLWNlcnRzLnA3YjBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vaDEu dXNoZXJjYS5vcmcvY3JsL2NhMS5jcmwwJ6AloCOGIWh0dHA6Ly9oMi51c2hlcmNhLm9yZy9jcmwv Y2ExLmNybDBOBgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0cHM6Ly93d3cudXNo ZXJjYS5vcmcvcHJhY3RpY2VzL2NhMS9jcHMucGRmMA0GCSqGSIb3DQEBBQUAA4IBAQCHbtcZxR5o 9B0MgMds0g3g9DBLZSJEi6kRY6heNocsmSsRxEsqE37R6gVtRg3xfTcjJG9E4J4fClB8EK5EDPRo UAJZExJE47aHNXT7KtHgYKqU5dQUXlGi/ZyPpJOA5Nm8xQ+wiDw3kg8AAnM1WrPNnTUiTCYEUqBI KY8AABaJ9CwVHsnu0wV04z4DtbiZgEhxBOczp8L+AveIsJhCTRc3VNlDmHPu9bh4VoyMnbzwlYKk ItLkehDC5xE2ZPTMfC0VYtL+LEDlbGfR0YpzbTzxP3X3dxsmFbIyXAfNvj5gTqViDcgN9CTzblDv oseZLtO0Te+e/YFeTRUBe/CcmUlmMIIF0DCCBLigAwIBAgIDAgQUMA0GCSqGSIb3DQEBBQUAMIGv MQswCQYDVQQGEwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxs ZTEfMB0GA1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFz dGVyQHZpcmdpbmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBT S1AgMTAeFw0wNzA4MDgxMzAzMDBaFw0wODA4MDgxMzAzMDBaMIGVMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTEeMBwGA1UECxMVVVZBIFN0YW5kYXJkIFBLSSBV c2VyMSEwHwYJKoZIhvcNAQkBFhJ0YW43ZkB2aXJnaW5pYS5lZHUxIjAgBgNVBAMTGVRpbW90aHkg QWxsZW4gTm93YWN6eWsgMTMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKEo43l7/lWiNKOe vtraIMIje77qJCSifhZ0CtrBT15E8HPQajBcFnqJ3U//6vvrEeN79de3Gvwygia0SwkgzjtFEsh8 /fLHKvYUDDlhyJxgbaVw3Ay1Ii9cHTyA8hopglAhyVweu08hwrnmSUDBsV+ugqV3AANQ0QwkXPDs WbIbAgMBAAGjggKPMIICizALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBSt9bmjP/g2cbvyzw+7IfnWfnDliDAJBgNVHRMEAjAAMB8GA1UdIwQYMBaA FAGpd8MuTIwww/Lbfd5nlCrBvuQZMEEGA1UdEQQ6MDigIgYKKwYBBAGCNxQCA6AUDBJ0YW43ZkBW aXJnaW5pYS5FRFWBEnRhbjdmQFZpcmdpbmlhLkVEVTCCAXgGA1UdHwSCAW8wggFrMH2ge6B5hnds ZGFwOi8vd3d3LnBraS52aXJnaW5pYS5lZHUvYz1VUyxvPVVuaXZlcnNpdHklMjBvZiUyMFZpcmdp bmlhLG91PVVWQSUyMFN0YW5kYXJkJTIwQXNzdXJhbmNlJTIwVVNIRVIlMjBTS1AlMjAxLGNuPTAy MDQxNDB9oHugeYZ3bGRhcDovL3d3dy5wa2kudmlyZ2luaWEuZWR1L2NuPTAyMDQxNCxvdT1VVkEl MjBTdGFuZGFyZCUyMEFzc3VyYW5jZSUyMFVTSEVSJTIwU0tQJTIwMSxvPVVuaXZlcnNpdHklMjBv ZiUyMFZpcmdpbmlhLGM9VVMwa6BpoGeGZWh0dHA6Ly93d3cucGtpLnZpcmdpbmlhLmVkdS9jZ2kt YmluL2dldC1jcmw/b3U9VVZBJTIwU3RhbmRhcmQlMjBBc3N1cmFuY2UlMjBVU0hFUiUyMFNLUCUy MDEmY249MDIwNDE0MFMGA1UdIARMMEowSAYJKwYBBAG0dgEBMDswOQYIKwYBBQUHAgEWLWh0dHA6 Ly93d3cucGtpLnZpcmdpbmlhLmVkdS9zdGFuZGFyZC9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOC AQEAY0SUBCrlT0E9VPUQy3lTVDYNQ+ewR3dPa+D4U+gqThk3mbOWSXWEOsYTw9BYOljv4UClAY5M Uhp1Iyj7twzIG8lJnZhVP3G/ToU+8fkCCPUdAH+MJ6eshdZaeEEA/a2RzB0XvvmAfYK5x3e2yYLM tOvfBHrRAl6m5O7wU2t6iykU6vGdL+MB9iqlylY2bxQ0x0NaW5KPL0XuPLgwxVvcds7eIDGOoy7+ WMDaY0miUqsq4PKjg98dnY5BaSUwGFyxhFocw8xtTVdls5VKh3jEvhYyq9ejTHFv49dEnXdmSZ1Y Z3p98sEfQ12+CtFUbzlwphhJELXdC4nm71zFPcXg8zGCA1cwggNTAgEBMIG3MIGvMQswCQYDVQQG EwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxsZTEfMB0GA1UE ChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZpcmdp bmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBTS1AgMQIDAgQU MAkGBSsOAwIaBQCgggH1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA3MDkxODIyMDY0MVowIwYJKoZIhvcNAQkEMRYEFOZhEYb11jfeLdg54Go+R3Ws+/67MIHIBgkr BgEEAYI3EAQxgbowgbcwga8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJnaW5pYTEYMBYGA1UE BxMPQ2hhcmxvdHRlc3ZpbGxlMR8wHQYDVQQKExZVbml2ZXJzaXR5IG9mIFZpcmdpbmlhMSUwIwYJ KoZIhvcNAQkBFhZwa2ltYXN0ZXJAdmlyZ2luaWEuZWR1MSswKQYDVQQDEyJVVkEgU3RhbmRhcmQg QXNzdXJhbmNlIFVTSEVSIFNLUCAxAgMCBBQwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYD VQQGEwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxsZTEfMB0G A1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZp cmdpbmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBTS1AgMQID AgQUMA0GCSqGSIb3DQEBAQUABIGADKOxplEt0abBwJBberd7M9FLBRmHbmqnq5y2lXlSMaUAz9tl mwZviwbmKKsnsOKUXXJkJtNz1B6/grUQNcGQo7ZQtp0uh2qzaZUMhKo7ok1GBr5FcWUrftRFCG+y 6iBVKFrsAPjCfRvF0XHbPiwjEIO1i4g0vQSwgLmDtxApCr4AAAAAAAA= --Apple-Mail-7--754879607--

1 0

(ITS#5143) com.novell.ldap.Connection(timeout) doesn't use LDAPSocketFactory that is set with setSocketFactory()
by tan7f＠virginia.edu 18 Sep '07

18 Sep '07

Full_Name: Timothy Nowacyzk Version: jldap 4.3 OS: OS X URL: Submission from: (NULL) (137.54.129.39) When creating a new LDAPConnection with the timeout constructor, the Connection is always created with a null SocketFactory even if a new default SocketFactory was set with the setSocketFactory method The patch is included. --- openldap-jldap.orig/com/novell/ldap/Connection.java 2006-09-07 02:18:29.000000000 -0400 +++ openldap-jldap/com/novell/ldap/Connection.java 2007-09-18 16:15:56.000000000 -0400 @@ -196,6 +196,8 @@ { myTimeOut = timeout; + mySocketFactory = socketFactory; + if( Debug.LDAP_DEBUG) { synchronized(nameLock) { name = "Connection(" + ++connNum + "): ";

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs