[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Comments on the "Skolelinux - User Requirements·Specification"



* Petter Reinholdtsen <pere@hungry.com> [040930 20:59]:

> 
> Hi, Kurt.
> 
> I finally found time to read through <URL:
> <URL:http://developer.skolelinux.no/qualityManagement/DQ/requirementsSpecification.html.en>.
> Sorry for taking so long.  I am glad you put the doc in CVS, as I'm
> reading this offline. :)

i am happy, that you now read it ;-)
> 
> Here are some comments.
> 
> > 2.1.1. Easy standard install
> 
> > ...means that the input to be types in is reduced to only the really
> > necessary. Hardware detection and Installation on the hard drive
> > (partitioning, formatting, installation) should as automatically as
> > possible.
> 
> I agree.
> 
> > An administrator should be able to install an uninterruptable power
> > supply (UPS) easily.
> 
> Eh, yes.  But how is this related to Skolelinux?

Some Linuxserver have a little tool to administrate the UPS. I
think there is an debian packet to connect UPS via serial
interface so that the server automaticly shut down, if the
energie reserve is going to finish.



> > 2.1.2. Flexible manual install
> 
> > For advanced users, it should be possible to install Skolelinux
> > manually, for instance to integrate Skolelinux in an existing
> > network.
> 
> What does this mean?  I see at least two possible in interpretations.
> (1) make it possible to install only subsets of skolelinux into a
> machine (ie pick the services you want) and (2) make it possible to
> customize the configuration of the skolelinux services.  Please
> elaborate.

The (2). Often here are existing IP Networks and it would
be good, if it is possible to customize the configuration


> > 2.1.4. User administration
> > 
> > Every user should get an account. Every user should get only the
> > needed rights. The principle of the minimum user rights should be
> > followed.
> 
> Not sure about if this is the principle we want to follow.  Empowering
> the user might be a interesting principle as well.  Personally, I
> believe it i simportant for an educational environment to place as few
> constrains as possible on the posibility of learing.  On the other
> hand, we need to make sure the possibilities don't make it possible to
> compromise the security of the system.  I believe it is good to make
> sure everyone take responsibility for their own acts, and limit the
> damage they can do while experimenting.  This is part of the reason I
> believe it is important to have individual users on the system.  This
> will limit the damage they can do to their own configuration (at least
> that should be the goal).  It will also make sure they know they are
> not anonymous while using the system (the login process reminds them
> of this).
perhaps there are also other means to empower users.

In the adult education i need root acounts for every pupil, so i
think about to merge the nice features of FAI fully automated
installation and skolelinux. In a tutorial with Thomas Lange i
lerned about FAI. If we get a school with about 50 workstations
to install, i dont want to do this with CD and sneakers ;-).
With FAI it is possible to switch in very short time the
installation.

> 
> > The user-rights have at least to be differentiated between
> > administrator, teacher and pupils.
> > 
> > A further differentiation into project leader, project groups and
> > subject teacher through the user administration has to be possible.
> >
> > Userdata from every popular school administration program should be
> > importable.
> > 
> > ----------------------------------------------------------------------------
> > 2.1.5. Administration of user accounts
> >
> > Administration of user accounts should be customized to the special
> > requirements of the school-types. All users should be able to change
> > their own password. Privileged teachers should be able to change
> > pupils passwords.
> >
> > The account data should be easily updateable at every new school year.
> >
> > When removing user accounts, it should be possible to save the user
> > data for a limited time.
> 
> I agree.  These features are planned implemented in Cerebrum.
> 
> > 2.1.6. Monitoring the disk usage
> >
> > It should be possible to get an clear overview of the used disk space.
> 
> Do you mean in total or per user?

The quota things we mean, per user. AFAIK it is installed but not
activatet.

> > 2.1.7. Controlling the print server
> >
> > It should be possible to specify which user may access which
> > printer. The selection of several printers should be possible. It
> > should be possible to assign one user the right to disable and
> > enable printers, as well as stopping and deleting printer jobs. Each
> > user should be able to delete its own printing jobs.
> 
> I agree that this would be nice.  Not sure how much of this is covered
> by CUPS and how much would need to be implemented.

Lot of schools in Germany looking this features. As Kurt Pfeifle
said, it is possible, if only Linux is in use for printing.

> > It should be possible to configure that the printing jobs of a user
> > are removed when logging off.
> 
> That was an interesting idea.  Not sure if I like it.  During my
> university days, I often sent a document to the printer, logged out
> and headed to the printer to wait for the printout and run out of the
> room.  Why do you want this?

The Teachers told me: teaching time ended, pupils away, some
problems with printers, next teacher is coming, solving the
printer problem in classroom and a lot of paper is wastet by
printing out losed jobs.

> > 2.1.8. Examination/tests environment
> >
> > During examinations / tests, it should be possible to easily prevent
> > any communication between pupils.
> 
> I suspect this will make the system almost unusable, so I have more
> belief in making sure all communcation is prohibited, and make a
> system to detect communication between pupils.  This way the rules are
> clear, and the danger of being detected if one tries to break the
> rules are near and clear.  I believe this is more likely to succeed
> then a solution where there is an arms race between the pupils and the
> system.  The system will loose that race.

I agree, but there exist useable solution. Oure friends from
Linuxmusterloesung in the South of germany having experience with
a system the showed to me. AFAIK the are using one time accounts
with now internet connections and only the teacher knows the
password. then they deliver the tasks and after the test the
collect the results. i think it is useable. AFAIK Andreas knows
exactly, what they have built.

> > 2.2. Backup of data
> >
> > It should be possible to make both complete and differential backups.
> 
> Yes, and it should be possible to recover both individual files (per
> user) and complete machines (for the sysadmin) fairly easy .
> 
> > 2.7. Migration
> >
> > Replacing existing Windows, Novell and Linux servers should be possible.
> 
> What does this mean?

We (especially Patrick) has done a lot to get that ready. Now it
is able to take a Arktur Schoolserver and migrate to skolelinux.
It is now in WLUS possible, to import the extracted account,
userdata, password from Arktur. Arktur is the widly spreaded
Linux Schoolserver in Germany (some people said 5000 schools).

There are also other Servers, like the Novell Maschines. The
Idea in the talks with the Linux Musterloesung friends was, to
help the Novell Server based Schools to migrate to skolelinux.


> 
> > Chapter 3. Server services
> [...]
> > The use of the preconfigured services should be configureable for
> > each user.
> 
> What does this mean?

That is so too general, i had to look in the collected papers.

> 
> > 3.1. Internet access
> >
> > It should be possible to allow and disallow access to the Internet
> > based on the room, PC or user.
> >
> > Access to unwanted websites should be deniable. Maintainance of the
> > filters should be easy.
> >
> > During classes, it should be possible to monitor the active
> > surfing. It should also be possible to log all surfing activity.
> 
> This sounds nice, but I'm not convinced it is possible to garantee
> this.  I suspect an arms race here too, where one try to close holes
> while the pupuils find new ways to penetrate the access control.

I understand, but it is a must in germany :-(
So we are working on this:
we first use a blacklist and a whitlist, checked by squid.
Often this is enough, because the most important bad websides are
not accessible. The pupil lerns this and the dont not try to find
new ways.
Hilaire has build a debian packet which updates the blacklist
from a server of the university of Toulouse. He uses squid and
squidguard.
Benedikt Wildenhain from skolelinux.de is now working on a packet
with the features:
different blacklist servers
automatic update from there
configurable cronjob therefore
all configurable within a webside similar to WLUS.


> > 3.2. The local web-server
> >
> > The local web-server should let all users present static and dynamic
> > web-pages. After the responsible teacher has checked the individual
> > web-pages, it should be possible to make them publicly available.
> >
> > It should be possible to upload specified web-pages to an external
> > web-server using a encrypted connection.
> 
> Interesting idea with a split/duplicate publishing system.  Not sure
> if there are any existing systems providing this.

ack.
If a bin asked, i propose to use an externel webserver for the
school website. And then produce the homepage on tjener and scp
it to the external server.


> 
> > 3.3. The email-server
> >
> > The email-server should provide local and external email. The rights
> > should be configureable through the user administration. It should
> > be possible to integrate a virus scanner. For use in the German
> > speaking parts of the world, an interface to the Winshuttle service
> > should exist.
> 
> What is the winshuttle service?  What do you mean with 'the rights'?

The right to email only intern or extern should be configurable.

Winshuttle is a widly spreaded service for schools. The offering
a email excange service. Mostly they use UUCP for emailtransport.

The Arktur, GEE and SuSE Server having this feature.


> > 3.4. The news-server
> >
> > A local news-server should provide selected news groups. The write-
> > and read-access should be configureable through the user
> > administration.
> 
> Debian-edu do not provide a USENET news server.  It will probably
> never provide this.  Personally, I believe this is best left to
> external service providers, as the proper maintainence of a news
> server is quite high, and it is hard to install one out of the box.

Some Linux Schoolserver in Germany offers this Service and a
teacher decides, which news a subscribed.

> 
> > 3.5. The file-server
> > 
> > Every user should get their own directory. The size of the
> > directories should be configureable through the user administration.
> 
> What do you mean by 'the size of the directory'?

Quota

> > 3.5.1. Directories for exchanging files
> >
> > It should be possible to create directories for exchanging files
> > related to classes, rooms and projects. The maximum size should be
> > configurealbe.
> 
> Ditto.  (typo in 'configurealbe', I believe)

ack ;-)

