Re: More on the future LDAP admin gui in Debian Edu

[Petter Reinholdtsen <pere@hungry.com>]

[Andreas B. Mundt]
> So in my opinion, every teacher needs to be able to change/renew the
> password of a pupil. If only admins or jadmins can do that, they
> will not be available when needed (or every teacher will be jadmin,
> which you also don't want).

Some schools might want this, while others do not.  I believe it is a
bad idea to let all teachers change passwords of all pupils, and
suspect some schools agree with me.  I also believe it is a good idea
to control access using information visible from within unix, like
file groups, and not using information invisible from within unix,
like LDAP object position in the tree.

Why should not the schools that want all teachers to be able to change
the passwords of all pupils not be members of the jradmin grup?  The
jradmin group is supposed to give privileges to change passwords of
all non-admin non-jradmin users, which seem to be exactly what you
talk about.

I believe the correct solution for schools that want all teachers to
be able to change pupils passwords it to add all teachers to the
jradmin group.

> Another disadvantage of a flat tree is the following: If you have a
> school with 1000 pupils, every year about 100 of these pupils will
> leave the school. What happens to their accounts?

A common and sensible approach in use today, is to add all these 100
pupils to a group for their year when the accounts are created.  Then
it is trivial to remove these accounts when the pupils are done.
There is no need for a non-flat LDAP structure for this.

> The way back from structure to a flat, unstructured tree is easy,
> but please think about the prospects some more structure offers.

I believe all the "problems" you have sketched are trivially handled
using groups, and believe this is the best solution for our LDAP
structure.

> Main difference to our current setup: Bind instead of powerDNS.

Actually, we can continue to use powerDNS if we adjust GOsa to update
an extra attribute in the DNS tree.  See
<URL:http://article.gmane.org/gmane.comp.ldap.gosa/506> for the
details.

> I think the decision we have to take is: Do we want to continue
> using powerDNS (which means we cannot use the GOsa packages because
> they use bind, so we have to find a solution, hack something or
> whatever...) or can we switch to bind which should make most (if not
> all) of the tools we need available in the squeeze repositories. So
> if there are no grave arguments against bind I think that's the
> easier way to go.

I believe we want to continue to use a DNS server that look up
information directly in LDAP, to ensure that DNS changes done in LDAP
take effect imediately.  All the bind based solutions I have seen so
far uses regular exports from LDAP to files bind understands, causing
a delay until changes show up in DNS.  Because of this, I believe we
are better off by keeping PowerDNS.  And thus I believe a third option
- change GOsa to work with PowerDNS - is the best one.

Happy hacking,
-- 
Petter Reinholdtsen