OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Development/6055
Full headers

From: abartlet@samba.org
Subject: Samba4 need 'name' implementation like AD (RDN-Name)
Compose comment
Download message
State:
0 replies:
26 followups: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Major security issue: yes  no

Notes:

Notification:


Date: Sun, 12 Apr 2009 07:42:57 +0000
From: abartlet@samba.org
To: openldap-its@OpenLDAP.org
Subject: Samba4 need 'name' implementation like AD (RDN-Name)
Full_Name: Andrew Bartlett
Version: CVS HEAD
OS: Fedora 10
URL: http://msdn.microsoft.com/en-us/library/cc223167(PROT.13).aspx
Submission from: (NULL) (59.167.251.137)


Active Directory always presents an attribute 'name' that is always equal to the
relative distinguished name.  AD allows only one RDN, but I don't mind if this
can be multi-valued for the multi-RDN case.  It is equal to the value of the RDN
as presented in the RDN.

This is not simply the subtype 'CN -> name', but a new attribute unrelated to
the existing definition of 'name'.

I don't care what name is assigned to 'name', as I can easily remap attributes.

It would be great if this could be constructed such that it may be declared to
be unique for a particular one-level search (also an AD requirement, but not one
Samba4 requires or enforces at this time).  

Andrew Bartlett

Followup 1

Download message
Date: Tue, 14 Apr 2009 10:09:19 +0200 (CEST)
From: Pierangelo Masarati <ando@sys-net.it>
To: abartlet@samba.org
Cc: openldap-its@openldap.org
Subject: Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
----- abartlet@samba.org wrote:

> Full_Name: Andrew Bartlett
> Version: CVS HEAD
> OS: Fedora 10
> URL: http://msdn.microsoft.com/en-us/library/cc223167(PROT.13).aspx
> Submission from: (NULL) (59.167.251.137)
> 
> 
> Active Directory always presents an attribute 'name' that is always
> equal to the
> relative distinguished name.  AD allows only one RDN, but I don't mind
> if this
> can be multi-valued for the multi-RDN case.  It is equal to the value
> of the RDN
> as presented in the RDN.
> 
> This is not simply the subtype 'CN -> name', but a new attribute
> unrelated to
> the existing definition of 'name'.
> 
> I don't care what name is assigned to 'name', as I can easily remap
> attributes.
> 
> It would be great if this could be constructed such that it may be
> declared to
> be unique for a particular one-level search (also an AD requirement,
> but not one
> Samba4 requires or enforces at this time).  

The only problem I see in defining such an attribute is that its syntax should
allow the value of any syntax, so it should probably be octetString or something
like that.  From the implementation point of view, what operations should it be
used for?  If you only need it to be returned with searches, and to be compared,
then the implementation would be trivial (it could be dynamically generated,
much like entryDN, as far as I can tell).  If you need to search for it, namely
use it in a filter, then it might be better to store it in the database.  This
would require to handle add and modrdn, forbid modify, and nothing else.

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
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------



Followup 2

Download message
Subject: Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
From: Andrew Bartlett <abartlet@samba.org>
To: Pierangelo Masarati <ando@sys-net.it>
Cc: openldap-its@openldap.org
Date: Tue, 14 Apr 2009 18:31:59 +1000
--=-z3vwQM0YDtLESpiQMoYR
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2009-04-14 at 10:09 +0200, Pierangelo Masarati wrote:
> ----- abartlet@samba.org wrote:
>=20
> > Full_Name: Andrew Bartlett
> > Version: CVS HEAD
> > OS: Fedora 10
> > URL: http://msdn.microsoft.com/en-us/library/cc223167(PROT.13).aspx
> > Submission from: (NULL) (59.167.251.137)
> >=20
> >=20
> > Active Directory always presents an attribute 'name' that is always
> > equal to the
> > relative distinguished name.  AD allows only one RDN, but I don't mind
> > if this
> > can be multi-valued for the multi-RDN case.  It is equal to the value
> > of the RDN
> > as presented in the RDN.
> >=20
> > This is not simply the subtype 'CN -> name', but a new attribute
> > unrelated to
> > the existing definition of 'name'.
> >=20
> > I don't care what name is assigned to 'name', as I can easily remap
> > attributes.
> >=20
> > It would be great if this could be constructed such that it may be
> > declared to
> > be unique for a particular one-level search (also an AD requirement,
> > but not one
> > Samba4 requires or enforces at this time). =20
>=20
> The only problem I see in defining such an attribute is that its
> syntax should allow the value of any syntax, so it should probably be
> octetString or something like that. =20

I think the AD document I reference explains that only some attributes
can be an RDN, so it limits them to those with a unicode string
representation I suppose.=20

There is another attribute that follows the 'type' of RDN btw (never
seen it used, but it's in the docs).=20

> From the implementation point of view, what operations should it be
> used for?  If you only need it to be returned with searches, and to be
> compared, then the implementation would be trivial (it could be
> dynamically generated, much like entryDN, as far as I can tell).  If
> you need to search for it, namely use it in a filter, then it might be
> better to store it in the database.  This would require to handle add
> and modrdn, forbid modify, and nothing else.

Like entryDN, we need to be able to search on it, so it should probably
be persistent.

Andrew Bartlett

--=20
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.

--=-z3vwQM0YDtLESpiQMoYR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQBJ5En/z4A8Wyi0NrsRAr6BAJ9TfUOgXqi25ArjKIXGVWDacL770gCgql6i
64vwlQj1AfncVVS2bCJlH5g=
=31Zg
-----END PGP SIGNATURE-----

--=-z3vwQM0YDtLESpiQMoYR--



Followup 3

Download message
Date: Tue, 14 Apr 2009 20:13:14 +0200
From: Pierangelo Masarati <ando@sys-net.it>
To: abartlet@samba.org
CC: openldap-its@openldap.org
Subject: Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
abartlet@samba.org wrote:

>> The only problem I see in defining such an attribute is that its
>> syntax should allow the value of any syntax, so it should probably be
>> octetString or something like that. =20
> 
> I think the AD document I reference explains that only some attributes
> can be an RDN, so it limits them to those with a unicode string
> representation I suppose.=20

OK, I coulnd't follow up to the document you cited.

> There is another attribute that follows the 'type' of RDN btw (never
> seen it used, but it's in the docs).=20
> 
>> From the implementation point of view, what operations should it be
>> used for?  If you only need it to be returned with searches, and to be
>> compared, then the implementation would be trivial (it could be
>> dynamically generated, much like entryDN, as far as I can tell).  If
>> you need to search for it, namely use it in a filter, then it might be
>> better to store it in the database.  This would require to handle add
>> and modrdn, forbid modify, and nothing else.
> 
> Like entryDN, we need to be able to search on it, so it should probably
> be persistent.

Ok.  Unlike entryDN, which is not persistent but evaluated on the fly 
based on dn2id indexes, unless we hardcode this in slapd (don't think 
so) we need to make the attr persistent.  It's on the todo list.

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
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------



Followup 4

Download message
Date: Sat, 18 Apr 2009 12:17:18 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: ando@sys-net.it
CC: openldap-its@openldap.org
Subject: Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
ando@sys-net.it wrote:
> ----- abartlet@samba.org wrote:
>> Active Directory always presents an attribute 'name' that is always
>> equal to the relative distinguished name.  AD allows only one RDN,
>> but I don't mind if this can be multi-valued for the multi-RDN
>> case.  It is equal to the value of the RDN as presented in the RDN.
>>
>> This is not simply the subtype 'CN -> name', but a new attribute 
>> unrelated to the existing definition of 'name'.
>>
>> I don't care what name is assigned to 'name', as I can easily remap
>> attributes.
>>
>> It would be great if this could be constructed such that it may be 
>> declared to be unique for a particular one-level search (also an AD
>> requirement, but not one Samba4 requires or enforces at this time).
> 
> The only problem I see in defining such an attribute is that its
> syntax should allow the value of any syntax, so it should probably be
> octetString or something like that.

Why? IMO such an attribute type could be declared like any other
attribute type. If its syntax does not match the syntax of the
characteristic attribute invalidAttributeSyntax should be returned.

I wonder what the exact requirements for the implementation within slapd
are and some very rough ideas as food for thought:

1. slapd shall enforce uniqueness on one-level
=> I'd vote for an additional feature of slapo-unique to define the
scope of uniqueness in a very flexible way

2. Value of 'name' has to match the value of the characteristic
attribute. Does this 1. has to be enforced within slapd or 2. could this
be enforced within smbd?
If 1. maybe the functionality/configuration of slapo-constraint could be
extended to define things like this.
(I've stumbled across ITS#5704. Isn't that already something like this?)

...more...?

In web2ldap's plugin classes I have implemented special treatment for
non-compliant notation for the DN part of LDAP URLs to reference a DN
based on an entry's DN:

.	the entry's DN
..	the entry's parent DN
_	the best matching namingContext for the entry's DN

This strings can be appended to DNs. For example:

'ou=Users,_' would always refer to entry ou=Users below an arbitrary
naming context.

'ou=My Stuff,.' could refer to a container below a user's entry

Maybe something like this could be helpful for an extended configuration
of slapo-unique and slapo-constraint.

Hmm, also

As said only very rough ideas...

Ciao, Michael.



Followup 5

Download message
Date: Sat, 18 Apr 2009 13:54:13 +0200
From: Pierangelo Masarati <ando@sys-net.it>
To: michael@stroeder.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
michael@stroeder.com wrote:
> ando@sys-net.it wrote:
>> ----- abartlet@samba.org wrote:
>>> Active Directory always presents an attribute 'name' that is always
>>> equal to the relative distinguished name.  AD allows only one RDN,
>>> but I don't mind if this can be multi-valued for the multi-RDN
>>> case.  It is equal to the value of the RDN as presented in the RDN.
>>>
>>> This is not simply the subtype 'CN -> name', but a new attribute

>>> unrelated to the existing definition of 'name'.
>>>
>>> I don't care what name is assigned to 'name', as I can easily remap
>>> attributes.
>>>
>>> It would be great if this could be constructed such that it may be 
>>> declared to be unique for a particular one-level search (also an AD
>>> requirement, but not one Samba4 requires or enforces at this time).
>> The only problem I see in defining such an attribute is that its
>> syntax should allow the value of any syntax, so it should probably be
>> octetString or something like that.
> 
> Why? IMO such an attribute type could be declared like any other
> attribute type. If its syntax does not match the syntax of the
> characteristic attribute invalidAttributeSyntax should be returned.

Since we're dealing with something unspecified, you can:

- be "strict": only allow the creation of this attribute when the naming 
attribute's syntax is 2.5.5.12 (unspecified, I understand, but we live 
in a wild world)

- be "liberal": always allow the creation of this attribute by allowing 
it to contain any value

> I wonder what the exact requirements for the implementation within slapd
> are and some very rough ideas as food for thought:
> 
> 1. slapd shall enforce uniqueness on one-level
> => I'd vote for an additional feature of slapo-unique to define the
> scope of uniqueness in a very flexible way
> 
> 2. Value of 'name' has to match the value of the characteristic
> attribute. Does this 1. has to be enforced within slapd or 2. could this
> be enforced within smbd?
> If 1. maybe the functionality/configuration of slapo-constraint could be
> extended to define things like this.
> (I've stumbled across ITS#5704. Isn't that already something like this?)

not exactly, as sets do not allow a placeholder for the naming 
attribute; maybe something like "this/entryRDN.ava{0}.value" if it 
existed...

p.

> ...more...?
> 
> In web2ldap's plugin classes I have implemented special treatment for
> non-compliant notation for the DN part of LDAP URLs to reference a DN
> based on an entry's DN:
> 
> .	the entry's DN
> ..	the entry's parent DN
> _	the best matching namingContext for the entry's DN
> 
> This strings can be appended to DNs. For example:
> 
> 'ou=Users,_' would always refer to entry ou=Users below an arbitrary
> naming context.
> 
> 'ou=My Stuff,.' could refer to a container below a user's entry
> 
> Maybe something like this could be helpful for an extended configuration
> of slapo-unique and slapo-constraint.
> 
> Hmm, also
> 
> As said only very rough ideas...
> 
> Ciao, Michael.
> 
> 



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
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------



Followup 6

Download message
Date: Sat, 18 Apr 2009 15:21:12 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: Pierangelo Masarati <ando@sys-net.it>
CC: openldap-its@openldap.org
Subject: Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
Pierangelo Masarati wrote:
> michael@stroeder.com wrote:
>> (I've stumbled across ITS#5704. Isn't that already something like
this?)
> 
> not exactly, as sets do not allow a placeholder for the naming
> attribute; maybe something like "this/entryRDN.ava{0}.value" if it
> existed...

But given that slapd already enforces the characteristic attribute (e.g.
'cn' for 'user' on Samba4) to be part of the entry IMHO this is not
needed. Provided the order of the checks are right.

So this would be:

constraint_attribute    name set
   "this/cn"
   restrict="ldap:///dc=example,dc=com??sub?(objectClass=user)"

constraint_attribute    name set
   "this/ou"
restrict="ldap:///dc=example,dc=com??sub?(objectClass=organizationalUnit)"

Since uniqueness of 'cn' or 'ou' for one-level search for the above
cases is already enforced wouldn't this be sufficient?

Maybe I miss something though.

Ciao, Michael.



Followup 7

Download message
Date: Mon, 3 Aug 2009 20:44:28 +0200 (CEST)
Subject: (ITS#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
From: masarati@aero.polimi.it
To: abartlet@samba.org
Cc: openldap-its@openldap.org
[Resending because I forgot the ITS number in the subject]

I have a simple prototype that on add/modrdn populates/maintains an
attribute (rdnValue) with the distinguished values of the naming
attributes of the RDN.  While doing this, it also checks for uniqueness of
the rdnValue value within siblings.

You can find it here
<ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.2.c>

Please test and comment.  I hope it does what intended.

p.





Followup 8

Download message
Subject: Re: (ITS#6055) Re: Samba4 need 'name' implementation like AD
 (RDN-Name)
From: Andrew Bartlett <abartlet@samba.org>
To: masarati@aero.polimi.it
Cc: openldap-its@openldap.org
Date: Wed, 05 Aug 2009 21:44:05 +1000
--=-797W8K2OMmXVapcbJp3G
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2009-08-03 at 20:44 +0200, masarati@aero.polimi.it wrote:
> [Resending because I forgot the ITS number in the subject]
>=20
> I have a simple prototype that on add/modrdn populates/maintains an
> attribute (rdnValue) with the distinguished values of the naming
> attributes of the RDN.  While doing this, it also checks for uniqueness o=
f
> the rdnValue value within siblings.
>=20
> You can find it here
> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.2.=
c>
>=20
> Please test and comment.  I hope it does what intended.

Can you please remind me in a few days if I don't get to this?

I'm keen to try it out, but I'm also busy with other things, so liable
to forget.

Andrew Bartlett

--=20
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

--=-797W8K2OMmXVapcbJp3G
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQBKeXCFz4A8Wyi0NrsRAnciAJ0W4oCBgFTi9hZ9kRZhYV2HVhYY5QCfb5pG
YmV71t4D3eYdAPwunBt5clU=
=ZZGj
-----END PGP SIGNATURE-----

--=-797W8K2OMmXVapcbJp3G--



Followup 9

Download message
Subject: Re: (ITS#6055) Re: Samba4 need 'name' implementation like AD
 (RDN-Name)
From: Andrew Bartlett <abartlet@samba.org>
To: masarati@aero.polimi.it
Cc: openldap-its@openldap.org
Date: Tue, 02 Mar 2010 15:30:39 +1100
--=-3cgveKzr2Byp6ib+VYg9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2009-08-03 at 20:44 +0200, masarati@aero.polimi.it wrote:
> [Resending because I forgot the ITS number in the subject]
>=20
> I have a simple prototype that on add/modrdn populates/maintains an
> attribute (rdnValue) with the distinguished values of the naming
> attributes of the RDN.  While doing this, it also checks for uniqueness o=
f
> the rdnValue value within siblings.
>=20
> You can find it here
> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.2.=
c>
>=20
> Please test and comment.  I hope it does what intended.

I'm starting to look at this now.  I'm sorry so many months have past
since you posted it.

Andrew Bartlett

--=20
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


--=-3cgveKzr2Byp6ib+VYg9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQBLjJRvz4A8Wyi0NrsRAqh2AJ4uvpxIGj0PTacpWVLVO18BRrWqaQCeOqhh
VdZtFVltm6uv6qY3Lw7ULpk=
=zoZi
-----END PGP SIGNATURE-----

--=-3cgveKzr2Byp6ib+VYg9--



Followup 10

Download message
Subject: Re: (ITS#6055) Re: Samba4 need 'name' implementation like AD
 (RDN-Name)
From: Andrew Bartlett <abartlet@samba.org>
To: masarati@aero.polimi.it
Cc: openldap-its@openldap.org
Date: Tue, 02 Mar 2010 18:17:02 +1100
--=-wu98lDL/cs9xvAtVkpXf
Content-Type: multipart/mixed; boundary="=-bGZqaJas0lpiam3pf2jA"


--=-bGZqaJas0lpiam3pf2jA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2010-03-02 at 15:30 +1100, Andrew Bartlett wrote:
> On Mon, 2009-08-03 at 20:44 +0200, masarati@aero.polimi.it wrote:
> > [Resending because I forgot the ITS number in the subject]
> >=20
> > I have a simple prototype that on add/modrdn populates/maintains an
> > attribute (rdnValue) with the distinguished values of the naming
> > attributes of the RDN.  While doing this, it also checks for
uniqueness=
 of
> > the rdnValue value within siblings.
> >=20
> > You can find it here
> > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.=
2.c>
> >=20
> > Please test and comment.  I hope it does what intended.
>=20
> I'm starting to look at this now.  I'm sorry so many months have past
> since you posted it.

I've now added it into Samba's provision, and using the diff I attach,
against current 'master', I get the attached error.

It seems to be unable to add the base DN. (The very first entry in the
database).

Andrew Bartlett

--=20
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


--=-bGZqaJas0lpiam3pf2jA
Content-Disposition: attachment; filename="rdnval-use-in-samba.diff"
Content-Transfer-Encoding: base64
Content-Type: text/x-patch; name="rdnval-use-in-samba.diff"; charset="UTF-8"

ZGlmZiAtLWdpdCBhL3NvdXJjZTQvZHNkYi9zYW1kYi9sZGJfbW9kdWxlcy9zYW1iYV9kc2RiLmMg
Yi9zb3VyY2U0L2RzZGIvc2FtZGIvbGRiX21vZHVsZXMvc2FtYmFfZHNkYi5jDQppbmRleCBjOTI5
ZDY1Li5jOGQ1YjkzIDEwMDY0NA0KLS0tIGEvc291cmNlNC9kc2RiL3NhbWRiL2xkYl9tb2R1bGVz
L3NhbWJhX2RzZGIuYw0KKysrIGIvc291cmNlNC9kc2RiL3NhbWRiL2xkYl9tb2R1bGVzL3NhbWJh
X2RzZGIuYw0KQEAgLTE3NSw3ICsxNzUsNiBAQCBzdGF0aWMgaW50IHNhbWJhX2RzZGJfaW5pdChz
dHJ1Y3QgbGRiX21vZHVsZSAqbW9kdWxlKQ0KIAkJCQkJICAgICAiYXNxIiwNCiAJCQkJCSAgICAg
ImV4dGVuZGVkX2RuX3N0b3JlIiwNCiAJCQkJCSAgICAgImV4dGVuZGVkX2RuX2luIiwNCi0JCQkJ
CSAgICAgInJkbl9uYW1lIiwNCiAJCQkJCSAgICAgIm9iamVjdGNsYXNzIiwNCiAJCQkJCSAgICAg
ImRlc2NyaXB0b3IiLA0KIAkJCQkJICAgICAiYWNsIiwNCkBAIC0xOTEsNiArMTkwLDcgQEAgc3Rh
dGljIGludCBzYW1iYV9kc2RiX2luaXQoc3RydWN0IGxkYl9tb2R1bGUgKm1vZHVsZSkNCiAJY29u
c3QgY2hhciAqKmxpbmtfbW9kdWxlczsNCiAJc3RhdGljIGNvbnN0IGNoYXIgKnRkYl9tb2R1bGVz
X2xpc3RbXSA9IHsNCiAJCSJzdWJ0cmVlX2RlbGV0ZSIsDQorCQkicmRuX25hbWUiLA0KIAkJInJl
cGxfbWV0YV9kYXRhIiwNCiAJCSJzdWJ0cmVlX3JlbmFtZSIsDQogCQkibGlua2VkX2F0dHJpYnV0
ZXMiLA0KZGlmZiAtLWdpdCBhL3NvdXJjZTQvZHNkYi9zYW1kYi9sZGJfbW9kdWxlcy9zaW1wbGVf
bGRhcF9tYXAuYyBiL3NvdXJjZTQvZHNkYi9zYW1kYi9sZGJfbW9kdWxlcy9zaW1wbGVfbGRhcF9t
YXAuYw0KaW5kZXggYmY5Y2Q0Zi4uNWVjN2E0YSAxMDA2NDQNCi0tLSBhL3NvdXJjZTQvZHNkYi9z
YW1kYi9sZGJfbW9kdWxlcy9zaW1wbGVfbGRhcF9tYXAuYw0KKysrIGIvc291cmNlNC9kc2RiL3Nh
bWRiL2xkYl9tb2R1bGVzL3NpbXBsZV9sZGFwX21hcC5jDQpAQCAtMjg3LDcgKzI4Nyw3IEBAIHN0
YXRpYyBjb25zdCBzdHJ1Y3QgbGRiX21hcF9hdHRyaWJ1dGUgZW50cnl1dWlkX2F0dHJpYnV0ZXNb
XSA9DQogCQkudHlwZSA9IExEQl9NQVBfUkVOQU1FLA0KIAkJLnUgPSB7DQogCQkJLnJlbmFtZSA9
IHsNCi0JCQkJIC5yZW1vdGVfbmFtZSA9ICJzYW1iYTRSRE4iDQorCQkJCSAucmVtb3RlX25hbWUg
PSAicmRudmFsIg0KIAkJCSB9DQogCQl9DQogCX0sDQpkaWZmIC0tZ2l0IGEvc291cmNlNC9zZXR1
cC9zY2hlbWEtbWFwLW9wZW5sZGFwLTIuMyBiL3NvdXJjZTQvc2V0dXAvc2NoZW1hLW1hcC1vcGVu
bGRhcC0yLjMNCmluZGV4IDBkMzg2NTIuLmFlZDU0MDIgMTAwNjQ0DQotLS0gYS9zb3VyY2U0L3Nl
dHVwL3NjaGVtYS1tYXAtb3BlbmxkYXAtMi4zDQorKysgYi9zb3VyY2U0L3NldHVwL3NjaGVtYS1t
YXAtb3BlbmxkYXAtMi4zDQpAQCAtMTUsNiArMTUsOSBAQCB1aWROdW1iZXINCiBnaWROdW1iZXIN
CiAjVGhlIG1lbWJlck9mIHBsdWdpbiBwcm92aWRlcyB0aGlzIGF0dHJpYnV0ZQ0KIG1lbWJlck9m
DQorIyduYW1lJyBpcyB0aGUgUkROIGluIEFELCBidXQgc29tZXRoaW5nIGVsc2UgaW4gT3BlbkxE
QVAuICBTa2lwIGFuZA0KKyMgdXNlIHRoZSBPcGVuTERBUCBvbmUNCituYW1lDQogI1RoZXNlIGNv
bmZsaWN0IHdpdGggT3BlbkxEQVAgYnVpbHRpbnMNCiBhdHRyaWJ1dGVUeXBlczpzYW1iYTRBdHRy
aWJ1dGVUeXBlcw0KIDIuNS4yMS41OjEuMy42LjEuNC4xLjcxNjUuNC4yNTUuNw0KQEAgLTI0LDgg
KzI3LDYgQEAgb2JqZWN0Q2xhc3NlczpzYW1iYTRPYmplY3RDbGFzc2VzDQogMi41LjIxLjY6MS4z
LjYuMS40LjEuNzE2NS40LjI1NS41DQogc3ViU2NoZW1hOnNhbWJhNFN1YlNjaGVtYQ0KIDIuNS4y
MC4xOjEuMy42LjEuNC4xLjcxNjUuNC4yNTUuNA0KLSMnbmFtZScgaXMgdGhlIFJETiBpbiBBRCwg
YnV0IHNvbWV0aGluZyBlbHNlIGluIE9wZW5MREFQDQotbmFtZTpzYW1iYTRSRE4NCiAjUmVtYXAg
dGhlc2Ugc28gdGhhdCB3ZSBkb24ndCBwdXQgb3BlcmF0aW9uYWwgYXR0cmlidXRlcyBpbiBhIHNj
aGVtYSBNQVkNCiBtb2RpZnlUaW1lU3RhbXA6c2FtYmE0TW9kaWZ5VGltZXN0YW1wDQogMi41LjE4
LjI6MS4zLjYuMS40LjEuNzE2NS40LjI1NS4zDQpkaWZmIC0tZ2l0IGEvc291cmNlNC9zZXR1cC9z
bGFwZC5jb25mIGIvc291cmNlNC9zZXR1cC9zbGFwZC5jb25mDQppbmRleCAwMDc3YTIyLi5lNWZj
ZDA2IDEwMDY0NA0KLS0tIGEvc291cmNlNC9zZXR1cC9zbGFwZC5jb25mDQorKysgYi9zb3VyY2U0
L3NldHVwL3NsYXBkLmNvbmYNCkBAIC00OSw2ICs0OSw3IEBAIGRlZmF1bHRzZWFyY2hiYXNlICR7
RE9NQUlORE59DQogcm9vdGRuIGNuPU1hbmFnZXINCiANCiBvdmVybGF5IGRlcmVmDQorb3Zlcmxh
eSByZG52YWwNCiANCiAke1JFRklOVF9DT05GSUd9DQogDQo=


--=-bGZqaJas0lpiam3pf2jA
Content-Disposition: attachment; filename="rdnval-errors

Message of length 10614 truncated


Followup 11

Download message
Date: Tue, 30 Mar 2010 18:28:28 +0200 (CEST)
Subject: Re: (ITS#6055) Re: Samba4 need 'name' implementation like AD 
     (RDN-Name)
From: masarati@aero.polimi.it
To: "Andrew Bartlett" <abartlet@samba.org>
Cc: openldap-its@openldap.org
> On Tue, 2010-03-02 at 15:30 +1100, Andrew Bartlett wrote:
>> On Mon, 2009-08-03 at 20:44 +0200, masarati@aero.polimi.it wrote:
>> > [Resending because I forgot the ITS number in the subject]
>> >
>> > I have a simple prototype that on add/modrdn populates/maintains
an
>> > attribute (rdnValue) with the distinguished values of the naming
>> > attributes of the RDN.  While doing this, it also checks for
>> uniqueness of
>> > the rdnValue value within siblings.
>> >
>> > You can find it here
>> > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.2.c>
>> >
>> > Please test and comment.  I hope it does what intended.
>>
>> I'm starting to look at this now.  I'm sorry so many months have past
>> since you posted it.
>
> I've now added it into Samba's provision, and using the diff I attach,
> against current 'master', I get the attached error.
>
> It seems to be unable to add the base DN. (The very first entry in the
> database).

Try this:
<www.aero.polimi.it/masarati/Download/pierangelo-masarati-2010-03-30-rdnval.2.c>.
 In fact, when adding the suffix entry, the overlay was erroneously
checking its siblings from its superior, which is very likely to fail.

p.



Followup 12

Download message
Date: Mon, 19 Apr 2010 02:15:20 +0200 (CEST)
Subject: ITS#6055
From: masarati@aero.polimi.it
To: abartlet@samba.org
Cc: openldap-its@openldap.org
Refactored rdnval.c available at

<ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-18-rdnval.c>

attempts to repair the database at startup; useful when the overlay is
configured for an existing database.  Please test.

p.



Followup 13

Download message
Subject: Re: ITS#6055
From: Andrew Bartlett <abartlet@samba.org>
To: masarati@aero.polimi.it
Cc: openldap-its@openldap.org
Date: Tue, 20 Apr 2010 14:38:39 +1000
--=-JaZE3OeFLXsBmyVf+gjk
Content-Type: multipart/mixed; boundary="=-5geAzHYesMuCPweb8j5I"


--=-5geAzHYesMuCPweb8j5I
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2010-04-19 at 02:15 +0200, masarati@aero.polimi.it wrote:
> Refactored rdnval.c available at
>=20
> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-18-rdnval.c>
>=20
> attempts to repair the database at startup; useful when the overlay is
> configured for an existing database.  Please test.

Sadly it segfaults on startup (we don't have the DB at startup - we
expect the first operations to create them).=20

I produced the environment with Samba4 from master
(538a07a80aae72b57e5c23133158c7f214d0c27a) with the attached additional
patch

TEST_LDAP=3Dyes OPENLDAP_SLAPD=3D/usr/local/libexec/slapd make quicktest

This ran:=20
'/usr/local/libexec/slapd'
'-F/scratch/samba-2/source4/st/dc/private/ldap/slapd.d' '-h' 'ldapi://%
2Fscratch%2Fsamba-2%2Fsource4%2Fst%2Fdc%2Fprivate%2Fldap%2Fldapi' '-d0'

and running that under gdb produced

Program received signal SIGSEGV, Segmentation fault.
0x000000000057ba54 in rdnval_repair (be=3D0x7fffffffdbe0) at rdnval.c:466
466		op->o_req_dn =3D op->o_bd->be_suffix[ 0 ];
Missing separate debuginfos, use: debuginfo-install
glibc-2.11.90-17.x86_64 libgcc-4.4.3-12.fc13.x86_64
libicu-4.2.1-7.fc12.x86_64 libicu-4.2.1-8.fc13.x86_64 libstdc
++-4.4.3-12.fc13.x86_64 libtool-ltdl-2.2.6-18.fc12.x86_64
libtool-ltdl-2.2.6-18.fc13.x86_64 libuuid-2.17.2-1.fc13.x86_64
mysql-libs-5.1.45-2.fc13.x86_64 postgresql-libs-8.4.3-1.fc13.x86_64
(gdb) p op
$1 =3D (Operation *) 0x7fffffffd4d0
(gdb) p op->o_bd
$2 =3D (BackendDB *) 0x0
(gdb) p *op
$3 =3D {o_hdr =3D 0x7fffffffd640, o_tag =3D 99, o_time =3D 1271737105, o_ti=
ncr =3D
1, o_bd =3D 0x0, o_req_dn =3D {bv_len =3D 0, bv_val =3D 0x0}, o_req_ndn =3D
{bv_len =3D 0, bv_val =3D 0x0}, o_request =3D {oq_add =3D {rs_modlist =3D 0=
x0,
rs_e =3D 0x0}, oq_bind =3D {
      rb_method =3D 0, rb_cred =3D {bv_len =3D 0, bv_val =3D 0x0}, rb_edn =
=3D
{bv_len =3D 0, bv_val =3D 0x0}, rb_ssf =3D 0, rb_mech =3D {bv_len =3D 0, bv=
_val =3D
0x0}}, oq_compare =3D {rs_ava =3D 0x0}, oq_modify =3D {rs_mods =3D {rs_modl=
ist =3D
0x0,=20
        rs_no_opattrs =3D 0 '\000'}, rs_increment =3D 0}, oq_modrdn =3D
{rs_mods =3D {rs_modlist =3D 0x0, rs_no_opattrs =3D 0 '\000'}, rs_deleteold=
rdn
=3D 0, rs_newrdn =3D {bv_len =3D 0, bv_val =3D 0x0}, rs_nnewrdn =3D {bv_len=
 =3D 0,
bv_val =3D 0x0},=20
      rs_newSup =3D 0x0, rs_nnewSup =3D 0x0}, oq_search =3D {rs_scope =3D 0=
,
rs_deref =3D 0, rs_slimit =3D 0, rs_tlimit =3D 0, rs_limit =3D 0x0, rs_attr=
sonly
=3D 0, rs_attrs =3D 0x0, rs_filter =3D 0x0, rs_filterstr =3D {bv_len =3D 0,=
 bv_val
=3D 0x0}},=20
    oq_abandon =3D {rs_msgid =3D 0}, oq_cancel =3D {rs_msgid =3D 0}, oq_ext=
ended
=3D {rs_reqoid =3D {bv_len =3D 0, bv_val =3D 0x0}, rs_flags =3D 0, rs_reqda=
ta =3D
0x0}, oq_pwdexop =3D {rs_extended =3D {rs_reqoid =3D {bv_len =3D 0, bv_val =
=3D
0x0}, rs_flags =3D 0,=20
        rs_reqdata =3D 0x0}, rs_old =3D {bv_len =3D 0, bv_val =3D 0x0}, rs_=
new =3D
{bv_len =3D 0, bv_val =3D 0x0}, rs_mods =3D 0x0, rs_modtail =3D 0x0}}, o_ab=
andon
=3D 0, o_cancel =3D 0, o_groups =3D 0x0, o_do_not_cache =3D 0 '\000',
o_is_auth_check =3D 0 '\000',=20
  o_dont_replicate =3D 0 '\000', o_acl_priv =3D ACL_NONE, o_nocaching =3D 0
'\000', o_delete_glue_parent =3D 0 '\000', o_no_schema_check =3D 0 '\000',
o_no_subordinate_glue =3D 0 '\000', o_ctrlflag =3D '\000' <repeats 31
times>,=20
  o_controls =3D 0x7fffffffd788, o_authz =3D {sai_method =3D 0, sai_mech =
=3D
{bv_len =3D 0, bv_val =3D 0x0}, sai_dn =3D {bv_len =3D 0, bv_val =3D 0x0}, =
sai_ndn
=3D {bv_len =3D 0, bv_val =3D 0x0}, sai_ssf =3D 0, sai_transport_ssf =3D 0,
sai_tls_ssf =3D 0,=20
    sai_sasl_ssf =3D 0}, o_ber =3D 0x0, o_res_ber =3D 0x0, o_callback =3D 0=
x0,
o_ctrls =3D 0x0, o_csn =3D {bv_len =3D 0, bv_val =3D 0x0}, o_private =3D 0x=
0,
o_extra =3D {slh_first =3D 0x0}, o_next =3D {stqe_next =3D 0x0}}
(gdb)=20


--=20
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


--=-5geAzHYesMuCPweb8j5I
Content-Disposition: attachment; filename="add-rdnval.patch"
Content-Transfer-Encoding: base64
Content-Type: text/x-patch; name="add-rdnval.patch"; charset="UTF-8"

ZGlmZiAtLWdpdCBhL3NvdXJjZTQvc2V0dXAvc2xhcGQuY29uZiBiL3NvdXJjZTQvc2V0dXAvc2xh
cGQuY29uZg0KaW5kZXggMDA3N2EyMi4uZTVmY2QwNiAxMDA2NDQNCi0tLSBhL3NvdXJjZTQvc2V0
dXAvc2xhcGQuY29uZg0KKysrIGIvc291cmNlNC9zZXR1cC9zbGFwZC5jb25mDQpAQCAtNDksNiAr
NDksNyBAQCBkZWZhdWx0c2VhcmNoYmFzZSAke0RPTUFJTkROfQ0KIHJvb3RkbiBjbj1NYW5hZ2Vy
DQogDQogb3ZlcmxheSBkZXJlZg0KK292ZXJsYXkgcmRudmFsDQogDQogJHtSRUZJTlRfQ09ORklH
fQ0KIA0K


--=-5geAzHYesMuCPweb8j5I--

--=-JaZE3OeFLXsBmyVf+gjk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

---

Message of length 5216 truncated


Followup 14

Download message
Date: Tue, 20 Apr 2010 07:11:22 +0200 (CEST)
Subject: Re: ITS#6055
From: masarati@aero.polimi.it
To: "Andrew Bartlett" <abartlet@samba.org>
Cc: openldap-its@openldap.org
> On Mon, 2010-04-19 at 02:15 +0200, masarati@aero.polimi.it wrote:
>> Refactored rdnval.c available at
>>
>> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-18-rdnval.c>
>>
>> attempts to repair the database at startup; useful when the overlay is
>> configured for an existing database.  Please test.
>
> Sadly it segfaults on startup (we don't have the DB at startup - we
> expect the first operations to create them).

It's not that sad: this overlay is not intended to be used as global.  You
should use it within any database you want the rdnvalue stored.  I haven't
considered yet how hard it would be to allow it to be global, and if it's
worth.  Since it needs to write operational attributes to the directory,
it may run into issues in case non-local storage databases are used, and
it'd definitely risk to suffer from authentication issues.  Does it make
sense for you to add an instance in each database you need rndvalue for?

p.

> I produced the environment with Samba4 from master
> (538a07a80aae72b57e5c23133158c7f214d0c27a) with the attached additional
> patch
>
> TEST_LDAP=yes OPENLDAP_SLAPD=/usr/local/libexec/slapd make quicktest
>
> This ran:
> '/usr/local/libexec/slapd'
> '-F/scratch/samba-2/source4/st/dc/private/ldap/slapd.d' '-h' 'ldapi://%
> 2Fscratch%2Fsamba-2%2Fsource4%2Fst%2Fdc%2Fprivate%2Fldap%2Fldapi' '-d0'
>
> and running that under gdb produced
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000000057ba54 in rdnval_repair (be=0x7fffffffdbe0) at rdnval.c:466
> 466		op->o_req_dn = op->o_bd->be_suffix[ 0 ];
> Missing separate debuginfos, use: debuginfo-install
> glibc-2.11.90-17.x86_64 libgcc-4.4.3-12.fc13.x86_64
> libicu-4.2.1-7.fc12.x86_64 libicu-4.2.1-8.fc13.x86_64 libstdc
> ++-4.4.3-12.fc13.x86_64 libtool-ltdl-2.2.6-18.fc12.x86_64
> libtool-ltdl-2.2.6-18.fc13.x86_64 libuuid-2.17.2-1.fc13.x86_64
> mysql-libs-5.1.45-2.fc13.x86_64 postgresql-libs-8.4.3-1.fc13.x86_64
> (gdb) p op
> $1 = (Operation *) 0x7fffffffd4d0
> (gdb) p op->o_bd
> $2 = (BackendDB *) 0x0
> (gdb) p *op
> $3 = {o_hdr = 0x7fffffffd640, o_tag = 99, o_time = 1271737105, o_tincr =
> 1, o_bd = 0x0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn =
> {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = {rs_modlist = 0x0,
> rs_e = 0x0}, oq_bind = {
>       rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn =
> {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val =
> 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist =
> 0x0,
>         rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn =
> {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn
> = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0,
> bv_val = 0x0},
>       rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 0,
> rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly
> = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val
> = 0x0}},
>     oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended
> = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata =
> 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val =
> 0x0}, rs_flags = 0,
>         rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new =
> {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon
> = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000',
> o_is_auth_check = 0 '\000',
>   o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0
> '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000',
> o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31
> times>,
>   o_controls = 0x7fffffffd788, o_authz = {sai_method = 0, sai_mech =
> {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn
> = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0,
> sai_tls_ssf = 0,
>     sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0,
> o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0,
> o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}}
> (gdb)
>
>
> --
> Andrew Bartlett                                http://samba.org/~abartlet/
> Authentication Developer, Samba Team           http://samba.org
> Samba Developer, Cisco Inc.
>
>




Followup 15

Download message
Subject: Re: ITS#6055
From: Andrew Bartlett <abartlet@samba.org>
To: masarati@aero.polimi.it
Cc: openldap-its@openldap.org
Date: Tue, 20 Apr 2010 16:43:56 +1000
--=-8VSfpSadYnNS78ACEBD7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2010-04-20 at 07:11 +0200, masarati@aero.polimi.it wrote:
> > On Mon, 2010-04-19 at 02:15 +0200, masarati@aero.polimi.it wrote:
> >> Refactored rdnval.c available at
> >>
> >> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-18-rdnval=
.c>
> >>
> >> attempts to repair the database at startup; useful when the
overlay is
> >> configured for an existing database.  Please test.
> >
> > Sadly it segfaults on startup (we don't have the DB at startup - we
> > expect the first operations to create them).
>=20
> It's not that sad: this overlay is not intended to be used as global.  Yo=
u
> should use it within any database you want the rdnvalue stored.  I haven'=
t
> considered yet how hard it would be to allow it to be global, and if it's
> worth.  Since it needs to write operational attributes to the directory,
> it may run into issues in case non-local storage databases are used, and
> it'd definitely risk to suffer from authentication issues.  Does it make
> sense for you to add an instance in each database you need rndvalue for?

That's no problem at all.  It now just fails in the same was as without
the patch.  I'll mention it on openldap-technical if I can't get
assistance on #ldap.

Then, when I get past that, I'll get back to this!

Andrew Bartlett

--=20
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


--=-8VSfpSadYnNS78ACEBD7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iD8DBQBLzU0sz4A8Wyi0NrsRAu1jAKCZMe8/cj55Qm+nFk1lZ0nRDnvQWACfXKCh
jbVrJNvjzyeb5W6fOR49u58=
=UMuS
-----END PGP SIGNATURE-----

--=-8VSfpSadYnNS78ACEBD7--



Followup 16

Download message
Date: Tue, 20 Apr 2010 15:37:35 +0200 (CEST)
Subject: Re: ITS#6055
From: masarati@aero.polimi.it
To: "Andrew Bartlett" <abartlet@samba.org>
Cc: openldap-its@openldap.org
> That's no problem at all.

Good.  This version explicitly check for instantiation as global, and also
does some further sanity checks prior to startup.

<ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-20-rdnval.2.c>

> It now just fails in the same was as without
> the patch.  I'll mention it on openldap-technical if I can't get
> assistance on #ldap.

Not quite clear what patch and what failure you refer to.  Anyway, I've
tested this version of the overlay as global (refuses to start) and on a
database, either empty or populated, and it works as intended.  Please
test and report.  Thanks, p.



Followup 17

Download message
Subject: Re: ITS#6055
From: Andrew Bartlett <abartlet@samba.org>
To: masarati@aero.polimi.it
Cc: openldap-its@openldap.org
Date: Wed, 21 Apr 2010 11:39:29 +1000
--=-u2bdcYXWzM+LH/qgpb9q
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2010-04-20 at 15:37 +0200, masarati@aero.polimi.it wrote:
> > That's no problem at all.
>=20
> Good.  This version explicitly check for instantiation as global, and als=
o
> does some further sanity checks prior to startup.
>=20
> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-20-rdnval.2.=
c>
>=20
> > It now just fails in the same was as without
> > the patch.  I'll mention it on openldap-technical if I can't get
> > assistance on #ldap.
>=20
> Not quite clear what patch and what failure you refer to.  Anyway, I've
> tested this version of the overlay as global (refuses to start) and on a
> database, either empty or populated, and it works as intended.  Please
> test and report.  Thanks, p.

It seems to be working well.  When can I expect it to be in the tree?

(I'll then require folks to use the current OpenLDAP CVS if they want to
use the LDAP backend).

Andrew Bartlett

--=20
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


--=-u2bdcYXWzM+LH/qgpb9q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iD8DBQBLzldRz4A8Wyi0NrsRAgzTAJ4lv6P1wia2JLA7L2jPNkpgEvX3FwCgqyY0
jrguLg5MsW14D6wPlNThuko=
=F1ZZ
-----END PGP SIGNATURE-----

--=-u2bdcYXWzM+LH/qgpb9q--



Followup 18

Download message
Date: Wed, 21 Apr 2010 03:44:46 +0200 (CEST)
Subject: Re: ITS#6055
From: masarati@aero.polimi.it
To: "Andrew Bartlett" <abartlet@samba.org>
Cc: openldap-its@openldap.org
> On Tue, 2010-04-20 at 15:37 +0200, masarati@aero.polimi.it wrote:
>> > That's no problem at all.
>>
>> Good.  This version explicitly check for instantiation as global, and
>> also
>> does some further sanity checks prior to startup.
>>
>> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-20-rdnval.2.c>
>>
>> > It now just fails in the same was as without
>> > the patch.  I'll mention it on openldap-technical if I can't get
>> > assistance on #ldap.
>>
>> Not quite clear what patch and what failure you refer to.  Anyway, I've
>> tested this version of the overlay as global (refuses to start) and on
a
>> database, either empty or populated, and it works as intended.  Please
>> test and report.  Thanks, p.
>
> It seems to be working well.  When can I expect it to be in the tree?
>
> (I'll then require folks to use the current OpenLDAP CVS if they want to
> use the LDAP backend).

I can commit it in a minute.  It's not 100% clear to me what's the most
appropriate location: slapd/overlays/ may not, as this looks like
something definitely specific to Samba4; probably, contrib/slapd-modules/
is more appropriate.  Perhaps, a contrib/slapd-modules/samba4/ would be
the most appropriate, along with future specific (i.e. not of general
usefulness) modules, as we did for the nssov module.

Comments?  I mean, from others, not only from you :)

p.



Followup 19

Download message
Subject: Re: ITS#6055
From: Andrew Bartlett <abartlet@samba.org>
To: masarati@aero.polimi.it
Cc: openldap-its@openldap.org
Date: Wed, 21 Apr 2010 12:24:49 +1000
--=-plI2z6xrAOfHgQ7f8NT2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2010-04-21 at 03:44 +0200, masarati@aero.polimi.it wrote:
> > On Tue, 2010-04-20 at 15:37 +0200, masarati@aero.polimi.it wrote:
> >> > That's no problem at all.
> >>
> >> Good.  This version explicitly check for instantiation as global,
and
> >> also
> >> does some further sanity checks prior to startup.
> >>
> >> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-20-rdnval=
.2.c>
> >>
> >> > It now just fails in the same was as without
> >> > the patch.  I'll mention it on openldap-technical if I can't
get
> >> > assistance on #ldap.
> >>
> >> Not quite clear what patch and what failure you refer to.  Anyway,
I'v=
e
> >> tested this version of the overlay as global (refuses to start)
and on=
 a
> >> database, either empty or populated, and it works as intended. 
Please
> >> test and report.  Thanks, p.
> >
> > It seems to be working well.  When can I expect it to be in the tree?
> >
> > (I'll then require folks to use the current OpenLDAP CVS if they want
t=
o
> > use the LDAP backend).
>=20
> I can commit it in a minute.  It's not 100% clear to me what's the most
> appropriate location: slapd/overlays/ may not, as this looks like
> something definitely specific to Samba4; probably, contrib/slapd-modules/
> is more appropriate.  Perhaps, a contrib/slapd-modules/samba4/ would be
> the most appropriate, along with future specific (i.e. not of general
> usefulness) modules, as we did for the nssov module.
>=20
> Comments?  I mean, from others, not only from you :)

My only concern is that it be maintained, so that the OpenLDAP backend
can be a supported part of Samba4 into the long term.  (I know it's not
been in good shape for the past while, but there is hope we can get it
back on track).=20

Do contrib modules come with this level of maintenance?

Andrew Bartlett

--=20
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


--=-plI2z6xrAOfHgQ7f8NT2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iD8DBQBLzmHxz4A8Wyi0NrsRAlF3AKCXBqb/jzSgemy/GREWapoan6QkVwCgj1of
Dmourk1xQiMAlvWFJocYuSQ=
=rE8J
-----END PGP SIGNATURE-----

--=-plI2z6xrAOfHgQ7f8NT2--



Followup 20

Download message
Date: Wed, 21 Apr 2010 04:32:48 +0200 (CEST)
Subject: Re: ITS#6055
From: masarati@aero.polimi.it
To: "Andrew Bartlett" <abartlet@samba.org>
Cc: openldap-its@openldap.org
> My only concern is that it be maintained, so that the OpenLDAP backend
> can be a supported part of Samba4 into the long term.  (I know it's not
> been in good shape for the past while, but there is hope we can get it
> back on track).
>
> Do contrib modules come with this level of maintenance?

Inherently no, because they would not be configured/built along with the
rest of the package.  Of course, as soon as users (possibly including
myself) notice issues, they would be maintained (see for example nssov).

The most straightforward way of having it routinely built is to place it
in slapd/overlays/; I guess this needs consensus from the rest of the
team.  I'd vote in favor; please holler.

p.



Followup 21

Download message
Date: Tue, 20 Apr 2010 19:44:37 -0700
From: Howard Chu <hyc@symas.com>
To: masarati@aero.polimi.it
CC: openldap-its@openldap.org
Subject: Re: ITS#6055
masarati@aero.polimi.it wrote:
>> My only concern is that it be maintained, so that the OpenLDAP backend
>> can be a supported part of Samba4 into the long term.  (I know it's not
>> been in good shape for the past while, but there is hope we can get it
>> back on track).
>>
>> Do contrib modules come with this level of maintenance?
>
> Inherently no, because they would not be configured/built along with the
> rest of the package.  Of course, as soon as users (possibly including
> myself) notice issues, they would be maintained (see for example nssov).
>
> The most straightforward way of having it routinely built is to place it
> in slapd/overlays/; I guess this needs consensus from the rest of the
> team.  I'd vote in favor; please holler.

I think contrib is the right place for now. It seems to me that the 
requirements here are still a moving target, so it's better in contrib. 
(Contrib items are free to add new features independent of the rest of the 
release cycle. Items in the main slapd/overlays are more constrained to 
bugfixes-only within a release cycle.)

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 22

Download message
Date: Wed, 21 Apr 2010 05:21:49 +0200 (CEST)
Subject: Re: ITS#6055
From: masarati@aero.polimi.it
To: hyc@symas.com
Cc: openldap-its@openldap.org
> masarati@aero.polimi.it wrote:
>>> My only concern is that it be maintained, so that the OpenLDAP
backend
>>> can be a supported part of Samba4 into the long term.  (I know it's
not
>>> been in good shape for the past while, but there is hope we can get
it
>>> back on track).
>>>
>>> Do contrib modules come with this level of maintenance?
>>
>> Inherently no, because they would not be configured/built along with
the
>> rest of the package.  Of course, as soon as users (possibly including
>> myself) notice issues, they would be maintained (see for example
nssov).
>>
>> The most straightforward way of having it routinely built is to place
it
>> in slapd/overlays/; I guess this needs consensus from the rest of the
>> team.  I'd vote in favor; please holler.
>
> I think contrib is the right place for now. It seems to me that the
> requirements here are still a moving target, so it's better in contrib.
> (Contrib items are free to add new features independent of the rest of the
> release cycle. Items in the main slapd/overlays are more constrained to
> bugfixes-only within a release cycle.)

Fair enough.  I've started committing stuff to contrib/slapd-modules/samba4

p.





Followup 23

Download message
Subject: Re: ITS#6055
From: Andrew Bartlett <abartlet@samba.org>
To: masarati@aero.polimi.it
Cc: openldap-its@openldap.org
Date: Wed, 21 Apr 2010 13:11:55 +1000
--=-dnOZfedjaeI8f/8PVlNm
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2010-04-21 at 04:32 +0200, masarati@aero.polimi.it wrote:
> > My only concern is that it be maintained, so that the OpenLDAP backend
> > can be a supported part of Samba4 into the long term.  (I know it's
not
> > been in good shape for the past while, but there is hope we can get it
> > back on track).
> >
> > Do contrib modules come with this level of maintenance?
>=20
> Inherently no, because they would not be configured/built along with the
> rest of the package.  Of course, as soon as users (possibly including
> myself) notice issues, they would be maintained (see for example nssov).
>=20
> The most straightforward way of having it routinely built is to place it
> in slapd/overlays/; I guess this needs consensus from the rest of the
> team.  I'd vote in favor; please holler.

My eventual goal is that folks using a Ubuntu or Fedora system would
have Samba4 'just work' with the packaged OpenLDAP.  I can of course
lobby them to get their packages updated to build from contrib, but it's
easier if it's just in there.=20

Similarly, when I ask folks to configure with 'OpenLDAP HEAD' in the
short term, it is of course easier for me if everything is already in
place.=20

But this is your project, not mine, and I am happy with whatever we can
make work.=20

Andrew Bartlett

--=20
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

--=-dnOZfedjaeI8f/8PVlNm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQBLzmzwz4A8Wyi0NrsRAomfAJ9J4b76Ujcu5fC3Yig3lgIBJ712ywCeOw3U
fDuSKTOqEEfK1JEriBOcJ8g=
=FSwh
-----END PGP SIGNATURE-----

--=-dnOZfedjaeI8f/8PVlNm--



Followup 24

Download message
Date: Wed, 21 Apr 2010 05:42:13 +0200 (CEST)
Subject: Re: ITS#6055
From: masarati@aero.polimi.it
To: abartlet@samba.org
Cc: openldap-its@openldap.org
> My eventual goal is that folks using a Ubuntu or Fedora system would
> have Samba4 'just work' with the packaged OpenLDAP.  I can of course
> lobby them to get their packages updated to build from contrib, but it's
> easier if it's just in there.=20
>
> Similarly, when I ask folks to configure with 'OpenLDAP HEAD' in the
> short term, it is of course easier for me if everything is already in
> place.=20
>
> But this is your project, not mine, and I am happy with whatever we can
> make work.=20

Right now, along the lines illustrated by Howard, I've committed
everything to contrib/slapd-modules/samba4.  You may need to tweak the
Makefile if you are not building in the source tree (as I usually do; then
adjust LDAP_BUILD to your build tree), and if you wish to install modules
in some specific place (prefix, exec_prefix, ldap_subdir).

My medium term objective would be to have:

- generally useful modules built-in (e.g. slapo-deref)

- Samba4-specific modules all in one contrib directory, possibly
harmonized and consolidated when possible in a single module, to ease
configuration and maintenance

The latter could then have a specific configure, if needed, so that
packagers could make and install them as easily as possible.  In the
meanwhile, we should live with this interim solution.  Time permitting, I
see no issue in maintaining that code, much like we already do with the
other modules.

p.



Followup 25

Download message
Subject: Re: ITS#6055
From: Andrew Bartlett <abartlet@samba.org>
To: masarati@aero.polimi.it
Cc: openldap-its@openldap.org
Date: Wed, 21 Apr 2010 14:17:22 +1000
--=-GJES2Ff4FHn/Nl+ftOBF
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2010-04-21 at 05:42 +0200, masarati@aero.polimi.it wrote:
> > My eventual goal is that folks using a Ubuntu or Fedora system would
> > have Samba4 'just work' with the packaged OpenLDAP.  I can of course
> > lobby them to get their packages updated to build from contrib, but
it'=
s
> > easier if it's just in there.=3D20
> >
> > Similarly, when I ask folks to configure with 'OpenLDAP HEAD' in the
> > short term, it is of course easier for me if everything is already in
> > place.=3D20
> >
> > But this is your project, not mine, and I am happy with whatever we
can
> > make work.=3D20
>=20
> Right now, along the lines illustrated by Howard, I've committed
> everything to contrib/slapd-modules/samba4.  You may need to tweak the
> Makefile if you are not building in the source tree (as I usually do; the=
n
> adjust LDAP_BUILD to your build tree), and if you wish to install modules
> in some specific place (prefix, exec_prefix, ldap_subdir).
>=20
> My medium term objective would be to have:
>=20
> - generally useful modules built-in (e.g. slapo-deref)
>=20
> - Samba4-specific modules all in one contrib directory, possibly
> harmonized and consolidated when possible in a single module, to ease
> configuration and maintenance
>=20
> The latter could then have a specific configure, if needed, so that
> packagers could make and install them as easily as possible.  In the
> meanwhile, we should live with this interim solution.  Time permitting, I
> see no issue in maintaining that code, much like we already do with the
> other modules.

Can you give me the exact commands I need to put into the wiki, for a
user to go from a checkout of OpenLDAP, to a build with this module
installed just like all the others?

Thanks,

--=20
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

--=-GJES2Ff4FHn/Nl+ftOBF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQBLznxIz4A8Wyi0NrsRAl6mAJ4+rykBiTBAhn3ANiDgEfc8dG1OAgCghGeg
ycx5bF3Vlb1Yx3OMwa3p13k=
=XUh6
-----END PGP SIGNATURE-----

--=-GJES2Ff4FHn/Nl+ftOBF--



Followup 26

Download message
Date: Wed, 21 Apr 2010 06:37:02 +0200 (CEST)
Subject: Re: ITS#6055
From: masarati@aero.polimi.it
To: "Andrew Bartlett" <abartlet@samba.org>
Cc: openldap-its@openldap.org
> Can you give me the exact commands I need to put into the wiki, for a
> user to go from a checkout of OpenLDAP, to a build with this module
> installed just like all the others?

Assuming one builds in the tree,

- follow instructions for anonymous CVS checkout of HEAD branch
  <http://www.openldap.org/software/repo.html#AnonCVS>

- cd contrib/slapd-modules/samba4

- edit Makefile if needed; as it is, it assumes you build in tree,
  and installs in /usr/local/libexec/openldap

- make; make install

- in slapd.conf:

    modulepath /usr/local/libexec/openldap
    moduleload rdnval.la

    # ...
    database hdb
    # ...

    overlay rdnval

That's it.

p.


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org