Patrick has done this for my Institute of adult education
(Volkshochschule). Teacher like this feature, to spread
information, text, tables to the pupils and to collect the result
at the end of the teaching time.

> 
> > 3.5.2. Retrieve directory
> >
> > Here teachers, course- and project-leaders should be able to place
> > data for being picked up. Pupils should only have read-access to
> > this directory.
> > ----------------------------------------------------------------------------
> > 3.5.3. Delivery directory
> >
> > Here pupils should be able to deliver finished documents or
> > files. This directory should not be readable by other
> > pupils. Teachers should easily be able to fetch and move these
> > documents and files.
> 
> Hm, I suspect this feature would be better handled by a web based
> learning management system.  Any views on this?
Ditto


> > 3.8. Wiki
> >
> > For group work a Wiki should be available.
> > ---------------------------------------------------------------------------
> > 3.9. The forum
> >
> > A forum (portal) should be available.
> 
> Not sure if we want to include this in Debian-Edu.
ack, at the moment i think, this has not a high priority

If a teacher is able to install ... just apt-get install it.

BTW i think we should deliver the minimum on one cd and all
packets, which are not necessary has to be configured, we could
deliver on a second cd, if there is no or bad internet connection like
in africa.

> > Chapter 4. Documentation
> >
> > Documentation customized for the intended audience is required
> > indeed and is divided in an admin, a user manual and accompanying
> > material.
> 
> I agree that we need these books.  As far as I know, we have a draft
> of the admin doc, and some fragments of the educational material.
> 
i think we need at last for every packet which is used to
teaching purposes a good documention.

> Several of the services in Skolelinux are not mentioned at all.
> Keeping the clock on all machines synchronized might be mentioned.  A
> system for keeping track (for existance, upgrades, etc) of all
> installed machines, and a system to administrate several machines as
> one could be mentioned as well.
> 
Like FAI ;-)

> What about a school administrative system to keep track of pupils,
> teachers and schedules?

In some parts of Germany the school administrative system has to
be seperated from the teaching system.

> The document do not mention scalability issues at all.  I want
> Debian-Edu to work both in small (<10 work places) and large (>1000
> work places), and these put some constrains on how we can do things.
i agree, i would like to have FAI, it brings a automatic
documention about every computer, every packet isnatlled and so
on.

> I also want to make sure several installations can be administrated
> from one location (the document touces this slightly with the remote
> administratable clause in 2.5, but I believe this should be stressed
> some more).
>
ack.
We are in work to administrate 7 different schools from one
server in the internet; blacklist and whitelist, update and
upgrade, starting with easy things.


Thank you for looking at the user requirements. It is a very
small version, builded in discussions with about 30 teachers who
administrate Linux Servers for longer time in germany.

This user requirement specification needs to be updated.

Alexander Schmehl and I tested Venus against this requierments send the results
via email to Andreas some weeks ago. 

Regards/Viele Gruesse!
Kurt
-- 
kurt.gramlich@lugrav.de   GnuPG Key ID  0xE263 FCD4



Reply to: