openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

Re: (ITS#6656) logging "reqEntryUUID" in accesslog
by michael＠stroeder.com 12 Apr '12

12 Apr '12

This is a cryptographically signed message in MIME format. --------------ms030601000506050202050204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable masarati(a)aero.polimi.it wrote: >> Please revisit this ITS. I'd like to implement something like "svn rev= ert=3D >> " >> based on accesslog entries. Having the entry's UUID in an indexable at= tri=3D >> bute >> would make this more robust. >> >> This could also be handy for delta-replication if "conflicting" modrdn= >> requests were sent by a client which result in same reqDN. >=20 > Added to master, please test. Thanks. Seems to work. Added support for it in upcoming web2ldap 1.1.12...(searching the accessl= og entries and reverse searching the target entries). Ciao, Michael. --------------ms030601000506050202050204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxMjA3NTUxMlowIwYJKoZIhvcNAQkEMRYE FKAXr449YjNzkPdvkc1ruZoD11dbMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAxBqZadPfILnU/3+CI04Q803WcBUbQGGWz1rp9t4aWjOpnDmXwSfoG5kJ+qKJLvo5SGqy CtvlizF3xkVjB4qZJo0x5wRKAV0a8it7YqQbQpwpMC8YX74qJZY0f+3W83WJYiXgLEelkL2p 9AwRnwQS3+MRz5FrO5O7Xr/9csrribOkhJAbEQ+LR4CUNAcNttqkpWeUQ9J4bgW6gUgf7sQ4 SAC3devBI3u1vFxZl7yP8E3H3QQcm9eElvzGIRkX+2aRv2MKev+UzMAO+icTZTl21lnjgAnz KqAYWjKh3FXVoc8RUvMrl5yEuwuc09UV+rQjZmYenHQcWvhauEVOdy46OAAAAAAAAA== --------------ms030601000506050202050204--

1 0

Re: (ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 11 Apr '12

11 Apr '12

This is a multi-part message in MIME format. --------------040402080004020608060006 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 09.04.2012 20:09, Hrvoje Habjanić wrote: > > Hi. > > Two more "hang"s, both in sched_yield(). This is with replacement malloc > (tcmalloc, minimal). > > http://free-zg.t-com.hr/HrvojeHabjanic/openldap/hang4.log > http://free-zg.t-com.hr/HrvojeHabjanic/openldap/hang5.log > > H. Hi. Attached patch if solving my proglem with "hang" in sched_yield. In general, i do think that there (cache management) is a lot of unnecessary locking and waiting ... And simplifying things there would solve a lot of problems ... Probably. :-) Of course, i'm not shure how will this change influence the rest of the code, but it does work for me (tm). H. p.s. Also available at http://free-zg.t-com.hr/HrvojeHabjanic/openldap/ol.diff --------------040402080004020608060006 Content-Type: text/x-patch; name="ol.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ol.diff" diff -Nru openldap-d7d1789-org/servers/slapd/back-bdb/cache.c openldap-d7d1789/servers/slapd/back-bdb/cache.c --- openldap-d7d1789-org/servers/slapd/back-bdb/cache.c 2012-04-10 00:47:23.000000000 +0200 +++ openldap-d7d1789/servers/slapd/back-bdb/cache.c 2012-04-11 10:23:43.267461183 +0200 @@ -1361,7 +1361,7 @@ DB_LOCK *lock ) { EntryInfo *ei = BEI(e); - int rc, busy = 0; + int rc, busy = 0, counter = 0; assert( e->e_private != NULL ); @@ -1378,7 +1378,7 @@ bdb_cache_entryinfo_unlock( ei ); - while ( busy ) { + while ( busy && counter < 1000) { ldap_pvt_thread_yield(); busy = 0; bdb_cache_entryinfo_lock( ei ); @@ -1387,6 +1387,13 @@ ei->bei_finders > 0 ) busy = 1; bdb_cache_entryinfo_unlock( ei ); + counter ++; + } + if( busy ) { + bdb_cache_entryinfo_lock( ei ); + ei->bei_state ^= CACHE_ENTRY_DELETED; + bdb_cache_entryinfo_unlock( ei ); + return DB_LOCK_DEADLOCK; } /* Get write lock on the data */ --------------040402080004020608060006--

1 0

Re: ITS#6598
by masarati＠aero.polimi.it 11 Apr '12

11 Apr '12

> --On Saturday, February 18, 2012 12:41 AM +0000 quanah(a)zimbra.com wrote: > >> --On Saturday, February 18, 2012 1:32 AM +0100 masarati(a)aero.polimi.it >> wrote: > >> ah, ok thanks. :) > > > Any particularly reason why the control can't be made critical? No. Now it can. p.

1 0

Re: (ITS#6656) logging "reqEntryUUID" in accesslog
by masarati＠aero.polimi.it 10 Apr '12

10 Apr '12

> Please revisit this ITS. I'd like to implement something like "svn revert= > " > based on accesslog entries. Having the entry's UUID in an indexable attri= > bute > would make this more robust. > > This could also be handy for delta-replication if "conflicting" modrdn > requests were sent by a client which result in same reqDN. Added to master, please test. p.

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 10 Apr '12

10 Apr '12

On 4/9/2012 3:42 PM, masarati(a)aero.polimi.it wrote: > I have checked this case (I suspect the same could happen in other schema > items) and I'm about to commit a fix. > Will this be part of 2.4.31? Thank you for the fix!

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by masarati＠aero.polimi.it 09 Apr '12

09 Apr '12

> On 4/9/2012 7:01 AM, masarati(a)aero.polimi.it wrote: >>> On 4/6/2012 10:22 AM, Howard Chu wrote: >>>> Find out why oc->oc_names is NULL. It should not be. Seems like you >>>> have an invalid schema definition. >>>> >>> I have fixed the objectClasses that were violating by adding >>> "extensibleObject". >> ObjectClass with OID '1.3.6.1.4.1.6152.10.3.2.16'. Can you provide its >> definition? Apparently, oc_names is NULL, i.e. no names are defined for >> that class. >> > Here is the object class definition. > > Few things to note: > 1. I had added this class temporarily (before I added extensibleObject). > 2. I had forgotten to remove this definition from the schema, after > adding extensibleObject. > > objectclass ( 1.3.6.1.4.1.6152.10.3.2.16 > NAME 'sendmailMTAMAPAlias' > SUP ( sendmailMTAAliasObject $ sendmailMTAMAPObject ) STRUCTURAL > DESC 'Sendmail MTA map alias definition' ) > > > 3. I am re-running the slapadd, without this schema. > > (Will update the bug with more info then) I have created something similar (a structural class inheriting from two existing ones) and I couldn't reproduce your issue. However, I could exactly reproduce it by entirely removing the "NAME 'sendmailMTAMAPAlias'" portion, so I suspect you were using something like that. Slapd is accepting such definition (which I believe is at least bad practice, but it should be legal as we only complain about missing OID). I have checked this case (I suspect the same could happen in other schema items) and I'm about to commit a fix. p.

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 09 Apr '12

09 Apr '12

On 4/9/2012 7:01 AM, masarati(a)aero.polimi.it wrote: >> On 4/6/2012 10:22 AM, Howard Chu wrote: >>> Find out why oc->oc_names is NULL. It should not be. Seems like you >>> have an invalid schema definition. >>> >> I have fixed the objectClasses that were violating by adding >> "extensibleObject". > ObjectClass with OID '1.3.6.1.4.1.6152.10.3.2.16'. Can you provide its > definition? Apparently, oc_names is NULL, i.e. no names are defined for > that class. > Here is the object class definition. Few things to note: 1. I had added this class temporarily (before I added extensibleObject). 2. I had forgotten to remove this definition from the schema, after adding extensibleObject. objectclass ( 1.3.6.1.4.1.6152.10.3.2.16 NAME 'sendmailMTAMAPAlias' SUP ( sendmailMTAAliasObject $ sendmailMTAMAPObject ) STRUCTURAL DESC 'Sendmail MTA map alias definition' ) 3. I am re-running the slapadd, without this schema. (Will update the bug with more info then)

1 0

Re: (ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 09 Apr '12

09 Apr '12

On 08.04.2012 13:25, Hrvoje Habjanić wrote: > On 04.04.2012 17:45, Hrvoje Habjanić wrote: >> On 03.04.2012 17:41, Howard Chu wrote: >>> You may be able to avoid this bug by using an alternate malloc >>> library, such as Google tcmalloc. >>> >> Hi. >> >> I did try - using tcmalloc. And this time, i got SIGSEGV. Odd thing is >> that this happened in "pthread_mutex_lock" which is in libpthread.so ...? >> >> Another bug in centos libs? I would appreciate if you could take a look. >> >> Thx. >> >> H. >> >> p.s. url -> http://free-zg.t-com.hr/HrvojeHabjanic/hang3.log > Hi. Two more "hang"s, both in sched_yield(). This is with replacement malloc (tcmalloc, minimal). http://free-zg.t-com.hr/HrvojeHabjanic/openldap/hang4.log http://free-zg.t-com.hr/HrvojeHabjanic/openldap/hang5.log H.

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by hyc＠symas.com 09 Apr '12

09 Apr '12

michael(a)stroeder.com wrote: > This is a cryptographically signed message in MIME format. > > --------------ms000408080902010107050201 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > masarati(a)aero.polimi.it wrote: >> In general, I also prefer to have NO matching rules associated to attrs= > >> designed for purposes that do not require matching > > Why? > > As said it's useful for collision detection in case of a modify. So at le= > ast > every multi-valued attribute should have an EQUALITY matching rule. Every multi-valued attribute already does. They would be unusable otherwise. This discussion is only about single-valued config attributes. -- -- Howard Chu CTO, 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#7226) olcAuditlogFile At dos not accept multiple values
by masarati＠aero.polimi.it 09 Apr '12

09 Apr '12

> masarati(a)aero.polimi.it wrote: >> In general, I also prefer to have NO matching rules associated to attrs >> designed for purposes that do not require matching > > Why? In general, configuring a system means to write something as a whole, not bit by bit, since it works as intended only when everything is in place. Changing a small bit can have unexpected semantic impact. There are exceptions (either theoretically, or practically). For example, ACLs: occasionally one needs to tweak ACLs (in this case, small modifications can have tremendous impact on the functionality of totally unrelated parts as well), but ACLs need to evolve and adapt to needs. Another example are indexes. Nonetheless, I believe the best way to modify ACLs is through "replace". Fortunately, the most important aspect of ACLs is their order; in this case, the administrator can leverage the X-ORDERED feature. For exceptions, and for all attrs that may legitimately need to be routinely modified, I concur having a well-defined matching rule is helpful. > As said it's useful for collision detection in case of a modify. So at > least > every multi-valued attribute should have an EQUALITY matching rule. "replace" is your friend when managing configuration. > If in doubt which matching rule to use one could choose the stricter one > as > default, e.g. prefer caseExact over caseIgnore. Well, I'm afraid there will always be someone complaining because we chose caseExact instead of caseIgnore. Of course, my 2c. p.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs