Re: (ITS#5521) Can't change indexing of an attribute within a single modification
by rhafer＠suse.de
On Sonntag, 25. Mai 2008, Pierangelo Masarati wrote:
> rhafer(a)suse.de wrote:
> > The following modification to add an additional index an attribute
> > fails with the error messages pasted below:
> >
> > --------------------------
> > dn: olcDatabase={1}bdb,cn=config
> > changetype: modify
> > delete: olcdbindex
> > olcDbIndex: cn pres,eq
> > -
> > add: olcdbindex
> > olcDbIndex: cn pres,eq,sub
> > --------------------------
> >
> > modifying entry "olcDatabase={1}bdb,cn=config"
> > ldap_modify: Other (e.g., implementation specific) error (80)
> > additional info: <olcDbIndex> handler exited with 1
> >
> > As far as I can see it fails because the old indexmask hat not yet
> > been deleted from the bdb-struct. The ainfo_insert()-call in
> > back-bdb/attr.c(bdb_attr_index_config()) returns with -1.
> >
> > Splitting the above modification in two separate operations works
> > around that problem.
>
> What about using replace instead?
That causes the same behavior as the modification pasted above. So it
doesn't work as well.
--
Ralf
15 years
Re: (ITS#5524) Additions to the Security section of the Admin Guide
by ghenry＠OpenLDAP.org
andrew.findlay(a)skills-1st.co.uk wrote:
> Full_Name: Andrew Findlay
> Version: 2.4.9
> OS: Linux
> URL: http://www.skills-1st.co.uk/pub/code/openldap-guide-patch-20080522
> Submission from: (NULL) (88.97.25.132)
>
>
> This patch adds text to the Security chapter in the Admin Guide. It describes
> the password storage schemes, including the {SASL} scheme that triggers
> pass-through authentication. The latter facility has existed since version 2.0
> but has never been mentioned in the docs, so I have included a section with an
> example of its use.
>
>
I've patched security.sdf and I'm abotu to clean up some typos and
formating.
Should we also mention that CRYPT is platform specific?
Lastly, should I also put:
Portions Copyright 2008 Andrew Findlay <andrew.findlay(a)skills-1st.co.uk>
into doc/guide/COPYRIGHT ?
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
15 years
Re: (ITS#5244) Problem configuring openldap 2.4.6
by h.b.furuseth＠usit.uio.no
pierre42d(a)9online.fr writes:
> Ok i agree it's an enhancement request rather than a bug. I know this
> environment variables, but my point of view is that /usr/local should
> be considered part of default/standard system locations.
I don't think we should suddenly mess with these defaults now,
but there could be an option to add them to CPPFLAGS and LDFLAGS.
Or rather, add $includedir (default /usr/local/include) and $libdir
(default /usr/local/lib).
--
Hallvard
15 years
(ITS#5528) Problem compiling openldap 2.4.9
by pierre42d＠9online.fr
Full_Name: Pierre
Version: 2.4.9
OS: GNU/Linux
URL:
Submission from: (NULL) (79.82.49.83)
# make
Making all in /tmp/openldap-2.4.9
Entering subdirectory include
make[1]: Entering directory `/tmp/openldap-2.4.9/include'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/tmp/openldap-2.4.9/include'
Entering subdirectory libraries
make[1]: Entering directory `/tmp/openldap-2.4.9/libraries'
Making all in /tmp/openldap-2.4.9/libraries
Entering subdirectory liblutil
make[2]: Entering directory `/tmp/openldap-2.4.9/libraries/liblutil'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/tmp/openldap-2.4.9/libraries/liblutil'
Entering subdirectory liblber
make[2]: Entering directory `/tmp/openldap-2.4.9/libraries/liblber'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/tmp/openldap-2.4.9/libraries/liblber'
Entering subdirectory liblunicode
make[2]: Entering directory `/tmp/openldap-2.4.9/libraries/liblunicode'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/tmp/openldap-2.4.9/libraries/liblunicode'
Entering subdirectory libldap
make[2]: Entering directory `/tmp/openldap-2.4.9/libraries/libldap'
/bin/sh ../..//libtool --mode=link gcc -s -O3 -march=i686
-L/usr/local/BerkeleyDB.4.6/lib -o apitest apitest.o libldap.la
../../libraries/liblber/liblber.la ../../libraries/liblutil/liblutil.a -lsasl2
-lgnutls -lcrypt -lresolv
gcc -s -O3 -march=i686 -o .libs/apitest apitest.o
-L/usr/local/BerkeleyDB.4.6/lib ./.libs/libldap.so
/tmp/openldap-2.4.9/libraries/liblber/.libs/liblber.so -L/usr/local/lib
../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a
/usr/local/lib/libsasl2.so -ldl /usr/local/lib/libgnutls.so
/usr/local/lib/libtasn1.so /usr/local/lib/libgcrypt.so -lnsl -lcap
/usr/local/lib/libgpg-error.so -lz -lcrypt -lresolv
./.libs/libldap.so: undefined reference to `gnutls_cipher_suite_info'
collect2: ld returned 1 exit status
make[2]: *** [apitest] Error 1
make[2]: Leaving directory `/tmp/openldap-2.4.9/libraries/libldap'
make[1]: *** [all-common] Error 1
make[1]: Leaving directory `/tmp/openldap-2.4.9/libraries'
make: *** [all-common] Error 1
15 years
Re: (ITS#5244) Problem configuring openldap 2.4.6
by pierre42d＠9online.fr
Ok i agree it's an enhancement request rather than a bug.
I know this environment variables, but my point of view is that
/usr/local should be considered part of default/standard system locations.
Regards,
15 years
Re: (ITS#5521) Can't change indexing of an attribute within a single modification
by ando＠sys-net.it
rhafer(a)suse.de wrote:
> The following modification to add an additional index an attribute fails with
> the error messages pasted below:
>
> --------------------------
> dn: olcDatabase={1}bdb,cn=config
> changetype: modify
> delete: olcdbindex
> olcDbIndex: cn pres,eq
> -
> add: olcdbindex
> olcDbIndex: cn pres,eq,sub
> --------------------------
>
> modifying entry "olcDatabase={1}bdb,cn=config"
> ldap_modify: Other (e.g., implementation specific) error (80)
> additional info: <olcDbIndex> handler exited with 1
>
> As far as I can see it fails because the old indexmask hat not yet been deleted
> from the bdb-struct. The ainfo_insert()-call in
> back-bdb/attr.c(bdb_attr_index_config()) returns with -1.
>
> Splitting the above modification in two separate operations works around that
> problem.
What about using replace instead?
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years
Re: (ITS#5517) add superclass of existing class fails
by ando＠sys-net.it
Kurt Zeilenga wrote:
>
> On May 24, 2008, at 2:18 AM, ando(a)sys-net.it wrote:
>
>> I believe the actual implementation should be... implementation
>> dependent :), provided it is consistent.
>
> I agree there is a slight inconsistency.
>
> A client can delete a listed superclass but not add an superclass of a
> listed attribute.
>
> One could argue that both be considered invalid operations. However, it
> would be reasonable to consider an add of an unlisted superclass and a
> delete of a listed superclass to be valid. However, a add of an already
> listed class should be invalid and a delete of a unlisted class should
> always be invalid.
Agreed. With respect to the current implementation, we're back to
square one, since the issue is related to using objectSubClassMatch() to
check for the presence of a value. Any superclass is returned as
present no matter if it is actually present or just implied. From your
answers, it seems that treating objectClass specially should be the
solution, and the fix I'm proposing goes in this direction. Should I
commit it, or does anyone see any side effect?
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years
Re: (ITS#5517) add superclass of existing class fails
by Kurt＠OpenLDAP.org
On May 24, 2008, at 2:18 AM, ando(a)sys-net.it wrote:
> I believe the actual implementation should be... implementation
> dependent :), provided it is consistent.
I agree there is a slight inconsistency.
A client can delete a listed superclass but not add an superclass of a
listed attribute.
One could argue that both be considered invalid operations. However,
it would be reasonable to consider an add of an unlisted superclass
and a delete of a listed superclass to be valid. However, a add of an
already listed class should be invalid and a delete of a unlisted
class should always be invalid.
-- Kurt
15 years
Re: (ITS#5517) add superclass of existing class fails
by Kurt＠OpenLDAP.org
On May 24, 2008, at 2:37 PM, h.b.furuseth(a)usit.uio.no wrote:
> ando(a)sys-net.it writes:
>> The issue right now is caused by the fact that comparing present
>> values with the asserted one causes objectSubClassMatch() to check
>> for
>> match including superiors.
>
> This looks like a bug to me.
Maybe in the RFCs.
> objectClass has EQUALITY matching rule
> objectIdentifierMatch, which does not follow the object class
> inheritance chain.
Yes, but objectClass is quite special (despite being a
userApplications attribute).
For instance, (objectClass=*) is to match DSEs which don't have an
objectClass attribute.
Likewise, objectClass=foo can match objectClass attributes which don't
explicitly contain foo.
> See RFC 4517 section 4.2.26. RFC 4512 section 3.3
> (the 'objectClass' attribute) does not special-case this.
>
> What makes slapd work is that it also disobeys RFC 4512 section 3.3:
> "When creating an entry or adding an 'objectClass' value to an
> entry,
> all superclasses of the named classes SHALL be implicitly added as
> well if not already present."
> This doesn't say the classes shall be considered to be implicitly
> present, like slapd does.
You are reading 3.3 as if it said "SHALL be added (by the server)".
It doesn't say "SHALL be added (by the server). It says "SHALL be
implicitly added" (presumedly by the server).
This was discussed during LDAPbis discussions. As the Editor of RFC
4512, I can say that it was my intent to allow servers to merely treat
superclasses as being present.
> Instead slapd should add the missing classes to the actual object,
Doing so is problematic. A client which adds B then deletes B would
be surprised by non-net-zero result of the operation(s).
> just like it adds some other attribute/values
> implicitly (createTimestamp, subschemaSubentry, etc).
These are operational attributes. ObjectClass is an userApplications
attribute. Servers should not muck with the values of userApplication
attributes.
> I don't know what to do about it now though. Will replication work
> between current servers and servers which obeys the RFCs? Is this a
> RE25
> fix, so we should stay with fixed like previously suggested in
> RE24? Or
> yet another thing to do with the last RE23, for the sake of
> replication?
>
> --
> Hallvard
>
>
15 years
