Re: wlus / User Administration
Kurt wrote:
* Finn-Arne Johansen <faj@bzz.no> [050524 14:24]:
Halvor Dahl wrote:
Hello everyone.
SLX Debian Labs is starting a project for improving user
administration in Skolelinux/debian-edu in general and
wlus in particular. The background for the project is
mainly feedback from users.
In Summer 2003 we startet in Germany a intensive discussion about
the user requierement specification for a school server.
Based on the opinions of many German teachers the following
quality management paper was developed:
http://developer.skolelinux.no/qualityManagement/DQ/requirementsSpecification.html.en
Please have a look at 2.1.4 and 2.1.5 concerning user administration.
We would really like to see this taken into serious consideration.
Kurt,
thanks a lot for pointing out this document to me. The timing is perfect,
and we will certainly take it into serious consideration when writing out
the specifications.
We had a meeting in Oslo on this subject with Andreas
Schuldei, Ragnar Wisløff, Knut, Vidar and myself present.
What follows is based on conclusions from that meeting.
1. Problem with "junior admin" rights
-------------------------------------
This issue has been raised from (among others) Trond from
Kongsvinger. Password administration takes too much time,
and it should be possible to authorise users to change other
users' password.
Andreas told us that there is already a solution to this,
although it is not 100% packed and documented yet.
TODO: Ragnar will try the solution out in Kongsvinger and
report back to Halvor if it works or not. If it does work,
Andreas will complete a "read me" file or something for
documentation.
we fully agree, see 2.1.4
2. Password policy
------------------
We agreed that the first time a user logs in (with a pre-
defined password), he will get a message saying that the
password is expired and be requested to enter and confirm
a new password (this is similar to Windows). Whether this
feature will be configurable or not is not yet decided.
Why are you thinking this is necessary?
Will this feature not consume a lot of time and interrupt the lessons?
I hope not. The idea behind it is to distribute password administration
to the users to save time for administrators. In this way it will be
possible to allow users to select their own passwords (chances are they
will not as easily forget them!), and administrator can select appropriate
rules for password (minimum length, if it must contain digits, expiry time,
etc).
To avoid confusion - by "first time" I mean "first time ever" and not
"first time every day".
Andreas told us that administration of password restrictions
(length, numbers etc) is already implemented in wlus, including
a user interface for administrator.
TODO: Andreas will check if pam in our setup can do this.
TODO: Andreas will check if kdm can be used to do the entering
and confirmation of a new password (it can be done in wlus).
Also check for samba users - Is the new password set in kde also set for
samba users. What about schools that uses Windows clients, and were
(some) students never would log into kde, but only use Windows
3. Mass import
--------------
Kongsvinger has reported a general problem doing mass import
of user data into ldap. Ragnar informed us this had to do
with the general poor performance in entering new users which
takes approximately 5 minutes per user(!). We do not know
at the moment the reason for the problem. Kongsvinger has
around 2700 users in their ldap database.
In our experience the time consuming factor is the copy process
for example the /etc/skel.
That is hereby noted.
TODO: Ragnar/Trond will try to increase the cache_size
parameter in the ldap config file. If that does not help,
they will try to install ldap 2.2 which should be 10-100
times faster than the current version in Kongsvinger (Andreas
told us that wlus is functioning together with ldap 2.2).
If that does not help, some serious debugging will need to be
done.
Update: Ragnar has tried to change parameters in ldap config
file and it did not work.
We made the same experiences.
For that amount of users, I would done this without wlus - as an ldif
instead. While this is possible to script, I know of few who has done
that. (I've lost my script - it was on Ulsrud, and the server is
reinstalled - sorry)
Of course ldif is faster, but without refinement of home
directories and without copying /etc/skel.
4. Other wlus problems
----------------------
There has been some general complaints about the user interface.
This will be addressed later in this summary. Apart from what
is already covered, there are no known major bugs in wlus.
But there is no good and updated user documentation.
TODO: Create a new user documentation for wlus. Person to do
it will be assigned later.
5. Data import
--------------
Knut and Halvor had a meeting with Morten Dahl who is the project
manager for FEIDE. Based on his recommendations we decided that
we would use the XML interface developed by Uninett ABC for importing
data from School Administration Systems (SAS). Further clarifications
will be done together with Uninett ABC.
Skolelinux will *not* use Cerebrum for anything.
Is Cerebrum dead?
May you please explain this in a more
detailed way?
I will get back with a detailed explanation on this when we start the FEIDE
integration project. The reasoning behind it is simply that we cannot
really
see what we need Cerebrum for. But there may be things we have overlooked.
If you disagree, please explain.
There are a number of different data formats for student data. Among
them are Microsoft Active Directory, Novell eDirectory and different
kinds of spreadsheets. In order to have a documented specification
we will use the same XML interface for transferring data from external
systems other than SAS.
TODO: Andreas will do what is necessary to support a new unique
key in ldap for data import. In Norway this will be "personnummer",
but the format will need to be generic.
Note - "Personnummer" is not unique in Norway - there are at least 4
instances of personnummer with more than 2 users. I have not yet heard
of 2 users with same name _and_ same "personnummer"
TODO: Write a program for importing data from XML interface to
Skolelinux' import format to ldap which is a comma/colon separated
file. Person to do it will be assigned later.
Please consider also German systems.
We will. Andreas has already pointed this out.
6. Data export
--------------
There are a number of systems that may need to import data from
Skolelinux. Examples are LMSs like ClassFronter, It's Learing!
and Micrsoft Learning Gateway. We decided to use Uninett ABC's
XML interface for User Administration Systems (BAS) for exporting
data from Skolelinux.
TODO: Write a program for downloading data from the Skolelinux
ldap database to Uninett ABC's XML format. Person to do it will
be assigned later.
Our export is ldif, the import filtering should be done by LMS or
M$.
Why is that? I want to be as flexible as possible, and I think that
all the LMS systems can read XML already. I am not too sure about ldif.
If Microsoft succeeds with Microsoft Learning Gateway (and they are
certainly trying hard!), I would like to have a smoothly working data
inteface between Skolelinux and Microsoft Learning Gateway.
7. Technical architecture
-------------------------
It was agreed that we need a three-tier application architecture
for user administration in Skolelinux to be able to support
different types of user interfaces. WebMin is probably not the
right tool, and we will decide on a new development framework
as part of the overall project. We will also create a new KDE
client covering all operations currently defined as use cases
in wlus.
TODO: Select development framework. Will be done later.
TODO: Create updated use cases as starting point for new KDE
interface and user documentation. Person to do it will be
assigned later.
Do we have to install KDE on tjener?
What about schools without KDE?
This will be one of several possible clients. If someone would like
to develope something for Gnome or whatever, the specifications will
be available.
TODO: Create new user administration interface in KDE. Person
to do it will be assigned later.
TODO: Write new business logic in a three-tier application
architecture. Person to do it will be assigned later.
We dont think that this is very usefull because of two reasons:
1) If it is not usable by browser, it is too unflexible
2) Develop a KDE Application will consume too much manpower
1) It will still be usable by browser.
2) Maybe it will take a lot of time, and maybe not. My plan is to
use some students we know who are good at this. I am not too
worried if we get our architecture right.
8. Project plan
---------------
SLX Debian Labs will propose a time schedule for the projsect
after decisions have been communicated to everyone involved and
reactions from users taken into account.
TODO: Make project plan for new user administration system in
Skolelinux. Person to do it will be assigned later.
Perhaps we should first fulfill the user requirement specification?
Of course, and the first draft is already completed. We will now take
a look at the document you referred to in your e-mail. The draft will
be posted on the relevant lists - probably next week.
Halvor
Reply to: