- openldap-bugs - openldap.org

Re: (ITS#5227) old dsn acceptance
by ando＠sys-net.it 12 Nov '07

12 Nov '07

Howard Chu wrote: > Ah, ok. So, do you think we need to integrate this patch? Do you mean: in 2.3? It might be a good idea in case we want all versions to be completely interoperable. Otherwise, as the code is now, 2.4 tolerates 2.3 (and 2.2, AFAIK), while 2.2 and 2.3 do not tolerate 2.4 (or, which is worse, tolerate but don't understand 2.4: issues could arise when comparing CSNs generated by different versions, which only 2.4 correctly handles by normalizing to its form). Eventually, this could be a problem as soon as someone tries to use 2.4 as master and 2.3 as slave. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5227) old dsn acceptance
by hyc＠symas.com 12 Nov '07

12 Nov '07

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: > >> It seems a bit odd to be introducing support for that format now in 2.4, when >> it was completely unsupported in 2.2 and 2.3. I.e., why wasn't this issue >> raised during the migration to/thru either 2.2 or 2.3? > > Probably because until 2.4 > > #define csnValidate blobValidate > > and as such any incompatible CSN was silently ignored. So this has > always been broken, only 2.4 detects the inconsistency, but behaved > badly (assert) until your fix. Ah, ok. So, do you think we need to integrate this patch? -- -- 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#5231) test045 failure in HEAD/RE24
by hyc＠symas.com 12 Nov '07

12 Nov '07

Gavin Henry wrote: > <quote who="hyc(a)OpenLDAP.org"> >> Full_Name: Howard Chu >> Version: HEAD/RE24 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (76.168.84.21) >> Submitted by: hyc >> >> >> The comparison fails after the first modify step, an entry that should >> have been >> deleted is still present on the slave. >> >> The presentlist is still left over from the initial query, and hasn't been >> emptied yet. This appears to be a missing step when the initial query >> transitions from Refresh to Persist mode. > On RE24 mine on AMD64 Dual doesn't get that far. It dies on test033 with: > > Comparison failed - database not created correctly. > > I'll provide all details shortly, or best to create a new ticket? I already fixed that in HEAD. See the commit logs. -- -- 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#5231) test045 failure in HEAD/RE24
by ghenry＠suretecsystems.com 12 Nov '07

12 Nov '07

<quote who="hyc(a)OpenLDAP.org"> > Full_Name: Howard Chu > Version: HEAD/RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.168.84.21) > Submitted by: hyc > > > The comparison fails after the first modify step, an entry that should > have been > deleted is still present on the slave. > > The presentlist is still left over from the initial query, and hasn't been > emptied yet. This appears to be a missing step when the initial query > transitions from Refresh to Persist mode. > > On RE24 mine on AMD64 Dual doesn't get that far. It dies on test033 with: Comparison failed - database not created correctly. I'll provide all details shortly, or best to create a new ticket? >

1 0

(ITS#5231) test045 failure in HEAD/RE24
by hyc＠OpenLDAP.org 12 Nov '07

12 Nov '07

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc The comparison fails after the first modify step, an entry that should have been deleted is still present on the slave. The presentlist is still left over from the initial query, and hasn't been emptied yet. This appears to be a missing step when the initial query transitions from Refresh to Persist mode.

1 0

Re: (ITS#5227) old dsn acceptance
by ando＠sys-net.it 12 Nov '07

12 Nov '07

hyc(a)symas.com wrote: > It seems a bit odd to be introducing support for that format now in 2.4, when > it was completely unsupported in 2.2 and 2.3. I.e., why wasn't this issue > raised during the migration to/thru either 2.2 or 2.3? Probably because until 2.4 #define csnValidate blobValidate and as such any incompatible CSN was silently ignored. So this has always been broken, only 2.4 detects the inconsistency, but behaved badly (assert) until your fix. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5228) Patches for minor typos in man pages
by ghenry＠OpenLDAP.org 12 Nov '07

12 Nov '07

<quote who="Sam Varshavchik"> > No problem. > > Here are the fixes diff-ed against CVS HEAD: > > http://www.tldp.org/manpages/openldap-2.4.6-manpatch.txt > > This is also attached to this message. Thanks, I'll get to this soon. Gavin.

1 0

Re: (ITS#5221) cache? of parent failes for hdb
by hyc＠symas.com 12 Nov '07

12 Nov '07

Dan.Oscarsson(a)tietoenator.com wrote: > Full_Name: Dan Oscarsson > Version: 2.3.32 > OS: SLES 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.15.240.60) > From this I suspect that it is the cache of which parent node belongs to > that gets corrupted. Or can it be something else? > What more could I do to trace down the bug? > I do not know if the above information is enough for you to find what is > wrong? Cannot include data as it contains company internal information and > a simple test program did not give the same error. > I have looked at the code, but it takes some time to understand it when > doing it for the first time. maybe som debugging code could be added > find the place where the bug is. This isn't a lot of information to go on. If you can create a test program that shows the problem occurring, using dummy data, that would help. -- -- 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#5230) pagedresults ignores sizelimit for rootDN
by hyc＠OpenLDAP.org 12 Nov '07

12 Nov '07

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc Performing a search as rootDN with both an explicit sizelimit and pagedresults causes the sizelimit to be ignored. Using the sizelimit and no pagedresults correctly honors the specified limit. This may also affect RE23, I haven't looked.

1 0

Re: (ITS#5227) old dsn acceptance
by hyc＠symas.com 12 Nov '07

12 Nov '07

aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.4.6 > OS: Linux EL 4 > URL: http://users.wpi.edu/~aej/schema_init.diff > Submission from: (NULL) (130.215.24.208) > > > Old CSN stamps are not accepted by 2.4.6. I guess they must be _very_ old, > since there is a "2/3" CSN conversion in the release. > > The stamps are of the form: YYYYMMDDHH:MM:SSZ That's the format from when CSNs were introduced in OpenLDAP 2.1. > Perhaps I'm the only person in the OpenLDAP universe who might see this problem, > but I adapted the 2/3 conversion for these old fields. It seems a bit odd to be introducing support for that format now in 2.4, when it was completely unsupported in 2.2 and 2.3. I.e., why wasn't this issue raised during the migration to/thru either 2.2 or 2.3? I'm inclined to reject this patch; you can fix it in LDIF using sed or perl and never have to think about it again. -- -- 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#5225) unexpected results in slapadd
by hyc＠symas.com 12 Nov '07

12 Nov '07

aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.4.6 > OS: RHEL4 i686 > URL: http://users.wpi.edu/~aej > Submission from: (NULL) (130.215.24.208) > > > Dependent on load flags (I normally have been using -w -q), I get various > results. Assertion failure, segfault, or success. > I've placed DB_CONFIG, users.ldapv2.2007.11.08.ldif, and slapd.utility5.conf in > http://users.wpi.edu/~aej/ Thanks, now fixed in HEAD. -- -- 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#5229) `make install' writes to the source tree as root
by hyc＠symas.com 12 Nov '07

12 Nov '07

mills(a)cc.umanitoba.ca wrote: > Full_Name: Gary Mills > Version: openldap-2.3.38 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.78.105.29) > > > The usual procedure is to run `configure' and `make' in the install tree as an > ordinary user, and then to run `make install' there as root. This install > procedure > writes to the install tree as root. In some cases, it actually relinks a > shared > library as root. We build on one server and install on another, where the > install > tree is mounted read-only. These errors prevent installation in this case. > Really, it shouldn't be doing relinking at that point, when running as root. > Perhaps it could do it earlier, during the compile step. I had to do a `make > install' as root in libraries/liblber on build server and then modify the > Makefiles > in libraries/libldap and libraries/libldap_r to link with the installed > library, > in order to avoid the relink on the install server. This worked, but is not a > good solution. Agreed, it should not be relinking, ever, but that's libtool. I've submitted patches to libtool to correct this a number of times over the past several years but the problem remains, and it's our policy to avoid using customized OpenLDAP-specific versions of the GNU tools so we no longer provide patched versions of libtool in our CVS. In the meantime, there's no reason for this to be affecting your source tree. You can always build using an object tree separate from the source tree. And you can always use "make install DESTDIR=/tmp/foo" on the build system to create an alternate hierarchy that can then be copied to any other machine. Since there is no fundamental bug in OpenLDAP here, 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#5228) Patches for minor typos in man pages
by sam.varshavchik＠gmail.com 12 Nov '07

12 Nov '07

------=_Part_2936_9723584.1194823201662 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline No problem. Here are the fixes diff-ed against CVS HEAD: http://www.tldp.org/manpages/openldap-2.4.6-manpatch.txt This is also attached to this message. On Nov 11, 2007 3:18 PM, Gavin Henry <ghenry(a)openldap.org> wrote: > sam.varshavchik(a)gmail.com wrote: > > Full_Name: Sam Varshavchik > > Version: 2.4.6 > > OS: Linux > > URL: http://www.tldp.org/manpages/openldap-2.4.6-manpatches.tar.gz > > Submission from: (NULL) (216.254.115.190) > > > > > > Attached please find patches for minor typos and fixes to various manual pages > > in openldap 2.4.6 > > > > http://www.tldp.org/manpages/openldap-2.4.6-manpatches.tar.gz > > > > > > > > Thanks. > > It may be using doing a cvs diff to create one doc patch? > > -- > Kind Regards, > > Gavin Henry. > OpenLDAP Engineering Team. > > E ghenry(a)OpenLDAP.org > > Community developed LDAP software. > > http://www.openldap.org/project/ > ------=_Part_2936_9723584.1194823201662 Content-Type: text/plain; name=openldap-2.4.6-manpatch.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_f8w6u5m50 Content-Disposition: attachment; filename=openldap-2.4.6-manpatch.txt SW5kZXg6IGRvYy9tYW4vbWFuMS9sZGFwbW9kaWZ5LjEKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3Jl cG8vT3BlbkxEQVAvcGtnL2xkYXAvZG9jL21hbi9tYW4xL2xkYXBtb2RpZnkuMSx2CnJldHJpZXZp bmcgcmV2aXNpb24gMS41MQpkaWZmIC1VMyAtcjEuNTEgbGRhcG1vZGlmeS4xCi0tLSBkb2MvbWFu L21hbjEvbGRhcG1vZGlmeS4xCTIgSmFuIDIwMDcgMTk6MDA6NTMgLTAwMDAJMS41MQorKysgZG9j L21hbi9tYW4xL2xkYXBtb2RpZnkuMQkxMSBOb3YgMjAwNyAyMzoxNjowNCAtMDAwMApAQCAtMzI2 LDYgKzMyNiw3IEBACiAgICAgdGl0bGU6IHRoZSB3b3JsZCdzIG1vc3QgZmFtb3VzIG15dGhpY2Fs IG1hbmFnZXIKICAgICBtYWlsOiBiamVuc2VuQGV4YW1wbGUuY29tCiAgICAgdWlkOiBiamVuc2Vu CisuZmkKIC5MUAogdGhlIGNvbW1hbmQ6CiAuTFAKQEAgLTM0NCw2ICszNDUsNyBAQAogLm5mCiAg ICAgZG46IGNuPUJhcmJhcmEgSmVuc2VuLGRjPWV4YW1wbGUsZGM9Y29tCiAgICAgY2hhbmdldHlw ZTogZGVsZXRlCisuZmkKIC5MUAogdGhlIGNvbW1hbmQ6CiAuTFAKSW5kZXg6IGRvYy9tYW4vbWFu My9sZGFwX2V4dGVuZGVkX29wZXJhdGlvbi4zCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9yZXBvL09w ZW5MREFQL3BrZy9sZGFwL2RvYy9tYW4vbWFuMy9sZGFwX2V4dGVuZGVkX29wZXJhdGlvbi4zLHYK cmV0cmlldmluZyByZXZpc2lvbiAxLjUKZGlmZiAtVTMgLXIxLjUgbGRhcF9leHRlbmRlZF9vcGVy YXRpb24uMwotLS0gZG9jL21hbi9tYW4zL2xkYXBfZXh0ZW5kZWRfb3BlcmF0aW9uLjMJMiBKYW4g MjAwNyAxOTowMDo1NCAtMDAwMAkxLjUKKysrIGRvYy9tYW4vbWFuMy9sZGFwX2V4dGVuZGVkX29w ZXJhdGlvbi4zCTExIE5vdiAyMDA3IDIzOjE2OjA0IC0wMDAwCkBAIC0zMiw3ICszMiw3IEBACiBj b25zdCBzdHJ1Y3QgYmVydmFsICpcZklyZXF1ZXN0ZGF0YVxmQiwKIExEQVBDb250cm9sICoqXGZJ c2N0cmxzXGZCLAogTERBUENvbnRyb2wgKipcZkljY3RybHNcZkIsCi1jaGFyICoqXGZJcmV0b2lk cFxmQjsKK2NoYXIgKipcZklyZXRvaWRwXGZCLAogc3RydWN0IGJlcnZhbCAqKlxmSXJldGRhdGFw XGZCICk7CiAuUkUKIC5TSCBERVNDUklQVElPTgpJbmRleDogZG9jL21hbi9tYW4zL2xkYXBfZ2V0 X3ZhbHVlcy4zCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9yZXBvL09wZW5MREFQL3BrZy9sZGFwL2Rv Yy9tYW4vbWFuMy9sZGFwX2dldF92YWx1ZXMuMyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xOQpk aWZmIC1VMyAtcjEuMTkgbGRhcF9nZXRfdmFsdWVzLjMKLS0tIGRvYy9tYW4vbWFuMy9sZGFwX2dl dF92YWx1ZXMuMwkyIEphbiAyMDA3IDE5OjI1OjE2IC0wMDAwCTEuMTkKKysrIGRvYy9tYW4vbWFu My9sZGFwX2dldF92YWx1ZXMuMwkxMSBOb3YgMjAwNyAyMzoxNjowNCAtMDAwMApAQCAtMTcsMzIg KzE3LDMyIEBACiAuZnQKIExEQVAgKmxkOwogTERBUE1lc3NhZ2UgKmVudHJ5OwotY2hhciAqYXR0 cgorY2hhciAqYXR0cjsKIC5MUAogLmZ0IEIKIHN0cnVjdCBiZXJ2YWwgKipsZGFwX2dldF92YWx1 ZXNfbGVuKGxkLCBlbnRyeSwgYXR0cikKIC5mdAogTERBUCAqbGQ7CiBMREFQTWVzc2FnZSAqZW50 cnk7Ci1jaGFyICphdHRyCitjaGFyICphdHRyOwogLkxQCiAuZnQgQgotbGRhcF9jb3VudF92YWx1 ZXModmFscykKK2ludCBsZGFwX2NvdW50X3ZhbHVlcyh2YWxzKQogLmZ0CiBjaGFyICoqdmFsczsK IC5MUAogLmZ0IEIKLWxkYXBfY291bnRfdmFsdWVzX2xlbih2YWxzKQoraW50IGxkYXBfY291bnRf dmFsdWVzX2xlbih2YWxzKQogLmZ0CiBzdHJ1Y3QgYmVydmFsICoqdmFsczsKIC5MUAogLmZ0IEIK LWxkYXBfdmFsdWVfZnJlZSh2YWxzKQordm9pZCBsZGFwX3ZhbHVlX2ZyZWUodmFscykKIC5mdAog Y2hhciAqKnZhbHM7CiAuTFAKIC5mdCBCCi1sZGFwX3ZhbHVlX2ZyZWVfbGVuKHZhbHMpCit2b2lk IGxkYXBfdmFsdWVfZnJlZV9sZW4odmFscykKIC5mdAogc3RydWN0IGJlcnZhbCAqKnZhbHM7CiAu U0ggREVTQ1JJUFRJT04KSW5kZXg6IGRvYy9tYW4vbWFuMy9sZGFwX3BhcnNlX3Zsdl9jb250cm9s LjMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3JlcG8vT3BlbkxEQVAvcGtnL2xkYXAvZG9jL21hbi9t YW4zL2xkYXBfcGFyc2Vfdmx2X2NvbnRyb2wuMyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS41CmRp ZmYgLVUzIC1yMS41IGxkYXBfcGFyc2Vfdmx2X2NvbnRyb2wuMwotLS0gZG9jL21hbi9tYW4zL2xk YXBfcGFyc2Vfdmx2X2NvbnRyb2wuMwk2IEF1ZyAyMDA3IDE1OjI0OjE0IC0wMDAwCTEuNQorKysg ZG9jL21hbi9tYW4zL2xkYXBfcGFyc2Vfdmx2X2NvbnRyb2wuMwkxMSBOb3YgMjAwNyAyMzoxNjow NCAtMDAwMApAQCAtMTIsNyArMTIsNyBAQAogI2luY2x1ZGUgPGxkYXAuaD4KIC5MUAogLmZ0IEIK LWludCBsZGFwX3BhcnNlX3Zsdl9jb250cm9sKCBsZCwgY3RybHAsIHRhcmdldF9wb3NwLCBsaXN0 X2NvdW50cCwgY29udGV4dHAsIGVycmNvZGVwICk7ICAKK2ludCBsZGFwX3BhcnNlX3Zsdl9jb250 cm9sKCBsZCwgY3RybHAsIHRhcmdldF9wb3NwLCBsaXN0X2NvdW50cCwgY29udGV4dHAsIGVycmNv ZGVwICkKIC5mdAogTERBUCAqbGQ7CiBMREFQQ29udHJvbCAqKmN0cmxwOwpJbmRleDogZG9jL21h bi9tYW4zL2xkYXBfdXJsLjMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3JlcG8vT3BlbkxEQVAvcGtn L2xkYXAvZG9jL21hbi9tYW4zL2xkYXBfdXJsLjMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjIK ZGlmZiAtVTMgLXIxLjIyIGxkYXBfdXJsLjMKLS0tIGRvYy9tYW4vbWFuMy9sZGFwX3VybC4zCTI0 IEp1bCAyMDA3IDE3OjExOjM5IC0wMDAwCTEuMjIKKysrIGRvYy9tYW4vbWFuMy9sZGFwX3VybC4z CTExIE5vdiAyMDA3IDIzOjE2OjA0IC0wMDAwCkBAIC0zMSw3ICszMSw3IEBACiB9IExEQVBVUkxE ZXNjOwogLkxQCiAuZnQgQgotbGRhcF9mcmVlX3VybGRlc2MoIExEQVBVUkxEZXNjICpsdWRwICkK K3ZvaWQgbGRhcF9mcmVlX3VybGRlc2MoIExEQVBVUkxEZXNjICpsdWRwICk7CiAuU0ggREVTQ1JJ UFRJT04KIFRoZXNlIHJvdXRpbmVzIHN1cHBvcnQgdGhlIHVzZSBvZiBMREFQIFVSTHMgKFVuaWZv cm0gUmVzb3VyY2UgTG9jYXRvcnMpCiBhcyBkZXRhaWxlZCBpbiBSRkMgNDUxNi4gIExEQVAgVVJM cyBsb29rIGxpa2UgdGhpczoKSW5kZXg6IGRvYy9tYW4vbWFuNS9zbGFwby1wcG9saWN5LjUKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQpSQ1MgZmlsZTogL3JlcG8vT3BlbkxEQVAvcGtnL2xkYXAvZG9jL21hbi9tYW41L3Ns YXBvLXBwb2xpY3kuNSx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xOApkaWZmIC1VMyAtcjEuMTgg c2xhcG8tcHBvbGljeS41Ci0tLSBkb2MvbWFuL21hbjUvc2xhcG8tcHBvbGljeS41CTI0IEp1bCAy MDA3IDE3OjExOjM5IC0wMDAwCTEuMTgKKysrIGRvYy9tYW4vbWFuNS9zbGFwby1wcG9saWN5LjUJ MTEgTm92IDIwMDcgMjM6MTY6MDQgLTAwMDAKQEAgLTUwMyw3ICs1MDMsNyBAQAogLkIgdXNlclBh c3N3b3JkCiAuUAogVGhlCi0uYiB1c2VyUGFzc3dvcmQKKy5CIHVzZXJQYXNzd29yZAogYXR0cmli dXRlIGlzIG5vdCBzdHJpY3RseSBwYXJ0IG9mIHRoZQogLkIgcHBvbGljeQogbW9kdWxlLiAgSXQg aXMsIGhvd2V2ZXIsIHRoZSBhdHRyaWJ1dGUgdGhhdCBpcyB0cmFja2VkIGFuZCBjb250cm9sbGVk CkluZGV4OiBkb2MvbWFuL21hbjgvc2xhcGFjbC44Cj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9yZXBv L09wZW5MREFQL3BrZy9sZGFwL2RvYy9tYW4vbWFuOC9zbGFwYWNsLjgsdgpyZXRyaWV2aW5nIHJl dmlzaW9uIDEuMTQKZGlmZiAtVTMgLXIxLjE0IHNsYXBhY2wuOAotLS0gZG9jL21hbi9tYW44L3Ns YXBhY2wuOAkxMSBKYW4gMjAwNyAxNToyNzoxMSAtMDAwMAkxLjE0CisrKyBkb2MvbWFuL21hbjgv c2xhcGFjbC44CTExIE5vdiAyMDA3IDIzOjE2OjA0IC0wMDAwCkBAIC0xMCw3ICsxMCw3IEBACiAu QiBbXC1EIGF1dGhjRE4gfCBcLVUgYXV0aGNJRF0KIC5CIFtcLWYgc2xhcGQuY29uZl0KIC5CIFtc LUYgY29uZmRpcl0KLS5CIFtcLW8gbmFtZVs9dmFsdWVdCisuQiBbXC1vIG5hbWVbPXZhbHVlXV0K IC5CIFtcLXVdCiAuQiBbXC12XQogLkIgW1wtWCBhdXRoeklEIHwgXC1vIGF1dGh6RE49RE5dCklu ZGV4OiBkb2MvbWFuL21hbjgvc2xhcGFkZC44Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9yZXBvL09w ZW5MREFQL3BrZy9sZGFwL2RvYy9tYW4vbWFuOC9zbGFwYWRkLjgsdgpyZXRyaWV2aW5nIHJldmlz aW9uIDEuNDgKZGlmZiAtVTMgLXIxLjQ4IHNsYXBhZGQuOAotLS0gZG9jL21hbi9tYW44L3NsYXBh ZGQuOAkxNyBPY3QgMjAwNyAyMTowODo0OCAtMDAwMAkxLjQ4CisrKyBkb2MvbWFuL21hbjgvc2xh cGFkZC44CTExIE5vdiAyMDA3IDIzOjE2OjA0IC0wMDAwCkBAIC0xNSw3ICsxNSw3IEBACiAuQiBb XC1qIGxpbmVub10KIC5CIFtcLWwgbGRpZi1maWxlXQogLkIgW1wtbiBkYm51bV0KLS5CIFtcLW8g bmFtZVs9dmFsdWVdCisuQiBbXC1vIG5hbWVbPXZhbHVlXV0KIC5CIFtcLXFdCiAuQiBbXC1zXQog LkIgW1wtUyBTSURdCkluZGV4OiBkb2MvbWFuL21hbjgvc2xhcGF1dGguOAo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJD UyBmaWxlOiAvcmVwby9PcGVuTERBUC9wa2cvbGRhcC9kb2MvbWFuL21hbjgvc2xhcGF1dGguOCx2 CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMgpkaWZmIC1VMyAtcjEuMTIgc2xhcGF1dGguOAotLS0g ZG9jL21hbi9tYW44L3NsYXBhdXRoLjgJMjQgSnVsIDIwMDcgMTc6MTE6MzkgLTAwMDAJMS4xMgor KysgZG9jL21hbi9tYW44L3NsYXBhdXRoLjgJMTEgTm92IDIwMDcgMjM6MTY6MDQgLTAwMDAKQEAg LTksNyArOSw3IEBACiAuQiBbXC1mIHNsYXBkLmNvbmZdCiAuQiBbXC1GIGNvbmZkaXJdCiAuQiBb XC1NIG1lY2hdCi0uQiBbXC1vIG5hbWVbPXZhbHVlXQorLkIgW1wtbyBuYW1lWz12YWx1ZV1dCiAu QiBbXC1SIHJlYWxtXQogLkIgW1wtVSBhdXRoY0lEXQogLkIgW1wtdl0KSW5kZXg6IGRvYy9tYW4v bWFuOC9zbGFwY2F0LjgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3JlcG8vT3BlbkxEQVAvcGtnL2xk YXAvZG9jL21hbi9tYW44L3NsYXBjYXQuOCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4zNQpkaWZm IC1VMyAtcjEuMzUgc2xhcGNhdC44Ci0tLSBkb2MvbWFuL21hbjgvc2xhcGNhdC44CTIyIEp1bCAy MDA3IDE2OjMwOjQ2IC0wMDAwCTEuMzUKKysrIGRvYy9tYW4vbWFuOC9zbGFwY2F0LjgJMTEgTm92 IDIwMDcgMjM6MTY6MDUgLTAwMDAKQEAgLTE1LDcgKzE1LDcgQEAKIC5CIFtcLWddCiAuQiBbXC1s IGxkaWYtZmlsZV0KIC5CIFtcLW4gZGJudW1dCi0uQiBbXC1vIG5hbWVbPXZhbHVlXQorLkIgW1wt byBuYW1lWz12YWx1ZV1dCiAuQiBbXC1zIHN1YnRyZWUtZG5dCiAuQiBbXC12XQogLkIgCkluZGV4 OiBkb2MvbWFuL21hbjgvc2xhcGRuLjgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3JlcG8vT3BlbkxE QVAvcGtnL2xkYXAvZG9jL21hbi9tYW44L3NsYXBkbi44LHYKcmV0cmlldmluZyByZXZpc2lvbiAx LjEyCmRpZmYgLVUzIC1yMS4xMiBzbGFwZG4uOAotLS0gZG9jL21hbi9tYW44L3NsYXBkbi44CTI0 IEp1bCAyMDA3IDE3OjExOjM5IC0wMDAwCTEuMTIKKysrIGRvYy9tYW4vbWFuOC9zbGFwZG4uOAkx MSBOb3YgMjAwNyAyMzoxNjowNSAtMDAwMApAQCAtOSw3ICs5LDcgQEAKIC5CIFtcLWYgc2xhcGQu Y29uZl0KIC5CIFtcLUYgY29uZmRpcl0KIC5CIFtcLU4gfCBcLVBdCi0uQiBbXC1vIG5hbWVbPXZh bHVlXQorLkIgW1wtbyBuYW1lWz12YWx1ZV1dCiAuQiBbXC12XQogLkIgRE4gWy4uLl0KIC5MUApJ bmRleDogZG9jL21hbi9tYW44L3NsYXBpbmRleC44Cj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9yZXBv L09wZW5MREFQL3BrZy9sZGFwL2RvYy9tYW4vbWFuOC9zbGFwaW5kZXguOCx2CnJldHJpZXZpbmcg cmV2aXNpb24gMS4yNwpkaWZmIC1VMyAtcjEuMjcgc2xhcGluZGV4LjgKLS0tIGRvYy9tYW4vbWFu OC9zbGFwaW5kZXguOAk0IE9jdCAyMDA3IDA5OjAyOjU3IC0wMDAwCTEuMjcKKysrIGRvYy9tYW4v bWFuOC9zbGFwaW5kZXguOAkxMSBOb3YgMjAwNyAyMzoxNjowNSAtMDAwMApAQCAtMTMsNyArMTMs NyBAQAogLkIgW1wtRiBjb25mZGlyXQogLkIgW1wtZ10KIC5CIFtcLW4gZGJudW1dCi0uQiBbXC1v IG5hbWVbPXZhbHVlXQorLkIgW1wtbyBuYW1lWz12YWx1ZV1dCiAuQiBbXC1xXQogLkIgW1wtdl0K IC5CIFthdHRyXSBbLi4uXQpJbmRleDogZG9jL21hbi9tYW44L3NsYXB0ZXN0LjgKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQpSQ1MgZmlsZTogL3JlcG8vT3BlbkxEQVAvcGtnL2xkYXAvZG9jL21hbi9tYW44L3NsYXB0ZXN0 LjgsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTQKZGlmZiAtVTMgLXIxLjE0IHNsYXB0ZXN0LjgK LS0tIGRvYy9tYW4vbWFuOC9zbGFwdGVzdC44CTE0IEF1ZyAyMDA3IDExOjUzOjM3IC0wMDAwCTEu MTQKKysrIGRvYy9tYW4vbWFuOC9zbGFwdGVzdC44CTExIE5vdiAyMDA3IDIzOjE2OjA1IC0wMDAw CkBAIC04LDcgKzgsNyBAQAogLkIgW1wtZCBsZXZlbF0KIC5CIFtcLWYgc2xhcGQuY29uZl0KIC5C IFtcLUYgY29uZmRpcl0KLS5CIFtcLW8gbmFtZVs9dmFsdWVdCisuQiBbXC1vIG5hbWVbPXZhbHVl XV0KIC5CIFtcLVFdCiAuQiBbXC11XQogLkIgW1wtdl0K ------=_Part_2936_9723584.1194823201662--

1 0

(ITS#5229) `make install' writes to the source tree as root
by mills＠cc.umanitoba.ca 11 Nov '07

11 Nov '07

Full_Name: Gary Mills Version: openldap-2.3.38 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.78.105.29) The usual procedure is to run `configure' and `make' in the install tree as an ordinary user, and then to run `make install' there as root. This install procedure writes to the install tree as root. In some cases, it actually relinks a shared library as root. We build on one server and install on another, where the install tree is mounted read-only. These errors prevent installation in this case. Here are some of the errors: cd overlays; make dynamic sh: slapd.conf.tmp: cannot create *** Error code 1 make: Fatal error: Command failed for target `all-cffiles' cd overlays; make dynamic touch: cannot change times on all-cffiles *** Error code 1 make: Fatal error: Command failed for target `all-cffiles' sh: ldapcompare.1.tmp: cannot create *** Error code 1 make: Fatal error: Command failed for target `all-common' The first few were fixed in servers/slapd/Makefile.in by putting all-cffiles and slapd.conf.tmp in /tmp instead of in the source tree. The man page error was fixed build/man.mk by putting the temporary man pages like $$page.$(TMP_SUFFIX) into /tmp. The relinking error looked like this: Entering subdirectory libldap ../../build/shtool mkdir -p /usr/local/lib /bin/sh ../..//libtool --mode=install ../../build/shtool install -c -m 644 libldap.la /usr/local/lib libtool: install: warning: relinking `libldap.la' ... mv: cannot rename libldap-2.3.so.0.2.26 to libldap-2.3.so.0.2.26U: Read-only file system libtool: install: error: relink `libldap.la' with the above command before installing it *** Error code 1 make: Fatal error: Command failed for target `install-local' Really, it shouldn't be doing relinking at that point, when running as root. Perhaps it could do it earlier, during the compile step. I had to do a `make install' as root in libraries/liblber on build server and then modify the Makefiles in libraries/libldap and libraries/libldap_r to link with the installed library, in order to avoid the relink on the install server. This worked, but is not a good solution.

1 0

Re: (ITS#5228) Patches for minor typos in man pages
by ghenry＠OpenLDAP.org 11 Nov '07

11 Nov '07

sam.varshavchik(a)gmail.com wrote: > Full_Name: Sam Varshavchik > Version: 2.4.6 > OS: Linux > URL: http://www.tldp.org/manpages/openldap-2.4.6-manpatches.tar.gz > Submission from: (NULL) (216.254.115.190) > > > Attached please find patches for minor typos and fixes to various manual pages > in openldap 2.4.6 > > http://www.tldp.org/manpages/openldap-2.4.6-manpatches.tar.gz > > > Thanks. It may be using doing a cvs diff to create one doc patch? -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: Contrib: addpartial overlay (ITS#3593)
by ghenry＠OpenLDAP.org 11 Nov '07

11 Nov '07

dhawes(a)vt.edu wrote: > On Friday 27 July 2007 05:20, ghenry(a)openldap.org wrote: >> Hi David, >> >> http://www.openldap.org/devel/cvsweb.cgi/contrib/slapd-modules/addpartial/ >> >> Will be pushed out in the next 2.4 beta. >> >> Please bear in mind that you will be looking after this overlay, so test >> as often as you can and re-submit and changes during our release cycle. >> >> Thank you for your contribution. > > Changes to work properly with 2.4.6 are at: > > ftp://ftp.openldap.org/incoming/david_hawes-addpartial-071109.tgz > > Thanks, > > dave > > Will take a look over the next week. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

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

10 Nov '07

Hi, Le Sam 10 novembre 2007 16:37, ando(a)sys-net.it a écrit : >> Below I represent sets in {element1, element2} notation, to describe the >> current behaviour (in HEAD) for slap_set_join on the '+' operation: >> - {"One", "Two"} + {"Three", "Four"} ==> {"OneThree", "OneFour", >> "TwoThree", "TwoFour"} >> - {"One", "Two"} + {""} ==> {"One", "Two"} >> - {"One", "Two"} + {NULL} ==> {"One", "Two"} > > Although sets lack a specification, I think this behavior is desirable > in many cases: adding NULL is equivalent to adding EMPTY (""). The problem is that {NULL} is equivalent to NULL, ie the empty set. >> Consider the following set: >> set="[ldap:///] + [ldap:///<searchbase>??<scope>?<filter1>] + >> [??<scope>?<filter2>]" >> >> Assuming [ldap:///<searchbase>??<scope>?<filter1>] returns a DN, this >> works. However, if [ldap:///<searchbase>??<scope>?<filter1>] returns no >> entries, this value is NULL. Therefore, the rest of the set becomes: >> "[ldap:///] + {NULL} + [??<scope>?<filter2>]" >> ...which is handed to the '+' operation in slap_set_join, to become: >> [ldap:///??<scope>?<filter2>] >> ...which obviously isn't valid. > > Well, it is valid: it's an URI with an EMPTY DN. In terms of LDAP, yes, but it can cause security issues here, as the EMPTY DN is at a higher level that any one which would have been returned by a normal result. >> The attached patch changes the last case of the current behaviour for >> slap_set_join on the '+' operation. This was already the behaviour >> before version 1.24.2.6 Thu Sep 13 20:43:29 2007 UTC: >> - {"One", "Two"} + {NULL} ==> {NULL} > > This is different from the above behavior, although it makes sense on > its own. Probably we need two different addition operators: one > inclusive (NULL is equivalent to "") and one exclusive (NULL nullifies > the concatenation). > > Comments? No problem in having the two operators. I just think the normal behavior is to return NULL, has in term of sets the cartesian product A x NULL returns NULL, not A. Regards, Raphael Ouazana.

1 0

(ITS#5228) Patches for minor typos in man pages
by sam.varshavchik＠gmail.com 10 Nov '07

10 Nov '07

Full_Name: Sam Varshavchik Version: 2.4.6 OS: Linux URL: http://www.tldp.org/manpages/openldap-2.4.6-manpatches.tar.gz Submission from: (NULL) (216.254.115.190) Attached please find patches for minor typos and fixes to various manual pages in openldap 2.4.6 http://www.tldp.org/manpages/openldap-2.4.6-manpatches.tar.gz

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 10 Nov '07

10 Nov '07

Jonathan Clarke wrote: > Pierangelo Masarati a écrit : >>> The patch attached corrects this problem on RE23 and HEAD for me >>> and doesn't have any side effects on our test set. However, it >>> may not be the "right" way - please correct if necessary! >> It seems to work correctly, but there seems to be an easier fix: just >> NULL out the pointer to lset/rset, respectively. I'm patching the >> code this way, please test if you get a chance. > > Whoops - looks like I spoke too soon. After more testing, I've > realized that the same commit this patch applied to actually changed the > behaviour of the "+" operation in the slap_set_join() function when > operating on empty sets, and can cause errors. > > The attached proposed patch restores the original design. The difference > is minor, but can cause slapd to hang indefinitely on some sets, like > the one in the generic example below. > > I understand an element in a set can have 3 possible states: > 1) non-empty string (example: "cn=user,ou=people,dc=example,dc=com") > 2) empty string (example: "", BER_BVISEMPTY) > 3) NULL (BER_BVISNULL) > > Below I represent sets in {element1, element2} notation, to describe the > current behaviour (in HEAD) for slap_set_join on the '+' operation: > - {"One", "Two"} + {"Three", "Four"} ==> {"OneThree", "OneFour", > "TwoThree", "TwoFour"} > - {"One", "Two"} + {""} ==> {"One", "Two"} > - {"One", "Two"} + {NULL} ==> {"One", "Two"} Although sets lack a specification, I think this behavior is desirable in many cases: adding NULL is equivalent to adding EMPTY (""). > Consider the following set: > set="[ldap:///] + [ldap:///<searchbase>??<scope>?<filter1>] + > [??<scope>?<filter2>]" > > Assuming [ldap:///<searchbase>??<scope>?<filter1>] returns a DN, this > works. However, if [ldap:///<searchbase>??<scope>?<filter1>] returns no > entries, this value is NULL. Therefore, the rest of the set becomes: > "[ldap:///] + {NULL} + [??<scope>?<filter2>]" > ...which is handed to the '+' operation in slap_set_join, to become: > [ldap:///??<scope>?<filter2>] > ...which obviously isn't valid. Well, it is valid: it's an URI with an EMPTY DN. > The attached patch changes the last case of the current behaviour for > slap_set_join on the '+' operation. This was already the behaviour > before version 1.24.2.6 Thu Sep 13 20:43:29 2007 UTC: > - {"One", "Two"} + {NULL} ==> {NULL} This is different from the above behavior, although it makes sense on its own. Probably we need two different addition operators: one inclusive (NULL is equivalent to "") and one exclusive (NULL nullifies the concatenation). Comments? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: Contrib: addpartial overlay (ITS#3593)
by dhawes＠vt.edu 09 Nov '07

09 Nov '07

On Friday 27 July 2007 05:20, ghenry(a)openldap.org wrote: > Hi David, > > http://www.openldap.org/devel/cvsweb.cgi/contrib/slapd-modules/addpartial/ > > Will be pushed out in the next 2.4 beta. > > Please bear in mind that you will be looking after this overlay, so test > as often as you can and re-submit and changes during our release cycle. > > Thank you for your contribution. Changes to work properly with 2.4.6 are at: ftp://ftp.openldap.org/incoming/david_hawes-addpartial-071109.tgz Thanks, dave

1 0

Re: (ITS#5226) ldapadd: invalid format (line 1) entry: ""
by quanah＠zimbra.com 09 Nov '07

09 Nov '07

--On Thursday, November 08, 2007 11:59 PM +0000 babu.shanmugham(a)gmail.com wrote: > Full_Name: Babu Shanmugam > Version: 2.1 > OS: windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.230.0.45) > > > Hey, > I am stuck u with this error....ldapadd: invalid format (line 1) entry: > "".... > > I am not sure which file to change, either init.ldif or slapd.conf. My > files contents looks like below. > > 1..slapd.conf. > > database bdb > suffix "dc=mymozilla,dc=com" > rootdn "cn=Manager,dc=mymozilla,dc=com" > rootpw passmozilla > directory C:/openldap/var/openldap-data > index objectClass eq > > 2. init.ldif : > > dn: dc=mymozilla,dc=com > objectClass: eq > objectClass: organization > objectClass: eq > description: Description of your domain > o: Something else about your domain > dc: mymozilla > > When i run this command, ldapadd -x -D "cn=Manager,dc=mymozilla,dc=com" -w > passmozilla -v -f init.ldif , i get the following error > > init.ldif > ldap_initialize( <DEFAULT> ) > ldapadd: invalid format (line 1) entry: "" Usage questions should be directed to openldap-software(a)openldap.org In answer to your question, your "objectClass" lines are very wrong. There is no objectClass named "eq", and you shouldn't have duplicate objectClass lines. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5227) old dsn acceptance
by aej＠wpi.edu 09 Nov '07

09 Nov '07

Full_Name: Allan E. Johannesen Version: 2.4.6 OS: Linux EL 4 URL: http://users.wpi.edu/~aej/schema_init.diff Submission from: (NULL) (130.215.24.208) Old CSN stamps are not accepted by 2.4.6. I guess they must be _very_ old, since there is a "2/3" CSN conversion in the release. The stamps are of the form: YYYYMMDDHH:MM:SSZ Perhaps I'm the only person in the OpenLDAP universe who might see this problem, but I adapted the 2/3 conversion for these old fields.

1 0

Re: (ITS#4860) Sets' enhancement
by jclarke＠linagora.com 09 Nov '07

09 Nov '07

This is a multi-part message in MIME format. --------------080208090603090201080004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Pierangelo Masarati a écrit : >> The patch attached corrects this problem on RE23 and HEAD for me >> and doesn't have any side effects on our test set. However, it >> may not be the "right" way - please correct if necessary! > > It seems to work correctly, but there seems to be an easier fix: just > NULL out the pointer to lset/rset, respectively. I'm patching the > code this way, please test if you get a chance. Whoops - looks like I spoke too soon. After more testing, I've realized that the same commit this patch applied to actually changed the behaviour of the "+" operation in the slap_set_join() function when operating on empty sets, and can cause errors. The attached proposed patch restores the original design. The difference is minor, but can cause slapd to hang indefinitely on some sets, like the one in the generic example below. I understand an element in a set can have 3 possible states: 1) non-empty string (example: "cn=user,ou=people,dc=example,dc=com") 2) empty string (example: "", BER_BVISEMPTY) 3) NULL (BER_BVISNULL) Below I represent sets in {element1, element2} notation, to describe the current behaviour (in HEAD) for slap_set_join on the '+' operation: - {"One", "Two"} + {"Three", "Four"} ==> {"OneThree", "OneFour", "TwoThree", "TwoFour"} - {"One", "Two"} + {""} ==> {"One", "Two"} - {"One", "Two"} + {NULL} ==> {"One", "Two"} Consider the following set: set="[ldap:///] + [ldap:///<searchbase>??<scope>?<filter1>] + [??<scope>?<filter2>]" Assuming [ldap:///<searchbase>??<scope>?<filter1>] returns a DN, this works. However, if [ldap:///<searchbase>??<scope>?<filter1>] returns no entries, this value is NULL. Therefore, the rest of the set becomes: "[ldap:///] + {NULL} + [??<scope>?<filter2>]" ...which is handed to the '+' operation in slap_set_join, to become: [ldap:///??<scope>?<filter2>] ...which obviously isn't valid. The attached patch changes the last case of the current behaviour for slap_set_join on the '+' operation. This was already the behaviour before version 1.24.2.6 Thu Sep 13 20:43:29 2007 UTC: - {"One", "Two"} + {NULL} ==> {NULL} Thus, in the above example, the whole set would resolve to NULL, and access is not granted. Sorry for the confusion. Can this patch be integrated? Regards, Jonathan -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com --------------080208090603090201080004 Content-Type: text/x-patch; name="jonathan-clarke-20071109.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="jonathan-clarke-20071109.patch" --- servers/slapd/sets.c.orig 2007-11-01 16:47:35.000000000 +0100 +++ servers/slapd/sets.c 2007-11-01 16:48:21.000000000 +0100 @@ -277,25 +277,13 @@ j = slap_set_size( lset ); /* handle empty set cases */ - if ( i == 0 ) { - if ( j == 0 ) { - set = cp->set_op->o_tmpcalloc( i * j + 1, sizeof( struct berval ), - cp->set_op->o_tmpmemctx ); - if ( set == NULL ) { - break; - } - BER_BVZERO( &set[ 0 ] ); - break; - - } else { - set = set_dup( cp, lset, SLAP_SET_LREF2REF( op_flags ) ); - lset = NULL; + if ( i == 0 || j == 0 ) { + set = cp->set_op->o_tmpcalloc( i * j + 1, sizeof( struct berval ), + cp->set_op->o_tmpmemctx ); + if ( set == NULL ) { break; } - - } else if ( j == 0 ) { - set = set_dup( cp, rset, SLAP_SET_RREF2REF( op_flags ) ); - rset = NULL; + BER_BVZERO( &set[ 0 ] ); break; } --------------080208090603090201080004--

1 0

RE: (ITS#5215) Use of ln is hardcoded in some files
by emmanuel.duru＠atosorigin.com 09 Nov '07

09 Nov '07

OK it works, thank you. -----Message d'origine----- De : Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] Envoyé : jeudi 8 novembre 2007 15:48 À : emmanuel.duru(a)atosorigin.com Cc : openldap-its(a)openldap.org Objet : RE: (ITS#5215) Use of ln is hardcoded in some files emmanuel.duru(a)atosorigin.com writes: > Then with MSYS, I get an error when running make on servers/slapd > Makefile: in case there is no extra LDFLAG, (...) Try this patch: --- servers/slapd/Makefile.in~ 2007-02-14 16:59:43.000000000 +0100 +++ servers/slapd/Makefile.in 2007-11-08 15:40:32.475898000 +0100 @@ -157,3 +157,3 @@ slapd.def: libbackends.a liboverlays.a version.o - @for i in $(LDFLAGS) ; do \ + @for i in XX $(LDFLAGS) ; do \ path=`expr "$$i" : "-L$.*$"`; \ @@ -169,3 +169,4 @@ base=`expr "$$i" : "-l$.*$"`; \ - for p in $$paths ; do \ + for p in " " $$paths ; do \ + test "x$$p" = "x " && continue ; \ for ext in la dll dll.a a ; do \ -- Regards, Hallvard

1 0

Re: [JunkMail] Re: ITS#5212 command that caused the crash
by hyc＠symas.com 09 Nov '07

09 Nov '07

Tony Earnshaw wrote: > Howard Chu skrev, on 08-11-2007 14:38: > >>> Howard Chu skrev, on 07-11-2007 04:14: >>>> That's all we needed. Fixed now in HEAD. >>> Do you happen to have a patch handy? I don't feel like waiting for >>> 2.4.7, this is the only serious bug I've found to date with 2.4.6. >> http://www.openldap.org/lists/openldap-commit/200711/msg00010.html > > Thank you :) I made a patch from a diff -Naur of the complete CVS > filter.c and the 2.4.6 one, incorporated it into Buchan's rpm spec file, > rebuilt the rpms, installed them and ran the same command. Guess what? > slapd2.4 doesn't report '?undefined' any more, nor crash: Right, I got tired of trying to guess what the filter was from that unhelpful diagnostic. Got rid of "?undefined" last year on Christmas (rev 1.136) and that was part of 2.4.4. This crash was an unfortunate oversight between 2.4.5 and 2.4.6... > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 fd=14 ACCEPT from > PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=0 BIND > dn="cn=admin,dc=billy,dc=demon,dc=nl" method=128 > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=0 BIND > dn="cn=admin,dc=billy,dc=demon,dc=nl" mech=SIMPLE ssf=0 > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=0 RESULT tag=97 err=0 text= > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=1 SRCH > base="dc=billy,dc=demon,dc=nl" scope=2 deref=0 filter="(?facsimileTele > phoneNumber=+4753491111)" > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=1 SRCH > attr=facsimileTelephoneNumber > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=1 SEARCH RESULT tag=101 > err=0 nentries=0 text=inappropriate matching request > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=2 UNBIND > Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 fd=14 closed > > --Tonni -- -- 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#5212 command that caused the crash
by tonni＠hetnet.nl 09 Nov '07

09 Nov '07

Howard Chu skrev, on 08-11-2007 14:38: >> Howard Chu skrev, on 07-11-2007 04:14: > >>> That's all we needed. Fixed now in HEAD. >> >> Do you happen to have a patch handy? I don't feel like waiting for >> 2.4.7, this is the only serious bug I've found to date with 2.4.6. > > http://www.openldap.org/lists/openldap-commit/200711/msg00010.html Thank you :) I made a patch from a diff -Naur of the complete CVS filter.c and the 2.4.6 one, incorporated it into Buchan's rpm spec file, rebuilt the rpms, installed them and ran the same command. Guess what? slapd2.4 doesn't report '?undefined' any more, nor crash: Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 fd=14 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=0 BIND dn="cn=admin,dc=billy,dc=demon,dc=nl" method=128 Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=0 BIND dn="cn=admin,dc=billy,dc=demon,dc=nl" mech=SIMPLE ssf=0 Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=0 RESULT tag=97 err=0 text= Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=1 SRCH base="dc=billy,dc=demon,dc=nl" scope=2 deref=0 filter="(?facsimileTele phoneNumber=+4753491111)" Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=1 SRCH attr=facsimileTelephoneNumber Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=inappropriate matching request Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 op=2 UNBIND Nov 9 06:36:56 tru slapd2.4[2576]: conn=21 fd=14 closed --Tonni -- Tony Earnshaw Email: tonni at hetnet dot nl

1 0

(ITS#5226) ldapadd: invalid format (line 1) entry: ""
by babu.shanmugham＠gmail.com 09 Nov '07

09 Nov '07

Full_Name: Babu Shanmugam Version: 2.1 OS: windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.230.0.45) Hey, I am stuck u with this error....ldapadd: invalid format (line 1) entry: "".... I am not sure which file to change, either init.ldif or slapd.conf. My files contents looks like below. 1..slapd.conf. database bdb suffix "dc=mymozilla,dc=com" rootdn "cn=Manager,dc=mymozilla,dc=com" rootpw passmozilla directory C:/openldap/var/openldap-data index objectClass eq 2. init.ldif : dn: dc=mymozilla,dc=com objectClass: eq objectClass: organization objectClass: eq description: Description of your domain o: Something else about your domain dc: mymozilla When i run this command, ldapadd -x -D "cn=Manager,dc=mymozilla,dc=com" -w passmozilla -v -f init.ldif , i get the following error init.ldif ldap_initialize( <DEFAULT> ) ldapadd: invalid format (line 1) entry: "" Please let me know how to overcome this. Regards.... Babu Shanmugam

1 0

Re: (ITS#5225) unexpected results in slapadd
by quanah＠zimbra.com 08 Nov '07

08 Nov '07

--On Thursday, November 08, 2007 1:01 PM -0500 "Allan E. Johannesen" <aej(a)WPI.EDU> wrote: >>>>>> "quanah" == Quanah Gibson-Mount <quanah(a)zimbra.com> writes: > > quanah> --On Thursday, November 08, 2007 4:46 PM +0000 aej(a)wpi.edu wrote: >>> Full_Name: Allan E. Johannesen Version: 2.4.6 OS: RHEL4 i686 URL: >>> http://users.wpi.edu/~aej Submission from: (NULL) (130.215.24.208) >>> >>> >>> Dependent on load flags (I normally have been using -w -q), I get >>> various results. Assertion failure, segfault, or success. > > quanah> Looks like it is related to the use of the -w flag, since your > segfault quanah> and assertions were hit when it was part of the command. > Thanks for quanah> the example bits to reproduce. > > Although the schemas probably don't come into play, and could probably be > removed from the config, I also put the two wpi schemas in > http://users.wpi.edu/~aej > > I forgot them when I was submitting. Please make sure you CC the ITS system on all emails about this bug. Thanks. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5225) unexpected results in slapadd
by quanah＠zimbra.com 08 Nov '07

08 Nov '07

--On Thursday, November 08, 2007 4:46 PM +0000 aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.4.6 > OS: RHEL4 i686 > URL: http://users.wpi.edu/~aej > Submission from: (NULL) (130.215.24.208) > > > Dependent on load flags (I normally have been using -w -q), I get various > results. Assertion failure, segfault, or success. Looks like it is related to the use of the -w flag, since your segfault and assertions were hit when it was part of the command. Thanks for the example bits to reproduce. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5225) unexpected results in slapadd
by aej＠wpi.edu 08 Nov '07

08 Nov '07

Full_Name: Allan E. Johannesen Version: 2.4.6 OS: RHEL4 i686 URL: http://users.wpi.edu/~aej Submission from: (NULL) (130.215.24.208) Dependent on load flags (I normally have been using -w -q), I get various results. Assertion failure, segfault, or success. utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# rm /var/openldap-data/* utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# ln /var/openldap-bdb/DB_CONFIG /var/openldap-data/ utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# servers/slapd/slapadd -w -q -f /usr/local/etc/openldap/slapd.utility5.conf < users.ldapv2.2007.11.08.ldif slapadd: entry.c:760: entry_encode: Assertion `i == a->a_numvals' failed. Abort utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# rm /var/openldap-data/* utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# ln /var/openldap-bdb/DB_CONFIG /var/openldap-data/ utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# servers/slapd/slapadd -q -f /usr/local/etc/openldap/slapd.utility5.conf < users.ldapv2.2007.11.08.ldif utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# rm /var/openldap-data/* utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# ln /var/openldap-bdb/DB_CONFIG /var/openldap-data/ utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# servers/slapd/slapadd -w -f /usr/local/etc/openldap/slapd.utility5.conf < users.ldapv2.2007.11.08.ldif Segmentation fault utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# rm /var/openldap-data/* utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# ln /var/openldap-bdb/DB_CONFIG /var/openldap-data/ utility5:/tools/src/openldap/RHEL4-i686/openldap-2.4.6# servers/slapd/slapadd -f /usr/local/etc/openldap/slapd.utility5.conf < users.ldapv2.2007.11.08.ldif I've placed DB_CONFIG, users.ldapv2.2007.11.08.ldif, and slapd.utility5.conf in http://users.wpi.edu/~aej/

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 08 Nov '07

08 Nov '07

On Donnerstag, 8. November 2007, you wrote: > <quote who="Ralf Haferkamp"> > > > On Donnerstag, 8. November 2007, rhafer(a)suse.de wrote: > >> I think I found a way. > >> 1. The SLAPD_ABANDON/op->o_abandon part of the cleanup handler will now > >> only get executed if the final result for the search has not been > >> received > >> (caching_reason == PC_IGNORE). > >> 2. Additionally, to add the entries to the cache, I do no longer use the > >> original Connection Object but create a new one > >> (connection_fake_init()), > >> because the op->o_abandon will be set for the original connection as > >> soon > >> as the client closes it. > >> > >> I'll do some more testing locally an submit this to HEAD later for more > >> external testing. > > > > Fix submitted to HEAD. Please test (preferably on the machine that caused > > this > > test to fail most often ;) ). > > I'll try this tonight. > > Just to clarify, this is a fix in the code, rather than the test, which I > thought Howard had changed? Yes, it is a fix in the pcache code. The fix in the testcase was only done temporarely in the RE24 branch (HEAD was not changed). I intend to remove it as soon as I get positive feedback. -- Ralf

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠OpenLDAP.org 08 Nov '07

08 Nov '07

<quote who="Ralf Haferkamp"> > On Donnerstag, 8. November 2007, rhafer(a)suse.de wrote: >> I think I found a way. >> 1. The SLAPD_ABANDON/op->o_abandon part of the cleanup handler will now >> only get executed if the final result for the search has not been >> received >> (caching_reason == PC_IGNORE). >> 2. Additionally, to add the entries to the cache, I do no longer use the >> original Connection Object but create a new one >> (connection_fake_init()), >> because the op->o_abandon will be set for the original connection as >> soon >> as the client closes it. >> >> I'll do some more testing locally an submit this to HEAD later for more >> external testing. > Fix submitted to HEAD. Please test (preferably on the machine that caused > this > test to fail most often ;) ). I'll try this tonight. Just to clarify, this is a fix in the code, rather than the test, which I thought Howard had changed? > > -- > Ralf >

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 08 Nov '07

08 Nov '07

On Donnerstag, 8. November 2007, rhafer(a)suse.de wrote: > I think I found a way. > 1. The SLAPD_ABANDON/op->o_abandon part of the cleanup handler will now > only get executed if the final result for the search has not been received > (caching_reason == PC_IGNORE). > 2. Additionally, to add the entries to the cache, I do no longer use the > original Connection Object but create a new one (connection_fake_init()), > because the op->o_abandon will be set for the original connection as soon > as the client closes it. > > I'll do some more testing locally an submit this to HEAD later for more > external testing. Fix submitted to HEAD. Please test (preferably on the machine that caused this test to fail most often ;) ). -- Ralf

1 0

RE: (ITS#5215) Use of ln is hardcoded in some files
by h.b.furuseth＠usit.uio.no 08 Nov '07

08 Nov '07

emmanuel.duru(a)atosorigin.com writes: > Then with MSYS, I get an error when running make on servers/slapd > Makefile: in case there is no extra LDFLAG, (...) Try this patch: --- servers/slapd/Makefile.in~ 2007-02-14 16:59:43.000000000 +0100 +++ servers/slapd/Makefile.in 2007-11-08 15:40:32.475898000 +0100 @@ -157,3 +157,3 @@ slapd.def: libbackends.a liboverlays.a version.o - @for i in $(LDFLAGS) ; do \ + @for i in XX $(LDFLAGS) ; do \ path=`expr "$$i" : "-L$.*$"`; \ @@ -169,3 +169,4 @@ base=`expr "$$i" : "-l$.*$"`; \ - for p in $$paths ; do \ + for p in " " $$paths ; do \ + test "x$$p" = "x " && continue ; \ for ext in la dll dll.a a ; do \ -- Regards, Hallvard

1 0

Re: ITS#5212 command that caused the crash
by hyc＠symas.com 08 Nov '07

08 Nov '07

tonni(a)hetnet.nl wrote: > Howard Chu skrev, on 07-11-2007 04:14: >> That's all we needed. Fixed now in HEAD. > > Do you happen to have a patch handy? I don't feel like waiting for > 2.4.7, this is the only serious bug I've found to date with 2.4.6. http://www.openldap.org/lists/openldap-commit/200711/msg00010.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: (ITS#5215) Use of ln is hardcoded in some files
by emmanuel.duru＠atosorigin.com 08 Nov '07

08 Nov '07

OK, forget about my remark on Cygwin/MinGW. However, you should update the "Porting OpenLDAP" FAQ to mention MSYS. Then with MSYS, I get an error when running make on servers/slapd Makefile: in case there is no extra LDFLAG, the lines @for i in $(LDFLAGS) ; do \ path=`expr "$$i" : "-L$.*$"`; \ if test $$? != 0; then continue; fi; \ paths="$$paths $$path"; \ done; \ cause a sh error: "syntax error near unexpected token ';'" -----Message d'origine----- De : Howard Chu [mailto:hyc@symas.com] Envoyé : mercredi 7 novembre 2007 04:08 À : emmanuel.duru(a)atosorigin.com Cc : openldap-its(a)openldap.org Objet : Re: (ITS#5215) Use of ln is hardcoded in some files emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.3.38 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.68.44.148) > > > configure allows the use of "cp" instead of "ln", but the build/shtool tool uses > a hardcoded "ln" (line 1266). > Some makefiles (libraries/liblunicode, libraries/libldap_r and > servers/slapd/back-hdb) use a hardcoded "-s" option. This is a problem on > Windows because in cygwin environment "cp -s" behaves the same way as "ln -s". > The use of "ln" is not welcome here because it creates a Windows shortcut, which > is not understood by mingw compiler. We only support the MSYS build environment on Windows. If you'd like to submit a patch to address this issue that doesn't break the other platforms, we can look at incorporating it. -- -- 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#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 08 Nov '07

08 Nov '07

On Dienstag, 6. November 2007, rhafer(a)suse.de wrote: > I think I have an idea what causes this bug. It is possible that the client > closes the connection before the server had a chance to run the cleanup > handler, the server sets op->o_abandon then (in connection_closing()). And > after that the cleanup handler is started, which in case of op->o_abandon > does not store the results in the cache. > > To make this race more reproduceable it is sufficient to insert a > usleep(100) before the call to slap_cleanup_play() in send_ldap_response() > in result.c. > > Any suggestions for possible ways to fix this? I think I found a way. 1. The SLAPD_ABANDON/op->o_abandon part of the cleanup handler will now only get executed if the final result for the search has not been received (caching_reason == PC_IGNORE). 2. Additionally, to add the entries to the cache, I do no longer use the original Connection Object but create a new one (connection_fake_init()), because the op->o_abandon will be set for the original connection as soon as the client closes it. I'll do some more testing locally an submit this to HEAD later for more external testing. -- Ralf

1 0

Re: ITS#5212 command that caused the crash
by tonni＠hetnet.nl 08 Nov '07

08 Nov '07

Howard Chu skrev, on 07-11-2007 04:14: >> > That's all very interesting, but you haven't provided the standard >> > items needed in a crash report - a stack trace from the crash, >> >> Yes I have, but later than your reply on the ITS site. >> >> > and the actual client command that caused the crash. Also, the slapd >> > configuration, plus any relevant schema if you've used any custom >> > schema in relation to this failing command. >> >> Other details: >> >> Command: >> >> ldapsearch2.4 -x -D "cn=admin,dc=billy,dc=demon,dc=nl" -w secret >> 'facsimileTelephoneNumber=+4753491111' facsimile TelephoneNumber > > That's all we needed. Fixed now in HEAD. Do you happen to have a patch handy? I don't feel like waiting for 2.4.7, this is the only serious bug I've found to date with 2.4.6. ..Tonni -- Tony Earnshaw Email: tonni at hetnet dot nl

1 0

Re: (ITS#5224) liblber Makefile misses some libraries
by richton＠nbcs.rutgers.edu 08 Nov '07

08 Nov '07

Note for reference, shutdown() is not called directly but rather via autoconf tcp_close() macro.

1 0

Re: (ITS#5216) Dynamic Lists doc contribution to the admin guide
by ghenry＠suretecsystems.com 07 Nov '07

07 Nov '07

Is the disclaimer ok? Can I commit the patch?

1 0

Re: (ITS#5217) refint overlay doc contribution
by ghenry＠suretecsystems.com 07 Nov '07

07 Nov '07

Is the disclaimer ok? Can I commit the patch?

1 0

Re: (ITS#5223) Minor patch to replication docs
by ghenry＠suretecsystems.com 07 Nov '07

07 Nov '07

<quote who="joshua(a)itsecureadmin.com"> > Full_Name: Josh miller > Version: 2.4.6 > OS: Linux (x86) > URL: http://itsecureadmin.com/replication-doc.patch > Submission from: (NULL) (198.134.96.8) > > > Minor grammatical error in replication.sdf (replace you with sure). > > Text: > "You also need to make you the rid of each mirror node pair is different > and > that the provider syncrepl directive points to the other mirror pair." > > Please see patch at: > > http://itsecureadmin.com/replication-doc.patch > > Thanks, > Josh > Thanks. This should also say "points to the other mirror node in the pair." I've got a nice diagram for this too, which I'll commit soon. Kurt, if I just make this change myself, do we need the usual contribution waver etc.?

1 0

(ITS#5224) liblber Makefile misses some libraries
by richton＠nbcs.rutgers.edu 07 Nov '07

07 Nov '07

Full_Name: Aaron Richton Version: RE23/RE24/HEAD OS: Solaris 9 URL: Submission from: (NULL) (128.6.31.135) Noticed that liblber uses shutdown(3socket) but does not link -lsocket on Solaris. Propose adding UNIX_LINK_LIBS = $(AC_LIBS) to libraries/liblber/Makefile.in. Verified to compile with this change on Solaris and Fedora...

1 0

(ITS#5223) Minor patch to replication docs
by joshua＠itsecureadmin.com 07 Nov '07

07 Nov '07

Full_Name: Josh miller Version: 2.4.6 OS: Linux (x86) URL: http://itsecureadmin.com/replication-doc.patch Submission from: (NULL) (198.134.96.8) Minor grammatical error in replication.sdf (replace you with sure). Text: "You also need to make you the rid of each mirror node pair is different and that the provider syncrepl directive points to the other mirror pair." Please see patch at: http://itsecureadmin.com/replication-doc.patch Thanks, Josh

1 0

Re: (ITS#5214) Compilation error with a non C++ compiler
by kurt＠OpenLDAP.org 07 Nov '07

07 Nov '07

On Nov 7, 2007, at 11:21 AM, h.b.furuseth(a)usit.uio.no wrote: > h.b.furuseth(a)usit.uio.no writes: >> It has been fixed in OpenLDAP 2.3.39. > > Hmm, not mentioned in openldap-2.3.39/CHANGES. > Can add it "retroactively", I guess. That's what was done in the past. -- Kurt

1 0

Re: (ITS#5214) Compilation error with a non C++ compiler
by h.b.furuseth＠usit.uio.no 07 Nov '07

07 Nov '07

h.b.furuseth(a)usit.uio.no writes: > It has been fixed in OpenLDAP 2.3.39. Hmm, not mentioned in openldap-2.3.39/CHANGES. Can add it "retroactively", I guess. -- Regards, Hallvard

1 0

Re: (ITS#5222) Missing PDF manual for 2.4
by kurt＠OpenLDAP.org 07 Nov '07

07 Nov '07

On Nov 7, 2007, at 6:45 AM, rwiker(a)gmail.com wrote: > Full_Name: Raymond Wiker > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (143.97.2.35) > > > Just tried to download the PDF manual > (http://www.openldap.org/doc/admin24/guide.pdf) from > http://www.openldap.org/doc/index.html. This didn't work; the obvious > explanation is that the file is not there, or that it has a > different name. Now fixed. Thanks for the report. (This was due to a change in the doc/guide/Makefile which caused the rule to build guide.pdf not to build guide.pdf. I've committed changes to HEAD to address this issue.)

1 0

(ITS#5222) Missing PDF manual for 2.4
by rwiker＠gmail.com 07 Nov '07

07 Nov '07

Full_Name: Raymond Wiker Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (143.97.2.35) Just tried to download the PDF manual (http://www.openldap.org/doc/admin24/guide.pdf) from http://www.openldap.org/doc/index.html. This didn't work; the obvious explanation is that the file is not there, or that it has a different name.

1 0

(ITS#5221) cache? of parent failes for hdb
by Dan.Oscarsson＠tietoenator.com 07 Nov '07

07 Nov '07

Full_Name: Dan Oscarsson Version: 2.3.32 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.15.240.60) I have found that using hdb there is a bug that now prevents me from moving from my old commercial X.500 database to openldap. I need to use hdb as I move objects using rename. I am running openldap under SLES 10. The version there is 2.3.32 but I have compiled 2.3.38 and tried that too. Both have same bug. Also compiled and tried openldap-2.4.5beta. Same failure there too. I am using hdb as database. What I do is to run a job that moves around a lot of leaf nodes to other branches, sometimes creating new branches before moving the leaf node there. The job moves about 7000 nodes out of 20000 when the bug occurs. After having run this, some nodes cannot be found by searching starting at a subtree under database suffix. I have done a simple test program to see if the bug appears. It does two searches: 1) Search with search base = database suffix 2) Search with search base = a branch 2 nodes deep below database suffix. If everything is correct, same number of objects should be found. My tests show: - running test: ok - running job that moves nodes - running test: failes, many objects are missing in search starting at search base that is 2 nodes below database suffix. - stopping and starting slapd - running test again: ok >From this I suspect that it is the cache of which parent node belongs to that gets corrupted. Or can it be something else? What more could I do to trace down the bug? I do not know if the above information is enough for you to find what is wrong? Cannot include data as it contains company internal information and a simple test program did not give the same error. I have looked at the code, but it takes some time to understand it when doing it for the first time. maybe som debugging code could be added find the place where the bug is.

1 0

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

07 Nov '07

We can check that an incoming modification will not leave an entry with more than one userPassword value. We already have a partial check for this now. But what can we do for an entry that already had multiple values, e.g., created before the overlay was in use? Simply refuse to Bind? -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs