LDAP GUI roadmap proposal
Hi all,
there have been discussions on the list about perspectives for our
LDAP GUI (CIPUX, GOsa, LWAT, in alphabetical order ;-), or even
new programs). Stimulated by them, I would like to propose a way how to
proceed. As usual, this is my personal view and discussing the
arguments is appreciated.
First, let's consider the short term proceeding, target is the squeeze
release:
As soon as the GOsa packages manage to migrate from NEW to sid we put
them in our skolelinux repository to not have to wait for the 10 days
they need to travel to testing. This allows for immediate broader
testing the new GUI. If we are happy with the results, fine tuning can
be done.
Concerning the simplicity of the GUI I do not believe that it is
currently more complicated than what we know from LWAT, perhaps it's
even simpler. However, it is possible to configure the GUI within a
wide range: A sysadmin can use the full range of options, a teacher
with limited permissions is only offered the tasks he has permissions
to change, for example adding users. He will not be overwhelmed by
options he does not know of.
A draft configuration out of the box is already in place with
templates to add users: As it is the case in LWAT, you only have to
choose the template (teacher or student) add first name, family name
and password, and you are done.
Problems and missing bits:
There are two issues we might have to make some sort of compromise for
now. PowerDNS and Netgroups. GOsa uses bind as DNS server, we use
PDNS. There are activities to include PDNS into GOsa and/or make it
possible to use both with the same schema.
Concerning Netgroups, I wrote a draft patch to include them in GOsa:
<URL:http://lists.debian.org/debian-edu/2010/04/msg00124.html> (see
also the screen shot attached to that mail). If I understand
correctly, GOsa uses GOsa-si for tasks we use netgroups for, compare
<URL:https://oss.gonicus.de/pipermail/gosa/2010-May/004553.html> (which
also offers some insight in GOsa's possibilities we do not use now,
but might be interested in some day). However, we might even be able
to add the netgroup approach upstream, if we care:
<URL:https://oss.gonicus.de/pipermail/gosa/2010-May/004547.html>
Both issues will not be fixed for squeeze and we need some kind of
workaround, but I am optimistic that they can be solved for squeeze+1.
Now let me outline how I imagine the prosperous future :) of
debian-edu/skolelinux from squeeze+1 on:
Besides the system administration (which is in no way different from
how it is done in many institutions, and I therefore hope to profit
from larger development communities and their tools), debian-edu is
targeted for the special needs of schools.
This requires all the ideas CipUX with CATweasel tries to offer:
Pedagogic stuff, exam mode and much more. This is where we, as a
project, are really on our own. Nobody else needs these things,
and in my opinion we should focus our coding efforts on exactly that
issue.
I think it is fine to have a sysadmin tool like GOsa for system
administration. It will be used by teachers that have some affinity to
computers. They use it to setup the systems, add/remove users, groups,
systems and handle package installation, ... .
In addition, there is the day-to-day tool (say CATweasel here) which
every teacher uses to do the school specific stuff.
With this "dual approach" I hope we are able to provide and ship a
system in the long run that:
* can be used in a small school and works out of the box there
* is flexible and scalable enough to be easily used for larger
deployments (i.e. a town or district with many schools managed
centrally by a professional sysadmin).
Best regards,
Andi
Reply to: