- openldap-bugs - openldap.org

Re: (ITS#6915) memberof+accesslog duplicate reqStart
by subbarao＠computer.org 02 Jun '11

02 Jun '11

On 06/01/2011 07:36 PM, Yuri Bank wrote: > Do you think this could be related to: > http://www.openldap.org/its/index.cgi?findid=6864 > > I've been having similar issues with MemberOf and Accesslog overlays > used together. I've occasionally experienced similar things that you describe but haven't captured the detailed data to be able to correlate that with this issue. > In your fix, is the memberof overlay enabled on your consumer nodes? No, it is disabled everywhere. -Kartik

1 0

Re: (ITS#6915) memberof+accesslog duplicate reqStart
by yuribank＠gmail.com 02 Jun '11

02 Jun '11

--bcaec520e733d305e204a4aefc06 Content-Type: text/plain; charset=ISO-8859-1 Do you think this could be related to: http://www.openldap.org/its/index.cgi?findid=6864 I've been having similar issues with MemberOf and Accesslog overlays used together. In your fix, is the memberof overlay enabled on your consumer nodes? -Yuri On Wed, Jun 1, 2011 at 1:00 PM, <subbarao(a)computer.org> wrote: > This is a multi-part message in MIME format. > --------------050703040907090602090901 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > I figured I would share a workaround that I'm currently using for this > issue which may be of help to others. I've disabled the memberOf overlay > in slapd, and use an external script to populate memberOf on the master > server, which then replicates to the consumer servers. I currently run > this every 5 minutes from cron as follows: > > memberof.pl --ldap > > Regards, > > -Kartik > > --------------050703040907090602090901 > Content-Type: application/x-perl; > name="memberof.pl" > Content-Transfer-Encoding: 7bit > Content-Disposition: attachment; > filename="memberof.pl" > > #! /usr/bin/perl > > # Implements memberOf reverse mapping attributes -- workaround for when > # memberOf overlay isn't available > > use Net::LDAP; > use Net::LDAP::LDIF; > use Authen::SASL; > use Fcntl qw(LOCK_EX LOCK_NB); > use Getopt::Long; > > use strict; > > my $basedn = "dc=example,dc=com"; > > my @attrs = qw(member manager); > # Note -- this filter properly excludes dynamic groupOfURLs groups > my $attrfilter = '(|' . join("", map { "($_=*)" } @attrs) . ')'; > my %revattrs = (member => 'memberOf', manager => 'directReports'); > my %fwattrs = reverse %revattrs; > my $revattrfilter = '(|' . join("", map { "($_=*)" } values %revattrs) . > ')'; > my (%entries, %reventries); > > # Prevent multiple instances from running at the same time > open(LOCKFH, $0); flock(LOCKFH, LOCK_EX|LOCK_NB) or exit 1; > > my ($generate_ldif, $update_ldap); > GetOptions('ldif' => \$generate_ldif, 'ldap' => \$update_ldap); > > my $ldifout = Net::LDAP::LDIF->new('-', 'w'); > $ldifout->{change} = 1; > my $ldap = Net::LDAP->new('ldapi://') or die "ldapi: $@\n"; > my $sasl = Authen::SASL->new(mechanism => 'EXTERNAL'); > my $sasl_client = $sasl->client_new('ldap', 'localhost'); > $ldap->bind(undef, sasl => $sasl_client); > > # Build %entries and %reventries maps > my $mesg = $ldap->search(base => $basedn, > filter => $attrfilter, > attrs => \@attrs); > $mesg->code && die($mesg->error . "\n"); > foreach my $entry ($mesg->all_entries) {$entries{lc $entry->dn} = $entry } > > $mesg = $ldap->search(base => $basedn, > filter => $revattrfilter, > attrs => [values > %revattrs]); > $mesg->code && die($mesg->error . "\n"); > foreach my $entry ($mesg->all_entries) { $reventries{lc $entry->dn} = > $entry } > > # Go through and generate updates for the reverse mapping attributes > my ($dn, $entry); > while (($dn, $entry) = each %entries) { > foreach my $attr (@attrs) { > my $revattr = $revattrs{$attr}; > foreach my $val ($entry->get_value($attr)) { > $val = lc $val; > if (!$reventries{$val}) { > $reventries{$val} = Net::LDAP::Entry->new; > $reventries{$val}->dn($val); > $reventries{$val}->changetype('modify'); > } > $reventries{$val}->add($revattr => $entry->dn) > unless grep({ lc $_ eq $dn } > > $reventries{$val}->get_value($revattr)); > } > } > } > while (($dn, $entry) = each %reventries) { > foreach my $revattr (values %revattrs) { > foreach my $val ($entry->get_value($revattr)) { > $val = lc $val; > $reventries{$dn}->delete($revattr => $val) > if !exists($entries{$val}) > || !grep({ lc $_ eq $dn } > > $entries{$val}->get_value($fwattrs{$revattr})); > > } > } > if ($entry->changes) { > $ldifout->write_entry($entry) if $generate_ldif; > if ($update_ldap) { > my $modmesg = $entry->update($ldap); > $modmesg->code && die("LDAP: " .$modmesg->error . > "\n"); > } > } > } > > --------------050703040907090602090901-- > > > --bcaec520e733d305e204a4aefc06 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Do you think this could be related to: <a href=3D"http://www.openldap.org/i= ts/index.cgi?findid=3D6864">http://www.openldap.org/its/index.cgi?findid=3D= 6864</a>=A0 I've been having similar issues with MemberOf and A= ccesslog overlays used together. In your fix, is the memberof overlay enabled on your consumer nodes= ? -Yuri <div class=3D"gmail_quote">On Wed, Jun 1, 2011 at 1:0= 0 PM, <<a href=3D"mailto:subbarao@computer.org">subba= rao(a)computer.org</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">This is a multi-part message in MIME format= . --------------050703040907090602090901 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit I figured I would share a workaround that I'm currently using for this<= br> issue which may be of help to others. I've disabled the memberOf overla= y in slapd, and use an external script to populate memberOf on the master server, which then replicates to the consumer servers. I currently run this every 5 minutes from cron as follows: <a href=3D"http://memberof.pl" target=3D"_blank">memberof.pl</a> --ldap Regards, =A0 =A0 =A0 =A0-Kartik --------------050703040907090602090901 Content-Type: application/x-perl; =A0name=3D"<a href=3D"http://memberof.pl" target=3D"_blank">memberof.p= l</a>" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; =A0filename=3D"<a href=3D"http://memberof.pl" target=3D"_blank">member= of.pl</a>" #! /usr/bin/perl # Implements memberOf reverse mapping attributes -- workaround for when # memberOf overlay isn't available use Net::LDAP; use Net::LDAP::LDIF; use Authen::SASL; use Fcntl qw(LOCK_EX LOCK_NB); use Getopt::Long; use strict; my $basedn =3D "dc=3Dexample,dc=3Dcom"; my @attrs =3D qw(member manager); # Note -- this filter properly excludes dynamic groupOfURLs groups my $attrfilter =3D '(|' . join("", map { "($_=3D*)&q= uot; } @attrs) . ')'; my %revattrs =3D (member =3D> 'memberOf', manager =3D> 'd= irectReports'); my %fwattrs =3D reverse %revattrs; my $revattrfilter =3D '(|' . join("", map { "($_=3D*= )" } values %revattrs) . ')'; my (%entries, %reventries); # Prevent multiple instances from running at the same time open(LOCKFH, $0); flock(LOCKFH, LOCK_EX|LOCK_NB) or exit 1; my ($generate_ldif, $update_ldap); GetOptions('ldif' =3D> \$generate_ldif, 'ldap' =3D> \= $update_ldap); my $ldifout =3D Net::LDAP::LDIF->new('-', 'w'); $ldifout->{change} =3D 1; my $ldap =3D Net::LDAP->new('ldapi://') or die "ldapi: $@\n= "; my $sasl =3D Authen::SASL->new(mechanism =3D> 'EXTERNAL');<br= > my $sasl_client =3D $sasl->client_new('ldap', 'localhost&#39= ;); $ldap->bind(undef, sasl =3D> $sasl_client); # Build %entries and %reventries maps my $mesg =3D $ldap->search(base =3D> $basedn, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 filter =3D> $attrfilter, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 attrs =3D> \@attrs); $mesg->code && die($mesg->error . "\n"); foreach my $entry ($mesg->all_entries) {$entries{lc $entry->dn} =3D $= entry } $mesg =3D $ldap->search(base =3D> $basedn, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 filter =3D> $revattrfilter, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 attrs =3D> [values %revattrs]); $mesg->code && die($mesg->error . "\n"); foreach my $entry ($mesg->all_entries) { $reventries{lc $entry->dn} = =3D $entry } # Go through and generate updates for the reverse mapping attributes my ($dn, $entry); while (($dn, $entry) =3D each %entries) { =A0 =A0 =A0 =A0foreach my $attr (@attrs) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0my $revattr =3D $revattrs{$attr}; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0foreach my $val ($entry->get_value($attr= )) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$val =3D lc $val; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!$reventries{$val}) {<b= r> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$reventries= {$val} =3D Net::LDAP::Entry->new; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$reventries= {$val}->dn($val); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$reventries= {$val}->changetype('modify'); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$reventries{$val}->add($= revattr =3D> $entry->dn) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unless grep= ({ lc $_ eq $dn } =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$reventries{$val}->get_value($rev= attr)); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0} } while (($dn, $entry) =3D each %reventries) { =A0 =A0 =A0 =A0foreach my $revattr (values %revattrs) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0foreach my $val ($entry->get_value($reva= ttr)) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$val =3D lc $val; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$reventries{$dn}->delete= ($revattr =3D> $val) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if !exists(= $entries{$val}) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|| !grep({ = lc $_ eq $dn } =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 $entries{$val}->get_value($fwattrs{$revattr}));<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0if ($entry->changes) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$ldifout->write_entry($entry) if $genera= te_ldif; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ($update_ldap) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0my $modmesg =3D $entry->= update($ldap); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$modmesg->code &&amp= ; die("LDAP: " .$modmesg->error . =A0"\n"); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0} } --------------050703040907090602090901-- </blockquote></div> --bcaec520e733d305e204a4aefc06--

1 0

Re: (ITS#6915) memberof+accesslog duplicate reqStart
by subbarao＠computer.org 01 Jun '11

01 Jun '11

This is a multi-part message in MIME format. --------------050703040907090602090901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I figured I would share a workaround that I'm currently using for this issue which may be of help to others. I've disabled the memberOf overlay in slapd, and use an external script to populate memberOf on the master server, which then replicates to the consumer servers. I currently run this every 5 minutes from cron as follows: memberof.pl --ldap Regards, -Kartik --------------050703040907090602090901 Content-Type: application/x-perl; name="memberof.pl" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="memberof.pl" #! /usr/bin/perl # Implements memberOf reverse mapping attributes -- workaround for when # memberOf overlay isn't available use Net::LDAP; use Net::LDAP::LDIF; use Authen::SASL; use Fcntl qw(LOCK_EX LOCK_NB); use Getopt::Long; use strict; my $basedn = "dc=example,dc=com"; my @attrs = qw(member manager); # Note -- this filter properly excludes dynamic groupOfURLs groups my $attrfilter = '(|' . join("", map { "($_=*)" } @attrs) . ')'; my %revattrs = (member => 'memberOf', manager => 'directReports'); my %fwattrs = reverse %revattrs; my $revattrfilter = '(|' . join("", map { "($_=*)" } values %revattrs) . ')'; my (%entries, %reventries); # Prevent multiple instances from running at the same time open(LOCKFH, $0); flock(LOCKFH, LOCK_EX|LOCK_NB) or exit 1; my ($generate_ldif, $update_ldap); GetOptions('ldif' => \$generate_ldif, 'ldap' => \$update_ldap); my $ldifout = Net::LDAP::LDIF->new('-', 'w'); $ldifout->{change} = 1; my $ldap = Net::LDAP->new('ldapi://') or die "ldapi: $@\n"; my $sasl = Authen::SASL->new(mechanism => 'EXTERNAL'); my $sasl_client = $sasl->client_new('ldap', 'localhost'); $ldap->bind(undef, sasl => $sasl_client); # Build %entries and %reventries maps my $mesg = $ldap->search(base => $basedn, filter => $attrfilter, attrs => \@attrs); $mesg->code && die($mesg->error . "\n"); foreach my $entry ($mesg->all_entries) {$entries{lc $entry->dn} = $entry } $mesg = $ldap->search(base => $basedn, filter => $revattrfilter, attrs => [values %revattrs]); $mesg->code && die($mesg->error . "\n"); foreach my $entry ($mesg->all_entries) { $reventries{lc $entry->dn} = $entry } # Go through and generate updates for the reverse mapping attributes my ($dn, $entry); while (($dn, $entry) = each %entries) { foreach my $attr (@attrs) { my $revattr = $revattrs{$attr}; foreach my $val ($entry->get_value($attr)) { $val = lc $val; if (!$reventries{$val}) { $reventries{$val} = Net::LDAP::Entry->new; $reventries{$val}->dn($val); $reventries{$val}->changetype('modify'); } $reventries{$val}->add($revattr => $entry->dn) unless grep({ lc $_ eq $dn } $reventries{$val}->get_value($revattr)); } } } while (($dn, $entry) = each %reventries) { foreach my $revattr (values %revattrs) { foreach my $val ($entry->get_value($revattr)) { $val = lc $val; $reventries{$dn}->delete($revattr => $val) if !exists($entries{$val}) || !grep({ lc $_ eq $dn } $entries{$val}->get_value($fwattrs{$revattr})); } } if ($entry->changes) { $ldifout->write_entry($entry) if $generate_ldif; if ($update_ldap) { my $modmesg = $entry->update($ldap); $modmesg->code && die("LDAP: " .$modmesg->error . "\n"); } } } --------------050703040907090602090901--

1 0

RE: Re: (ITS#6952)
by quanah＠zimbra.com 01 Jun '11

01 Jun '11

--On Friday, May 27, 2011 4:47 AM +0000 Srinivas.Kondamadugu(a)mphasis.com wrote: > Any help here? The ITS system is for reporting bugs, not for asking for help. If you need help, use the openldap-technical(a)openldap.org mailing list. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6961) back-bdb/hdb search performance issue
by hyc＠OpenLDAP.org 01 Jun '11

01 Jun '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc See this thread for background http://www.openldap.org/lists/openldap-technical/201011/msg00146.html Currently when returning the entries in an IDL range, back-bdb search.c just iterates through all the values in the range. If a lot of entries have been deleted within this range a lot of time is wasted calling into BDB to fetch entryIDs that don't exist. Strictly speaking this performance loss can be avoided by simply using a cursor on the id2entry DB, and using DB_NEXT to fetch the next entry that exists. However, while that approach provides uniform search performance, it's also always about 2x slower than the best-case where we just iterate through the IDL. Also if we keep a cursor like this open for the entire search operation, it will leave all of those entries read-locked until the search completes. (Note that an MVCC approach, like for back-mdb, would not have this latter problem.) The current patch continues to use the IDL iterator, but if the next iterated ID comes up as nonexistent, then we check for the next ID in the DB. We use the same approach as the online indexer to avoid taking any long-term locks: create a cursor, use DB_SET_RANGE to get the next ID, and then close the cursor, thus freeing its locks. This way the ideal case (all consecutive entries exist) remains fast, and the performance hit of asking BDB is only incurred when necessary. Testing shows that search performance remains uniform and within 1% of the ideal case.

1 0

(ITS#6960) Out of memory erro occurs when running LDAP
by ArunPrasathSevugan＠oracle.com 31 May '11

31 May '11

Full_Name: Arun Prasath Version: 3 OS: Window Xp URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.225.129.57) Hi, We have a tool integrated with LDAP to load all the users in Cognos reporting. There are about 5000+ users and while running LDAPCONFIG we have been getting out of memory exception issue. In the task manage I could see the LDAP is using memory of around 3 GB and finally errors out. Please help us to load the 5000+ users. Thanks, Arun

1 0

(ITS#6959) ldap_dnfree not mentioned anywhere
by frank.muzzulini＠comsoft.aero 31 May '11

31 May '11

Full_Name: Frank Muzzulini Version: 2.4.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.221.120.78) Hi, Reading the documentation of ldap_str2dn I was wondering how to free the allocated DN. After browsing for a while I loaded the latest tarball to see some example code and found ldap_dnfree. I re-checked and indeed the function is not mentioned anywhere in the docs ("find doc -type f | xargs grep ldap_dnfree" found nothing). Regards, Frank

1 0

(ITS#6958) slapd segmentation fault with TLSCRLCheck all
by alex.deiter＠gmail.com 27 May '11

27 May '11

Full_Name: Alex Deiter Version: 2.4.25 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.66.145.56) FreeBSD x86 and amd64, OpenLDAP 2.4.25 configure option: $ ./configure --with-threads=posix --with-tls=openssl --disable-dependency-tracking --enable-dynamic --with-cyrus-sasl --enable-modules --localstatedir=/var/db --enable-crypt --enable-lmpasswd --enable-ldap=mod --enable-meta=mod --enable-rewrite --enable-null=mod --enable-monitor=mod --enable-accesslog --enable-auditlog --enable-collect --enable-constraint --enable-dds --enable-deref --enable-dyngroup --enable-dynlist --enable-memberof --enable-ppolicy --enable-proxycache --enable-refint --enable-retcode --enable-rwm --enable-seqmod --enable-sssvlv --enable-syncprov --enable-translucent --enable-unique --enable-valsort --enable-bdb=mod --enable-hdb=mod --enable-spasswd --enable-slapi --enable-wrappers --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ --build=i386-portbld-freebsd9.0 slapindex segmentation fault when option TLSCRLCheck all is used in slapd.conf: TLSCACertificatePath /etc/ssl TLSCACertificateFile /etc/ssl/ca.crt TLSCertificateKeyFile /etc/ssl/server.key TLSCertificateFile /etc/ssl/server.crt TLSVerifyClient allow TLSCRLCheck all # slapindex -v Segmentation fault (core dumped) # gdb /usr/local/libexec/slapd /var/tmp/slapd-49225.core ... (gdb) bt #0 ldap_free_urllist (ludlist=0x2) at url.c:1515 #1 0x28c9b0b4 in ldap_int_destroy_global_options () at init.c:485 #2 0x28c7efc0 in __do_global_dtors_aux () from /usr/local/lib/libldap-2.4.so.8 #3 0x28cabf1c in _fini () from /usr/local/lib/libldap-2.4.so.8 #4 0x281d4538 in ?? () from /libexec/ld-elf.so.1 #5 0x281d4538 in ?? () from /libexec/ld-elf.so.1 #6 0xbfbfea38 in ?? () #7 0x281a9100 in dlinfo () from /libexec/ld-elf.so.1 #8 0x281a9260 in dlclose () from /libexec/ld-elf.so.1 #9 0x283a81b1 in _sasl_done_with_plugins () from /usr/local/lib/libsasl2.so.2 #10 0x283a18f0 in sasl_done () from /usr/local/lib/libsasl2.so.2 #11 0x080c7a3b in slap_sasl_destroy () #12 0x080a4d3d in slap_destroy () #13 0x080e4553 in slap_tool_destroy () #14 0x080e6147 in slapindex () #15 0x0805b665 in main () (gdb) f 0 #0 ldap_free_urllist (ludlist=0x2) at url.c:1515 1515 next = ludp->lud_next; also slapd segmentation fault when slapd service stopped: (gdb) bt #0 ldap_free_urllist (ludlist=0x2) at url.c:1515 #1 0x28c9b0b4 in ldap_int_destroy_global_options () at init.c:485 #2 0x28c7efc0 in __do_global_dtors_aux () from /usr/local/lib/libldap-2.4.so.8 #3 0x28cabf1c in _fini () from /usr/local/lib/libldap-2.4.so.8 #4 0x281d4538 in ?? () from /libexec/ld-elf.so.1 #5 0x281d4538 in ?? () from /libexec/ld-elf.so.1 #6 0xbfbfe9f8 in ?? () #7 0x281a9100 in dlinfo () from /libexec/ld-elf.so.1 #8 0x281a9260 in dlclose () from /libexec/ld-elf.so.1 #9 0x283a81b1 in _sasl_done_with_plugins () from /usr/local/lib/libsasl2.so.2 #10 0x283a18f0 in sasl_done () from /usr/local/lib/libsasl2.so.2 #11 0x080c7a3b in slap_sasl_destroy () #12 0x080a4d3d in slap_destroy () #13 0x0805bc92 in main () (gdb) f 0 #0 ldap_free_urllist (ludlist=0x2) at url.c:1515 1515 next = ludp->lud_next; without TLSCRLCheck all option in slapd.conf/ldap.conf slapd work fine, but without the CRL we can't authenticate clients on their certificates ;-( ldap.conf: TLS_CACERT /etc/ssl/ca.crt TLS_CACERTDIR /etc/ssl TLS_REQCERT demand TLS_CRLCHECK all URI ldaps://server.domain.ru BASE dc=domain,dc=ru RESTART yes VERSION 3 SIZELIMIT 0 TIMELIMIT 0 TIMEOUT 30 NETWORK_TIMEOUT 30 slapd.conf: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/samba.schema include /usr/local/etc/openldap/schema/dhcp.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/sendmail.schema pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args TLSCACertificatePath /etc/ssl TLSCACertificateFile /etc/ssl/ca.crt TLSCertificateKeyFile /etc/ssl/server.key TLSCertificateFile /etc/ssl/server.crt TLSVerifyClient allow TLSCRLCheck all allow bind_v2 sizelimit -1 timelimit -1 modulepath /usr/local/libexec/openldap moduleload back_hdb database hdb cachesize 1024 directory /var/db/openldap-data dbconfig set_cachesize 0 67108864 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 suffix "dc=domain,dc=ru" rootdn "cn=manager,dc=domain,dc=ru" rootpw "passwd" index objectClass eq access to * by * read sasl-authz-policy to sasl-regexp gidNumber=(.*)\\+uidNumber=0,cn=peercred,cn=external,cn=auth "cn=manager,dc=domain,dc=ru" sasl-regexp gidNumber=60\\+uidNumber=60,cn=peercred,cn=external,cn=auth "cn=manager,dc=domain,dc=ru" sasl-regexp gidNumber=(.*)\\+uidNumber=(.*),cn=peercred,cn=external,cn=auth ldap:///dc=domain,dc=ru??sub?(&(gidNumber=$1)(uidNumber=$2)) sasl-regexp uid=(.*),cn=(.*),cn=auth ldap:///dc=domain,dc=ru??sub?(uid=$1)

1 0

RE: Re: (ITS#6952)
by Srinivas.Kondamadugu＠mphasis.com 27 May '11

27 May '11

This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1C29.1B3F5374 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Any help here? Regards,=20 Srinivas Kondamadugu MphasiS an HP company |Ext. 51-41119|Mob: +91 9764401128 | email - srinivas.kondamadugu(a)mphasis.com |=20 > _____________________________________________=20 > From: Srinivas Kondamadugu =20 > Sent: Wednesday, May 25, 2011 2:15 PM > To: 'openldap-its(a)openldap.org' > Subject: Re: (ITS#6952) >=20 >=20 > Hi, Please find the configuration files > Regards,=20 > Srinivas Kondamadugu > MphasiS an HP company |Ext. 51-41119|Mob: +91 9764401128 | email - > srinivas.kondamadugu(a)mphasis.com |=20 >=20 > << File: (ITS#6952).zip >>=20 Information transmitted by this e-mail is proprietary to MphasiS, its assoc= iated companies and/ or its customers and is intended=20 for use only by the individual or entity to which it is addressed, and may = contain information that is privileged, confidential or=20 exempt from disclosure under applicable law. If you are not the intended re= cipient or it appears that this mail has been forwarded=20 to you without proper authority, you are notified that any use or dissemina= tion of this information in any manner is strictly=20 prohibited. In such cases, please notify us immediately at mailmaster@mphas= is.com and delete this mail from your records. ------_=_NextPart_001_01CC1C29.1B3F5374 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7653.29"> <TITLE>RE: Re: (ITS#6952)</TITLE> </HEAD> <BODY>  Any help here? Regards, Srinivas Kondamadugu</FON= T> MphasiS an HP company&nbs= p; |Ext. 51-41119|Mob: +91 9764401128 | email - srinivas.kondamadugu@mphasi= s.com |=20 <UL> _________________________________________= ____ From:   Srinivas Kondamadugu  Sent:   Wednesday, May 25, 2011 2:15 PM To:    </B= > 'openldap-its(a)openldap.org' Subject:    &nbsp= ;   Re: (ITS#6952)</FON= T> Hi, Please find the configuration files<= /FONT> Regards, Srinivas Kondamadugu</FON= T> MphasiS an HP company&nbs= p; |Ext. 51-41119|Mob: +91 9764401128 | email - srinivas.kondamadugu@mphasi= s.com |=20  << File: (ITS#6952).zip >= > </UL> Information transmitted by this e-mail is proprietary to MphasiS, its assoc= iated companies and/ or its customers and is intended for use only by the individual or entity to which it is addressed, and may = contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended re= cipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemina= tion of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailmaster@mphas= is.com and delete this mail from your records.</BODY> </HTML> ------_=_NextPart_001_01CC1C29.1B3F5374--

1 0

(ITS#6955) smbk5pwd: Update shadowLastChange
by fumiyas＠osstech.co.jp 26 May '11

26 May '11

Full_Name: SATOH Fumiyasu Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/smbk5pwd-shadowLastChange.patch Submission from: (NULL) (113.197.240.138) This patch is for smbk5pwd overlay to support updating shadowLastChange attribute in shadowAccount. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by SATOH Fumiyasu <fumiyas(a)osstech.co.jp>. I have not assigned rights and/or interest in this work to any party. I, SATOH Fumiyasu, 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.

1 0

(ITS#6954) pcache crashes when bind-caching is enable
by ralf＠OpenLDAP.org 26 May '11

26 May '11

Full_Name: Ralf Haferkamp Version: 2.4.25/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.211.118) Submitted by: ralf The pcache overlay can crash slapd when bind-caching ("pcacheBind" in slapd.conf) is enabled. It turned out to be a race condition with the consistency checker background task. The task might free and (expired) cached query while it is still being referenced by a bind operation currently in progress. Fix is coming.

1 0

(ITS#6953) pcache deadlocks when refreshing cached queries
by ralf＠OpenLDAP.org 25 May '11

25 May '11

Full_Name: Ralf Haferkamp Version: 2.4.25/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.172.234) Submitted by: ralf Under certain circumstances slapo-pcache causes a deadlock in slapd when refreshing a cached query. The reason seems to be that, slapo-pcache considers the refresh search, issued from the consitency checker task, to be answerable from the local cache database (this only seems to happen when the pcacheAttrset contains the "objectclass" Attribute). slapo-pcache will search the cache db with the response callback pointing to be_modify() (indirectly through refresh_merge()) of the same database. When using bdb/hdb as the cache database this cause the task request a write lock on the cached entry with in one bdb transaction while already holding a read lock (from the internal search) through another TXN. slapd is deadlocked after that. See below for a gdb backtrace taken from that situation. The fix seems to be fairly easy. Just do not lookup the cache db when refreshing a cached query. It doesn't make sense anyway. I'll commit something for that shortly. #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x00007f2b88eaf519 in __db_pthread_mutex_lock (env=0xa5ebb0, mutex=<value optimized out>) at ../mutex/mut_pthread.c:318 #2 0x00007f2b88f4252e in __lock_get_internal (lt=0xa5efc0, sh_locker=<value optimized out>, flags=0, obj=0x14060, lock_mode=<value optimized out>, timeout=2169475480, lock=0x7f2b814f93a8) at ../lock/lock.c:953 #3 0x00007f2b88f4350c in __lock_vec (env=0xa5ebb0, sh_locker=0x7f2b858acf38, flags=0, list=0x7f2b814f9360, nlist=2, elistp=0x0) at ../lock/lock.c:136 #4 0x00007f2b88f43c48 in __lock_vec_api (dbenv=<value optimized out>, lid=2147483672, flags=0, list=0x7f2b814f9360, nlist=2, elistp=0x0) at ../lock/lock.c:84 #5 __lock_vec_pp (dbenv=<value optimized out>, lid=2147483672, flags=0, list=0x7f2b814f9360, nlist=2, elistp=0x0) at ../lock/lock.c:66 #6 0x000000000052a5d3 in bdb_cache_entry_db_relock (bdb=0x9c7a20, txn=0xa66670, ei=0xd71720, rw=1, tryOnly=0, lock=0x7f2b814f94d0) at ../../../../servers/slapd/back-bdb/cache.c:198 #7 0x000000000052c1e7 in bdb_cache_modify (bdb=0x9c7a20, e=0x7f2b85445068, newAttrs=0x7f2b8267e258, txn=0xa66670, lock=0x7f2b814f94d0) at ../../../../servers/slapd/back-bdb/cache.c:1231 #8 0x00000000004f3f2d in bdb_modify (op=0x7f2b8167a430, rs=0x7f2b814f9820) at ../../../../servers/slapd/back-bdb/modify.c:711 #9 0x000000000059e458 in refresh_merge (op=0x7f2b8167a430, rs=0x7f2b8167a370) at ../../../../servers/slapd/overlays/pcache.c:3275 #10 0x000000000045c207 in slap_response_play (op=0x7f2b8167a430, rs=0x7f2b8167a370) at ../../../servers/slapd/result.c:505 #11 0x000000000045dd28 in slap_send_search_entry (op=0x7f2b8167a430, rs=0x7f2b8167a370) at ../../../servers/slapd/result.c:997 #12 0x00000000004fbfd0 in bdb_search (op=0x7f2b8167a430, rs=0x7f2b8167a370) ---Type <return> to continue, or q <return> to quit--- at ../../../../servers/slapd/back-bdb/search.c:962 #13 0x000000000059d86e in pcache_op_search (op=0x7f2b8167a430, rs=0x7f2b8167a370) at ../../../../servers/slapd/overlays/pcache.c:3037 #14 0x00000000004d9ba5 in overlay_op_walk (op=0x7f2b8167a430, rs=0x7f2b8167a370, which=op_search, oi=0x9c7430, on=0x9c7610) at ../../../servers/slapd/backover.c:661 #15 0x00000000004d9e52 in over_op_func (op=0x7f2b8167a430, rs=0x7f2b8167a370, which=op_search) at ../../../servers/slapd/backover.c:723 #16 0x00000000004d9f3a in over_op_search (op=0x7f2b8167a430, rs=0x7f2b8167a370) at ../../../servers/slapd/backover.c:750 #17 0x000000000059e9bb in refresh_query (op=0x7f2b8167a430, query=0xa66580, on=0x9c7610) at ../../../../servers/slapd/overlays/pcache.c:3371 #18 0x000000000059f03d in consistency_check (ctx=0x7f2b8167ab60, arg=0xa61910) at ../../../../servers/slapd/overlays/pcache.c:3492

1 0

Re: (ITS#6952)
by Srinivas.Kondamadugu＠mphasis.com 25 May '11

25 May '11

This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1AB8.7233BFF9 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC1AB8.7233BFF9" ------_=_NextPart_002_01CC1AB8.7233BFF9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please find the configuration files Regards,=20 Srinivas Kondamadugu MphasiS an HP company |Ext. 51-41119|Mob: +91 9764401128 | email - srinivas.kondamadugu(a)mphasis.com |=20 <<(ITS#6952).zip>>=20 Information transmitted by this e-mail is proprietary to MphasiS, its assoc= iated companies and/ or its customers and is intended=20 for use only by the individual or entity to which it is addressed, and may = contain information that is privileged, confidential or=20 exempt from disclosure under applicable law. If you are not the intended re= cipient or it appears that this mail has been forwarded=20 to you without proper authority, you are notified that any use or dissemina= tion of this information in any manner is strictly=20 prohibited. In such cases, please notify us immediately at mailmaster@mphas= is.com and delete this mail from your records. ------_=_NextPart_002_01CC1AB8.7233BFF9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7653.29"> <TITLE>Re: (ITS#6952)</TITLE> </HEAD> <BODY>  Hi, Please find the configuration files<= /FONT> Regards, Srinivas Kondamadugu</FON= T> MphasiS an HP company&nbs= p; |Ext. 51-41119|Mob: +91 9764401128 | email - srinivas.kondamadugu@mphasi= s.com |=20 <<(ITS#6952).zip&= gt;> Information transmitted by this e-mail is proprietary to MphasiS, its assoc= iated companies and/ or its customers and is intended for use only by the individual or entity to which it is addressed, and may = contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended re= cipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemina= tion of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailmaster@mphas= is.com and delete this mail from your records.</BODY> </HTML> ------_=_NextPart_002_01CC1AB8.7233BFF9-- ------_=_NextPart_001_01CC1AB8.7233BFF9 Content-Type: application/x-zip-compressed; name="(ITS#6952).zip" Content-Transfer-Encoding: base64 Content-Description: (ITS#6952).zip Content-Disposition: attachment; filename="(ITS#6952).zip" UEsDBBQAAgAIAPmyjTwmALxUVhYAAOlMAAAOAAAAcHBvbGljeS5zY2hlbWHVXHtTG0mS//v4FLXg CGBCCCTA2J7ZiZCFsHUrJFYS4/FsbGwU3SXU51a3ph889mK/++Wjqrq61YDk2SPuiN2xHlVZWfn8 VVa2dsSb0VJFg/PO1Qex/HZ7GPpyeZiq5E4l6WEayqV/mHpztZCHy2UcBt5jk9827kSredZsN09F +6h1dHh0ctg6hpcf2scfTt6Lb3mSid7DUrzZ2tkR03mQivs4+Sbg36WEr+KZMOuKSTzL7mWixE/z LFt+ODy8v79vxvAt8tKMk9vDn5tABQl14+VjEtzOM1jp6OQAVwbiqqB1EeeRL7MgjnCK6IShoPGp SBTtyjekxsoP0iwJbnIcLWTkizxVIohEGueJp+iTmyCSyaOYxckibYj7IJuLOKF/4zxDKovYD2aB Rys2BG5iqZJFkGXKF3EUPgqZCpnD8CT4J3x08ygyh12kcJXfgFjFIPBUlCrDXUd4sFUUU4ayC/lb FJ+8k0Eob0JiFYnNAng96Hd7w0lPf4YUsnh5EKo7FQo/SJSXxYkmp0Rp43ECfIeZSiLYBAx/hLe0 NVcbhmHShmamOc8WIWqGdhEnSC11NLTX3Sfd9CMkrjLQsxeo7FHsoe72ST9XoZKwrVTBNnLQlWdn p5nM1EJFmbhRYXzf3NraEedqFkQBrzNL4oU4T+QMB8xVIg/QWg6WMk3B0PwDNtaDozOxJ7XpRWKZ xLdgB+n+1s5/XOmRwDqORB0LMqFzLa5ApbDmF9S5eshgx8W6n9V9qLLs4Ep632TifwByy3u/O1fe t8vYz0EfKvOI5W4Mu4/A/IwmSVtoJ2l+81+wDuhJeHMZ3SqxF0RemPtBdCt8BfRhPWDUWJuI4gwE T/IWwzgDg/biBUjIB7tC5mFzfu6RTsGQ/wSjrkG095r/BIQpPEk6/xNwNlQZSeUL/AdX/JTE+VKs 8/efTTEBG4f4MFfBYmvH6PeAtbHZ3zAGkwsbYCTe1g7EC5B9+kF0lkkQivZJA938dF1agyboMsji HLb+nX+TPBKXgZfE6WMK5pd+P6URmNCNSswmTlBtddTWNMPKn4+iPnjW8N81s4cM15yAJ+WFAV6q RaxZobDsx15OfoaxJRIVbWIQhC8cY5XgpmBqdwH5A9EB0qliyzvGN+OLrjh++/asKcTHR5yLARGN jBgor9AQSnpzIsNxEux6ibEanSabS2QBouhyCbuiqLeU6FAYhmOIZYnoX42FF8pggVskOvfzwJsL iDwwBmyUNkb5ZS7vFEQLFXEQh43cUDD0wjhVfoM2i6s9QecGHU5pWjXTIcBIzwMdyMhjxyMyWhrv mlrq5f2nFAzutRcaZaQmVNvg2Ytug0ipBEax7mT6DbIdJqq9fm96sQ/rMzGZ8k7wraF7i96dNtHf MkViZcWRBPlLsZAg5zCNi/RQx5dM6zbx3N7IVh0KdzIMOGJJWPMhWOQLsqDgAbJplM15AdwBcgQi zpeQ0VHAYBmh9PAVav8mjSFIclLljThcktkQoSxYKNh4nwwc0vkSjBfCi0Q5xJTyV5hGsDBTiQI1 EokFDIYZIS6L4TogGaqFXhbEGeGk7WqaaW5bR1OQwlOCPV6eJGjA1VU9IAKbBQuCmbArrSInCUPy nFECxheHrcA/kDegKemB/MHXmzWLVbx5Mpd+fO+Glk2WTWk2pf2mG0Eqi5BnKArlAIEqsZwmFhhh SDlNE9sEOmztdPTe9WQbRzn+oT58lXpgx7ApQkXVWAcxi2SUQL5OC5/wwAaTOEzFHCRloipbck4C wiDhLwCIQIZImPgAub5X+F+icW4RV4fkKq6SOIu9OBR7GNv3xY1EUn6hB7RQDEs+2lNMRIIFhlmy NAyveRJkhOAoOzhTtat8g0AHbhbMAI7mYYYORmTMFoQH0iJnJvOUEC/Blm8gXqDNZrFLEmMJyggk GCQYddmTYqGiGYWcivBAzXaZPJW36HCgP/At/h6Ft5C+oq0hrb9BgAHs4v8d357C6AkdKljCGBoq adExbT5+CABI7Oo+gkKYBZ4IIBKzE+0G0I24VRHkR0CV4L+3RsydslS0ucSc3yCRgLaCgirnALQJ GUSF0XCI0laQEHBeISkzHUV1PLYyg6NNQgcGGTIdO5DjpV6akt88Dn27j+oKhJHZVlAvCyJK4sOc isJMmizgNuzbrCKmj0tYikStjxAAXjX8GJEcuigGLfOLOAT8jXaDzOFoy6/ICkr6ZFNQciVquGi2 BI6wrLhRBHeaEo1IQpbV+c9ZK9bKoGUqkgh00kCYAEc85BqE8CAXy1A1amfo3KJnIHU6NwERFJs1 P7s+oHn7Grct9uD8e9x822w1T/D/bdhd+6z5Dl63tjS27Vz2xK673139Te+v151Bf/pVC6nvgyXD MVIllzIDMKSx6NfhtPNraZXWyVt42Tptttrwpnn8TuxvsWDbJNjLIOrclqRayM+Rb75AZMqoLY58 jbMWOeQMBSf+FKEOhDMVcfZzjripFpQVJ8YtDSyLpeANHFaEhnENcUR0zGI4NE0hDvsbyLRdlSlv dUWg4PvqdlM5ts/M0P7w06B38EtncN2zoj1m0cqH7xItZET4gC1XalkqvxyDnIxpgdSLQgUDD9hH AFDl9P1RSTVEx48Vz9PkiTK+P2o4c0n14A2AWhDqMKJBD/o91zFKq52Ha9+0WthAj8creiS5voYe T0iP/egzhGxIzfWqTJfKQw2xOg08LdRKsa5ABUhJa7MIpXoBN3b8EaU2aNGSxXCiwJnMwHOLU+7J 5nmqQx4RShTS3EBvJ1W9WTm+hupOSXVUX/krWCQAIS3R/56OzkcfsMqSBgidqJLCJ03Q5SNk7Qc0 3VH/HCy/h0kRXrK/EUSWROV3pklgReyFAUApyOwiVFFD7JAzo1UgkJhLhJwqgZSuMm/fwByWKUEd jaeNHfkizjPgDYa7ALT5r/IG7LFMqDuFuozz2zkbC/xvoWREZ29MWMAEiEGjA0hfSh/C/TwhcGeC SrkyCXjOnu+QCuZ0TntMQ0+35/BhU7tGQPl9loeEK9Igy3UiuCfAVUqtMBbOTMnjMtP2CmMiG/Ma AuwM0I0ewF+SP2FVgdb8V71TBpGPG1GMyUtLGtWZ4/gdHNRsgIWoG2IuQ7kYLtDFpO+r9TKXxtBV n9w92m3YpUkfuATxgNOBDw2UcZUOzzOVkt3WrrMhUiMjfCy5Mw2jYWXW0Af6mcUoejQqJ6KqCFUR cRYoes/P6QMJuk3nTryyRRMdA2QKitzHKUZ8eAxE5RRsE8vtOpZdRl5mu5Zl0hYf04OsYRlJVJYn WJIXKkmoIjTLU+PVFnmsH7xOq8HLjSSvEb/eGnQ2UNEtloVoy1/QAVasiJwIBeQ3qtZZ4Aw8eEBi IjJFcirCk4PobpSF+rIGtpVPICsOEMVmrcKKQtqEsRki4Jh7/2l1FwaiSVhL5ZrDE9Z6H6Rqv1H1 kgaEEghcVC6PI2uQVYTiqrrYJ4TvgGo3bPCruMkU3Qu1gF+B2yNT4MH7wpil4m/au/sbGOTbGjTL pvEa1nhG1sjF9i8yiSjufw8YMhj3RoH2ldaimw20enUxiPMbvuaD6j2vDektxZpBWrIojgE6OUSU H/CQhPkMptij7fdDZbBszUCqNc4h0Cz8AlROF5BDDVS2X5sgb+AxgdvvOkSeVU2kpK/XMJN3ZCaf IKKoDmbnQbAIsnUMpTAQrL3SrQJbgOPbAJOIkIlOGgJoFas1knOhVcfvGS+7xoJ2hpqdySDcQPzv quKvyOE1FPCeFDCIvW902fwsMmownAq4vs6S2J6Or3vbjQJjlCIcwkENVuo0oA+u0kGyVq+mTopV SSp9oXAV3ZZTxUQtllnK2LgmajgTiVDdZLpzsgtjSZ2c6QKG5n/wkLx90RlMWCyqHLDMdUOdNEi6 ZeN2+DZJlHmHPMa3TAmW4TY6Zr2vmp3W/oq53cRxCKeCzcztWWtrHbnmdp5zkP7OWlIJo4Ovg1Ke c3eTKLIY4AbewD1hUH02vX9LZYS5epKjHF6E1DSSYW1Tlic7pd842aQ0ePSEgo28XyOutFqi7E+b BfUnHL/sA27Zq2QML4Sd5h8qlNCkpb4xwEMFzyIQZy54S2WsQgE2/we3EZZUNlFqq6aopUX7Kvrk 4q9esRuD6dLF2R3W7v5IvXLFZ2a8BJeflnlyi7c12BBDfUj8JdhHjqs3SqWMiO+00pzuw7CcUEnS sUcXo/6msb2U8TRSmxmzpjRF3OC31I/lePSTzGyi+5XCdJ0aXsUKdJ0a8GmX+ole8mrqDJKFLzBc 4PiN+DolrMtC5AYlkFGQOEVIkxQhXgcJwmIM17pSXDSdaSCxcjig27CkLsRWwuu6Z9Xnkj1vSFdN 9QHj95wwadGAVd6fyJdgl7gnuvyacWFcPZMIcEup3VNavSiZ1tozjNT1Oz4KY7eLxyW2AgHR7ZpT PzQXtGCdYLMh2DULkXl6QpB6D8QcnaLovjXZTb+nptJareRby3sNtMLV/A7WMa9hE8+ZfFG6AoOl Uz9bA5ZqS5qP76NymZ06I00tVpnB9v6WrDjDvOH2R1FQcVsJ1qo0rjqisXd9V1ZnPxhGqP+Pa8Pu la68SaljFOjpoxYzZpiCUzduJ0gXmyh95RqgooDX0DxfBkzkTF1iTffFixyjdHAAlDgKRz2AT5Sr 5Xys1zVNOF3KMKaSbsaqj9S9c1+HcY/LymwS69fTpAlJRYza/DK0tVLQLKTxv6wB8fnK6YYl0Zc7 X02XY0UdeKef6oBzYDocwlj6VBtccNMspR7qLfRN06O+7viHkf3evpjlEcXHJoq8WuHTeQX8Aevs WKxr7zIl7r7Vcy3aw+CJTT2co+AzXbwJqPPI6blgIqVqbeo0FOIwNAM88tpF8CDIkBTbf1CpH4x4 gH51Z1S+FT+Y9w39/geqgesaWUPcxYEvfpDJLajDitpZM4VwFfqmhI69Qv+YXHe7vclEt9xx+926 Ef/sFP95/940NZRL6KxybXLW4jyZqt4DJLF+59QxuzUAjq6LnvcmXbE7qLOOIEozCUCNwvn2k7ah WaqaL7dbcJNPzUbbzkaLnXI/C+0XkqVxjOsr7LDX7zrXv/YH/c74q35/2fkK9Cst4fs6hLVYY9We G+E23ZD3lHqSbAtSqStGNypxMq+0uJhbaTWbIRnWvm5BogSIbVe6bRcO/6ZbLrWFEbe/CRG6zmHM VnGYSlTIV4LzYGkaRxCeyMhcWicZtqTJRE+ldqBnVGEjXfspZayphevJlNVQ9D7tVzXEHQzijVOu fVPqE+C3pSDzRhNxC/c8rFSk5Y8qhUP+0BT1mM6bmsKL5UifJ/h93eGixI7FYDy+kp75wyJZWJs8 Xu0Pq+nCE9hKjl2ZttnsieZLakwrNaWZsvkCbBjtWLf5uX1qOpK5s/DJlxihG8EaO1hAKk340ZqX e+psK6IzpNJy94E1TJl8GixUg+0WxOfR8RFVo79xlGDfa0NpWG2DwEtkxoi4G4XHT/KbHu5At8Ud Y0ioF3WhlNHSkfckwA7zurY2j6I/drU9YhJM4QyelPerqy6MdLB7xIW7JGLTeneD3adPSI30ielP N2vDONIYrknI61HXEEreh1GBGu6wj0wXiEsJ1nRjLo36DVSQHPhmphnRJFIgf/CTIWEX+ll/yz0K K1+j2WTULWHp8WNZ/XPdNEKz955tvdPNH5VuSB1Gl5nuHNiDfJxkBH/2OSBpnN607ZVOo2Iwq2+i RCBBj/iUeidh9rbbrIhndxUVF5/WnuuVyA8s2JZHdqqGQUaOgB1KP6K83TU/YFf30VHr6Bjkcto+ +q0ejWuFsrjpcZIDPLqC3FO1wHzucXkX8R6YR1Qc0VWK1cT61tdyd6hzd8eX3amSiX60xAqA05bt ijO2ag24QSAQ+OPWVnIF3Rj+xMpYU7B3hsah21XBrVNihVyY0ZUZn1FQHc7ZXNzrRy+KI4fToFM0 4JrhzkWrfnDzqTOK0yMIkazSLstNLRhGKh2KaNxPn1DemjEOYLTC2DVfMtBDL7LbdrfLEtH7tZMs ztRt0fhgJVJlqKkHjcbnvTGgv+qgEXbYg92VBq+BTE/sWAdSms+uJ51PvaLiNbL1gX1jD8f16eSl 8qyWir5Q0cUayVRYQETKdrXzWzsC+8bqLmS4Bi/whAtqLSrxtvvLuYbtiCN28Bb+85u5BS9TNgua my+XGXweVkZAMXw0mBFm8bOxTxWqsDKTR0hA3/fYJdazvrMV61sR/VM2KCOOhqtS/n9tgCeiglzW MT0IdYulfRTNvfcp18tLdwPraej9ioYc3p7QTZkdjg3P8+Sw9X9Eey9ristbzzYps5akmOsTCl5k JeouiPMUvKrcogwu/Au6bFq0ppRo0UMdCXizfmgdn3832AhhOCKv2wBvcjjBsK4tbOp8HF44UMGc mf7MzrS9s60BFUIrfKcbv/ClLzOpZ9Jg/vuz+Kki8wmzIysdAW+xGrn6QC3s8G/ji267fdr+u4GB BQtAPsoXoEIPyyjw9yO3lfES9slT58CrXnoE+EfInyi5Ax+YWwDAwnUoxjF2TdcjopuVzZ0oI/Ny v+OLNJytBZXH38AoX57vys64sVYYq0YvoMX1Y+UKMfYyvPWA1VC16/Oryf3bWMbVC2vSXFndVvtI 7c8okLnXrFi6hbGm9HPpEUjjKwxvnU5Fo0qd+rSjlXy30tmvG7tNYZHOCs7DgTPzWAYWIhYYhmhD nLttFRCfcVUJZlwLI2AHcDKMlPLpIR7pc/82tgljFMWnGTXs5s3oh6i4fpknyzhVK9TMgQZE+Oly aiaukwDaRysJwD5PsBL8nThHubkAxTVhnfTNMWPDKH1ytH6Ufiuqp/3NEuotzqykrLT+qhRBle6f W0+0rRXRunyulVzr2CuuQA2FOhY3y7PrpU4W+VlRS3k+Lc5CiR5h7/3EHl3Y4K3a/hPNcLZlSz9r vnKaqlykRvbGyBxPzOWrAerYk8y34tXegnVU2F5RIe27Rnd6k1R7WQH6TieaO7v+bmhn/cuhPwRF ua/UVsLonFuv0GUc0K9AxJWqSKpnVarb9mjLVZP1JH28IukyZzUiX4sRzcSqzH2+eswDbHYfyo0d otX+fvFv7Zzjz1VIcEPK2L/gXVDxNFX590BMfd8tyOpbCP24NVZZsL7GN3b4g0fmrnm7MxH9yTY+ 5x7wA+rTzz3RHQ2n4/7H6+lo3KAPRuNPnWH/t860PxqKz73DCXw27l2Ne5PecDohSqMxEBKTq9Fw Mhr3zsXHr2KvfyE6w6/7TKM/nPbGw95UTEbdfg8E3Bmel74gMr3hp/6wx5h+2pn8RVyMxt2eOO9P uoNO/1J0BgPxpTMed4bTfm/SEL1fkYsJLX95Nej3zrma2x92B9fnSAW2IYajqRj0L/tTYGw6QqYM ka/AQmdKfFxPYKMX+FJTgKUvzZbHvf5QfOnD6kgLvkMOe0Rp3P/0eUoc4DvNBT84YhlFwpe9cfcz vO187JOBwYSL/nSI3F/gZHHVGU/73etBZyyursdXo0mvycZQ/ODCxPza0sY/xVDzKzK6GcJ9bpR/ g6thfseKTQKCEni67nUpLAus6mP3Spy9a9grJPVAT2lIvtwFc+RbebRAxiT80zGI8pAI1fC4pYMX bm5t/Q9QSwMEFAACAAgAAG65Ppjh1fQHAwAAAgcAAAoAAABzbGFwZC5jb25mrVRZTxsxEH5OpPyH EXkpUkgQUtUKiQeOHqiEPiT0FXnt2ayL12N8APvvO/Zm6aEStRK7ijae+Tz3fFM4uziDMyHv0CqQ ZGu9SV5ETRZqbXAynsIKEYIRTs2z/s3bfajJg8IotAnAwN+vkcufMM9X140OxQ6EhpJRcP11DRXC I3k+eBRKVAYZmqQSURw4EZvRfNGfJmNtpUkKRywKssFWLCR5nPf//64O2u4CWB12aPluJL9x6APZ HThyaI0SbgdEdXbjKe2COEdGy+4ZkV+nVS5XRvlkF33ZWTgZC78JRfWrJgv7i1P4YHMtYX21Al2D Ix+Bi6+w5qxUaVkOeQtn1Df0uu7OjUYbweID+iI+165Bv0o6Iny+/PT5ePnh4vJmeXywWl09HPUQ 9FHXWoqIH3NvOSOUyeNCsiLwwbOxucP2T/QX7P7lwul/OJi+zpMLWKkK8txVImBfN10m+RWd5Hdw MWJ/k3FIda2fRqM9JU9a5HVR1AptZ3yU1O5Nxp4oKssAaU+WwooN+tlL2CmcGxQ+4lMEJ0LgNVNh BhgcSi2M6coYxAahtzrbrmXJHkE8kFZzeF74YkK9eb8PgsnhRQoom37DNaMaQvRkNyASO7ExdzBT AlpJTA8bVPM+IfcI/HBTPcaeJ/CX0muPkvewg+XNag34pAOn43UOnYCH32p2UcKB0+uLfH/LLmQ5 xZyIlBiCzutQdSXfHj2kwXZoG/eSFMK7w0MmI65hyyxYgvwZw3zRcxFLYpcZi3vGNZZNiMyacHSY rVxapdllji93hMti88YrfMpnw9FjmOH9IKPqO1uXhutbVIOch04kEwHvZyFVgzTYrSD/ylAKM+gi GnQNWbSprfIG92L57D7p0l2P94lTUpkacj2IF8iILjNElTS7ZL4SLfeLh2Qybkklg4aEgoGkjMhm tH2gO85zGC4oWs2SfrDY3MXluvRhMh58bE3k+z0blQiGXAflFnU7yPc48pPtYUbpxD0Ovl4c/8FE CnhrSN5Rij+FjQjNrRzWo1/FvI4/AFBLAwQUAAIACADvg54+Ig2vK+YSAABqUAAACwAAAGNvcmUu c2NoZW1h7Txpc+JIsp/bv6LC7g3jfTYGcfiYty9CDbibGAwsx27325gPslSAtoVKo8M2M/H++8us QxLosNzX7Ds6YsZClcrKOysrSzohE4+6o74+JT3mUxKYG7o1jk7IW3X/lnif15eOZXiXAfUfqR9c Bo7hWZcC9NKEx+ri+vyRNOvX13Wtfk20RrNx2WhfNltweau1btvX5HPkh2Tw7JG3RycnZLGxA/LE /M8E/noGDLFVQs2crcInAyj6900YereXl09PT3UGo0hJnfnry/+oAxZE1GPezrfXm5A0b26uL3Bm QE4TXHcsci0jtJmLjxDdcQiHD4hPOU+WQjWjlh2Evv0QITQxXItEASW2SwIW+Sbldx5s1/B3ZMX8 bXBOnuxwQ5jP/7IoRCxbZtkr2+QznhNkwqP+1g5DahHmOjtiBMSIANy3f4NbDzsSpshFDNPowbFN MrJN6gZUUacTE1hFMYUoO0eMoviMR8N2jAeHk4rIVjZcj4a9wXg+kPcQQ8i8C4c+UodYtk/NkPkS HSV7jDMf6HZC6rvABIDv4CdnLa0NRTDXhiSmvgm3DmqGc8F8xBakNFTrnXHdDF1ETkPQs2nTcEdq oLsr0F2jexYraSaUNDtQEjcci5nRlroh10joGy4YpZgM+LFDsjV25IGiwGwQMQKtIt+1gw38Chmi YcC1DwrEMYv69iNnlVtkABIxQnh4y6fgAhHwTzYInD57jgFCtblIYMgIApAe4bcCYm89h+KDnCBF iedTMHJqnUuazomHSkaCEAunQqkARwHZ04aBFgE/XKODnCsjQ7sFSFPoagUP7xDHZ9tFtD57tC1k E3lA1RoP7JGLQirBZaEtbZkbEuA21r7hbdBWEZHtmk5kcWsFM3BIEJkbQXaQK646IR/YE9gVmA1i RByxgkAk1FlxMcDEKArhH4DeRhfbkScD7IvPAY4B3uDTLbDgrrnFbnIoB5H4dEV96ppAUcg4VMak lM4QTTwItmq49m/CVs5BlSb1QpzXpRQ5Bq/m2LzI9xjomq04M+gzwL+7TjAFIYjC8K1AqMpGERnw BH/aZya1IlATIkQMMQ9gunRlu4L7fbpjhPzxICDbKOACU/8Q0Yo5DsgaFM0NDwTxawS+bHExSD+g 6AG2C3ccw11Hxhro4KJAm3ARy8Bdo+1xV/sm/4RjUghKEOiAGh7xwC3QI8G2XLwn7FDGQ4+GkeFw c3qywcakbXBEPn1kn5PImKdZdDQwGRQT8wPlhGsXbTGhqCBcbDBOYvwWHmoy8FWuEhARRS8OEi/i aYAjOtbnZDg/Jg9GYAs/WHwYkOF4MZiNBwsyn/SGg8Unoo/7+wOD8fvheDCYDcfvOT36/GdyN5n1 BqQ/nPdG+vB+TvTRiPxdn8308WI4mJ+TwcfpbDCfk8mMDO+no+Ggfw4Ie6NlX2J5t1yQ8WQBMf5+ uBjAjBOY+JPC8Qko0BecjCUkgMmdpAimvdcXw8kYUXwYzAbDMfn7EOZGVDCMNA44otnw/YcFnx9/ SRpSJAJOxHE/mPU+wB393XA0hGkB/m64GCPpd/gsmeqzxbC3HOkzMl3OppP5oH6E2eEIfZJHmYBg EnlsybUHaJZuwW18tr09Onkzu+sRTetol/C/LqkJ0DP+/Jw6kMJiP0TrNz/vYVEImtpVm9Qi27q0 zDOFtHF1Q2rL2TC+obWvSM0yAWby8E/AHA90rmFg+vMwdQMe7e9cYwtJuh9n0jmkKQhPgYJrdzSY FuwSzBac0uqzLZjZHvEpMwRnyKNda11dcdoVUeJxxbQRypRBwp1HhdyIFFoXQAE22AWAMF7axU/g A6RGtHqn3q43yFi/H5BTxmfpOUD1KVDQH8x75BTwIbpbIkaJicM0UEsH8Cs73CH44K9LnduBABxa OASh3r83QnMDAPNPYCsfYZnYqnfrTZi3WW+2u3DZ7NSbGvyot67JWWWqm4LqGjk1HBuCrxTS2NjS 0/jewA39nbh1lmUJlEh5DhXAkvI9ZjAvQ+iPeLJGRNW5aWpkDj41Glz8TR8tB8haPiealP9nlz05 1FrTYWIZp0eHRMdQaQMCsJhkzETDtQtrc0FrFVI7v7e0q+71f71C/q1Y/qYLAscFE3MLRS2GucRr wRlPtSJvJkaEoReZcyH2ow7my6nQUKHg2jEJAZIQwCpPzn84PRgtLEBX4LTO7uwVVFQgoiO1BwtV 23DG0faB+lmtiVHi8uFD5ynT3fLdfDFL3Z9HD7j+c9dBZe22279321K1IjY1b8RKxOY5sAbKixJH gST4sd5pNHiakwycFTDfTYyA20CU9rdEBjjjLQmfGFQgUAr5kEsnF61mt0vkI/DXoilxVzLaJkAd ONjJF5CZsdUMcZoiW1CZMs1qDn4VT+/A9A4zIeCEOWKStirHY9MEi5TBFxaVNmZN261kmteJf4To H1CV0Ik/xeUNrJ6L5udguKryJODXE3KTIsSnVBCDF7plAaognwwEIIaAiCtfFaO/s89ARGxqIh4W pJ9GzBMDdtK1RZFg0zB70nyAAgOIg2V8JWk2k9THooO5DWcJXl2FAohGEYB+FSEqc0EYc2g26PHb JFkEiQ2TvciXnqRq4peZ5xQM0PRtT+S/jBfHo48HmfKk2HROXradk4rG09BUyO1TqP9Nzj8UNdSF MgwKxDk1fHPzHhZ3tEi67TizxKB5iQUHyRpHz4HpF+Y6rWL8WqdE5yrfPUQB1E1B0IPZ1rAEzpKm IIiZgPzRXiszwSkU+KHhqPCTIV0Mq+CTT/cIloZFtOPYl2TqZgnpV3uk91ieNUi6ZTb97sJuN8pk fZ0ieLJaQXn0jj1naZ7CMBHjRAD8wXTfKLo3u8CGXNynDgQRfydo5LE1y4SEJQpYcSTB/2C711SN F0Lt6W2YS4sWqgsFQGKImPaDh/cZOBj8Ai46DahCyphopph4LmPgOSG+wrRayZRaasqQPi9wawtS Z1Ld5hMAoETBkj3gCvSUBAEtqbpWhhnYUM/QxYFKceg5L/vfqSdI7c54PstTdYXcUCYtlbGeAbYw tn5ETETPhlYojqBKMufcbPaNa2/oC0yr1f292SkzLZXVbFd2PnCBZM/74yIz2wOEkqE/lsXdD+So W8aRynQ+XUMyoj61CjWSgGQTHy7Q9pLl1+Yx7SpZvoW2kODQtbBnxnLknIICmSdg371kfiGgxsmN dyNAdCrw39Nww6yc1KwAgSWZIrYKtEKEb2eL3QLKbhLKAtWJKl7opIDyljs5SKoLsVWV5pZKT0Hk ecyH5avueY5so/YYuNpzmLP0VcDESKD5jr4Af2FHsvKGZAHNKhttaX6EEPf5/iJZ+yzypDdlthRL 5lDphz25eVPw26Qmt5MEm2dfMI2qqHzm0IlpRp7h5sibyRFkCSHLJqq6iZjUOFR3ApZTx0Fgxfmo w6uaZIv2q6dWIT8KqD+FIvWJ+VZm/kut1bgCN5HjSArC7294m4A6HeOr1IjtRhxhTsi9bPbxJp6M Elg8rclP4sQBwPDa2aR+KM4X0MGzYYr6g/gR5nQPTAE37m6KNuta3RTHvQRTXooGNJzR9Izn/ECE pGgvBOdRVcW/rn8o+yrxmHoF5nv6vwjrBcyo/CMPk4S7GX1kIgRi8VnEVgzOG60yZDrwwCGHL3Nw 85UcqDyVEmE1HlIPfHMuAlhdyEMj2F2HxUfSrU8d/ilqSKg8ZvosCFJWNjVsv5AdhN1jygPo13PS bLwi+rVV9uIdkx+zJ5a0mApo0uLiZg0LJLmPerp284qZle2Dxr5pJ6fdiosAO7QNJ8hb9YsRzAMB 2/JtcjwlAz8Rd3BOACs/z4B0yIYUEFivRoDKhmsKeZ1b9V8jKEPy60yO61c1rhbH6Hiw3ogRVJtY 5cLnTqOxdG0w/LIKV7SHIg5H7DRgbEUPdrhf9bxoIN0S8lTissrkAQuFX1OjxQXCZNbnJzJSIxMf zzUd1mhfWUKUMKRSUf4O7QFjCmhvr7dasV5Sh7WTCoaFzGROaddZARU1nXOQVJeU9prApdJGZu33 Dfv2xc1eFeCF8d8XLP2la+RVADGFaQzVC5ISo+qokL5hkDrK/JcDFDju99qfTJ8v+NIlQ0fLlInO Glczm21QWh6moSrY41eubDpJg8oJjZfWNBzocB3z05etYwroUWnF2lr5u9fqIEz/vl8pX3RVvvAC GlnM3W1jnJAbtEatHW7OIGio0fhoZdy93e/7xUeaDg4ZqRNN/EBTNkIIaA4sSevGh5lC5uUUk3BX Hb4A86C+eNbcGDZvDOpo6npvAZf3y/mCpE5E5YaoPAKUF/JDRTkkGC6Jh1AKSBLMuuwtljN9pGbO nGnC+fOmUy4hzypkdWuQZChnPjGdCX/1T4A01Wskb0mqw0rOiihQ1q7OLeSRkBrLpUHMLTr+b4nc DOBXaXICHHSq0qWsPt30zqHNJQcAhUJiitD0jkGWyJj4ww4peXv05k1qaxxAMpuzgrnMvih/tGCr ER5JNUTkr9xeBcdy0KcB+II9bxgB8KI2A1eH1Ndeg0/+Fh1KQXd6+xiHC/tqr9ZxJ0fH4gjEi5qW 5x9KFR79X9P4v7zC4/499YNcdybxSKFaIdK4MB9oD+vKXAVnRZYouRKdV7mGOS2iOmOae1yIHzkR UxyweUv+P6iU2xiLEkMrVNl1rspmLO9kU1ZhqQ3x/AzrKqX9j1JWsaYAUeIT6cYBKqOQTqVeqcEi BZMD9SJ4VQVX9FBVR/LCbLJCREFePOHj8QYPqfXHwVl5dJFl30GEyeaGVEwRjRzJR+Ugo84gnorj mC5uTZWEmBTUy/EFWXFKaH/RikFl+XZMKlqxtNQCOybfLKv9cGN9KRA14xIiaWtOxWthuXpNdz+9 GK5CJErZX/Qa14nPfaZmHqgTneX07R38LPCfnJ4zUGa6iS+VtIn33Uq5k4NaqcZbXLzP9bxwkLw8 K2tBY43vltUMIl6RVrEhI5pM+s573aOQqriEp/iaUS5haqSS4pN3FcrjUHWbiN+DCH3mrvUIamzg W0hgGeRtQxlEwPKmVAIsG6wxH/ry43A01GefJBsH3ctCgrqZ/hLak+p/5RbKKaxGCrCIkhop6L6h uRZ1tXh82GtBglBRLXk9o0Lmrvazl9izfzmHyY3JOJXxRpd4OHVM7YX8lt65/BFZ7jrVtp5TM0J5 l25WG6J1HUjYgz3rPG0eRJV4v7CEqtTWS66BXfxNk5Pljx+9iQkgYv6c7cKS+eP26WzUT72/P2W2 G5brLx1JS8y02Lh5an8FrfHpU2trlZMmdygL67L/vVst5QvtKkXRFy5DcrwQ3zIVO4+kd7ATy9+I BYBcNat1i/fZzkR8eAwdc/rzsCy+g84rhvf4ZC5M1tOzU+FEr4nn3Nq+TTh/WxDKC1nZ6xf0ZqN8 bsrFluuQBy8ML/hb0svZkDjGA43fOU5027i6ebkPl25CaJ0GnlhW2YijpRbMsL/xDXhvMc1gGMZv eogPqqS8RXxJxZO1NEeTOZSQOl9T7cBBVt6HpLeSZUtC+kT1KA7ol70J+XkQ/tmAgHcSUKD772KX 2VgyUeJsffyoBn6BQmkC31oXZwm4ZFz6RI4DME1x4iE4xqcO9dKo34AptTVIDVqj0WqAZvC/ehPE pc5VQOA8FYkUL/befcQpb0XiTHcGf8jJEMjauedCilhqHcUcbQ0bX6r0V+a1pt3Djwd2cPhdMAYX AEAUxBF+JiKHs6HeEZTjeIY9GD3kkMO93IjvxjzuW2Q+h6mXUAL+SRm17MnapuBOQCUrnr0+W9Ei Os6r8ZvB/GMJ/0bUJxEq60PrJAqx8BVbi3/uoMe2HiQyWI9kFHKJ+G+JgMO3wyVgbic6VsqbKhqp ci6im3lz9yThujhmcDSt+JiO+lrE/go0j68ShRCuD8tMEdG6KiIC/6osG38XYm96ePaWL8lfmlEs 2+NXwrX2EX4OBr/jcnr42YrTVHgLPGpiaAhIfzwn/0B1NlrtX/BCa143f+FYNkyezQoERFNr/SIC J34B5vCFUNxM5cTWOQEAZQfnHM+j4UQ0efc3RcWGRY6FYZinFPkZIPF9HGzQ6+/Gd7c8tMI/qYy/ EJ+xkFzK5PfnGulPFvLHmYDkAAQg51O9NxD3BADcGw0W/eF78g/y526zpn5dkg+fph8GY4jl8o6Q gPr1F/Kn51bjonUDkH96bjcvOjq/6jYvrnTyEzluHJMLcnxzDHeP9eOL4//kVwZc/XYsMHFaCMcE C+mCfz+BYgzIqbVjciyZkYTx5/rFz212HhTf8OCFehDFQuSEg+IHPUgisCSuHdePz6pH7isZKbJG lglqUm+H5lL2Bvj3iBSJX7Y7N+TiIv2SLZC3Mh4ZP+MjU1GN+z2WI/LTeFnhNPEzeW0QR7PVad/g 4Q1I0nEApTKl8b/xC/KwzjWDGzmWjqYt7bpxSxy6NsxdykPwxAWHVm918Lf1wWmDHya5+ID7fwNQ SwMEFAACAAgA74OePpHXiJgUDQAALUkAABQAAABpbmV0b3JncGVyc29uLnNjaGVtYdVce2/jNhL/ 2/4URBIgWSBxLPmdOxzgOt7WbZJN46S3xSLA0RJjsyuJiijF6376mxnqZSftZeu9uNqHLVPkcPib B2coUvtMBiJW0TwUkVZBQzsL4XN2csImUP4hml9TOTu6eT+ye4P+u/o+O/gQiuDifHh9xsLP81PP 5eGpFtET1DzVHg/dU0Pl9CXSx0/Malj9ht3oMLtpNU+b7VOrBZdnduus3Wefkyhm4y8hO6jv77Pb hdRsqaLPDL5DDrfUA8u6Z1P1EC95JNg/F3Ecnp2eLpfLhoK7yFIDej79VwOoIKGRCleRnC9iZg0G /RPsGYiLgtZ7lQQujyUwivWHnseovmaRoMG5Gakb4UodR3KWYG3GA5clWgCOTKskcgSVzGTAoxV7 UJGvj9lSxgumIvpWSYxUfOXKB+lQj8cMBwEw+TKOhctU4K0Y14wnUD2Sv0PRbMXiErtI4TqZedJh F9IRgRYZd0PmwFARphix88xdhI8/cenxmUesIrEHCdcXk9H4ajpOy5BCrMITTzwJj7kyEg5IMCUn 2NrAVQR8e7GIAhgEVF/BTxpaWRoZwySNlJnGIvY9lAzo0h9qGdw7F9DY1SwJVQA/GRQ8yECazh8A Zvax0Wk22TA2TAl2uwoN/HDvw+w3YJ6NPK41jIn9oDyXqNwFEsUCckzlNXFFEIMwgAd2dHcz0e/Y J2Sk2Rvc1/drR46KRKq9hjEGKE8T3+cFMsTJ0aD7jt2BtrCpMSPoh3SD5I8wPLUMabvT/SPSqJWj D9PJ1ZhGMgkQYRGnY00JIxHL7rXvGZDQYGc5EaDh8ChVinpqQX7igYi4l4AmwTg9F/UBGHMRGJCx ilwaBVXR2Zgy3VER0InEHIVP+spCjwPaAKxyJEeNpQEC6DJw5ZN0E+416jwTS4xSOWJ2w+o2+u1m A+zfavVazUYLL+u1q+HlmB0WXB/Wa+fj6Ygdptpwxp7EQjpemaMX+IFm45/vhheT218BAi0m8wDQ veSxs6jXpnffTW9vSuXTZIa6HMx1VuPXq9vhR3BOrUYX+Gojb+0uXFqdhmVb+LPDCF9XoCfyQWmu En8mEJ2RcgVJu7iH0C6BbcCFGQ/IZsJT0GGDGak4ABj3tIJyIIHcODEYfpD4Ai7ZkWjMG8fMslvt dzhi7oULvnFz+N3oFCq8ey3adob25hieYy4zqwDPUR4Wilqi2wOe5jyQv5MI3g58qUHaqyvuI2j/ XoggKwJyyBXwGIErEjoUoJweAJpxDH5VnHhgLEynxuuBCh0zCV4rNYiHxEO5zUC50VHCZQoD+GMW QJ/pXbQdEONUBuA/FBgLiAcFcAKUyBOhFDT0g+LXoNzBIfn4kiEeI7PcdcmfcY/lAqS2wA+QCoRw qaNzM0TDArDqoidEYwa9ID8fJlGocBZ4pR60c7srAfpcCcJIPIgogp42Bg+qvY48wg668gZ6ALUm V99fjE9+GV7cjY1WCD/01EqI3CCvUjvZtJtcqyN0X3IeGB+Ymegxgg+zMqrNDNjEGYOmOhcagFtc wIxINFPXh84n831lczC6MfdSl+q+Vi6tTCrrA3oumHQ8xGjZUoMcit0Z6ksC0jqorlQ6mVRgFBUX RQ3+FuaC8RL8vEsjgdzX4eyf1onwRj6QSHjEul7IEKcxI5Y0bgBKxjVICJ7BT+yNFDgFjhHk3jHb G6dE8NpENXh1C7Tp7heKJL099Iso4L274HOglsEeOlQoW5lemA9uMPPAr5Rfe9OqcNzPBUk0QJ1M LZrs0L9mWvg2U1zNoBjdKO//KZrrSEGcJqKh60uSQ1aA1zfCESHRkvFbycjqZkLKRv83FRAM+7dQ zK8XKlYlAWnQcoERBjoiH6+lz+cmmM4DwETjVIki/PF6/D17L0nGZAwOeMO5gDQ08nnMPv34fvL+ voEuU2FEsIAybJb3vBkuLPl6UJBmpJTSbeYQofQU5LUosgDDf5jhReBQwOMWGRZSkTFkkwmkCxSh esrBYP+5RJuNQQOiVBDswG42W00QLf5vdJuZTHO+nwuVGywIrcPXSMHuGynksckFIJdA67K5QB7i UI5SzkkOdSmgWUaYbKNHZjpUnwXOT15KKYvQi6CQ0AjSZJfiNUiaIggyVQCW6ZDUF4nPA4wAHeWH gE7aAhygmXt+MdlVHrNtiPDybnoLTQNKTkm3KOVey3mxZOigdZ5ko2YLwXEeNHldpgMSh2Oy2G7/ Pl2AAOUUX1LTPmNETIvHhPjf2yC7x/bO9nDiXqQKwJRZnShhw5kuT6cbA3p1zDPItOSZRP8sIH0m v1x6b+0UXop30IlNLyeX45GIYrPQg/o5ZNc/jab7PSOaltW5h4gEw51zHvNjDKojQXIBPYgpiUTL B6jToIiyAkms0poQVNMYfpCbeanP1P+D0CaxaY3pvg++00VLQepp0r/gT2Au7D9pzzRFIlUXOMuj KT7TcA+oZNUOjd4V2p0tPBW6gDU55V+pRDQmCxCyoaWUOAUPKINs9Ub70hcjHvKZ9ED70WxIvwm3 bqt1b3jHf0AG5jDpJz5ov3agV6gNGMqIERoQas4VKMvCB0EXBNcMkoxtjWvM1ky6Q57dJcYitBYd k32Vl/hgPkRoD1+SwD9MvUMUwUOxCHe82SEJp1Bv9YTz+4Im0ags0KIFqvn01AwxDL10MVHT+mW+ rhnA/HHG9lIu9hgEZIGGPjLDvvpwm+d0MIfoFQjrC2qcafDaCKtZnr03IXhuxqkVFLqfr0bpJAxV FKcDe9WE0ClMDulaNvzAC7Zv2eyTKboHaCnAQa/1YCZZxA/8oZl4QW+NeoJrN8FWvEJbC0xl48Fp uYGS+lI5mafREdLyYtUU142lI45TV14wWBJi4V/NmsLtplasaSFQ+l96aERg+inpHi4r5mSBTGr1 qObX7z+y6/O7fBQ8Ez7Z/i7UyV6PBs1gXpgMNgVWFgtgUWgBDPErVOnr/tDjhQSw89O8DnUpX5M2 8/3l+IfJlF2DYgO30xWIzqdIn6KeiVtcmbkLgnQc9w4XCq08500Zq8YCIWIaLt2RSmiWuuZaL3Fx mwrQkraE9/Xw5etrGTvfAMBXxMa9dLlFxuInsTqH+XD9V+pQTLaCTumcpszQPMqawwysY/BbHngw sOApNPwsVn8bpWzmoWJpSBXSzFQd/wbqmT8IWOPpTXQ0y6IfZKTjWwjzPDWndMU4SeMdaYqDiVRD kgzVWAz1GFUsZrEGezPFG+R4rXP9JoD1/tKkxKZx+rx8tACVEhjk/IxT/hOPJEagmlmocnazTg8N H60/FMFUvEDHxJp5LmjElN1gmed5E+n0crcAo6iOO3Ae7a0gtyES3A3g/WYBuF0lwFtbAd6KdgZ4 8Zj8sVUlwNtbAd6OF7sC3C4Ab1cJ8M5WgHd2B3irALxTmd0IzmN3K7y7u8O7XeDdrRDeva3w7u0K 7U6Bdq9K7qS/FdyCdlzuCPJuAXm/Qgo+2Arxwc4cyqAUogwqhLfV3Apwq7krxO1macq0mlWCfLtU 07J2p+RlyK0qQb5dqmnZu4O8FKhYdpUg3y7ZtFq7g7wUrVitKkG+Xbpp7S7fHJSiFatdJci3Szit 3WWcg14J8iqlnNZ2Oae1u6Rz0C9BXqWs09ou7bR6u4O8vDbeqxLk26WeVn93cXlpddyqUuppbZd7 WoPdQV5KPq0qZZ/2dtmnvcPss7RCblcl+wR0xlfnr3oo+rUPXF9+4joM9DI7HGa2AxXHcMsP+xl3 HNoVgDu8tnoWS1uEqVfr7dba8lCKV+YJrAHa/hZA228HdL8EtF0loFvfAujW2wE9KAHdqhLQ7W8B dPvt4tNmCejqJL7fwtV/9QxD+5FL70ug4/1ivQzEHeIbK4JYs1CoEDpfLhTt831+Xh/PUZbQM++w 8PE00So7MYCHPOIoceIkwkMv9DYF3IJMh5Aj+UR7kh8i5ZP2lKlxL+XInIIvnVqW9OYG22KfPsLn faOu6F0NRLz2sqbYDbvO4E+6J7U84uc6k593+rDGDsvqI6Hp3fWL3Jqbtzd3o9u7m+FFvXY5/JUd 1Ws1nrhSsQM2w0NcQusRADnHXd4HpRcuwI/Nk/XsABqXDllDlfXDvVCgdVAqprdYHOSnAOFyDjgH pjEQW4CIrhd4mueA0bXSMfeGrgty11BG54W4h5fFeTFsCLooPOHe3Uzglg+6SV8BnxMTvppJ6g1H GZpCaBSa5ixSyi8YFk4kYk6jT6Sbcls+poBNv3SazSSQj4koXrGBtDeP+VDlF0+vHJQ3zR/km6QP 8k2+xGppByP8Xt+h97wA+jqgGIvRl22+WuarjYMrbZd9V6/9hc13eCRFgEfNHWxqqeuFZVN10g3k In1vSf7akjmocXp+4E/896ssqFWyoHVOvt6Eal9tP4XsDPQGeQO8wd157NBnlz579Nmnz4Fp1TRf prVlmlumvWUI4Lb1Gl0YIpahYhkylqEDwX2tRoL9Srn+F1BLAQIUABQAAgAIAPmyjTwmALxUVhYA AOlMAAAOAAAAAAAAAAEAIAAAAAAAAABwcG9saWN5LnNjaGVtYVBLAQIUABQAAgAIAABuuT6Y4dX0 BwMAAAIHAAAKAAAAAAAAAAEAIAAAAIIWAABzbGFwZC5jb25mUEsBAhQAFAACAAgA74OePiINryvm EgAAalAAAAsAAAAAAAAAAQAgAAAAsRkAAGNvcmUuc2NoZW1hUEsBAhQAFAACAAgA74OePpHXiJgU DQAALUkAABQAAAAAAAAAAQAgAAAAwCwAAGluZXRvcmdwZXJzb24uc2NoZW1hUEsFBgAAAAAEAAQA 7wAAAAY6AAAAAA== ------_=_NextPart_001_01CC1AB8.7233BFF9--

1 0

(ITS#6952) Unable to get the Accout Locked message via Password Policy
by srinivas.kondamadugu＠mphasis.com 25 May '11

25 May '11

Full_Name: Srinivas Kondamadugu Version: 2.4.23 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (15.195.185.82) We installed and configured the OpenLDAP password policy and while testing with bind operation we are getting Error code as 49 (invalid credentials) but we need account locked messages to appeared. Even if we use ppolicy_use_lockout in ppolicy.la we are getting the same error code and when we view the admin console we are not able to see any operation attribute for the user w.r.t password policy etc., Configuration snnippet # required if the overlay is built dynamically moduleload ppolicy.la # invokes password policies for this DIT only overlay ppolicy # define the default policy ppolicy_default "uid=default,ou=pwpolicies,dc=mehisdomain,dc=com" ppolicy_use_lockout ppolicy_hash_cleartext

1 0

Re: (ITS#6915) memberof+accesslog duplicate reqStart
by hyc＠symas.com 24 May '11

24 May '11

ebackes(a)symas.com wrote: > The openldap-techincal traffic Michael mentioned is almost certainly the same issue. In our case, yes this could have appeared as early as 2.4.23. > > What I'm seeing now is that formerly memberof functioned with accesslog in > a delta-syncrepl type environment by having each stage of replication (master, hub, replica, etc) run the overlay to supply the changes. It seems like originally only the group change went through and the overlay relied on reqStart collisions to prevent its internal operations from reaching the replication log. > > So: the recent change that exposed this was something that changed the > order these things are applied and sent to accesslog. > > Changing memberof again to reveal only the group changes should probably a separate ITS, or perhaps a discussion (openldap-devel) on how we want it to work. As-is, the fix in git master breaks compatibility with configurations from prior releases. The breakage seems to go back to ITS#6329. The original design for memberOf was for the internal modifications to not be replicated. Instead, any replicas that wanted to maintain member information was expected to run an identical memberOf overlay configuration. The fact that memberOf didn't update the entryCSN on its internal modifications was intentional. This design constraint was broken by the fix to ITS#6329. The patch for #6329 and any ripple effect from it needs to be reverted. In general it's incorrect to replicate internal operations. The fanout from replicating every internal operation would be too large and the information content of what is being replicated is essentially nil. When the servers are configured identically they will maintain identical data by virtue of the overlays on each node performing the same internal operations in response to a given sequence of user operations. > Emily Backes > Symas - The LDAP Guys > ebackes(a)symas.com > > > > -- -- 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

(ITS#6951) pcache: valgrind reports some errors when bind-caching is enabled
by ralf＠OpenLDAP.org 24 May '11

24 May '11

Full_Name: Ralf Haferkamp Version: 2.4.25/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.222.177) Submitted by: ralf I get this when starting a bind-caching slapo-pcache setup under valgrind: ==18290== Invalid write of size 1 ==18290== at 0x59628F: ftemp_attrs (pcache.c:490) ==18290== by 0x5A29E0: pc_cf_gen (pcache.c:4199) [..] ==18290== Address 0x768dcc6 is 0 bytes after a block of size 6 alloc'd ==18290== at 0x4C2683D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==18290== by 0x509CC85: ber_memalloc_x (memory.c:228) ==18290== by 0x46B958: ch_malloc (ch_malloc.c:54) ==18290== by 0x596206: ftemp_attrs (pcache.c:448) [..] ==18290== ==18290== Invalid write of size 1 ==18290== at 0x5A3153: pc_cf_gen (pcache.c:4281) [..] ==18290== Address 0x768e437 is 0 bytes after a block of size 7 alloc'd ==18290== at 0x4C2683D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==18290== by 0x509CC85: ber_memalloc_x (memory.c:228) ==18290== by 0x46B958: ch_malloc (ch_malloc.c:54) ==18290== by 0x5A30D5: pc_cf_gen (pcache.c:4270) [..] A fix is on the way to HEAD.

1 0

Re: (ITS#6920) OpenLDAP 2.4.25 / Berkeley DB 4.8.30 Solaris 10 x86 slapd hangs
by fumiyas＠osstech.jp 24 May '11

24 May '11

At Thu, 28 Apr 2011 18:05:43 GMT, mslby(a)deshaw.com wrote: > My company uses OpenLDAP 2.4.25 with Berkeley DB 4.8.30 compiled on Solaris > 10 x86 using Sun Studio. OpenLDAP is used as the backend for generic naming > services (passwd, group, netgroup etc?) as well as holding mail routing and > some custom data. We have master and slave servers and are using syncrepl > refresh and persist. Are you using Solaris nss_ldap and ldap_cachemgr(1M) on your Solaris 10 with OpenLDAP slapd? If so, Solaris libldap.so breaks your slapd process as the following scenario: (1) slapd calls some name service functions, e.g. getpwnam(3C). (2) Solaris nss_ldap (/usr/lib/nss_ldap.so.1) is loaded. (3) Solaris libldap.so (/usr/lib/libldap.so.5) is loaded. (4) Solaris libldap.so overrides ldap_*() and ber_*() functions in slapd (or OpenLDAP libldap_r.so and liblber.so). (5) OpenLDAP calls ldap_*() and ber_*() functions that are belong to Solaris libldap.so, not OpenLDAP's one. See also: http://www.openldap.org/lists/openldap-technical/200902/msg00000.html https://bugzilla.mozilla.org/show_bug.cgi?id=292127 http://bugzilla.padl.com/show_bug.cgi?id=203 -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- Personal Home: http://www.SFO.jp/blog/ > Lately we have been experiencing hangs with slapd and I cannot figure out > what the cause is. Things will be humming along and then slapd will simply > stop accepting connections and answering any requests for reads/writes. We > have set the loglevel to 256 and there is nothing in the logs that > indicates what the issue it. At the time that the process goes catatonic all > syslogs from slapd stop > > I have not found a way to reproduce this on demand. > > Today we have had three hangs and the truss ouput is exactly the same on > all process. Once the slapd process gets in this state a simple kill does > not work. The syslog always says that slapd is waiting for tasks to > complete but this never happens. I need to kill -9 the pid. > > I am going to include all of the debug info that I have collected and > hopefully someone will have some idea what is going on. I also have a gcore > of the process if anyone wants and info from that > > All and any help is greatly appreciated

1 0

Re: (ITS#6950) pcache crashing when '+' or '*' is used in attrsets
by Ralf Haferkamp 24 May '11

24 May '11

'1.1' is also causing a crash (on shutdown)

1 0

(ITS#6950) pcache crashing when '+' or '*' is used in attrsets
by ralf＠OpenLDAP.org 24 May '11

24 May '11

Full_Name: Ralf Haferkamp Version: 2.4.25/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.222.177) Submitted by: ralf The pcache overlay crashes slapd when using * or + in a pcacheAttrset. It seems the problem was introduced with the recent changes to support caching of undefined attributes. Fix is on the way.

1 0

Re: (ITS#6941
by rhafer＠suse.de 24 May '11

24 May '11

> Some how this got duplicated from ITS#6940, please close. Done.

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it 24 May '11

24 May '11

On 05/23/2011 10:15 PM, Tim.Mooney(a)ndsu.edu wrote: > Thank you Pierangelo. We've been running with that patch since last > Friday without problems, so I'm comfortable with the fix. > > If you can do so without having to spend much time on it, could you give > a brief overview of what you believe might be involved in implementing the > longer fix? I won't make any promises, but if you give me a hint at what > would be involved, I might be able to contribute the code to skip mapping > when not needed. That seems like it would be very beneficial. I don't think it's worth the effort, because mapping and rewriting are somehow tightly joined, so as soon as the overlay is loaded it is nearly always worth to scan all data to check whether intervention is needed. Further optimization would make the code even more hairy without significant improvements. p.

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by Tim.Mooney＠ndsu.edu 23 May '11

23 May '11

In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, Pierangelo...: > On 05/20/2011 10:21 PM, Tim.Mooney(a)ndsu.edu wrote: >> In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, >> masarati(a)aero.po...: >> >>> The bug is caused by the fact that "mapping" is always on, and slapo-rwm >>> checks whether there is anything it can/need to do about special >>> attributes, and it (incorrectly) assumed attributes have an equality rule. >>> It has nothing to do with the fact that you defined no rules for search >>> or so. >>> >>> The quick fix would be to check whether sat_equality is NULL; the >>> (possibly) long fix would be to entirely skip mapping when not needed. >> >> My apologies for the delay in responding. >> >> I've uploaded a patch, >> >> TimMooney-110520.patch >> >> to incoming. It tests that sat_equality is not NULL before dereferencing. >> >> Is this essentially what you had in mind as a fix? > > Yes. Fixed in HEAD. Thanks, p. Thank you Pierangelo. We've been running with that patch since last Friday without problems, so I'm comfortable with the fix. If you can do so without having to spend much time on it, could you give a brief overview of what you believe might be involved in implementing the longer fix? I won't make any promises, but if you give me a hint at what would be involved, I might be able to contribute the code to skip mapping when not needed. That seems like it would be very beneficial. Tim -- Tim Mooney Tim.Mooney(a)ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164

1 0

(ITS#6949) OpenLDAP Logging
by andrew.stringer＠igt.com 23 May '11

23 May '11

Full_Name: Andrew Stringer Version: @(#) $OpenLDAP: slapd 2.3.43 OS: Red Hat 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.205.160.142) Software Enhancement Requests Hi, we are currently rebuilding our LDAP tree using vendor current version of software, including openLDAP. I don't have much LDAP experience, so may be there is already a way to do this, but I have not found it despite several trips to Google. etc.. Logging in openldap seems to be all via syslog and controlled by a value made up by adding the code for a particular log entry of interest, all of which are sent to syslog under one facility number. I feel that logging could be improved by allowing logging similar to how BIND's named does it, namely having different log files for queries, normal operational logs and zone transfers (or in LDAP's case, replications). This would make it much easier to monitor the activity of the server without having to grep out unwanted information to see the required detail. Regards, Andrew.

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it 23 May '11

23 May '11

On 05/20/2011 10:21 PM, Tim.Mooney(a)ndsu.edu wrote: > In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, masarati(a)aero.po...: > >> The bug is caused by the fact that "mapping" is always on, and slapo-rwm >> checks whether there is anything it can/need to do about special >> attributes, and it (incorrectly) assumed attributes have an equality rule. >> It has nothing to do with the fact that you defined no rules for search >> or so. >> >> The quick fix would be to check whether sat_equality is NULL; the >> (possibly) long fix would be to entirely skip mapping when not needed. > > My apologies for the delay in responding. > > I've uploaded a patch, > > TimMooney-110520.patch > > to incoming. It tests that sat_equality is not NULL before dereferencing. > > Is this essentially what you had in mind as a fix? Yes. Fixed in HEAD. Thanks, p.

1 0

RE: (ITS#6944) Add option to limit or remove operation list cache
by jorge.perez.burgos＠ericsson.com 23 May '11

23 May '11

Hello Quanah, Our slapd uses back-meta to communicate to other slapds. We have to fulfill some requirements related with bandwith with network latencies and packet loss between slapds, to fulfill such requirements we need to increase these threads. Best Regards -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: viernes, 20 de mayo de 2011 19:01 To: Jorge Perez Burgos; openldap-its(a)openldap.org Subject: Re: (ITS#6944) Add option to limit or remove operation list cache --On May 19, 2011 8:03:00 AM +0000 jorge.perez.burgos(a)ericsson.com wrote: > Full_Name: Jorge Perez Burgos > Version: 2.4.21 > OS: SLES 10 SP3 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.235.15.243) > > > Our slapd uses 256 threads Why do you have 256 thread set? Do you have a 64-core box? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs