Logged in as guest
Viewing Development/6055 Full headers
Major security issue: yes no
Notes: a proposed overlay is available 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
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 -----------------------------------
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--
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 -----------------------------------
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.
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 -----------------------------------
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.
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.
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--
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--
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
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.
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.
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 ---
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. > >
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--
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.
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--
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.
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--
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.
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/
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.
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--
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.
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--
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.
______________ © Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org
