Re: More on the future LDAP admin gui in Debian Edu
Hi all,
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.
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.
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).
[...]
> 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).
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
-- ...
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 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?
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).
Ok, so much (!) for now. Please add comments/ideas and fix missing
bits!
Regards,
Andi
Reply to: