[Fedora-directory-devel] Plugin questions

[Richard Megginson]

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: <http://listman.redhat.com/archives/fedora-directory-devel/attachments/20071108/627acab1/attachment.bin>