On Thursday 30 September 2004 22:39, Kurt Gramlich wrote: > * Petter Reinholdtsen <[EMAIL PROTECTED]> [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
