[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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
