Re: (ITS#5342) DN and naming attribute mismatch
by richton＠nbcs.rutgers.edu
> 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.
15 years, 10 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:
[..]
>
> back-config crashes if I delete some attribute, even some which
> does not exist, and then olcAttributeOptions:
>
> bash$ cat slapd.conf
> include servers/slapd/schema/core.schema
> database config
> rootdn cn=config
> rootpw secret
>
> bash$ ldapmodify -xh:3890 -Dcn=config -wsecret
> dn: cn=config
> changetype: modify
> # or use "delete: o"
> delete: olcAllows
> -
> delete: olcAttributeOptions
> olcAttributeOptions: foo
> -
>
> Crash in bconfig.c:config_modify_internal line 4843 because d ==
> NULL: 4842 if ( ml->sml_values ) {
> 4843 d = d->next;
> 4844 ch_free( dels );
> 4845 dels = d;
> 4846 }
[..]
This should be fixed in HEAD now. The code did not check the return code
of modify_delete_vindex() for failures.
> Also the error message from deleting just olcAttributeOptions is bad:
>
> bash$ ldapmodify -xh:3890 -Dcn=config -wsecret
> dn: cn=config
> changetype: modify
> replace: olcAttributeOptions
> olcAttributeOptions: foo
>
> ldap_modify: Internal (implementation specific) error (80)
> additional info: modify/delete: modifyTimestamp: no such attribute
> modifying entry "cn=config"
>
> Finally "replace:" only needs to fail if there are options to delete,
> not if one adds a line with just "attributeOptions" to slapd.conf.
> That removes the default, "lang-".
Haven't looked into this yet.
--
Ralf
15 years, 10 months
Re: (ITS#5344) Wrong check for bad Modify DN
by h.b.furuseth＠usit.uio.no
hyc(a)symas.com writes:
> Probably should look at adding the dest_dn to the op struct, so each
> backend doesn't have to rebuild it.
Third-party overlays which modify newrdn or newSuperior would become
incorrect, so maybe this change should wait for OpenLDAP 2.5.
--
Hallvard
15 years, 10 months
Re: (ITS#5344) Wrong check for bad Modify DN
by h.b.furuseth＠usit.uio.no
hyc(a)symas.com writes:
>> The slapd/modrdn.c check for affectsMultipleDSAs is insufficient, it
>> requires newSuperior to be in the same backend. That does not catch
>> moving "cn=x,cn=y" to another database's suffix "cn=z,cn=y".
>
> I don't see how it can miss this.
It checks if newSuperior is in another backend, but that move doesn't
need a newSuperior. It keeps the same parent:
database 1: suffix cn=y
database 2: suffix cn=z,cn=y
modify rdn: dn "cn=x,cn=y"; newrdn cn=z; newSuperior (if any) cn=y.
> Probably should look at adding the dest_dn to the op struct, so each
> backend doesn't have to rebuild it.
Indeed. And dest_ndn.
--
Hallvard
15 years, 10 months
Re: (ITS#5344) Wrong check for bad Modify DN
by hyc＠symas.com
h.b.furuseth(a)usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: HEAD
> OS:
> URL: http://folk.uio.no/hbf/OpenLDAP/modrdn.diff
> Submission from: (NULL) (129.240.6.233)
> Submitted by: hallvard
>
>
> The slapd/modrdn.c check for affectsMultipleDSAs is insufficient, it
> requires newSuperior to be in the same backend. That does not catch
> moving "cn=x,cn=y" to another database's suffix "cn=z,cn=y".
I don't see how it can miss this.
> Also
> if a database has multiple suffixes it prevents moving an entry
> to one of the suffixes.
OK, I see that.
> slapd/modrdn.c can catch attempts to place an entry above/below itself.
> It doesn't need to send those to the database and hope that catches it.
> This patch puts it in the frontend (fe_op_modrdn); that needed to
> generate the destination DN anyway for the affectsMultipleDSAs check.
> Not sure if that's right or if it should go in do_modrdn() instead.
> (I'm thinking of DN rewriting in rwm, vs. global overlays.)
Probably should look at adding the dest_dn to the op struct, so each backend
doesn't have to rebuild it.
> In test005-modrdn, the "modrdn with newSuperior as child of target" check
> would not catch anything: It expects failure, but the newSuperior did
> not exist and would fail with noSuchObject in any case. This patch uses
> newSuperior=target instead, and expects unwillingToPerform.
> I'll apply the patch later, unless someone thinks it should be done
> differently.
--
-- 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, 10 months
(ITS#5344) Wrong check for bad Modify DN
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: HEAD
OS:
URL: http://folk.uio.no/hbf/OpenLDAP/modrdn.diff
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
The slapd/modrdn.c check for affectsMultipleDSAs is insufficient, it
requires newSuperior to be in the same backend. That does not catch
moving "cn=x,cn=y" to another database's suffix "cn=z,cn=y". Also
if a database has multiple suffixes it prevents moving an entry
to one of the suffixes.
slapd/modrdn.c can catch attempts to place an entry above/below itself.
It doesn't need to send those to the database and hope that catches it.
This patch puts it in the frontend (fe_op_modrdn); that needed to
generate the destination DN anyway for the affectsMultipleDSAs check.
Not sure if that's right or if it should go in do_modrdn() instead.
(I'm thinking of DN rewriting in rwm, vs. global overlays.)
In test005-modrdn, the "modrdn with newSuperior as child of target" check
would not catch anything: It expects failure, but the newSuperior did
not exist and would fail with noSuchObject in any case. This patch uses
newSuperior=target instead, and expects unwillingToPerform.
I'll apply the patch later, unless someone thinks it should be done
differently.
15 years, 10 months
Re: (ITS#5330) back-null upgrade
by h.b.furuseth＠usit.uio.no
hyc(a)symas.com writes:
> h.b.furuseth(a)usit.uio.no wrote:
>> I'll be upgrading back-null a bit. At the moment just support for
>> Back-config, Modify-Increment Extension and empty rootpw.
>
>> Maybe grow it to a useful template of a nontrivial backend later
>> (after I learn how to write that), with access control, referrals,
>> various extensions... Might be almost-unused and thus subject to
>> code rot, but less so than documentation of the backend API.
>> (...)
>
> I don't believe back-null should ever handle access controls or
> referrals.
OK. However it shouldn't need to _handle_ referrals, since it can have
no referral objects. I think the complete implementation would be to
set SLAP_BFLAG_REFERRALS and LDAP_CONTROL_MANAGEDSAIT in the init
function. Assuming the default_referral code in BDB which neither of us
understand (ITS#5339) is unnecessary.
SLAP_BFLAG_INCREMENT and (I think) LDAP_CONTROL_X_PERMISSIVE_MODIFY can
be set without needing any extra code, and LDAP_CONTROL_NOOP will need
one line for the update functions.
> It shouldn't have any config options at all, really.
Does that mean I shouldn't add back-config support either?
I do find "bind on" useful. And it would be convenient to accept and
ignore the "directory" option, so it can be used as a drop-in
replacement for a minimal back-bdb/back-ldif config.
My current motivation is nothing major, just to push back-null through
"cd tests/ && ./run -b null all".
> Create some other backend if you want a dummy template that shows how
> all the other APIs are tied in.
OK. Just need to think of something for it to do...
--
Hallvard
15 years, 10 months
(ITS#5343) cn=config crash when deleting attrs
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (129.240.203.232)
Submitted by: hallvard
back-config crashes if I delete some attribute, even some which
does not exist, and then olcAttributeOptions:
bash$ cat slapd.conf
include servers/slapd/schema/core.schema
database config
rootdn cn=config
rootpw secret
bash$ ldapmodify -xh:3890 -Dcn=config -wsecret
dn: cn=config
changetype: modify
# or use "delete: o"
delete: olcAllows
-
delete: olcAttributeOptions
olcAttributeOptions: foo
-
Crash in bconfig.c:config_modify_internal line 4843 because d == NULL:
4842 if ( ml->sml_values ) {
4843 d = d->next;
4844 ch_free( dels );
4845 dels = d;
4846 }
Backtrace:
#0 0x000000000042db19 in config_modify_internal (ce=0x9cb710, op=0x9d7330,
rs=0x41801cb0, ca=0x417ff750) at bconfig.c:4843
#1 0x000000000042e34a in config_back_modify (op=0x9d7330, rs=0x41801cb0)
at bconfig.c:4991
#2 0x0000000000461107 in fe_op_modify (op=0x9d7330, rs=0x41801cb0)
at modify.c:300
#3 0x00000000004609b0 in do_modify (op=0x9d7330, rs=0x41801cb0)
at modify.c:175
#4 0x0000000000440dd8 in connection_operation (ctx=0x41801e00, arg_v=0x9d7330)
at connection.c:1087
#5 0x0000000000441306 in connection_read_thread (ctx=0x41801e00, argv=0x9)
at connection.c:1214
#6 0x00002b100d4c354f in ldap_int_thread_pool_wrapper (xpool=0x927a10)
at tpool.c:625
#7 0x00002b100e1e6317 in start_thread () from /lib/libpthread.so.0
#8 0x00002b100f935d5d in clone () from /lib/libc.so.6
#9 0x0000000000000000 in ?? ()
Also the error message from deleting just olcAttributeOptions is bad:
bash$ ldapmodify -xh:3890 -Dcn=config -wsecret
dn: cn=config
changetype: modify
replace: olcAttributeOptions
olcAttributeOptions: foo
ldap_modify: Internal (implementation specific) error (80)
additional info: modify/delete: modifyTimestamp: no such attribute
modifying entry "cn=config"
Finally "replace:" only needs to fail if there are options to delete,
not if one adds a line with just "attributeOptions" to slapd.conf.
That removes the default, "lang-".
15 years, 10 months
Re: (ITS#5342) DN and naming attribute mismatch
by hyc＠symas.com
Aaron Richton wrote:
> Backend is hdb. The add was done under 2.3.37, the server has since been
> upgraded to 2.3.40 (last Thursday).
>
> db_dump -p does show a high character...
>
> \80\10cn=172.23.58.210\00cn=1\b72.23.58.210\00\00\00\00\00\00\01\e4e
>
> which I suppose you're theorizing is off-by-one on the disk. BTW, slapcat
> doesn't agree with ldapsearch here, which might be construed as a bug?
> (Although it's tough to call something a bug in an impossible situation, I
> admit.)
> I dunno. I suppose if the hardware is bad then I might be seeing all sorts
> of crazy stuff. But we're talking modern sparc/solaris hardware: all my
> other boxes are pretty good about screaming during their death. And they
> also don't have the amazingly-coincidental upgrade to 2.3.40 from last
> Thursday, either. (Which I started seeing err=80 returns within 24 hours
> of, after not seeing them...well, almost ever in production.) It's all
> just a bit too perfect a storm for my taste...but I'd obviously defer to
> you when it comes to bdb internals.
Well, if the entry was created a while ago and hasn't ever been modrdn'd then
this DB record would never have been touched since then. (Or more to the
point, not modrdn'd since the 2.3.40 upgrade.) It's possible that a software
bug might have caused a stray bitwise OR to toggle that bit in an in-memory
cached page, but seems unlikely that a page corrupted in that manner would
have been written back to disk. Unless of course this record is one of the
last ones in the DB before the upgrade, and new entries were added right 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.)
> With that in mind, I might as well see through your theory. I'll play with
> a second box tomorrow and see if I can reproduce fresh.
And for most err=80 situations, there ought to be BerkeleyDB error messages in
the log as well.
--
-- 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, 10 months
Re: (ITS#5342) DN and naming attribute mismatch
by richton＠nbcs.rutgers.edu
Backend is hdb. The add was done under 2.3.37, the server has since been
upgraded to 2.3.40 (last Thursday).
db_dump -p does show a high character...
\80\10cn=172.23.58.210\00cn=1\b72.23.58.210\00\00\00\00\00\00\01\e4e
which I suppose you're theorizing is off-by-one on the disk. BTW, slapcat
doesn't agree with ldapsearch here, which might be construed as a bug?
(Although it's tough to call something a bug in an impossible situation, I
admit.)
I dunno. I suppose if the hardware is bad then I might be seeing all sorts
of crazy stuff. But we're talking modern sparc/solaris hardware: all my
other boxes are pretty good about screaming during their death. And they
also don't have the amazingly-coincidental upgrade to 2.3.40 from last
Thursday, either. (Which I started seeing err=80 returns within 24 hours
of, after not seeing them...well, almost ever in production.) It's all
just a bit too perfect a storm for my taste...but I'd obviously defer to
you when it comes to bdb internals.
With that in mind, I might as well see through your theory. I'll play with
a second box tomorrow and see if I can reproduce fresh.
15 years, 10 months