[horde] passwd H4 polishing for release - Requirements and directions?

[Ralf Lang]

Am Donnerstag, 9. Juni 2011, 20:23:00 schrieb Eric Jon Rostetter:
> Quoting Ralf Lang <lang at b1-systems.de>:
> > I've been toying around with the unreleased passwd from git.
> 
> Thanks.  Are you submitting back to git?

The changes are already in git.
http://git.horde.org/horde-git/-/browse/passwd/?ws=1

> 
> > For its main purpose, changing the user's horde account pw, passwd
> > doesn't need to be a separate app (as said in the roadmap).
> 
> Yes, but I would hope we could keep it doing more than just that.

Me too. 
 
> > But passwd is/was more generic and could be configured to change any
> > password in a given infrastructure independent of Horde. Such a feature
> > should be a separate app and not live somewhere under options or
> > preferences. This could evolve into a generic password/credentials
> > manager but is a completely different story.
> 
> And an interesting one, though I'm not sure who if anyone would want to
> work on it (so it may never happen).

I had done some work out of tree for re-implementing eleusis from cvs.
This has just stalled because there were more urgent tasks. 

> > I am not sure what is needed for a proper passwd H4 3.2 release but
> > I've found
> > 
> > the following items:
> >  * convert the ldap backend to Horde_Ldap
> >  * Make sure the composite backend uses the injector instead of the base
> > 
> > class' factory method
> > 
> >  * remove that method
> >  * make sure things like Horde_Vfs are included via injector
> 
> Would certainly be a good start (and work for me, since I use it with the
> ldap backend).

We are currently using it with the hordeauth backend, and hordeauth is 
actually ldap. SQL has also been tested. 
 * TODO: Add horde_test unit tests to passwd.


> > I think I could basically do that before H4.1 but passwd ships a lot of
> > backends and I doubt I can build the infrastructure to test them all
> > properly.
> 
> If you have horde, sql, and ldap complete, it could probably ship.  We
> could see about removing some of the older, less used drivers too.
> Others could be released if we at least think they should work, and we
> can fix bugs with them as they are reported.  horde/sql/ldap should
> cover most people...  Be nice if composite worked too, but probably not
> a show stopper.  The kolab folks could probably help get the kolab driver
> working.  I'd certainly not be opposed to dropping some drivers (like
> pine, servuftp, etc) and shipping with untested ones (like expect,
> procopen, vpopmail, vmailmgr, etc).  As long as we have some well tested
> popular ones together (sql, ldap, etc).

[..]

> Some could just be dropped (until someone wants to pay for them?).  

Sure - open source does not mean people shouldn't pay for special needs.


> The plan has been to drop/integrate it for 4-5 years now, and I don't
> think anyone has started yet.  So I would say, if we can, we should
> maintain it as-is until someone at least starts the integrate it with the
> intent of replacing it.  So I would say we should indeed try to port it.

Yes. Anything released and tested and official is better than people grabbing 
git snapshots for production and horde not officially having a password change 
utility.

> 
> > Any comments welcome.
> 
> I can help later this year, but I've got a June 20th deadline to meet which
> is consuming 110% of my time right now (and will probably continue to take
> 50% of my time for a while after the deadline).  So I might be able to help
> with this come mid/late July...

Meanwhile I can see how far I get.

-- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang at b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537