Comments on the "Skolelinux - User Requirements Specification"
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. :)
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?
> 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.
> 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).
> 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?
> 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.
> 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?
> 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.
> 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?
> Chapter 3. Server services
[...]
> The use of the preconfigured services should be configureable for
> each user.
What does this mean?
> 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.
> 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.
> 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'?
> 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.
> 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'?
> 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)
> 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?
> 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.
> 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.
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.
What about a school administrative system to keep track of pupils,
teachers and schedules?
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 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).
Reply to: