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