Re: More on the future LDAP admin gui in Debian Edu
Hello,
On Fri, Oct 22, 2010 at 04:38:13PM +0200, Petter Reinholdtsen wrote:
> [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.
Can you give an argument why it is a bad idea for the majority of
schools in your belief?
> 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.
The ldap access rules defined in slapd.conf are completely independent
of the unix 'access rules'. For example the user admin doesn't even
exist as a posix user, but has full access to the ldap tree. However,
lwat associates rules depending of posix group membership, and they
allow to make sure that a (posix group) 'jadmin' cannot change the
password of a (posix group) 'admin'.
GOsa does not use the access ruling defined in slapd.conf, but defines
a completely independent access policy. It is possible to associate
access rules with posix group membership, but as far as I know, it is
not possible to limit the access depending on the posix group
membership of the object that's going to be changed (someone should
check that). The GOsa access rules will not be available to any other
software like ldapsearch, ldapadd, etc. (It would need to be
especially made to use the information saved within ldap and used by
GOsa).
To sum up: it doesn't help or hinder any other ldap tool what we
define as ldap access rules for GOsa. We talk about different things.
The only valid argument to stick with the historic rules (or better said
their names) is to give the user the same names which, in my opinion
is not worth it. Because of the different implementation, there will
not be a 1-to-1 mapping anyway. (Perhaps using the same name is even a
bad idea because it will not be the same).
[...]
>
> > 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.
As I tried to explain above, the problem of a teacher being able to
change pupils' passwords but not his colleagues one is not solved
trivially with posix groups and a flat structure.
What I learned about ldap: It is a good idea to map the structure of
your organization, enterprise or in our case school within the
structure of the ldap tree. Why not use it that way? Sure you can list
all users that are members of a posix group in GOsa and remove them,
but why not handling them in a department and mark them all together
to put them in a posix group? I don't understand why to limit
ourselves to the flat structure, in my opinion it simply makes no
sense. Sure there is no "need". There's no "need" for graphical tools
at all, but they make information and structures visible and easier to
work with.
> > 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.
>
I don't know. I have and will not have too much time the next months,
and if it turns out that this is a "wash me but don't make me
wet"-thing, a temprory fill in made imping from the beginning or a
partial rewrite of GOsa, maybe it's better to wait for the tool that
does not change anything at all.
Regards,
Andi
Reply to: