malloc without check
by andreas moroder
Hello,
in servers/slapd/add.c int the function slap_entry2mods() malloc() is called
three times and the result is not checked against NULL.
Bye
Andreas
15 years, 2 months
collective attributes (the hard way)
by Brett ＠Google
Having worked on the simple / practical way of getting collective
attributes, my next task is to investigate and possibly fix ? the more
complex but ultimately more complete, collective attribute scheme, which is
used when you declare an object in the schema with COLLECTIVE (eg. in
collective.schema).
So far, i have worked out how to create a collective definition, but it has
no effect as i'm presuming *subtreeSpecification* is currently
unimplemented. Can somebody please check i have the below correct at least.
I have declared the following :
dn: cn=template1,o=openldap,c=AU
*objectClass: collectiveAttributeSubentry
objectClass: subentry
objectClass: top*
cn: template1
*subtreeSpecification: { base "ou=test1,o=openldap,c=AU" }*
createTimestamp: 20080906145020Z
creatorsName: cn=Manager,c=AU
entryCSN: 20080906145740.998417Z#000000#000#000000
entryDN: cn=template1,o=openldap,c=AU
entryUUID: df2317c6-106e-102d-82e5-ffce2194e1a8
hasSubordinates: FALSE
modifiersName: cn=Manager,c=AU
modifyTimestamp: 20080906145740Z
structuralObjectClass: subentry
subschemaSubentry: cn=Subschema
This appears to set up the collective attributes, and where they should
apply but has no effect. Presumably this is because c-PostalAddress and/or
c-PostalCode (as defined in collective.schema) are not present.
Well there are no suplimentary objectclases that allow these attributes, so
i tried adding the extensibleObject objectclass, and then added the
c-PostalCode and c-PostalAddress attributes. This gave me :
dn: cn=template1,o=openldap,c=AU
objectClass: collectiveAttributeSubentry
*objectClass: extensibleObject*
objectClass: subentry
objectClass: top
cn: template1
subtreeSpecification: { base "ou=test1,o=openldap,c=AU" }
*c-PostalAddress: 123 Someplace St
c-PostalCode: 9999*
createTimestamp: 20080906145020Z
creatorsName: cn=Manager,c=AU
entryCSN: 20080906145740.998417Z#000000#000#000000
entryDN: cn=template1,o=openldap,c=AU
entryUUID: df2317c6-106e-102d-82e5-ffce2194e1a8
hasSubordinates: FALSE
modifiersName: cn=Manager,c=AU
modifyTimestamp: 20080906145740Z
structuralObjectClass: subentry
subschemaSubentry: cn=Subschema
(Incidentally very impressed that Apache Directory Studio can handle the
above subschema stuff quite competently)
So although the configuration information is now present, i assume there is
nothing actually using or applying this data. If i understand the above
correctly, the intent is to apply the above values in c-PostalAddress and
c-PostalCode, to the matching attributes postalAddress and postalCode for
all entries under base "ou=test1,o=openldap,c=AU", with no exclusions
I'm thinking that it is a requirement to efficiently keep a list of objects
matching (objectClass=collectiveAttributeSubentry) and then applying the
specifications therein to search results. The existing collect overlay is a
simple demonstration overlay, which keeps only a simple static definition
which never changes, so does not implement collective attributes in the more
complex dynamic form.
To implement collective attributes fully (and as declared in
collective.schema) this meta data would need to be dynamic, but without the
overhead of continually searching for new things matching
(objectClass=collectiveAttributeSubentry) which would trash performance.
Any thoughts on how to go about implementing this ?
Cheers
Brett
15 years, 2 months
line numbers in openldap debugging
by Brett ＠Google
Is there any special magic to get source line numbers in gdb (bt or bt full) ?
I tried :
CFLAGS="-g -g3 -ggdb -ggdb3" --enable-slapd --enable-shared
--enable-overlays --disable-ipv6 --with-threads --enable-ssl
--enable-collect --enable-debug
The CFLAGS added the gdb options when compiling, but did not provide
any line numbers for openldap source when doing backtraces under gdb..
Cheers
Brett
15 years, 2 months
postalAddress matching rule
by Brett ＠Google
Hello,
I've just submitted a patch to help make the collect overlay
(attribute inheritance) a bit more useful (ITS#5659).
As part of my testing work for the above i once accidentally created a
postalAddress attribute with two values. When i tried to remove the
extra attribute value it failed, the error i got was something like
that there is no matching rule for postalAddress, which if there
really isn't then it's probably a reasonable thing for slapd to
complain about, as it wont be able to tell the individual values of
postalAddress apart.
So to put it in a nutshell, i'm willing to have a go implementing a
postalAddress matching rule, but i was wondering if anyone has any
thoughts where i might begin, and/or any pointers as to which file(s)
implement the matching rules.
Cheers
Brett
15 years, 2 months
