[Fedora-directory-devel] Plugin questions

[Jonathan Barber]

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