Re: Comments on the "Skolelinux - User Requirements·Specification"
On Thursday 30 September 2004 22:39, Kurt Gramlich wrote:
> * 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/requirementsSpec
> >ification.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
In germany it is often a ko criteria for skolelinux because we are not able to
integrate a skolelinux in an existing ip range / netmask.
I had this situation several times in the past I tried to introduce
skolelinux.
Have a look at SUSE open school server, IMHO there you can see how this can be
done in a very smart way.
>
> > > 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.
And there are some of this huge schools who are interested in skolelinux.
Whithout an automated installation they will use SUSE open school server who
offers an automated 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 :-(
It is not a must.
It is a don't use skolelinux if not implemented!
So I agree whith Kurt, its a _MUST_ for german authorities.
Nevertheless it is a pain in the ass to keep blacklists up to date. :-P
> 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.
This might be a feature which can be done by ILIAS.
It offers to set up a forum which comes quite close to how pupils are using
news.
And this function is integrated in a powerfull e-leraning environment which in
my eyes is a win win for us to have.
>
> > > 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 ;-)
We should have a closer look to ILIAS.
This is _exactly_ what ILIAS offers.
>
> 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.
I most all parts of DE, precisely I don't know a region yet where this is not
a must.
>
> > 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.
Nevertheless I will get flamed, but autoyast is much better for what we are
looking for.
>
> > 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.
Tschüss,
TT
Reply to: