Re: More on the future LDAP admin gui in Debian Edu
Le Friday 22 October 2010 16:07:50 Andreas B. Mundt, vous avez écrit :
> Hi all,
Hello,
> with regard to the replies to my mail, I conclude that we agree that
> for the time being it is best to focus on GOsa for squeeze. I hoped
> that we can get some consensus, which seems to be the case, at
> least when I look at the replies so far.
Cool
> Well, then let's start to have a look and discuss what needs to be
> done.
>
> On Thu, Oct 21, 2010 at 05:55:45PM +0200, Petter Reinholdtsen wrote:
> [...]
>
> > For the specific LDAP setup, I believe we should change our Gosa
> > setup to have a "flat" ldap directory (ie no students and teachers
> > subtrees), and use the traditional three levels of administrative
> > access (admin with full access, jr. admin with limited access and the
> > rest with no special privileges.
>
> The idea behind the structure I implemented so far (separated teacher-
> and student sub-trees) is the following:
>
> This structure allows the application of additional access rules. From
> my experience, students loose their password (and if you really force
> them not to loose it, they will either choose '123' and/or write it
> down. Both things you don't want to teach them). So there will be
> lectures where the students/pupils have to work at the machines, and
> in the frequent case one or two students will not be able to log in.
> You can say: 'Well that's not my problem', but depending on age and
> school it will become your problem, for example when your lecture is
> spoiled by these two pupils (they are not able to do anything now and
> look for interesting alternatives). Or when parents turn up and
> complain.
>
> 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).
>
> With the teacher and student sub-trees, every teacher can change
> every students password, but does not have access to change the
> one of his colleague.
+1
> It is no problem to change this and use a flat tree, but we waste
> usability that is available (and, at least in the schools I've seen so
> far, part of our competitors' systems).
no flat tree, is not a godd idea when you have lots of stuff
> [...]
>
> > With the flat structure and the three levels of access, we
> > have not tied ourself too tight to gosa and should be able to migrate
> > to other tools in the future, as well as making it possible for sites
> > to use other tools if they want to.
>
> 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? Currently we simply
> ignore this. It is something nobody cares about and, at least after
> some years, it will be the problem of the local sysadmin. What can he
> do? In the flat tree, he has to remove all the users that graduate
> every year. He has to work trough a list of names, search them in the
> flat tree and remove them. (I know that my sysadmin will prefer his
> windows system, when I try to convince him to use our system, but have
> to admit that he will have to do that job from now on).
+1
> So I suggest not only to have the student and teacher trees, but in
> addition have age-groups in the students-tree: Every year at
> school enrolment, a new organizational unit (subtree, called
> department in GOsa) is added, it contains all pupils that start now
> and will (with hopefully only a few exceptions) graduate x years
> later. After x+1 years, the whole department and the corresponding
> accounts can be deleted easily. In addition, if you want to add all
> pupils in this age-group to a posix group, it's easy to select them in
> that GOsa-department.
>
> We have that feature why not offer them to our users? I would also try
> to keep the structure flexible, i.e. allow also something like:
>
> students--yr2005--classA
> --classB
> --classC
> --yr2006--...
> --...
> --yr2007
> -- ...
Will look at the ldif you send me and make proposal from that, but this
one seems nice.
> I guess this or comparable structures are in use already in most
> schools. And if we want to be a serious alternative, we have to
> support some more structure than the flat tree, regardless of the tool
> we offer for administration. CipUX also uses much more structuring of
> the tree.
>
> The way back from structure to a flat, unstructured tree is easy, but
> please think about the prospects some more structure offers.
>
> Next issue:
> > I expect us to have to maintain our own set of gosa packages in our
> > own repository to get a version with support for netgroups and
> > kerberos and the other things that are missing. I also hope we can
> > get support for powerdns to avoid having to rewrite that part of the
> > server setup.
>
> I hope we do not need to maintain too much. The most important part
> currently missing is the machine management. First we need to integrate
> the services run by tjener into GOsa. I started with some testing a
> while back, the ldif is still in svn:
> <URL:http://svn.debian.org/wsvn/debian-edu/trunk/src/debian-edu-config/
>ldap-bootstrap/gosa-server.ldif> This looked promising, I used GOsa to
> define the services. Main difference to our current setup: Bind instead
> of powerDNS.
> 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 don't know power dns enough but i could look at it if needed. on the
other part the ldap -> bind flat files is working quite well. i use it on
dozen of production systems.
> I am also not sure how to "add machines". Perhaps Benoit can help us,
> iirc gosa-si (which is not available yet) will automatically show
> machines that are connected, so it's possible to add them if
> needed. Perhaps sitesummary, which also collects information about
> connected machines, can help us here and provide the functionality.
> Could it be possible that we do not need to add machines by hand?
> Can a user on a 'foreign' machine do any harm if we only allow to
> mount the home directory with nfs4 if the user has a valid kerberos
> ticket?
yep goto-si can do that, it can do arp request to find machine on the
network and provision it. i will have to look at this on your context
> Finally, as Petter pointed out, netgroups are missing. I hacked
> something a while ago
> <URL:http://lists.debian.org/debian-edu/2010/04/pngBXWKdbVux3.png> but
> to make it work properly, someone with php-knowledge is needed,
> although the patch seems not to be completely terrible:
> <URL:https://oss.gonicus.de/pipermail/gosa/2010-May/004547.html>
> It would then be possible to add the patched file during installation
> to have netgroups working. In the long run it might be also of
> interest for upstream (but I guess it needs some more stuff to edit
> netgroups, where we only want to use predefined ones for now).
i will discuss with cajus on how ot do that correctly but it think we
could integrate it more cleanly.
could you explain a bit further the netgroup use is this to apply
fonctions to the set of selected machines ?
> Ok, so much (!) for now. Please add comments/ideas and fix missing
> bits!
Cheers
--
Benoit Mortier
CEO
OpenSides "logiciels libres pour entreprises" : http://www.opensides.eu/
Promouvoir et défendre le Logiciel Libre http://www.april.org/
Contributor to Gosa Project : http://gosa-project.org/
Reply to: