Re: (ITS#5343) cn=config crash when deleting attrs
by rhafer＠suse.de
On Donnerstag, 31. Januar 2008, rhafer(a)suse.de wrote:
> On Mittwoch, 30. Januar 2008, h.b.furuseth(a)usit.uio.no wrote:
> > Ralf Haferkamp writes:
> > > There are multiple ways to fix this, I guess. I am not sure which
> > > one to take:
> > > 1. Make slap_mods_opattrs() create a LDAP_MOD_ADD operation, when
> > > the attributes don't exist in the entry.
> >
> > It'd be better to fix bconfig's LDAP_MOD_REPLACE. That should work
> > like LDAP_MOD_ADD when the attribute is absent. Haven't looked at
> > how easy that would(n't) be though.
> >
> > > 2. Do not try to modify the attributes (not even add) in
> > > slap_mods_opattrs() if they do not exist.
> >
> > No idea...
> >
> > I like the consistency it gives as far as it goes - keep the
> > presence of the attrs independent of whether they were created over
> > the protocol or with slapd -f -F. Except fix #2 doesn't do that
> > since it won't know whether to add them when creating an entry. So
> > in summary, no opinion:-)
>
> I am currently testing the 3rd approach, the attributes will be
> created even when starting with -f only. I'll commit it as soon as
> make test finishes.
Done. Please test.
--
Ralf
15 years, 7 months
Re: (ITS#5341) Invalid TLSCipherSuite causes hang
by kyle＠moffetthome.net
On Jan 31, 2008 7:43 AM, Kyle Moffett <kyle(a)moffetthome.net> wrote:
> On Jan 31, 2008 12:29 AM, Kyle Moffett <kyle(a)moffetthome.net> wrote:
> > I ran into this problem a little while ago and scribbled up the
> > attached patch to fix it. It's trivial enough and it works in my
> > testing here.
>
> Sorry, the patch seems to have gone out MIME-encoded and mostly
> useless to people who want to download it from the bug-tracker. Let
> me try again... (Sorry, still getting used to a new email client)
Well damn, it still didn't work. Hopefully gmail won't mangle a
pasted patch. Again, my apologies for the mess.
Cheers,
Kyle Moffett
--- openldap-2.4.7/libraries/libldap/tls.c.orig 2007-12-21
19:24:08.000000000 -0500
+++ openldap-2.4.7/libraries/libldap/tls.c 2007-12-21 19:36:02.000000000 -0500
@@ -300,6 +300,7 @@
for (i=0; i<n_ciphers; i++) {
if ( !strncasecmp( ciphers[i].name, ptr, len )) {
num++;
+ ptr = end + 1;
break;
}
}
@@ -330,6 +331,7 @@
* only appear once in each list.
*/
if ( !strncasecmp( ciphers[i].name, ptr, len )) {
+ ptr = end + 1;
for (j=0; j<nkx; j++)
if ( kx[j] == ciphers[i].kx )
break;
15 years, 8 months
Re: (ITS#5341) Invalid TLSCipherSuite causes hang
by kyle＠moffetthome.net
------=_Part_21408_16591909.1201783413748
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Jan 31, 2008 12:29 AM, Kyle Moffett <kyle(a)moffetthome.net> wrote:
> I ran into this problem a little while ago and scribbled up the
> attached patch to fix it. It's trivial enough and it works in my
> testing here.
Sorry, the patch seems to have gone out MIME-encoded and mostly
useless to people who want to download it from the bug-tracker. Let
me try again... (Sorry, still getting used to a new email client)
Cheers,
Kyle Moffett
------=_Part_21408_16591909.1201783413748
Content-Type: text/plain; name=tls.patch.txt
Content-Transfer-Encoding: base64
X-Attachment-Id: f_fc3apr6s1
Content-Disposition: attachment; filename=tls.patch.txt
LS0tIG9wZW5sZGFwLTIuNC43L2xpYnJhcmllcy9saWJsZGFwL3Rscy5jLm9yaWcJMjAwNy0xMi0y
MSAxOToyNDowOC4wMDAwMDAwMDAgLTA1MDAKKysrIG9wZW5sZGFwLTIuNC43L2xpYnJhcmllcy9s
aWJsZGFwL3Rscy5jCTIwMDctMTItMjEgMTk6MzY6MDIuMDAwMDAwMDAwIC0wNTAwCkBAIC0zMDAs
NiArMzAwLDcgQEAKIAkJZm9yIChpPTA7IGk8bl9jaXBoZXJzOyBpKyspIHsKIAkJCWlmICggIXN0
cm5jYXNlY21wKCBjaXBoZXJzW2ldLm5hbWUsIHB0ciwgbGVuICkpIHsKIAkJCQludW0rKzsKKwkJ
CQlwdHIgPSBlbmQgKyAxOwogCQkJCWJyZWFrOwogCQkJfQogCQl9CkBAIC0zMzAsNiArMzMxLDcg
QEAKIAkJCSAqIG9ubHkgYXBwZWFyIG9uY2UgaW4gZWFjaCBsaXN0LgogCQkJICovCiAJCQlpZiAo
ICFzdHJuY2FzZWNtcCggY2lwaGVyc1tpXS5uYW1lLCBwdHIsIGxlbiApKSB7CisJCQkJcHRyID0g
ZW5kICsgMTsKIAkJCQlmb3IgKGo9MDsgajxua3g7IGorKykKIAkJCQkJaWYgKCBreFtqXSA9PSBj
aXBoZXJzW2ldLmt4ICkKIAkJCQkJCWJyZWFrOwo=
------=_Part_21408_16591909.1201783413748--
15 years, 8 months
Re: (ITS#5343) cn=config crash when deleting attrs
by rhafer＠suse.de
On Mittwoch, 30. Januar 2008, h.b.furuseth(a)usit.uio.no wrote:
> Ralf Haferkamp writes:
> > There are multiple ways to fix this, I guess. I am not sure which
> > one to take:
> > 1. Make slap_mods_opattrs() create a LDAP_MOD_ADD operation, when
> > the attributes don't exist in the entry.
>
> It'd be better to fix bconfig's LDAP_MOD_REPLACE. That should work
> like LDAP_MOD_ADD when the attribute is absent. Haven't looked at
> how easy that would(n't) be though.
>
> > 2. Do not try to modify the attributes (not even add) in
> > slap_mods_opattrs() if they do not exist.
>
> No idea...
>
> I like the consistency it gives as far as it goes - keep the presence
> of the attrs independent of whether they were created over the
> protocol or with slapd -f -F. Except fix #2 doesn't do that since it
> won't know whether to add them when creating an entry. So in
> summary, no opinion:-)
I am currently testing the 3rd approach, the attributes will be created
even when starting with -f only. I'll commit it as soon as make test
finishes.
> > 3. Create the opattrs, when reading from slapd.conf
>
> Doesn't help preexisting cn=config directories.
They didn't have the problem. The opattr were only absent, when slapd is
started with -f. When started with -f -F the attrs were created during
the conversion to back-config. They were at least present on disk.
--
Ralf
15 years, 8 months
Re: (ITS#5341) Invalid TLSCipherSuite causes hang
by kyle＠moffetthome.net
------=_Part_20332_23395431.1201757372670
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
I ran into this problem a little while ago and scribbled up the
attached patch to fix it. It's trivial enough and it works in my
testing here.
Cheers,
Kyle Moffett
------=_Part_20332_23395431.1201757372670
Content-Type: application/octet-stream; name=tls.patch
Content-Transfer-Encoding: base64
X-Attachment-Id: f_fc2v9vtn0
Content-Disposition: attachment; filename=tls.patch
LS0tIG9wZW5sZGFwLTIuNC43L2xpYnJhcmllcy9saWJsZGFwL3Rscy5jLm9yaWcJMjAwNy0xMi0y
MSAxOToyNDowOC4wMDAwMDAwMDAgLTA1MDAKKysrIG9wZW5sZGFwLTIuNC43L2xpYnJhcmllcy9s
aWJsZGFwL3Rscy5jCTIwMDctMTItMjEgMTk6MzY6MDIuMDAwMDAwMDAwIC0wNTAwCkBAIC0zMDAs
NiArMzAwLDcgQEAKIAkJZm9yIChpPTA7IGk8bl9jaXBoZXJzOyBpKyspIHsKIAkJCWlmICggIXN0
cm5jYXNlY21wKCBjaXBoZXJzW2ldLm5hbWUsIHB0ciwgbGVuICkpIHsKIAkJCQludW0rKzsKKwkJ
CQlwdHIgPSBlbmQgKyAxOwogCQkJCWJyZWFrOwogCQkJfQogCQl9CkBAIC0zMzAsNiArMzMxLDcg
QEAKIAkJCSAqIG9ubHkgYXBwZWFyIG9uY2UgaW4gZWFjaCBsaXN0LgogCQkJICovCiAJCQlpZiAo
ICFzdHJuY2FzZWNtcCggY2lwaGVyc1tpXS5uYW1lLCBwdHIsIGxlbiApKSB7CisJCQkJcHRyID0g
ZW5kICsgMTsKIAkJCQlmb3IgKGo9MDsgajxua3g7IGorKykKIAkJCQkJaWYgKCBreFtqXSA9PSBj
aXBoZXJzW2ldLmt4ICkKIAkJCQkJCWJyZWFrOwo=
------=_Part_20332_23395431.1201757372670--
15 years, 8 months
Re: (ITS#5343) cn=config crash when deleting attrs
by h.b.furuseth＠usit.uio.no
Ralf Haferkamp writes:
> There are multiple ways to fix this, I guess. I am not sure which one
> to take:
> 1. Make slap_mods_opattrs() create a LDAP_MOD_ADD operation, when the
> attributes don't exist in the entry.
It'd be better to fix bconfig's LDAP_MOD_REPLACE. That should work
like LDAP_MOD_ADD when the attribute is absent. Haven't looked at
how easy that would(n't) be though.
> 2. Do not try to modify the attributes (not even add) in
> slap_mods_opattrs() if they do not exist.
No idea...
I like the consistency it gives as far as it goes - keep the presence of
the attrs independent of whether they were created over the protocol or
with slapd -f -F. Except fix #2 doesn't do that since it won't know
whether to add them when creating an entry. So in summary, no opinion:-)
> 3. Create the opattrs, when reading from slapd.conf
Doesn't help preexisting cn=config directories.
--
Hallvard
15 years, 8 months
Re: (ITS#5343) cn=config crash when deleting attrs
by rhafer＠suse.de
On Mittwoch, 30. Januar 2008, h.b.furuseth(a)usit.uio.no wrote:
> Ralf Haferkamp writes:
> > This should be fixed in HEAD now.
>
> Yes. Instead test034-translucent fails:
> >>>>> Starting test034-translucent ...
>
> ...
> Dynamically configuring local slapd without translucent_no_glue...
> ldap_modify: No such attribute (16)
> additional info: modify/delete: entryCSN: no such attribute
> modifying entry
> "olcOverlay={0}translucent,olcDatabase={2}bdb,cn=config"
>
> ldapmodify of dynamic config failed (16)
>
> >>>>> scripts/test034-translucent with bdb failed (exit 1)
Hm, the config entries do not contain the usual operational Attributes
like entrycsn, modifytimestamp, and so on when the config was loaded
from slapd.conf, but during modification slapd tries to update them
using slap_mods_opattrs(). This function always creates a
LDAP_MOD_REPLACE modifcation, even if the attributes do not exist in
the original entry.
There are multiple ways to fix this, I guess. I am not sure which one to
take:
1. Make slap_mods_opattrs() create a LDAP_MOD_ADD operation, when the
attributes don't exist in the entry.
2. Do not try to modify the attributes (not even add) in
slap_mods_opattrs() if they do not exist.
3. Create the opattrs, when reading from slapd.conf
4. Fix the original Bug differently. Even though I am pretty sure that
my fix is correct.
5. ?
Any suggestions?
--
Ralf
15 years, 8 months
Re: (ITS#5342) DN and naming attribute mismatch
by richton＠nbcs.rutgers.edu
> Have you got any servers running 2.3.39, or all 2.3.37?
Everything went from 2.3.37 -> 2.3.40. Since I get hosed w/err=80,
the slaves don't have corrupt data. I'm thinking about moving the master
down to 2.3.39 as a data point.
In the meantime, thanks for the db_dump idea; I can now show that the bad
commits are definitely (a) 2.3.40 and (b) increasing. Consider:
# grep 172.23.93.232 dbdump*
dbdump.Jan291845: \80\10cn=172.23.93.232\00cn=172.23.93.232\00\00\00\00\00\00\01\d3\8d
dbdump.Jan291845: \00\10cn=172.23.93.232\00cn=172.23.93.232\00\00\00\00\00\00\00\01>
dbdump.Jan301043: \80\10cn=172.23.93.232\00cn=1\b72.23.93.232\00\00\00\00\00\00\01\d3\8d
dbdump.Jan301043: \00\10cn=172.23.93.232\00cn=172.23.93.232\00\00\00\00\00\00\00\01>
15 years, 8 months
Re: (ITS#5342) DN and naming attribute mismatch
by hyc＠symas.com
Aaron Richton wrote:
>> after it. ("Last" is obviously imprecise. But the point is you would have had
>> to have created some new entries after the upgrade whose DNs would cause
>> their records to fall on the same DB page as this record, meaning they're
>> close in the sort order and such.)
>
> As for "close pagewise," there's a lot of churn here since it's the
> beginning of the semester. It's not uncommon to see the same DN DEL/ADD
> within ~30-60 minutes.
>
>> And for most err=80 situations, there ought to be BerkeleyDB error messages
>> in the log as well.
>
> Agreed. On that end, I pulled out two weeks of logs overnight, and grep
> for "bdb(" found precisely zero hits.
>
>
> While I had the logs out, I looked back, and it turns out the first time I
> ever saw a problem with 2.3.40 actually WASN'T err=80:
>
> Jan 24 19:03:31 op=4 DEL dn="cn=172.23.132.58,cn..."
> Jan 24 19:03:31 conn=3252 op=4 RESULT tag=107 err=32 text=
>
>
>
> This was added under 2.3.37:
>
> Jan 22 18:33:28 op=4 ADD dn="cn=172.23.132.58,cn=..."
>
> Now of course you can blame stuff between Jan 22-24 as moving that entry.
> But I've got nightly slapcat's showing:
>
> dn: cn=172.23.132.58,cn=Clients,cn=ResNet Service Config,ou=Host Config,o=Rutg
> entryCSN: 20080122233328Z#000004#00#000000
>
> As a matter of fact, I can even run that right this second.
>
> # date;slapcat -b "o=Rutgers CCF,c=US" | /usr/sfw/bin/ggrep -A12 cn=172.23.132.58 | egrep '^cn|^entryCSN'
> Wed Jan 30 09:29:03 EST 2008
> cn: 172.23.132.58
> entryCSN: 20080122233328Z#000004#00#000000
>
> So notfound is.....dubious. (And no, I'm not manually tweaking it, and I
> don't even know how to spell managedSAit. ;) That's the first time I saw
> 2.3.40 go weird.
Well, one of the big patches in 2.3.40 (relative to 2.3.39) was a fix for some
caching bugs which showed up if an entry was being deleted and added in rapid
succession, and being searched for. In that case, it was possible for the old
dn2id value to be read back into the cache from disk before it got deleted off
the disk. So it's conceivable that this patch caused your err=32 problem
somehow. But nothing explains the errant bit getting set in the DN.
Have you got any servers running 2.3.39, or all 2.3.37?
--
-- 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/
15 years, 8 months
Re: (ITS#5343) cn=config crash when deleting attrs
by h.b.furuseth＠usit.uio.no
Ralf Haferkamp writes:
> This should be fixed in HEAD now.
Yes. Instead test034-translucent fails:
>>>>> Starting test034-translucent ...
...
Dynamically configuring local slapd without translucent_no_glue...
ldap_modify: No such attribute (16)
additional info: modify/delete: entryCSN: no such attribute
modifying entry "olcOverlay={0}translucent,olcDatabase={2}bdb,cn=config"
ldapmodify of dynamic config failed (16)
>>>>> scripts/test034-translucent with bdb failed (exit 1)
--
Hallvard
15 years, 8 months
