Re: Comments on the "Skolelinux - User Requirements Specification"
Hi Petter,
thanks from me, too, for reviewing this translation.
Am Donnerstag, 30. September 2004 21:10 schrieb Petter Reinholdtsen:
...
>
> > An administrator should be able to install an uninterruptable power
> > supply (UPS) easily.
>
> Eh, yes. But how is this related to Skolelinux?
This, indeed, reads like: An admin must have the skills to ... Easy to set up
UPS is the core of the message, I think.
>
> > 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.
Call for expert modus, which is there, on the one hand, more variable settings
(like internet IP 10.0.2.1) on the other.
>
> > 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.
This is the point. There might be some "mature student" group as well as a
"junior admin" group, as well. Think about differentiate even logging and
squid filters...
> >
> > 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.
CVS is enough if you can choose the separator and assign the columns meaning
(well done in wlus)
> >
> > -------------------------------------------------------------------------
> >--- 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.
It's now the attic.
>
> > 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?
In the first place, something like [k]df could be on central position in
webmin. Then, of course, I wish to control, what eats up my disc space. [x]du
and the like can analyse, what folders / users are most consuming, some
additional scripts can determine special file types that need more space than
necessary (wav, bmp, raw, ... )
>
> > 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.
shouldn't be too hard for groups, if we mean to give allowance to specific
groups (pupils don't use the teacher's color xerox! - kidding, we don't have
one). more tricky to set up the default printer depending on user / machine.
>
> > 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?
Mh, rather have a central "kill all print jobs" button. At our place, I
disconnect our print box + printer for few secs, then mostly the buffer is
empty.
>
> > 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.
very true. either use disconnected single work stations (laptops w/o wlan!) or
control all actions (running processes included)
> > 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?
a) importing user data
b) individual setup of services including their IP's and domain names.
>
> > Chapter 3. Server services
>
> [...]
>
> > The use of the preconfigured services should be configureable for
> > each user.
> What does this mean?
who can use mail, news, chat? configure by classes rather than by user
>
> > 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.
logging can easily be done by replacing IPs in squid's log by the name of the
user that is currently logged in there. It _must_ be possible to lock the web
for my class room when it is not needed for the very task I put. (Other rooms
are independend). This is meant by machine-wide.
Teachers and adult pupils need no surfing filters, hence we need a user (or
group) based filtering.
>
> > 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.
sftp, rsync?
>
> > 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'?
well, who can explain? it is a mail provider for schools. personally I am very
much against giving all pupils email addresses like username@schoolname that
are valid beyond the school.
>
> > 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.
how about some local news server (intranet)?
>
> > 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'?
eh, sounds funny, right, the maximum size that the contents of the user's home
may have = 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
> > configurable.
>
> Dito.
quota for transfer folders that are commonly usable for one class/group each.
>
> > 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?
Mh, maybe, never used such function.
>
> > 3.8. Wiki
> >
> > For group work a Wiki should be available.
rather: installable
> > -------------------------------------------------------------------------
> >-- 3.9. The forum
> >
> > A forum (portal) should be available.
>
> Not sure if we want to include this in Debian-Edu.
there is too point in this: apache's start page (tjener.intern/
= /var/www/index.html) _should_ be a skolelinux page that informs new users
about the system and links to further tutorials.
A literal web forum / learning platform like plone, sTeam, moodle, whatsoever,
should be easy to install / set up.
>
> > 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.
for this I'd need some slight instructions, myself :)
>
> What about a school administrative system to keep track of pupils,
> teachers and schedules?
who' where you mean?
>
> 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).
this is a technical issue, but at the same time it is user related in terms of
hardware aquiration.
how about having more than one tjener (at remote schools) that sync their user
data (don't mention users' homes).
Regards
Ralf
Reply to: