ITIL-handleiding van Debian Edu / Skolelinux 16/07/2018


Inhoudsopgave

1. Kennisuitwisseling over gecentraliseerd beheer
2. Licentie
2.1. Dankwoord
2.2. Achtergrond
3. Uitbouw van de dienst
3.1. Servicedesk
3.1.1. Taken en functies
3.1.2. Verwachte tijdsinvestering
3.1.3. Checklist
3.2. Het beheer van incidenten
3.2.1. Checklist
3.2.2. Planning en uitvoering
3.2.3. Activiteiten die verband houden met operationele voorvallen
3.2.4. Functies
3.2.5. Kernaspecten
3.2.6. Hulpmiddelen
3.3. Probleembeheer
3.3.1. Procedures voor probleembeheer
3.4. Configuratiebeheer
3.4.1. Planning
3.4.2. Het beheer van Configuratie-Items (CI)
3.4.3. Planning en installatie
3.4.4. Checklist
3.4.5. Relaties met andere processen
3.4.6. Instrumenten voor configuratiebeheer
3.5. Wijzigingsbeheer
3.5.1. Activiteiten
3.6. Uitgavebeheer
3.6.1. Elementaire zaken
3.6.2. Programmatuurbibliotheek (Definitive Software Library - DSL)
3.6.3. Database voor configuraties en hardware
3.6.4. Bouwbeheer
3.6.5. Uittesten
3.6.6. Terugvaloptie
3.6.7. Voordelen en mogelijke problemen
3.6.8. Planning en uitvoering
3.6.9. Activiteiten
3.6.10. Hulpmiddelen
3.6.11. Relaties met andere processen
3.7. Hulpmiddelen voor operationele ondersteuning
3.7.1. Soort gereedschap
3.7.2. Evaluatiecriteria bij het selecteren van hulpmiddelen
3.7.3. Producttraining
3.8. Planning bij het begin van de implementatie van service-ondersteuning
3.8.1. Service-ondersteuning toepassen
3.8.2. Haalbaarheidsstudie
3.8.3. De huidige situatie omschrijven
3.8.4. Algemene richtlijnen voor projectplanning
3.8.5. Projectbeoordeling en rapportage
4. Dienstverlening
4.1. Dienstenniveaubeheer
4.1.1. Algemene checklist
4.1.2. Planning
4.1.3. Implementatie
4.1.4. The operational situation
4.1.5. Content of the Service Level Agreement (SLA)
4.2. Financial Management
4.2.1. Budgeting
4.2.2. Accounting
4.2.3. Planning the accounting and billing
4.2.4. Implementatie
4.2.5. Daily operation
4.3. Capacity Management
4.3.1. Monitoring
4.3.2. Analysis
4.3.3. Configuration
4.3.4. Implementatie
4.3.5. Preparing the capacity plan
4.4. Availability management
4.4.1. Availability measurements
4.4.2. Infrastructure
4.4.3. «Single points of failure»
4.4.4. Risk management
4.4.5. Uittesten
4.4.6. Design improvements
4.4.7. Planning for availability
4.4.8. Planning for recovery
4.5. Service Continuity
5. ICT Infrastructure Management
5.1. Design and planning
5.2. Deployment
5.2.1. Roles during roll-out
5.3. Operations
5.4. Configuration item
5.5. Technical support
6. A design and planning example
6.1. Background for the plan
6.2. What's expected of the ICT tools and services
6.3. Skills needs
6.4. Investments
6.4.1. Pupils
6.4.2. Teachers
6.4.3. Recommended technical development budget
6.4.4. Software, learning platforms, and services
6.4.5. Check list centralisation
6.4.6. Software
6.4.7. Learning platforms
6.4.8. Online services
6.5. Use of resources in operations
6.5.1. Operations' roles
6.5.2. Operation and support costs
6.6. Summary of the options
6.7. Recommendation
6.8. Attachment
7. Extra configurations
7.1. Simple firewall
7.2. Simple firewall with floppy (Coyote)
7.2.1. Solution 2 Create a Coyote Linux Floppy on a Windows machine
7.2.2. Exception handling
7.2.3. Verification
7.2.4. Update the configuration database
7.3. Simple firewall with CD
7.3.1. Solution
7.3.2. Exception handling
7.3.3. Verification
7.3.4. Update the configuration database
7.4. Starting the Coyote firewall
7.4.1. Solution
7.4.2. That is normal what is shown
7.4.3. Exception handling
7.4.4. Verification
7.4.5. Update the configuration database
7.5. Firewall administration through the browser (Coyote)
7.5.1. Exception handling
7.5.2. Verification
7.5.3. Update the configuration database
7.6. Firewall as a DHCP server (Coyote)
7.6.1. Verification
7.6.2. Update the configuration database
7.7. Coyote firewall and Internet operators
7.7.1. Exception handling
7.7.2. Verification
7.7.3. Update the configuration database
7.8. Support for network cards in the firewall
7.8.1. Exception handling
7.8.2. Verification
7.8.3. Update the configuration database
7.9. Particularly old network cards in the firewall (ISA)
7.9.1. Exception handling
7.9.2. Verification
7.9.3. Update the configuration database
7.10. Useful links about the Coyote firewall
7.10.1. Exception handling
7.10.2. Verification
7.10.3. Update the configuration database
7.11. Config:
7.11.1. Solution
7.11.2. Exception handling
7.11.3. Verification
7.11.4. Update the configuration database
8. Setting up infrastructure
8.1. Network architecture
8.1.1. Solution
8.1.2. Exception handling
8.1.3. Verification
8.1.4. Update the configuration database
8.2. Server profiles
8.2.1. Combi-server as a combined resolution
8.2.2. Description of the profiles in Skolelinux/Debian-Edu
8.2.3. Solution
8.2.4. Exception handling
8.2.5. Verification
8.2.6. Update the configuration database
8.3. Hardware servers
8.3.1. Solution
8.3.2. Exception handling
8.3.3. Verification
8.3.4. Update the configuration database
8.4. Client computers
8.4.1. Table of client types
8.4.2. Solution
8.4.3. Exception handling
8.4.4. Verification
8.4.5. Update the configuration database
8.5. Switches
8.5.1. Solution
8.5.2. Exception handling
8.5.3. Verification
8.5.4. Update the configuration database
8.6. Wireless access points
8.6.1. Solution
8.6.2. Exception handling
8.6.3. Verification
8.6.4. Update the configuration database
8.7. Firewall(s)
8.7.1. Solution
8.7.2. Exception handling
8.7.3. Verification
8.7.4. Update the configuration database
8.8. Routers
8.8.1. Solution
8.8.2. Exception handling
8.8.3. Verification
8.8.4. Update the configuration database
8.9. Setting up a simple firewall
8.9.1. Solution
8.9.2. Exception handling
8.9.3. Verification
8.9.4. Update the configuration database
8.10. Setup:
8.10.1. Solution
8.10.2. Exception handling
8.10.3. Verification
8.10.4. Update the configuration database
9. Useful commands
9.1. Support for 4 GB memory <-- included in configuration management
9.1.1. Exception handling
9.1.2. Verification
9.1.3. Update the configuration database
9.2. Administrating packages (apt-get)
9.2.1. Exception handling
9.3. Update the package archive
9.3.1. Exception handling
9.3.2. Verification
9.4. Update to new packages
9.4.1. Warning
9.4.2. Exception handling
9.4.3. Verification
9.5. Summary of installed packages
9.6. Find the name of a particular package
9.7. Show available information about packages
9.8. Installation of packages
9.9. Removal of installed packages
9.10. Install a specific package version
9.11. Install a package using dpkg
9.12. Search through files in a package
9.13. Find which package a file came from
9.14. Unpackaging files from a package without installing the package
9.15. Make your own package mirror
9.16. Secure login to the firewall (ssh)
9.16.1. Exception handling
9.16.2. Verification
9.16.3. Update the configuration database
9.17. Status summary for the firewall (Coyote)
9.18. Next
9.18.1. Exception handling
9.18.2. Verification
9.18.3. Update the configuration database
9.19. Last
9.19.1. Exception handling
9.19.2. Verification
9.19.3. Update the configuration database
10. Appendix A - Contract on operating Debian Edu / Skolelinux
10.1. CONTRACT ON OPERATING DEBIAN EDU / SKOLELINUX
10.1.1. Appendix 1 - Definitions
10.1.2. Appendix 2 - Customer Obligations
10.1.3. Appendix 3 - The Vendor's obligations
10.1.4. Appendix 4 - Prices and terms of payment
10.1.5. Appendix 5 - General provisions
10.1.6. Appendix 6 - Contacts and addresses

1. Kennisuitwisseling over gecentraliseerd beheer

Kleine organisaties zijn in de praktijk afhankelijk van individuen en zijn daarom kwetsbaar als iemand vertrekt. Een gedetailleerd en kwaliteitsvol handboek voor systeembeheer is dus essentieel om in de operationele praktijk stabiliteit en continuïteit te kunnen garanderen. Het Programma voor Digitale Geletterdheid heeft als eerste objectief een aantal aanbevolen praktijken en richtlijnen te ontwikkelen die scholen en onderwijsinstellingen stabiliteit en voorspelbaarheid kunnen bieden, zodat computers, netwerken en basisdiensten behoorlijk functioneren.

Het ITIL-boek bevat op "goede praktijken" gebaseerde richtlijnen die toegespitst zijn op gemeenten die gebruik maken van vrije software zoals Skolelinux, om gecentraliseerde netwerken te laten functioneren die verschillende scholen bedienen. Deze richtlijnen zijn aangepast voor gemeentelijke en regionale bestuurlijke centra. Veel gemeenten beschikken slechts over een deeltijdse functie die instaat voor de ICT van de scholen. Noorwegen telt meer dan 300 kleine en middelgrote gemeenten. Gewoonlijk beschikt iedere gemeente over 1-4 voltijdse ICT-medewerkers. Het delen van expertise en ervaringen onder interventiediensten is daarom voor iedereen van essentieel belang.

2. Licentie

Dit document is geschreven onder versie 3 van de GNU General Public License (GNU Algemene Publieke Licentie). Dit houdt in dat u

  • het recht heeft om deze documentatie voor elk doeleinde te gebruiken (Recht 0).

  • het recht heeft om deze documentatie te bestuderen en aan uw behoeften aan te passen (Recht 1).

  • het recht heeft kopieën ervan door te sturen zodat u uw buur kunt helpen (Recht 2).

  • het recht heeft dit document te verbeteren en het met uw aanpassingen publiek te verspreiden, zodat de hele gemeenschap ervan kan genieten (Recht 3).

Deze rechten worden op Wikipedia toegelicht. Torgeir Kielland van de rechtsfaculteit van de universiteit van Bergen heeft de GNU-licentie en de Copyleft-bepalingen onderzocht. Hij stelt dat de GNU-licentie inzake copyright toepasbaar is. Kort samengevat betekent dit dat u alles uit dit document naar eigen goeddunken kunt gebruiken. U moet er wel voor zorgen dat uw eigen bijdragen ook onder een Algemene Publieke Licentie geplaatst worden.

2.1. Dankwoord

Velen hebben aan deze documentatie bijgedragen. Ze werd hoofdzakelijk door Knut Yrvin en Andreas Johansen geschreven met veel bijdragen van Klaus Ade Johnstad. Halvor Dahl van Skolelinux Drift AS behoort tot de commissie en heeft verschillende bijdragen geleverd op het vlak van structuur, vormgeving en inhoud. Daarnaast werden ook bijdragen geleverd door Snorre Løvås, UNINETT ABC, door Finn-Arne Johansen van BzzWare AS, door Ragnar Wissløff van LinuxLabs AS en door de stuurgroep, die meewerkten aan het realiseren van de documentatie. De volgende personen maakten deel uit van de stuurgroep:

  • Monica Larssen - gemeente Harstad

  • Aksel Celasun - gemeente Hurum

  • Trond Mæhlum - gemeente Kongsvinger

  • Bjarne Nielsen - gemeente Nittedal

  • Stein Lier - district Akershus

Deze documentatie wordt in een wiki onderhouden. Het doel ervan is ervoor te zorgen dat interventiemedewerkers gemakkelijk oplossingen voor problemen kunnen vinden, configuratie-instellingen kunnen aanpassen, enzovoort.

Raadpleeg de copyright-pagina voor de copyrightstatus van dit document.

http://www.gnu.org/copyleft/gpl.html

2.2. Achtergrond

Het Programma voor Digitale Competentie was Het ICT-plan van het Noorse ministerie van onderwijs voor de jaren 2004-2008. Een van de doelstellingen ervan was een aantal aanbevolen operationele praktijken en passende richtlijnen te ontwikkelen. Dit moet scholen en onderwijsinstellingen stabiliteit en voorspelbaarheid bieden, zodat computers, netwerken en basisdiensten behoorlijk functioneren. Operationele oplossingen dienen aangepast te zijn aan de grootte en de behoeften van de instellingen.

Deze documentatie bevat richtlijnen, gebaseerd op praktijken die op maat zijn van ICT-diensten van gemeenten en districten. Ze kan ook toegepast worden door commerciële ondernemers. Veel gemeenten hebben slechts een deeltijdse medewerker ter beschikking voor het operationeel houden van de computernetwerken van scholen. Slechts 13% van alle gemeenten van Noorwegen heeft meer dan 20.000 inwoners en 73% van de gemeenten heeft minder dan 10.000 inwoners. Gewoonlijk beschikt een gemeentelijke administratie over 1-4 voltijdse ICT-medewerkers. Voor de scholen staat meestal slechts een deeltijdse ICT-functie ter beschikking, die het beheer heeft over ongeveer 500-800 client-computers in 5-10 scholen met ongeveer 1700-3200 studenten en leerkrachten die van het systeem gebruik maken.

Deze documentatie is ook voor grotere organisaties bruikbaar. Ze is gebaseerd op de ISO 20000 standaard voor ICT-interventies, die ook gekend is als de Information Technology Infrastructure Library (ITIL). Raadpleeg Wikipedia voor meer informatie over de standaard zelf: http://en.wikipedia.org/wiki/ITIL

De eerste editie van dit document werd voltooid op 19 juli 2006.

Dit document wordt in een wiki onderhouden en kan bijgewerkt worden op https://wiki.debian.org/!DebianEdu/Documentation/nb/ITIL. De vorige versie is te vinden op http://developer.skolelinux.no/itil/oldindex.html

Dit document werd vanaf maart 2015 naar het Engels vertaald met behulp van https://www.transifex.com/projects/p/itil-revitalization/.

3. Uitbouw van de dienst

Zoals in de inleiding aangegeven, is het aangeraden om te beginnen met het opzetten van een centrale interventiedienst, zodat u de orders kunt beheren. Dit biedt snel voordelen die bovendien zichtbaar zijn, hetgeen belangrijk is voor de klanten- en gebruikerstevredenheid.

Eens de dienst geïnstalleerd en operationeel is, en er een redelijke werkorganisatie is in verband met de orders (de verzoeken van gebruikers en het oplossen van problemen), begint u aan de grootste uitdaging voor de organisatie. Veelal betreft het ofwel het aanpakken van veranderingen of het oplossen van problemen. Organisaties met "cowboy-achtige" systeembeheerders, die slimme ideeën spuien en deze beginnen toe te passen zonder ze veel uit te testen, beginnen vaak bij het doorvoeren van veranderingen. Voor organisaties die geconfronteerd worden met het feit dat de systemen geregeld uitvallen, zal probleemoplossing op de eerste plaats komen.

Wat u ook kiest om mee van start te gaan, telkens zal een zekere hoeveelheid configuratiebeheer nodig zijn. Configuratiebeheer is cruciaal in het ter beschikking stellen van de gebruiker van software en diensten. Software moet volgens de verwachtingen functioneren. Om voordelige aanpassingen te kunnen realiseren, moet men kennis hebben van de configuratie van de verschillende programma's.

Voor het beheer van de aanpassingen aan de configuratie, kunt u gebruik maken van een databank (Configuration Management Data Base (CMDB)). Weinigen gebruiken een databank voor alle configuraties en u moet alle configuraties ook niet in één enkele databank samenbrengen. Het is goed om configuraties in verschillende kleinere en deels onafhankelijke depots op te slaan. Sommige mensen plaatsen bijvoorbeeld configuraties en instellingen onder versiecontrole. Maar ook al gebruikt u verschillende depots, dan nog kunt u betere resultaten bereiken met het koppelen van informatie uit de verschillende processen.

Voor de gebruikers van Debian Edu bevindt de configuratie van de meeste diensten zich in een specifieke map (/etc). Het kan een voordeel bieden als die configuratiegegevens bijgehouden en opgeslagen worden in een centrale map die onder versiecontrole staat. Dit maakt het makkelijker om uitgevallen diensten te herstellen en om computers die opnieuw geïnstalleerd worden, in te stellen. Dit geldt zowel voor servers als voor laptops van gebruikers of werkstations. Het maken van een reservekopie van de configuratiemap /etc maakt deel uit van het back-upsysteem van Debian Edu. Dit back-upsysteem is echter niets anders dan een databank of een onder versiecontrole geplaatste map met configuraties.

3.1. Servicedesk

De servicedesk is de plaats waar gebruikers vragen stellen of problemen rapporteren. Vaak stuurt de ICT-contactpersoon van een school interventierapporten naar de servicedesk. Er kunnen ook verzoeken zijn zoals een nieuwe PC installeren of een programma installeren.

Op de school vormt de ICT-contactpersoon de verbinding met de servicedesk. De ICT-contactpersoon beantwoordt ook de meest voorkomende vragen. Sommige vragen zijn te moeilijk om opgelost te worden binnen elke school apart en moeten doorgestuurd worden naar de servicedesk. Het is belangrijk dat er een goed contact is tussen de ICT-contactpersoon van de school en de servicedeskmedewerkers. Taken die te uitgebreid zijn of te moeilijk om lokaal opgelost te worden moeten doorgegeven worden aan de servicedesk.

Gebruikers kunnen ook rechtstreeks antwoord krijgen van een servicedeskmedewerker. Alle interventieaanvragen gaan naar de servicedesk. Aanvragen krijgen een volgnummer toegewezen. Iedereen die een aanvraag indient, krijgt een e-mail ter bevestiging dat de aanvraag ontvangen werd. Gedurende de behandeling van de zaak kunnen de ermee belaste servicedeskmedewerkers de gebruiker statusupdates sturen.

Op deze manier hebben gebruikers één contactpunt en krijgen de medewerkers van de servicedesk een overzicht over alle problemen. Tussenkomsten om problemen op te lossen kunnen in alle onderdelen van de organisatie plaats vinden. Op geregelde tijden moet de teamleider alle problemen en oplossingen overlopen en daarbij voorrang geven aan het opsporen van fouten om te vermijden dat fouten opnieuw gemaakt worden, zodat scholen over een stabiele operationele omgeving kunnen beschikken.

Storingen kunnen gerapporteerd worden via telefoon, fax, e-mail of een webformulier. De meest dringende storingen krijgen voorrang. Storingen die vlug opgelost moeten worden, worden vaak per telefoon gerapporteerd. Minder belangrijke voorvallen worden gewoonlijk via bijvoorbeeld e-mail gerapporteerd. De storing moet toegewezen worden aan een medewerker van de ondersteuningsdienst en die zal de gebruiker een aantal vragen moeten stellen om het probleem te onderzoeken.

  • Denk er daarbij aan om actief en niet passief te luisteren.

Alle aanvragen moeten genoteerd worden en er moet een e-mailbevestiging gestuurd worden. Het is belangrijk dat de gebruiker zich veilig voelt en er moet hem informatie gegeven worden over wat het probleem zou kunnen zijn. Als de aanvraag toekomt op de servicedesk, moet een korte beschrijving van de storing genoteerd worden. De aanvraag kan afkomstig zijn van de ICT-contactpersoon van de school of van iemand waarmee overeengekomen is dat deze de servicedesk kan contacteren. Het noteren van het voorval moet zo snel mogelijk gebeuren en er moet een volgnummer aan toegekend worden. De gebruiker moet een bevestiging krijgen via e-mail dat de zaak opgepakt werd en er een passend volgnummer aan toegekend werd.

Vroeger werden aanvragen genoteerd in een papieren logboek. Nu wordt er van software gebruik gemaakt om aanvragen te noteren in een "aanvraagopvolgingssysteem". Het registreren van de aanvragen is onontbeerlijk bij tussenkomsten. In principe gebeurt dit in functie van het omgaan met fouten, van de vragen van gebruikers en van de prioriteitsbepaling tussen de verschillenden storingen. Het bijhouden van een registratie is belangrijk om te vermijden dat fouten zich herhalen. Aangezien de operationele gebeurtenissen geregeld nagekeken worden, kan er een beoordeling van de reparaties gebeuren en kunnen prioriteiten ingesteld worden. De registratie biedt ook een basis voor het verbeteren van de dienstverlening door het foutvrij maken van problematische diensten en toepassingen en dit op basis van wat de gebruikers als problematisch ervaren.

Het registreren van vragen is dus een basaal en noodzakelijk hulpmiddel voor zowel de gebruikers als de servicedesk. Er bestaan verschillende vrij verkrijgbare en goed gedocumenteerde systemen voor het bijhouden van vragen <<FootNote(RT Essentials: http://www.oreilly.com/catalog/rtessentials/chapter/index.html )>>. Skolelinux Drift gebruikt RT <<FootNote(RT: Request Tracker: http://www.bestpractical.com/ )>> voor het verwerken van vragen.

Een belangrijk element bij het opstarten van de ondersteuning is geen te moeilijke opstart te maken. Tracht niet alles tegelijk te verwezenlijken. Zet liever in op gemakkelijke verwezenlijkingen die de gebruiker op de hoogte houden en streef naar snelle reactietijden. Het is ook belangrijk uit te klaren aan wie de servicedeskmedewerkers problemen kunnen doorspelen als ze die niet zelf kunnen oplossen. Het ondersteuningsteam moet ook nagaan of de gebruiker met een onderbreking geconfronteerd zal worden. Dit maakt het mogelijk om snel en gemakkelijk feedback te geven.

Voor gebruikers is het belangrijk dat storingen aangepakt worden. Voor de dienstverlenende instantie is het van belang dat de storingen correct afgehandeld worden in overeenstemming met de dienstverleningsovereenkomst en dat aangevraagde werkzaamheden die buiten de afspraken vallen, geregeld worden tussen het schoolbestuur en de organisatie voor systeembeheer.

3.1.1. Taken en functies

We raden een overeenkomst aan over welke de verplichtingen zijn van de ICT-contactpersoon van de school en welke de verantwoordelijkheden zijn van de medewerkers van de servicedesk. In vergelijking met wat gebruikelijk is in gemeentelijke administraties en in private ondernemingen, beschikken scholen vaak over weinig middelen. Tegelijk hebben scholen gewoonlijk veel meer gebruikers en vaak meer clientmachines dan er in de rest van de gemeente in gebruik zijn.

Taken worden overeenkomstig de functies toegewezen. Bij duidelijk afgebakende functies is het eenvoudiger om taken te verdelen en duidelijk te krijgen welke arbeidsprestatie nodig is om een interventietaak tot een goed einde te brengen. Praktische ondervinding in gemeenten en professionele organisaties leert dat de volgende functies gebruikelijk zijn.

  • ICT-contactpersoon op elke school. Vaak is dit een leerkracht met een achtergrond als ICT-lesgever en/of een technische achtergrond.

  • Medewerker(s) die in de centrale IT-dienst werkt/werken. Dit is een voor interventies gekwalificeerd persoon.

  • ICT-coördinator die instaat voor het didactisch gebruik van IT en bijdraagt aan het plannen van ontwikkelingsgerichte, technische en onderwijskundige toepassingen. Vaak is dit een leerkracht.

  • ICT-verantwoordelijke. Gewoonlijk is dit de schooldirecteur die verantwoordelijk is voor IT-interventies.

Hierna volgt een overzicht van de verschillende dagelijkse taken, waarvan sommige door gemeenten uitbesteed worden.

De taken van de ICT-contactperso(o)n(en) op elke school:

  • Toezicht houden op de serverkamer van de school.

  • Optreden als contactpersoon voor de school op de gemeente - fouten en storingen rapporteren.

  • Eenvoudige onderhoudstaken uitvoeren, zoals het vervangen van een muis of een toetsenbord, het opwaarderen van thin-clients en eenvoudige herstellingen uitvoeren.

  • Fungeren als de supergebruiker van de school - in staat om collega's raad te geven over: gebruikersinterfaces, e-mail, videoprojectoren en relevante toepassingen.

  • Deelnemen aan ICT-vergaderingen.

  • Aanmaken en beheren van lokale gebruikers.

  • Het eenvoudige onderhoud van printers verzekeren.

  • Aanmaken en beheren van e-mailaccounts.

  • Eenvoudige commando's en interventies uitvoeren onder toezicht van een ICT-instructeur.

  • Het gebruik van ICT in de lespraktijk bevorderen.

Taken van de interventiemedewerker:

  • Aannemen van meldingen van storingen en serviceverzoeken.

  • ICT-contactpersonen ondersteunen via telefoon en e-mail.

  • Op afspraak ter plaatse gaan in scholen voor het verhelpen van defecten en storingen aan computers, printers en servers.

  • Reservekopieën maken.

  • Updates van beveiligingssoftware toepassen op de computers van de school (servers en clients).

Taken van de ICT-coördinator:

  • Het schoolbestuur en de ICT-contactpersonen bijstaan bij de ontwikkeling van de technische en onderwijskundige ICT-planning.

  • De servicedesk en het schoolbestuur begeleiden bij het kiezen van software en dergelijke.

  • Ervoor zorgen dat de scholen over geschikte ICT-hulpmiddelen voor het onderwijs beschikken en dat computers en netwerken aangepast zijn aan een schoolomgeving.

  • Begeleiding en advies verschaffen aan de interventiedienst in verband met de technische en pedagogische vereisten inzake ICT in scholen.

Taken van de ICT-verantwoordelijke (directeur, schoolhoofd, hoofd van de interventiedienst):

  • Gegroepeerde aankopen doen van computermateriaal en gezamenlijke overeenkomsten onderschrijven, enz.

  • Schema's met de bevoegdheidsverdeling ontwikkelen.

  • De scholen cursussen aanbieden over het onderwijskundig gebruik van ICT.

  • De wijze van werken.

  • Overeenkomsten onderhandelen in verband met interventies.

  • Ervoor zorgen dat de ICT-contactpersoon en de ICT-dienst over de nodige middelen beschikken.

Het voordeel van het vooraf definiëren wie verantwoordelijk is voor het uitvoeren van welke taken, is dat de verwachtingen ten aanzien van individuele personen gekend zijn, hetgeen een goede basis biedt voor het plannen en beheren van ICT-diensten. Gewoonlijk worden deze ICT-taken slechts op deeltijdse basis verricht door personeel dat ook nog belast is met onderwijstaken.

Een bedrijf kan wel over twee voltijdse medewerkers beschikken die verantwoordelijk zijn voor de werking van 100 standaard client-computers voor 100 gebruikers. In scholen kan het in totaal gaan om een 30% functie, verdeeld over verschillende personen, die de verantwoordelijkheid heeft over het onderhoud van 100 client-computers die door 320 leerlingen en leerkrachten gebruikt worden.

Als scholen over zo weinig middelen voor interventies beschikken, is het van cruciaal belang om deze goed te gebruiken. Duidelijke overeenkomsten over wie welke taken op zich neemt, kan het makkelijker maken om in te schatten of bijkomende middelen vereist zijn, of om tot het besluit te komen dat de verwachtingen op het gebied van IT-initiatieven in scholen naar beneden bijgesteld moeten worden omwille van budgetbeperkingen. Een IT-beheerder die een goed overzicht heeft over de ICT-taken in de school is beter geplaatst om meer middelen te vragen als dat nodig is. Er kan nood zijn aan extra middelen om door ICT ondersteunde examens te kunnen organiseren of behoefte zijn aan nieuwe uitrusting, zoals digitale schoolborden om die als leermiddelen te kunnen gebruiken.

3.1.2. Verwachte tijdsinvestering

We hebben een tabel gemaakt die laat zien hoeveel tijd besteed wordt aan tussenkomsten en onderhoud. De tabel is gebaseerd op de ervaring van gemeenten die werken met een centraal beheerd Debian Edu-systeem voor 9-10 scholen met 250-500 client-computers. Verschillende zaken werden in de tabel niet opgenomen. Daarom moet meer tijd voorzien worden voor projecten waarbij scholen zelf hun eigen ICT-oplossingen uitbouwen met netwerken en extra apparatuur.

Functie

Concrete verantwoordelijkheid

Per school en per week besteedde tijd

Totaal besteedde tijd voor alle scholen

Centrale interventiestaff

Opvolging, probleemoplossing en operationeel houden van 500 computers in bijvoorbeeld 10 scholen met 3.200 leerlingen en leerkrachten.

2-3 u (50 clients)

½-timefunctie (500 clients)

ICT-contactpersoon per school

Toezicht houden op de uitrusting, eenvoudige onderhoudstaken en het rapporteren van storingen en aanvragen.

3-4 u (50 clients)

1 voltijdse functie (10 scholen / 500 clients)

Centrale ICT-coördinator

Ondersteuning bieden bij het plannen en toepassen van onderwijskundige en technische ICT-werkzaamheden in scholen.

1-2 u

½-timefunctie

ICT-beheerder (directeur)

Gegroepeerde aankopen verrichten en zich houden aan de dienstverleningsovereenkomst. Inplannen van updates of het ontwikkelen van oplossingen.

1 u

¼-timefunctie

Totaal per school

50 client-computers (gelijktijdige gebruikers)

6 - 10 u

 

Totaal voor alle scholen

10 scholen, 500 client-computers (gelijktijdige gebruikers)

2 ¼ fulltimefuncties

De ervaring leert dat de uit te voeren werkzaamheden van de ICT-contactpersoon beïnvloed wordt door het aantal gelijktijdige gebruikers. Voor velen is de term "gelijktijdige gebruikers" wellicht onbekend. Laten we hem met een voorbeeld illustreren: neem een school met 250 leerlingen, maar met slechts 50 computers. Dan kunnen ten hoogste 50 leerlingen gelijktijdig een computer gebruiken. Dit is veel minder dan het totaal van 250 gebruikers die op het systeem een account hebben. Het zijn deze 50 ingelogde gebruikers die de IT-dienst werk bezorgen. De overige 200 niet ingelogde personen bezorgen maar weinig extra werk.

Daarom is het gebruikelijk om de kosten van IT te berekenen op basis van het maximum aantal gelijktijdige gebruikers. Ook andere berekeningsmethodes zijn mogelijk, bijvoorbeeld als betaald wordt voor commerciële software. Maar vermits er geen licentiekosten verbonden zijn aan Debian Edu, is het aantal gelijktijdige gebruikers het meest cruciale cijfer voor de interventiekosten. Voor een school heeft het weinig of geen zin om de kosten te berekenen op basis van het aantal gebruikersaccounts.

Voor gebruikers van Debian Edu is het verschil in kosten voor het beheren van 100 of van 250 gebruikersaccounts zeer klein. Er zijn enkele uitzonderingen. Wanneer leerlingen herhaaldelijk hun wachtwoord vergeten maakt 100 of 250 leerlingen een verschil. Daarom is het verstandig om de leerkracht die verantwoordelijk is voor de klas, de toelating te geven deze leerlingen een nieuw wachtwoord te geven.

Indien de school 50 client-computers heeft, heeft de ICT-contactpersoon minder tijd nodig voor zijn operationele taken dan wanneer de school over 150 client-computers beschikt. Bij een groter aantal client-computers neemt de totale tijd die gespendeerd wordt aan interventies toe, maar de geïnvesteerde tijd per client-computer vermindert een beetje.

Verschillende gemeenten hebben 3-4 uur per week gereserveerd voor de taken van de ICT-contactpersoon op iedere school met 30-70 client-computers. Het onderwijsdepartement in Oslo heeft anderhalve dag per week of 30% van een voltijdse functie gereserveerd voor de ondersteuning van 150 client-computers. De ervaring vanuit andere gemeenten suggereert dat 20% van een voltijdse functie volstaat voor de taken van een lokale ICT-contactpersoon wanneer een school 160 thin-clients of schijfloze clients heeft met Debian Edu.

Daarnaast zijn er kosten verbonden aan de gecentraliseerde interventies, aan het ICT-management en aan het ontwikkelen van het onderwijskundig gebruik van ICT-hulpmiddelen bij schoolse activiteiten. Wellicht volstaat één medewerker voor het operationeel houden van 1000 client-computers. Wat onderwijskundige ondersteuning betreft, beschikken veel directeurs hiervoor in de school over een 50-100% medewerker. Er kan een 10-20% functie zijn voor een ICT-contactpersoon en een 40-80% functie voor de didactische ondersteuning van de leerkrachten. Veel leerkrachten ervaren ICT-hulpmiddelen op school als iets nieuws. Sommige schoolhoofden wensen meer ondersteuning te bieden op onderwijskundig gebied en leerkrachten meer vertrouwd te maken met het gebruik van IT-hulpmiddelen in de verschillende vakken.

3.1.3. Checklist

We bieden hier een checklist aan met wat er nodig is om een nieuwe service-entiteit op te starten.

  • Aan de betrokkenen de diverse functies toewijzen, zoals IT-manager, IT-contactpersoon in iedere school, medewerker van de centrale interventiedienst en IT-coördinator voor alle scholen. Het is belangrijk om de technische en onderhoudswerkzaamheden te onderscheiden van de onderwijstaken.

  • De servicedesk uitbouwen, zodat iedere school over een dienstverleningsovereenkomst beschikt waarin bepaald wordt welke interventieactiviteiten als standaard beschouwd moeten worden en welke als extra. Het is noodzakelijk dat de directeurs die verantwoordelijk zijn voor ICT bij dit proces betrokken worden.

  • Een systeem opzetten om inkomende verzoeken af te handelen (een aanvraagopvolgingssysteem). Alle aanvragen per e-mail moeten een volgnummer krijgen. Ook bijna alle aanvragen van gebruikers of IT-contactpersonen van scholen moeten een volgnummer krijgen.

  • Ervoor zorgen dat in de ICT-begroting de noodzakelijke inbreng voorzien wordt die men nodig heeft om de goede werking te verzekeren van de computeruitrusting en de netwerken. Tegenwoordig wordt vereist dat de ICT-systemen gebruikt kunnen worden voor nationale en lokale tests met gebruikmaking van ICT-hulpmiddelen, en dit met of zonder internetverbinding.

  • In principe gebruik maken van de standaarduitgave van Debian Edu met eenzelfde versie in alle scholen. Maak van daaruit alle gewenste aanpassingen. Deze aanpassingen moeten beheerd worden in een configuratiedatabank en de gemaakte veranderingen moeten gedocumenteerd worden. Er kan gebruik gemaakt worden van versiebeheer om de aanpassingen en de documentatie te bewaren.

3.2. Het beheer van incidenten

Het doel van de ICT-dienst is storingen zoals systeemuitval en softwareproblemen te vermijden. Gebruikers zullen weinig problemen ervaren met het ICT-systeem als de ICT-dienst over voldoende middelen beschikt voor het uitvoeren van interventies, voor uitrusting en voor het behandelen van aanvragen aan de servicedesk. Kleine of grote problemen zullen ertoe leiden dat gebruikers met onderbrekingen te maken krijgen, en dus is een goede aanpak van incidenten noodzakelijk.

In de wereld van het valschermspringen noemt men bijna-ongevallen "incidenten". Bij interventies in verband met computers is het misschien niet helemaal hetzelfde wanneer iets niet werkt. Het doel bij het behandelen van incidenten is diensten zo snel mogelijk te herstellen, zodat alles normaal functioneert. Indien er iets fout loopt, moet dit de kleinst mogelijke impact hebben op gebruikers. Wat verstaan wordt onder een "normale dienst" wordt afgesproken via een interventieovereenkomst waarin het dienstverleningsniveau omschreven wordt.

Het bijhouden van statistieken over incidenten is belangrijk, in het bijzonder wanneer meerdere mensen in de organisatie werken. Als verschillende mensen samenwerken, kan men makkelijk het zicht op het werk verliezen. Via het bijhouden van statistieken zal zichtbaar worden voor welke probleemgebieden een snelle oplossing vanuit de servicedesk niet volstaat maar een grondiger aanpak nodig is. Er kunnen bijvoorbeeld veel aanvragen zijn voor het vervangen van vergeten wachtwoorden, waardoor het verstandig kan zijn om de leerkracht de wachtwoorden van de leerlingen van zijn klas te laten vervangen.

Een operationele storing wordt omschreven als:

  • een voorval dat niet tot het normale functioneren behoort en een onderbreking of een kwaliteitsvermindering van de dienst veroorzaakt of kan veroorzaken.

Mogelijke voorbeelden van operationele storingen zijn:

  • Programma's

    • het officepakket (OpenOffice.org) start niet

    • de webbrowser (Firefox) crasht

    • de harde schijf is vol

  • Hardware

    • de server ligt plat

    • printen lukt niet

    • inloggen lukt niet

  • Aanvragen

    • vragen om informatie, advies of documentatie

    • vergeten wachtwoord

Dit zijn voorbeelden van de meest voorkomende operationele problemen. Het zijn problemen die gebruikers ertoe brengen de school of de servicedesk te contacteren. De ICT-dienst moet prioriteiten vastleggen tussen wat onmiddellijk afgehandeld moet worden en welke problemen meer tijd vragen om opgelost te worden. Om prioriteiten te bepalen in verband met de problemen die een grondiger probleembehandeling vereisen, is het belangrijk om alle verzoeken in verband met storingen te registreren. Eens men een overzicht heeft over de meest voorkomende problemen, kan passende actie ondernomen worden.

3.2.1. Checklist

We ontwikkelden een korte checklist om ervoor te zorgen dat de nodige procedures en systemen voor een goede afhandeling van voorvallen ontplooid worden.

  • De medewerker die met de probleemoplossing belast is, rapporteert terug over de situatie aan de ICT-contactpersoon en/of de gebruiker.

  • Het systeem voor het registreren van voorvallen moet beschikbaar en operationeel zijn (zowel technisch als functioneel) voor diegenen die in de school en aan de servicedesk bezig zijn met de afhandeling van voorvallen.

  • Het systeem voor het registreren van voorvallen moet voor praktisch alle operationele gebeurtenissen gebruikt worden.

  • Periodiek moeten statistieken opgemaakt worden op basis van de registratie van de voorvallen. De statistieken kunnen gebruikt worden om terugkerende problemen die irritant zijn voor de gebruikers, te identificeren en te elimineren.

3.2.2. Planning en uitvoering

Een werkbaar systeem opzetten voor het registreren van voorvallen vereist iets meer dan enkel het installeren van het systeem. Iedereen van het interventiedepartement moet het systeem gebruiken. Diegenen die fouten rapporteren moeten ook feedback krijgen via e-mail met het volgnummer van de werkbon. Dit houdt in dat aanzienlijke inspanningen nodig zijn om het systeem voor het registreren van voorvallen te configureren. Daarenboven moet men een basisvorming voorzien voor diegenen bij wie de aanvragen toekomen.

Uitgebreide en omvattende plannen zijn voor een behoorlijke afhandeling van voorvallen niet vereist. Het aanpakken van voorvallen is volkomen een standaardtaak voor wie op de servicedesk of als ICT-contactpersoon op de school werkt. Bij het opzetten van een computerhulpmiddel voor het registreren van voorvallen, kan het ontwikkelen van een goede configuratie wel tot enkele weken in beslag nemen, en gebruikers kunnen ook voorvallen rapporteren via e-mail of per telefoon.

De gebruikersinterface van het registratiesysteem is redelijk duidelijk, waardoor het niet te veel tijd zou mogen vragen om ermee aan de slag te gaan. Door het systeem dagelijks te gebruiken zullen gebruikers vertrouwd geraken met wat geregistreerd moet worden. Het is cruciaal dat iedereen van het interventiedepartement het registratiesysteem gebruikt voor interventieberichten.

3.2.3. Activiteiten die verband houden met operationele voorvallen

Om een idee te geven van de verrichte werkzaamheden als gevolg van een gerapporteerd voorval, maken we gebruik van een voorbeeld.

Een gebruiker contacteert het kantoor van de servicedesk met een probleem en rapporteert dat hij niet kan printen. De interventiedienst registreert het voorval onmiddellijk nadat het telefoongesprek beëindigd werd. Een dossier wordt geopend voor het probleem en er wordt onmiddellijk een dossiernummer aan toegekend.

De interventiedienst op de servicedesk maakt een snelle analyse. Is de spooler opnieuw uitgevallen, of is er iets anders aan de hand? Ontbreekt er papier of toner? De interventiemedewerker onderzoekt de spooler en merkt dat de wachtrij volgelopen is. Ze verwijdert de wachtrij en test of de volgende printopdracht afgedrukt wordt.

Deze keer loopt de afdrukwachtrij terug vol. De interventiedienst contacteert de ICT-contactpersoon van de school en vraagt om te controleren of de papierlade leeg is. Dit wordt geregistreerd in de log van het voorval. De contactpersoon van de school antwoordt dat de papierlade opnieuw bijgevuld werd en dat het afdrukken normaal verloopt. De zaak wordt afgesloten en dit wordt geregistreerd in het registratiesysteem voor voorvallen.

Indien het afdrukken niet opnieuw had gefunctioneerd, was de oorzaak misschien het ontbreken van toner of mogelijk was er een printerfout. Indien het een printerfout betrof, had de interventiedienst de aanpak moeten verruimen. Dit betekent dat men iemand anders dan de interventiemedewerker of de ICT-contactpersoon nodig had om het probleem op te lossen - in dit voorbeeld, een technicus die printers kan repareren.

Dit voorbeeld illustreert de volledige werkstroom die onderzocht moet worden om een printer opnieuw te laten werken. Indien een printer na de controle of papier en toner aanwezig zijn, nog steeds niet werkt, vraagt het probleem om een uitgebreidere aanpak. Het interventiedepartement moet een expert te hulp roepen om het probleem te repareren - in dit geval betrof het een onderhoudstechnicus voor printers.

Wat er fout ging en hoe het gerepareerd werd, worden genoteerd in het registratiesysteem voor voorvallen.

3.2.4. Functies

Verschillende functies zijn betrokken wanneer de ICT-dienst gerapporteerde problemen aanpakt. In het bovenstaande voorbeeld werken de ICT-contactpersoon van de school en de interventiemedewerker samen om het printerprobleem op te lossen. Was het probleem ingewikkelder geweest, dan hadden ze een technicus moeten bellen. Mocht de printer niet gerepareerd kunnen worden, moest er een nieuwe aangekocht worden. Indien de school een nieuwe printer had moeten aankopen, hadden de ICT-managers de betaling moeten regelen. In veel organisaties heeft de directeur het laatste woord.

Kort samengevat geraken er makkelijk veel personen betrokken wanneer iets niet functioneert. Waar mogelijk zouden problemen ter plaatse opgelost moeten worden en zou vermeden moeten worden om anderen er onnodig bij te betrekken. Een verruimde aanpak voor problemen die lokaal opgelost kunnen worden, kan snel kostelijk worden. Veel verzoeken kunnen onmiddellijk afgehandeld worden, maar andere vragen hebben met meer complexe problemen te maken waarbij meer mensen betrokken zijn. Indien extra of externe hulp nodig is om het probleem op te lossen, moet dit in de regel uitgeklaard worden met de interventiedirecteur. Het is belangrijk zich van deze zaken bewust te zijn bij het aanpakken van voorvallen, om zo hulpmiddelen op de juiste wijze in te zetten.

3.2.5. Kernaspecten

We hebben enkele kernaspecten voor het behandelen van incidenten opgesteld. Deze elementen kunnen behulpzaam zijn om aan de hand van meetbare en duidelijk omschreven verplichtingen te kunnen evalueren of de zaken goed gaan. Dergelijke ijkpunten zijn:

  • Het totaal aantal operationele incidenten.

  • De gemiddelde tijd die verliep tussen het binnenkomen van een aanvraag en de oplossing van het probleem, met een classificatie op basis van codes (een goed georganiseerd interventiedepartement beschikt over codes voor verschillende types voorvallen en fouten).

  • Het percentage incidenten dat afgehandeld werd binnen de overeengekomen reactietijd (zoals in de dienstverleningsovereenkomst afgesproken werd).

  • De gemiddelde kost per voorval

  • Het percentage incidenten dat door de servicedesk opgelost werd zonder een meer uitgebreide aanpak

  • Voorvallen per clientcomputer (werkplek)

  • Aantal en percentage van incidenten dat door het interventiecentrum opgelost werd, zonder dat een bezoek aan de school nodig was

3.2.6. Hulpmiddelen

Een aantal hulpmiddelen kunnen de aanpak van operationele incidenten vergemakkelijken

  • Automatische registratie

  • Automatisch doorsturen van voorvallen naar de juiste persoon

  • Automatisch ophalen van gegevens uit de databank voor configuratiebeheer

  • Het gebruik van telefoon en e-mail in combinatie met hulpmiddelen voor het registreren van aanvragen en incidenten.

3.3. Probleembeheer

Het beheer van problemen is een "zoekend" proces. Bekende fouten worden meestal rechtstreeks door de servicedesk aangepakt. Dit is de meest gebruikelijke manier om voorvallen af te handelen. Voor het onderzoeken van onbekende fouten is zowel gezond verstand als instinct vereist. Goede interventiemedewerkers gebruiken hun instinct om recht op het probleem af te gaan, er een oplossing voor te zoeken en de dienst zo spoedig mogelijk te herstellen, zodat alles terug normaal functioneert.

Probleembeheer is

  • Probleembeheer

  • Fouten controleren

  • Pro-actieve controle om problemen te voorkomen

  • Foutenpatronen identificeren met behulp van informatie uit, bijvoorbeeld, het beheer van voorvallen

Probleemcontrole

  • Problemen identificeren

  • Problemen classificeren

  • Problemen inspecteren/onderzoeken

Foutcontrole

  • Bekende fouten identificeren en registreren

  • Zo mogelijk tijdelijke oplossingen zoeken

  • Contact leggen met diegenen die verantwoordelijk zijn voor veranderingsbeheer om de fout definitief te elimineren

Proactieve controle

  • Problemen en fouten identificeren en oplossen vooraleer het incident gerapporteerd wordt door gebruikers.

  • Logs en informatie uit de afhandeling van voorvallen gebruiken om te leren hoe problemen kunnen ontstaan

3.3.1. Procedures voor probleembeheer

De handleiding van Skolelinux / Debian Edu is een omvattende verzameling oplossingen voor problemen en systeemconfiguraties. Alles is te vinden op de wikipagina's van Debian. Oplossingen worden onderhouden met de hulp van stafmedewerkers van scholen, gemeentelijke ICT-diensten, individuele beroepskrachten en vrijwilligers. De links naar de Engelstalige pagina's zijn te vinden op: https://wiki.debian.org/DebianEdu/Documentation/Manuals . De pagina's worden vertaald naar het Noorse Bokmål. Er wordt gewerkt om eveneens te voorzien in links naar het Bokmål.

De wikitechnologie is een groot succes gebleken voor het onderhouden van gestructureerde informatie op het internet. Men kan er gemakkelijk aan bijdragen en alle wijzigingen worden bijgehouden. Het is ook mogelijk om OpenOffice.org-documenten te importeren en documenten in PDF-formaat te exporteren.

3.4. Configuratiebeheer

Met de middelen die in scholen besteed worden aan IT-systemen moet op financieel vlak voorzichtig omgesprongen worden om controle te houden over de gebruikte diensten en de uitrusting/infrastructuur. De uitrusting, de software en de diensten hebben een heleboel instellingen - dit is de configuratie, of een logisch model van hoe infrastructuur en diensten opgezet zijn.

Om de configuratie te beheren moet ze bepaald en opgeslagen zijn en onderhouden worden. Men moet ook de verschillende versies van de configuratie kunnen opvolgen. Ieder onderdeel van een instelling noemen we een Configuratie-Item (CI). Een configuratiebestand kan er bijvoorbeeld voor zorgen dat bepaalde gebruikers toegang hebben tot een aantal printers in het netwerk. Een ander kan er voor zorgen dat schijfloze clientcomputers een buffer toegewezen krijgen.

Een bijgewerkte database voor configuratiebeheer is essentieel voor een snelle en gecontroleerde afhandeling van problemen in de werking of van wijzigingen in de opzet van machines, programma's en diensten.

3.4.1. Planning

Er is planning vereist bij het opzetten van een database voor configuratiemanagement. Men moet beslissen in welke domeinen het systeem, met welk oogmerk en volgens welke instructies en processen gebruikt zal worden voor de opslag en het onderhoud van de configuraties.

  • Bepaal en selecteer een structuur voor de configuratie die in overeenstemming is met de belangrijke onderdelen van de ICT-infrastructuur. Men moet nadenken over wie eigenaar zal zijn van de configuratie, over naamlabels (attributen), over onderlinge afhankelijkheden en relaties tussen configuraties.

  • Enkel goedgekeurde configuraties worden in de database beheerd gedurende de levenscyclus van het systeem. Controle over de toegang tot de configuratie-instellingen kan uitgeoefend worden met behulp van groepspermissies en gerealiseerd worden via het proces van Wijzigingsbeheer.

  • Statusregistratie - houdt de toestand en de status van de verschillende subsystemen bij. Dit is van toepassing gedurende de levenscyclus van de dienst, de software of de hardware. Er kan een actief werkende, een uitgeschakelde en een vervallen configuratie bestaan.

  • Controle en revisie. Elke configuratie moet gecontroleerd worden om te bevestigen dat de correcte informatie opgeslagen werd in de configuratiedatabase (CMDB). Dit wordt met periodiek nazicht opgevolgd om er zeker van te zijn dat de database actueel is.

Zoals u ziet, is heel wat planning vereist met het oog op configuratiebeheer in het IT-systeem. Het doel van planning als onderdeel van IT-werkzaamheden is te garanderen dat systemen snel gerepareerd worden als ze uitvallen. Met een goed configuratiebeheer is het eenvoudig om een defecte machine door een nieuwe te vervangen. De configuratie-instellingen kunnen snel naar de nieuwe computer overgezet worden en het IT-systeem zal even goed functioneren als voordien.

3.4.2. Het beheer van Configuratie-Items (CI)

Een configuratie-item is een onderdeel van de infrastructuur. Het betreft gewoonlijk de configuratie van een dienst of een programma. Soms wensen gebruikers de manier waarop een dienst werkt, aan te passen. Men moet de configuratie-instellingen bijhouden als er aanpassingen gemaakt werden.

In de praktijk kunnen we ons de configuratie van een printerserver voorstellen. U wilt een nieuwe printer toevoegen aan het computernetwerk en hem in het printersysteem CUPS onderbrengen. Als u een configuratie-instelling via een webapplicatie of via het KDE-configuratiesysteem wijzigt, zal het configuratiebestand voor CUPS aangepast worden en moet de printerserver opnieuw gestart worden. Dit kan gebeuren vanuit de KDE-hulpmiddelen of via een webapplicatie. Het gewijzigde instellingenbestand wordt gekopieerd naar een map waar het bestand door een versiebeheersysteem verwerkt kan worden.

Onder de verschillende te maken keuzes, zijn er aantal vaak voorkomende. Het gaat dan over het feit of een dienst actief moet zijn, gestopt, beëindigd, gestart, onderbroken of uit dienst genomen moet worden.

Men moet voorzichtig zijn met het wijzigen van configuraties zonder een voorafgaand duidelijk plan. Men vergeet gemakkelijk wat men precies gedaan heeft op een server of een PC. Daarom is het belangrijk om de gemaakte wijzigingen te beschrijven in een logboek met aanpassingen.

3.4.3. Planning en installatie

De configuratie van het computernetwerk is gekoppeld aan de architectuur ervan. Veel van de planning gebeurt in Debian Edu. Dit is omdat het met behulp van Windows-servers of Redhat of andere GNU/Linux-distributies telkens 3 tot 4 weken kan vergen om servers met een overeenkomstig serviceniveau op te zetten. Debian Edu doet dit in 1-2 uur. Indien u een vast IP-adres wilt voor het netwerk, heeft een beroepskracht daar een extra ½ uur voor nodig. Dit is omdat webdiensten worden opgezet met herbruikbare namen.

Wat vervolgens gepland moet worden is welke bijkomende gebruikersprogramma's gebruikt moeten worden en welke subsystemen met Debian Edu moeten interageren. Een school kan bijvoorbeeld een elektronisch whiteboard hebben.

3.4.4. Checklist

We hebben een lijst samengesteld met activiteiten en oplossingen die bij goed configuratiemanagement van belang zijn.

  • Plaats een gebied waarin u de configuraties van alle servers en van geselecteerde werkstations en laptops zult opslaan, onder versiebeheer. Git en SVN worden hier vaak voor gebruikt. Denk eraan om dagelijks een reservekopie te maken van dit gebied en zorg ervoor om alle aanpassingen op te slaan in configuraties.

  • Gebruik een elektronisch systeem om de recepten bij te houden waarin de toelichting staat bij de configuratie van de verschillende types machines, van het netwerk en van de diensten. Zulke recepten zijn nuttig omdat anderen die bij bepaalde operaties helpen of deze overnemen, er kunnen nalezen wat er gedaan wordt. Een wiki kan hiervoor een bruikbaar instrument zijn.

  • Gebruik op alle systemen één welbepaalde versie van het besturingssysteem en van de software. Dit is om te vermijden dat verschillende versies van de software onderhouden moeten worden. Zorg ervoor dat de software goed uitgetest werd. Daarom kan het verstandig zijn om 6-12 maanden te wachten vooraleer over te schakelen naar de nieuwste uitgave van een programma.

3.4.5. Relaties met andere processen

Het beheer van configuratie-instellingen is nauw verbonden met de afhandeling van problemen en met de beschikbaarheid van systemen. Als het printersysteem te vaak uitvalt, kan een aanpassing van de configuratie het probleem misschien oplossen. Deze kan er bijvoorbeeld in bestaan een routine voor het verwijderen van de printerwachtrij en het herstarten van de printerdienst op te zetten.

Het doel van aan configuraties gemaakte aanpassingen is gewoonlijk een verhoogde beschikbaarheid van diensten en programma's. Het doel ervan kan ook zijn om de toegang tot bepaalde programma's of diensten te beperken tot bepaalde tijdstippen. Om dit te bekomen moet de dienst geherconfigureerd worden. Daarenboven kan het extra geld kosten, bovenop wat inzake serviceniveau of capaciteit van het systeem overeengekomen was.

De voorbeelden illustreren dat het beheer van configuraties ook op een aantal andere gebieden ingrijpt. Daarom valt er veel te winnen bij het installeren van goede praktijken voor het beheer van aanpassingen aan configuraties. Ook automatisering valt aan te bevelen indien u een grotere stabiliteit wenst, of toegang tot bepaalde diensten tijdens specifieke periodes.

3.4.6. Instrumenten voor configuratiebeheer

Zoals vermeld werd onder Checklist, kan men gebruik maken van

  • het opslaan van de configuratiebestanden in een systeem voor versiebeheer, bijvoorbeeld subversion.

  • een wiki voor het opslaan van documentatie over instellingen en van wizards

  • een gemeenschappelijke map op het internet met operationele documentatie die onderhouden wordt door de Skolelinux/DebianEdu-staf in de scholen.

3.5. Wijzigingsbeheer

Veel ICT-diensten gaan niet slim om met aanpassingen aan ICT-systemen. Dit leidt tot veel mistevreden gebruikers. Enquêtes in de openbare sector in Denemarken toonden aan dat de werkingskosten afnemen als u een goede controle over de aanpassingen behoudt. Daarom loont het om gebruikers met training en participatie te betrekken bij de doorgevoerde aanpassingen.

Wijzigingsbeheer is volledig afhankelijk van passende processen. Dit geldt ongeacht of het om kleine of grote wijzigingen gaat. Daarom is het belangrijk om de juiste mensen ter beschikking te hebben als wijzigingen doorgevoerd worden, zowel voor het geven van training als voor het beantwoorden van vragen. Dit wordt vooral belangrijk wanneer nieuwe releases van software en diensten ontplooid worden. Of men gebruik maakt van vrije of gepatenteerde software maakt daarbij geen verschil.

Wijzigingsbeheer moet ervoor zorgen dat alle aanpassingen op een gestandaardiseerde en juiste wijze gebeuren. Het is van belang om de beslissing in verband met de aanpassing te verankeren op het gepaste niveau binnen de organisatie. Standaardaanpassingen kunnen vaak vooraf goedgekeurd worden als ze enkele malen uitgevoerd worden. Maar bij belangrijke wijzigingen zal de beslissing vaak op een hoger niveau tussen schooldirectie en ondernemer genomen worden.

De reden waarom de directie betrokken moet worden is dat een opwaardering vaak een training van gebruikers vereist. Het kan gaan om een opwaardering naar een nieuwe browser of een nieuwe versie van kantoorsoftware. Dit kan al snel gaan om een training van een halve dag over wat nieuw is in het programma. Over dergelijke aanpassingen moet men een akkoord van de directie hebben. De veranderingen moeten ook doorgevoerd worden zonder dat de andere onderdelen van het systeem stoppen met werken.

Diegenen die verantwoordelijk zijn voor het goedkeuren van wijzigingen ontvangen een zogenaamd wijzigingsbericht of RFC (Request For Change). Als u een RFC heeft, kunt u inschatten of de wijziging moet doorgevoerd worden. Vaak moet u met de directie uitklaren of facultatieve aanpassingen nodig zijn en als dit zo is, wanneer ze zullen plaats vinden.

Bij wijzigingen moet men ook samenwerken met de ICT-verantwoordelijke van de school. Men moet ervoor zorgen dat de wijzigingen gebeuren wanneer dit past in de plannen van de school. Significante wijzigingen doorvoeren zonder wijzigingsbeheer kan tot veel ontevredenheid leiden en tot bijkomende vragen aan de servicedesk. Dit zou een significant volume extra werk betekenen dat niet voorzien is. Daarenboven kan dit leiden tot een wijziging die snel daarna teruggedraaid wordt. U krijgt algauw dubbel zoveel werk, zonder uiteindelijk ergens anders te belanden dan terug bij af. Had men toegewerkt naar de vereiste goedkeuringen, dan was de aanpassing wellicht op een geplande en eenvoudige manier verlopen.

Wijzigingsbeheer wordt toegepast om te vermijden dat men meer extra werk dan nodig krijgt. Wijzigingen aanbrengen vereist duidelijk meer werk, maar bij geplande veranderingen zal dit extra werk beperkter zijn. Men vermijdt bovendien dat wijzigingen teruggeschroefd moeten worden, omdat zich problemen zullen manifesteren waar gebruikers niet voorbereid worden op substantiële wijzigingen.

Wanneer u bijvoorbeeld het volledige systeem naar een nieuwe versie opwaardeert, moet u ervoor zorgen dat iedereen op de hoogte is. Men moet nagaan of diegenen die met de wijziging te maken zullen krijgen, training nodig hebben. Een goede professioneel zal dit allemaal voorbereiden, zodat er zich geen verrassingen voordoen.

Niet alle verantwoordelijkheid moet terecht komen bij de persoon die verantwoordelijk is voor het versiebeheer van de software, de releasemanager. De afhandeling van een release is een proces dat bij voorkeur werkt met aanpassingen die vele kleine wijzigingen omvatten. Dit komt gewoonlijk voor wanneer nieuwe systemen en diensten uitgerold worden of bij het opwaarderen van het hele systeem naar een nieuwe versie.

3.5.1. Activiteiten

  • Zie de wijzigingsmelding of RFC (Request For Change) hierboven en controleer ook of deze een uniek nummer gekregen heeft.

  • Stel prioriteiten op en werk met categorieën van aanpassingen

  • Verwijder niet realiseerbare veranderingen. Dit kan gebeuren door ze als onmogelijk te markeren.

  • Geef feedback aan diegene die het wijzigingsbericht uitgaf

  • Zorg ervoor dat u beschikt over een wijzigingsadviescommissie, waar de verandering aangepakt, bediscussieerd en geëvalueerd wordt. Deze adviescommissie kan samengesteld zijn uit geselecteerde ICT-contactpersonen en interventiemedewerkers met een lange staat van dienst.

  • Coördineer wijzigingen met het releasebeheer dat zich bezighoudt met de verschillende versies van toepassingen en diensten.

  • Herlees en werk het wijzigingsbericht (RFC) af

  • Denk eraan om gewijzigde configuraties op te slaan in het depot van configuratiebestanden.

  • Raporteren

Zelfs wat er kan uitzien als een kleine en onbeduidende wijzigingsmelding, kan bij de implementatie ervan grote consequenties hebben. We hebben voorbeelden meegemaakt van scholen met een stabiel netwerk van Debian Edu waarin alle programma's werken. Van een populair programma wordt op een gegeven moment een testversie geïnstalleerd dat voortdurend crasht en de schuld ervoor wordt op Debian Edu geschoven.

Een voorbeeld zijn de scholen waar de testversie van de recentste uitgave van OpenOffice.org geïnstalleerd werd voordat het programma volledig klaar was. Velen dachten dat het leuk kon zijn om de nieuwste versie uit te proberen. Het probleem is dat testuitgaves gewoonlijk uitgebracht worden om op het spoor te komen van fouten en onstabiele functies in de toepassing. Ze zijn niet bedoeld om in een productieve omgeving gebruikt te worden.

In een werkomgeving is de algemene regel dat u geen testversies van software installeert. De meeste operatoren raden aan om de voorlaatste versie van een toepassingsprogramma te gebruiken voor productiedoeleinden. Meestal zijn na 6-12 maanden de ergste fouten weggefilterd uit een nieuwe hoofdversie van een programma.

Dit betekent dat men vaak tot de zomer wacht voor men opwaardeert naar een programma dat juist voor Nieuwjaar een nieuwe uitgifte gekend heeft. Dit past goed bij een schooljaar. Het alternatief zou instabiliteit kunnen betekenen en geïrriteerde gebruikers. Om die reden speelt de adviesgroep een sleutelrol bij het doorvoeren van kleine en grote wijzigingen.

3.6. Uitgavebeheer

De afwikkeling van een release draait om beheers- en planningsactiviteiten ter voorbereiding van de gewenste veranderingen. De wijzigingen kunnen klein of groot zijn, waarbij grote wijzigingen kunnen bestaan uit vele kleinere aanpassingen. Uitgavebeheer speelt zich af voor men begint aan de eigenlijke fase van het installeren van software en hardware in de werkomgeving.

Eerst wordt het plannen en uittesten van nieuwe uitgaves doorgevoerd. Daarna wordt alles ontplooid in de werkomgeving. Het ontplooien maakt deel uit van het infrastructuurbeheer. De procedure komt neer op het toepassen in de systemen voor configuratiebeheer van wat gepland en getest werd en klaar gebleken is. Nadat alles gepland en getest werd en de configuraties opgeslagen zijn, wordt de oplossing uitgerold in de werkomgeving.

Gewoonlijk zijn veel dienstverleners en leveranciers bij het proces betrokken. Dit geldt zowel voor het aanschaffen van machines als voor de gebruikte software en de aanbevolen configuraties. Een goede middelenplanning is cruciaal om een nieuwe uitgave op een voor gebruikers goede manier te verpakken en te verdelen. Nonchalance op dit vlak kan leiden tot uitrusting die niet werkt of ongebruikt blijft ten gevolge van onvolkomenheden in de installatie.

Uitgavebeheer heeft een omvattende benadering nodig bij het veranderen van een dienst en dat moet ervoor zorgen dat alle onderdelen van een uitgave in hun context gezien worden. Dit geldt zowel voor de technische als de niet-technische aspecten.

3.6.1. Elementaire zaken

Zoals u kunt zien is uitgavebeheer wezenlijk willen computers, software en netwerken werken zoals voorzien. Een juiste afhandeling van releases voorkomt storingen. Nieuwe uitgaven of wijzigingen kunnen geïntroduceerd worden terwijl alles normaal blijft werken, zonder onderbreking of kwaliteitsvermindering.

Veranderingen of nieuwe uitgaven doorvoeren kan vergeleken worden met het bouwen van een nieuwe weg. Wagens moeten nog altijd voorbij kunnen, ook als u een nieuwe weg aanlegt bovenop de bestaande. Er moet goede signalisatie aanwezig zijn. Men moet ook de vereiste middelen hebben om de weg opnieuw aan te leggen. Indien u niet over de middelen beschikt om veranderingen door te voeren, is het beter om de dingen zo te laten.

Sommigen zouden kunnen denken dat releasemanagement vervelend is, aangezien men telkens wanneer iets nieuws uitgebracht wordt, niet altijd de meest recente versie mag ontplooien. Maar dikwijls beschikt het interventiedepartement niet over de nodige middelen om een stortvloed aan klachten op te vangen, mocht een opwaardering mislukken. Een hoge mate van betrouwbaarheid vereist het gebruik van degelijke technologie, zoals Linux-expert David Elboth in het Linux Magazine (1/2004) stelde. Hij schrijft:

  • Hoe hogere eisen u stelt aan het systeem, des te dwingender zijn de vereisten die aan de afzonderlijke componenten ervan gesteld worden. Bij hoge betrouwbaarheidseisen blijken de beschikbare keuzemogelijkheden beperkt tot oudere technologieën. Enkel empirische gegevens kunnen na verloop van tijd iets zeggen over de frequentie van storingen. We hebben allemaal kunnen vaststellen hoe ver Red Hat en !SuSE met hun serverproducten achterop lopen.

Wilt u weinig klachten krijgen dankzij een stabiele en betrouwbare omgeving, dan is degelijk uitgavebeheer vereist. Anders krijgt men af te rekenen met een hoop klachten en steken ontevreden gebruikers de kop op omdat onvoldoende getest allermodernste software geïnstalleerd wordt. Amateurs hebben de neiging de consequenties van softwareopwaarderingen te onderschatten. Indien iets goed werkt op uw persoonlijke computer, betekent dat nog niet dat dit zal werken in een groot netwerk met 500 client-computers en 3200 gebruikers.

3.6.2. Programmatuurbibliotheek (Definitive Software Library - DSL)

In een bedrijfscontext is een softwarearchief een verzameling originele versies van de in gebruik zijnde software. Indien u gebruik maakt van Skolelinux 2.0 is dat het softwarepakket. In sommige andere contexten, in het bijzonder onder programmeurs, wordt de uitdrukking softwarearchief in een andere betekenis gebruikt. In de operationele praktijk bedoelen we er het originele softwarepakket in een bepaalde versie mee, zoals dat gebruikt wordt om de installatie uit te voeren.

Bij het gebruik van vrije software zou het softwarearchief kunnen bestaan uit Skolelinux 2.0 plus de extra programma's die je er uit andere bronnen hebt aan toegevoegd. Het zou bepaalde versies van Macromedia Flash, Java en decoders kunnen bevatten die het mogelijk maken om in de browser nationale tests af te nemen of uitzendingen van een nationaal TV-station te bekijken.

Indien u van plan bent op te waarderen naar de volgende versie van Debian Edu wanneer deze uitgebracht wordt, zal deze nieuwe versie het centrale gedeelte van het programma-archief uitmaken. Het nieuwe archief zal ook de gepaste versies bevatten van alle extra toepassingen naast Debian Edu.

Aangepaste of lokaal door het interventiedepartement gecreëerde instellingenbestanden worden niet opgenomen in het centrale programma-archief. Configuraties worden apart bewaard in een versiecontrolesysteem of een database.

3.6.3. Database voor configuraties en hardware

Zoals vermeld in het hoofdstuk over configuratiemanagement, moet u een database of een onder versiecontrole geplaatste map aanmaken om zorg te dragen voor configuratiebestanden. Men moet ook een overzicht bijhouden van alle computers, welk soort machines in gebruik zijn, hun rendement en de unieke standaardadressen van hun netwerkkaarten (MAC=addressen).

Er zijn veel redenen om een overzicht te behouden over de uitrusting. Een van de belangrijke redenen is om een overzicht te hebben over hoeveel machines in gebruik zijn, hoeveel er niet gebruikt worden en hoeveel er in reparatie zijn. Een andere reden is de planning van opwaarderingen.

3.6.4. Bouwbeheer

Behalve een browser en een bureausoftwaresuite wordt nog een verscheidenheid aan toepassingen geïnstalleerd in scholen. Men heeft onderwijsprogramma's in functie van de opleiding, browserplug-ins en programma's voor multimediatoepassingen nodig. De systemen worden ook gekenmerkt door hun netwerkopstelling en er zijn aangepaste instellingen voor specifieke programma's. Indien u veel servers heeft en misschien duizenden clientcomputers, laat de behoefte aan effectieve hulpmiddelen voor de ontplooiing zichzelf snel voelen. Dergelijke hulpmiddelen zitten standaard in Debian Edu.

Bouwbeheer draait om er zorg voor dragen dat altijd de vereiste softwarepakketten geïnstalleerd worden evenals de vereiste diensten en de passende instellingen voor zowel individuele programma's als voor het netwerk. Veel mensen hebben over de zogenaamde "images" gehoord. Men installeert het besturingssysteem met alle vereiste programma's en configureert het netwerk. Daarna gebruikt men een image-programma om een kopie te maken van de harde schijf. Dit "schijf-image" kan dan naar andere computers gekopieerd worden.

Het is niet nodig om dergelijke schijfimages te bouwen. Debian Edu is gebaseerd op Debian dat beschikt over een excellent systeem voor pakketbeheer. Het compileren van toepassingen is niet nodig, aangezien klaargemaakte pakketten rechtstreeks vanaf het internet geïnstalleerd kunnen worden. Het volstaat om uit te maken welke aanpassingen u wenst ten opzichte van de standaardopstelling van Debian Edu of het centrale programma-archief waarmee gewerkt wordt. Daarna maakt u een of meer scripts die op elke machine uitgevoerd moeten worden, zodat alles geïnstalleerd en ingesteld wordt.

In de meeste situaties is het werken met scripts een gemakkelijke manier om programma's en configuraties te "bouwen" en uit te rollen. Maar er bestaan situaties waarin het bouwen van schijfimages de oplossing kan zijn, bijv. voor een installatie op een groot aantal laptops.

Zoals gezegd draait het bouwproces om het faciliteren van een uitrol op veel computers. In uitzonderlijke gevallen komt daar het bouwen van een op maat gemaakt Debian pakket bij kijken. Maar in de meeste gevallen is alles vooraf verpakt beschikbaar. Dan dient u een script te schrijven en uit te rollen dat extra programma's en bepaalde instellingen installeert. U kunt ook disk-images creëren als u veel identieke machines heeft, zoals een laptop voor elke student.

3.6.5. Uittesten

Het is essentieel dat nieuwe toepassingen, configuraties en nieuwe diensten uitgetest worden vooraleer ze in een werkomgeving ingezet worden. Verschillende scholen werden met instabiliteit geconfronteerd nadat ze software installeerden zonder de noodzakelijke afstelling ervan. Daarom is het essentieel om wijzigingen aan configuraties of nieuwe versies van software te testen voor de aanpassing op alle machines doorgevoerd wordt.

Het testen gebeurt over het algemeen in drie stappen.

  • Vooreerst doet men een installatie van de aanpassingen op een testnetwerk. Dit is een technische test om na te gaan of alles functioneert in een systeem zonder gebruikers. Zorg ervoor om alle aanpassingen op te nemen in de configuratiebestanden.

  • Als u zeker weet dat alles werkt vanuit technisch oogpunt bekeken, probeert u vervolgens de oplossing op één school te installeren. Het is heel belangrijk om deze fase van uittesten te bespreken met de ICT-contactpersoon van de school. Ook gebruikers moeten volledig ingelicht worden over de aanpassingen die voor de test gedaan zullen worden. Zorg ervoor om de huidige aanpassingen aan instellingenbestanden, die misschien tijdens routineonderhoudswerkzaamheden ingevoerd werden, op te slaan.

  • Wanneer u zeker weet dat alles werkt, kunt u de oplossing in alle scholen uitrollen. Het eenvoudigst is om een script te maken dat het opwaarderen van softwarepakketten, diensten en configuraties makkelijker maakt.

3.6.6. Terugvaloptie

Tijdens een nieuwe installatie of een opwaardering kan er veel fout lopen. Daarom moet men een terugvaloptie achter de hand hebben. Dit laat u toe om snel terug te keren naar het systeem zoals het was voor de opwaardering. In technische termen wordt dit benoemd als terugrollen.

Bij het terugrollen is het absoluut van essentieel belang om de vorige versie van het softwarearchief en van de configuratiebestanden bij de hand te hebben. Dit betekent bijvoorbeeld dat u in minder dan een uur Edu 1.0 kunt installeren en de passende configuratiebestanden op hun plaats kunt zetten.

Maar terugrollen vraagt tijd. Daarom kan het voorzichtig zijn om een server klaar te hebben met de vorige versie van de software, de juiste configuraties en een recente kopie van de persoonlijke mappen van de gebruikers. Deze server kan snel een eventuele machine waarop de opwaardering niet volgens plan verloopt, vervangen. Servercomputers in reserve hebben kan zorgen voor een hoge graad van operationaliteit, zelfs als er iets fout gaat.

3.6.7. Voordelen en mogelijke problemen

Het kan niet onderschat worden welk voordeel het biedt om een register te hebben met de software die in gebruik is. Velen betrouwen op het feit dat ze de software ter beschikking hebben op hun respectieve CD's en DVD's. Dit is echter een inefficiënte distributiemethode. Om tijd en moeite te sparen is al de software in Debian Edu online beschikbaar.

Uw interventieafdeling kan op een centrale server een kopie maken van het archief van Debian Edu. Van daaruit kan alle software snel en vlot geïnstalleerd worden op andere machines. Het voordeel is dat uw ICT-dienst een permanent overzicht heeft over de versies van de software die ze ter beschikking gesteld hebben aan de scholen. Dit vermijdt ook het installeren van software die niet nagekeken werd door het wijzigingsbeheer.

Er kunnen zich aanzienlijke problemen manifesteren indien u het softwarearchief en de configuratie-instellingen niet onderhoudt. Het kan ook gebeuren dat men een fout maakt bij een configuratie of een softwarepakket. Dan wordt die naar alle machines uitgerold. Daarenboven kunnen sommige scholen onvoldoende geteste software installeren of bèta-releases gebruiken in hun werkomgeving. Men moet dus over goede processen beschikken en over iemand die verantwoordelijk is voor het onderhoud van het programma-archief en de configuratie-instellingen.

Het kan erop lijken dat men een heleboel zaken voorhanden moet hebben om de in gebruik zijnde diensten en programma's te installeren en te onderhouden. Indien u echter de hulpmiddelen die het mogelijk maken om controle te houden over een opwaardering, links laat liggen, bezorgt u zichzelf een boel extra werk. De ICT-dienst moet dan een boel tijd spenderen aan het handmatig installeren van elke machine afzonderlijk. Het gevaar neemt dan toe dat er fouten gemaakt worden. Als bepaalde zaken niet werken, krijgt u misnoegde gebruikers en moet u veel tijd spenderen aan het repareren van problemen.

Velen die uitgebreide IT-systemen beheren hebben geen adequate plannen voor aanpassingen die te gebeuren staan. Sommigen hebben helemaal geen plan, maar waarderen de software gewoon op naar de laatste release. Doorgevoerde wijzigingen kunnen door sommige gebruikers als problematisch ervaren worden, omdat functies waarmee ze vertrouwd waren naar een andere plaats in de gebruikersinterface verplaatst werden. De goede werking kan volledig in het honderd lopen. Toen men bijvoorbeeld in de gemeente Arendal probeerde op te waarderen van een oudere naar een meer recente versie van Windows, stopte ongeveer alles met werken. Het IT-departement vertelde dat men verschillende computerprogramma's "met haken en ogen" aan elkaar hangen had. Het heeft een half jaar gevergd om alles op te ruimen.

3.6.8. Planning en uitvoering

De reden waarom er gepland moet worden voor het uitvoeren van aanpassingen is om te vermijden dat er weken of maanden vertraging ontstaat ten gevolge van problemen. De tijd die geïnvesteerd wordt in planning, wordt snel teruggewonnen doordat extra problemen vermeden worden. Er zullen altijd mensen zijn die beweren dat ze geen problemen gehad hebben met ad hoc aanpassingen aan het systeem. Een nader onderzoek toont echter aan dat er zich na dergelijke wijzigingen problemen manifesteren, maar dat ze alleen niet gecommuniceerd worden.

In onze ogen zijn ad-hocoplossingen bij een veranderingsproces niet meer of minder dan omwegen die enkel nuttig zijn als noodmaatregel. Een ad-hocoplossing is als een tijdelijke reparatie die met "haken en ogen" aan elkaar hangt. Mettertijd moet men dergelijke oplossingen opruimen om een stabiele werking te garanderen zonder voortdurende verrassingen. Een planningsfase overslaan leidt tot meer ad-hocoplossingen en tot verschillende functioneringsproblemen wanneer wijzigingen of opwaarderingen doorgevoerd worden. Om die reden is het essentieel dat de beroepskrachten en de directie de waarde begrijpen van een goed gepland veranderingsproces.

Daarom bevelen we aan dat u een planningsvergadering belegt en een fasegewijs plan ontwikkelt voor aanpassingen aan het systeem. Het fasegewijs plan zal natuurlijk verschillen naargelang de aanpassing. Het opwaarderen van de OpenOffice.org-suite is nogal verschillend van een opwaardering van het hele systeem. Bij een opwaardering naar een nieuwe kantoortoepassing, kan in elke school een rondleiding door de kantoorsuite voor de leerkrachten gedurende 2-3 uur volstaan. Bij het opwaarderen van het volledige systeem moet men zowel voorzien in een training voor de gebruikers en moet men uittesten dat op technisch vlak alles naar wens functioneert.

Het belangrijkste gegeven is dat planning en uitvoering simpel zijn. Onderzoekingen tonen aan dat wanneer men behoorlijk plant en zorgt dat de mensen over de juiste vaardigheden beschikken, de werkzaamheden een geringere kostprijs hebben.

3.6.9. Activiteiten

Het is essentieel om nieuwe releases te plannen. De meeste aanpassingen aan het systeem moeten met de directie uitgeklaard worden. De volgende lijst van werkzaamheden werd ontwikkeld ter ondersteuning van de plannings- en implementatiefase van opwaarderingen.

Taken

Bijzonderheden

Prioriteitsbepaling van de release:

Nagaan of de nodige beslissingen genomen werden vooraleer een wijziging of opwaardering uitgevoerd wordt.

Uiteindelijke softwarebibliotheek

Zich ervan verzekeren dat de passende softwarepakketten die geïnstalleerd moeten worden, aanwezig zijn in de definitieve softwarebibliotheek.

Configuratiedatabank

Zorg ervoor dat alle configuratiebestanden aanwezig zijn. Dit heeft zowel betrekking op die welke in gebruik zijn als op de nieuwe die geplaatst worden op de systemen die gewijzigd of opgewaardeerd moeten worden

Bouwbeheer

Alle scripts en systemen die gebruikt worden bij het aanwenden of aanmaken van schijfimages moeten aanwezig zijn.

Uittesten

Voer eerst testen uit op testapparatuur. Indien dit probleemloos verloopt, kan er in een school uitgetest worden. De school moet hierover volledig ingelicht worden en moet er zich ten volle van bewust zijn dat het om het uitproberen van nieuwe software gaat. Als men er zeker van is dat alles naar behoren functioneert, kan men de opwaardering voor alle andere uitvoeren.

Terugvaloptie

Zelfs ondanks uitgebreid testen, kan het bij een nieuwe release fout gaan. Het is daarom essentieel om over een terugvalmogelijkheid te beschikken. De makkelijkste manier is om de oude installatie en de gegevens ervan te bewaren op een aparte servercomputer. Die kan dan terug aangeschakeld worden als de aanpassing of de opwaardering mislukt.

3.6.10. Hulpmiddelen

Zoals we bij de lijst van activiteiten gezien hebben, heeft men verschillende hulpmiddelen nodig voor het opvolgen van de verschillende softwarereleases en van de diensten en de hardware in het systeem. Sommige van die hulpmiddelen werden reeds eerder vermeld. Maar we overlopen ze toch nog eens:

  • Debian hulpmiddelen voor de definitieve softwarebibliotheek

  • Configuratiedatabase en hardware-inventaris (subversion-versiebeheersysteem voor instellingenbestanden en spreadsheets die een overzicht bieden over alle hardware en de fysieke locatie ervan)

  • Bouwbeheer (het systeem dat instaat voor het bouwen van Debian pakketten)

  • Hardware voor testdoeleinden en als back-upoplossing

3.6.11. Relaties met andere processen

Het uitgavebeheer valt te situeren bij de kerntaken van de ICT-diensten. Het betreft het toepassen van passende beveiligingsupdates, wijzigingen aan de diensten of opwaarderingen van computersoftware. Een verzoek voor een nieuwe release kan verband houden met operationele problemen of met het verlangen naar nieuwe software. Een afweging of de wijziging noodzakelijk is gaat aan het toepassen van de nieuwe release vooraf.

Indien het een eenvoudige wijziging betreft, kan men de vereiste aanpassingen in de configuratie maken en de vereiste pakketten met toepassingssoftware klaarmaken voor aanwending. Dan zou men dit moeten uittesten en er moeten voor zorgen dat men een noodoplossing achter de hand heeft. Wanneer de wijzigingen doorgevoerd worden, zal men misschien onderdelen van de werkmethode moeten bijstellen. Het valt niet moeilijk om in te zien dat wijzigingsbeheer een invloed heeft op alle aspecten van de operationele ondersteuning.

3.7. Hulpmiddelen voor operationele ondersteuning

De eerste vraag die men zich zou moeten stellen is: "Hebben we echt softwarehulpmiddelen nodig?" Indien het antwoord daarop ja is, is het van essentieel belang om de opties grondig te onderzoeken.

Als men de glitterbrochures en de woorden van handelsvertegenwoordigers moet geloven, kan men niet zonder dergelijke hulpmiddelen. Maar bekwame mensen, goede procesbeschrijvingen, goede procedures en taakomschrijvingen vormen de basis voor een goed dienstenbeheer. Of er behoefte is aan hulpmiddelen en hoe gesofistikeerd die moeten zijn, hangt af van de mate waarin de organisatie behoefte heeft aan computersystemen en van de grootte van de organisatie.

In een kleine organisatie zal een eenvoudige vrij toegankelijke database volstaan voor het bijhouden en beheren van gebeurtenissen (aanvraagopvolgingssysteem). Maar in grotere organisaties zal men bijna zeker behoefte hebben aan een gesofistikeerd gedistribueerd en geïntegreerd gereedschap voor dienstenbeheer. Dit betekent dat alle processen gekoppeld worden aan een systeem voor gebeurtenisverwerking.

Hoewel hulpmiddelen belangrijk kunnen zijn, zijn ze niet inherent belangrijk. Het zijn de uit te voeren taken en processen en de benodigde informatie die belangrijk zijn. Zij zullen de nodige informatie leveren om uit te maken welke hulpmiddelen best geschikt zijn om de interventies te ondersteunen. Hier volgen een aantal redenen waarom men software zou kunnen gebruiken voor operationeel en dienstenbeheer:

  • toegenomen behoeften bij gebruikers

  • gebrek aan ICT-kennis

  • budgetrestricties

  • de organisatie is volledig afhankelijk van de kwaliteit van de dienstverlening

  • het integreren van systemen die van verschillende leveranciers afkomstig zijn

  • toegenomen complexiteit van de ICT-infrastructuur

  • de opkomst van internationale standaarden

  • Groter toepassingsgebied en wijzigingen in ICT

Automatische hulpmiddelen laten toe om:

  • Kernfuncties te centralliseren

  • Functies bij het verstrekken van diensten te automatiseren

  • Gegevens te analyseren

  • Trends te onderkennen

  • Preventieve maatregelen toe te passen

3.7.1. Soort gereedschap

In dit hoofdstuk stellen we een aantal hulpmiddelen voor ter verbetering van de operationele ondersteuning. Hierna volgt een samenvatting van de hulpmiddelen:

  • Debian hulpmiddelen voor de definitieve softwarebibliotheek

  • Configuratiedatabase en hardware-inventaris (subversion-versiebeheersysteem voor instellingenbestanden en spreadsheets die een overzicht bieden over alle hardware en de fysieke locatie ervan)

  • Bouwbeheer (het systeem dat instaat voor het bouwen van Debian pakketten)

  • Hardware voor testdoeleinden en als back-upoplossing

  • Aanvraagopvolgingssysteem (Request Tracker)

  • Monitoringsysteem (Munin)

Naarmate het departement voor interventies meer ervaring opdoet met systematische werkmethodes, zullen meer en verschillende types hulpmiddelen ontwikkeld of aangeschaft worden.

3.7.2. Evaluatiecriteria bij het selecteren van hulpmiddelen

Hoewel een grote hoeveelheid geld geïnvesteerd werd in het ontwikkelen van evaluatiecriteria voor software, is het enige resultaat ervan op ervaring gestoelde richtlijnen. Een definitief antwoord op wat goede en minder goede software is, is er niet gekomen. Zoals bij veel andere zaken, draait het ten dele om smaak. Verschillende alternatieven kunnen dezelfde taak even goed uitvoeren, maar kunnen een heel verschillende vorm aannemen. Toch kunnen hier sommige vuistregels nuttig zijn.

Het belangrijkste evaluatiecriterium is of men überhaupt een taak uit te voeren heeft. Veel IT-hulpmiddelen zijn absoluut perfect en functioneren foutloos, maar lossen problemen op die niet opgelost moeten worden. Het belangrijkste criterium is daarom of het juiste probleem opgelost wordt en of het überhaupt nodig is om iets te ondernemen.

  • De eerste vraag die men zich dus moet stellen is, of het hulpmiddel nodig is.

Als blijkt dat men een taak te vervullen heeft, kan een simpele oplossing er misschien in bestaan om een aantal commando's handmatig uit te voeren. De simpelste werkwijze is de beste. Maar wanneer men verschillende machines moet onderhouden, wordt automatisering cruciaal. Het is te omslachtig om in te loggen bij 20 identieke servermachines om een beveiligingsupdate uit te voeren. Dan is automatisering de marsrichting.

  • De vraag die men zich hier dus moet stellen is of het hulpmiddel nuttig is om de taak te volbrengen

  • Daarna moet men zich afvragen of het hulpmiddel bruikbaar is.

Vaak bestaat er een ruim scala aan programma's en werkwijzen om een specifieke taak te volbrengen. Maar sommige problemen worden op een heel andere manier opgelost wanneer men 500 computers en 11 servers onderhoudt, dan wanneer men gewoon iets moet aanpassen aan zijn PC thuis. Een mogelijk voorbeeld zijn hulpmiddelen die de leerkracht toelaat om de grafische werkomgeving van elke student te zien op zijn/haar client-machine. De leerkracht kan voor alle leerlingen programma's starten en beëindigen en kan bijvoorbeeld individuele leerlingen beletten om een chat-programma te gebruiken als dit binnen de onderwijscontext ongepast is.

Bij de keuze van interventiegereedschap draait het om automatisering en vereenvoudiging van de interventietaken. Het gaat erom het handmatige werk tot een minimum te beperken. Het doel is om enkel de automatisering te moeten onderhouden. Ook in dit geval is het mogelijk om de zaken eenvoudig te maken, hetgeen reeds een aanzienlijke taak kan zijn.

Zoals u kunt zien, is het niet eenvoudig om goede criteria voorop te stellen voor de selectie van interventiegereedschap voor grote installaties. Dit is vooral omdat softwareontwikkelaars vaak geen ervaring hebben met het beheren van IT-systemen. Zij zijn enkel vertrouwd met het creëren van nieuwe dingen, maar het ontwikkelen van goede en relevante interventiehulpmiddelen vereist vele jaren ervaring.

Sommige algemene interventiehulpmiddelen werden de laatste 20 jaar niet meer vervangen. Maar de gebruikte producten kunnen wel vervangen zijn. Ook kan bepaalde software op enkele jaren tijd irrelevant geworden zijn. Daarom moet men bereid zijn om zich bij te scholen over het gebruik van nieuwe versies van toepassingen die bij interventies gebruikt worden en over opwaarderingen van en wijzigingen aan eindgebruikerssoftware.

3.7.3. Producttraining

Grondige training van gebruikers maakt dat een boel ondersteuningsproblemen informeel opgelost geraken via rechtstreekse communicatie tussen eindgebruikers zelf. Vaak bedragen de kosten voor training niet meer dan 1% van de globale werkingskosten. Het loont de moeite om iets meer aan training te spenderen. Het effect ervan is zeer positief. Hetzelfde geldt voor een passende training voor de ICT-contactpersonen op de scholen en voor de interventiemedewerkers. Training van ICT-contactpersonen in het gebruiken van eenvoudige systemen voor het wijzigen van wachtwoorden, voor foutmeldingen, enz., zal bijdragen tot een betere kwaliteit van de oproepen voor de IT-dienst.

In Noorwegen wordt producttraining in het onderwijs geregeld overeenkomstig de Arbeidswet (§ 4-2)

  • Werknemers en hun vakbondsvertegenwoordigers moeten op de hoogte gehouden worden van de systemen die gebruikt worden in de plannings- en implementatiefase. Zij moeten de nodige training krijgen om zich vertrouwd te maken met deze systemen en zij moeten betrokken worden bij het uittekenen ervan.

Kortom, het kan voordelig zijn om de inspanningen inzake training te verhogen, hetgeen de kwaliteit van de ICT-dienstverlening zal verhogen en een significante kostenvermindering met zich mee kan brengen. Dit is omdat gebruikers en IT-contactpersonen meer vertrouwen krijgen en beter worden in het helpen van elkaar. Er dient ook opgemerkt te worden dat de overschakeling op nieuwe software ook een opportuniteit kan bieden voor het vereenvoudigen van sommige werkwijzen. Een vereenvoudiging kan de nood aan producttraining verminderen.

3.8. Planning bij het begin van de implementatie van service-ondersteuning

Een groeiend aantal organisaties ziet de noodzaak in van servicecontrole. Het is vaak een gangbare praktijk om beslissingen te baseren op historische en politieke overwegingen, in plaats van op de huidige noden van de organisatie. Daarom is het belangrijk om te verzekeren dat de directie zich engageert in het participeren aan de werkmethodes van de organisatie en in het begrijpen ervan en om de bestaande processen te overlopen en deze te toetsen aan de noden van de organisatie en aan "goede praktijken".

3.8.1. Service-ondersteuning toepassen

Doorlichting

3.8.2. Haalbaarheidsstudie

< FIXME>

3.8.3. De huidige situatie omschrijven

Doorlichting

3.8.4. Algemene richtlijnen voor projectplanning

Zakelijke argumenten voor het project

Kritische succesfactoren en mogelijke problemen

Projectkosten

Organisatie

Product

Planning

Communicatieplan

3.8.5. Projectbeoordeling en rapportage

Voortgang

Evaluatie van het project

Bijkomend werk.

Toetsing om na te gaan of beantwoord wordt aan de kwaliteitsparameters

Toetsing met betrekking tot de kernfactoren

4. Dienstverlening

Het hoofddoel van dienstverlening is proactieve interventies te garanderen en ervoor te zorgen dat de ICT-diensten passende ondersteuning bieden aan de gebruikers. Het doel van de dienstverlening is te focussen op de behoeften van uw organisatie. Het gaat om actief leren met gebruikmaking van ICT-hulpmiddelen in de onderscheiden domeinen van de noden van de school. Achtereenvolgens behandelt dit hoofdstuk:

  • Dienstenniveaubeheer

  • Kostenbeheer

  • Capaciteitsbeheer

  • Capaciteitsplanning

  • Toegangscontrole

  • Operationele continuïteit

4.1. Dienstenniveaubeheer

Dienstenniveaubeheer (Service Level Management) wordt vaak afgekort met het letterwoord SLA. Het beheren van het dienstenniveau houdt verband met de kwaliteit van de operationele diensten, gemeten in relatie tot wat in een contract overeengekomen is. Er zijn absoluut concrete maatstaven voor beschikbaarheid, antwoordtijden, ondersteuning, foutenherstel, enz.

Het doel is controle te houden over het dienstenniveau en de kwaliteit van de operationele diensten te verhogen. In achtereenvolgende stappen wordt het kwaliteitsniveau vastgelegd, opgevolgd en gerapporteerd, Het doel is het contact tussen ICT-beheerders en gebruikers te verbeteren en te komen tot het leveren van een ICT-dienst die in overeenstemming is met de overeengekomen kwaliteit.

Het is van belang om de verschillende types SLA te begrijpen. Er is keuze mogelijk uit verschillende types overeenkomsten. De drie meest voorkomende types zijn:

  • Een overeenkomst per dienst voor alle klanten

  • Een overeenkomst per klant voor alle diensten

  • Een overeenkomst per dienst per klant

Alle SLA's moeten beheerd, gerapporteerd en onderhouden worden. Dit kan al snel verwarrend worden en veel werk met zich meebrengen dat geen specifiek voordeel oplevert. Het doel is een overeenkomst te bekomen die de kwaliteit van de dienstverlening helpt te verhogen. Daarom is het van belang om dit grondig te overdenken bij het opstellen van de overeenkomst. Hierna volgt een overzicht van waarvan men zich zeker moet vergewissen bij het opmaken van een overeenkomst in verband met het dienstenniveaubeheer.

4.1.1. Algemene checklist

  • De overeenkomst tussen de gebruiker en de interventiedienst over wat feitelijk gemeten wordt. Dit moet bekeken worden vanuit het perspectief van de gebruiker en niet vanuit het perspectief van de ICT-diensten.

  • Meting van en duidelijkheid over de maatstaven die in het SLA vervat zijn

  • Leg realistische doelen vast voor het dienstverleningsniveau (meer beloven dan men kan waarmaken heeft geen zin)

  • Volgehouden focus op de controle van de dienst - opvolging van en periodieke rapportage over de bereikte resultaten.

4.1.2. Planning

Het is essentieel dat het interventiecentrum over de technisch capaciteit beschikt om de waardemetingen die in het SLA opgenomen werden, uit te voeren. Van bij het begin moet men hiermee rekening houden.

Bovendien is het belangrijk om de diensten te omschrijven waarvoor men afhankelijk is van onderaannemers en waarvoor men zodoende geen servicegaranties kan bieden of waarvoor men zich steunt op een vergelijkbare overeenkomst met de onderaannemer. De omschrijving van afhankelijkheden gebeurt omdat het duidelijk moet zijn wie verantwoordelijk is voor het verhelpen van problemen en om te vermijden dat eindeloze onderhandelingen gevoerd moeten worden vooraleer een fout hersteld wordt.

Het niveau van de dienstverlening kan verschillend zijn voor verschillende gebruikersgroepen of gedurende verschillende periodes van een schooljaar. Er kunnen bijvoorbeeld verschillen zijn tussen leerkrachten en studenten, of er kan een hogere kwaliteit van dienstverlening zijn tijdens de examens. Dialoog met alle relevante gebruikers is belangrijk om te verzekeren dat metingen gebeuren in verband met wat belangrijk is voor elk van de gebruikersgroepen.

4.1.3. Implementatie

Een dienstencatalogus met alle diensten die in het SLA opgenomen zijn, moet voorbereid worden. In dit repertorium zal een dienst vaak een applicatie (programma) zijn. Aan verschillende diensten zullen vaak verschillende vereisten gesteld worden en dit zal in de overeenkomst weerspiegeld worden in de vorm van verschillende objectieven.

Het belang van het vaststellen en permanent bijstellen van de verwachtingen van de gebruikers kan niet overschat worden. Vaak hebben gebruikers overtrokken verwachtingen naar het systeem en de erin vervatte diensten. Het is de verantwoordelijkheid van de ICT-diensten om de verwachtingen naar een realistisch niveau terug te brengen voordat de dienstenniveauovereenkomst (SLA) ondertekend wordt. Het management van de interventiedienst moet er ook voor zorgen dat alle gebruikers effectief ingelicht worden over en op de hoogte zijn van het volgens de overeenkomst verwachte dienstverleningsniveau.

Raadpleeg voor de structuur van het SLA het hoofdstuk in de dienstenniveauovereenkomst.

4.1.4. The operational situation

Monitoring of the actually achieved service levels, and reporting back to the customer, are essential to preserve a good relationship between the Service Desk and the users. Format and levels of detail for reporting, should be dealt with in the SLA.

It must be held periodic, for example quarterly or semiannually, meetings with the client. These meetings should result in concrete plans for the next period and, possibly, agreements for the implementation of new services.

4.1.5. Content of the Service Level Agreement (SLA)

4.1.5.1. Introduction

Name and contact information for the Contracting Parties, description of the services included, duration of the agreement, responsibilities between the customer and the supplier.

4.1.5.2. Service time

During which time period would the agreement be valid (like from Monday to Friday, from 8:00 a.m. to 4:00 p.m.), any special requirements at defined dates and times (for example exams) and routines to order an expansion of the service time limits.

4.1.5.3. Availability

Access to the services. Is best measured as the period of time when one or more services have been unavailable, for example a calendar month. Different levels for different services may be agreed, for example depending on the degree of importance for users.

Important to emphasise that this is availability within the agreed period of service, not the overall availability all day, all week and all year round (called 24/7/365). For example, it may be agreed that the system should be available between 8:00 and 18:00 on workdays, after that and on weekends it is more uncertain whether one can use the computer system, unless otherwise agreed.

Availability also means getting support via phone or email. For example, whether the Service Desk can be reached between 08 and 16 during the day time, or if it can be reached the whole day, or in the afternoons and evenings, or even during specific weekends.

4.1.5.4. Stability

Is often measured according to the amount of downtime in a period of time, or the average time between downtimes. One can also measure the time it takes the system to come up again after downtime.

4.1.5.5. Support

Often measured as response times by phone (for example 1 minute) or email (for example 30 minutes) to requests from users. When the operator gets a request for support, the message will be categorized by severity with a time guarantee for answers. There may also be an agreement about how quickly error correction will start, which will depend on what kind of inquiry was received.

The support is also about when during the day or night one can reach people. Should support be available during school hours between 08 and 16 o'clock, or should one also have support throughout the evening or on weekends. Some will have support also on certain holidays.

The period when support is available is usually in the SLA. It is also agreed what support will be available, with a fixed price, and what must be resolved additionally on an assignment basis. The agreement regulates the process of handling enquiries, both what to fix, and when this will happen.

4.1.5.6. Capacity

Can be measured as the average response time by certain operations in specific applications. Will measure user experience of the system.

4.1.5.7. Change management

Measurement for the management, approval and implementation times of change requests from the users.

4.1.5.8. Security

Can be measured as the number of ascertained security incidents in a period. It is very important to be clear on each user's responsibility to ensure that warranties will apply.

4.1.5.9. Billing

Prices, times for billing and settlement provisions.

4.1.5.10. Reporting and follow-up

Description of rules and periods for reporting of measured service levels. Regular meetings are recommended, for example quarterly, to go through the report and plan ahead.

4.1.5.11. Sanctions and possible incentives

Rules for price reduction if the agreed service is not met. Escalation procedures and rules for cancellation of agreement by continuous violations of guaranteed service level. Possible incentives for achievement or better than expected service.

See Appendix A for SLA.

4.2. Financial Management

Organisations rarely have a full overview of their ICT spending. A 2001-survey of Norwegian municipalities showed that only 1 of 8 municipalities had an ICT budget. It is probably not better for schools. Putting in place an ICT budget is important. Often users think they pay too much for a service they are not happy with. This often creates conflicts between users and the ICT department.

It is very useful for both the operations center and the users to document the real ICT costs. Without this, it is difficult to budget appropriately. And mostly, it is difficult to make a cost/benefit assessment of existing ICT solutions. The rector should know the ICT budget as well as she would know the salary budget, or the budget for the teaching aids.

There are three major key processes related to financial management of ICT services:

  1. Budgeting

  2. Accounting

  3. Billing

4.2.1. Budgeting

The objective of the budget is to make a realistic estimate of the expected ICT costs. Budgeting usually contains various alternative solutions. It applies both to equipment and software, and the level you aspire to. The budget is the starting point for subsequent budget negotiations with the director of education and/or politicians.

Budget must include both personnel and equipment costs. Some organisations only count the cost to buy equipment, omitting as much as 60 - 70 % in personnel costs for the operation of an ICT-solution. One must also get all of the equipment.

There are examples of municipalities forgetting to count the cost of power connectors and computer networks in schools. Then you have forgotten about 2000 NOK (10 NOK = 0.85 GBP/1.18 EUR) per client machine. For 70 new computers, we need about 140,000 NOK for computer networks and power.

Alternative solutions are also important to include in the budget. This applies both for the operation and the equipment. Today there are several vendors who specialize in the operation of computer equipment in schools with varying prices and quality. The number of simultaneous users, and type of machines and software to be maintained, is important.

If one would like to have laptops for all teachers and students one will easily get 5-6 times higher costs than if one had desktops with three students for each client machine.

4.2.2. Accounting

Accounting will mainly consist of invoices for purchased equipment, cabling, repair, operations and extra services. When the accounting period is over, it is important to go through the numbers and compare this with the budget.

4.2.3. Planning the accounting and billing

Not all municipalities have accounting systems that show ICT costs detailed by school. There may be practical reasons for that, such as discounts and similar that the municipality gets centrally. Therefore it is important to do some planning so that you get an overview of what were the costs for operations and procurement when the accounting is assessed against the budget.

Some organisations may have cumbersome and costly accounting procedures. You quickly get extra charges if you pay bills late, or there are many who must approve a payment, for instance. So it is important to agree on good billing practices in procurement and operations in order to have control, as well as to handle payments on time without long decision processes.

4.2.4. Implementatie

The payment method is regulated by the SLA. When it gets to the accounting system, one must agree with the finance department for a convenient way to get out the reports, in order to get the necessary accounting overview of ICT costs without it taking a long time to be generated.

4.2.5. Daily operation

Regarding contracts one will usually have a fixed monthly billing consisting of a fixed amount and possible additional services. Billing is done from the accounting office based on the current operations' contracts, and the extra services performed. It is important to have good and frequent contact with the accounting service based on the tasks carried out for the customer.

4.3. Capacity Management

Capacity planning is used to ensure that all parts of the ICT solution have sufficient capacity to safeguard users' requirements. This includes:

  • Monitoring the performance of ICT services and their related infrastructure

  • Configuration of the systems to ensure they are optimally utilised to what the users actually do

  • Understanding the user needs and planning for possible changes in the systems to take care of future needs

  • Resource planning in cooperation with the budget officer

  • Preparation of a capacity plan to ensure delivery of operations in accordance with the agreed upon service level

Capacity planning is all about balance:

  • Costs against capacity. The budget limits what kind of possible solutions one can implement

  • Supply and demand. The systems must have the capacity to handle the demands set by the users

The objective of capacity planning is to avoid surprises.

4.3.1. Monitoring

It is essential for good capacity planning that the systems are continuously monitored to obtain the necessary data.

Typical data that is monitored is:

  • Processor utilization

  • Memory utilization

  • CPU usage per task

  • Response time per task for users

  • Printer management - the number of prints, queue length, time for print outs

  • Storage capacity

  • Number of clients

  • Number of logins

  • Number of simultaneous users

In Debian Edu, Nagios is used as a monitoring tool.

4.3.2. Analysis

On the basis of data collected from monitoring routines, one tries to identify any bottlenecks in the systems. Examples:

  • Poor or varying utilization of the hardware

  • Poorly designed software

  • Poor utilization of memory capacity

  • Bottlenecks on data storage, memory or processor

  • Bottlenecks in the network

4.3.3. Configuration

If the data analysis uncovers bottlenecks, one needs to try to set up the system in a way that better caters for the users' needs.

Here is a list of commonly encountered bottlenecks and what to do to get rid of them:

Bottlenecks

Actions

Missing sound, USB stick support and DVD on thin clients.

Install diskless workstations (> 800 MHz processor, > 256 MB RAM)

Has 60 thin clients connected to the server and wants more PCs.

Go for diskless clients, or install another thin client server

Thin clients run slowly after we expanded with 20 pieces without acquiring a new server machine

Install 2GB more memory on the server machine

Thin clients with 32MB memory do not start after upgrading to Skolelinux 2.0

Turn on swapping on the thin clients, or downgrade to LTSP 4.2 which is set up with swap.

Flash animations make the thin clients slow when 50 students are logged into the same server machine

Install diskless clients

4.3.4. Implementatie

Implementation of possible changes to the system configuration must be done in accordance with the guidelines set for changes of the system. A well-planned function and performance test must also be done before changes can be made in the production system. Testing is done to avoid operational disturbances when changes are set into production.

4.3.5. Preparing the capacity plan

A capacity plan is basically an investment plan for the ICT system based on knowledge of the users' current needs and future plans.

The capacity plan should be updated and processed once a year, normally in conjunction with the budget process. The plan should include the following themes:

  • Introduction

  • Preconditions

  • Summary

  • Current and future user needs

  • Service summary

  • Resource summary

  • Areas for improvement

  • Cost model

  • Recommendation

4.4. Availability management

Good and stable availability of ICT services is obviously crucial for users.

Availability, seen from the user perspective, depends on the following assumptions:

  • Availability of technical components

  • Failure tolerance

  • Quality of maintenance and support

  • Procedures and routines for processing operational services

  • Security, integrity and availability of data

Availability can be measured in several ways. But before we show examples we'll point out what may be difficult targeting figures. If we should make systematic efforts to availability, we have to clarify what the different things mean. What means for example a percentage of availability.

Let's say a "computer with computer program" is a service. If the computer program does not work one day, then the service is unavailable if all the other programs work fine. What if the computer program is unavailable for a classroom, but available for the rest of the school (because of an underlying service). This is a difficult matter to clarify and work on in practice.

4.4.1. Availability measurements

Availability can be measured using several methods. Here are some examples:

Value

Meaning

% available

The value can be availability between hours 08:00 and 18:00. If the system is down 1 hour during one day, than the system is available in 90% of the agreed upon time. If availability is measured over a month with 20 work days, then the system is available 95% of the time.

% unavailable

Is the system down one hour during an agreed uptime, for example 10 hours a day, the system is unavailable in 10% of the time. Measured over 20 days, we may assume the system has been unavailable for 5% of the time.

Downtime

One can agree on the number of times one accepts the system to be unavailable during, for example, one month (20 days). It can be a maximum of one hour unavailability in that period, and between 08:00 until 18:00.

Error frequency

Even error frequency can be measured per day or for each month. 3 errors in the month because the system was down between 08:00 and 18:00, is an example.

Error consequences

Measured values are a common starting point for judging how to respond to an error beyond ordinary error correction. The customer or the school for example, may ask to pay less for the operating agreement for the current month.

The most important is that your measurements describe the user experience in the best possible way. Therefore, one should measure what is important for the user.

The feedback from the schools is that printers give most problems. This includes everything from the print queue has stopped, to missing paper or toner. Some have also experienced some instability with the browser, and that OpenOffice.org suite is hanging. It may happen when your broadband connection is unstable and you have links in documents going to the Internet.

4.4.2. Infrastructure

To have a stable computing environment, one is dependent on a good enough technical quality of the network. Several schools have experienced instability because the physical computer network is provisional and of poor quality.

Today many invest in wireless networks. Doing so, one must also be aware of wireless networks having significant weaknesses. Wireless networks have limited capacity. It can be quite choppy when about 30 students are to see a film from the Internet simultaneously. Wireless networks also have shadows. Meaning areas may not get coverage, which allows some to end up in blind zones. This would provide poor or no net connection at all.

Availability requirements for the maintenance company and ICT service providers should specify good quality of network services to schools.

4.4.3. «Single points of failure»

Some parts of the system simply must work. Failures in a firewall, for example, may compromise security or (if you're lucky) shut down the whole network. This last can also result from problems with the DHCP (Dynamic Host Configuration Protocol) system for sharing out addresses.

The operating department has a responsibility to know which parts may stop the entire system. It is important to find these points, and remove the errors one by one, to the extent you can afford. If one can't afford to remove these sources of errors, one must live with the risk of the entire computer network suddenly grinding to a halt.

Sources of errors making everything stop, may also be logical rather than physical. This is especially true for computer networks and databases. So it is important to have a broader perspective when it comes to such errors.

4.4.4. Risk management

One must consider what risks one accepts in the network. Is it acceptable that users lose personal files and data, when a hard drive fails? How quickly should one replace broken equipment? Some schools have spent several days getting a server up and running again after a virus attack. The municipality may have no resources to allocate to fix errors.

Much of the operations work goes on to maintain the agreed service level. It's about avoiding and losing confidence and user satisfaction. Risk management is about having in place the appropriate resources to keep the entire computer system on the air, and have resources ready if something should go wrong, and needs to be fixed.

4.4.5. Uittesten

It is a big difference to install equipment and software on a single PC and to do it on hundreds, even thousands of computers. With the responsibility for hundreds of machines, a small error that one can live with on a PC, means much instability and discontent if it affects hundreds of users.

To avoid making mistakes during installation and to contribute to stability, it is essential to test the equipment and software to be used. It's about following up the expected quality. If you want stable operations one must often choose next to the last edition of equipment and software.

One should avoid adopting software with a version number ending with a zero. For example you should avoid OpenOffice.org 4.0. One should adopt the office program when version 4.0.2 has arrived or later. Then the program has been fixed for several errors. The same applies to hardware.

Server machines have usually a slightly older version of processors, and more robust memory, and hard drives. This is because many people use this hardware simultaneously. A small error that would not mean anything for one user, can provide downtime if 30 users are logged into the machine.

So testing is about to use proven equipment and editions of software running well a half or a year. Testing is also about trying out the different parts in a smaller but realistic context, to ensure that everything works. Adopting the latest version, or even beta versions of software or completely latest hardware usually lead to much trouble and extra work with maintenance. Setting systems in production without a small test in realistic environments usually lead to significant firefighting and dissatisfied users.

When testing in a smaller scale on equipment in production, it is essential to coordinate that with those affected. In addition, one must choose when to test. One should not test new things, for example, under ongoing exams, with the use of ICT tools.

4.4.6. Design improvements

It is often worth an operations department's while to enhance systems that produce many operational messages. If users get much spam, then it might be wise to install spam-filters. There might be a lot of extra work with students who constantly forget their passwords, if teachers have to get central sysadmin staff to help them out. To avoid extra emailing and double work, the teacher can be authorised to give the student a new password.

These are two examples of design improvements that simplified maintenance and made users happier. A well-run maintenance team has a prioritised list of such improvements. Prioritising these, as a rule, is based on how often relevant issues show up in the service office's message log and estimates of how much work each improvement shall involve.

4.4.7. Planning for availability

It means having realistic expectations to the ICT service based on what operations costs. Plan for what's the expected accessibility. For example, when schools require one should be up and running in less than 1 hour after the server crashes, one must have a standing pre-installed machine in reserve, to be inserted as a replacement for the faulty machine. What should be done during one hour is to copy your backup files to the backup machine.

For when a diskless or thin client fails, the school should have a small store of machines and monitors prepared. The school ICT contact can fetch and install a replacement machine. This can be done easily without waiting days for an equipment order to be filled.

4.4.8. Planning for recovery

As for equipment standing ready to replace any that develop defects, users also expect to be able to retrieve lost files and data. Therefore it is crucial to back up user data regularly and keep a copy of the configuration files. One must also have architectural diagrams, and descriptions of systems, to enable ICT staff to quickly set systems up when something goes wrong.

It is crucial to schedule backup of user data and settings. One must plan ahead in order to have proper equipment and appropriate services. Routines must be planned to be followed when certain error situations occur and systems must be restored.

4.5. Service Continuity

Operating continuity or continuity management is often the most costly part of the work. High demands to operational continuity will require huge investments, which must be agreed upon whilst making the SLA. For example it can be agreed that there is no disaster plan for certain services. If you have a disaster plan the value is very low if not tested once in a while. Usually this is expensive. There are examples where customers and management have blocked the engine room and turned off power to test readiness of the IT department.

Operating continuity may be more needed in certain periods like under the examination periods. Then extra requirements can be needed in order to have equipments with backup ready in case of a hard disk failure on the server. But even this will require considerable additional work for the operational staff.

An IT coordinator told us that it might be just as well to postpone the exam one day, if something went wrong with the computer system. This costs a lot less than having a double number of servers at each school. There are examples of schools having had water leakage. Then it is usual to defer examination a day or two to repair the damage . One might think the same way when it comes to school data solutions. If you have a backup of home directories for pupils and teachers, you have time to consider without doubling the systems at each school. Then it is sufficient with one or two servers in reserve located at the municipality building, which quickly can be moved and connected at the school if something goes wrong.

5. ICT Infrastructure Management

This part of the operational documentation is to a greater extent about technology. The other chapters about service support and service delivery, are about work processes and procedures. Infrastructure management, are about planning, design, deployment, and ongoing maintenance of ICT systems. The purpose is to provide ICT solutions adapted to the organisation's needs, which can be operated over time to a cost one can afford.

Good planning, administration, and management are the key to ensure a well-developed ICT service, and that the service can be adapted to changing organisational needs over time. It is about using resources well and having skills and competences required to offer a good ICT service.

Even with a well-developed infrastructure, one must expect 60-70% of the cost to go on operations, i.e. service support and service delivery. Likewise, infrastructure constitutes around 20-30% of the total costs, and one must take this part just as seriously as operations. The infrastructure chosen also has a major impact on what operations will cost and what the systems can deliver.

Most people associate infrastructure with roads, water and sewage, and power supply. Building a house requires infrastructure in place if we are to have a certain housing standard. In the computer world infrastructure is often associated with the data network. This was in the 1980s. Over the next two decades infrastructure extended to networks, computers, software and maintenance. So in this part of the documentation is all network, hardware and significant portions of the software part of the infrastructure.

Even here we focus on practical planning and implementation. We have gathered concrete planning data from different municipalities with good ICT plans by budgetting and procurement. We went through design and planning, deployment process, operations process and support. It is important to keep in mind the difference in operational terms of what Service Desk does with, for example. support, and the support operations does for example with network cables to the school. It is basically four processes that recur at infrastructure management:

<ol style="list-style-type: decimal;"> <li><p>Design and planning process</p> <p>Development and maintenance of ICT strategies and processes for deployment and implementation of appropriate solutions in the ICT infrastructure of the organisation.</p></li> <li><p>Deployment process</p> <p>Concerns implementation and deployment of activities and / or ICT solutions designed and planned with a minimum of disruption to the organisation</p></li> <li><p>Operating process</p> <p>All activities and initiatives to deliver and/or maintain the desired use of ICT infrastructure.</p></li> <li><p>Technical support process</p> <p>The development of knowledge for evaluation, support and quality assurance of all current and future infrastructure solutions.</p></li></ol>

5.1. Design and planning

Design and planning is about providing pervasive strategic guidelines for the development and installation of an ICT infrastructure to the institution's needs. It applies not only to infrastructure networks, computers, and applications. Also basic processes must be in place to get the technology to work. It applies to both Service Desk and processes for service management.

Avoiding scheduling, or cutting corners, is very risky. Therefore it is often wise to spend a little more time and effort on planning, which will reduce risk and provide significant benefits during implementation. Most projects that get stranded do so for lack of planning. Putting in place an ITIL process in an organisation depends entirely on preparation and planning, along with effective use of people, processes, and products (tools and technology).

It is very important to communicate with and talk to every part of the organisation while planning ITIL. In Norway this is regulated by the labour act §4-2:

  • Employees and their representatives should be kept informed of systems used in the planning and execution of the work. They should be given the necessary training to be familiar with these systems, and take part in designing them.

The objective is to deliver the right ICT solutions for your organisation. These must be easy to maintain and adapted to the school's needs. The solution must be reasonable over a long time, also when the systems expand. During a design and planning process should one relate generally to a steering group and a reference group. A good project ensures to have skilled people in the steering group and people who contribute to the reference group. A good planner is clever to use those groups and other employees to bring up the good solutions.

We created a check list over activities and deliveries in an infrastructure project.

Feedback

  • Plan for the schools, both curricula and activity plans

  • Existing ICT strategies

  • What's expected of operational services

  • Current ICT systems and operations management

Processes

  • go through all the suggestions and documents

  • look at others performing design- and planning activities

  • making and maintaining ICT plans and decisions

  • making and maintaining ICT architecture

  • making and maintaining the ICT strategy

Deliveries

  • ICT-strategy

  • ICT decisions (with justifications)

  • IT plans

  • the entire IT architecture

  • Design and planning of processes and procedures

  • organisational structure and framework

  • Design, planning standards and decisions

  • SWOT analysis (Strengths, Weaknesses, Opportunities, Threats)

  • user cases and usability studies

  • Requirement lists and tender documents

  • Project plans

  • Technical drawings, plans and maps

  • Comments and feedback

As you can see extensive planning is carried out for an infrastructure project. An ICT project for schools in the municipality can quickly reach several million NOK (hundreds of thousands pounds) should one deliver 500-1000 computers with power, computer networks and software. With such amounts, it is important to have good and feasible plans with realistic budgets.

There are several examples of municipalities that have underestimated the need for funding for ICT in schools. They have installed lots of nice equipments remaining unused. Maybe the software could be missing. The network might be of poor quality or lacking power connectors. The municipality gets quickly an additional expense of 2 million NOK (around 165 000 pounds) if 800 machines in 10 schools should have a computer network and power connectors.

Good development plans are made to avoid surprises. Plans are also made to ensure a proper level of ambition with a realistic budget.

5.2. Deployment

Definition:

  • Is about implementation and deployment of activities and/or ICT solutions designed and planned with a minimum of disturbance for the organisation.

The planning project shall have assessed what equipment schools have, and how much is available. From that, one creates a plan to roll out new equipment, or replace equipment, at each school and at the central operating service.

This is about placing the equipment where it is to be used. Set each PC on a table and connect it to the computer network with a network cable. Plug the power cable in to the electrical outlet. Connect the screen and put network cables in the correct switches.

The term roll-out (or deployment) is used both for placing the equipment, and for installing and configuring software on many machines. Rolling out software may also be referred to as "release management". But the word roll-out is short and fine, although one should make clear whether you are talking about hardware or software, which require totally different procedures.

Rollout management is about implementing what has been planned and designed in the release process. Getting out the equipment where it should be is often harder than we think, and takes considerable time. This is because many parties are involved either to deliver the equipment, or being among the many to receive it. In a way you could say that rollout is the same as a wheel bolt that holds the vehicle wheel in place on the shaft.

To get everything in place, is totally dependent on a lot of coordination. One must make good tactical planning, which involves both change management and project management. One must make sure that the roll out is associated with the design and planning process.

Danger may often occur by underestimating how deployment affects existing systems. Taking in use new solutions or upgrades will affect or change the organisation. Work routines are changed and one gets new ways to solve tasks.

In the school , the change means introducing ICT tools in school subjects. This is new and different for teachers. Many are unfamiliar with how the equipment can be used in teaching. At the same time, an operating and maintenance service should be in place to give schools a safe and stable ICT solution. This leads to changes in the organisation, which must be planned and requires resources. Therefore it is important to take this into consideration both under planning and rollout..

5.2.1. Roles during roll-out

Building an IT infrastructure can be likened to building a house. When building a house one really needs an architect, a builder, an owner, masons, carpenters, plumbers, electricians and one or more supervisors (foremen). Much the same applies to deploying infrastructure. We have summed up the roles recommended as part of the operating standards ITIL.

  • Owner of the deployment process - is responsible for the deployment process, and for it happening in a good and efficient manner.

  • Project manager for the roll-out - is responsible for developing appropriate plans for deployment of the ICT system and day-to-day directing of the roll-out.

  • Coordinator for the roll-out - is responsible for coordinating roll-out activities. The Coordinator shall ensure that the project attains the objectives and acceptance requirements for the system and ensure an orderly handover.

  • Roll-out analyst - responsible for ensuring that equipment is installed in suitable settings. Shall verify that the equipment and premises are suitable for the standards, tests and deployment agreed upon..

  • Employees in the rollout team - are responsible for the ICT solution and the work environment, and support the acceptance and test processes.

As we see, roll-out touches many parts of an organisation. Technically it affects configurations and versions of software and equipment. It also influences the process of change and how work is done at the service.

One must think carefully about who gets assigned each of these roles. Even in a full-scale roll-out project costing several hundred thousand pounds, one person might have several roles. But it is not always prudent to give one person several roles, because it can be very demanding to follow up with both suppliers and customers of the equipment.

For minor upgrades and adjustments, there might be soon too many roles. For example, one needs not to have a project manager to place a new server, or replace a switch. This is part of the infrastructure, but is very close to the operations and maintenance. The important thing here is to distinguish between a rollout in infrastructure, and operational services. The operations department will not take over the equipment before it operates as agreed. In other words, you have a transfer document where one acknowledges that the equipment is delivered as agreed.

5.3. Operations

Definition:

  • The development of knowledge for evaluation, support and quality assurance of all current and future infrastructure solutions.

Operations of the equipment is about having tools and machines in place as the basis for delivering the agreed upon ICT services. Operations of equipment has a strong focus on technology. This supports all other activities being done with the ICT systems. Often operations are seen as support tucked away in an office at the end of the corridor. As a hygiene service" .First when something goes wrong, operations personnel are contacted. A good operational service is still crucial for ICT tools to work properly. Without good operations one accepts the loss of time and that tasks cannot be solved. For example a school can get problems when using tests done with ICT tools.

One may ask whether one needs operations. Needing people to operate in today's high tech world? Is there no one who has found a way to solve operational tasks automatically? Why should you have people in the operations? The answer is usually that balancing between what is done automatically, and what people have to follow up with. An important realization is that most people want someone to talk to when a problem occurs. They want the error to be fixed, and they want feedback that everything goes smoothly. This type of error correction is not particularly easy to replace with machines.

A good operations department chooses to automate where possible. Simultaneously one needs people to monitor and keep control of the automated solutions. The automation must be further developed. There are also situations where automation is insufficient. Equipment breaks, and applications crash. You need someone who is handy and can rectify errors, or obtain substitutes for what cannot be repaired.

A poorly organised operations service wastes a lot of time fighting fires and working through manual procedures which could have been avoided with automation. Time spent automating can quickly pay for itself by freeing up time. This time can be used to improve support, provide more services and raise the quality for users. To get a permanent fix of errors, sometimes people might have to delay upgrades or remove services for temporary repair. This makes time to fix problems properly when monitoring the system manually would otherwise take up all the time.

Operations is mostly about preventing errors, or correcting equipments with reported errors. One is often not entirely familiar with causes of an error. One must troubleshoot to find the fault. Good operations' employees have flair. They use past experience to uncover errors. Then they go almost right to problem solution and correct the error.

5.4. Configuration item

A Configuration Item (CI) is part of an infrastructure. It often describes a wish for change or a question. Maybe to put in place a new service, or make adjustments to the services you already have in production. Often it is a question of upgrading some equipment, or obtaining something new.

Configuration items are important in configuration management when it comes to equipment and infrastructure. Often a configuration item is about whether systems shall:

  • be run

  • be closed

  • be shut down

  • be started

  • be interrupted

  • be removed

5.5. Technical support

Technical support ensures staff are available with the right skills to support services provided in the computer network, as well as staff to work at the Service Desk. As part of technical support one should have in-depth documentation with technical advice. The advice should provide information, guidance and examples of roll-out activities, and describe support and maintenance of all parts of the ICT service. To achieve this, the staff must know, or be able to obtain information, about the technologies, processes and documentation in use. As listed below, technical support consists of several activities:

  • Research and development related to new technology.

  • Third line service in response to incident reports from the Service Desk and general handling of problems.

  • Delivery management - technical support lack in-depth knowledge or understanding of the technology in use and need technical support from others.

  • Coherence of design and planning. Especially in support and documentation. For example, when preparing tender documents.

  • Coherence with the deployment of new system versions, and acceptance in the operating environment.

  • Analysis, interpretation and distribution of information from reports and logs.

  • Tactical assembly of improvements in the quality of the ICT service delivered.

6. A design and planning example

As an example of how infrastructure can be made, we have taken significant portions of the ICT plan for schools in Nittedal 2005-2008. We have made some adjustments, to make it more general and easier for others to copy.

  • Background for the plan

  • What's expected of the ICT tools and services

  • Skills needs

  • Investments

  • Objectives

  • Students and teachers

  • Status and objectives

  • Costs

  • Other purchasing options

  • Software, learning platforms, and services

  • Software and learning platforms

  • Online services

  • Resource usage

  • Centralized operations and roles

  • Operation and support costs

  • Recommendation

  • Attachment

6.1. Background for the plan

In its "Program for Digital Competence 2004-2008", the Ministry of Education and Research sets objectives for the use of digital technology in the Norwegian school. "By 2008 we will have an infrastructure, an organisation and a culture that makes our school system to one of the world leaders when it comes to development and educational use of ICT in teaching and learning."

Being able to use digital tools is defined as a basic skill for all 13 school years. Pupils' development of basic skills is to be given priority in all subjects. The new curricula will mean that students must increasingly make use of digital tools when learning. Pupils should be able to use the same technology in work, that forms the basis for the final assessment, as they use when learning. When the examination is carried out using digital tools, this provides better coherence between the learning process and the final assessment.

A national survey in Norway (Skolenes digitale tilstand 2003, ITU, Feb. 2004) shows computers are seldom included in the subjects in primary school and computers are barely used by pupils in the school.

This plan builds on "Competence Plan for schools in Nittedal (2005-2008)" and implements that competence plan's objectives for digital knowledge in Nittedal's schools. In addition, this is a plan for investment and resource requirements associated with the operation of our Linux network.

6.2. What's expected of the ICT tools and services

We have different objectives for different groups in the school and to different aspects of the ICT commitments. Briefly put, our goals are:

  • Get increased use of ICT among both students and teachers by increasing physical access to ICT equipment.

  • Be tools-oriented, and therefore emphasise the use of ICT tools in the school's subjects.

  • Give full access to educational software for everything from musical composition and use of the Internet to learning to write, simulations and games.

  • Be thrifty and utilise the financial resources we have in the best possible way.

Through these main objectives we will achieve:

  • Teachers get good working and communication tools at work.

  • Students get the opportunity to be personal users of ICT and use ICT as a natural tool in everyday school life.

  • The school will be physically able to fulfill various aspects of the curriculum related to ICT.

  • Operating and maintenance costs are not greater than what the school budget can allow.

6.3. Skills needs

To build and maintain the infrastructure you need a collaboration between many different professionals. As an example, we show what equipment areas you need expertise in. These are equipment areas that form part of the infrastructure in an ordinary school.

  • Network infrastructure with local area network (LAN) and wide area network (WAN). Mostly it is easy to obtain switches and other network equipment. This is off-the-shelf kit. But it must be set up for the planned architecture designed for centralized operations. This is a job for professionals. The municipality building department must approve the changes made.

  • Power supply (230V/110V) supporting client computers, servers and network equipment. Many schools have not installed outlets for all computers to be placed in classrooms, computer labs or the library. It is a job for professionals to plan a power grid with enough sockets, and follow given regulations. The municipality building department must approve the changes made.

  • Servers and clients support a greater variety of network services and end-user applications. To obtain the right equipment is a considerable job. It is about finding equipment with appropriate capacity, good quality, decent guarantee schemes, and low prices.

  • Machine setup and systems for monitoring hardware. To be sure that all equipment is running, it is normally accompanied by remote monitoring systems. That way you can have an overview of the health status of the equipment in a centralized operations center.

  • Designing appropriate environment or room for placement of equipment that needs cooling. Computers and network electronics emit considerable heat. First recently, manufacturers of equipment have addressed the ever-increasing power consumption. Therefore, one must sometimes ensure that the excess heat gets transported away. Such cooling systems need to be installed by professionals.

  • Knowledge of different performance requirements for software. A program for video editing must run on a workstation with >1.5 Ghz processor and ample memory. Other programs may easily be used on a thin client. One must have relatively good knowledge of what can be expected of different types of client machines to choose the right mix of equipment. This requires insight into how computers are intended to be used in different subjects and in different rooms of the school.

  • Installation and setup of optional equipment such as printers, video projectors, computer boards and the like. To set up accessories may quickly take considerable time. For example video projectors need to be screwed into the ceiling, and one must arrange for both screen cables and power to reach them. Printers must have a network point and be connected to the network. This type of installation usually requires professionals for both installation and setup.

Besides to the different professionals needed to build the infrastructure, you will additionally need:

  • Owner of the deployment process - is responsible for the deployment process, and for it happening in a good and efficient manner. This may be the steering group.

  • Project manager for the roll-out - is responsible for developing appropriate plans for deployment of the ICT system and day-to-day directing of the roll-out.

  • Coordinator for the roll-out - responsible for coordinating deployment activities. Coordinator shall ensure the project fulfils the objectives and acceptance requirements that apply to the solution, and ensure an orderly handover. This may be an assistant to the project leader.

  • Deployment analyst - responsible for ensuring an appropriate environment at the locations where the equipment will stand. Shall verify that the equipment and premises are suitable for the agreed standards, tests and deployment. This may be an assistant to the project leader, with the task of reporting deviations from plans to the steering group.

  • Employees in the roll-out team - responsible for ICT solution and the working environment, and support for acceptance and test processes. This is employees who participate in one or more sub-projects.

Organizationally it will look like this

Organisational part

Taken

Reference group

shall represent users of the system. They will advise on measures to promote a good and everyday ICT solution for schools.

Steering group

whose mission is to ensure the project has enough resources and that project management gets the roll-out carried out according to the plans. The group will consist of skilled professionals who are well acquainted with project implementation, system solutions, and the use of ICT tools in schools.

The project

has the task of building the solution. The project usually consists of many sub-projects, which deliver their part of the solution.

6.4. Investments

To meet a new curriculum, schools must have sufficient computers available for their students and staff. This investment plan includes the actual costs of increasing the stock of computers at schools to reach national objectives. Those objectives call for at least one client machine or PC per four students. The requirements for equipment shall probably increase in a few years, so we expand that to a PC workstation per three students. All teachers should have access to a computer in their daily work at school.

Today the school net consists of servers and thin clients at the schools, and a shared server for backup in the municipality. Since we can use used computers as client machines in our network, the users' computers are not the most expensive (we buy used equipment and receive donated equipment from industry). The major costs lie in increased need for power outlets in classrooms, and possibly an increase in electricity bills in the schools.

The increased number of concurrent users will also increase support and operational costs. There will also be a need for tables and chairs for the new PC workplaces. In addition, all schools received a broadband connection at a fixed price. Later, we shall illustrate the total cost by doubling the stock of equipment.

Status for pc coverage 01.06.2005 is:

  1. 8.9 students per computer in primary schools

  2. 4.4 students per computer in secondary schools.

Objectives for the students:

Each student group (formerly called classes) should have access to at least five computers, plus the school should have a computer room with a minimum of 15 PCs. In addition the school needs some special equipment for video editing, special education and reading/writing courses.

Objectives for the teachers:

All teachers should have access to a computer in their daily work at school.

Total number of machines:

Status per 01.06.05

Needs 2008

 

Server status

Clients

Laptops

File servers + thin client server:

Clients

Laptops

Holumskogen

1

25

5

2

68

15

Ulverud

1

35

5

2

111

15

Slattum

1

44

8

2

87

15

Rotnes

1

35

5

2

80

15

Sørli

1

31

5

2

60

15

Kirkeby

1

31

5

2

94

15

Hagen

1

7

5

1

46

15

Li

2

70

5

2

130

30

Nittedal

1

55

20

2

110

30

Hakadal

1

45

5

2

52

30

Sum

11

378

68

29

838

195

We envisage a combination of thin clients, diskless clients and laptops. Schools should have an infrastructure making it possible to roll out thin clients in every classroom. Here students can write, calculate, using the internet and make presentations. In addition the school will have the opportunity to lend laptops to different groups. In this way students get close to full PC coverage in certain work situations. The laptops are connected to servers in wireless networks. In this way teaching becomes more flexible.

6.4.1. Pupils

We recommend an investment providing at least one client computer per third student, something the government has stated as a goal for ICT tools in schools. To achieve this we need nearly a doubling of the number of client machines.

6.4.1.1. Status and objectives

To reach our target we need to increase the machine park from 506 to 1033 machines. This is an increase of just under 600 machines. (thin clients, diskless clients and notebooks).

6.4.1.2. Costs

We have counted with these prices, which might be subject to changes:

  • Thin Client: 700 NOK, per piece

  • Server: approx. 50,000, per piece

  • Monitors: 500, per piece

  • Portables: 8,000, per piece

  • Power plug 750, per piece

  • Table/chair: 700, -

  • Increased resource here means increased number of hours for ICT contacts in schools. Here we consider an hourly rate per teacher of NOK 270 (£22.5) - per hour, or NOK 467,100 (£38,925) a year. We also consider somewhat increased resources to central operations of the municipality. We expect slightly less than one new hire in centralized operations for over 1,000 client machines. In addition, ICT contact at each school, training and ICT coordinator.

  • Licence costs. Today, we can install Linux on laptops using the school's existing network. Thus we avoid the rent of Microsoft products such as Windows and Office. School Rates for rental of Microsoft program cost as much as all computers over a period of 5-6 years.

  • Broadband agreement, all schools have broadband connection. Price depends on the individual school agreement.

Recently used equipment have more performance than the machines that were available for 3-4 years ago. If the users machines had 256 MB of memory and 800 MHz processor then those would fit as diskless clients. This simplifies support for using the CD / DVD player, audio, USB stick and similar.

2006

2007

2008

Total

 

Thin clients and diskless workstations

130,000

130,000

130,000

322,000

Servers

500,000

500,000

1,000,000

Monitors

80,000

80,000

80,000

230,000

Laptops

340,000

340,000

340,000

1,020,000

Other: switches, cables,

150,000

150,000

150,000

450,000

Power plug/cables

290,000

290,000

290,000

870,000

Tables/chairs

190,000

190,000

190,000

570,000

Increased resources, operations

700,000

Licence costs for portable machines

40,000

40,000

40,000

120,000

Broadband agreements

100,000

100,000

100,000

300,000

Sum

5,582,000

6.4.1.3. Other purchasing options

There has been a growing interest from politicians, parents and teachers to go over to laptops in secondary schools. Laptops and a wireless network will give schools a completely different flexibility in room layout and teaching.

The problem with only focusing on laptops is:

  • We have to buy Microsoft licenses in addition to the machines.

  • The machines have a lifespan of approximately 3 years. Thus the municipality incurs an annual expenditure to cover new classes in secondary schools.

  • Increased insurance costs

  • A greater need for power outlets when all laptops must have access to electricity.

  • Increased need for the schools ICT-contact resources

  • Doubling of central operating costs of preparing the disk images etc. for laptops, and maintenance of a locally-installed system on 266 additional laptops.

This option has a total price tag of roughly 12 million NOK, just over 1 million pounds. (This does not include any increase in insurance costs.)

6.4.2. Teachers

Each teacher should have access to a client machine at the school.

6.4.2.1. Status and objectives

Status: Schools today have approximately 65 PCs divided among approximately 266 employees. This gives a PC coverage of 4 teachers per PC.

We want to give credits to the teachers in Nittedal. The new curriculum sets high requirements for teachers' ICT skills. It will be necessary to ensure that all teachers in Nittedal have access to a computer. Today's teacher plans and implements teaching on and with data. They document and report, write weekly plans, work plans, annual plans and IEPs. More and more teachers use e-mail for contact both at home and school.

Schools have already arranged to buy computers for their staff. As a result, the number of computers varies from school to school. We aim to give each teacher access to a computer at work.

Here we outline two options to achieve full PC coverage for teachers in Nittedal.

6.4.2.2. Costs

Option 1: Thin clients in combination with portables. This will give each teacher access to a thin client + that 3.3 teachers share access to one laptop.

cost

Total cost

  
   

Alternative 1

Thin clients

140,000

 

Monitors

100,000

  

Laptops

640,000

  

Other: switches, cables,

80,000

  

Tables, chairs

140,000

  

Power plug/cables

400,000

  

License costs

40,000

  

Total

1,540,000

 

Additional for flatscreen

200,000

  

Totally with LCD

1,740,000

 

The advantage of the thin clients to teachers are the low cost of procurement. We can also expect a longer lifetime of the thin clients compared to laptops.

But reused equipment is often without flatscreen. Client machines' cabinets can be large, giving space shortage in the workplace for teachers. Should we obtain a flatscreen to all teachers, one must triple the cost, going from 500, - NOK ( 43 £ ) to 1500, - NOK. The total cost would increase by 200,000 NOK. Overall equipment to teachers cost 1.74 million NOK ( 150,000 £ ).

6.4.2.3. Other purchasing options

Option 2: Portables for all teachers

cost

Total cost

  
   

Alternative 2

Laptops

2,128,000

 

Wireless switches

80,000

  

Power plug

75,000

  

License costs

117,000

  

2,400,000

  

The problem we see is the actual location of the thin clients. Teachers have small work desks often in large common rooms. A thin client per teacher with old-style (CRT) monitors would create a space problem in all schools. The problem is greatly reduced with modern flat screens.

The advantage of portables is that they require little space. Teachers can easily bring their work home. The disadvantage is the lifespan of a portable, around half that of stationary equipment. It is reasonable to assume that laptops are twice as expensive to maintain as desktop PCs, and three to four times more costly to operate than the thin or diskless clients.

6.4.3. Recommended technical development budget

In the period 2005 to 2008 we put up the following recommendation for an IT infrastructure at the schools.

Number

Article

Cost

600

Thin clients and diskless workstations including all infrastructure

5,582,000

200

Thin clients or diskless workstations with flat screen and all infrastructure

1,740,000

800 client machines in total

Total

7,322,000

6.4.4. Software, learning platforms, and services

Where software runs, depends on infrastructure and capacity of the network. It's fine to operate all installations on schools from a central location, for example from ICT services in the municipality or a centrally located operation.

One must take into account that network capacity to schools can provide limits to how much schools can download at the same time, or where it is best to place servers to get the equipment's full functionality. There is a big difference between a single teacher downloading a film from for example NRK, compared to about 30 students doing the same simultaneously. If the shool has 1.5 Mbit/s broadband capacity, it is not possible for 30 simultaneous users to download the movie directly from NRK. Then you must have cacheing proxies in place at the school.

6.4.5. Check list centralisation

UNINETT ABC has made a document with recommendations <<FootNote(Recommendations of UNINETT ABC: http://www.uninettabc.no/?p=veiledning&amp;sub=annet )>> related to the centralisation of ICT operations. It gives advice about the placement of servers and which operational tasks may be centralised from the available capacity of the bandwidth to the school.

General measures to improve the operation of clients and servers

Thin or diskless clients against local serversLockdown of thick clientsLocal server machines

Remote operationCentralisation of some functionsLocal server machines

Server machines regionally/nationallyCentralisation of all operations

Capacity of the schools' network

Low bandwidth (ISDN)

Medium bandwidth (ADSL and similar)

High bandwidth (fibre and similar)

6.4.6. Software

The new curriculum (L2006) highlights the use of digital tools as one of the "basic skills". We wish that the use of ICT should go beyond teaching, and increasingly provide educational and administrative tools to support learning activity and new forms of learning while providing easy access to knowledge. Giving experience with digital learning platforms is one of the objectives of the competence plan. The aim was for one or more schools to try this out in 2006.

Research shows computer equipment being used to a limited extent for teaching in schools. Computer usage has stagnated and in some subjects declined, research shows (ITU Monitor 2005). The use of ICT in schools is often individualized, and students learn to become consumers. Teaching methods are hindering the sharing of knowledge in school. Few teachers use ICT daily. Internet and text-related services are the most important forms of computer use in schools.

Simply put, teachers focus too much on using tools for office administrative work such as MS Office or OpenOffice.org. What they ought to focus on was the use of simulations, editing pictures, audio and video communication on the Internet, and games.

Home use is often quite different. At home students are producers and use ICT mostly collectively and for communication. They put together and send each other pictures, exchanging content, using the major opportunities for recording, editing and sharing of movies which is possible with today's computers with broadband. Children and young people also play video games more at home than at school (ITU Monitor 2005).

Researchers say that video games are one of the main leisure activities for children and young people. One child in four plays every day (Youth Agency 2006). Video games are a social activity. In the wake of the games both virtual and physical communities arise, from playing together on consoles to participating in gatherings where youth can play.

An important task is that the school development contributes to update general education perspective in the general part of the curriculum. Allowing digital judgement or digital education developed in relation to steps and learning strategies, as stated by the national Research and Resource Centre for ICT in education.

To get equipment more in use requires considerable effort by the teacher. They must be continually educated in new forms of learning to use the new ICT tools for teaching. There must be more emphasis on youth's actual use of media and forms of communication. It is not enough to provide a teaching platform and e-mail. The tools should fully support the new ways of using media.

To achieve this, the equipment must be adapted to the software and the online services that teachers and students use in their school work. The browser is arguably the most important program students use in learning. Many will also be surprised that office programs as OpenOffice.org or MS Office are irrelevant in lower grades. At those grades, simple programs for practicing writings, drawings, communication, simulations and music forming apply. So what is important in the choice of software is to provide good access to the Internet and support for active learning using ICT tools that are relevant to the school subjects.

With diskless clients you get full support for multimedia, film, USB sticks and more. The advantage of thin clients is that they allow reuse from as far back as 1995. At that time the machines had no video capabilities. The USB standard was not fully developed. Computers from 2000 and later usually have a much higher capacity. Such machines can easily show video clips from NRK, DVDs, and one can play games.

The advantage of diskless clients is that they provide the same performance as the so-called thick clients or computers with most of the software installed locally. At the same time one gets the same low operating costs with diskless clients as with thin clients. This is because all the software is managed on the central server machine.

Today Skolelinux comes with over 50 school-relevant programs. In addition, it has browser, email client and OpenOffice.org with 8 different office applications. This is much more than what comes with Microsoft which mostly offers browser, e-mail and 5 current office tools.

With Debian Edu, it is also relatively easy to customize menus for the various stages of education so that we can reduce the number of educational programs. Especially since some applications are introduced in 4th-5th grade. While programs may be popular at first or second stages of education will be too easy when students have gotten older and learned more. In addition, there is an increasing number of educational programs on the Internet. This is software that works on any platform. So you can use the programs at home on Apple or Windows, and the school's Debian Edu. Students handle this just fine.

6.4.7. Learning platforms

Various digital learning platforms are found on the market. Some cost money, others are free. They all offer teachers and students an area where they can share and store documents, send and receive information.

Product

Price example:

Digital learning platform

It`s learning

3300,- NOK per school per year

School network

Free

6.4.8. Online services

Regardless of the bandwidth the following functions can be centralized:

  • Configuration management, i.e. having oversight and control of the configuration of machines, networks, applications and services

  • Program management, i.e. having oversight and control of access to, usage and performance of applications and services

  • Updates and patching

  • User administration, preferably with a FEIDE compatible user management system (BAS)

  • Licence administration

  • Monitoring and measurement

Checklist for services that can be centralized or replicated. For example can backup be centralized. The same applies to the user database with a central directory server (LDAP) with replication to each school.

Services

Description

Local

Central

Apache

Webserver allows all users to create a website

 

CUPS

Print server. The aim is that it will also manage print quotas

 

DHCP

Automatic connection of computers in the network

 

DNS

Name server

 

LDAP

Directory server containing user data for logon, file sharing and group information

 

LTSP

Thin client server

 

NFS

Network file system

 

NTP

Clock server so that all machines have the correct time

 

SMTP/IMAP over SSL

Email to everyone locally at the school

 

SSH

Remote control over encrypted connection

 

Squid

Cache for web sites (to save bandwidth)

 

Webmin

System management via the web browser

 

User administration

Simplified user administration

 

Backup

Backup (should be done on a separate machine)

 

SMB

Samba for connecting Windows-computers

 

cfengine

Automatic control of the system setup

 

Host and service monitoring

Monitoring the health of the server machine

 

Appletalk

Connecting Macs

 

SQL-server

Supplied (not set up)

 

6.5. Use of resources in operations

For day-to-day operation of its computers, each school has an ICT contact. ICT contacts have from 2 to 4 hours allocated to this work per week. In addition, the municipality has an ICT tutor in a 50% position working with, among other things, competence and operations. The operation of the Linux network would gradually be transferred to the municipal ICT service in the school year 2005-2006.

On behalf of Debian Edu, Kapp næringshage (business park) made a calculation program which estimates the use of resources for ICT in schools. Today we operate the school network for over 3000 users with 2.1 FTEs. (Schools' ICT contacts allocate a total of 1.6 FTEs for their work, and 0.5 FTEs in the municipality.) When Kapp næringshage calculates our resource requirements for operation, they estimate the current needs to be 4.6 FTEs. This shows that the school has managed much with few resources.

Increased resources must primarily be placed in schools, because the schools' ICT contacts get busier when the number of PCs goes up. Increased number of pcs means increased use, and increased need for guidance in educational use of ICT tools.

Maintenance will increase faster than number of simultaneous users, but maintenance of the machines themselves will increase almost linearly with the number of machines. We want to focus more on the educational use of the equipment, and want most of the increase to be go towards use of ICT tools in school subjects.

There will also be a somehow greater need for increased resources for the municipality's ICT service, but because of economies of scale, the increase here will be small.

Today it is difficult for schools to prioritize hours to an ICT contact. Both because money for this must be taken from already stressed school finances, and because schools have lacked guidance on what and how much ICT contacts at schools will perform.

6.5.1. Operations' roles

The duties of ICT contact at each school:

  • Toezicht houden op de serverkamer van de school.

  • Optreden als contactpersoon voor de school op de gemeente - fouten en storingen rapporteren.

  • Eenvoudige onderhoudstaken uitvoeren, zoals het vervangen van een muis of een toetsenbord, het opwaarderen van thin-clients en eenvoudige herstellingen uitvoeren.

  • Fungeren als de supergebruiker van de school - in staat om collega's raad te geven over: gebruikersinterfaces, e-mail, videoprojectoren en relevante toepassingen.

  • Deelnemen aan ICT-vergaderingen.

  • Aanmaken en beheren van lokale gebruikers.

  • Het eenvoudige onderhoud van printers verzekeren.

  • Aanmaken en beheren van e-mailaccounts.

  • Het gebruik van ICT in de lespraktijk bevorderen.

  • Eenvoudige commando's en interventies uitvoeren onder toezicht van een ICT-instructeur.

From experience, we reckon these tasks take a minimum of 4 hours a week for a school with 50 thin or diskless clients. If the school has fewer machines, this reduces the number of hours a bit. With more machines, for example 150 machines, the local ICT contact at each school needs around a 30% position to easily handle technical maintenance.

If the school can't set aside a sufficient number of hours to the ICT contact, duties in the work list above must be removed, and the opposite if the school can use more hours.

Tasks beyond this, for example updating a website, being an instructor (beyond normal collegial guidance), must be agreed individually for compensation/taking time off.

The ICT supervisor recommends the following tasks for ICT and ICT service supervisor.

Operations:

  • ICT-contactpersonen ondersteunen via telefoon en e-mail.

  • Visit the school for troubleshooting defects and errors on computers, printers and servers.

  • Gegroepeerde aankopen doen van computermateriaal en gezamenlijke overeenkomsten onderschrijven, enz.

  • Reservekopieën maken.

  • Continuous updating of software on school servers.

  • Procurement of equipment and software with tenders in the market.

Skills:

  • Develop the competence plan.

  • De scholen cursussen aanbieden over het onderwijskundig gebruik van ICT.

  • De wijze van werken.

  • Training of ICT contacts in schools.

  • Introduction to user interface and standard programs for teachers.

How much of the central operating resources are required, depends on which client types you have selected. Operation of workstations is almost twice as expensive for the operation of diskless clients.

6.5.2. Operation and support costs

The definition of operating costs:

  • All activities and initiatives to deliver and/or maintain the desired use of ICT infrastructure.

We have described what is a realistic operating environment, considering a moderate level of service with proactive operation. The Norwegian "Program for digital kompetanse" is the basis for our assessments.

Proactive operation is to discover and rectify errors before they affect users. An example of proactive operation is to update laptops with new disk images once a week. When teachers log in the morning after, all the machines will have been reset to the school's preferences.

Operations get messages about defects in the system before it goes wrong for users. Defects are rectified and bugs fixed before users notice anything. A system example that provides messages used to proactive operation is disk store. They can notify when a hard disk is defective, or if the disk cache is full. Operations can also get information if the computer network is available, or whether processes must be terminated when users logs out.

  • Advantage: One achieves very high stability of the system, supposing one has access to the right tools and the right skills. It becomes easier to maintain multiple types of computers because they know if they work or fail and can replace faulty equipment. Disadvantage 1: Requires higher technical expertise. Higher costs of establishing and managing operations. Disadvantage 2: Proactive operation is more costly than reactive operation if one does not count the loss of working hours for equipment that is defective. What you focus on depends on what the consequences are if the system is down. It is difficult to calculate the loss of teaching when ICT tools do not work. If it is required that the pupils and teachers have little downtime, one must invest in high uptime.

When we expand the fleet in schools this must have an impact on both ICT contacts' working resource and municipal ICT service for schools.

To quantify the need, we have estimated increased resource requirements in some of our investment options:

Investments

Servers

The number of clients/portables

Users:

Stipulated resource needs in 2008

Today's real resource:

Today's need 2005:

11

506

More than 3000

4.6 FTEs (man-year)

2,1 FTEs

      

Pupils in 2008

29

1033

More than 3000

6,9 FTEs

 
6.5.2.1. Teachers in 2008

Alternative 1

280

266

4,3 FTEs

 

Alternative 2 (laptop)

266

266

5,9 FTEs*

 
  • ) Additional FTEs for maintenance of 266 laptops

Costs for the administration of all the computers for students and teachers. We go out from Alternative 1 in regards to the thin clients for students and teachers, and some laptops.

Year

Number of PCs

Central operator

ICT guide for the entire municipality

ICT-contact at each school (average)

In total

2005

506

1/2 FTE

1/2 FTE

8,5 % FTE(3:30 hours per week)

2,1 FTEs

2005

Human resources' costs for operations*

NOK 980 910,-

 

2008

1333

1 position

1/2 FTE

100 % FTE(26 hours per week)

11,5 FTE

2008

Human resources' costs for operations*

NOK 5 400 00,-

 
  • ) NOK 270, - per teacher hour 1730 hours a year. ICT contact at each school uses 75% of the time on pedagogical support.

Alternative 2 with laptops for every teacher:

Year

Number of PCs

Central operator

ICT guide for the entire municipality

ICT-contact at each school (average)

In total

2008

1333

1 + 4/5 FTE*

1/2 FTE

100 % FTE(26 hours per week)

12,8 FTEs

2008

Human resources' costs for operations*

NOK 6,000,000.-

 
  • ) An additional position for maintenance of laptops.

Training costs for students and teachers is roughly the same with Windows and Linux, according to surveys done in schools in Norway and the UK. This is because the training is related to the use by end user programs in everyday school life.

  • Usually, at a school with 300 students and teachers only one or two persons need training in operating computer systems. This refers to both an ICT contact at school, and an operator in the municipality.

We have included additional training costs for Linux. When all teachers have one day going through the Linux desktop option, the transition to the new system goes easier for those who think they can only manage Windows. The cost for displays like LærerIKT and similar are not included as we have done in the cost overview from the municipalities in this survey.

6.6. Summary of the options

To achieve the objective of one computer per third student and one pc per teacher Option 1 is recommended. This option requires over 800 additional computers compared to current coverage of 506 client machines. Overall, we will then get just over 1300 client computers with emphasis on thin and diskless clients. Some machines will also be portable to provide additional flexibility in everyday school life.

Alternatives

Cost over 3 years

Option 1: Development of 800 clients

NOK 7,322,000.-

Option 2: Portable to all teachers + Option 1.

NOK 12,000,000.-

Operating costs:

Alternatives

Yearly cost

Alternative 0. Administrating 506 client machine

NOK 1,000,000.-

Option 1. Increases with about 800 to 1300 PCs

NOK 5,400,000.-

Option 2. Portables to to all teachers*

NOK 6,000,000.-

Option 3. Portable room layout*

NOK 8,000,000.-

The large increase in operating expenses from current option 0 to option 1 is due to investment in ICT contact at schools. This increases from 10% to a full 100% FTE. The maintenance ICT contacts do today is around 10% FTE. This will probably increase to 20% with a doubling of the number of client machines. On increase to a full-time position, 80% will be used to support the educational use of ICT tools in school subjects. This means that principals at school must allocate resources for this, so that one follows the national curriculum from 2006.

6.7. Recommendation

Alternative 1:

Type of cost

Amount

Of this is the administration of 1300 client computers:

NOK 2,000,000.-

Annual investment in three years:

NOK 2 440 667,-

Support for educational use of ICT tools:

NOK 3,400,000.-

Annual cost for Option 1 with investment and operations:

NOK 7,841,000.-

6.8. Attachment

Many schools have developed an activity plan for the use of ICT in the school. This should be included as attachment.

7. Extra configurations

/!\ Graphics in the document must be inserted and updated

7.1. Simple firewall

Debian Edu's architecture suits centralized operations with the placement of services centrally, and can be operated locally at each school. A firewall makes it easier to start with Debian Edu's if you want to try out a small installation.

7.2. Simple firewall with floppy (Coyote)

Use Case: To get started with Debian Edu's we need to make a simple firewall. The purpose is to separate Debian Edu's network from the second network that is set up.

Main author Klaus Ade Johnstad

  • Regardless of whether you choose to Coyote Linux floppy on a Linux or Windows machine, the following configuration must be used. This applies to any other firewall router than Coyote Linux

  • Local network interface:

         IP Address:   10.0.2.1
         Netmask:      255.255.254.0
         Broadcast:    10.0.3.255
         Network:      10.0.2.0
  • Install the Big Pond login software? [y/n]:n

Press "n"

This refers to some extra stuff you need if you want to have access from the provider Big Pond, but we are not sure. Is there anyone who knows that for sure?

  • Do you want to enable the Coyote DHCP-server [y/n]: n

Press "n"

  • Use 10.0.2.2 as a syslog server. This is the IP address of the main server

Warning: Since Skolelinux/Debian-Edu already has a DHCP server running, you must disable the DHCP server on your firewall/router. The same applies to all other machines that may be connected to a Skolelinux/Debian-Edu network. Having two DHCP servers on the same network usually just leads to trouble

If a new version of Coyote Linux exists when you read this, it might replace the version 2.24 in the commands above with the version downloaded.

  1. After that the Coyote Linux was downloaded, the files must be unpacked. One must be the root user to unpack.

tar zvxf coyote-2.24.tar.gz

cd coyote

./makefloppysh

  1. When creating Coyote Linux on a Linux machine, one needs to answer several questions. Here is a summary of the answers that can be supplied:

a.   Coyote floppy builder script v2.9

    Please choose the desired capacity for the created floppy:
    1) 1.44MB (Safest and most reliable but may lack space needed for
           some options)
    2) 1.68MB (Good reliability with extra space) - recommended
    3) 1.72MB (Most space but may not work on all systems or with all
           diskettes)

    Enter selection:2

The recommended choice is «1.68MB»

b.   Please select the type of Internet connection that your system uses.

    1) Standard Ethernet Connection
    2) PPP over Ethernet Connection
    3) PPP Dialup Connection\n\nEnter Selection:

Here it is best to select 1)

c.   Configuring system for Ethernet based Internet connection.
    By default, Coyote uses the following settings for the local network
    interface:

    IP Address: 192.168.0.1
    Netmask:    255.255.255.0
    Broadcast:  192.168.0.255
    Network:    192.168.0.0

    Would you like to change these settings? [Y/N]: y
    Enter local IP Address [192.168.0.1]: 10.0.2.1
    Enter local Netmask [255.255.255.0]: 255.255.254.0
    Enter local Broadcast [192.168.0.255]: 10.0.3.255
    Enter local network number [192.168.0.0]: 10.0.2.0

These network settings for local network must be changed. See A

   IP Address: 10.0.2.1
    Netmask:    255.255.254.0
    Broadcast:  10.0.3.255
    Network:    10.0.2.0

e.   Does your Internet connection get its IP via DHCP? [y/n]:

Answer yes(y) or no(n) in accordance with what the network configuration is.

If one gets an IP via DHCP, the following information should be filled out:

   Please enter the information for your static IP configuration
    Internet IP Address:\nInternet Subnet Mask [255.255.255.0]:
    Internet Broadcast [Enter = Default]:
    Internet Gateway Address:
    Domain Name:
    DNS Server 1:

    DNS Server 2 (optional):
  • Enter the DHCP hostname:

Usually, this one can be blank

  • Install the Big Pond login software? [y/n]:

We think that this refers to some extra stuff that comes from the provider Big Pond, but is not sure. If anyone who knows better then send us an email.

h.   Do you want to enable the Coyote DHCP server? [y/n]: n

Here must the answer be «n»!

i.   If you don't know what a DMZ is, just answer NO\nDo you want to configure a De-Militarized Zone? [Y/N]: n

Just choose "n"

j. You now need to specify the module name and parameters for your
  network cards.

  If you are using PCI or EISA cards, leave the IO and IRQ lines
  blank.

  Enter the module name for you local network card:

This is the tricky part. Knowing which module to use for network cards is sometimes difficult. See Section 3.12 to get an overview of the available modules. Remember to not use .o at the end of the module name. Use only "first name" of the module.

Many prefer 3Com. Almost all use this module 3c59x.

k.   The default language of the Coyote Web Administrator is English
    Do you like to configure a different language ? [Y/N]: n

Use English. It is much easier to get help. Search for example using Google to find solutions to problems.

l.   Syslog server address:

Here you can use the main server as syslog server. Use 10.0.2.2

  1. You must insert a floppy disk in the machine. Remember to turn the write protection. It takes a few minutes to write to the disk.

  2. Be sure not to get any error messages to unknown NIC modules, like this:

    Checking module deps for (wrong,bad)...
    Copying module: drivers/wrong.o

    Unable to copy module (drivers/wrong.o): No such file or directory

Be sure you get something like this instead:

   Checking module deps for (e100,3c59x)...
    Module 3c59x dep =
    Module e100 dep =
    Copying module: drivers/e100.o
    Copying module: drivers/3c59x.o

7.2.1. Solution 2 Create a Coyote Linux Floppy on a Windows machine

To create a floppy on a Windows machine is done almost the same way as on Linux.

Download the source files for Windows. They can be obtained from Disk Creation Wizard v2.24.0

Figur 3-2. Coyote Linux Windows Creator Welcome Image

  • {{attachment:graphics22.png}}

Here you can just press "Next"

Figure 3-3. Local LAN network setup

  • {{attachment:graphics23.png}}

Fill in the necessary network information here: See A

Fill in the correct IP address and subnet mask (Netmask) and Coyote Linux will give the correct calculation of the broadcast address (Broadcast) and the network address (Network)

Figure 3-4. Insert a password on the Coyote Linux floppy disk

  • {{attachment:graphics24.png}}

Without this password you can't log into the Coyote Linux on a later occasion. See Section 3.6

Figur 3-5. Syslog-server

  • {{attachment:graphics25.png}}

Leave the field blank, or look at 2.l

Figure 3-6. Type of Internet connection (WAN)

  • {{attachment:graphics26.png}}

Choose what suits you. Do you have access to DHCP server, which is very likely, then you do not need more information.

Figure 3-7. Static IP configuration

  • {{attachment:graphics27.png}}

Do you have a fixed address, fill in the appropriate values here.

Figure 3-8. Do not enable the Coyote Linux DHCP server!

  • {{attachment:graphics28.png}}

Do not turn on the Coyote Linux DHCP server. There is already one running on main server

Figure 3-9. Select a driver module for the network card (NIC)

  • {{attachment:graphics29.png}}

Drag and drop to choose the correct network card at the Coyote Linux machine.

In this particular screen, we use the module for 3Com on the LAN side of the grid (Debian Edu's) and Intel pro 100 card for the WAN (Internet) connection.

Figure 3-10. Select language

  • {{attachment:graphics30.png}}

If you want to get good support from the Internet, choose English.

Figure 3-11. Make the disc

  • {{attachment:graphics31.png}}

Place a floppy disk in the disc station and press 'Next'.

7.2.2. Exception handling

Our clear advice is to make at least two copies of the floppy disk. It is nice to have a couple copies ready if anything should happen.

7.2.3. Verification

< FIXME>

7.2.4. Update the configuration database

< FIXME>

7.3. Simple firewall with CD

Use Case: To get started with Debian Edu's we need to make a simple firewall. The purpose is to separate Debian Edu's network from the second network that is set up.

Main author Klaus Ade Johnstad

7.3.1. Solution

Coyote Linux is a product in constant development and maintenance. Just like Skolelinux / Debian-edu. Meaning that new versions are released constantly, with new features and security fixes. Especially due to security fixes, you should always use the latest stable version of Coyote Linux

Since Coyote Linux runs solely from a floppy disk, there is no system to upgrade. You must create a new floppy as described in Section 3.3. To make this process as simple as possible, there are some things to remember.

  1. Find out what kind of network you have. If this is unknown, one can use the command lsmod to list all loaded modules (drivers) in use. Maybe this will give an idea of what kind of network cards are used.

coyote# lsmod
Module                  Size  Used by
3c509                   7732   2
ip_nat_quake3           1768   0 (unused)
ip_nat_mms              2608   0 (unused)
ip_nat_h323             2060   0 (unused)
ip_nat_amanda            876   0 (unused)
ip_nat_irc              1904   0 (unused)
ip_nat_ftp              2384   0 (unused)
ip_conntrack_quake3     1848   1
ip_conntrack_mms        2704   1
ip_conntrack_h323       2065   1
ip_conntrack_egg        2280   0 (unused)
ip_conntrack_amanda     1488   1
ip_conntrack_irc        2672   1
ip_conntrack_ftp        3440   1

In this list of modules that are loaded, the module for the network card 3com509 is loaded twice. For a list of available modules, look at

It is best practice to write on the machine itself what kind of network card it contains.

  1. What kind of "port forwarding" is it?

Information about the "port forwarding" rules, if you have made any, is in the file/etc/coyote/portforwards

   coyote# more /etc/coyote/portforwards\nport Y 10.0.2.2 tcp 2333 22 # Example - Secondary SSH

7.3.2. Exception handling

< FIXME>

7.3.3. Verification

< FIXME>

7.3.4. Update the configuration database

< FIXME>

7.4. Starting the Coyote firewall

User case: After a simple firewall is installed, it shall be installed on the network and be effective.

Author: Klaus Ade Johnstad.

7.4.1. Solution

There are two network cards in Coyote Linux, one (LAN) is connected to the Skolelinux/Debian-edu server, the other is connected with a crossed cable, or via a switch to another network (WAN). Sometimes it can be a bit difficult to decide which network card is which, especially if they are both connected to the same address. The method we use to determine which card is which, is to use a crossed cable and connect it to the network card in the Skolelinux/Debian-edu main server.

  1. First you start Coyote Linux without any wired network card

  2. Then use the crossed cable to connect Coyote Linux with the Skolelinux / Debian-edu main server (make sure it goes to the NIC labeled eth0 if the main server is a combined server).

  3. Login to the main server. Try to ping the Coyote Linux machine. Use the command ping -c10 10.0.2.1, or alternatively, try to ping the main server from Coyote Linux with the command ping -c10 10.0.2.2.

  4. Then you get a response like this if it works:

ping -c10 10.0.2.1
PING 10.0.2.1 (10.0.2.1): 56 data bytes
64 bytes from 10.0.2.1: icmp_seq=0 ttl=63 time=0.6 ms
64 bytes from 10.0.2.1: icmp_seq=1 ttl=63 time=0.3 ms
64 bytes from 10.0.2.1: icmp_seq=2 ttl=63 time=0.3 ms

When you have found the network card on the Coyote Linux that must be labelled LAN, then we know that the other network card is WAN. This procedure will only work as long as the network card on the LAN is set up properly. As shown during startup on the line

LAN network: UP

7.4.2. That is normal what is shown

WAN network: 
    down

Since you have started without any wires connected to the network card.

When the role of each of the network cards is decided, it is time to reboot the firewall with all the cables in place.

Different names for the network cards

The two network cards got two different names in Coyote Linux. This is a bit confusing and not very consistent. Here is a summary:

The various names used for network cards in Coyote Linux

This is connected to the existing network

Internet

Eth1

WAN

This goes to the Debian Edu network

LAN network

Eth0

LAN

Reboot the Coyote Linux machine and make sure the Coyote Linux floppy disk is present in the floppy station. Ensure that the machine is configured to boot from floppy drive.

Figure 3-12. Coyote Linux Login

  • {{attachment:graphics35.png}}

You can log in. Use the user name "root" and the password you set when you created the floppy (if this was done from Windows). or press Enter (blank password) for logging on floppy disk created by Linux

Note: It is normal that you don't get any visible response when you type a password in a Linux system. This is to reveal as little information as possible about the password.

7.4.3. Exception handling

menu, status of the network, down

  • {{attachment:graphics37.png}}

Once you have entered, press 'c' to get the status of the network. In case there is a problem:

Figure 3-14. menu, status of the network, up

  • {{attachment:graphics38.png}}

If everything went well, both will be "up"

Q: It looks like the network card (LAN) going to to the Skolelinux/Debian-edu network is not working: DOWN

Q: It looks like the network card (WAN) connected to the Internet, is not working: DOWN

Q: We have set up firewalls with many different driver modules for many network cards. We have yet to find anything not working properly.

Q:It looks like the network card (LAN) going to to the Skolelinux/Debian-edu network is not working: DOWN

A:If you set up your network card according to A, but it still does not work. That may mean the wrong driver has been chosen for your network card

Q:It looks like the network card (WAN) connected to the Internet, is not working: DOWN

A:There are usually two reasons why the WAN network card is not up (UP):

  1. You're using a connection with the wrong Internet configuration. Take another look at 2.b

If you have a connection with a DHCP-assigned address, which is not static. Then it must be a physical connection through a network wire between Coyote Linux and the network socket.

  1. You have chosen the wrong driver module for this network card.

You should attempt to login to Coyote Linux and choose q) quit to leave the Coyote Linux menu. Then you should run the command

dmesg|more

then use space to scroll. Look for references to eth0 and eth1. Look at Different names to the network cards for a reminder of what eth0 and eth1 means. Usually it is an indicator of what the problem is.

Q:We have set up firewalls with many different driver modules for many network cards. We have yet to find one that doesn't work properly.

A:Have you looked at this website for more information about network cards and corresponding driver modules for Coyote Linux? http://www.dalantech.com

7.4.4. Verification

The firewall works if you try to reach the Internet through the web browser on the main server or through a connected client.

7.4.5. Update the configuration database

< FIXME>

7.5. Firewall administration through the browser (Coyote)

Use Case: We need to change the settings in the firewall. The firewall is locked in the computer room. Can I make the change over the network?

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

Coyote Linux has a pretty and practical administration tool through a web portal. Here you can do everything. Type http://10.0.2.1:8180 in the address field of your browser. The address will provide web administration for Coyote Linux. Click on the link and enter your user name root and the password you created for the firewall.

Coyote Linux web administration

  • {{attachment:graphics42.png}}

All options and settings can be done in Main Menu on the left side.

Coyote Linux Main Menu

  • {{attachment:graphics43.png}}

  • Information

Choosing this gives the status of your network cards, active IP addresses, uptime for Coyote Linux, Ist and the like.

  • LAN setup

Here you have the possibility to reconfigure the LAN network card. It goes to the Skolelinux/Debian-edu network. Leave the values as they are. Referring to A.

Warning: Do not make changes here! Doing so may reduce the performance of Skolelinux/Debian-edu network

< FIXME: Should describe the contents of change_ip_setup here, later>

  • Internet setup

Here you have the possibility to change the values in the WAN network card connected to the Internet. If you have got a new ISP, or changed a dynamically assigned IP address by DHCP to a fixed one, this is the place to change the information without the need of creating a new Coyote Linux floppy from scratch. See 2.b

  • DHCP setup. Warning: Do not enable the DHCP server in Coyote Linux!

This provides the possibility to configure DHCP server as part of Coyote Linux

  • Administrative settings

Here it is possible to turn on and off services like the name server (DNS), ssh and web administration.

  • Port Forwarding

Here you may change and enable port forwarding in Coyote Linux. This is a neat feature in a Skolelinux/Debian-edu network. Since Coyote Linux stops and blocks most connections for example ssh, it's nice to use port forwarding. This is a way to let ssh connections through Coyote Linux to a Skolelinux/Debian-edu- network.

Use this rule for port forwarding

   Yes         TCP         Any         22         10.0.2.2         22         No           SSH straight into Mainserver

all ssh-connections coming to Coyote Linux will be forwarded to the Skolelinux/Debian-edu main server. You need to decide if this is as wished.

  • Simplified firewall configuration

Here you can set up and configure the firewall rules in Coyote Linux. There are many rules ready to use and can be used as an example.

  • Advanced firewall configuration

  • QOS configuration

Here you can set up restrictions on network capacity

  • System password

Here you can change the root password for Coyote Linux, also known as the system password. This is the same as using the command line Section 3.6.

  • Configuration files

These are files that contain all settings.

  • Diagnostic tools

Here you would find useful tools like ping, testing ports (gateway), testing nameserver (DNS), and the status of the network.

  • Backup now

Are there any changes in Coyote Linux then those must be saved on the diskette. By selecting Main Menu in Coyote Linux users can choose to save the setup. The alternative is that all changes are lost when you reboot Coyote Linux

  • Reboot the system

When you need to start again the Coyote Linux, this can be done from the "Main Menu". When choosing restart this must be confirmed.

Restart or turn off Coyote Linux?

  • {{attachment:graphics47.png}}

7.5.1. Exception handling

< FIXME>

7.5.2. Verification

< FIXME>

7.5.3. Update the configuration database

< FIXME>

7.6. Firewall as a DHCP server (Coyote)

Use case: Want to set up a good DHCP server with high stability regardless of the operating system. Notification: normal DHCP server in a non-Skolelinux/Debian-edu network

Author: Klaus Ade Johnstad.

Coyote Linux is a good solution if you just need a DHCP server on the network regardless of what type of machines, be it Linux, Windows or Mac.

The only thing that needs to be configured differently, is to enable the DHCP server. < FIXME: create link to screenshot>

A brief summary about changing a Coyote Linux to a DHCP-server:

Coyote Linux as the default DHCP server

  • Remember to answer "yes" to the question "Do you want to enable the Coyote DHCP-server [y/n]:"

  • Once a DHCP server runs on Coyote Linux, you will probably need to use a different address for login, if you did not change the LAN setup:

Configuring system for Ethernet based Internet connection


By default, Coyote uses the following settings for the local network
interface:

IP Address: 192.168.0.1
Netmask:    255.255.255.0
Broadcast:  192.168.0.255
Network:    192.168.0.0

Would you like to change these settings? [Y/N]: n

then you should use the address 192.168.0.1 instead of 10.0.2.1 when logging into the Coyote Linux web administration. See Section 3.7 and

In this case the new address is:

7.6.1. Verification

< FIXME>

7.6.2. Update the configuration database

< FIXME>

7.7. Coyote firewall and Internet operators

User Case: We have a firewall with Coyote Linux. Does it allow itself to connect to our ISP?

Author: Klaus Ade Johnstad.

Note: We've seen no case where Coyote didn't work with an ISP in Norway. Tell us if you experience problems with an ISP.

This is a list of Internet providers that work well with Coyote Linux

  • Nextgentel, Norway

  • Tele2 ADSL Privat, Norway

  • Tele2 ADSL Bedrift, Norway

  • UPC Chello Classis, Norway

  • The Department of Education in Oslo. Not tested on schools connected to Simens' !InnsIKT-solution for Oslo schools

Due to different network policies in The Department of Education in Oslo, you must make the following changes in the main server:

Change the following in the file/etc/bind/named.conf [5]

       // forwarders {
        // By special request from the good people inside the Dept of Education in
        // Oslo:
        //      193.156.192.40;
        //      193.156.192.50;
        // Dept. of Education in Oslo  end of block
        //      0.0.0.0;
        // };

change this to

          forwarders {
        // By special request from the good people inside the Dept of Education in
        // Oslo:
                193.156.192.40;
                193.156.192.50;
        // Dept. of Education in Oslo end of block
        //      0.0.0.0;
           };

This means to remove the comment marker (#) in front of "forwarders".

If you don't do this, you will not be able to connect to the Internet due to problems with the name server (DNS) in The Department of Education in Oslo. Operating staff will also engage more people to get this changed to such as this service wants it.

After the changes are inserted in /etc/bind/named.conf one needs to restart bind with service bind9 restart

  • Telenor ADSL, Norway

  • Oslo University College (Høgskolen i Oslo)

Here, you must make the same bind-changes as the Department of Education in Oslo.

7.7.1. Exception handling

< FIXME>

7.7.2. Verification

< FIXME>

7.7.3. Update the configuration database

< FIXME>

7.8. Support for network cards in the firewall

Use case: Are the two network cards in the machine supported by Coyote?

Author: Klaus Ade Johnstad.

This is a list of modules included in Coyote Linux. All driver modules for network cards are listed.

tjener:~/coyote# ls  data/kernel/drivers/
3c501.o     eth16i.o               ne.o
3c503.o     ewrk3.o                ni5010.o
3c505.o     fealnx.o               ni52.o
3c507.o     forcedeth.o            ni65.o
3c509.o     hp100.o                pcnet32.o
3c515.o     hp.o                   ppp_async.o
3c59x.o     hp-plus.o              ppp_deflate.o
8139cp.o    ip_conntrack_amanda.o  ppp_generic.o
8139too.o   ip_conntrack_egg.o     pppoe.o
82596.o     ip_conntrack_ftp.o     pppox.o
8390.o      ip_conntrack_h323.o    ppp_synctty.o
ac3200.o    ip_conntrack_irc.o     sch_htb.o
amd8111e.o  ip_conntrack_mms.o     sch_ingress.o
at1700.o    ip_conntrack_quake3.o  sch_sfq.o
b44.o       ip_conntrack_rtsp.o    sis900.o
bridge.o    ip_conntrack_tftp.o    slhc.o
bsd_comp.o  ip_nat_amanda.o        smc9194.o
cls_fw.o    ip_nat_cuseeme.o       smc-ultra.o
cls_u32.o   ip_nat_ftp.o           softdog.o
cs89x0.o    ip_nat_h323.o          starfire.o
de4x5.o     ip_nat_irc.o           sundance.o
depca.o     ip_nat_mms.o           tlan.o
dgrs.o      ip_nat_quake3.o        tulip.o
dmfe.o      ip_nat_rtsp.o          typhoon.o
e100.o      ip_nat_tftp.o          via-rhine.o
e2100.o     lance.o                wd.o
eepro100.o  lp486e.o               winbond-840.o
eepro.o     mii.o                  zlib_deflate.o
eexpress.o  natsemi.o              zlib_inflate.o
epic100.o   ne2k-pci.o

7.8.1. Exception handling

< FIXME>

7.8.2. Verification

< FIXME>

7.8.3. Update the configuration database

< FIXME>

7.9. Particularly old network cards in the firewall (ISA)

Use case: We want to try to use some network cards in the firewall that are almost 20 years old. They are using the so called ISA bus. Is this possible?

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

Network cards with model number 3c509 from 3Com have been a very popular series. Many have Coyote Linux with such a network card built in which could have been produced for example in 1989, over 25 years ago. We've run these cards for three years with Coyote firewall without any problems. Once you have managed to get one running, it will probably run for a long time. But it is sometimes difficult to get the cards to work in the first place. This is because they have an ISA bus. This means that important addresses (I/O) and termination messages (IRQ) must be handled manually. This is done automatically with PCI cards, but using an ISA card requires extra effort. I/O and IRQ on these cards can be handled by an old DOS program. This can be somewhat difficult to obtain, since this software is over 25 years old.

The DOS configuration program is called 3c5x9cfg.exe, and it is used in the following way:

  1. Start the machine with DOS. One can use !FreeDOS or a boot floppy created with Windows 95 or 98.

  2. As soon as the machine is booted using DOS, insert a floppy disk with the program 3c5x9cfg.exe. Run the program 3c5x9cfg.exe from the command line in DOS.

  3. When 3c5x9cfg.exe is started, each of the 3c509 network cards can be configured with the "auto" option

3c5x9cfg.exe can be found at Ruprecht-Karls-Universität Heidelberg: http://www.urz.uni-heidelberg.de/Netzdienste/nm/misc/3comnic/

!FreeDOS can be found on: http://www.freedos.org/

7.9.1. Exception handling

Warning: Many reports show problems with using two 3c509 card on the same machine if one of the cards is a combo type. This is a card type with different types of network cable plugs.

Do not use combo type ISA bus cards!

7.9.2. Verification

< FIXME>

7.9.3. Update the configuration database

< FIXME>

7.10. Useful links about the Coyote firewall

User case: I have not gotten enough help with using the firewall on these pages. Where can I get more help?

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

7.10.1. Exception handling

< FIXME>

7.10.2. Verification

< FIXME>

7.10.3. Update the configuration database

< FIXME>

7.11. Config:

User case: What's should be configured

7.11.1. Solution

< FIXME>

7.11.2. Exception handling

< FIXME>

7.11.3. Verification

< FIXME>

7.11.4. Update the configuration database

< FIXME>

8. Setting up infrastructure

8.1. Network architecture

User case: Shall set up a computer network that scales so that one can either operate the system locally or connect to a centralized operational solution

8.1.1. Solution

8.1.2. Exception handling

8.1.3. Verification

8.1.4. Update the configuration database

8.2. Server profiles

Use case: How to install machines for an entire computer network for a school or many schools in a municipality.

< FIXME: In with the drawing showing diskless clients>

<ul> <li><p>{{attachment:bilder50.png}}</p> <p>The different profiles on different servers.</p></li></ul>

8.2.1. Combi-server as a combined resolution

Two profiles with main server and thin client server in combination are called a combi-server

  • {{attachment:bilder51.png}}

This is a fairly small step, which makes it easy to use an appropriate switch on the backbone network, and use a crossover cable to connect the firewall with a combi-server

Note: Be aware that setting a printer on the address 192.168.0.0/24, which is the thin client network, does not work if the hostname is printer00. Be sure to edit KDE printing manager to search for printers at 192.168.0.0/24-net. Not standard 10.0.2.0/23-net.

8.2.2. Description of the profiles in Skolelinux/Debian-Edu

Profiles shown during the installation originate from the file src/debian-edu-install/debian/debian-edu-install.templates in the debian-edu-install package.

Graphical desktop

One will increasingly see references to a graphical desktop. In short that means a modern desktop with point and click, windows, icons, and file folders. Graphical user interfaces were first made by Xerox Parc in 1973, 10 years before they came to personal computers that could be bought on the market. This was a very short presentation of graphical user interfaces.

A brief summary of the different profiles in Skolelinux/Debian-edu and how they can be combined

<ol style="list-style-type: decimal;"> <li><p>Main server</p> <p>Warning: All Skolelinux/Debian-edu-networks must have only one main server, and only one machine with that profile. Most commonly that profile can be combined with thin client servers, or just a workstation.</p> <p>Every Skolelinux network needs one, and only one machine running the 'Main Server'. This machine provides network services such as for example network login with the help of directory server (LDAP) etc. Without this machine the network does not work. Since this machine will save all data files, it needs a lot of disk space. You do not get graphical user interface by installing this profile. If you want a graphical user interface you must also install workstation-profile or thin client server.</p></li> <li><p>Workstation</p></li></ol>

Machines running the 'workstation' profile is what we know as normal PCs. Users log on to workstations, and get storage space on The main server. Documents, personal settings and many network services are on The main server. User programs run on the workstation.

For access to CD/DVD-player/burner, digital cameras, scanners, this is the profile to install.

  1. Thin client server

Machines running the thin client server support the thin clients. This profile also includes the workstation profile. To prevent saturating the network, two NICs are required. The profiles: main server, workstation and thin client server can be installed on the same machine.

This profile also contains the work station-profile

  1. Diskless workstations

Machines running as thin client servers provide support for diskless clients if this is enabled. In Skolelinux 2.0 this must be enabled afterwards. This profile also includes the workstation-profile. Profiles main server, workstation and thin client server can be installed on the same machine.

  • This profile also contains the work station-profile

  • Main server + thin client server (including workstation)

This combination of profiles, also called combined profile, providing the ability to setup a complete Skolelinux / Debian-edu network workstations and thinclients with only one server. This is an acceptable solution in a small Skolelinux/Debian-edu network, with maybe 10-15 thin clients and a few workstations. For larger installations, one must usually choose servers which are larger.

  1. Main server + workstation

This combination of profiles mainly gives you a main server with a GUI. If you do not like the idea of administering your main server from the command line, this is a good combination.

The standalone profile is not part of Skolelinux/Debian-edu network. The purpose of this profile is to support the home PC or portables.

  1. Stand alone

The standalone profile can not be installed together with the main server, workstation or thin client server.

The standalone profile is best to use without linking it to a Skolelinux / Debian-edu network.

All programs in Skolelinux/Debian edu are included in the standalone profile

8.2.3. Solution

8.2.4. Exception handling

8.2.5. Verification

8.2.6. Update the configuration database

8.3. Hardware servers

User case: What's should be configured

8.3.1. Solution

8.3.2. Exception handling

8.3.3. Verification

8.3.4. Update the configuration database

8.4. Client computers

User case: Choice of client machines. Should you choose silent machines or machines for multimedia. Should one have laptops to all or desktops.

Several types of technologies can provide application on the PC. Most common is thick clients operating locally on each computer. But there are other types of technology for applications on the desktop. Many have heard of graphic terminals. Examples include Citrix, !FreeNX and Windows Terminal Server. There are also other options like lowfat clients and real thin clients. This article describes the options and provides an overview of where the various terminal technologies do best. The reason for the article is the experience of enterprise solutions with centralized operation of the computer in many different buildings with low, medium or high network capacity.

Client technologies are described in the following order. Graphic terminals Citrix and !FreeNX, thin clients with X Windows, thick clients with Linux and Windows, client in between with Linux, and laptops. The following are examples of what server systems are commonly used in various business-oriented installations. A key factor for calculating costs is the number of concurrent users and the number of servers. Centralized management of computer equipment at several schools may in practice be compared with how the operations of ICT systems is done in larger companies. Often schools have more computers than the rest of the council's activities. Failure to think things through in what one chooses for client solutions in schools can quickly lead to a doubling of the number of employees in IT services in the municipality.

Citrix is the most known product for graphical clients. The company making this is product was established in 1989. The first graphical clients were made for the operating system OS/2. First Windows product was launched with NT 3.51 in 1995. There are several competing products to Citrix. One of the most successful is the NX technology. Briefly, you may run applications from a server with Citrix or NX. The screen is exported over the network from a server to a graphical terminal on a thick client.

Graphical clients have the strength that it would be seemless what ever kind of operating system that might be running on the client. One could use the applications on the server anyways. One can run standard office programs and client emails over an ISDN line with 64 kbps. That said, there are limitations in graphic software, whether it is used with multimedia or interactive graphics. The solution can quickly become of no practical use if a municipality distributes 30 or 50 graphic terminals at 5-6 schools with broadband with 2-8 Mbps. With this capacity one can not run interactive graphical applications. The Internet would be filled up with traffic, and the Citrix client would disconnect from the server machine.

With graphical clients the operations department must run two parallel paths for the maintenance of software. Maintenance occurs on all client computers and on local and central servers. For getting for example Citrix to work reasonably well, there must be deployed two additional server machines in each building, in addition to central application servers. In addition, it usually needs some thick clients also for use with multimedia. For example 1/3 of the machines in Oslo schools are thick clients to provide support for multimedia.

Thin clients was introduced in 1984 at MIT. This was around the same time Apple released the Macintosh GUI. The following year Microsoft shipped the first edition of MS-Windows. Actually thin clients are named X Window Systems and can be used on all possible platforms like Linux, Mac or Windows. X Windows turned things upside down. In practice applications run on a server, and the GUI is sent over the network to the client computer. The client computer runs a server program to display graphical windows. An X server may run your application windows from different programs running on many different servers. Thick clients also run the X Window system, using a virtual local network on the PC. All Unix systems with graphical user interfaces run X servers.

The main advantage of thin clients is the reuse of older equipment without increasing the complexity of operations. Many people use PCs with 233 MHz and 32 MB memory as thin clients. There is no need for local hard drive. Users can handle heavier graphics, sound and simple video. Several schools have opened up for the use of CD / DVD-Rom and USB memory stick at the thin clients. Operating personnel do not have to keep track of a separate operating system on each of the PCs. Everything is handled from the server. Each thin client uses around 2 Mbps network capacity during normal use. The performance of thin clients is significantly better than graphic terminals. Thin clients need in average fewer servers than graphic clients with for example Citrix, as shown by a study of The Department of Education in Oslo.

Thick clients or standard PCs is what is mostly used today. The term Personal Computers were used for the first time November the third 1962. The first PC with network and graphical user interface was created at Xerox PARK in 1973. Today it is the PC concept IBM launched in 1981 that is known and widespread. The entire operating system and all the software applications are installed on each client computer on a local data store. The most famous operating computers are Microsoft Windows and Linux. But there are also a number of other systems that many people use, including a version of BSD.

The advantage of Thick clients is that all programs are run locally, which can provide great flexibility and performance for users. Since most user programs run locally few central servers are needed. Solutions with thick clients can be relatively inexpensive to operate if one standardizes. On Windows, it is a great advantage to have mostly similar machines, which is difficult over time. It is quite common, for example, that the school has both 4 and 5 PC types. This affects operational costs. Linux is more flexible because the system can be more easily managed with many different PC types. Linux also requires less memory, and allows for longer use of older computers without loss of performance as the British Educational Communications and Technology Agency (BECTA) reports.

Diskless clients is another exciting technology. Today supported on Linux with Lessdisks or new LTSP. Novell had a virtual monopoly on diskless clients 15 years ago. Simply explained, the entire operating system and applications are installed on a server. The operating system is uploaded from the server to the client over the network. File, print, and Web services are handled by an operating system designed for networks. By the introduction of Windows 95, Novell met a technological barrier. Microsoft changed controlling Windows with registry instead of text files. Now it's only Linux and other Unix variants offering diskless clients.

The advantage with diskless clients is that you get the performance of thick clients with the operational advantage of thin clients. It means that the organisation can connect many client machines to a server, without installing locally an operating system on each client. Everything is handled from the server. The system supports audio, video, CD/DVD-Rom and USB memory stick. Today it is unusual to find used machines with less than 800 MHz processors and 256 MB of memories, which is well suited for the half thick clients. It is recommended to use local hard drive cache.

Portable machines are essentially thick clients. Laptops may in principle be used as thin clients, half thick clients or graphical terminals. But it is not very practical for several reasons. Portables should be used as thick client. In order to connect the laptop to a stationary computer network, one must choose what kind of services to be used.

There are significant challenges with portables in wireless networks with many users. Wireless networks have limited capacity. Portables are also subject to rough treatment, and require more frequent replacement than what is normal for stationary equipment. One should not run graphical terminals on laptops in wireless networks. This quickly becomes unstable when you have many users. Thick clients with Linux or Windows run fine. They can relatively easily be authenticated against the network. The user can access file directories, printing and other network services in a safe and secure manner. Several providers offer laptops in schools which connect to the computer network running Debian Edu.

8.4.1. Table of client types

Main solution

Support for multimedia

Characteristics

Fat clients (Windows, Linux or Mac)

Good support for sound, graphics and video with powerful enough processor and memory on the client machine.

All user applications installed on the client machine. The user programs run on the client machine. The client machine may be stationary or portable. Running multiple services in networks such as email, file storage, case-filing system etc.Advantage: Requires few server machines. Good support for multimediaDisadvantage: Need to install and maintain all the software on each client machine

Diskless workstation (Linux. Earlier this was the solution from Novell with Windows 3.X)

Good support for sound, graphics and video given a powerful enough processor and memory on the client machine.

All user applications are installed on the server machine. User programs run on the client machine. Client computer is usually stationary. Running multiple services on the network such as email, file storage, case-filing system etc.Advantages: Same functionality as thick clients. Need few servers. The client computers do not have software installed.

Thin client (X Window System)

Decent audio, graphics and video support given a powerful enough processor memory on the server machine. Needs high capacity client network.

All user programs and services are installed on the server machine. The user programs running on servers. The client computer is usually stationary. Running multiple services in networks such as email, file storage, case-filing system etc.Advantage: Gives new life to reused computers. Client does not have installed software.Disadvantage: Requires more servers than thick and diskless clients.

Graphical terminals (FreeNX, Citrix, RDP)

Decent graphics support given powerful enough processor memory on the server machine, and high capacity network. Weak or little support for interactive graphics at medium capacity network.

All user programs and services are installed on the server machine. A full operating system with a graphical interface is usually installed on the client machine. The user programs run on the server. The client computer is usually stationary. Several network services such as email, file storage, case-filing system etc. are provided.Advantage: Gives new life to reused computers.Disadvantage: Must install and maintain the operating system on each client machine. Requires more servers than real thin clients. Requires significantly more servers than thick or diskless clients. Gives poor performance or no support for multimedia. The terminal disconnects with network overloads. This may happen several times an hour.

Laptops

Good support for sound, graphics and video with powerful enough processor and memory on the client machine.

Advantage: Can take the PC anywhere suitableDisadvantage: Must install and maintain the operating system on each client machine. Must set up and maintain services that make it easy to connect and disconnect machines on the network. There is considerable breakage with portable equipment, and lifetimes average 3 years; that's 2-5 years less than desktops. Administration of portable devices is expensive.

8.4.2. Solution

8.4.3. Exception handling

8.4.4. Verification

8.4.5. Update the configuration database

8.5. Switches

User case: What's should be configured

8.5.1. Solution

8.5.2. Exception handling

8.5.3. Verification

8.5.4. Update the configuration database

8.6. Wireless access points

User case: What's should be configured

8.6.1. Solution

8.6.2. Exception handling

8.6.3. Verification

8.6.4. Update the configuration database

8.7. Firewall(s)

User case: What's should be configured

8.7.1. Solution

8.7.2. Exception handling

8.7.3. Verification

8.7.4. Update the configuration database

8.8. Routers

User case: What's should be configured

8.8.1. Solution

8.8.2. Exception handling

8.8.3. Verification

8.8.4. Update the configuration database

8.9. Setting up a simple firewall

User case: What's should be configured

8.9.1. Solution

8.9.2. Exception handling

8.9.3. Verification

8.9.4. Update the configuration database

8.10. Setup:

User case: What's should be configured

8.10.1. Solution

8.10.2. Exception handling

8.10.3. Verification

8.10.4. Update the configuration database

9. Useful commands

9.1. Support for 4 GB memory <-- included in configuration management

Use Case: Because there is limited space on the Skolelinux/Debian-Edu CD only one Linux kernel is included, i.e. the lowest common denominator. That means a kernel working at as many as possible different types of hardware is included.

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

You can find out the type of kernel running with the command uname -a. The command can be used later to ensure that you have upgraded to the required core. Then it may look like this:

tjener:~# uname  -a
Linux tjener.intern 2.6.8-2-386 #1 Thu May 19 17:40:50 JST 2005 i686 GNU/Linux

Here runs a 386-core, which should work on just about all of the PCs. But it is not optimal for dual core processors or more than 940MB.

If you want a kernel for new servers with plenty of memory and multiple processors, you can download and install it afterwards. Debian's package system makes that easy.

Look at Section 8.9 for a more detailed description of apt-get and dpkg.

smp is the keyword to look for when you want a Linux kernel with support for more RAM than 940MB of memory and dual processors. The acronym stands for Symmetric Multi-Processors. The command is run from a shell which lists the number of cores ready for installation:

apt-cache search kernel-image | grep smp

. At the time this is written the following is listed:

kernel-image-2.4-686-smp - Linux kernel image for version 2.4 on PPro/Celeron/PII/PIII/P4 SMP
kernel-image-2.4-k7-smp - Linux kernel image for version 2.4 on AMD K7 SMP
kernel-image-2.4.27-2-686-smp - Linux kernel image for version 2.4.27 on PPro/Celeron/PII/PIII/P4 SMP
kernel-image-2.4.27-2-k7-smp - Linux kernel image for version 2.4.27 on AMD K7 SMP
kernel-image-2.6-686-smp - Linux kernel image for version 2.6 on PPro/Celeron/PII/PIII/P4 SMP.
kernel-image-2.6-amd64-k8-smp - Linux kernel image for version 2.6 on AMD64 SMP systems
kernel-image-2.6-em64t-p4-smp - Linux kernel image for version 2.6 on Intel EM64T SMP systems
kernel-image-2.6-k7-smp - Linux kernel image for version 2.6 on AMD K7 SMP.
kernel-image-2.6.8-11-amd64-k8-smp - Linux kernel image for version 2.6.8 on AMD64 SMP systems
kernel-image-2.6.8-11-em64t-p4-smp - Linux kernel image for version 2.6.8 on Intel EM64T SMP systems
kernel-image-2.6.8-2-686-smp - Linux kernel image for version 2.6.8 on PPro/Celeron/PII/PIII/P4 SMP.
kernel-image-2.6.8-2-k7-smp - Linux kernel image for version 2.6.8 on AMD K7 SMP.

There is no need to specify a specific kernel version like 2.4.27 or 2.6.8. Just use 2.4 or 2.6. This boils down to

kernel-image-2.4-686-smp - Linux kernel image for version 2.4 on PPro/Celeron/PII/PIII/P4 SMP
kernel-image-2.4-k7-smp - Linux kernel image for version 2.4 on AMD K7 SMP
kernel-image-2.6-686-smp - Linux kernel image for version 2.6 on PPro/Celeron/PII/PIII/P4 SMP.
kernel-image-2.6-amd64-k8-smp - Linux kernel image for version 2.6 on AMD64 SMP systems
kernel-image-2.6-em64t-p4-smp - Linux kernel image for version 2.6 on Intel EM64T SMP systems
kernel-image-2.6-k7-smp - Linux kernel image for version 2.6 on AMD K7 SMP.

Now you just need to know what kind of processor you have eg. 686 (Intel), k7 (AMD) AMD64 or EM64T

As soon as which kernel fit the machine best it can be installed using the command

apt-get install kernel-image-2.6-<your processor type>-smp

If the machine contain an Intel Xeon one can use

apt-get install kernel-image-2.6-686-smp

If a 2.4 kernel is used

apt-get install kernel-image-2.4-<your processor type>-smp

With an AMD Athlon(TM) MP 2000 it is possible to use

apt-get install kernel-image-2.6-k7-smp

When you install the new kernel, you may see something like this:

tjener:~# apt-get update
tjener:~# apt-get install kernel-image-2.6-686-smp
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
  kernel-image-2.6.8-2-686-smp
Suggested packages:
  lilo kernel-doc-2.6.8 kernel-source-2.6.8
Recommended packages:
  irqbalance
The following NEW packages will be installed:
  kernel-image-2.6-686-smp kernel-image-2.6.8-2-686-smp
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 15.3MB of archives.
After unpacking 44.9MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ftp.debian.org sarge/main kernel-image-2.6.8-2-686-smp 2.6.8-16 [15.3MB]
Get:2 http://ftp.debian.org sarge/main kernel-image-2.6-686-smp 101 [2154B]
Fetched 15.3MB in 1m13s (208kB/s)
Selecting previously deselected package kernel-image-2.6.8-2-686-smp.
(Reading database ... 80762 files and directories currently installed.)
Unpacking kernel-image-2.6.8-2-686-smp (from .../kernel-image-2.6.8-2-686-smp_2.6.8-16_i386.deb) ...
Selecting previously deselected package kernel-image-2.6-686-smp.
Unpacking kernel-image-2.6-686-smp (from .../kernel-image-2.6-686-smp_101_i386.deb) ...
Setting up kernel-image-2.6.8-2-686-smp (2.6.8-16) ...
File descriptor 3 left open
File descriptor 4 left open
File descriptor 5 left open
File descriptor 6 left open
File descriptor 7 left open
    Finding all volume groups
    Finding volume group "vg_data"
    Finding volume group "vg_system"
Searching for GRUB installation directory ... found: /boot/grub .
Testing for an existing GRUB menu.list file... found: /boot/grub/menu.lst .
Searching for splash image... none found, skipping...
Found kernel: /boot/vmlinuz-2.6.8-2-686-smp
Found kernel: /boot/vmlinuz-2.6.8-2-386
Updating /boot/grub/menu.lst ... done
Setting up kernel-image-2.6-686-smp (101) ...

As shown, you were asked to install kernel-image-2.6-686-smp, and it automatically translated to install kernel-image-2.6.8-2-686-smp. It was also suggested to install some other packages that might be useful.

Reboot the machine with the command: shutdown -r now

9.1.1. Exception handling

To activate a new kernel the machine need to be rebooted.

Building the kernel for a Skolelinux / Debian-Edu machine, is the only time you ever need a restart. When installing other programs there is no need for a restart.

9.1.2. Verification

When running the command uname -a after installation, the following is displayed

tjener:~# uname  -a
Linux tjener.intern 2.6.8-2-686-smp #1 SMP Thu May 19 17:27:55 JST 2005 i686 GNU/Linux

After the installation of the smp kernel and after the reboot, you can run the command free and cat /proc/cpuinfo. Then you can see if the new kernel uses all memory and both processors.

ltspserver00:~# free
             total       used       free     shared    buffers     cached
Mem:       4074752    4045556      29196          0     339248    2327780
-/+ buffers/cache:    1378528    2696224
Swap:      1835000       5852    1829148

Here is a shortened printing with the unnecessary printing removed .

ltspserver00:~# cat /proc/cpuinfo
processor       : 0
vendor_id       : !GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Xeon(TM) CPU 2.66GHz

processor       : 1
vendor_id       : !GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Xeon(TM) CPU 2.66GHz

processor       : 2
vendor_id       : !GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Xeon(TM) CPU 2.66GHz

processor       : 3
vendor_id       : !GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Xeon(TM) CPU 2.66GHz

9.1.3. Update the configuration database

9.2. Administrating packages (apt-get)

Use case: Installing new programs or update programs

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

To install packages one needs to tell from where they should be fetched. In other words, which package archive to use.

One can specify package archives in the file /etc/apt/sources.list

You can work with package management on the command line. There is more graphical applications like for example KPackage 7 or Webmin 12

This section provides a quick introduction to using the command line for administrating packages.

This is the content of a file with references to package repositories on the Internet or from a CD ROM:

#deb file:///cdrom/ sarge main local

deb cdrom:[Debian GNU/Linux edu _Sarge_ - Unofficial i386 Binary-1 (20050808)]/ unstable contrib local main non-free

 1. deb http://security.debian.org/ stable/updates main contrib non-free
 1.deb http://security.debian.org/ sarge/updates main contrib non-free
   1. Use (by uncommenting) either http or ftp, NOT both
   1. http based apt source: ----------------
 1. deb http://ftp.debian.org/debian/ sarge main contrib non-free
 1. deb http://non-us.debian.org/debian-non-US/ sarge/non-US main contrib non-free
 1. deb http://ftp.skolelinux.no/skolelinux/ sarge local
   1. ftp based apt source: -----------------
 1. deb ftp://ftp.debian.org/debian/ sarge main contrib non-free
 1. deb ftp://non-us.debian.org/debian-non-US/ sarge/non-US main contrib non-free
 1. deb ftp://ftp.skolelinux.no/skolelinux/ sarge local

Note that the lines without hashtag (#) can be used as reference to the package archive. The example shows that one only gets packets from the CD ROM used during installation. Other archives are not activated. When doing this, one should open for security upgrades. So you can try other archives for more packages.

As a start it should look something like this:

#deb file:///cdrom/ sarge main local

 1.deb cdrom:[Debian GNU/Linux edu _Sarge_ - Unofficial i386 Binary-1 (20050808)]/ unstable contrib local main non-free

 1.deb http://security.debian.org/ stable/updates main contrib non-free
deb http://security.debian.org/ sarge/updates main contrib non-free
   1. Use (by uncommenting) either http or ftp, NOT both
   1. http based apt source: ----------------
deb http://ftp.debian.org/debian/ sarge main contrib non-free
deb http://non-us.debian.org/debian-non-US/ sarge/non-US main contrib non-free
deb http://ftp.skolelinux.no/skolelinux/ sarge local
   1. ftp based apt source: -----------------
 1. deb ftp://ftp.debian.org/debian/ sarge main contrib non-free
 1. deb ftp://non-us.debian.org/debian-non-US/ sarge/non-US main contrib non-free
 1. deb ftp://ftp.skolelinux.no/skolelinux/ sarge local

Note that there is a # sign in front of the line containing "deb: cdrom". There is no need to load packages from a CD-ROM when one can get everything from the Internet.

If you add a new line to this file, you must update the database with information about what that is available.

See chapter 13 for other lines to add as package sources.

9.2.1. Exception handling

Links to package archives have a specific form. Failure to follow this gives error messages when updating, asking to correct the error.

The comment sign (#) is also in place in front of several lines in the file. The technique of "commenting out" is typical for most configuration files in Linux. Other symbols to be used is the semicolon (;) and double slashes (//). But here, the hashtag is in force, and when removed, what is written on the line is operative.

9.3. Update the package archive

Use case: Update the package repository with a summary of updated programs.

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

The selection of available packages is constantly updated. The most common is new security updates. New versions of the software can also be posted. Therefore, one must update the package archives. This is done with the following command

tjener:~# apt-get update
Get:1 http://ftp.skolelinux.no sarge/local Packages [17.4kB]
Ign http://ftp.skolelinux.no sarge/local Release
Get:2 http://non-us.debian.org sarge/non-US/main Packages [20B]
Get:3 http://non-us.debian.org sarge/non-US/main Release [102B]
Get:4 http://non-us.debian.org sarge/non-US/contrib Packages [20B]
Get:5 http://non-us.debian.org sarge/non-US/contrib Release [105B]
Get:6 http://non-us.debian.org sarge/non-US/non-free Packages [20B]
Get:7 http://non-us.debian.org sarge/non-US/non-free Release [106B]
Get:8 http://ftp.debian.org sarge/main Packages [3347kB]
Get:9 http://security.debian.org sarge/updates/main Packages [155kB]
Get:10 http://security.debian.org sarge/updates/main Release [110B]
Get:11 http://security.debian.org sarge/updates/contrib Packages [538B]
Get:12 http://security.debian.org sarge/updates/contrib Release [113B]
Get:13 http://security.debian.org sarge/updates/non-free Packages [20B]
Get:14 http://security.debian.org sarge/updates/non-free Release [114B]
Get:15 http://ftp.debian.org sarge/main Release [95B]
Get:16 http://ftp.debian.org sarge/contrib Packages [56.2kB]
Get:17 http://ftp.debian.org sarge/contrib Release [98B]
Get:18 http://ftp.debian.org sarge/non-free Packages [58.4kB]
Get:19 http://ftp.debian.org sarge/non-free Release [99B]
Fetched 3635kB in 23s (157kB/s)
Reading Package Lists... Done

This command must be executed before an upgrade or before adding new packages.

9.3.1. Exception handling

9.3.2. Verification

9.4. Update to new packages

Use case: Updating the installed packages to a newer version if one is available

Author: Klaus Ade Johnstad

Co-author: Knut Yrvin

All installed packages can be upgraded to newer versions using the command

apt-get upgrade

tjener:~# apt-get upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be upgraded:
  apache apache-common apache2-utils bsdutils cfengine cfengine-doc courier-authdaemon courier-base courier-imap courier-imap-ssl courier-ldap
  courier-ssl cpio debian-edu-config debian-edu-install education-common education-main-server education-networked education-tasks libapr0 libice6
  libmysqlclient12 libpam-ldap libpcre3 libsensors3 libsm6 libsnmp-base libsnmp5 libssl0.9.7 libungif4g libx11-6 libxext6 libxft1 libxi6 libxmu6 libxmuu1
  libxp6 libxpm4 libxrandr2 libxt6 libxtrap6 libxtst6 localization-config lynx mount mysql-common ntp ntp-refclock ntp-server ntpdate openssl python2.3
  slbackup snmp squid squid-common tcpdump util-linux xdebconfigurator xfree86-common xlibs xlibs-data
62 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 23.7MB of archives.
After unpacking 225kB disk space will be freed.
Do you want to continue? [Y/n]

Just press Enter or 'Y' and Enter. The packages will be downloaded and installed automatically. One will get a change log when the upgrade begins.

Once you have upgraded, you can delete the packages downloaded in the directory/var/cache/apt/archives/. Use the command

apt-get clean

to clear the archive. This should be done occasionally. Otherwise /var becomes full.

9.4.1. Warning

Sometimes it's OK to see what is going to happen before upgrading. If judging whether it is necessary to download several large packages, maybe you need to wait until there is more bandwidth available. If you run

apt-get upgrade --simulate

if one will simulate what will happen, without it actually happens. Is it too much information on the screen, one can run

apt-get upgrade --simulate | more

If it looks good, one can run the command again without the --simulate parameter

It is also possible to use aptitude dist-upgrade in combination with apt-get upgrade.

9.4.2. Exception handling

Sometimes you will get a message about changes affecting packages to upgrade or install, as in here

kdeaddons (4:3.1.0-4) unstable; urgency=low

  * Rebuilt against libvorbis0a (closes: #184713).
  * Removed alpha compile flags.
  * Fresh admin/ sync.

 -- Ben Burton <bab@debian.org>  Sun, 16 Mar 2003 16:00:19 +1100

kdeaddons (4:3.1.0-2) unstable; urgency=low

  * First KDE3 upload to debian!
  * Applied Ewald Snel's patch for xine support.
  * Rolled the epoch to aid upgrades from the unofficial repository on
    ftp.kde.org.. *sigh*

Use Space on the keyboard to browse through the message. Then you will see

quanta (1:3.0pr1-1) unstable; urgency=low

  * New upstream release.
  * Built for KDE3.

 -- Ben Burton <benb@acm.org>  Wed,  4 Sep 2002 10:36:12 +1000

(END)

Press the q key to quit and you get

Fetched 60.2MB in 11m24s (87.9kB/s)
Reading changelogs... Done
apt-listchanges: Do you want to continue? [Y/n]?

To continue you need to press Y for Yes.

9.4.3. Verification

9.5. Summary of installed packages

Use case: Want a summary of installed packages

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

To get a summary of the installed packages run this command

dpkg --list | more

Note that when the first letters in the list is "ii" it mean the package is fully installed.

To get the status of one particular package one can use grep to search for it:

tjener:~# dpkg --list | grep apache
ii  apache         1.3.33-6       versatile, high-performance HTTP server
ii  apache-common  1.3.33-6       support files for all Apache webservers
ii  apache2-utils  2.0.54-4       utility programs for webservers

9.6. Find the name of a particular package

Use case: Often it is hard to remember the name of a package.

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

To find a particular package one can use a search term with this command:

apt-cache search <package name>

Try this if there is too much text on the screen

apt-cache search <package name>|more

The two symbols < and > must not be used. They are only used in this example.

tjener:~# apt-cache search apache
apache - versatile, high-performance HTTP server
apache-common - support files for all Apache webservers
apache-dbg - debug versions of the Apache webservers
apache-dev - development kit for the Apache webserver
apache-doc - documentation for the Apache webserver
apache-perl - versatile, high-performance HTTP server with Perl support
apache-ssl - versatile, high-performance HTTP server with SSL support
apache-utils - utility programs for webservers (transitional package)

As the screen dump show there are a lot more related to apache than the packages already installed.

9.7. Show available information about packages

User case: Want to get information about the package. There may be dependencies to other packages etc..

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

The command

apt-cache showpkg <package name>

and

<apt-cache policy <package name>

gives details about the package.

tjener:~# apt-cache showpkg kdissert
Package: kdissert
Versions:
0.3.8-1(/var/lib/apt/lists/ftp.debian.org_debian_dists_sarge_main_binary-i386_Packages)

Reverse Depends:
Dependencies:
0.3.8-1 - kdelibs4 (2 4:3.3.2-4.0.2) libc6 (2 2.3.2.ds1-4) libgcc1 (2 1:3.4.1-3) libqt3c102-mt (2 3:3.3.3) libstdc++5 (2 1:3.3.4-1)
Provides:
0.3.8-1 -
Reverse Provides:
tjener:~# apt-cache policy  kdissert
kdissert:
  Installed: (none)
  Candidate: 0.3.8-1
  Version Table:
     0.3.8-1 0
        500 http://ftp.debian.org sarge/main Packages

So one notices that the package kdissert is not installed, but available for installation in version 0.3.8-1 from `http://ftp.debian.org sarge/main`

9.8. Installation of packages

Use case: Want to install a program or a program package.

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

When you have found the package to be installed, run the command

apt-get install <package name>

If you want to see what happened during the installation you should run a simulation first with the command

apt-get install <package name> --simulate

tjener:~# apt-get install  aterm --simulate
Reading Package Lists... Done
Building Dependency Tree... Done
The following NEW packages will be installed:
  aterm
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Inst aterm (0.4.2-11 Debian:3.1r0/stable)
Conf aterm (0.4.2-11 Debian:3.1r0/stable)
tjener:~# apt-get install  aterm
Reading Package Lists... Done
Building Dependency Tree... Done
The following NEW packages will be installed:
  aterm
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 91.6kB of archives.
After unpacking 287kB of additional disk space will be used.
Get:1 http://ftp.debian.org sarge/main aterm 0.4.2-11 [91.6kB]
Fetched 91.6kB in 1s (71.0kB/s)
Selecting previously deselected package aterm.
(Reading database ... 32924 files and directories currently installed.)
Unpacking aterm (from .../aterm_0.4.2-11_i386.deb) ...
Setting up aterm (0.4.2-11) ... 

9.9. Removal of installed packages

Use case: Wants to remove certain packages that will not be used.

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

To find a specific package to be removed, use the commands listed above.

When you have found the name of the package run the command

apt-get remove <package name>

If you want to see what happens when you remove the package, you may simulate this with the command

apt-get remove <package name> --simulate

tjener:~# apt-get remove  aterm --simulate
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
  aterm
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Remv aterm (0.4.2-11 Debian:3.1r0/stable)
tjener:~# apt-get remove  aterm
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
  aterm
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0B of archives.
After unpacking 287kB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 32936 files and directories currently installed.)
Removing aterm ...

9.10. Install a specific package version

User case: Want a specific version of a package. It can for example be a previous release of a program.

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

When installing a package with the command

apt-get install <package name>

then the newest package is installed. Sometimes an older version instead of the newest version is wanted.

apt-get install <package name>=older_version_number

To get an older version of the Webmin backup module one can run

apt-cache showpkg webmin-slbackup

to get a summary of the available version

tjener:~#  apt-cache policy webmin-slbackup
webmin-slbackup:
  Installed: 0.0.10-1
  Candidate: 0.0.10-1
  Version Table:
 *** 0.0.10-1 0
        500 http://ftp.skolelinux.no sarge/local Packages
        100 /var/lib/dpkg/status
     0.0.9-1 0
        500 http://ftp.debian.org sarge/main Packages

Here one can see that there are two versions available. Both 0.0.9-1 and 0.0.10-1

If the 0.0.9-1 version of the program is wanted it can be installed using the following command

apt-get install webmin-slbackup=0.0.9-1

tjener:~# apt-get install webmin-slbackup=0.0.9-1 --simulate
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be DOWNGRADED:
  webmin-slbackup
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
Inst webmin-slbackup [0.0.10-1] (0.0.9-1 Debian:3.1r0/stable)
Conf webmin-slbackup (0.0.9-1 Debian:3.1r0/stable)
tjener:~# apt-get install webmin-slbackup=0.0.9-1
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be DOWNGRADED:
  webmin-slbackup
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
Need to get 22.0kB of archives.
After unpacking 131kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ftp.debian.org sarge/main webmin-slbackup 0.0.9-1 [22.0kB]
Fetched 22.0kB in 0s (23.6kB/s)
dpkg - warning: downgrading webmin-slbackup from 0.0.10-1 to 0.0.9-1.
(Reading database ... 32924 files and directories currently installed.)
Preparing to replace webmin-slbackup 0.0.10-1 (using .../webmin-slbackup_0.0.9-1_all.deb) ...
Unpacking replacement webmin-slbackup ...
Setting up webmin-slbackup (0.0.9-1) ...

9.11. Install a package using dpkg

User case: Sometimes it is needed to download a package from other places, not located in a Debian web archive. Opera browser is such a package.

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

Download the package from the home page of the creators of the program. This could for example be Opera. The program is installed using the following command:

dpkg -i <full path to the package>

. If you first want to simulate this try

dpkg --no-act -i <full path to package>

tjener:~# dpkg --install --no-act opera_8.51-20051114.5-sharedqt_en_sarge_i386.deb
Selecting previously deselected package opera.
(Reading database ... 32924 files and directories currently installed.)
Unpacking opera (from opera_8.51-20051114.5-shared-qt_en_sarge_i386.deb) ...
tjener:~# dpkg --install  opera_8.51-20051114.5-shared-qt_en_sarge_i386.deb
Selecting previously deselected package opera.
(Reading database ... 32924 files and directories currently installed.)
Unpacking opera (from opera_8.51-20051114.5-shared-qt_en_sarge_i386.deb) ...
dpkg: dependency problems prevent configuration of opera:
 opera depends on libqt3c102-mt; however:
  Package libqt3c102-mt is not installed.
dpkg: error processing opera (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 opera

dpkg requires more manipulations than apt-get because it does not handle package dependencies. This means you may need to run apt-get immediately afterwards with additional parameter. For example, it helps to run apt-get --fix-broken to tidy up

tjener:~# apt-get install --fix-broken --simulate
Reading Package Lists... Done
Building Dependency Tree... Done
Correcting dependencies... Done
The following extra packages will be installed:
  libaudio2 liblcms1 libmng1 libqt3c102-mt libxcursor1 libxft2
Suggested packages:
  nas liblcms-utils libqt3c102-mt-psql libqt3c102-mt-mysql libqt3c102-mt-odbc
The following NEW packages will be installed:
  libaudio2 liblcms1 libmng1 libqt3c102-mt libxcursor1 libxft2
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Inst libaudio2 (1.7-2 Debian:3.1r0/stable) [opera ]
Inst liblcms1 (1.13-1 Debian:3.1r0/stable) [opera ]
Inst libmng1 (1.0.8-1 Debian:3.1r0/stable) [opera ]
Inst libxcursor1 (1.1.3-1 Debian:3.1r0/stable) [opera ]
Inst libxft2 (2.1.7-1 Debian:3.1r0/stable) [opera ]
Inst libqt3c102-mt (3:3.3.4-3 Debian:3.1r0/stable)
Conf libaudio2 (1.7-2 Debian:3.1r0/stable)
Conf liblcms1 (1.13-1 Debian:3.1r0/stable)
Conf libmng1 (1.0.8-1 Debian:3.1r0/stable)
Conf libxcursor1 (1.1.3-1 Debian:3.1r0/stable)
Conf libxft2 (2.1.7-1 Debian:3.1r0/stable)
Conf libqt3c102-mt (3:3.3.4-3 Debian:3.1r0/stable)
Conf opera (8.51-20051114.5 )
tjener:~# apt-get install --fix-broken
Reading Package Lists... Done
Building Dependency Tree... Done
Correcting dependencies... Done
The following extra packages will be installed:
  libaudio2 liblcms1 libmng1 libqt3c102-mt libxcursor1 libxft2
Suggested packages:
  nas liblcms-utils libqt3c102-mt-psql libqt3c102-mt-mysql libqt3c102-mt-odbc
The following NEW packages will be installed:
  libaudio2 liblcms1 libmng1 libqt3c102-mt libxcursor1 libxft2
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 3489kB of archives.
After unpacking 8753kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ftp.debian.org sarge/main libaudio2 1.7-2 [71.5kB]
Get:2 http://ftp.debian.org sarge/main liblcms1 1.13-1 [123kB]
Get:3 http://ftp.debian.org sarge/main libmng1 1.0.8-1 [171kB]
Get:4 http://ftp.debian.org sarge/main libxcursor1 1.1.3-1 [23.7kB]
Get:5 http://ftp.debian.org sarge/main libxft2 2.1.7-1 [54.4kB]
Get:6 http://ftp.debian.org sarge/main libqt3c102-mt 3:3.3.4-3 [3045kB]
Fetched 3489kB in 16s (212kB/s)
Selecting previously deselected package libaudio2.
(Reading database ... 33027 files and directories currently installed.)
Unpacking libaudio2 (from .../libaudio2_1.7-2_i386.deb) ...
Selecting previously deselected package liblcms1.
Unpacking liblcms1 (from .../liblcms1_1.13-1_i386.deb) ...
Selecting previously deselected package libmng1.
Unpacking libmng1 (from .../libmng1_1.0.8-1_i386.deb) ...
Selecting previously deselected package libxcursor1.
Unpacking libxcursor1 (from .../libxcursor1_1.1.3-1_i386.deb) ...
Selecting previously deselected package libxft2.
Unpacking libxft2 (from .../libxft2_2.1.7-1_i386.deb) ...
Selecting previously deselected package libqt3c102-mt.
Unpacking libqt3c102-mt (from .../libqt3c102-mt_3%3a3.3.4-3_i386.deb) ...
Setting up libaudio2 (1.7-2) ...

Setting up liblcms1 (1.13-1) ...

Setting up libmng1 (1.0.8-1) ...

Setting up libxcursor1 (1.1.3-1) ...

Setting up libxft2 (2.1.7-1) ...

Setting up libqt3c102-mt (3.3.4-3) ...

Setting up opera (8.51-20051114.5) ...

Armed with different commands from earlier in this chapter, we can now confirm that Opera is already installed

tjener:~# apt-cache policy opera
opera:
  Installed: 8.51-20051114.5
  Candidate: 8.51-20051114.5
  Version Table:
 *** 8.51-20051114.5 0
        100 /var/lib/dpkg/status
tjener:~# dpkg --list|grep opera

ii opera 8.51-20051114. The Opera Web Browser

9.12. Search through files in a package

Use case: Want to find a program name or file in a package

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

You get an overview with the command

dpkg --listfiles <package name>

tjener:~# dpkg --listfiles opera
/usr/bin
/usr/bin/opera
.
.
.
/etc
/etc/opera6rc
/etc/opera6rc.fixed

9.13. Find which package a file came from

User case: Want to find the package a file came from.

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

dpkg --search <filename>

This can look like this

tjener:~# dpkg --search /etc/opera6rc.fixed
opera: /etc/opera6rc.fixed

9.14. Unpackaging files from a package without installing the package

Use case: Perhaps an important system file was deleted by accident, and there is no backup.

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

When using the command

dpkg --search <filename>

Warning: Never unpack packages in the root directory

if one finds which package a file came from. One can extract the package to get back the systemfile like shown later.

First you need to fetch the deb package in question. This can be done by placing it in the /tmp directory. Use this command to unpack the files in this directory

dpkg --vextract <package name> /tmp

. Then the required directories will be created in /tmp and the files are placed there.

dpkg --vextract <package name> /tmp

9.15. Make your own package mirror

Use case: Some packages are often installed. For others it is useful to avoid downloading them from the Internet.

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

The apt-get command makes it easy to install packages from the Internet. But apt-get will use significant network capacity when programs are downloaded from Debian archives on the Internet. Because of that, it is possible to tell apt-get to use a local package repository. This way it is possible to install already downloaded packages simply by using apt-get. This provides quick installation.

mkdir /var/www/dpkg

cp /var/cache/apt/archives/*.deb /var/www/dpkg

cd /var/www/

dpkg-scanpackages dpkg /dev/null | gzip -9c > dpkg/Packages.gz

After that, add a new line to the file /etc/apt/sources.list:

deb file:///var/www dpkg/

And then the command apt-get update must be executed as usual to update the packages in the database.

9.16. Secure login to the firewall (ssh)

Use case: Some times it is required to log into Coyote Linux when no web browser is available. Perhaps the command line is preferred? Then ssh can be used to connect to Coyote Linux.

If you are logged into a machine in a Skolelinux / Debian Edu network you can use

ssh -l root 10.0.2.1

to log in on Coyote Linux

If you are outside a Skolelinux / Debian Edu network, the value 10.0.2.1 can be replaced with the appropriate value for the network card with the WAN in. In this case it might be ssh -l root 192.168.1.10

Here you will meet the same options present as when logged into the Coyote Linux web administration. This is presented in a text based menu.

               Coyote Linux Gateway -- Configuration Menu


  1) Edit main configuration file         2) Change system password
  3) Edit rc.local script file            4) Custom firewall rules file
  5) Edit firewall configuration          6) Edit port forward configuration

  c) Show running configuration           f) Reload firewall
  r) Reboot system                        w) Write configuration to disk

  q) quit                                 e) Exit
  ----------------------------------------------------------------------------
  Selection:

The options will be approximately the same as those provided when logged into Coyote Linux for web administration. See section 3.7 for a quick description of the menu choices.

When selecting q) quit you will end up on the command line in Coyote Linux. If you need to get back to the main menu in Coyote Linux, write menu and press Enter.

If you see this when you try to log into Coyote Linux

klaus@tjener:~$ ssh 10.0.2.1 -l root
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
34:b7:a3:9b:06:4c:e2:30:1b:0d:03:45:7b:22:b7:dd.
Please contact your system administrator.
Add correct host key in /skole/tjener/home0/klaus/.ssh/known_hosts to get rid of this message.
Offending key in /skole/tjener/home0/klaus/.ssh/known_hosts:27
RSA host key for 10.0.2.1 has changed and you have requested strict checking.
Host key verification failed.

This is most likely because one logged in earlier into another machine with the IP address 10.0.2.1, or because the network card in Coyote Linux has been changed. It could also be an attack from an unknown man in the middle. The solution is to remove the key, in this case line number 27 in the /skole/tjener/home0/klaus/.ssh/known_hosts file.

9.16.1. Exception handling

9.16.2. Verification

9.16.3. Update the configuration database

9.17. Status summary for the firewall (Coyote)

Use case: Which commands can be used to get the menu or to get an overview of the status of the firewall?

Main author: Klaus Ade Johnstad

Useful commands in Coyote Linux

  • ping

Useful to figure out if the network is working. The command checks if there is a connection to the Skolelinux / Debian Edu main server.

coyote# ping -c5 10.0.2.2
PING 10.0.2.2 (10.0.2.2): 56 data bytes
64 bytes from 10.0.2.2: icmp_seq=0 ttl=64 time=0.9 ms
64 bytes from 10.0.2.2: icmp_seq=1 ttl=64 time=0.5 ms
  • uptime

This command gives the duration since the last reboot for Coyote Linux.

   coyote# uptime\n  2:37pm  up 80 days,  7:55, load average: 0.00, 0.00, 0.00
  • dmesg

This command displays information about the Linux kernel running on the machine. It lists things like memory, processor and network card. If there is too much output from dmesg you can send the output through a so called pager program like "more" and use Space to read everything, dmesg|more

  • ifconfig

Show extra information about the network cards.

coyote# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:50:FC:F8:D2:44
          inet addr:10.0.2.1  Bcast:10.0.3.255  Mask:255.255.254.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:314723 errors:0 dropped:0 overruns:0 frame:0
          TX packets:312105 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:53700845 (51.2 !MiB)  TX bytes:277496136 (264.6 !MiB)
          Interrupt:11 Base address:0x7000

eth1      Link encap:Ethernet  HWaddr 00:E0:18:A8:B1:BA
          inet addr:192.168.100.133  Bcast:192.168.100.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:307395 errors:0 dropped:0 overruns:0 frame:0
          TX packets:281202 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:272404311 (259.7 !MiB)  TX bytes:47880640 (45.6 !MiB)
          Interrupt:10 Base address:0xb800 Memory:e3000000-e3000038

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:14565 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14565 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1290756 (1.2 !MiB)  TX bytes:1290756 (1.2 !MiB)
  • lsmod

This command lists up driver modules. This is useful to see which modules are used by network cards.

coyote# lsmod
Module                  Size  Used by
eepro100               17516   1
3c59x                  24408   1
mii                     1852   0 [eepro100]
ip_nat_quake3           1608   0 (unused)
ip_nat_mms              2448   0 (unused)
ip_nat_h323             2044   0 (unused)
ip_nat_amanda           1020   0 (unused)

This is a list showing that the driver modules for the network card are loaded. For Intel pro100 the module is named eepro100 and for 3Com the module is named 3c59x (which is valid for cards with type names 3c590, 3c595, 3c900, 3c905). See section 3.12

  • route

  • traceroute

Is useful to figure out where the Internet packages move. If there are problems, it is useful to see the path the Internet packages use.

  • showcfg

Another command giving information about the state of the network cards.

Coyote running configuration display utility.

Internet    (eth1): UP
LAN network (eth0): UP

-------------Internet configuration--------------
IP Address   192.168.100.133 (Static)
Netmask      255.255.255.0
Gateway      192.168.100.2
----------------LAN configuration----------------
IP Address   10.0.2.1
Netmask      255.255.254.0
Broadcast    10.0.3.255
----------------DNS configuration----------------
domain localdomain
nameserver 213.184.200.1
nameserver 213.184.200.2
-------------------------------------------------
10:51am up 7 days, 20:53, load average: 0.00, 0.00, 0.00

Press enter to return to system menu.
  • free

The command is used to see how much memory is available and how much is used. This machine has 32 MB memory.

coyote# free
              total         used         free       shared      buffers
  Mem:        30860         6004        24856            0            0
 Swap:            0            0            0
Total:        30860         6004        24856
  • menu

This command starts the Coyote Linux menu

               Coyote Linux Gateway -- Configuration Menu


  1) Edit main configuration file         2) Change system password
  3) Edit rc.local script file            4) Custom firewall rules file
  5) Edit firewall configuration          6) Edit port forward configuration

  c) Show running configuration           f) Reload firewall
  r) Reboot system                        w) Write configuration to disk
  • reboot

coyote#reboot

This command does a reboot of Coyote Linux

  • shutdown

coyote#halt

Here is Coyote Linux turned off

9.18. Next

Use case:

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

9.18.1. Exception handling

9.18.2. Verification

9.18.3. Update the configuration database

9.19. Last

Use case:

Author: Klaus Ade Johnstad.

Co-author: Knut Yrvin

9.19.1. Exception handling

9.19.2. Verification

9.19.3. Update the configuration database

10. Appendix A - Contract on operating Debian Edu / Skolelinux

Contract no.: ..................

Customer no.: ..................

10.1. CONTRACT ON OPERATING DEBIAN EDU / SKOLELINUX

between

Driftselskapet AS, Maskinrommet 1, 0313 Oslo

Org.no.: 989 313 313

(hereafter called The Vendor)

and

NN

Org.No:

(hereafter called The Customer)

The parties have reached an agreement on the delivery of operational services (hereinafter The Agreement) on subsequent contractual terms. The following appendixes are part of The Agreement:

  • Appendix 1 - Definitions

  • Appendix 2 - Customer Obligations

  • Appendix 3 - The Vendor's obligations

  • Appendix 4 - Prices and terms of payment

  • Appendix 5 - General provisions

  • Appendix 6 - The proxy Persons

The agreement is valid from the signing date and a minimum of 12 months from The Delivery date. The agreement is then renewed automatically for periods lasting 12 months unless one of the parties denounces the Agreement in writing, three months before the expiry of a contract period.

The contract is signed in two - 2 - copies, and each of the parties keeps one - 1 - copy.

Place: .............................

Date: .................. 2006

For The Vendor: ....................................................

For The Customer: ....................................................

10.1.1. Appendix 1 - Definitions

Term

Description

Operating period

From the Delivery day to the day when the agreement ceases to apply, regardless of the reason.

Services provided

Services from The Vendor in the Operating period. The services provided are further described in Appendix 3.

ICT manager

Competence person(s) at the customer serving as liaison(s) to the supplier.

Delivery day

The day the customer can use the services provided.

Skolelinux

Linux distribution built on Debian Linux and adjusted for use in Norwegian schools.

10.1.2. Appendix 2 - Customer Obligations

10.1.2.1. 1. ICT skill requirements

ICT administrator (1 - 3 named persons at the customer) to deal with inquiries from users related to the use of the applications included in Skolelinux/Debian Edu. ICT administrator shall have sufficient expertise to make a qualified assessment of whether a problem is related to the use or operation of the system.

The ICT administrator should contact the supplier's the user support center by phone or e-mail. The customer's users should not contact the supplier directly.

10.1.2.2. 2. Machine requirements

The Customer should have installed and tested that the equipment operates satisfactorily before the delivery day.

10.1.2.3. 3. Program requirements

The customer shall, before delivery day, have installed Skolelinux / Debian Edu to get a verified, satisfactory functioning installation.

10.1.2.4. 4. Communication requirements

The Customer shall, before the delivery date, have installed and configured communication with the Internet and tested it works satisfactorily. To make it possible to provide services, the customer must arrange for the contractor to be able to access the customer's ICT-facilities via the Internet.

10.1.2.5. 5. Information from The Vendor

When all the above requirements are met, the customer shall notify the contractor, in writing or by e-mail, that the ICT-system is prepared for the contractor for provide services.

A list of all the users of the system including full name, username and wanted password should be sent electronically to the Vendor at the latest together with this message.

10.1.3. Appendix 3 - The Vendor's obligations

10.1.3.1. 1. Delivery day requirements

The supplier shall, after receiving notification from the customer in accordance with Appendix 2, paragraph 5, as soon as possible arrange for the Customer to receive the provided services. Delivery date shall be no later than 4 weeks after such notice is received by the supplier.

10.1.3.2. 2. Information to The Customer

When all the above requirements are met, the contractor shall notify the customer, in writing or by e-mail, that the ICT-system is prepared for the customer to receive the provided services.

10.1.3.3. 3. Service requirements

The following table shows all relevant services related to operating Skolelinux/!DebianEdu. The crosses in the table show the responsibilities between the Supplier and the Customer for the different services:

Delivered (incl.) are carried out by the supplier and included in the Agreement price. Delivered (running) performed by the Supplier at the Customer's account in accordance with the rates in Chapter 7. The Customer, is done by the Supplier at the Customer's expense.

Service

Delivered (incl.)

Delivered (running)

The Customer

Troubleshooting and user support over the phone and email

x

 

Participation in the user forum

x

 

Replacing the hardware[a]

x

 

Add, change and remove users[b]

(x)

x

Changing password when the password is forgotten

(x)

x

Security updates on Skolelinux

x

 

Version updates on Skolelinux

x

 

Change the user permissions

(x)

x

Monitoring of filling on disks

x

 

Monitoring of the lifetime for the relevant components

x

 

Extending disk partitions

x

 

Operation and monitoring of firewall

x

 

Operation and monitoring of network

x

 

Deleting print jobs stuck in the queue at the request of the ICT administrator

x

 

Monitoring to ensure backup copies are taken

x

 

Data deletion under request from the ICT administrator

x

 

Replacing backup medium and storing backup copies

x

Restore with a security backup, at the request of the ICT administrator.

x

 

Set up new printers and printer queues

(x)

x

Stopping and restarting the printer queues at the request of the ICT administrator

x

 

Stopping hanging processes on the server as a result of application errors

x

 

[a] Supplier's responsibility is limited to managing the a change of hardware. The supplier is not responsible for hardware and warranties, pricing, shipping costs etc. which must bee agreed separately with machine supplier.

[b] The customer can do this using a separate application in Debian Edu. The supplier can do this server for NOK 50 per user excluding vat.

10.1.3.4. 4. Response time requirements

The supplier shall without undue delay, start troubleshooting and problem solving. ICT administrator should be held continuously updated on the status and progress of error correction.

10.1.3.5. 5. Skill requirements

The supplier shall at all times have sufficient resources with relevant expertise to provide services in a professional manner

10.1.4. Appendix 4 - Prices and terms of payment

10.1.4.1. 1. Compensation for services provided

The compensation for the services provided is calculated on the basis of the number of workstations on the network. The agreement includes a minimum of 60 workstations. The Customer shall pay the Supplier £78 per year per workstation, excluding VAT, in compensation for the services provided, i.e. £390 per month excluding VAT for 60 workstations.

If the number of workstations changes the customer shall give the supplier a written notice thereof with the corresponding dates for the change. Adjustment of the billing basis with a possible recalculation will be included in the next invoice

10.1.4.2. 2. Consultant support

Hourly rate for consultancy is NOK 800 (65 £) ex Moms (VAT). All work on an ongoing bill should be approved by the customer before work starts. Documented travel expenses are charged to the client. Compensation for travel time calculated by the elapsed time with hourly rate NOK 400 ex Moms.

10.1.4.3. 3. Payment conditions

Compensation for the services provided is billed in advance for each quarter. For the first quarter, billing starts from the delivery date and runs until the end of the current quarter.

Compensation for consultancy is billed as after-payment on the basis of agreed and work performed.

All invoicing is done within a 30 days deadline.

10.1.4.4. 4. Price regulation

Prices may be adjusted every year with the increase in the national consumer price index (SSB CPI). This can take place for the first time one year after signing the agreement.

10.1.5. Appendix 5 - General provisions

10.1.5.1. 1. The parts' cooperation and duties

General

The parties shall cooperate to achieve the most efficient implementation of the Agreement. Both parties may, in writing, summon one another to meet with five business days' notice to discuss matters arising in connection with the implementation of the Agreement. The parties are obliged, without delay, to notify each other about matters that they understand or should understand may affect the implementation of the Agreement. Such notification does not relieve the parties from the responsibilities resulting from the Agreement.

The suppliers duties

The Supplier undertakes to supply the contract business performance at the terms of the Agreement. The supplier undertakes to allocate the resources necessary to implement the commitments in the Agreement.

Customer duties

The customer shall pay the agreed compensation. The customer must assist the supplier so that the supplier will not be delayed or otherwise prevented from fulfilling the obligations. The customer undertakes to allocate the necessary resources, and ensure the necessary assistance from a third party where this is agreed.

10.1.5.2. 2.Confidentiality

The parties are mutually obliged to keep confidentiality and not disseminate information which they become aware of in connection with carrying out the out the Agreement, to the extent that such information is not considered public. The same applies to all the material which is marked confidential. personal matters, and information that could harm the parties or that can be exploited by outsiders in business. This duty of confidentiality applies to the parties and their employees and others acting on behalf of the parties in connection with carrying out the of the Agreement. The duty of confidentiality applies correspondingly after the termination of the Agreement.

10.1.5.3. 3.Force majeure

In the event of an extraordinary situation outside control of the parties, which could not be foreseen at inception and which significantly hampers the fulfilment of a party duties, the other party shall be notified without undue delay. The affected party's obligations are suspended to the extent that is relevant so long as the extraordinary situation prevails. The other party in return suspended for the same period. Either party may terminate the Agreement by giving one month's written notice if the force majeure situation makes it particularly burdensome to maintain the Agreement.

10.1.5.4. 4. Transfer of the agreement

Parties may only reassign their rights and obligations under the agreement with the written consent of the counterparties. Consent may not be unreasonably withheld. It is not considered as transfer if one of the parties mergea with one or more other companies or the assignment is to a subsidiary. Right to compensation under this Agreement may be assigned freely, but such transfer does not relieve the Contractor from its obligations and responsibilities.

10.1.5.5. 5. Non-fulfilment
10.1.5.5.1. 5.1 Delay of the delivery date
10.1.5.5.2. a. Liquidated damages

If delivery does not happen on the date agreed between the parties, and this is not due to the circumstances mentioned in Clause 3 or circumstances the Customer is responsible for, then a daily penalty is applied from the agreed delivery date. The penalty fee is 0.1% of the agreed annual compensation for the portion of services provided that are delayed, calculated per calendar day of delay and up to a maximum of 60 days. As long as daily penalties are being applied, the customer may neither terminate the Agreement nor demand a discount or other compensation for the delay.

10.1.5.5.3. b. Canceling

If the delivery date has not occurred by the end of liquidated damages period, you may terminate the Agreement with immediate effect.

10.1.5.5.4. c. Delay caused by customer

In case of delay caused by customer the supplier may, by written notice, cancel their work until the customer takes corrective action. The supplier is entitled to recover their additional costs as a result of customer's breach, and a reasonable time to the reassignment of resources.

10.1.5.5.5. 5.2 Defaults in the operating period
10.1.5.5.6. 5.2.1 The suppliers non-fullfillment
10.1.5.5.7. a. Shortcomings

There is a shortcoming of the supplier if services provided do not meet the requirements and specifications stipulated in the Agreement, and this causes a circumstance for which the supplier is responsible. If there is a shortcoming in operating performance, the supplier shall without undue delay remedy the defect. Where a defect can not be repaired within a reasonable time the Customer shall be entitled to a proportionate discount, ref. Section b. Below.

10.1.5.5.8. b. Price discount for shortcomings

If the client has not been able to use the services provided, fully or partially, as a result of the defect, the customer has the right, in the period from when the error or defect was notified in writing until the defect is corrected, to receive a proportionate discount. Any refund due to lack of availability due to the same circumstance, is deducted when calculating the discount.

10.1.5.5.9. c. Canceling

In the event of any other shortcoming, that is significant to the customer's use of the services provided, and is not corrected within 30 business days after the Customer notified the supplier in writing about the shortcoming, the Customer may notify the supplier in writing of intent to terminate the Agreement. If the supplier, after such notice, has not rectified the situation within 14 business days, the customer is entitled to terminate the Agreement with immediate effect.

10.1.5.5.10. 5.2.2 The customers non-fullfillment

If the customer does not pay on time, the supplier is entitled to interest for the amount that is overdue. (In Norway, this arises from a law relating to interest on late payment of 19. Dec. 1976 no. 100, § 3, first paragraph.) In cases where the payments plus interest are not paid within 14 days of the due date, the supplier can issue written notice that the services provided will be discontinued, or that the agreement will be terminated, unless the customer settles all outstanding bills within 7 days of receipt of this notification. Upon termination of the Agreement due to the customer's fault, the supplier shall be indemnified by the customer for the costs and liabilities undertaken in connection with the Agreement.

10.1.5.6. 6.Replacement

The customer may demand compensation for losses that can be reasonably attributed to the shortcoming, unless the supplier can demonstrate that the breach, or the cause of the breach, not attributed to him. Any liquidated damages caused by delay in accordance with Clause 5a for the same breach is deducted by calculating compensation. If the customer defaults on its obligations under this Agreement, supplier shall be entitled to recover their additional costs that may reasonably be attributed to the Customer defaults, unless the Customer can prove that the breach, or cause of the breach can not be attributed to him.

Parties are not responsible for the other party's indirect losses, including expected savings or gains. Indirect losses included among others

  • Losses due to reduced or lost production or sales (operational interruption);

  • Losses arising because the services provided can not be used as intended (consequential losses);

  • Lost profits as a result of a contract with a third party that is dropped or not fulfilled properly.

Parties liability towards each other is limited to the agreed annual compensation, or a maximum of NOK 1 million, regardless of the number of damage cases. The limitations of the parties' liability does not apply, if the party or anyone he is responsible for, has shown gross negligence or willful misconduct.

10.1.5.7. 7. Legal defects

If a third party asserts that the use of software that the Customer or Vendor has license responsibility goes against the third party's rights, the Party shall ensure that appropriate rights are retained or acquired, or that other equivalent software functionality is obtained without charge to the other party. Should claims arise from a third party against the Customer or Vendor on the basis of defects inherent in the relationship of the other Party, that Party undertakes its own expense to assist and eventually lead case for both parties. From the time a party takes over the case, the other party is obliged to assist the special compensation.

10.1.5.8. 8. Responsibility for subcontractors

Parties are fully accountable for agreed services that are performed by subcontractors.

10.1.5.9. 9. Regulating the termination of the Agreement

Upon termination, the parties shall draw up a joint plan of liquidation of the customer relationship and obligations by mutual to assist each other in the practical work in this liquidation. The vendor is obliged by termination of this Agreement to return Client software and current data in the agreed format. The Customer chooses the means of transport and is responsible for transportation from the Vendors' premises. The Customer undertakes immediately after termination of the Agreement to return all equipment belonging to the Vendor. The Vendor chooses the mode of transport and is responsible for transportation from the Vendor's premises.

10.1.5.10. 10. Legalities and solving disagreements

The rights and obligations under this Agreement shall completely follow the Norwegian law. Upcoming Disagreements in connection with this Agreement shall be resolved by negotiation between the parties. If the parties fail within two weeks not to solve the disagreement through negotiations, either party may require the dispute to be resolved by arbitration under the rules of the law of 13 August 1915 No. 6, Chap. 32 (Civil Procedure). Each party shall appoint one arbitrator who together appoint the arbitration tribunal. If a party fails to designate its representative within two weeks after the other has demanded arbitration and appointed its representative, he will be appointed by the Chief Justice of the Oslo District Court. The same applies for the election of the chairman if the two arbitrators members have not chosen the President within 14 days after both being appointed.

10.1.6. Appendix 6 - Contacts and addresses

1. Correspondence Requests regarding the agreement shall be in writing and addressed as follows:

To Vendor

To Customer

Operating company LtdBy authorized personMachine room 10313 Oslo

NNBy authorized person

2. Authorized persons

The following persons do have authority to sign on their part according to the agreement.

Name

Position/Function

Telephone

Telefax

E-mail

The vendor

 

Petter Smart

CEO

+47 22 31 31 31

ps@driftselskapet.no

The Customer