From j.barber at dundee.ac.uk Thu Nov 8 12:46:11 2007 From: j.barber at dundee.ac.uk (Jonathan Barber) Date: Thu, 8 Nov 2007 12:46:11 +0000 Subject: [Fedora-directory-devel] Plugin questions Message-ID: <20071108124610.GK14340@flea.lifesci.dundee.ac.uk> I'm having a look (again) at writing a couple of plugins, the aspects I'm interested in are: 1) Updating samba hashes when an entries userpassword is updated (both through the password extop and LDAP replace/add) 2) Automatically generating posixGroup memberUid attributes from an entry of objectclass groupOfUniquenames and the DNs refered to by the uniqueName attributes of the entry. For the password updating, I've looked at the passwd_exop plugin (out of curiosity, why is it not in the plugin directory heirarchy?), and it'd be nice to piggyback on it, allowing the passwd_extop plugin to deal with determining whether or not the connection is secure, generating a new password if required, and for my plugin not to change the samba hash until the userPassword has been succesfully changed. Obviously, I'd need to also implement a postop plugin to catch straight modifies as well. With some experimentation, it appears possible to have two plugins for the same extop OID, but is there a way for the extop plugins to specify order of operation (the PDF plugin manual suggests not on page 50, but then later suggest alphabetical ordering may be possible, and later says that SLAPI_PLUGIN_(START|CLOSE)_FN functions are ordered)? Or, is it better to implement as a entry store plugin and look modifications to the userpassword attribute (assuming that at that point the etxop must have worked and the password isn't hashed at this point)? The post op plugins don't seem to see operations of extops, is this designed behaviour? Assuming there is a way of wrapping the existing password-exop plugin, to generate the hashes I was thinking of taking the SMB hashing algorithims from samba and wrapping them in a shamelessly stolen pwdstorage type plugin and then using slapi_encode(). Is this sane? For the posixGroup generation, I've prototyped the idea with a postop computed attribute - which appears to work okay, but means that searches for entries containing a particular memberUid doesn't work, i.e.: $ ldapsearch -b "cn=test,o=base" memberuid dn: cn=test,o=base memberuid: foo $ ldapsearch -b "cn=test,o=base" "(memberuid=foo)" $ Looking at the cos plugin, it seems to use virtual attributes, and this looks like a better approach. If so, is there any documentation on virtual attributes and their interface apart from the code and the vattrsp_template plugin (and the cos/roles/presence plugins)? What are good methods for triggering virtual attributes on an entry (assuming that you don't want to apply it to all the entries): tag the entries with a particular objectclass? Provide search filters in the plugin config that define the objects? Thanks for your assistance. -- Jonathan Barber High Performance Computing Analyst Tel. +44 (0) 1382 386389 From rmeggins at redhat.com Thu Nov 8 15:23:37 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 08 Nov 2007 08:23:37 -0700 Subject: [Fedora-directory-devel] Plugin questions In-Reply-To: <20071108124610.GK14340@flea.lifesci.dundee.ac.uk> References: <20071108124610.GK14340@flea.lifesci.dundee.ac.uk> Message-ID: <473329F9.7030002@redhat.com> Jonathan Barber wrote: > I'm having a look (again) at writing a couple of plugins, the aspects > I'm interested in are: > > 1) Updating samba hashes when an entries userpassword is updated (both > through the password extop and LDAP replace/add) > This has already been done as part of the freeipa.org project. It also does Kerberos. I don't know how hard it would be to just use it for Samba, but probably much easier than writing from scratch. > 2) Automatically generating posixGroup memberUid attributes from > an entry of objectclass groupOfUniquenames and the DNs refered to > by the uniqueName attributes of the entry. > > For the password updating, I've looked at the passwd_exop plugin > (out of curiosity, why is it not in the plugin directory heirarchy?), > It was not designed as a plugin. I don't know why. > and it'd be nice to piggyback on it, allowing the passwd_extop plugin to > deal with determining whether or not the connection is secure, > generating a new password if required, and for my plugin not to change > the samba hash until the userPassword has been succesfully changed. > > Obviously, I'd need to also implement a postop plugin to catch straight > modifies as well. > > With some experimentation, it appears possible to have two plugins for > the same extop OID, but is there a way for the extop plugins to specify > order of operation (the PDF plugin manual suggests not on page 50, but > then later suggest alphabetical ordering may be possible, That might work. > and later says > that SLAPI_PLUGIN_(START|CLOSE)_FN functions are ordered)? > This is different. The start/close functions have explicit dependencies i.e. many plugins depend on the database, so the dependency mechanism makes sure the database plugin is started before the plugins that depend on the database. But this is _only_ for start/close functions, not for general extop/preop/postop use. > Or, is it better to implement as a entry store plugin and look > modifications to the userpassword attribute (assuming that at that point > the etxop must have worked and the password isn't hashed at this point)? > > The post op plugins don't seem to see operations of extops, is this > designed behaviour? > Yes. In the context of a plugin, the "op" in pre-op or post-op means an LDAP ADD, MODIFY, DELETE, or MODDN operation. Pre means before the operation touches the database (i.e. for filtering) and post means after the operation has completed the database operations (both success and failure) - usually like a "trigger" in an SQL sense. And extended operation may modify the database, but it will have to explicitly handle any pre or post handling, or simply provide another plugin to handle the pre/post actions, or write a plugin of type "object" that can be an extop plugin and a pre-op and a post-op. > Assuming there is a way of wrapping the existing password-exop plugin, > to generate the hashes I was thinking of taking the SMB hashing > algorithims from samba and wrapping them in a shamelessly stolen > pwdstorage type plugin and then using slapi_encode(). Is this sane? > > For the posixGroup generation, I've prototyped the idea with a postop > computed attribute - which appears to work okay, but means that searches > for entries containing a particular memberUid doesn't work, i.e.: > > $ ldapsearch -b "cn=test,o=base" memberuid > dn: cn=test,o=base > memberuid: foo > > $ ldapsearch -b "cn=test,o=base" "(memberuid=foo)" > $ > > Looking at the cos plugin, it seems to use virtual attributes, and this > looks like a better approach. If so, is there any documentation on > virtual attributes and their interface apart from the code and the > vattrsp_template plugin (and the cos/roles/presence plugins)? > In order to support searches, you'll also have to provide an indexing plugin, to create a virtual "index" for your virtual attribute. This is what the Roles plugin does - roles is a virtual attribute provider that provides the "nsRole" attribute - it also provides the ability to do searches like this - (nsRole=cn=myrole,dc=example,dc=com) See also the source code for the presence plugin. > What are good methods for triggering virtual attributes on an entry > (assuming that you don't want to apply it to all the entries): tag the > entries with a particular objectclass? Provide search filters in the > plugin config that define the objects? > It just depends. Any/all of these may be good for your particular situation. Search filters give you more flexibility, but you will have to make sure the attributes you use in your search filters are indexed. > Thanks for your assistance. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From j.barber at dundee.ac.uk Thu Nov 8 18:42:51 2007 From: j.barber at dundee.ac.uk (Jonathan Barber) Date: Thu, 8 Nov 2007 18:42:51 +0000 Subject: [Fedora-directory-devel] Plugin questions In-Reply-To: <473329F9.7030002@redhat.com> References: <20071108124610.GK14340@flea.lifesci.dundee.ac.uk> <473329F9.7030002@redhat.com> Message-ID: <20071108184251.GA21018@flea.lifesci.dundee.ac.uk> On Thu, Nov 08, 2007 at 08:23:37AM -0700, Richard Megginson wrote: > Jonathan Barber wrote: > >I'm having a look (again) at writing a couple of plugins, the aspects > >I'm interested in are: > > > >1) Updating samba hashes when an entries userpassword is updated (both > > through the password extop and LDAP replace/add) > > > This has already been done as part of the freeipa.org project. It also > does Kerberos. I don't know how hard it would be to just use it for > Samba, but probably much easier than writing from scratch. Wow, that looks like an exciting project. Looks like they have an eye on dealing with the memberuid stuff as well. What's the relationship between the freeipa and fds projects, will we see their plugins packaged into fds? > >2) Automatically generating posixGroup memberUid attributes from > > an entry of objectclass groupOfUniquenames and the DNs refered to > > by the uniqueName attributes of the entry. > > > > >For the password updating, I've looked at the passwd_exop plugin > >(out of curiosity, why is it not in the plugin directory heirarchy?), > > > It was not designed as a plugin. I don't know why. > >and it'd be nice to piggyback on it, allowing the passwd_extop plugin to > >deal with determining whether or not the connection is secure, > >generating a new password if required, and for my plugin not to change > >the samba hash until the userPassword has been succesfully changed. > > > >Obviously, I'd need to also implement a postop plugin to catch straight > >modifies as well. > > > >With some experimentation, it appears possible to have two plugins for > >the same extop OID, but is there a way for the extop plugins to specify > >order of operation (the PDF plugin manual suggests not on page 50, but > >then later suggest alphabetical ordering may be possible, > That might work. Hmm, is there a way of disabling the existing password exop from the server config then, so if I use the freeipa plugin, I can stop the existing password exop from interfering, or is that overly paranoid? I ask, as disabling the plugin by recompiling the main server gives me the willies for deploying into a production service. > >and later says > >that SLAPI_PLUGIN_(START|CLOSE)_FN functions are ordered)? > > > This is different. The start/close functions have explicit dependencies > i.e. many plugins depend on the database, so the dependency mechanism > makes sure the database plugin is started before the plugins that depend > on the database. But this is _only_ for start/close functions, not for > general extop/preop/postop use. > >Or, is it better to implement as a entry store plugin and look > >modifications to the userpassword attribute (assuming that at that point > >the etxop must have worked and the password isn't hashed at this point)? > > > >The post op plugins don't seem to see operations of extops, is this > >designed behaviour? > > > Yes. In the context of a plugin, the "op" in pre-op or post-op means an > LDAP ADD, MODIFY, DELETE, or MODDN operation. Pre means before the > operation touches the database (i.e. for filtering) and post means after > the operation has completed the database operations (both success and > failure) - usually like a "trigger" in an SQL sense. > > And extended operation may modify the database, but it will have to > explicitly handle any pre or post handling, or simply provide another > plugin to handle the pre/post actions, or write a plugin of type > "object" that can be an extop plugin and a pre-op and a post-op. > >Assuming there is a way of wrapping the existing password-exop plugin, > >to generate the hashes I was thinking of taking the SMB hashing > >algorithims from samba and wrapping them in a shamelessly stolen > >pwdstorage type plugin and then using slapi_encode(). Is this sane? > > > >For the posixGroup generation, I've prototyped the idea with a postop > >computed attribute - which appears to work okay, but means that searches > >for entries containing a particular memberUid doesn't work, i.e.: > > > >$ ldapsearch -b "cn=test,o=base" memberuid > >dn: cn=test,o=base > >memberuid: foo > > > >$ ldapsearch -b "cn=test,o=base" "(memberuid=foo)" > >$ > > > >Looking at the cos plugin, it seems to use virtual attributes, and this > >looks like a better approach. If so, is there any documentation on > >virtual attributes and their interface apart from the code and the > >vattrsp_template plugin (and the cos/roles/presence plugins)? > > > In order to support searches, you'll also have to provide an indexing > plugin, to create a virtual "index" for your virtual attribute. This is > what the Roles plugin does - roles is a virtual attribute provider that > provides the "nsRole" attribute - it also provides the ability to do > searches like this - (nsRole=cn=myrole,dc=example,dc=com) > See also the source code for the presence plugin. > >What are good methods for triggering virtual attributes on an entry > >(assuming that you don't want to apply it to all the entries): tag the > >entries with a particular objectclass? Provide search filters in the > >plugin config that define the objects? > > > It just depends. Any/all of these may be good for your particular > situation. Search filters give you more flexibility, but you will have > to make sure the attributes you use in your search filters are indexed. That's what I thought, just wanted to make sure there wasn't a canonical best practise way of doing things. > >Thanks for your assistance. > > -- Jonathan Barber High Performance Computing Analyst Tel. +44 (0) 1382 386389 From rmeggins at redhat.com Thu Nov 8 19:08:04 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 08 Nov 2007 12:08:04 -0700 Subject: [Fedora-directory-devel] Plugin questions In-Reply-To: <20071108184251.GA21018@flea.lifesci.dundee.ac.uk> References: <20071108124610.GK14340@flea.lifesci.dundee.ac.uk> <473329F9.7030002@redhat.com> <20071108184251.GA21018@flea.lifesci.dundee.ac.uk> Message-ID: <47335E94.3040507@redhat.com> Jonathan Barber wrote: > On Thu, Nov 08, 2007 at 08:23:37AM -0700, Richard Megginson wrote: > >> Jonathan Barber wrote: >> >>> I'm having a look (again) at writing a couple of plugins, the aspects >>> I'm interested in are: >>> >>> 1) Updating samba hashes when an entries userpassword is updated (both >>> through the password extop and LDAP replace/add) >>> >>> >> This has already been done as part of the freeipa.org project. It also >> does Kerberos. I don't know how hard it would be to just use it for >> Samba, but probably much easier than writing from scratch. >> > > Wow, that looks like an exciting project. Looks like they have an eye on > dealing with the memberuid stuff as well. > > What's the relationship between the freeipa and fds projects, will we see > their plugins packaged into fds? > freeipa will support using fedora ds as its ldap backend We will probably incorporate their plugins into fedora ds at some point. > >>> 2) Automatically generating posixGroup memberUid attributes from >>> an entry of objectclass groupOfUniquenames and the DNs refered to >>> by the uniqueName attributes of the entry. >>> >>> >>> For the password updating, I've looked at the passwd_exop plugin >>> (out of curiosity, why is it not in the plugin directory heirarchy?), >>> >>> >> It was not designed as a plugin. I don't know why. >> >>> and it'd be nice to piggyback on it, allowing the passwd_extop plugin to >>> deal with determining whether or not the connection is secure, >>> generating a new password if required, and for my plugin not to change >>> the samba hash until the userPassword has been succesfully changed. >>> >>> Obviously, I'd need to also implement a postop plugin to catch straight >>> modifies as well. >>> >>> With some experimentation, it appears possible to have two plugins for >>> the same extop OID, but is there a way for the extop plugins to specify >>> order of operation (the PDF plugin manual suggests not on page 50, but >>> then later suggest alphabetical ordering may be possible, >>> >> That might work. >> > > Hmm, is there a way of disabling the existing password exop from the > server config then, so if I use the freeipa plugin, I can stop the > existing password exop from interfering, or is that overly paranoid? > > I ask, as disabling the plugin by recompiling the main server gives me > the willies for deploying into a production service. > I'm not sure. Take a look at what the freeipa guys have done. > >>> and later says >>> that SLAPI_PLUGIN_(START|CLOSE)_FN functions are ordered)? >>> >>> >> This is different. The start/close functions have explicit dependencies >> i.e. many plugins depend on the database, so the dependency mechanism >> makes sure the database plugin is started before the plugins that depend >> on the database. But this is _only_ for start/close functions, not for >> general extop/preop/postop use. >> >>> Or, is it better to implement as a entry store plugin and look >>> modifications to the userpassword attribute (assuming that at that point >>> the etxop must have worked and the password isn't hashed at this point)? >>> >>> The post op plugins don't seem to see operations of extops, is this >>> designed behaviour? >>> >>> >> Yes. In the context of a plugin, the "op" in pre-op or post-op means an >> LDAP ADD, MODIFY, DELETE, or MODDN operation. Pre means before the >> operation touches the database (i.e. for filtering) and post means after >> the operation has completed the database operations (both success and >> failure) - usually like a "trigger" in an SQL sense. >> >> And extended operation may modify the database, but it will have to >> explicitly handle any pre or post handling, or simply provide another >> plugin to handle the pre/post actions, or write a plugin of type >> "object" that can be an extop plugin and a pre-op and a post-op. >> >>> Assuming there is a way of wrapping the existing password-exop plugin, >>> to generate the hashes I was thinking of taking the SMB hashing >>> algorithims from samba and wrapping them in a shamelessly stolen >>> pwdstorage type plugin and then using slapi_encode(). Is this sane? >>> >>> For the posixGroup generation, I've prototyped the idea with a postop >>> computed attribute - which appears to work okay, but means that searches >>> for entries containing a particular memberUid doesn't work, i.e.: >>> >>> $ ldapsearch -b "cn=test,o=base" memberuid >>> dn: cn=test,o=base >>> memberuid: foo >>> >>> $ ldapsearch -b "cn=test,o=base" "(memberuid=foo)" >>> $ >>> >>> Looking at the cos plugin, it seems to use virtual attributes, and this >>> looks like a better approach. If so, is there any documentation on >>> virtual attributes and their interface apart from the code and the >>> vattrsp_template plugin (and the cos/roles/presence plugins)? >>> >>> >> In order to support searches, you'll also have to provide an indexing >> plugin, to create a virtual "index" for your virtual attribute. This is >> what the Roles plugin does - roles is a virtual attribute provider that >> provides the "nsRole" attribute - it also provides the ability to do >> searches like this - (nsRole=cn=myrole,dc=example,dc=com) >> See also the source code for the presence plugin. >> >>> What are good methods for triggering virtual attributes on an entry >>> (assuming that you don't want to apply it to all the entries): tag the >>> entries with a particular objectclass? Provide search filters in the >>> plugin config that define the objects? >>> >>> >> It just depends. Any/all of these may be good for your particular >> situation. Search filters give you more flexibility, but you will have >> to make sure the attributes you use in your search filters are indexed. >> > > That's what I thought, just wanted to make sure there wasn't a > canonical best practise way of doing things. > > >>> Thanks for your assistance. >>> >>> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From j.barber at dundee.ac.uk Thu Nov 8 19:19:27 2007 From: j.barber at dundee.ac.uk (Jonathan Barber) Date: Thu, 8 Nov 2007 19:19:27 +0000 Subject: [Fedora-directory-devel] Plugin questions In-Reply-To: <47335E94.3040507@redhat.com> References: <20071108124610.GK14340@flea.lifesci.dundee.ac.uk> <473329F9.7030002@redhat.com> <20071108184251.GA21018@flea.lifesci.dundee.ac.uk> <47335E94.3040507@redhat.com> Message-ID: <20071108191927.GB21018@flea.lifesci.dundee.ac.uk> On Thu, Nov 08, 2007 at 12:08:04PM -0700, Richard Megginson wrote: > Jonathan Barber wrote: > >On Thu, Nov 08, 2007 at 08:23:37AM -0700, Richard Megginson wrote: > > > >>Jonathan Barber wrote: > >> > >>>I'm having a look (again) at writing a couple of plugins, the aspects > >>>I'm interested in are: > >>> > >>>1) Updating samba hashes when an entries userpassword is updated (both > >>> through the password extop and LDAP replace/add) > >>> > >>> > >>This has already been done as part of the freeipa.org project. It also > >>does Kerberos. I don't know how hard it would be to just use it for > >>Samba, but probably much easier than writing from scratch. > >> > > > >Wow, that looks like an exciting project. Looks like they have an eye on > >dealing with the memberuid stuff as well. > > > >What's the relationship between the freeipa and fds projects, will we see > >their plugins packaged into fds? > > > freeipa will support using fedora ds as its ldap backend > > We will probably incorporate their plugins into fedora ds at some point. [snip] > >Hmm, is there a way of disabling the existing password exop from the > >server config then, so if I use the freeipa plugin, I can stop the > >existing password exop from interfering, or is that overly paranoid? > > > >I ask, as disabling the plugin by recompiling the main server gives me > >the willies for deploying into a production service. > > > I'm not sure. Take a look at what the freeipa guys have done. I did, they don't seem to do anything. [snip] -- Jonathan Barber High Performance Computing Analyst Tel. +44 (0) 1382 386389 From rmeggins at redhat.com Fri Nov 9 15:01:42 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 09 Nov 2007 08:01:42 -0700 Subject: [Fedora-directory-devel] Plugin questions In-Reply-To: <20071108191927.GB21018@flea.lifesci.dundee.ac.uk> References: <20071108124610.GK14340@flea.lifesci.dundee.ac.uk> <473329F9.7030002@redhat.com> <20071108184251.GA21018@flea.lifesci.dundee.ac.uk> <47335E94.3040507@redhat.com> <20071108191927.GB21018@flea.lifesci.dundee.ac.uk> Message-ID: <47347656.1080601@redhat.com> Jonathan Barber wrote: >>> Hmm, is there a way of disabling the existing password exop from the >>> server config then, so if I use the freeipa plugin, I can stop the >>> existing password exop from interfering, or is that overly paranoid? >>> >>> I ask, as disabling the plugin by recompiling the main server gives me >>> the willies for deploying into a production service. >>> >>> >> I'm not sure. Take a look at what the freeipa guys have done. >> > > I did, they don't seem to do anything. > https://hosted.fedoraproject.org/projects/freeipa/browser/ipa-server/ipa-slapi-plugins/ipa-pwd-extop Do you mean you've seen this code and you can't figure out where they disable the existing passwd_extop code? > [snip] > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From geykel at gmail.com Fri Nov 9 22:02:01 2007 From: geykel at gmail.com (Geykel Raul Moreno Ceballos) Date: Fri, 9 Nov 2007 17:02:01 -0500 Subject: [Fedora-directory-devel] Fedora Directory Server and AzMan Message-ID: <3aa18a480711091402k61d2a3bbm8b9a47ba5db612f7@mail.gmail.com> Hello, I wanted to know if there is any feature on Fedora Directory Server similar to Microsoft Authorization Manager "AzMan" or if you're planning to do something like that... -- Regards, Geykel Raul _________________________ It claims to be fully automatic, but actually you have to push this little button here. ?Gentleman John Killian -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.barber at dundee.ac.uk Mon Nov 12 10:51:50 2007 From: j.barber at dundee.ac.uk (Jonathan Barber) Date: Mon, 12 Nov 2007 10:51:50 +0000 Subject: [Fedora-directory-devel] Plugin questions In-Reply-To: <47347656.1080601@redhat.com> References: <20071108124610.GK14340@flea.lifesci.dundee.ac.uk> <473329F9.7030002@redhat.com> <20071108184251.GA21018@flea.lifesci.dundee.ac.uk> <47335E94.3040507@redhat.com> <20071108191927.GB21018@flea.lifesci.dundee.ac.uk> <47347656.1080601@redhat.com> Message-ID: <20071112105149.GD21018@flea.lifesci.dundee.ac.uk> On Fri, Nov 09, 2007 at 08:01:42AM -0700, Richard Megginson wrote: > Jonathan Barber wrote: > >>>Hmm, is there a way of disabling the existing password exop from the > >>>server config then, so if I use the freeipa plugin, I can stop the > >>>existing password exop from interfering, or is that overly paranoid? > >>> > >>>I ask, as disabling the plugin by recompiling the main server gives me > >>>the willies for deploying into a production service. > >>> > >>> > >>I'm not sure. Take a look at what the freeipa guys have done. > >> > > > >I did, they don't seem to do anything. > > > https://hosted.fedoraproject.org/projects/freeipa/browser/ipa-server/ipa-slapi-plugins/ipa-pwd-extop > > Do you mean you've seen this code and you can't figure out where they > disable the existing passwd_extop code? I looked at the version from: http://freeipa.com/downloads/devel/sources/freeipa-admintools-0.4.1.tgz And couldn't see anything, but then I only starting looking at the FDS code a week ago. Cheers. -- Jonathan Barber High Performance Computing Analyst Tel. +44 (0) 1382 386389 From rmeggins at redhat.com Mon Nov 12 14:33:36 2007 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 12 Nov 2007 07:33:36 -0700 Subject: [Fedora-directory-devel] Plugin questions In-Reply-To: <20071112105149.GD21018@flea.lifesci.dundee.ac.uk> References: <20071108124610.GK14340@flea.lifesci.dundee.ac.uk> <473329F9.7030002@redhat.com> <20071108184251.GA21018@flea.lifesci.dundee.ac.uk> <47335E94.3040507@redhat.com> <20071108191927.GB21018@flea.lifesci.dundee.ac.uk> <47347656.1080601@redhat.com> <20071112105149.GD21018@flea.lifesci.dundee.ac.uk> Message-ID: <47386440.3080806@redhat.com> Jonathan Barber wrote: > On Fri, Nov 09, 2007 at 08:01:42AM -0700, Richard Megginson wrote: > >> Jonathan Barber wrote: >> >>>>> Hmm, is there a way of disabling the existing password exop from the >>>>> server config then, so if I use the freeipa plugin, I can stop the >>>>> existing password exop from interfering, or is that overly paranoid? >>>>> >>>>> I ask, as disabling the plugin by recompiling the main server gives me >>>>> the willies for deploying into a production service. >>>>> >>>>> >>>>> >>>> I'm not sure. Take a look at what the freeipa guys have done. >>>> >>>> >>> I did, they don't seem to do anything. >>> >>> >> https://hosted.fedoraproject.org/projects/freeipa/browser/ipa-server/ipa-slapi-plugins/ipa-pwd-extop >> >> Do you mean you've seen this code and you can't figure out where they >> disable the existing passwd_extop code? >> > > I looked at the version from: > http://freeipa.com/downloads/devel/sources/freeipa-admintools-0.4.1.tgz > > And couldn't see anything, but then I only starting looking at the FDS > code a week ago. > Ok. The ipa pwd extop plugin does work. If you have any questions about it, you should ask the freeipa guys. > Cheers. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Nov 15 02:05:56 2007 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 14 Nov 2007 19:05:56 -0700 Subject: [Fedora-directory-devel] Please review: Bug 383301: Admin Server main html page refers to dsgw, org Message-ID: <473BA984.9010507@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=383301 Resolves: bug 383301 Bug Description: Admin Server main html page refers to dsgw, org Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Introduce a new directive - INCLUDEIFEXISTS. This will include the html file specified if it exists, or just skip it if not found. When dsgw, org, etc. are ready, we can just plug in the appropriate html file. Platforms tested: RHEL5 x86_64 Flag Day: no Doc impact: no QA impact: should be covered by regular nightly and manual testing New Tests integrated into TET: none https://bugzilla.redhat.com/attachment.cgi?id=259221&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Nov 19 15:21:29 2007 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 19 Nov 2007 08:21:29 -0700 Subject: [Fedora-directory-devel] Please review: Bug 388021: MMR breaks from master that has been reinited Message-ID: <4741A9F9.1000404@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=388021 Resolves: bug 388021 Bug Description: MMR breaks from master that has been reinited Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: This problem occurs when you have two or more masters, and you have updates that have originated at a master that have been sent to other masters (so that the other masters have a valid min/max csn for that replica in the ruv). If that master needs to be reinitialized for some reason (crash, etc.) the reinit will erase the changelog. The RUV for that master will now contain CSNs that are not in the changelog. If that master attempts to update another master, it will first look at the RUV from the consumer, which will contain the old CSNs, and it will look for those CSNs in the changelog, fail, and abort the update process, meaning this master can no longer send updates to other servers. The solution is for the master to just use the min CSN in its own RUV as the new starting point, if it has not been purged. In the case of purging, if the CSN is not found, this means the consumer is too far behind and must be reinitialized. Platforms tested: RHEL5 x86_64 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=263531&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Tue Nov 27 05:00:50 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 27 Nov 2007 16:00:50 +1100 Subject: [Fedora-directory-devel] Re: LDAP/Samba 4 summary In-Reply-To: <1191349969.4226.36.camel@localhost.localdomain> References: <1191349969.4226.36.camel@localhost.localdomain> Message-ID: <1196139650.3147.53.camel@naomi> On Tue, 2007-10-02 at 11:32 -0700, Andrew Bartlett wrote: > (please forgive the cross-posting to subscriber-only lists) > > Howard Chu helpfully wrote up this summary of the meeting we held at the > CIFS Workshop on how Samba4 should work with an LDAP backend. > > The background is that Samba4 increasingly needs some things that an > LDAP server could provide for us. In the short term, we need to add > subtree renames to ldb_tdb, but OpenLDAP's hdb already provides this for > us. Just as an update, I've implemented this, and linked attributes (another thing we discussed at the CIFS workshop) in Samba4, for ldb_tdb. This does however bring up the issue of linked attributes in LDAP backends. Linked attributes include member/memberOf, master/masteredBy and many others. They are defined in the AD schema, and as far as I know, are strictly updated as a pair (they are not flattened memberOf listings, for example). Linked attributes and subtree renames are closely linked - if you don't support subtree renames, then handling linked attributes on the Samba side is easy - the LDAP server remains 'dumb' about it. As I understand it (corrections welcome), Fedora DS is not likely to handle subtree renames soon, so this approach will work for Samba4 on Fedora DS. However, for Samba4 on OpenLDAP, we will want to have the LDAP backend handle subtree renames. Has there been any work to handle memberOf in OpenLDAP? How does this interact with subtree renames? Any other thoughts? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ando at sys-net.it Tue Nov 27 06:25:50 2007 From: ando at sys-net.it (Pierangelo Masarati) Date: Tue, 27 Nov 2007 07:25:50 +0100 Subject: [Fedora-directory-devel] Re: LDAP/Samba 4 summary In-Reply-To: <1196139650.3147.53.camel@naomi> References: <1191349969.4226.36.camel@localhost.localdomain> <1196139650.3147.53.camel@naomi> Message-ID: <474BB86E.3030200@sys-net.it> Andrew Bartlett wrote: > Has there been any work to handle memberOf in > OpenLDAP? How does this interact with subtree renames? There's a slapo-memberof(5) overlay in 2.4 that maintains cross links (a la memberOf) for usual update operations. It lacks some consistency check (like creating missing links if the overlay is switched on on an already existing database) and probably doesn't handle subtree renames (need to check). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati at sys-net.it ---------------------------------------