Knowledge sharing for centralised administration

Small organisations are in practice dependent on individuals and therefore vulnerable if someone leaves. A thorough and quality assured system administration handbook is therefore essential to ensure stability and continuity in operating practices. The Program for Digital Literacy has the primary objective of developing a set of recommended operating solutions, with guidelines that provide schools and educational institutions with stability and predictability so that computers, networks and basic services function properly.

The ITIL book contains guidelines based on "best practices", adapted for municipalities using free software like Skolelinux to run centralized networks across multiple schools. These guidelines are adapted for municipal and regional administrative centres. Many municipalities have only one part-time position for ICT operations in schools. In Norway there are more than 300 small and medium sized municipalities; usually they have 1-4 persons working full time with ICT in each municipality. Therefore, sharing expertise and experience between operating organizations is essential for all.

License

This document is written under the GNU General Public License version 3. It means that you have:

Mer forklaring av disse frihetene er forklart på wikipedia. Torgeri Kielland på Institutt for rettsinformatikk har laget en analyse av GNU-lisensen eller vilkårene for Copyleft. Han slår fast at GNU-lisensen er opphavsrettslig relevant. Kort sagt kan du bruke alt i denne dokumentasjonen slik det passer, gitt at du sikrer fri bruk for de som mottar dokumentasjonen. Dine bidrag får også en General Public License.

Thanks

Mange har bidratt til dokumentasjonen. I hovedsak er den skrevet av Knut Yrvin og Andreas Johansen med mange bidrag fra Klaus Ade Johnstad. Halvor Dahl i Skolelinux Drift AS har vært i styringsgruppa. Han har kommet med flere bidrag når deg gjelder struktur og form, og en del innhold. I tillegg er det gitt flere bidrag Snorre Løvås fra UNINETT ABC, Finn-Arne Johansen i ?BzzWare AS, Ragnar Wissløff i ?LinuxLabs AS og referansegruppa som deltok under skriving av dokumentasjonen. Følgende har deltatt i referansegruppa:

This documentation is maintained in a wiki. This is to ensure that operations staff can easily search for solutions to problems, update configurations, and so on.

[http://www.nordicos.org/open_source/free_software/ ]

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

Background

The Program for Digital Competence is the Norwegian Ministry of Education's ICT plan from 2004 to 2008. One objective is to develop a set of recommended operating solutions and appropriate guidelines. It will provide schools and educational facilities with stability and predictability, so that computers, networks and basic services function properly. Operating solutions must be adapted to the institutions' size and needs.

This documentation contains guidelines based on practices customised for ICT-services within municipalities and counties. It is also applicable for commercial operators. Many municipalities have only one part-time position for computer networkinfg operations within the schools. Overall just 13% of the municipalities in Norway have more than 20,000 inhabitants; 73 % have less than 10,000. Usually 1-4 people work full time in ICT within the municipal administration. When it comes to schools, there is often only one part-time ICT position, which can cover approximately 500-800 client computers at 5-10 schools, with around 1700-3200 students and teachers using the system.

The documentation is also suitable for larger organisations. It is based on the ISO 20000 standard for ICT operations, also known as the ICT Infrastructure Library. See Wikipedia for more information about the standard itself: [http://en.wikipedia.org/wiki/ITIL ]

The first edition of this document was finished 19th July 2006.

The document maintained in a wiki and can be updated on [http://wiki.skolelinux.no/Dokumentasjon/ITIL ] . An earlier version is available from [http://developer.skolelinux.no/itil/oldindex.html ]

Service support

As mentioned in the introduction, it is recommended to begin by establishing an office for centralized operations to allow you to manage tickets. The benefits of this come quickly and are visible, which is important for customer and user satisfaction.

After the office is up and running with a sensible workflow for tickets (user requests and troubleshooting) you will move on to the biggest challenge for the organization. As a rule, this is either change management or problem solving. Organizations with "cowboy" system administrators who come up with smart ideas and implement them without much testing, often begin with change management. For organisations suffering recurring outages, problem solving comes first.

Whatever you choose to start with, a certain amount of configuration management will be necessary. Managing configuration is critical to delivering the software and services for the user. Software must work as expected. In order to make beneficial changes, one must know the configuration of the different programs.

To manage configuration changes you may use a database (Configuration Management Data Base (CMDB)). Few people use a database for all the configurations, and neither do you have to add all configurations to one single database. It's fine to place configurations into multiple smaller and partly independent repositories. Some people, for example, store configurations and setups in version control. But even if you have different repositories, you may get greater benefits if you connect information from the different processes.

For users of Debian Edu, most service configurations lie within a specific directory (/etc). These may benefit from being collected and stored in a central version controlled directory. This makes it easier to restore lost services and setup machines if they are reinstalled. This applies both to servers and user laptops or workstations. As part of the backup system in Debian Edu, a backup is made of the setup directory /etc. But the backup system is nothing more than a database or a version controlled directory for configurations.

Service Desk

The Service Desk is where users submit questions or errors. At school, the ICT-contact often forwards operational events to the Service Desk. There may also be requests like setting up a new PC, or installing a program.

At school the ICT contact is the link to the Service Desk. The ICT contact also responds to the most common questions. Some questions are too difficult to manage at each school and must be forwarded to the Service Desk. It is important to have good cooperation between the school ICT contact and Service Desk operators. Tasks that are too extensive or too difficult to solve locally should be passed to the Service Desk.

Users may also get direct answers from an operator at the Service Desk. All operational enquiries go to the Service Desk. Enquiries will be assigned a case number. Anyone who has registered a case will receive an e-mail confirming that the inquiry has been received. During consideration of the case, those working with it at the Service Desk may send updated status to the user.

Events can emerge over phone, fax, email or as a web form. Urgent events get priority. Incidents which must be resolved quickly, usually come by phone. Less important events may come via for example email. Operators in support must attend to the user's problem, and ask questions to find the most of the problem.

Events can get over the phone, fax, email or web form. Events that urgency is prioritized. Incidents must be resolved quickly get on telephone. Less important events coming via eg email. Characters in support must be put into the user's problem and ask questions to find most of the problem.

All inquiries should be logged, and also provide email confirmation for receiving a case. It is important that the user should feel safe, and to get good information about what might be the problem. When the inquiry comes to the Service Desk, log a brief description of the event or an inquiry. The inquiry may be from the ICT contact at the school or others who have an agreement to use the Service Desk. Logging should happen as soon as possible, and it will follow with a case number. Whoever with an inquiry, will get email copy that the matter has been received with appropriate reference number.

In earlier times, inquiries were written in paper logs. Today computer system is used to record the inquiries. In English, this is called "Request Tracker". It is crucial for the operation to log inquiries. This is basically for error handling, user requests, and prioritization of the various operating events. Log entries are important to prevent recurring errors. Because one periodically goes through operational events one also have an assessment if a fix is good, and if the priority of the tasks is proper. The log also provides a basis for improving the service by debugging problem services and applications based on what users perceive as problematic.

Thus the log of requests is a basic and necessary tool both for users and the Service Desk. There are several freely available systems for logging requests with good documentation <ref>RT Essentials: http://www.oreilly.com/catalog/rtessentials/chapter/index.html </ref>. Service provider Skolelinux Drift uses RT <ref>RT Essentials: http://www.oreilly.com/catalog/rtessentials/chapter/index.html </ref> to handle requests.

One important thing when starting up support is not to get a too tough start. Do not try to achieve everything at once. Bet rather on "quick wins" that keep the user informed, and short response times. It is also important to clarify who Service Desk should forward events to, if they can not figure out the inquiry themselves. The support must also be able to see if there are disruptions for the user. This makes it quick and easy to give feedback.

For the users it is important that incidents are handled. For the service office it is important that the incidents are handled correctly according to the service level agreement, and that work requested outside what is already agreed upon is handled between leaders at the school and the system administration organisation.

Tasks and roles

Vi anbefaler å avtale hva IKT-kontakten på skolen har i oppgaver og hva som er ansvaret for de som jobber på servicekontoret. Skolene har ofte små ressurser sammenlignet med hva som er vanlig i kommuneadministrasjonene eller private bedrifter. Samtidig har man vanligvis mange flere brukere og ofte flere klientmaskiner enn hva som er i bruk i resten av kommunen.

For å fordele arbeidsoppgaver må man ha på plass roller. Ved å ha klarlagte roller er det enklere å fordele oppgaver, og arbeidskapasiteten som er nødvendig for å løse driftsoppgavene på en god måte.Ut fra erfaringer i kommuner og profesjonelle driftsorganisasjoner viser det seg at følgende roller er vanlig.

Her følger en oversikt over de forskjellige arbeidsoppgavene som er vanlige, og som enkelte kommuner har kontraktfestet med de som gjør jobben.

IKT-kontakten(e)s arbeidsoppgaver på hver skole:

Driftsoperatørens arbeidsoppgaver:

IKT-koordinators oppgaver:

IT-ansvarliges arbeidsoppgaver (rektor, skoleleder, leder av driftstjenesten):

Fordelen med å avtalefeste disse arbeidsoppgavene er at man både vet hva som forventes av den enkelte, og at man har et godt grunnlag for å planlegge og styre IT-tjenestene. Vanligvis gjøres disse IT-oppgavene som kun en del av jobben til en lærer som også har undervisningsoppgaver.

I en bedrift ville man fort hatt to ansatte på full tid for å drifte 100 standard klientmaskiner med 100 brukere. I skolen har man kanskje en 30% stilling totalt fordelt på flere personer som drifter 100 klientmaskiner som brukes av 320 elever og lærere.

Når man i skolen har så få ressurser til driften så er det avgjørende å ha god styring på ressursene. Ved å avtalefeste oppgavene kan man enklere gjøre vurderinger knyttet til om man trenger ekstra ressurser, eller må redusere forventningene til IT-satsingen i skolen ut fra budsjettmessige hensyn. Ved å ha god oversikt over hva IT-oppgavene er vil skolens IT-ansvarlige enklere kunne be om økning i ressursene om dette er nødvendig. Det kan være behov for økte ressurser til gjennomføring av IKT-basert eksamen eller behov for nytt utstyr som digital tavle som hjelpemiddel i undervisningen.

Forventet tidsbruk

Vi har laget en tabell som viser tiden som brukes på drift og vedlikehold. Tabellen bygger på erfaringer fra kommuner som sentraldrifter Skolelinux på 9-10 skoler med 250-500 klientmaskiner. Det er flere ting som ikke er med i tabellen. Derfor må man sette opp ekstra tid til prosjekter hvor skolene utbygger ut IT-løsningene med nettverk og mer utstyr.

Rolle

Driftsansvar

Tidsbruk pr skole pr uke

Total tidsbruk alle skoler

Driftsoperatør sentralt

Overvåking, feilretting og drift av 500 maskiner på f.eks. 10 skoler med 3200 elever og lærere.

2-3 t(50 klienter)

½ stilling(500 klienter)

IKT-kontakt på hver skole

Oppsyn over utstyr, enkelt vedlikehold, og rapportering av hendelser og forespørsler

3-4 t(50 klienter)

1 stilling(10 skoler / 500 klienter)

IKT-koordinator sentralt

Bistå planlegging og gjennomføring av pedagogiske og tekniske IT-arbeidet i skolen.

1-2 t

½ stilling

IT-ansvarlig (rektor)

Gjøre felles innkjøp, og passe på at tjenestenivåavtalen overholdes. Planlegge oppdateringer, eller utbygning av løsningene

1 t

¼ stilling

Totalt for skole

50 klient-maskiner (samtidige brukere)

6 - 10 t

Totalt for alle skoler

10 skoler, 500 klient-maskiner (samtidige brukere)

2 ¼ stilling

Erfaringer viser at arbeidsomfanget til IKT-kontakten blir påvirket av antall samtidige brukere. Uttrykket «samtidige brukere» er nytt for mange. For å illustrere med et eksempel. En skole kan ha 250 elever men ikke mer enn 50 datamaskiner. Da er det maksimalt 50 elever som kan bruke datamaskiner på samme tid. Dette er mye mindre enn de tilsammen 250 brukerne som har konto på systemet. Det er disse 50 innloggede brukerne som gir arbeide for IT-tjenesten. De andre 200 personene som ikke er logget inn gir lite ekstra arbeide.

Derfor er det vanlige å beregne IT-kostnader ut fra maksimalt antall samtidige brukere. Andre beregningsmåter er også mulig, f.eks. når man betaler for produsenteid programvare. Men siden Skolelinux ikke har lisenskostnader, så er det antall samtidige brukere som er det mest avgjørende for driftskostnadene. Å regne driftskostnader ut fra brukerkonti gir liten eller ingen mening i skolen.

For brukere av Skolelinux er det nesten ingen kostnadsforskjell å forvalte 100 eller 250 brukerkonti. Det er et par unntak. Sannsynligvis er det flere elever som stadig glemmer passordet sitt med 250 elever sammenlignet med 100. Derfor er det lurt å la læreren med ansvar for klassen være den som gir elever som glemmer nytt passord.

Har skolen 50 klientmaskiner trenger IKT-kontakten mindre tid på sine driftsoppgaver enn om skolen har 150 klientmaskiner. Med flere klientmaskiner øker den samlede tiden som brukes på drift. Men driftstiden fordelt pr klientmaskin går noe ned.

Flere kommuner har satt av 3-4 timer i uka til IKT-kontaktens oppgaver på hver skole om det er installert 30-70 klientmaskiner. Utdanningsetaten i Oslo har satt av halvannen ukedag, eller 30% stilling til å følge opp 150 klientmaskiner. Erfaringer fra andre kommuner tyder på at en 20% stilling er nok for å løse arbeidsoppgavene til en lokal IKT-kontakt om skolen har 160 tynne eller halvtykke klienter med Skolelinux.

I tillegg kommer kostnadene med sentralisert drift, IT-ledelse, og oppføringen av den pedagogisk bruken av IT-verktøy i skolefagene. Sannsynligvis er det nok med en stilling til drift av 1000 klientmaskiner. Når det gjelder pedagogisk støtte er det flere rektorer som har en 50-100% stilling på skolen til dette arbeidet. Det kan være en 10-20% stilling som IKT-kontakt og en 40-80% stilling som pedagogisk støtte for læreren. Mange lærere oppfatter IT-verktøy i skolen som noe nytt. En del rektorer ønsker å satse ekstra på den pedagogiske siden ved å gjøre lærerne trygge på bruk av IT-verktøy i skolefagene.

Sjekkliste

Vi har satt opp en huskeliste over oppgaver som må løses om man skal få på plass et ordentlig servicekontor.

Hendelseshåndtering (Incident Management)

Hensikten med IT-tjenesten er å hindre forstyrrelser som driftsstans eller redusert kvalitet ved bruk av dataprogrammene. Brukerne vil oppleve få problemer med IT-systemet om IT-tjenesten har nok ressurser til drift, utstyr og henvendelser til servicekontoret. Allikevel skjer små eller store feil som gir forstyrrelser for brukerne. Da trenger man god håndtering av hendelser.

I fallskjermmiljøet kaller man nestenulykker for «hendelser». Det er kanskje ikke helt det samme i datadrift når noe ikke virker. Hensikten med å håndtere hendelser er og gjenopprette tjenesten så raskt som mulig slik at alt virker på vanlig måte. Går noe galt skal dette ha minst mulig å si for brukerne. Hva som er en normal tjeneste er avtalt gjennom en driftsavtale som beskriver tjenestenivå.

Statistikk over hendelser er viktig. Spesielt om flere jobber med driften. Når flere jobber sammen mister man fort oversikten over alle sakene. Statistikk vil kunne påvise problemområder som må håndteres mer grundig enn en rask løsning fra servicekontoret. F.eks. kan det være mange henvendelser om å bytte passord til elever som har glemt dette. Da kan det være lurt å la læreren til klassen bytte elevens passord.

En driftsforstyrrelse er definert som:

Eksempler på driftforstyrrelser kan være:

Eksemplene viser noen av de vanligste driftsforstyrrelsene. Dette er problemer som gjør at brukere henvender seg til IKT-kontakten på skolen eller servicekontoret. IT-tjenesten må prioritere hva som skal behandles med en gang, og hvilke problemer som trenger mer tid for å løses. For å prioritere hvilke problemer som trenger mer omfattende feilretting er det viktig å logge alle henvendelser om driftsforstyrrelser. Når man har oversikt over hvilke driftsforstyrrelser det er mest av, kan man sette inn tiltak på de områdene der det er mest problemer.

Sjekkliste

Vi har laget en kort huskeliste for å sikre at man har på plass rutiner og systemer for god hendelseshåndtering

Planlegging og implementasjon

Å sette opp et brukbart system for logging av hendelser krever er noe mer enn å installere systemet. Alle i driftsavdelingen må bruke systemet. De som melder feil må også få tilbakemelding på e-post med saksnummer. Slike ting krever betydelig med konfigurering av systemet for hendelseslogging. I tillegg må man sørge for enkel brukeropplæring av de som tar imot henvendelsene.

Man trenger ikke store og omfattende planer for å få på plass skikkelig hendelseshåndtering. Å håndtere hendelser er en helt standard oppgave for de som jobber på servicekontoret og IT-kontaktene på hver skole. Å sette opp et dataverktøy for logging av hendelser krever fort en par uker slik at det er konfigurert riktig, og brukere også kan rapportere hendelser via e-post i tillegg til telefon.

Selve brukergrensesnittet til loggsystemet er relativt selvforklarende. Så det tar ikke mange timene å ta i bruk. I løpet av den daglige bruken av systemet vil man bli mer og mer komfortabel med hva som bør stå i meldingene som logges. Det er avgjørende at alle i driftsavdelingen bruker systemet for logging av driftsmeldinger.

Aktiviteter ved driftsforstyrrelser

For å få en idé om hvilke aktiviteter som gjøres ved en melding av en hendelse, bruker vi et eksempel.

En bruker kontakter servicekontoret med et problem. Utskriften virker ikke, er meldingen fra brukeren på telefon. Driftsoperatør logger hendelsen rett etter samtalen er avsluttet. Problemet med utskriften blir en sak med et saksnummer (som gis automatisk).

Driftsoperatør på servicekontoret gjør en rask analyse. Er det utskriftskøen som har stoppet igjen, eller er det noe annet? Det kan hende det mangler papir eller toner? Ved å undersøke utskriftskøen ser driftsoperatøren at den er fylt opp. Hun sletter køen, og ser om neste utskrift blir skrevet ut.

Denne gangen fylte skriverkøen seg opp igjen. Driftsoperatør kontakter skolens IT-kontakt, og ber om å sjekk om papir er på plass. Dette noteres i hendelsesloggen. IT-kontakten melder tilbake at papir er fylt på, og at utskriften går som normalt. Saken er avsluttet noe som også noteres i systemet for hendelseslogging.

Om skriveren ikke hadde startet igjen kunne det vært toner som manglet, eller at skriveren hadde en feil. Var det en feil måtte driftsoperatør skalert problemet. Med skalering menes at andre enn driftsoperatør og IKT-kontakten løser problemet. I dette eksemplet måtte man fått hjelp av en servicetekniker som kan fikse skrivere.

Dette eksemplet viser at det settes igang et helt apparat for å få igang en skriver som har stanset opp. Virker ikke skriveren selv om man har lagt inn mer papir i en i en tom skriver, så må man først undersøke om det er toner som mangler. Om alt ser ut til å være på plass, men ting fortsatt ikke virker, må man skalere problemet. Driftsavdelingen kaller inn en ekspert på et bestemt område for å fikse feilen. Denne gangen var det en servicetekniker for skrivere.

Hva som var feilårsak og den reparasjonen som ble gjort noteres i systemet for hendelseslogging.

Roller

Det er en rekke roller involvert når IT-tjenesten behandler meldinger om at noe ikke virker. I eksemplet over samarbeider skolens IT-kontakt og driftsoperatøren om å løse problemet med utskrift. Hadde problemet vært større måtte man ha innkalt en servicetekniker. Får man ikke fikset skriveren å må kjøpe ny. Må skolen skaffe ny skriver kan det hende man må involvere IT-ansvarlige for å få penger. Mange steder er det rektor som har siste ordet.

Kort sagt blir det fort mange som blir involvert når noe ikke virker. Man skal i utgangspunktet løse problemer der og da. Da unngår man å involvere mange som ikke kan bidra til å løse problemet. Skalerer man problemer som kan løses lokalt så blir det fort mer kostbart. Også fordi mange henvendelser bør være enkelt å håndtere der og da. Andre henvendelser dreier seg om mer sammensatte problemer. Da må man involvere flere personer. Er man avhengig av ekstra eller ekstern hjelp for å løse problemet så må dette som hovedregel avklares med driftsleder. Det viktige er å være bevisst ved håndtering av driftshendelser, og bruke ressursene på en god måte.

Nøkkelpunkter

Vi har satt opp en del nøkkelpunkter ved håndtering av hendelser. Punktene skal være til hjelp for å vurdere om man gjør en god jobb ut fra målbare og vel definerte krav. Slike målepunkter er:

Verktøy

Det er en rekke verktøy som kan gjøre det enklere å håndtere driftsforstyrrelser.

Problemhåndtering (Problem Management)

Problemhåndtering er en «undersøkende» prosess. Kjente feil blir oftest håndtert direkte av servicekontoret. Dette er den mest vanlige formen for hendelseshåndtering. Ved ukjente feil må man undersøke nærmere hva som er galt. Denne form for feilsøking krever både sunn fornuft og teft. Gode driftsfolk bruker teften til å gå rett til problemet, finner løsningen, og gjenopprette tjenesten så raskt som mulig slik at alt virker på vanlig måte.

Problemhåndtering er;

Problem kontroll

Feil kontroll

Proaktiv kontroll

Prosedyrer for problemhåndtering

Vi har lagt ved en omfattende samling av problemløsninger og oppskrifter for konfigurering. I løpet av sommeren 2006 vil dette også være lagt ut på Internett. Vedlikeholdet av oppskriftene vil skje av profesjonelle driftsoperatører på skoler, kommunale IT-tjenester og private driftsoperatører. For å gjøre det enkelt å gjøre forbedringer i dokumentasjonen er det hele lagt ut i en wiki som ligger på en Skolelinux-tjener.

Wiki-teknologien har vist seg å være en stor suksess for å vedlikeholde katalogisert informasjon på Internett. Det er enkelt å bidra og alle endringer loggføres. Det er også mulig å importere OpenOffice.org dokumenter, og eksportere oppskrifter som pdf.

Konfigurasjonsstyring (Configuration Management)

Ressursene som brukes på IT-systemene i skolen må håndteres på en økonomisk forsvarlig måte. Da må man ha styring på tjenestene som brukes og utstyret eller infrastrukturen som det ofte kalles. Utstyret, programvaren og tjenestene har en hel rekke med innstillinger. Dette er konfigurasjoner, eller en logisk modell av hvordan infrastruktur og tjenester er satt opp.

For å kunne styre konfigurasjonene må de kunne identifiseres, lagres og vedlikeholdes. Man må også kunne holde orden på forskjellige utgaver av konfigurasjonene. Vi kaller hver del av et oppsett for en «konfigurasjonsdel» (eng.: Configuration Item CI). En konfigurasjonsfil kan f.eks. sørger for at bestemte brukere får adgang til noen få skrivere i datanettet. En annen kan sørge for at man får mellomlager på halvtykke klienter.

En oppdatert database for konfigurasjonsstyring er avgjørende for å sikre rask og kontrollert behandling av driftsforstyrrelser, eller ønske om endringer i oppsettet av maskiner, programmer eller tjenester.

Planlegging

Det krever planlegging for å få på plass en database for konfigurasjons styring. Man må bestemme seg for områdene systemet skal brukes, målsetningen, politikken og prosessene for lagring og vedlikehold av konfigurasjonene.

Som vi ser må man planlegge en hel del om man vil ha en god forvaltning av konfigurasjonene til IT-systemet. Hensikten ved å planlegge dette som en del av IT-driften er å sikre at systemer som går ned raskt kan komme på lufta. Har man god orden på konfigurasjonene er det lett å bytte ut en defekt maskin, og erstatte denne med en ny. Konfigurasjonene kan raskt overføres til den nye maskinen, og IT-systemet oppleves som like godt som før det gikk galt med den gamle maskinen.

Styring av delekonfigurasjonene

A configuration item is a part of the infrastructure. It is normally the configuration of a service or a program. Some times users want to change how a service work. One need to keep track of the configurations if changes are made.

For å få dette ned på jorda så kan vi tenke oss konfigurasjonen til utskriftstjeneren. Man ønsker å legge til en ny skriver i datanettet, og vil legger til denne i utskriftssystemet CUPS. Da endrer man i konfigurasjonen gjennom en nett-applikasjon eller via oppsettet i KDE. Konfig-fila til CUPS vil endres, og man må starte utskriftstjeneren på nytt. Dette kan gjøres i KDE-verktøyet eller via nett-applikasjonen. Den endrede oppsettfilen kopieres til en filkatalog der fila kan håndteres av et versjonsystem.

Of many different choices there are a few common ones. This is if a service should: run, stop, terminate, start, be interrupted or taken out.

Man bør være varsom med å endre konfigurasjonene uten en skikkelig plan. Det er lett å glemme hva man har gjort på en tjenermaskin eller en PC. Derfor er det viktig med dokumentasjon av endringene som er gjort i en endringslogg.

Planlegging og installasjon

Konfigurasjonen av datanettet henger sammen med arkitekturen. Mye av planleggingen er gjort med Skolelinux. Dette skyldes at det fort tar både 3 og 4 uker å sette opp tjenermaskiner med tilsvarende tjenestenivå med Windows server eller RedHat og andre GNU/Linux-distribusjoner. Med Skolelinux tar dette 1-2 timer. Skal man ha fast IP-adresse på nettverket bruker en fagperson ½ time ekstra på dette. Det skyldes at nett-tjenestene er satt opp med gjenbrukbare navn.

Det som da må planlegges er hvilke ekstra brukerprogram som skal opp, og hvilke delsystemer som skal samvirke med Skolelinux. Det kan f.eks. være at skolen har elektronisk tusjtavle (eng. Whiteboard).

Check list

Vi har laget en liste med aktiviteter og løsninger som må på plass skal man ha god styring på konfigurasjoner.

Relasjoner til andre prosesser

Styring av konfigurasjoner henger nøye sammen med håndtering av problemer og om systemene er tilgjengelige. Opplever man stadig vekk at utskriften stopper, så kan det hende det hende en endring av konfigurasjonen løser problemet. Det kan f.eks. være å få på plass en rutine for sletting av utskriftskøen og starte utskriftstjenesten på ny.

Målsetningen med endringene man gjør i konfigurasjonene er som regel å øke tilgjengeligheten til tjenester eller programmer. Det kan også være for å begrense tilgangen til enkelte programmer eller tjenester til bestemte tidspunkt. For å få dette til må man endre oppsettet til tjenesten. I tillegg kan det koste penger ut over det som er avtalt om tjenestenivå, eller kapasiteten til systemet.

Eksemplene viser at håndtering av konfigurasjoner griper inn i en rekke andre områder. Derfor er det mye å tjene på å få på plass gode arbeidsrutiner for håndtering av endringene som gjøres i konfigurasjonene. Også automatisering er lurt om man ønsker økt stabilitet, eller tilgang til bestemte tjenester i bestemte perioder.

Tools for configuration management

Som nevnt under huskelisten kan man bruke:

Change Management

Mange IT-tjenester er lite flinke til å håndtere endringer i IT-systemene. Det fører til mange misfornøyde brukere. Undersøkelser i offentlig sektor i Danmark viser at driftskostnadene går ned når man har god styring på endringene. Derfor lønner det seg å involvere brukerne med opplæring og medvirkning knyttet til endringene som gjøres.

Det er helt avhengig av skikkelige prosesser ved endringsmeldinger. Dette gjelder uavhengig om endringene er små eller store. Derfor er det viktig å ha på plass riktige personer når man gjør endringer slik at det både er gitt opplæring og det er folk til å svare på spørsmål. Dette blir spesielt viktig når man tar i bruk nye utgivelser av programvare og tjenester. Det har ingen ting med om man bruker fri eller produsenteid programvare.

Endringsledelsen skal sørge for at alle endringer gjøres på en standardisert og riktig måte. Det er viktig å få til beslutning om endring på riktig nivå i organisasjonen, Standard endringer kan ofte være forhåndsgodkjente når de er gjort et par ganger. Men større endringer vil ofte involvere et høyre beslutningsnivå mellom skoleledelsen og driftsoperatør.

Grunnen til at ledelsen skal være med er at endringer i systemet er at en oppgradering ofte vil kreve opplæring av brukerne. Det kan være oppgradering til ny nettleser eller ny utgave av kontorprogrammet. Dette kan fort føre med seg en halv dags opplæring i hva som er nytt i et program. Slike endringer må derfor avklares med ledelsen. Endringene må også gjøres uten at det andre deler av systemet slutter å fungere.

De med ansvar for å godkjenne endringer mottar en mottar en såkalt endringsmelding eller RFC (Request For Change) som er den engelske forkortelsen. Når man har en endringsmelding kan man vurdere om endringen skal utføres. Mange ganger må man avklare med ledelsen om eventuelle endringer skal gjøres, og eventuelt når det skal skje.

Ved endringer må man også samarbeide med skolens IKT-ansvarlig. Man må sørge for at endringene skjer når det passer med skolenes planer. Å gjennomføre betydelige endringer uten endringsledelse kan føre til mye misnøye og ekstra henvendelser til servicekontoret. Da får man betydelig ekstraarbeid uten at dette er planlagt. I tillegg kan det føre til en endring som ville fort må rulles tilbake. Man får fort dobbelt så mye arbeide uten å havne noe annet sted enn tilbake til start. Hadde man sørget for de nødvendige godkjenninger ville endringen kunne gjøres på en planlagt og grei måte.

Endringsledelse gjøres for å unngå mer ekstra arbeide enn hva som er nødvendig. Å gjøre endringer krever selvsagt mer arbeide, men man vil få mindre ekstra arbeide om endringene planlegges. Man unngår også at man må rulle tilbake endringer fordi det oppstår problemer der brukerne ikke er forberedt på betydelig omlegging.

Når man f.eks. oppdaterer hele systemet til ny versjon må man passe på at alle er orientert. Man må undersøke om de som berøres av endringen trenger opplæring. De rette fagpersonene må forberede det hele slik at det ikke oppstår overraskelser.

Men må unngå at alt ansvar havner hos den som står for styring av versjonene av programvaren. Det er den som har ansvaret for håndtering av utgivelser (release manager). Utgivelseshåndteringen er en prosess som fortrinnsvis skal arbeide med endringer som inneholder mange mindre endringer. Dette skjer som regel ved utrulling av nye systemer og tjenester, eller ved oppgradering av hele systemet til ny versjon.

Aktiviteter

Selv hva som kan se ut som en liten ubetydelig endringsmelding kan få omfattende konsekvenser om endringen gjøres. Vi har eksempler på skoler som har et stabilt Skolelinux-nett der alle programmene virker. Så installeres en testutgave av et populært program som kræsjer hele tiden. Skolelinux får skylda.

Et eksempel er skoler som har installert testversjonen av nyeste OpenOffice.org før programmet var endelig ferdig. Flere syntes at det kunne være gøy og prøve ut. Problemet er at testutgaver som regel er utgitt for å finne feil og ustabilitet i programmer. De er ikke ment for bruk i produksjon.

Hovedregel er at man ikke installerer testutgaver av programvare i produksjon. De fleste driftsoperatører anbefaler å bruke nest siste versjon av et program beregnet på produksjon. Etter 6-12 måneder er som regel de verste feilene plukket av en ny hovedutgave av et program.

Det betyr at man gjerne venter til sommeren før man oppdaterer til et program som kom i ny utgave rett før nyttår. Dette passer bra med skoleåret. Alternativet kan være ustabilitet og irriterte brukere. Derfor har rådgivningsgruppa en sentral rolle når det gjøres små eller store endringer.

Utgivelsesledelse (Release Management)

Utgivelseshåndteringen er administrasjon og planleggingsaktiviteter for å klargjøre for ønskede endringer. Endringene kan være små eller store der store endringer kan bestå av mange mindre delendringer. Utgivelseshåndringingen skjer før man setter igang selve jobben med å installere program- og maskinvare i produksjon.

Først gjennomføres planlegging og testing av nye utgivelser. Deretter så rulles det hele ut i produksjon. Utrulling er en del av infrastrukturledelse. Prosedyren er å gjennomføre det som er planlagt, testet, og ligger klar i systemene for konfigurasjonsstyring. Når alt er planlagt, testet og konfigurasjonene er lagret, så ruller man ut løsningen i drift.

Som regel er mange tjenestetilbydere og leverandører involvert. Det gjelder både i forbindelse med anskaffelse av maskiner, den programvaren som brukes, og de konfigurasjonene som er anbefalt. God ressursplanlegging er grunnleggende for å kunne pakke og distribuere en ny utgivelse på en bra måte for brukerne. Slurver man på dette området kan man ende opp med at utstyret ikke virker, eller blir stående ubrukt fordi det er mangler ved installasjonen.

Utgivelsesledelsen tar et helhetlig grep ved endring i en tjeneste, og skal sikre at alle deler av en utgivelse ses i sammenheng. Det gjelder både for tekniske og ikke-tekniske forhold.

Grunnleggende

Som man ser er utgivelseshåndtering helt grunnleggende for at datamaskiner, programvare og nettverket virker som planlagt. Skikkelig håndtering av utgivelser gjøres for å hindre driftsforstyrrelser. Ved nye utgivelser eller endringer er det forventet at driften skal gå som normalt uten avbrudd eller reduksjon i kvaliteten.

Håndtering av endringer eller nye utgivelser kan sammenlignes med å bygge ny vei. Bilene må fortsatt komme fram selv om man bygger ny vei oppå den gamle. God skilting må være på plass. Man må også ha de nødvendige ressurser til å legge om veien. Mangler man ressurser til å gjøre endringene så er det like greit å la vær.

For noen kan det være kjedelig med skikkelig utgivelseshåndtering. Man får ikke brukt det nyeste nye hver gang det kommer noe nytt. Men som oftest er det ikke satt av ekstra tid i driftsavdelingen for å håndtere en flom av klager når helt ny programvare svikter. Linux-eksperten David Elboth slår fast at høye oppetider krever etablert teknologi. I LINUXmagasinet (1/2004) skriver han:

Vil man ha lite klager med stabilt og driftssikkert miljø krever dette solid utgivelseshåndtering. Alternativt er en haug med klager og misfornøyde brukere man har installert siste skrik av programvaren som ikke er godt nok testet. Personer med «gutteromskompetanse» har en lei tendens til å undervurdere konsekvenser ved oppgradering av programvare. At noe går fint på hjemmedatamaskinen betyr ikke at dette vil fungere i et stort datanett med 500 klientmaskiner og 3200 brukere.

Sentralt programarkiv (DSL)

Programarkivet i driftssammenheng er en samling av originalutgaven av den programversjonen av programvaren som er i produksjon. Bruker man Skolelinux 2.0 er det dette som er programarkivet. I dataverdenen brukes ordet programarkiv i flere sammenheng, spesielt når man programmerer. Når det gjelder drift snakker vi den originale sammensatte programvare av en bestemt versjon som er utgangspunktet for installasjonen.

Bruker man fri programvare kan programarkivet være Skolelinux 2.0 pluss de ekstra programmene man har lagt inn i tillegg fra forskjellige kilder. Det kan være bestemte versjoner av Macromedia Flash, Java og decodere som gjør det mulig å kjøre nasjonale prøver i nettleseren, eller se sendinger fra NRK.

Har man planlagt og oppgradere til neste versjon av Skolelinux når den har kommet, vil det være den nye versjonen som blir hoved programarkiv. Også her vil alle ekstra programmer ut over ny Skolelinux være en del av arkivet.

Oppsettfiler som er justert eller laget lokalt av driftsavdelingen er følger ikke med som en del av hovedarkivet for programmer. Konfigurasjoner lagres i en egen versjonshåndtert katalog eller database.

Database for konfigurasjoner og maskinvare

Som nevnt under kapitlet med konfigurasjonsstyring må man opprette en database eller en versjonshåndtert katalog for å ta vare på oppsettfiler. Man må også ha oversikt over alle datamaskiner, hva slags maskiner det er snakk om, ytelse, og unike standardadresser på nettverkskortene (MAC adresser).

Det er mange grunner til å ha oversikt over utstyret. En av hovedgrunnene er å ha oversikt over hvor mange maskiner som er i drift, antall maskiner som ikke er i bruk, og antall maskiner på reparasjon. En annen grunn går på planlegging ved oppgraderinger. Det går både på hvor mye

Bygg-håndtering

I skolen installeres en rekke program i tillegg til nettleser og kontorprogram. Det trengs pedagogiske program for læring, tilleggsprogram i nettleseren, og det trengs program for multimedia. Systemene har også nettverksoppsett og endrede innstillinger i bestemte programmer. Har man mange tjenermaskiner og kanskje tusenvis av klienter ser man raskt at det er behov for effektive verktøy for utrulling. Slike verktøy er standard i Skolelinux.

Bygg-håndtering handler om å få installert de ønskede programpakkene, tjenestene og riktig innstillinger både av enkelte program og datanettverket. Mange har hørt om å bygge såkalte «images». Man installerer operativsystem og alle de programmene man trenger. Stiller inn nettverket. Deretter bruker man et image-program for å lage en kopi av det som er installert på harddisken. Dette kopieres så ut til de andre datamaskinene.

Det er slett ikke nødvendig å bygge såkalte «images» eller diskbilder man kan kalle det på norsk. Skolelinux bygger på Debian som har et utmerket pakkesystem. Man trenger på ingen måte å kompilere programmer da dette er ferdig satt sammen, og kan installeres rett fra Internett. Det man må ha orden på er ønskede endringer i standardoppsettet til Skolelinux eller hoved programarkivet som er i bruk. Deretter lager man et eller flere skript som kan kjøre på de forskjellige maskinene for å få alt installert og satt opp.

For de fleste situasjoner er skripting en enkel måte å «bygge» og rulle ut programmer og oppsett. Men det er situasjoner der bygging av diskbilder kan være løsningen. F.eks. ved installasjon på mange bærbare datamaskiner.

Som vi ser handler håndtering av bygg-prosessen om å tilrettelegge for utrulling på mange datamaskiner. Helt unntaksvis handler det om å bygge en skreddersydd Debian-pakke. Men i de aller fleste situasjoner er alt pakket ferdig. Da må man få på plass et skript for som installerer ekstra programmer og bestemte innstillinger. Man kan også lage diskbilder om man har mange like maskiner, som f.eks. bærbar PC til alle elevene.

Testing

Det er helt avgjørende å teste nye programmer, konfigurasjoner, og nye tjenester før de settes i produksjon. Flere skoler har erfart ustabilitet fordi de har installerer programvare uten å gjøre de nødvendige justeringene. Derfor er det helt avgjørende å teste endringer i konfigurasjoner eller ny versjon av programvaren før endringen gjøres på alle maskinene.

Testing skjer gjerne i tre steg.

Reserveløsning

Mye kan gå galt under en ny installasjon eller oppgradering. Derfor må man ha klar en reserveløsning. Det betyr at man på kort tid kan ta i bruk systemet slik det var før oppgraderingen. På fagspråket heter dette tilbakerulling.

Når man skal rulle tilbake er det helt avgjørende å ha klar forrige versjon av arkivet for programvare og oppsettfiler. Det betyr at man kan installere f.eks. Skolelinux 1.0 på under en time, og legge på plass aktuelle konfigurasjonsfiler.

Men tilbakerulling tar tid. Derfor kan det være greit å ha en tjenermaskin klar med forrige utgave av programvaren, de riktige konfigurasjonene, og hjemmekatalogene til brukerne. Denne tjeneren kan raskt erstatte maskinene som ble oppgradert, men ikke virket etter planen. Ved å ha tjenermaskin(er) i reserve kan man sørge for høy tilgjengelighet selv om noe skulle gå galt.

Fordeler og mulige problemer

Fordelen med å ha arkiv over programvaren som er i produksjon kan ikke undervurderes. Mange satser på å ha programvaren på sine respektive CD-er og enkelte DVD-er. Dette gir lite effektiv distribusjon. For å spare tid og bryderi er all programvaren i Skolelinux tilgjengelig på Internett.

Driftsavdelingen kan lage kopi av Skolelinux-arkivet på en sentral tjenermaskin. Herfra kan all programvaren raskt og greit installeres på de andre maskinene. Fordelen med dette er at IT-tjenesten hele tiden har oversikt over hvilke versjoner av programvaren som de har gjort tilgjengelig for skolene. Man hindrer også installasjon av programvare som ikke har vært vurdert av styringsgruppa for endringer.

Det kan oppstå betydelig problemer om man ikke vedlikeholder programarkivet og konfigurasjoner. Det kan også være at man gjør feil med en konfigurasjonsfil eller programpakke. Da rulles dette ut til alle maskinene. I tillegg kan enkelte skoler installere lite testet programvare eller beta-program som de setter i produksjon. Så man må ha gode prosesser og ha noen å holde ansvarlige for vedlikehold av programarkivet og konfigurasjonene.

Det kan virke som man må ha på plass mye ekstra for å installere og vedlikeholde tjenesten og programvaren som er i bruk. Velger man vekk de verktøyene som gir styring med oppgraderingene gir man seg selv mye ekstra arbeide. IT-tjenesten må bruke masse tid på manuelt arbeide med installasjon på hver enkelt maskin. Faren for å gjøre feil øker. Når ting ikke virker får man misfornøyde brukere, og mye tid går med til feilretting.

Mange som drifter store IT-systemer har mangelfulle planer for endringer. Noen har ikke planer i det hele tatt, men bare installerer nye utgaver av programvaren. Endringene som gjøres kan oppleves som problematiske for en del brukere fordi funksjoner de er komfortable med endrer plass i brukergrensesnittet. På driftssiden kan det gå fullstendig galt. F.eks. skulle de oppgradere til fra eldre utgave av Windows til nyere i Arendal Kommune. Det meste sluttet å virke. IT-tjenesten sa de hadde flere dataprogram som var holdt sammen med «ståltråd og tape». Det tok de et halvt år å rydde opp.

Planlegging og implementasjon

Årsaken til at man planlegger før man gjennomfører endringer er for å hindre uker eller ekstra måneder med problemer. Selv om man skulle bruke noe ekstra tid på planlegging, så tjenes dette raskt inn fordi man unngår ekstra problemer. Det vil alltid være personer som forteller at de ikke har hatt problemer med ad-hoc-endringer i systemene. Men når man undersøker nærmere viser det seg at det er problemer etter endringer, og at henvendelser om dette ikke formidlet videre.

I våre øyne er ad-hoc-løsninger kun en omvei ved endringer, og kun en nødløsning. En ad-hoc løsning kan sammenlignes med en midlertidig reparasjon med «ståltråd og tape». Man må på sikt rydde opp i slike løsninger når man vil ha stabil drift uten stadige overraskelser. Ved å hoppe over en planleggingsfase vil man få mange flere ad-hoc-løsninger, og flere driftsproblemer ved endringer eller oppgraderinger. Derfor er det helt avgjørende at fagfolk og ledelsen forstår verdien av en god planprosess. endringer.

Derfor anbefaler vi at man innkaller til planmøte, og lager en stegvis plan ved endringer av systemet. En stegvis plan vil selvsagt variere i forhold til hva som skal endres. Det å oppgradere kontorprogrammet OpenOffice.org er noe annet enn å oppgradere hele systemet. Ved oppgradering til nytt kontorprogram holder det kanskje med en 2-3 timers gjennomgang av kontorpakken for læreren på hver skole. Når man skal oppgradere hele systemet må man både sørge for brukeropplæring og at det tekniske fungerer etter forutsetningene.

Hovedpoenget er at det er få snarveier når det kommer til planlegging og implementasjon. Undersøkelser viser at de som planlegger skikkelig og sørger for at folk har riktig kompetanse har lavere driftskostnader knyttet til driften.

Aktiviteter

Det er helt avgjørende å planlegge nye utgivelser. De fleste endringer av systemet skal avklares med ledelsen. Følgende liste over aktiviteter er laget som støtte ved oppgraderinger i en plan- og gjennomføringsfase.

Oppgaver

Detaljer

Prioritering av utgivelsen:

Sjekk om nødvendige beslutninger er gjort før en endring eller oppgradering skal rulles ut.

Sentralt programarkiv

Sørg for at de aktuelle programpakker som ønskes installert er på plass i det sentrale programarkivet.

Konfigurasjonsdatabase

Sørg for å ha på plass alle oppsettfiler. Det gjelder både de som er i bruk, og de nye som følger med systemene som endres eller oppdateres.

Bygg-håndtering

Alle skript og systemer som brukes til utrulling eller å lage diskbiler (images) må på plass.

Testing

Kjør først utprøving på testutstyr. Når dette fungerer uten problemer så kan det prøves ut med en skole. Skolen må være fullt orientert om, og med på at de skal prøve ut ny programvare. Når man er sikker på at alt virker kan man oppgradere hos alle.

Reserveløsning

Selv med omfattende testing kan nye utgivelser gå galt. Derfor er det avgjørende å ha en reserveløsning. Den enkleste reserveløsningen er å ha den gamle installasjonen med data på en egen tjenermaskin. En slik maskin kan plugges inn om endringen eller oppgraderingen ikke virker.

Verktøy

Som man ser av aktivitetslisten trenger man flere verktøy for å holde orden på forskjellige utgivelser av programvaren, tjenester og maskinvare i systemet. Noen av disse verktøyene er nevnt tidligere. Men vi gjentar dette allikevel:

Relasjoner til andre prosesser

Utgivelsesledelse griper rett inn i kjernen til IT-tjenesten. Det går på å gjennomføre ønskede sikkerhetsoppdateringer, endringer i tjenester, eller og oppgradering av dataprogram. Forespørsler om nye utgivelser kan skyldes driftsproblemer eller ønske om ny programvare. Før en ny utgivelse så er det gjort en vurdering om endringen er ønskelig.

Om endringen er grei så vil man gjøre nødvendige endringer i konfigurasjoner og klargjøre programpakker for utrulling. Dette vil være testet, og man vil ha på plass reserveløsninger. Når endringene er utført vil man kanskje måtte legge om deler av driftsaktiviteten. Så det er enkelt å se at endringshåndtering påvirker alle deler av driftsstøtten.

Verktøy for driftsstøtte

Det første man skal spørre seg selv om: «trenger vil virkelig programvareverktøy?» Trenger man verktøy så er det avgjørende å undersøke alternativene grundig.

Tar man en glanset brosjyre, og lytter til salgsprat, så er man helt avhengig av slike verktøy. Men gode folk, gode prosessbeskrivelser, og gode prosedyrer og arbeidsbeskrivelser er et grunnlag for god tjenestestyring. Behovet for, og hvor kompliserte verktøyene er, er avhengig av virksomhetens behov for datasystemer, og størrelsen på organisasjonen.

I en liten organisasjon vil en enkel fritt tilgjengelig database være nok for logging og styring på hendelser (request tracker). Men i større organisasjoner vil man ganske sikkert ha behov for et sofistikert distribuert og integrerte verktøy for tjenestestyring. Det betyr at man linker alle prosesser til et system for hendelseshåndtering.

Selv om verktøy kan være viktig, så er ikke disse viktige i seg selv. Det er de oppgaver og prosesser som må gjøres, og informasjonen som det er behov for som er utgangspunktet. Dette vil gi nødvendig informasjon til en spesifisering for hvilke verktøy som passer best til å støtte driften. Her er noen grunner til hvorfor man kan bruke programvare til driftsstøtte og tjenestehåndtering:

Automatiske verktøy tillater:

Type verktøy

I dette kapitlet har vi forestått en rekke verktøy for å forbedre driftsstøtten. Her følger en oppsummering av verktøyene:

Etter som driftsavdelingen får mer erfaring med systematisk drift vil det lages, eller skaffes flere typer verktøy.

Evalueringskriterier ved valg av verktøy

Selv om det er brukt store beløp på å lage evalueringskriterier for programvare, så finnes ikke annet enn erfaringsbaserte retningslinjer. Det er ingen endelige svar på hva som er god eller mindre god programvare. Som med mye annet dreier en del seg om smak og behag. Flere løsninger gjøre samme jobben like godt, men kan ha ganske forskjellig utforming. Men det er noen tommelfingerregler som kan være nyttige å ta med seg.

Det viktigste evalueringskriteriet er om man har behov for å gjøre en jobb i det hele tatt. Mange IT-verktøy er helt perfekt og løser sine oppgaver uten feil, men det løser oppgaver ingen trenger å ha løst. Så det viktigste kriteriet er om man løser riktig problem, og om det i det hele tatt er nødvendig å gjøre noe som helst.

Om det viser seg at man vil ha løst en oppgave, kan det vise seg at løsningen er så enkel at det er like greit å kjøre noen kommandoer for hånd. Det enkleste er gjerne det beste. Men når man får mange maskiner å drifte blir automatisering helt avgjørende. Det blir for mye jobb å logge seg inn på 20 likeartede tjenermaskiner for å gjøre en sikkerhetsoppgradering. Da er automatisering tingen.

Det er ofte et stort utvalg av programmer og fremgangsmåter for å løse et bestemt oppgave. Men en del problemer løses helt annerledes når man vedlikeholder 500 datamaskiner og 11 tjenermaskiner enn når man fikser hjemme-PC-en. Et eksempel kan være verktøy for at læreren kan se skrivebordet til hver enkelt elev på sin klientmaskin. Læreren kan stoppe og starte programmer hos alle elevene, og hindre enkeltelever å bruke f.eks. lynmeldinger når dette forstyrrer skolearbeide.

Når det gjelder valg av driftsverktøy handler det om automatisering og forenkling av driftsoppgaver. Det er om å gjøre og få redusert manuelt arbeide til et minimum. Så motivasjonen er å kun vedlikeholde automatikken. Også her går det på å gjøre ting enkelt, noe som kan være en betydelig jobb å få til.

Som man ser er det slett ikke enkelt å sette opp gode kriterier for valg av driftsverktøy for store installasjoner. Mest av alt kan dette skyldes at utviklere av programvare ofte mangler erfaring fra drift av IT-systemer. De er kun kjent med å lage nye ting, og det å lage gode og relevante verktøy for drift krever mange års erfaring.

En del generelle driftsverktøy som ikke har vært byttet ut de siste 20 årene. Men de produktene som brukes kan være byttet ut. Også noen programmer kan om få år være uaktuelle å bruke. Derfor må man belage seg på trening i nye utgaver av programmene som brukes til drift, eller ved oppgradering og endringer i brukerprogram.

Produkttrening

Grundig brukeropplæring gjør at mye av brukerstøtten kan ivaretas uformelt i direkte samtale mellom brukere. Ofte er opplæringskostnadene så lite som 1% av de totale driftskostnader. Det er vel verdt å bruke litt mer til opplæring. Effekten er svært positiv. Det samme gjelder riktig opplæring for IT-kontaktene på skolene, og driftsoperatører. Trening av IT-kontakter i bruk av enkle systemer for passordbytte, feilmeldinger ol. vil gi bedre kvalitet på henvendelsene til IT-tjenesten.

Opplæring og produkttrening er regulert i Arbeidsmiljøloven (§ 4-2):

Så kort fortalt kan man med fordel øke innsatsen på opplæring, noe som vil forbedre IT-tjenesten og gi betydelig kostnadsreduksjon. Dette fordi brukere og IT-kontakter blir tryggere og flinkere til å hjelpe hverandre. Det bør også nevnes at overgang til ny programvare kan også gi en anledningen til å forenkle noen av driftsrutinene. Forenklinger kan redusere kravet til produkttrening.

Planlegging ved igangsetting av servicestøtte

Et stadig økende antall virksomheter ser nødvendigheten av tjeneste-styring. Det er ofte praksis at man baserer beslutninger på historiske og politiske vurderinger, framfor gjeldende behov i virksomheten. Derfor er det viktig å sikre at ledelsen forplikter seg til deltagelse, og forståelse for arbeidsmåten i organisasjonen, og gå gjennom eksisterende prosesser og sammenligne disse med virksomhetens behov og «best practice».

Innføring av servicestøtte

Helsesjekk

Brukbarhetsstudie (Feasibility study)

Fastslå gjeldende situasjon

Helsesjekk

Generelle retningslinjer for prosjektplanlegging

Forretningstilfelle for prosjektet

Kritiske suksessfaktorer og mulige problemer

Prosjektkostnader

Organisasjonen

Produkt

Planlegging

Kommunikasjonsplan

Prosjektgjennomgang og rapportering

Fremdrift

Evaluering av prosjektet

Etterarbeide

Gjennomgang for å sjekke samsvar med kvalitetsparametere

Gjennomgang i forhold til nøkkelfaktorer

Tjenesteleveranse (Service Delivery)

Hovedformålet med tjenesteleveranse er å sikre proaktiv drift og at IT-tjenesten leverer passende støtte for brukerne. Hensikten med tjenesteleveranse er å fokusere på virksomhetens behov. Det er aktiv læring med bruk av IT-verktøy i de forskjellige fagene som er behovet i skolen. Dette kapitlet beskriver i rekkefølge:

Tjenestenivåhåndtering

Vi har oversatt det som ofte er kjent som forkortelsen SLA (Service Level Management) til tjenestenivåhåndtering. Håndtering av tjenestenivå handler om kvaliteten på driftstjenesten. Den måles i forhold til hva som er avtalt i en kontrakt. Det er helt konkrete tall for tilgjengelighet, svartider, brukerstøtte, feilretting osv.

Målet er å ha styring over tjenestenivået for og forbedre kvaliteten på driftstjenestene. Ved gjentakende runder fastsettes, overvåkes og rapporteres kvalitetsnivået. Hensikten er å forbedre kontakten mellom IT-ansvarlige og brukerne slik at det leveres en IT-tjeneste til avtalt kvalitet.

Det er viktig å ha et bevist forhold til forskjellig typer SLA-er. Man kan velge mellom mange typer avtaler. Det vanlige er tre typer:

Alle SLA-ene skal administreres, rapporteres på og vedlikeholdes. Det blir fort uoversiktlig og mye arbeide som ikke gir særlig nytte. Hensikten er at man får en avtale som bidrar til å bedre kvaliteten på tjenesten. Derfor er det nyttig å tenke seg godt om når avtalen lages. Her følger en oversikt over hva som er viktig å passe på når man lager en avtale om tjenestenivåhåndtering.

2.2 Overordnet sjekkliste

2.3 Planlegging

Det er helt avgjørende at driftssenteret har tekniske muligheter til å måle de verdiene som inngår i tjenestenivåavtalen. Dette må tas hensyn til helt fra begynnelsen.

Videre er det viktig å definere de tjenestene hvor man er avhengig av underleverandører og derfor ikke kan gi garantier for tjenestenivå, eller er avhengig av en tilsvarende avtale med underleverandøren. Definisjonen av avhengigheter gjør man for at det skal være klart hvem som retter opp i problemer, og for å unngå stadige forhandlinger før feil kan rettes.

Krav til tjenestenivå kan være forskjellig for forskjellige brukergrupper eller under forskjellig perioder av skoleåret. F.eks. kan det være forskjell på lærere og elever, eller at man har høyere tjenestekvalitet under gjennomføring av eksamen. Det er viktig å ha dialog med alle relevante brukergrupper for å sikre at det som måles er mest mulig relevant for hver enkelt brukergruppe.

2.4 Implementering

Det må utarbeides en tjenestekatalog som inneholder alle tjenestene som inngår i tjenestenivåavtalen. En tjeneste vil ofte være en applikasjon (program) i denne katalogen. Det vil ofte være forskjellige krav til forskjellige tjenester, og det vil gjenspeiles i forskjellige måltall i avtalen.

Etablering og kontinuerlig justering av brukernes forventninger kan ikke overvurderes. Ofte vil brukerne ha overdrevne forventninger til systemet og tjenestene som inngår, og det er IT-tjenestens ansvar å justere forventningene ned til realistisk nivå før tjenestenivåavtalen inngås. Driftssenteret må også passe på at alle brukere faktisk får beskjed om hvilket tjenestenivå som forventes gjennom avtalen.

For strukturen på selve tjenestenivåavtalen, se 2.6.

2.5 Driftssituasjonen

Overvåkning av faktisk oppnådd tjenestenivå og rapportering tilbake til kunden er vesentlig for å bevare en god relasjon mellom driftssenteret og brukerne. Format og detaljeringsnivå for rapportering skal være håndtert i tjenestenivåavtalen.

Det skal avholdes periodiske (f.eks. kvartalsvise eller halvårlige) møter med kunden. Fra disse møtene bør det komme konkrete planer for neste periode og f.eks. avtalt implementering av nye tjenester.

2.6 Innhold i tjenestenivåavtalen

Innledning

Navn og kontaktinformasjon for avtalepartene, beskrivelse av tjenestene som inngår, varighet på avtalen, ansvarsforhold mellom kunde og leverandør.

Tjenestetid

Hvilket tidsrom avtalen gjelder (f.eks. mandag-fredag 08:00 - 16:00), eventuelle spesielle krav for bestemte tidspunkter (f.eks. eksamen), rutiner for å bestille utvidelse av tjenestetiden.

Tilgjengelighet

Tilgang til tjenestene. Måles best som den tiden en eller flere tjenester har vært utilgjengelig i en periode (f.eks. en kalendermåned). Det kan avtales forskjellige nivåer for forskjellige tjenester (f.eks. avhengig av viktighet for brukerne).

Viktig å presisere at dette er tilgjengelighet innenfor den avtalte tjenestetiden, ikke den total tilgjengelighet hele døgnet, hele uka og hele året (såkalt 24/7/365). F.eks. kan det være avtalt at systemet skal være tilgjengelig mellom kl. 08 til 18 på arbeidsdager, etter det og i helger er det mer usikkert om en kan bruke datasystemet om ikke annet er avtalt.

Tilgjengelighet handler også om når man får brukerstøtte via telefon eller e-post. F.eks. kan servicekontoret nås mellom kl. 08 og 16 på dagen, eller hele døgnet. Skal man ha mulighet for brukerstøtte på ettermiddag og kvelden, eller i bestemte helger.

Stabilitet

Måles ofte som antall ganger med nedetid i en periode eller som gjennomsnittlig tid mellom episoder med nedetid. Man kan også måle tiden det tar før systemet kommer opp igjen.

Brukerstøtte

Måles ofte som svartid på telefon (f.eks. 1 minutt) eller e-post (f.eks. 30 minutter) ved henvendelser fra brukerne. Når driftsoperatør får en henvendelse om brukerstøtte vil meldingen bli kategorisert etter alvorlighetsgrad sammen med tidsgaranti for svar. Det kan også være avtale om hvor fort feilretting skal starte, noe som vil avhenge av hva slags kategori henvendelsen har fått.

Brukerstøtten handler også om når i døgnet man får tak i folk. Skal brukerstøtten være tilgjengelig i skolens åpningstid mellom kl. 08 og 16, eller skal man også ha brukerstøtte ut over kvelden eller på helgedager. Noen vil ha brukerstøtte også på bestemte helgedager.

Perioden for når brukerstøtten er tilgjengelig står som regel i tjenestenivåavtalen. Det avtales også om hva brukerstøtten skal hjelpe til med innen for en fast pris, og hva som må løses på oppdragsbasis. Avtalen regulerer prosessen det er å behandle henvendelser, både med hva som vil fikses, og når dette vil skjer.

Kapasitet

Kan måles som gjennomsnittlig svartid ved bestemte operasjoner i bestemte applikasjoner. Skal måle brukeropplevelsen av systemet.

Endringshåndtering

Mål for tid til håndtering, godkjennelse og implementering av endringsforespørsler fra brukerne.

Sikkerhet

Kan måles som antall fastslåtte sikkerhetshendelser i en periode. Det er svært viktig å være tydelig på hver enkelt brukers ansvar for at garantier skal gjelde.

Fakturering

Priser, tidspunkt for fakturering og oppgjørsbestemmelser.

Rapportering og oppfølging

Beskrivelse av regler og perioder for rapportering av målt tjenestenivå. Det anbefales regelmessige møter (f.eks. kvartalsvis) for å gå gjennom rapporten og planlegge fremover.

Straffereaksjoner og eventuelle incentiver

Regler for reduksjon i pris hvis avtalt tjenestenivå ikke er oppfylt. Eskaleringsrutiner og regler for heving av avtale ved kontinuerlig brudd på garantert tjenestenivå. Eventuelle incentiver ved oppnåelse eller bedre enn forventet tjenestenivå.

Se appendiks A for tjenestenivåavtale.

Økonomisk styring (Financial Management)

Organisasjoner har sjelden full oversikt over IT-kostnadene sine. En undersøkelse av norske kommuner i 2001 viste at bare 1 av 8 kommuner hadde et IT-budsjett. Sannsynligvis står det ikke bedre til i skolen. Å få på plass et IT-budsjett er viktig. Ofte synes brukerne at de betaler for mye for en tjeneste de ikke er fornøyde med. Dette skaper mange ganger konflikter mellom brukere og IT-avdelingen.

Det er svært nyttig både for driftssenteret og brukerne å få dokumentert de reelle IT-kostnadene. Uten dette blir det vanskelig å budsjettere riktig. Ikke minst blir det vanskelig å gjøre en kost/nytte-vurdering av eksisterende IT-løsninger. Rektor bør kjenne IT-budsjettet like godt som hun kjenner lønnsbudsjettet, eller budsjettet over læremidler.

Det er tre viktige prosesser knyttet til økonomisk styring av IT-tjenestene:

  1. Budsjettering
  2. Regnskapsføring
  3. Fakturering

3.2 Budsjettering

Målet med budsjettet er å lage et realistisk anslag over forventede IT-kostnader. Budsjetteringen inneholder som regel forskjellige alternative løsninger. Det gjelder både i forhold til utstyr og programvare, og nivået man vil legge seg på. Budsjettet er utgangspunkt for senere budsjettforhandlinger med skolesjefen og/eller politikerne.

Budsjettet skal inneholde både personal- og utstyrskostnader. En del virksomheter regner bare på hva det koster å kjøpe utstyr. Da utelater man så mye som 60-70% er personalkostnader ved drift av en IT-løsning. Man må også få med alt av utstyr.

Det er eksempler på kommuner som har glemt å regne med kostnader til strømkontakter og datanettverk på skolene. Da har man glemt ca. 2000 kroner pr. klientmaskin. Skal man få på plass 70 nye datamaskiner snakker vi fort om 140.000 kroner til datanettverk og strøm.

Alternative løsninger er også viktig å få med i budsjettet. Det gjelder både i forhold til drift og utstyr. I dag er det flere leverandører som har spesialisert seg på drift av datautstyr på skolene med varierende priser og kvalitet. Antall samtidige brukere og type maskiner og programvare som skal vedlikeholdes betyr også en hel del.

Skal man ha bærbar PC til alle lærere og elever vil man fort få 5-6 ganger høyere driftskostnader enn om man har stasjonære PC-er med tre elever for hver klientmaskiner.

Regnskap

Regnskapet vil i all hovedsak bestå av fakturaene for innkjøpt av utstyr, kabling, reparasjoner, drift og ekstra tjenester. Når regnskapsperioden er over er det viktig å gå gjennom tallene og sammenligne dette med budsjettet.

Planlegging av regnskap og fakturering

Ikke alle kommuner har regnskapssystem som viser IT-kostnadene brutt ned på hver skole. Det kan være praktiske grunner til dette som for eksempel rabattordninger og lignende som kommunen får sentralt. Derfor er det viktig å gjøre litt planlegging slik at man får oversikt over hva kostnadene har vært med drift og anskaffelser når regnskapet skal vurderes opp mot budsjettet.

En del organisasjoner kan ha tungvinte og kostbare regnskapsrutiner. Man får fort ekstra kostnader med å betale regninger ved forsinkelser, eller om man har mange som skal godkjenne en utbetaling. Så det er viktig å bli enig om gode faktureringsrutiner ved anskaffelse og drift slik at man både har kontroll, men også håndterer betaling i tide uten lange beslutningsveier.

Implementering

Betalingsmåte er regulert av tjenestenivåavtalen. Når det gjelder regnskapssystemet må man bli enig med økonomiavdelingen om en praktisk måte å få rapporter på, slik at man får den ønskede regnskapsoversikten over IT-kostnadene uten at det tar lang tid å få ut oversikten.

Daglig drift

Når det gjelder driftsavtaler vil man vanligvis ha en fast månedlig fakturering som består av et fast beløp og eventuelle ekstra tjenester. Fakturering gjøres fra regnskapskontoret ut fra de driftsavtalene man har, og de ekstra tjenestene som er utført. Det er viktig med god og hyppig kontakt med regnskapstjenesten ut fra de oppdrag som er utført for kunden.

Kapasitetsplanlegging (Capacity Management)

Kapasitetsplanlegging brukes for å sikre at alle deler av IT-løsningen har tilstrekkelig kapasitet til å ivareta brukernes krav. Dette omfatter:

Kapasitetsplanlegging handler om å balansere:

Målet med kapasitetsplanleggingen er å unngå overraskelser.

Overvåkning

Det er avgjørende for god kapasitetsplanlegging at systemene overvåkes kontinuerlig for å fremskaffe det nødvendige datagrunnlaget.

Typiske data som overvåkes er:

I Skolelinux er det Nagios som brukes som overvåkningsverktøy.

Analyse

På bakgrunn av innsamlede data fra overvåkningsrutinene forsøker man å avdekke eventuelle flaskehalser i systemene. Eksempler:

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

Tiltak

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

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

Har 60 tynnklienter koblet til tjenermaskinen og ønsker flere PC-er.

Sats på halvtykke klienter, eller installer enda en tynnklient-tjener

Tynnklienter går tregt etter vi utvidet med 20 stykker uten å skaffe ny tjenermaskin

Installer 2 GB mer minne på tjenermaskin

Tynnklienter med 32 MB minne starter ikke etter oppgradering til Skolelinux 2.0

Skru på mellomlager (swap) på tynnklientene, eller nedgrader til LTSP 4.2 som er satt opp med swap.

Flash animasjoner gjør at tynnklientene går tregt når 50 elever er logget inn på samme tjenermaskin

Installer halvtykke klienter

Implementering

Implementering av eventuelle endringer av systemkonfigurasjonen må gjøres i samsvar med de retningslinjer som er satt for endringer av systemet. En godt planlagt test av funksjon og ytelse må også gjøres før endringene kan gjøres i produksjonssystemet. Testingen gjøres for å unngå driftsforstyrrelser når endringene settes i produksjon.

Utarbeidelse av kapasitetsplanen

En kapasitetsplan er i utgangspunktet en investeringsplan for IKT-systemet basert på kjennskap til brukernes nåværende behov og fremtidige planer.

Kapasitetsplanen bør oppdateres og behandles en gang i året, normalt i forbindelse med budsjettprosessen. Planen bør inneholde følgende områder:

Tilgjengelighetsstyring

God og stabil tilgjengelighet av IKT-tjenestene er selvsagt helt avgjørende for brukerne.

Tilgjengelighet sett fra brukerperspektiv avhenger av følgende forutsetninger:

Tilgjengelighet kan måles på flere måter. Men før vi viser eksempler peker vi på hva som kan være vanskelig med måltall. Om det skal jobbes systematisk med tilgjengeligheten må man avklare hva de forskjellige tingene betyr. Hva betyr f.eks. et prosenttall for tilgjengelighet.

La oss si at det er en «datamaskin med dataprogram» er en tjeneste. Om dataprogrammet ikke fungerer en dag, er da tjenesten utilgjengelig når alle de andre programmene fungerer helt greit. Hva om dataprogrammet er utilgjengelig for et klasserom, men tilgjengelig på resten av skolen (på grunn av en underliggende tjeneste). Dette er vanskelig materie å avklare, og jobbe med i praksis.

Måltall for tilgjengelighet

Tilgjengelighet kan måles på flere måter. Her er noen eksempler:

Måleverdi

Betydning

% tilgjengelig

Verdien kan være tilgjengelighet mellom kl 08:00 til 18:00. Er systemet nede 1 time i løpet av en dag, er systemet tilgjengelig i 90% av den avtalte tiden. Måles tilgjengelighet over en måned med 20 arbeidsdager, så er systemet tilgjengelig i 95% av tiden.

% utilgjengelig

Er systemet nede 1 time i løpet av en avtalt driftstid på f.eks. 10 timer om dagen, er systemet utilgjengelig i 10% av tiden. Måles dette over 20 arbeidsdager snakker vi om at systemet har vært utilgjengelig i 5% av tiden.

Antall timer utilgjengelig

Man kan avtale antall ganger man godtar at systemet er utilgjengelig i løpet av f.eks. en måned (20 arbeidsdager). Det kan være maksimalt 1 time utilgjengelighet i den perioden, og mellom 08:00 til 18:00.

Feilhyppighet

Også feilhyppighet kan måles pr dag eller hver måned. 3 feil i måneden for at systemet er nede mellom 08:00 til 18:00 er et eksempel.

Konsekvenser av feil

Måleverdiene er et vanlig utgangspunkt for å bedømme om en feil skal få konsekvenser ut over vanlig feilretting. Kunden eller skolen kan f.eks. be om å betale mindre for driftsavtalen for aktuell måned.

Det viktigste er at det man måler beskriver brukeropplevelsen på en best mulig måte. Derfor bør man måle det som er viktig for brukeren.

Tilbakemeldingen fra skolene er at det er skrivere som gir mest problemer. Det gjelder alt fra at skriverkøen har stoppet opp, til at papir eller toner mangler. Enkelte har også opplevd noe ustabilitet med nettleseren, og at kontorprogrammet OpenOffice.org blir hengende. Det kan skje når bredbåndsforbindelsen er ustabil og man har linker i dokumenter som går ut på Internett.

Infrastruktur

Skal man ha et stabilt datasystem er man avhengig av en god nok teknisk kvalitet på datanettet. Flere skoler har erfart ustabilitet fordi det fysiske datanettet er provisorisk og av dårlig kvalitet.

Mange satser i dag på trådløse nett. Gjør man det må man også være klar over at trådløse nett har betydelige svakheter. Trådløse nett har begrenset kapasitet. Det gjør at det kan bli ganske hakkete om 30 elever skal se en filmsnutt fra Internett samtidig. Trådløse nett har også skygger. Det betyr at det er områder som ikke dekkes, noe som gjør at enkelte havner i blindsoner. Da får man dårlig eller ingen nettoppkobling i det hele tatt.

Skal man stille krav til tilgjengelighet til vanligvis driftsselskap og IT-tjenester stille krav om god kvalitet på datanettet på skolen.

«Single points of failure»

Det er som regel deler i en dataløsning som bare må virke. Svikter f.eks. en brannmur og slutter å virke, så stopper det all trafikk til Internett. Man kan ha problemer med stabiliteten til system for tildeling av nett-adresser med DHCP (Dynamic Host Configuration Protocol).

Driftsavdelingen har som ansvar og kjenne til de delene som kan stoppe hele dataløsningen. Det er viktig å finne disse punktene, og fjerne feilene en etter en, om dette er noe man har råd til. Hvis man ikke har råd til å fjerne feilkilder som kan stoppe f.eks. hele datanettet må man leve med risikoen om at noe plutselig ikke virker.

Feilkilder som gjør at alt stopper kan også være logiske fremfor fysiske. Dette gjelder spesielt for datanett og databaser. Så det er viktig å ha et bredere perspektiv når det kommer til slike feilkilder.

Risikostyring

Man må vurdere hva man aksepterer av risiko i datanettet. Er det akseptabelt at brukere mister personlige filer og data når en harddisk går i stykker? Hvor raskt skal man få på plass utstyr som har gått i stykker? Det er skoler som har erfart at det tar flere dager å få opp tjenermaskinen etter virusangrep. Kommunen har ikke ressurser å avsette til feilretting.

Mye av arbeidet med drift går på å opprettholde tjenestenivået som er avtalt. Det handler om å unngå og miste tillit og brukertilfredshet. Risikostyring handler om å sette av passende ressurser til å holde hele datasystemet på lufta, og ha ressurser klar om noe skulle gå galt og må fikses.

Testing

Det er stor forskjell på å installere utstyr og programvare på en enkelt PC og hundrevis, kanskje tusenvis av datamaskiner. Har man ansvar for hundrevis av maskiner vil en liten feil som man kan leve med på en PC bety mye ustabilitet og misnøye om feilen rammer hundrevis av brukere.

For å unngå at man gjør feil ved installasjon, og bidrar til stabilitet, er det helt avgjørende å teste utstyr og programvare som skal brukes. Det handler om å følge opp den forventede kvaliteten. Skal man ha stabil drift må man ofte velge nest siste utgave av utstyr og programvare.

Man bør unngå å ta i bruk programvare som som slutter med en null. F.eks. OpenOffice.org 2.0 bør man unngå. Man bør ta i bruk kontorprogrammet når versjon 2.0.2 har kommet eller nyere. Da har programpakken blitt fikset for flere feil. Det samme gjelder maskinvare.

Når man ser på tjenermaskiner har de gjerne litt eldre utgave av prosessorer, og mer robust minne, og harddisker. Dette er fordi mange bruker denne maskinvaren samtidig. En liten feil som ikke ville bety noe for en bruker, kan gi driftsstans om 30 brukere er logget inn på maskinen.

Så testing handler om å ta i bruk utstyr som er velprøvd og utgaver av programvaren som har fått et halvår eller et år på baken. Testing handler også om å prøve ut de forskjellige delene i en mindre men realistisk sammenheng, for å forsikre seg om at alt virker. Å ta i bruk siste versjon, eller til og med beta-utgaver av programvare eller helt nyeste maskinvaren fører som regel til mye trøbbel og ekstra arbeide med vedlikehold. Å sette systemer i produksjon uten en mindre test i realistiske omgivelser fører som regel til betydelig brannslukking og misfornøyde brukere.

Når man gjør testing i mindre skala på utstyr som er i produksjon, er det helt avgjørende å avtale dette med de berørte. I tillegg må man velge tidspunkt for test. Man skal ikke test ut nye ting samtidig som det pågår f.eks. eksamensavvikling med bruk av IT-verktøy.

Designforbedringer

En driftsavdeling vil være tjent med å utbedre systemer som gir mye driftsmeldinger. Det kan være at brukerne får mye søppelpost. Da kan det være greit å installere filer for søppelpost. Det kan være mye ekstra arbeide med elever som stadig glemmer passordet sitt, og lærere som sender henvendelsen til den sentrale drifsstaben. For å unngå ekstra e-posting og dobbeltarbeide så kan læreren selv gi eleven nytt passord.

Dette var et par eksempler på designforbedringer som letter arbeidet med drift, og gjør at brukerne blir mer fornøyd. En godt drevet driftsavdeling har en liste med prioriterte designforbedringer som gjør at driften blir enklere. Prioriteringene gjøres som regel ut fra en vurdering av henvendelsen til servicekontoret som man har lagret i meldingsloggen, og en vurdering av arbeidet som må gjøres for å behandle henvendelsene.

Planlegging for tilgjengelighet

Det betyr at man har realistiske forventninger til IT-tjenesten ut fra hva driften koster. Planlegg hva som er forventet tilgjengelighet. F.eks. krever skolene at man skal være på lufta på under 1 time etter serverkræsj, så må man ha stående en ferdig installert maskin i reserve, hvor denne kan kobles inn som erstatning for den defekte maskinen. Det som gjøres i løpet av en time er å legge over sikkerhetskopierte filer til reservemaskinen.

Går en halvtykk eller tynn klient i stykker har man liggende et lite lager med maskiner og skjermer på skolen. Skolens IT-kontakt kan hente og installere en erstatningsmaskin. Dette kan gjøres enkelt og greit uten å vente i dagevis på utstyr som må bestilles.

Planlegging for gjenoppretting

Som eksemplet med utstyr som står klar til å erstatte defekt utstyr, så er det også forventet å kunne hente fram filer og data som har gått tapt. Derfor er det helt avgjørende å ha sikkerhetskopi av brukerdata og en kopi av oppsettfiler. Man må også ha arkitekturtegninger, og beskrivelser av systemet som gjør at IT-staben raskt kan få på plass systemene når noe går galt.

Det er helt avgjørende å planlegge sikkerhetskopiering av brukerdata og oppsett. Man må planlegge slik at man har riktig utstyr og passende tjenester. Det må også planlegges hvilke rutiner som skal følges når bestemte feilsituasjoner har skjedd, og systemene må gjenopprettes.

Driftskontinuitet (Service Continuity)

Driftskontinuitet eller kontinuitetshåndtering er ofte det mest kostbare prosessen å jobbe med. Høye krav til driftskontinuitet vil kreve store investeringer, noe som avtales i arbeidet med SLA-en. F.eks. kan det avtales at det ikke er noen katastrofeplan for enkelte tjenester. Har man en katastrofeplan så er verdien svært lav om den ikke prøves en gang i blant. Som regle er dette dyrt. Det er eksempler der kunden og ledelsen har sperret maskinrommet og tatt strømmen for å teste beredskapen til IT-avdelingen.

Driftskontinuitet kan være aktuelt i bestemte perioder som ved eksamen. Da kan det stilles ekstra krav til å ha utstyr med backup klart i tilfelle en harddisk på tjenermaskinen skulle svikte. Men også dette vil kreve betydelig ekstraarbeide for driftsstaben.

En IT-koordinator fortalte oss at det kan være like greit å utsette eksamen en dag om noe gikk galt med dataanlegget. Dette kostet mye mindre enn å ha et dobbelt antall med tjenermaskiner på hver skole. Det er eksempler på at skoler har hatt vannlekkasje. Da er det vanlige å utsette eksamen en dag eller to til skaden er utbedret. Man kan tenke på samme måte når det kommer til skolens dataløsning. Har man backup av hjemmekatalogene til elever og lærere har man tid til å områ seg uten å doble systemer på skolen. Da holder det med en eller to tjenermaskiner plassert på kommunehuset i reserve, som raskt kan kjøres ut og kobles opp på skolen om noe skulle gå galt.

IKT Infrastrukturledelse

Denne delen av driftsdokumentasjonen handler i større grad om teknologi. De andre kapitlene om servicestøtte og tjenesteleveranse handler om arbeidsprosesser og rutiner. Infrastrukturledelse handler om planlegging, design, utrulling, og vedvarende teknisk vedlikehold av IT-systemene. Hensikten er å tilby IT-løsninger som er tilpasset virksomhetens behov, og kan driftes over tid til en kostnad man har råd til.

God planlegging, administrasjon, og styring er nøkkelen for å sikre en godt utbygd IT-tjeneste, og at tjenesten kan tilpasses endringer i virksomhetens behovene over tid. Det handler om å bruk ressursene godt, og at man har ferdigheter og kompetanse som kreves for å tilby en god IT-tjeneste.

Selv om man skulle ha bygd ut en god infrastruktur må man regne med at 60-70% av kostnadene går til drift, altså servicestøtte og tjenesteleveranse. Allikevel utgjør infrastruktur rundt 20-30% av totalkostnadene, og man må ta denne delen like på alvor som driften. Den infrastrukturen man har valgt påvirker også i stor grad hva driften vil koste og hva systemene er i stand til å levere.

De fleste forbinder infrastruktur med vei, vann og kloakk, og strømforsyning. Skal man bygge et hus må man sørge for at infrastrukturen er på plass om man skal ha en viss bostandard. I dataverdenen forbindes ofte infrastrukturen med datanettverket. Dette var på 1980-tallet. I løpet av de to neste tiårene er infrastrukturen utvidet til å gjelde nettverk, datamaskinene, programvaren, og vedlikehold av dette. Så i denne delen av dokumentasjonen er alt nettverk, maskinvare og betydelige deler av programvaren en del av infrastrukturen.

Også her fokuserer vi på praktisk planlegging og gjennomføring. Vi har hentet inn konkrete plandata fra forskjellig kommuner som har laget gode IT-planer ved budsjettinger og anskaffelser. Vi går igjennom design og planleggingsprosessen, utrullingsprosessen, driftsprosessen, og støtte. Det er viktig å ha i bakhodet at det er forskjell på driftsstøtte når det gjelder hva servicekontoret gjør med f.eks. brukerstøtte, og den driftsstøtten som gjøres av f.eks. nettverkskabler til skolen. Det er i hovedsak fire prosesser som går igjen ved infrastrukturledelse:

<ol style="list-style-type: decimal;"> <li><p>Design og planleggingsprosess</p> <p>Utvikling og vedlikehold av IT-strategier og prosesser for utrulling og sammensetting (implementasjon) av passende løsninger i IT-infrastrukturen i organisasjonen.</p></li> <li><p>Utrullingsprosess</p> <p>Dreier seg om sammensetting (implementasjon) og utrulling av virksomhet, og/eller IT-løsninger designet og planlagt med et minimum av forstyrrelser for virksomheten.</p></li> <li><p>Driftsprosess</p> <p>Alle aktiviteter og tiltak for å levere og/eller vedlikeholde den ønskede bruken av IT infrastruktur.</p></li> <li><p>Teknisk støtteprosess</p> <p>Utviklingen av kunnskap for evaluering, støtte og kvalitetssikring av hele gjeldende og fremtidige infrastrukturløsninger.</p></li></ol>

Design og planlegging

Design og planlegging handler om å gi gjennomgripende strategiske retningslinjer for utvikling og installasjon av en IT-infrastruktur ut fra virksomhetens behov. Det gjelder ikke bare infrastruktur som nettverk, datamaskiner, og programmer. Også grunnleggende prosesser må på plass for å få teknologien til å virke. Det gjelder både servicekontoret og prosesser for tjenestestyring.

Å unngå planlegging, eller å kutte hjørner, gjører til stor risiko. Derfor er det ofte lurt å bruke litt mer tid og innsats på planleggingen, noe som vil redusere risiko, og gi betydelige fordeler under gjennomføringen. De fleste prosjekt strander grunnet manglende planlegging. Å få på plass en ITIL-prosess i organisasjonen er helt avhengig av forberedelse og planlegging, og effektiv bruk av folk, prosesser, og produkter* (verktøy og teknologi).

Det er også svært viktig å kommunisere og samtale med alle deler av organisasjonen under planlegging av ITIL. I Norge er dette regulert i arbeidsmiljøloven §4-2:

Hensikten er å levere de riktige IT-løsningene for virksomheten. Dette må være enkelt å vedlikeholde og være tilpasset skolen behov. Løsningen skal være rimelig over lang tid også når systemene utvides. Under en design- og planleggingsprosess forholder man seg vanligvis til en styringsgruppe og en referansegruppe. Et godt prosjekt sørger for å ha dyktige folk i styringsgruppa og personer som bidrar i referansegruppa. En god planlegger er flink til å bruke disse gruppene, og andre medarbeidere for å få fram de gode løsningene.

Vi har satt opp en huskeliste over aktiviteter og leveranser i et infrastrukturprosjekt.

Innspill

Prosesser

Leveranser

Som man ser er det omfattende planlegging som gjøres i et infrastrukturprosjekt. Et IT-prosjekt for skolene i kommunen kan fort bli på flere millioner kroner skal man ha ut 500-1000 datamaskiner med strøm, datanettverk og programvare. Med slike beløp er det viktig å ha gode og gjennomførbare planer med realistiske budsjetter.

Det er flere eksempler på at kommuner har undervurdert datasatsingen på skolene. De har installert masse fint utstyr som blir stående ubrukt. Det kan være programvare som mangler. Nettverket kan være av dårlig kvalitet eller man mangler strømkontakter. Kommunen for fort en ekstra regning på 2 millioner kroner om 800 maskiner på 10 skoler skal ha datanett og strømkontakter.

Gode utbyggingsplaner laget man for å unngå overraskelser. Planene lages også for å sikre et riktig ambisjonsnivå med et realistisk budsjett.

Utrulling

Definisjon:

I plan-prosjektet vil man ha gjort opp status for hva skolene har av utstyr, og hvor mye utstyr som finnes. Ut fra dette lages en plan for å rulle ut nytt utstyr, eller bytte ut utstyr på hver skole, og hos den sentrale driftstjenesten.

Dette handler om å plassere ut utstyret der det skal brukes. PC-ene skal settes ut på bordene og kobles til datanettet med en nettverkskabel. Stikkontakten skal settes i støpselet. Skjermen skal kobles til og man skal sette nettverkskabler i riktige switcher.

Uttrykket utrulling brukes både om de å plasser ut utstyr, og det å installere programvare og oppsett på mange maskiner. Man kunne kalt det å rulle ut programvare for utgivelseshåndtering av det engelske uttrykket «Release Management». Men ordet utrulling er kort og greit, selv om man bør presisere at om man snakker om maskinvare eller programvare, noe som krever helt forskjellige fremgangsmåter.

Utrullingshåndtering handler om gjennomføring av det som er planlagt og designet i utgivelsesprosessen. Å få ut utstyret der det skal er ofte vanskeligere enn det man tror, og tar betydelig med tid. Dette fordi mange parter er involvert enten det gjelder de som leverer utstyret, eller alle de som skal ta imot utstyret. På en måte kan man si at utrulling er det samme som en hjulbolt som holder bilhjulet på plass til akslingen.

Det er helt avhengig av mye samordning for å få alt på plass. Man må sørge for god taktisk planlegging, noe som involverer både endringsledelse og prosjektledelse. Man må sørge for at utrullingen henger sammen med design- og planleggingsprosessen.

Ofte kan oppstå en fare i at man undervurdere hvordan utrullingen påvirker eksisterende systemer. Når man tar ibruk nye løsninger, eller oppgraderinger, vil dette påvirke eller endre organisasjonen. Arbeidsrutiner legges om, og man får nye måter å løse oppgaver på.

I skolen handler endringen om at man innfører IT-verktøy i skolefagene. Dette er nytt og anderledes for lærerene. Mange er ukjent med hvordan utstyret kan brukes til læring. Samtidig skal det på plass en drifts- og vedlikeholdstjeneste for å gi skolene en trygg og stabil IT-løsning. Dette fører til endringer i organisasjonen, noe som må planlegges og krever ressurser. Derfor er det viktig å ta hensyn til dette både under planlegging og utrulling.

Roller under utrulling

Dette med å bygge ut en IT-infrastruktur kan sammenlignes med å bygge et hus. Bygge man et hus har man gjerne med en arkitekt, byggherre, huseier, murere, snekkere, rørleggere, elektrikere og en eller flere arbeidsledere (forman). Slik er det også ved utrulling av infrastruktur. Vi har summert opp de rollene som anbefales som en del av driftsstandarden ITIL.

Som vi ser berører utrullingen mange deler av virksomheten. Teknisk berøres konfigurasjoner og versjoner av programvare og utstyr. I tillegg påvirkes selve prosessen for endringer og hvordan arbeidet gjøres på servicekontoret.

Man må tenke seg litt om før man sørger for at personer får arbeidsoppgavene disse rollene legger opp til. Selv om man har et fullt utrullingsprosjekt til flere millioner kroner så kan det hende at en person har flere roller. Men det er ikke sikkert det er heldig at en og samme person har flere roller, da et utrullingsprosjekt for blir krevende i å følge opp leverandører og de som skal motta utstyret.

Ved mindre oppgraderinger og justeringer kan det fort bli for mange roller. F.eks. trenger man ikke å ha en prosjektleder for å plassere inn en ny tjenermaskin, eller bytte en svitsj. Dette er en del av infrastrukturen, men ligger veldig tett opp til drift og vedlikehold. Det viktige her er å skille mellom utrulling i infrastrukturen og driftstjenesten. Driftsavdelingen skal ikke overta utstyret før det virker slik som avtalt. Med andre ord har man et overdragelsesdokument der man kvitterer ut at utstyret er levert i forhold til det som er avtalt.

Driften

Definisjon:

Drift av utstyret handler om å ha verktøyene og maskinene på plass som et grunnlag for å levere IT-tjenestene som er avtalt. Drift av utstyr har et sterkt fokus på teknologi. Dette understøtter alle andre aktiviteter som gjøres med IT-systemene. Ofte ses driften på som støttetjenester bortgjemt på et kontor innerst i lokalet. Det er en «hygienetjeneste».Først når noe går galt kontaktes driftspersonellet. En god driftstjeneste er allikevel helt avgjørende for at IT-verktøyene virker som de skal. Uten en god drift så godtar man tap av tid, og at oppgaver ikke kan løses. F.eks. kan en skole få problemer med gjennomføring av prøver som gjøres med IT-verktøy.

Man kan spørre seg om man trenger drift. Trenger man folk til drift i dagens høyteknologiske verden? Er det ingen som har funnet på en måte å løse driftsoppgavene helt automatisk? Hvorfor skal man ha folk til drift? Svaret er som regel at man balanserer mellom hva som gjøres automatisk, og hva som folk må følge med på. En viktig erkjennelse er at folk flest vil ha noen å prate med når det oppstår et problem. De vil at feilen skal fikses, og de vil ha tilbakemelding om at alt går greit. Denne type feilretting er ikke særlig enkelt å erstatte med maskiner.

En god driftsavdeling velger å automatisere der det er mulig. Samtidig trenger man folk til å overvåke og holde styringen på de automatiserte løsningene. Automatikken må videreutvikles. Det er også situasjoner hvor automatikken ikke strekker til. Utstyr går i stykker, og programmer krasjer. Man trenger noen som er nevenyttige og kan utbedre feil og mangler, eller skaffe erstatning for det som ikke kan repareres.

En uorganisert driftstjeneste gjør at mye arbeidstid går med til brannslukking og manuelle rutiner som kunne vært automatisert. Å bruke tid på automatisering kan fort lønne seg fordi man kan frigjøre tid. Dette er tid som kan brukes til å forbedre brukerstøtten, gi flere tjenester, og høyne kvaliteten for brukerne. For å få til en permanent feilfiks kan det hende at man noen ganger må utsette oppgraderinger, eller fjerne tjenester som er til midlertidig reparasjon. Dette for å få tid til å fikse problemene skikkelig uten at det tar all tiden å overvåke systemet manuelt.

Drift handler i stor grad om å forebygge feil, eller rette på utstyret som er feilmeldt. Ofte er man ikke helt kjent med årsaken til en feil. Man må feilsøke for å finne ut hvor feilen ligger. Gode driftsmedarbeidere har teft. De bruker tidligere erfaring på å avdekke hvor feilen ligger. Så går de nesten rett på problemløsningen og retter feilen.

Configuration item

Konfigurasjonselement heter Configuration Item (CI) på engelsk. Det er en del av en infrastruktur. Et konfigurasjonselement er gjerne en som beskriver et ønske om endring eller et spørsmål. Det kan være å få på plass en ny tjeneste, eller gjøre justeringer på tjenester man allerede har i produksjon. Ofte er det et spørsmål om å oppgradere noe utstyr, eller skaffe noe nytt.

Konfigurasjonselementet er en viktig del av konfigurasjonsstyringen når det kommer til utstyr og infrastruktur. Ofte handler konfigurasjonselement om systemer skal:

Teknisk støtte

Teknisk støtte skal sørge for at man har folk med riktig kompetanse til å understøtte de tjenestene som leveres i datanettet, og personene som jobber på g servicekontoret. Som en del av den tekniske støtten bør man ha dyptgående dokumentasjon med tekniske råd. Rådene skal gi informasjon, veiledning og eksempler på utrullingsaktiviteter, og for støtte og vedlikehold av alle deler av IT-tjenesten. For å få dette til må staben kjenne, eller være i stand til å skaffe informasjon om teknologi, prosesser og dokumentasjon. Som man ser av listen består teknisk støtte av en rekke aktiviteter som man må gjøre:

Design og planlegging

Som eksempel på hvordan infrastrukturen kan lages, har vi tatt med betydelige deler av IT-planen for skolene i Nittedal 2005-2008. Vi har gjort en del justeringer så den blir mer generell og enklere kan kopieres av andre.

Bakgrunn for planen

I sitt «Program for digital kompetanse 2004-2008» setter Utdannings- og forskningsdepartementet mål for bruk av digital teknologi i norsk skole. «Innen 2008 skal vi ha en infrastruktur, en organisering og en kultur som gjør vårt skolesystem til et av de fremste i verden når det gjelder utvikling og pedagogisk utnytting av IKT i undervisning og læring.»

Å kunne bruke digitale verktøy defineres som en grunnleggende ferdighet i hele det 13-årige løpet. Elevenes utvikling av grunnleggende ferdigheter skal prioriteres i alle fag. De nye læreplanene vil medføre at elevene i økende grad må ta i bruk digitale verktøy i undervisningen. Elevene skal kunne bruke samme teknologi i arbeidene som danner grunnlag for sluttvurderingen som de bruker i undervisningen. Når eksamen gjennomføres med bruk av digitale verktøy, gir dette bedre samsvar mellom læringsarbeidet underveis og den avsluttende vurdering.

En nasjonal kartleggingsstudie (Skolenes digitale tilstand 2003, ITU, feb.2004) viser at datamaskiner i begrenset grad inngår i fagene i grunnskolen, og at datamaskinene brukes lite av elevene på skolen.

Denne planen bygger på «Kompetanseplan for skolene i Nittedal (2005-2008)» og er en presisering av kompetanseplanens mål for digital kunnskap i Nittedals skolen. I tillegg er dette en plan for investeringer og ressursbehov tilknyttet driften av vårt linux nettverk.

Forventninger til IT-verktøy og tjenester

Vi har ulike mål for ulike grupper i skolen og for de ulike sidene ved IKT-satsingen. Kort formulert er målene våre:

Gjennom disse hovedmålene vil vi oppnå at:

Kompetansebehov

For å bygge ut og vedlikeholde infrastrukturen trenger man et samarbeid mellom mange forskjellige fagfolk. Som eksempel viser vi hvilke utstyrsområder man trenger fagekspertise. Dette er utstyrsområder som inngår som en del av infrastrukturen på en vanlig skole.

I tillegg til de forskjellige fagfolkene som må på plass for å bygge ut infrastrukturen trenger man i tillegg:

Organisatorisk vil dette se slik ut

Organisasjonsdel

Oppgaver

Referansegruppe

skal representere brukerne av systemet. De skal gi råd om tiltak som fremmer en god og hverdagslig IKT-løsning for skolene.

Styringsgruppe

har som oppgave å passe på at prosjektet har nok ressurser, og at prosjektledelse får gjennomført utrulling i henhold til planene. Gruppa skal bestå av dyktige fagfolk som er godt kjent med prosjektgjennomføring, systemløsninger, og bruk av IKT-verktøy i skolen.

Prosjektet

har til oppgave å bygge ut løsningen. Prosjektet består gjerne av mange delprosjekt som leverer hver sin del av løsningen.

Investeringer

For å oppfylle ny læreplan må skolene ha tilstrekkelig med datamaskiner tilgjengelig for sine elever og ansatte. Denne investeringsplanen har med de faktiske kostnadene ved en økning av maskinparken på skolene slik at vi når nasjonale målsetninger. Minimum med utstyr er en klientmaskin eller pc per fjerde elev. Sannsynligvis vil det i løpet av få år komme ytterligere krav til mer utstyr, så vi legger opp til en pc-arbeidsplass per tredje elev. Alle lærere skal ha tilgang til en datamaskin i sitt daglige arbeide på skolen.

I dag består skolenettet av servere og tynne klienter på skolene, og en felles server til sikkerhetskopiering (backup) i kommunen. Siden vi kan bruke brukte datamaskiner som klientmaskiner i vårt nettverk, er det ikke maskinene til brukerne som er det dyreste (vi kjøper inn brukt utstyr og mottar donerte maskiner fra næringslivet). De store kostnadene ligger i økte behov for strømstikk i klasserom, og eventuelt en økning av strømkursene på skolene.

Siden antall samtidige brukere øker vil man også få økning i støtte- og driftskostnader. Det vil også være behov for bord og stoler til de nye pc-arbeidsplassene. I tillegg har alle skolene fått en fast utgift til bredbåndstilknytning. Videre belyser vi de totale kostnadene ved å doble maskinparken.

Status for pc-dekningen 01.06.2005 er:

  1. 8,9 elever per datamaskin på barnetrinnet
  2. 4,4 elever per datamaskin på ungdomstrinnet.

Mål for elever:

Hver elevgruppe (tidligere kalt klasser) skal ha tilgang på minst fem datamaskiner pluss at skolen skal ha et datarom med minimum 15 pc-er. I tillegg trenger skolen noen spesialmaskiner til videoredigering, spesialundervisning og lese/skrivekurs.

Mål for lærere:

Alle lærere skal ha tilgang på en datamaskin i sitt daglige arbeid på skolen.

Totalt antall maskiner:

Status Pr. 01.06.05

Behov 2008

Server status

Klienter

Bærbare

Fil servere + tynnklientserver:

Klienter

Bærbare

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

Vi ser for oss en kombinasjon av tynne klienter, halvtykke klienter og bærbare maskiner. Skolene skal ha en infrastruktur som gjør det mulig å sette ut tynne klienter i alle klasserom. Her kan elevene skrive, regne, bruke internett og lage presentasjoner. I tillegg skal skolen ha mulighet for å låne ut bærbare maskiner til forskjellige grupper. På denne måten får elevene tilnærmet full pc-dekning i gitte arbeidssituasjoner. De bærbare maskinene blir koblet opp mot tjenermaskiner i trådløst nettverk. På den måten blir undervisningen mer fleksibel.

Elever

Vi anbefaler en investering som gir minst en klientmaskin per tredje elev, noe regjeringen har nevnt i sin målsetning for IT-verktøy i skolen. For å få dette til trenger vi nærmere en dobling av antall klientmaskiner.

Status og mål

For å nå vårt mål må vi øke maskinparken fra 506 til 1033 maskiner. Dette er en økning på i underkant av 600 maskiner. (tynnklienter, halvtykke klienter og bærbare).

Kostnader

Vi har regnet med disse prisene og tar forbehold om prisendring:

Nyere brukt utstyr har mer ytelse enn de maskinene som var tilgjengelig for 3-4 år siden. Har maskinene 256 MB minne og 800 Mhz prosessor passer dette som halvtykke klienter. Dette gir enklere støtte til bruk av CD/DVD-spiller, lyd, USB-penn ol.

2006

2007

2008

Totalt

Thin clients and diskless workstations

130,000

130,000

130,000

322,000

Server machines

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

Strømstikk/kurs

290,000

290,000

290,000

870,000

Tables/chairs

190,000

190,000

190,000

570,000

Økt ressurs, drift

700,000

Lisenskostnader på bærbare msk

40,000

40,000

40,000

120,000

bredbåndsavtaler

100,000

100,000

100,000

300,000

Sum

5,582,000

Andre innkjøpsalternativer

Det er registrert en økende interesse både fra politikere, foreldre og lærere om å gå over til bærbare maskiner på ungdomstrinnet. Bærbare maskiner og trådløst nettverk vil gi skolene en helt annen fleksibilitet med tanke på romløsning og undervisning.

Problemet med ensidig satsing på bærbare er:

Grovt regnet har dette alternativet en prislapp på totalt 12 millioner. (Da er ikke økte forsikrings kostnader regnet med.)

Teachers

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

Status og mål

Status: Skolene har i dag ca. 65 pc-er fordelt på ca. 266 ansatte. Dette gir en pc-dekning på 4 lærere pr. pc.

Vi ønsker å satse på lærerne i Nittedal. I ny læreplan stilles det høye krav til lærernes IT kompetanse. Det vil være fornuftig å sørge for at alle lærere i Nittedal har tilgang til en datamaskin. Dagens lærer planlegger og gjennomfører undervisning på og med data. De dokumenterer og rapporterer, skriver ukeplaner, arbeidsplaner, årsplaner og individuelle opplæringsplaner. Flere og flere lærere benytter e-post i kontakten hjem/skole.

Skolene har selv sørget for å kjøpe inn datamaskiner til sitt personale. Dette har ført til at antallet datamaskiner varierer fra skole til skole. Vi ønsker at alle lærere skal ha tilgang til en datamaskin i sitt arbeid.

Vi skisserer her to alternativer for å oppnå full pc-dekning for lærerne i Nittedal.

Kostnader

Alternativ 1: Tynne klienter i kombinasjon med bærbare. Dette vil gi hver lærer tilgang på en tynnklient + at 3,3 lærere deler tilgangen på en bærbar datamaskin.

kostnad

Totalkostnad

Alternativ 1

Tynne klienter

140 000

Monitors

100,000

Laptops

640 000

Annet: switcher, kabler.

80,000

Bord stoler

140 000

Strømstikk/kabling

400 000

lisenskostnader

40,000

Totalt

1 540 000

Tillegg for flatskjerm

200 000

Totalt med LCD

1 740 000

Fordelen med tynne eller halvtykke klienter til lærere er de lave kostnadene ved innkjøp. Vi kan også regne med en lengre levetid på de tynne klientene i forhold til bærbare maskiner.

Men gjenbrukt utstyr er ofte uten flatskjerm. Kabinettet til klientmaskiner kan være stort. Dette gir plassmangel på arbeidsplassen til lærerne. Skal man skaffe flatskjerm til alle lærerne må man tredoble kostnadene for skjer fra 500,- til 1500,-. Totalkostnaden vil da øke med 200.000 kroner. Totalt vil utstyret til lærerne koste 1,74 millioner kroner.

Andre innkjøpsalternativer

Alternativ 2: Bærbare maskiner til alle lærere

kostnad

Totalkostnad

Alternativ 2

Bærbare

2 128 000

Trådløse switcher mm

80,000

Strømstikk

75 000

Lisenskostnader

117 000

2 400 000

Problemet vi ser er selve plasseringen av de tynnklientene. Lærerne har små arbeidspulter ofte i store fellesrom. En tynnklient per lærer med skjerm av gammel type vil skape et plassproblem på alle skoler. Problemet blir sterkt redusert om man går for flatskjerm.

Fordelen med bærbare er at de krever lite plass. Lærerne kan enklere ta med arbeidet hjem. Ulempen er at levetiden på bærbart er rundt halvparten sammenlignet med stasjonært utstyr. Så det er rimelig å anta at vedlikeholdet av bærbare er dobbelt så dyrt som stasjonære pc-er, og tre til fire ganger mer kostbart å drifte enn tynne eller halvtykke klienter.

Anbefalt utbyggingsbudsjett

I perioden 2005 til 2008 har vi satt opp følgende anbefaling for en IT-infrastruktur for skolene.

Ant.

Art

Kostnad

600

Tynne og halvtykke klienter med all infrastruktur

5,582,000

200

Tynne eller halvtykke klienter med flatskjerm og all infrastruktur

1 740 000

Totalt 800 klientmaskiner

Totalt

7 322 000

Programvare, læringsplattformer, og tjenester

Hvor programvaren kan kjøres avhenger av infrastruktur og kapasitet på datanettet. Det går helt fint å drifte alle installasjoner på skolene fra et sentralt sted, f.eks. fra IT-tjenesten i kommunen eller et sentralt plassert driftssenter.

Man må ta høyde for at nettkapasiteten til skolene kan gi begrensninger i forhold til hvor mye skolene kan laste ned på samme tid, eller hvor det er mest optimalt å plassere tjenermaskiner om man vil ha full funksjonalitet på utstyret. Det er stor forskjell på om en enkelt lærer laster ned en filmsnutt fra f.eks. NRK, eller om 30 elever gjør dette samtidig. Har skolen 1,5 Mbit/s kapasitet på bredbåndet er det ikke mulig for 30 samtidige brukere å laste ned filmen direkte fra NRK. Da må man ha på plass mellomlagring på skolen.

Sjekkeliste sentralisering

UNINETT ABC har laget et dokument med anbefalinger<ref>Anbefalinger fra UNINETT ABC: http://www.uninettabc.no/?p=veiledning&amp;sub=annet </ref> knyttet til sentralisering av IKT-driften. Det blir gitt råd om plassering av tjenermaskiner og hvilke driftsoppgaver som kan sentraliseres ut fra tilgjengelig kapasitet på båndbredden til skolen.

Generelle tiltak for bedret drift av klienter og tjenere

Tynne eller havltykke klienter mot lokale tjenereNedlåsing av tykke klienterLokale tjenermaskiner

FjerndriftSentralisering av enkelte funksjonerLokale tjenermaskiner

Tjenermaskiner regionalt / nasjonaltSentralisering av all drift

Kapasitet på nettverket til skolene

Lav båndbredde (ISDN)

Middels båndbredde (ADSL o.l)

Høy båndbredde (fiber o.l)

Programvare

I ny læreplan (L2006) er bruken av digitale verktøy fremhevet som en av de «grunnleggende ferdigheter». Vi ønsker at bruken av IKT ikke bare skal omfatte undervisningen, men i økende grad være et pedagogisk og administrativt verktøy for å støtte læringsaktivitet, nye læringsformer og gi enkel tilgang til kunnskap. Å gjøre erfaring med bruken av digital læringsplattformer er et av målene i kompetanseplanen. Vi har et mål om at en eller flere skoler prøver ut dette innen 2006.

Forsking viser at man i begrenset grad utnytter datautstyret til læring i skolen. Databruken har stagnert og i enkelte fag gått tilbake viser forskning (ITU Monitor 2005). Bruken av IKT i skolen er gjerne individrettet, og elevene lærer å bli konsumenter. Man har læringsformer som hindrer kunnskapsdeling i skolen. Få lærere bruker IKT daglig. Internett og tekstrelaterte tjenester er de mest sentrale formene for datamaskinbruk i skolen.

Forenklet sagt fokuserer lærerne for mye på bruk av verktøy for kontoradministrativt arbeide som f.eks. MS Office eller OpenOffice.org. Det de burde fokusert på var bruk av simuleringer, redigering av blide, lyd og videoer, kommunikasjon på Internett, og spill.

Hjemmebruken er som oftest en helt annen. Hjemme er elevene produsenter og bruker IKT mest kollektivt og kommunikativt. De setter sammen og sender hverandre bilder, utveksler innhold, og bruker de store mulighetene til opptak, redigering og deling av filmklipp som er fullt mulig med dagens datamaskiner med bredbånd. Barn og unge spiller også dataspill mer hjemme enn på skolen (ITU Monitor 2005).

Forskerne sier at dataspill er en av de viktigste fritidsaktivitetene som barn og unge er opptatt av. Hvert fjerde barn spiller hver dag (Ungdomsstyrelsen 2006). Dataspill er en sosial aktivitet. I kjølevannet av spillene oppstår det både virtuelle og fysiske felleskap, fra å spille sammen på konsoller til at det arrangeres samlinger unge kan spille.

En viktig oppgave er at skoleutviklingen bidrar til å oppdatere allmenndannelsesperspektivet i den generelle delen av læreplanen. Slik at digital dømmekraft eller digital dannelse utvikles i forhold til trinn og læringsstrategier slås det fast av Forsknings og kompetansesenter for IT i utdanningen.

For å få tatt utstyret mer i bruk krever det betydelig innsats av læreren. De må etter- og videreutdannes i nye læringsformer for å kunne bruke de nye IT-vertkøyene i undervisningen. Det må legges mer vekt på unges faktiske mediebruk og kommunikasjonsformer. Da er det ikke nok med å tilby en læringsplattform og e-post. Da bør verktøyene ha full støtte for de nye formene for mediebruk.

For å få dette må utstyret være tilpasset den programvaren og nett-tjenestene lærere og elever bruker til skolearbeidet. Nettleseren er kanskje det viktigste programmet elevene bruker til læring. Mange vil også la seg overraske at kontorprogram som OpenOffice.org eller MS Office er lite aktuelt i lavere skoletrinn. Da er det enkle program til skrivetrening, tegninger, kommunikasjon, simuleringer og musikkforming som gjelder. Så det som er viktig i valg av programvare er å tilby god tilgang til Internett og støtte for aktiv læring med bruk av IT-verktøy relevant for skolefagene.

Med halvtykke klienter får man full støtte for multimedia, film og USB-penn med mer. Fordelen med tynnklienter er at det gir gjenbruk fra så langt tilbake som 1995. Den gang hadde ikke maskinene kapasitet til video. USB-standarden var ikke ferdig utviklet. Seks år gamle datamaskiner fra 2000 og nyere har som regel en mye høyere kapasitet. Slike maskiner kan helt greit vise fram videoklipp fra NRK, DVD-er, og man kan spille spill.

Fordelen med halvtykke klienter er at de gir samme ytelse som såkalte tykke klienter eller datamaskiner med det meste av programvaren installert lokalt. Samtidig får man samme lave driftskostnader med halvtykke klienter som med tynnklienter. Dette fordi all programvaren administreres på sentral tjenermaskin.

I dag følger det med over 50 skoleaktuelle program i Skolelinux. I tillegg er det med nettleser, e-post-klient og OpenOffice.org med 8 forskjellige kontorprogrammer. Dette er mye mer enn hva som følger med fra Microsoft som stort sett tilbyr nettleser, e-post og 5 aktuelle kontorverktøy.

Med Skolelinux er det også relativt greit å tilpasse menyene for de forskjellige skoletrinn slik at man kan redusere antall pedagogiske programmer. Spesielt siden noen programmer først introduseres i 4.-5. trinnet. Mens programmer som kanskje er populære på første eller andre skoletrinn vil bli for enkelt når elevene har blitt eldre og har lært mer. I tillegg er det et stadig økende antall pedagogiske programmer på Internett. Dette er programvare som virker uavhengig av plattform. Så man kan bruke programmene hjemme på Apple eller Windows, og på skolen med Skolelinux. Elevene takler dette helt fint.

Læringsplattfomer

Ulike digitale læringsplattformer finnes på markedet. Noen koster penger, mens andre er gratis. Felles for dem alle er at de tilbyr lærere og elever et område der de kan dele og lagre dokumenter, sende og motta informasjon.

Produkt

Priseksempel:

Digital læringsplatform

It`s learning

3300,- pr. skole pr. år

Skolenettet

Gratis

Nett-tjenester

Uavhengig av båndbredde kan følgende funksjoner sentraliseres:

Sjekkliste for tjenester som kan sentraliseres, eller replikeres. F.eks. kan backup sentraliseres. Det samme gjelder brukerdatabasen med sentral katalogtjener (LDAP) med replikering til hver skole.

Tjenester

Beskrivelse

Lokalt

Sentralt

Apache

Vevtjener gjør at alle brukere kan lage hjemmeside

CUPS

Utskriftstjener. Målet er at den også vil styre utskriftskvoter

DHCP

Automatisk oppkobling av maskiner i nettverket

DNS

Name server

LDAP

Katalogtjener som inneholder brukerdata for pålogging, fildeling og gruppeinformasjon

LTSP

Thin client server

NFS

Network file system

NTP

Klokketjener slik at alle maskinene har riktig tid

SMTP/IMAP over SSL

Email to everyone locally at the school

SSH

Fjernstyring over kryptert forbindelse

Squid

Mellomlager for nettsider (for å spare båndbredde)

Webmin

Systemadministrasjon via nettleser

User administration

Simplified user administration

Backup

Sikkerhetskopi (bør gjøres på egen maskin)

SMB

Samba for tilkobling av Windows-maskiner

cfengine

Automatisk styring av systemoppsettet

Host and service monitoring

Overvåking av helsetilstanden på tjenermaskinen

Appletalk

Tilkobling av Mac-maskiner

SQL-tjener

Følger med (ikke satt opp)

Ressursbruk til drift

For den daglige driften av skolenes datamaskiner har hver skole en IKT-kontakt. IKT-kontaktene har fra 2 til 4 timer avsatt til dette arbeidet pr. uke. I tillegg har kommunen en IKT veileder i 50 % stilling som jobber bla. med kompetanse og drift. Selve driften av linux nettverket skal gradvis føres over til kommunens it-tjeneste skoleåret 2005-2006.

På oppdrag for Skolelinux har Kapp næringshage laget et beregningsprogram som stipulerer ressursbruk for IKT i skolene. I dag drifter vi skolenes nettverk med over 3000 brukere på 2,1 årsverk. (Skolenes IKT-kontakter har avsatt tilsammen 1,6 årsverk til sitt arbeid, og 0,5 årsverk på kommunen) Når Knapp næringshage beregner vårt ressursbehov på drift stipulerer de dagens behov til å være 4,6 årsverk. Dette viser at skolen har klart mye på få ressurser.

Økt ressurs må i hovedsak settes inn på skolene. Det er skolenes IKT-kontakter som får mer å gjøre når pc-tallet går opp. Økt antall pc-er betyr økt bruk, og økt behov for veiledning i pedagogiske bruk av IT-verktøy.

Vedlikeholdet vil øke i forhold til flere samtidige brukere, men selve maskinvedlikeholdet vil øke nesten lineært i forhold til antall maskiner. Vi ønsker å satse mer på pedagogisk bruk av utstyret, og at mesteparten av økningen settes inn på bruk av IT-verktøy i skolefagene.

Det vil også bli et noe større behov for økt ressurs på kommunens IT tjeneste, men pga. stordriftsfordeler vil økningen her bli liten.

I dag er det vanskelig for skolene å prioritere timer til IKT-kontakt. Både fordi penger til dette må tas fra en allerede presset skoleøkonomi og fordi skolene har manglet føringer på hva og hvor mye IKT-kontaktene på skolene skal utføre.

Roller til drift

Oppgavene til IKT-kontakten på hver skole:

Erfaringsvis beregner vi disse oppgavene til minimum 4 timers jobb i uka for en skole med 50 tynne eller halvtykke klienter på en skole. Har skolen et mindre antall maskiner reduseres dette timetallet noe. Med økt antall maskiner til f.eks. 150 maskiner trenger lokal IKT-kontakt på hver skole rundt en 30% stilling til enkelt teknisk vedlikehold.

Kan ikke skolen avsette tilstrekkelig antall timer til IKT-kontakten må arbeidsoppgaver i listen over strykes og motsatt hvis skolen kan avsette flere timer.

Oppgaver ut over dette eks. oppdatering av nettside, være kursholder (ut over vanlig kollegial veiledning) må avtales individuelt mot eventuell kompensasjon/avspasering.

IKT-veileder anbefaler følgende oppgaver for IT-tjenesten og IKT-veileder.

Drift:

Kompetanse:

Hvor mye sentrale driftsressurser som er nødvendig avhenger mye av ha slags klienttyper man har valgt. Drift av arbeidsstasjoner er nærmere dobbelt så dyrt om drift av halvtykke klienter.

Drift- og støttekostnader

Definisjonen til driftskostnader:

Vi beskrevet hva som er et realistisk driftsmiljø ut fra hensynet til et moderat tjenestenivå med proaktiv drift. «Program for digital kompetanse» ligger til grunn for våre vurderinger.

Proaktiv drift handler om å oppdage og utbedre feil før dette berører brukerne. Et eksempel på proaktiv drift er å oppdatere bærbare datamaskiner med nye diskbilder en gang i uka. Når lærere logger seg inn om morgenen dagen etter, er alle maskinene stilt tilbake slik skolen vil ha det.

Driftsoperatør får meldinger om feil og mangler i systemet før det går galt for brukerne. Manglene utbedres og feilene fikses før brukerne merker noe. Et eksempel på system som kan gi meldinger som brukes til proaktiv drift er disklagre. De kan melde om en harddisk er defekt, eller om disklageret går fullt. Driftsoperatør kan også få informasjon om datanettet er tilgjengelig, eller om prosesser må avsluttes når brukere logger ut.

Når vi utvider maskinparken på skolene må dette få betydning for både IKT-kontaktenes arbeidsressurs og kommunens it-tjeneste mot skolene.

For å tallfeste behovet har vi beregnet økt ressursbehov på noen av våre investeringsalternativer:

Investeringer

Tjener-maskiner

Antallklienter/bærbare

Brukere:

Stipulert ressursbehov 2008

Dagens reelle ressurs:

Dagens behov 2005:

11

506

Over 3000

4,6 årsverk

2,1 årsverk

Elever i 2008:

29

1033

Over 3000

6,9 årsverk

Lærere i 2008:

Alternativ 1

280

266

4,3 årsverk

Alternativ 2 (bærbart)

266

266

5,9 årsverk*

Kostnader for drift av alle datamaskiner for elev- og lærermaskiner. Vi regner ut fra alternativ 1 med tynne eller halvtykke klienter for elever og lærere, og en del bærbare maskiner.

År

Ant. PC-er

Sentral driftsoperatør

IKT-veileder for hele kommunen

IKT-kontakt på hver skole (gj.snitt)

Samlet

2005

506

1/2 stilling

1/2 stilling

8,5 % stilling(3:30 timer i uka)

2,1 stillinger

2005

Personalkostnader til drift*

kr 980 910,-

2008

1333

1 stilling

1/2 stilling

100 % stilling(26 timer i uka)

11,5 stillinger

2008

Personalkostnader til drift*

kr 5 400 00,-

Alternativ 2 med bærbare datamaskiner til alle lærere:

År

Ant. PC-er

Sentral driftsoperatør

IKT-veileder for hele kommunen

IKT-kontakt på hver skole (gj.snitt)

Samlet

2008

1333

1 + 4/5 stilling*

1/2 stilling

100 % stilling(26 timer i uka)

12,8 stillinger

2008

Personalkostnader til drift*

kr 6 000 000,-

Opplæringskostnadene for elever og lærere er omtrent de samme med Windows og Linux, viser undersøkelsene som er gjort på skoler i Norge og i Storbritannia. Dette skyldes at opplæringen er knyttet til bruk av sluttbrukerprogram i skolehverdagen.

Vi har satt opp ekstra opplæringskostnader knyttet til Linux. Ved at alle lærere får en dags gjennomgang av skrivebordet med Linux-alternativet, går overgang til nytt system enklere for de som tror de bare kan Windows. Det er ikke regnet inn kostnader for opplegg som LærerIKT og lignende slik vi har gjort i kostnadsoversikten fra kommunene i denne undersøkelsen.

Alternativene oppsummert

For å nå målsetningen om en datamaskin per tredje elev og en pc per lærerer så anbefales alternativ 1. Dette alternativet krever over 800 ekstra datamaskiner i forhold til dagens dekning på 506 klientmaskiner. Totalt vil vi da få i overkant av 1300 klientmaskiner med hovedvekt på tynne og halvtykke klienter. Noen maskiner vil også være bærbare for å gi ytterligere fleksibilitet i skolehverdagen.

Alternativer

Kostnad over 3 år

Alternativ 1: Utbygging med 800 klienter

kr 7 322 000,-

Alternativ 2: Bærbar alle lærere + alt. 1

kr 12 000 000,-

Driftskostnader:

Alternativer

Årlig kostnad

Alternativ 0. Drift av 506 klientmaskiner

kr 1 000 000,-

Alternativ 1. Øker med 800 til 1300 pc-er

kr 5 400 000,-

Alternativ 2. Bærbar til alle lærere*

kr 6 000 000,-

Alternativ 3. Bærbar romløsning*

kr 8 000 000,-

Den store økningen i driftskostnadene fra dagens alternativ 0 til alternativ 1 skyldes satsing på IKT-kontakten på skolene. Denne økes fra 10% til en full 100% stilling. Det vedlikeholdet IKT-kontaktene gjør i dag er på rundt 10% stilling. Dette vil sannsynligvis øke til 20% med en dobling av antall klientmaskiner. Ved økning til en full stilling vil 80% av tiden brukes på støtte til den pedagogiske bruken av IT-verktøy i skolefagene. Dette betyr at rektorene på skolen må sette av ressurser til dette slik at man følger opp læreplanen av 2006.

Anbefaling

Alternativ 1:

Kostnadstype

Beløp

Av dette er drift av 1300 klientmaskiner:

kr 2 000 000,-

Årlig investering i tre år:

kr 2 440 667,-

Støtte til pedagogisk bruk av IKT-verktøy:

kr 3 400 000,-

Årlig kostnad for alternativ 1 med investering og drift:

kr 7 841 000,-

Vedlegg

Mange skoler har utarbeidet aktivitetsplan for bruk av IKT i skolen. Denne bør ligge med som vedlegg.

Ekstra konfigureringer

?/!\ Grafikk i dokumentet må legges inn og oppdaters

Enkel brannmur

Skolelinux har en arkitektur som både passer sentralisert drift, med plassering av tjenester sentralt, og kan driftes lokal på hver skole. En brannmur gjør det enklere å starte med Skolelinux om man vil prøve ut en liten installasjon.

Enkel brannmur med floppy (Coyote)

Brukertilfelle: For å komme igang med Skolelinux trenger vi og lage en enkel brannmur. Hensikten er å dele Skolelinux-nettet fra det andre nettet som er satt opp.

Hovedforfatter Klaus Ade Johnstad

<pre> IP adresse (IP Address): 10.0.2.1

Press "n"

Dette refererer til noe av de ekstra tingene som man trenger om man vil ha tilgang fra tilbyderen Big Pond, men er ikke sikker. Er det noen som vet?

Press "n"

Varsel: Siden Skolelinux/Debian-edu allerede har DHCP-tjener kjørende, må du skru av DHCP-tjeneren på egen firewall/router. Det samme gjelder alle andre maskiner som eventuelt kobles til et Skolelinux/Debian-edu-nett. Å ha to DHCP-tjenere på samme nett fører som regel bare til trøbbel

Eksisterer en ny utgave av Coyote Linux når dette leses, kan den erstatte versjon 2.24 med kommandoene over med versjonsnummeret som ble lastet ned.

  1. Etter Coyote Linux er lastet ned må filene pakkes ut. Man må være root-bruker for å pakke ut.

tar zvxf coyote-2.24.tar.gz

cd coyote

./makefloppysh

  1. Når man lager Coyote Linux på en Linux-maskin må man besvare flere spørsmål. Her følger en oversikt over svar som kan gis:

<pre>a. Coyote floppy builder script v2.9

Valget som anbefales er «1.68MB»

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

Her er det best å velge 1)

<pre>c. Configuring system for Ethernet based Internet connection.

Disse nettverksinstilingene for lokalt nettverk må endres. Se A

<pre> IP Address: 10.0.2.1

e. Does your Internet connection get its IP via DHCP? [y/n]:</pre> Svar yes(y) eller no(n) i samsvar med hva som er nett-oppsettet.

Får man IP via DHCP fyller man inn følgende informasjon:

<pre> Please enter the information for your static IP configuration

Vanligvis kan denne være blank

Vi tror dette refererer til noen ekstra ting som kommer fra leverandøren Big Pond, men er ikke sikre. Er det noen som vet så send oss en e-post.

<pre>h. Do you want to enable the Coyote DHCP server? [y/n]: n</pre> Her må svaret være «n»!

<pre>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</pre> Bare velg «n»

<pre>j. You now need to specify the module name and parameters for your

Dette er den vanskelige delen. Å vite hvilken modul som skal brukes for nettverkskorte er av og til vanskelig. Se på Seksjon 3.12 for å få et overblikk over tilgjengelige moduler. Husk, bruk ikke .o på slutten av modulnavnet. Bruk bare «fornavnet» på modulen.

Mange foretrekker 3Com. Nesten alle bruker modulen 3c59x.

<pre>k. The default language of the Coyote Web Administrator is English

Bruk engelsk. Det er mye enklere å få hjelp. Søk gjerne i Google for å finne løsning på problemer.

<pre>l. Syslog server address:</pre> Her kan man bruke hovedtjener som syslog-tjener. Bruk 10.0.2.2

  1. Du må sette inn en floppydisk i maskinen. Husk å skru av skrivebeskyttelsen. Det tar et par minutter å skrive til disketten.
  2. Vær sikker på at det ikke kommer noen feilmeldinger til ukjente NIC-moduler som dette:

<pre> Checking module deps for (wrong,bad)...

Vær sikker på at man får noe lignende dette isteden:

<pre> Checking module deps for (e100,3c59x)...

Løsning 2 Lag en Coyote Linux-diskett på en Windows-maskin

Å lager du en diskett på en Windows-maskin er nesten det samme som på Linux.

Last ned kildefilene for Windows. De kan hentes fra [http://www.coyotelinux.com/downloads/channel.php?ChannelID=5 Disk Creation Wizard v2.24.0]

Figur 3-2. Coyote Linux Windows Creator Welcome Image

Here you can just press "Next"

Figur 3-3. Lokalt nettverksoppsett av LAN

Fyll inn nødvendig informasjon om nettverket her: Se A

Fyll ut de rette IP-adressene og nettmaske (Netmask) gjør at Coyote Linux vil gi korrekt beregning av kringkastingsadresse (Broadcast) og nettadresse (Network)

Figur 3-4. Legg inn passord på Coyote Linux-disketten

Uten dette passordet kan du ikke logge inn på Coyote Linux ved en senere anledning. Se Seksjon 3.6

Figur 3-5. Syslog-tjener

La feltet stå blankt, eller se på 2.l

Figur 3-6. Type Internett-tilknytning (WAN)

Velg hva som passer for deg. Har du tilgang til DCHP-tjener, som er svært sannsynlig, da trenger du ikke mer informasjon.

Figur 3-7. Fast IP-oppsett

Har du en fast adresse, fyll ut de passende verdier her.

Figur 3-8. Ikke skrup på Coyote Linux DHCP-tjener!

Ikke skru på Coyote Linux DHCP-tjener. Det er allerede en som kjører på hovedtjener

Figur 3-9. Velg en drivermodul til nettverkskortet (NIC)

Dra og slipp for å velge riktig nettverkskort på Coyote Linux-maskinen.

I dette bestemte skjermbildet brukes modulen for 3Com på LAN-siden av nettet (Skolelinux), og Intel pro 100 kort for WAN-tilkoblingen (Internett).

Figur 3-10. Velg språk

Ønsker du å få god støtte på Internett, velge engelsk.

Figur 3-11. Lag disken

Plasser en floppydisk i diskettstasjonen, og trykk «Next».

Unntakshåndtering

Vårt klare råd er å lage minst 2 kopier av floppydisken. Det er kjekt å et par kopier klar om noe skulle skje.

Verifikasjon

< FIXME>

Oppdater konfigurasjonsdatabase

Enkel brannmur med CD

Brukertilfelle: For å komme igang med Skolelinux trenger vi og lage en enkel brannmur. Hensikten er å dele Skolelinux-nettet fra det andre nettet som er satt opp.

Hovedforfatter Klaus Ade Johnstad

Løsning

Coyote Linux er et produkt i stadig utvikling og vedlikehold. Akkurat som Skolelinux/Debian-edu. Det betyr at nye versjoner blir utgitt stadig vekk, med nye funksjoner og sikkerhetsrettelser. Spesielt grunnet sikkerhetsfikser burde du alltid bruke nyeste stabile utgave Coyote Linux

Siden Coyote Linux kjøer kun fra en floppydisk så er det ikke noe system å oppgradere. Man må lage en ny floppy som beskrevet i Seksjon 3.3. For å gjøre denne prosessen så enkel som mulig er det noen ting å huske på.

  1. Finn ut hva slags nettverkskort du har. Om dette er ukjent kan man bruke kommandoen lsmod for å liste alle lastede moduler (drivere) som er i bruk. Kanskje dette vil gi en ide om hva slags nettverskort som er i bruk.

<pre>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</pre> I denne listen med moduler som er lastet er nettverkskortet 3Com509 på plass to ganger. For en liste med tilgjengelige moduler, se på

Det vil være best å skrive ned på selve maskinen hva slags nettverkskort som er i den.

  1. Hva slags «port forwarding» er det?

Informasjon om «port forwarding»-reglene, om det er laget noen, er i fila <code>/etc/coyote/portforwards</code>

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

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Oppstart av Coyote brannmur

Brukertilfelle: Etter enkel brannmur er installert skal den installeres i nettet og virke.

Forfatter: Klaus Ade Johnstad.

Løsning

Det er to network card i Coyote Linux, en (LAN) er tilkoblet til Skolelinux/Debian-edu-tjeneren, den andre er koblet med en krysset kabel, eller via en sitsj til et annet nett (WAN). Noen ganger kan det være litt vanskelig å bestemme hvilke network card som er koblet hvor, spesielt om de begge er koblet til nett med lik adresse. Fremgangsmåten vi bruker for å bestemme hvilket kort som går hvor, er å bruke krysset kabel og først koble denne til network card i Skolelinux/Debian-edu-hovedtjener.

  1. Først starter man Coyote Linux uten noen kabel til network card
  2. Så brukes den kryssede kabelen for å koble Coyote Linux med Skolelinux/Debian-edu-hovedtjener (vær sikker på at den går i nettverkskortet merket eth0 om hovedtjener er en kombinert tjener).

  3. Logg inn på hovedtjener. Forsøk å bruke pingel Coyote Linux-maskinen. Bruk kommandoen ping -c10 10.0.2.1, eller alternativt forsøk å pinge hovedtjener fra Coyote Linux med kommandoen ping -c10 10.0.2.2.

  4. Da får du et svar som dette om det virker:

<pre>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</pre> Da har du funnet network card på Coyote Linux som må merkes LAN. Da vet vi at den andre network card er WAN. Denne fremgangsmåten vil bare virke sålenge network card-et på LAN-et er satt opp riktig. Som vist under oppstarten på linen

<pre>LAN network: UP</pre>

Er normalt det som vises

<pre>WAN network:

Siden du har startet uten noen kabler i network card-en.

Når det er bestemt hvilken rolle det er for hver av network card-ene, da kan man omstarte brannmuren med alle kablene på plass.

Forskjellige navn på network card-ene

De to network card-ene har fote forskjellige navn i Coyote Linux. Det blir litt forvirrende og lite konsistent. Her følger en oversikt:

De forskjellige navn brukt på network cards i Coyote Linux

Denne går til eksisterende nett

Internett

Eth1

WAN

Denn går til Skolelinux-nettet

LAN nettverket

Eth0

LAN

Start Coyote Linux-maskinen omigjen og vær sikker på at floppydisken til Coyote Linux står i diskettstasjonen. Pass også på at maskinen er satt opp til å starte fra floppydisk.

Figur 3-12. Coyote Linux Login

Du kan logge inn. Bruk brukernavnet «root» og passordet som ble bestemt når floppydisken ble laget (om dette ble gjort fra Windows). Eller trykk Enter (tomt passord) for innlogging på disketten laget med Linux

Notat: Det er vanlig at det ikke følger med noen tilbakemelding når man trykker passord i et Linux-system. Dette er for å avsløre så lite som mulig om passordet.

Unntakshåndtering

meny, status til nettveket, nede

Når du har kommet inn, trykk «c» for å få statusen til nettverket. I tilfelle det er et problem:

Figur 3-14. meny, status til nettverket, opp

Om alt har gått bra vil begge være «oppe»

Q: Det ser ut som network card (LAN) som går til Skolelinux/Debian-edu-nettet ikke virker: DOWN

Q: Det ser ut som network card (WAN) som er tilkoblet Internett ikke virker: DOWN

Q: Vi har satt opp brannmurer med mange forskjellige nettverkskort og driver-moduler for mange network card. Vi har til gode å finne noe som ikke virker riktig.

Q:Det ser ut som network card (LAN) som går til Skolelinux/Debian-edu-nettet ikke virker: DOWN

A:Har du satt opp network card i henhold til A, men fortsatt virker det ikke. Det kan hende at man har valgt feil driver for network card

Q:Det ser ut som network card (WAN) som er tilkoblet Internett ikke virker: DOWN

A:Det er vanligvis to grunner til at WAN network card ikke er oppe (UP):

  1. Du bruker en tilkobling med feil Internett-tilkobling. Så du må ta en titt på ny på 2.b

Om du har en tilkobling med en adresse tildelt av DHCP, som ikke er statisk. Da må det være en fysisk tilkobling med en nettverkskabel mellom Coyote Linux og nettkontakten.

  1. Du har valgt feil driver-modul for dette network card.

Du bør forsøke å logge inn på Coyote Linux og velge q) quit for å gå ut av Coyote Linux-menyen. Så bør du kjøre kommandoen

dmesg|more

bruk så mellomrom for å bla. Se på referansene til eth0 og eth1. Se på Forskjellige navn på network card-ene for en påminnelse om hva eth0 og eth1 betyr. Det er vanligvis en indikator for hva problemet er.

Q:Vi har satt opp brannmurer med mange forskjellige nettverkskort og driver-moduler for mange network card. Vi har til gode å finne noe som ikke virker riktig.

A:Har du sett på dette nettstedet for mer informasjon om network card og passende driver-moduler for Coyote Linux? [http://www.dalantech.com/ http://www.dalantech.com]

Verifikasjon

Brannmuren virker om du kommer ut på Internett via nettleseren på hovedtjener eller en tilkoblet klient.

Oppdater konfigurasjonsdatabase

Administrasjon av brannmur i nettleser (Coyote)

Brukertilfelle: Vi trenger å endre innstillingene i brannmuren. Brannmuren står innelåst på datarommet. Kan jeg gjøre endringen over nettverket.

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

Coyote Linux har en pen og et velfungerende administrasjonsverktøy via en nettside. Her kan man gjøre det meste. Skriv [http://10.0.2.1:8180/ http://10.0.2.1:8180] i adressefeltet til nettleseren. Adressen vil gi vev-administrasjon av Coyote Linux. Klikk på lenken, og skriv brukernavnet root og passordet du har laget for brannmuren.

Coyote Linux vev-administrasjon

Alle valg og innstillinger kan gjøres i Main Menu på venstresiden.

Coyote Linux hovedmeny

Å velge denne gir status for network card-er, IP-adressene som er på plass, oppetid til Coyote Linux, lst og lignende.

Her har du mulighet til å endre oppsettet til LAN network card. Det er denne som går til Skolelinux/Debian-edu-nettet. Behold verdiene som de er. Viser til A.

Varsel: Ikke gjør endringer her! Å gjøre det kan redusere ytelsen til Skolelinux/Debian-edu-nettet

< FIXME: Bør vise inneholdet av change_ip_setup her, senere>

Her har man muligheten til å endre veridene i WAN network card til det som går til Internett. Har du fått en ny Internett-leverandør, eller endrer dynamisk IP med DHCP til fast IP-adresse, så er dette stedet å endre informasjonen uten behov av å lage ny Coyote Linux-floppy fra bunnen av. Se 2.b

Dette gir muligheten til å sette opp DHCP-tjener som en del av Coyote Linux

Her kan man skru på og av tjenester som navnetjener (DNS), ssh og vev-admin.

Her kan man endre og skru på port forwarding i Coyote Linux. Dette er en kjekk funksjon i et Skolelinux/Debian-edu-nett. Siden Coyote Linux stopper og blokkerer de fleste tilkoblinger som f.eks. ssh, er det kjekt å bruke port forwarding. Dette er en måte å slippe ssh-tilknytninger gjennom Coyote Linux til et Skolelinux/Debian-edu-nettverk.

Bruk denne regelen for port forwarding

<pre> Yes TCP Any 22 10.0.2.2 22 No SSH straight into Mainserver</pre> alle ssh-tilkytninger som kommer til Coyote Linux vil bli videresendt til Skolelinux/Debian-edu hovedtjener. Du må bestemme om dette er ønsket.

Her kan man sette opp og stille inn brannmurregler i Coyote Linux. Det er mange regler som er klar til bruk, og kan brukes som eksempel.

Her kan man sette opp begrensninger på nettkapasiteten

Her kan man endre root-passordet Coyote Linux, også kjent som system-passordet. Dette er på samme måte som å bruke kommandolinja Seksjon 3.6.

Dette er filer som inneholder alle innstillinger.

Her finner man nyttige verktøy som ping, testing av porter (gateway), testing av navnetjener (DNS), og status for nettverket.

Er det gjort endringer Coyote Linux må disse lagres på disketten. Ved å velge Main Menu i Coyote Linux så kan man velge å lagre oppsettet. Alternativet er at alle endringer går tapt ved omstart av Coyote Linux.

Når man trenger å starte Coyote Linux på nytt kan dette gjøres fra «Main Menu». Når man velger omstart må dette bekreftes.

Omstart eller skru av Coyote Linux?

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Brannmur som DHCP-tjener (Coyote)

Brukertifelle: Ønsker å sette opp en god DHCP-tjener med høy stabilitet uavhengig av operativsystem i nettverket. Varsel: vanlig DHCP-tjener i et ikke-Skolelinux/Debian-edu-nettverk

Forfatter: Klaus Ade Johnstad.

Coyote Linux er en god løsning om man bare trenger en DHCP-tjener på nettverket uavhengig av hva slags maskiner som brukes, være seg Linux, Windows eller Mac.

Den eneste tingen som må konfigureres anderledes, er å skru på DHCP-tjeneren. < FIXME: lag lenke til skjermbilde>

En kort oppsummering om å gjøre om Coyote Linux til DHCP-tjener:

Coyote Linux som en standard DHCP-tjener

<pre>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</pre> så bør du bruke adressen 192.168.0.1 i steden for 10.0.2.1 når man logger inn på Coyote Linuxs vev-administrasjon. Se Seksjon 3.7 og

Ny adresse i dette tilfellet er:

Verifikasjon

Oppdater konfigurasjonsdatabase

Coyote brannmur og Internett-operatører

Brukertilfelle: Vi har en brannmur med Coyote Linux. Lar den seg koble til vår Internett-leverandør?

Forfatter: Klaus Ade Johnstad.

Notat: Det har enda ikke vært en situasjon hvor Coyote ikke virker mot Internett-leverandører i Norge. Fortell oss om du har erfart problemer med en.

Dette er en liste med Internett-tilbydere som fungerer godt med Coyote Linux

Grunnet anderledes nettverkspolitikk på Utdanningsetaten i Oslo må man gjøre følgende endringer på hovedtjeneren:

Endre følgende i filen <code>/etc/bind/named.conf</code> [5]

<pre> // forwarders {

endre dette til

<pre> forwarders {

Det betyr å fjerne kommentator-merker (#) foran «forwarders».

Gjør du ikke dette vil man ikke være i stand til å koble utstyret til Internett som skyldes problemer med navnetjeneren (DNS) hos Utdanningsetaten i Oslo. Driftspersonalet vil også engasjere flere til å få dette endret til slik etaten vil ha det.

Etter endringene er lagt inn i <code>/etc/bind/named.conf</code> må man omstarte bind med /etc/init.d/bind9 restart

Her må man gjøre samme bind-endringer som for Utdanningsetaten i Oslo.

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Støtte for nettverkskort i brannmuren

Brukertilfelle: Er de to nettverkskortene vi har i maskinen støttet av Coyote?

Forfatter: Klaus Ade Johnstad.

Dette er en liste med moduler som følger med Coyote Linux. Alle driver-moduler for network carder er listet opp.

<pre>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</pre>

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Spesielt gamle nettverkskort i brannmuren (ISA)

Brukertilfelle: Vi vil prøve å bruke noen nettverkskort i brannmuren som er nesten 20 år gamle. De har såkalt ISA-buss. Går dette?

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

Nettverkskot med typebetegnelsen 3c509 fra 3Com har vært en svært populær serie. Flere har Coyote Linux med slike nettverkskort produsert i f.eks. 1989, snart 20 år siden. Vi har kjørt disse kortene i tre år med Coyote brannmur uten problemer. Straks man har fått kortene opp å kjøre, vil de sannsynligvis kjøre i lang tid. Men det er noen ganger vanskelig å få kortene til å virke. Dette er fordi de har ISA-buss. Det betyr at viktige adresser (IO) og avbruddsmeldinger (IRQ) må håndteres manuelt. Dette gjøres helt automatisk med PCI-kort. Men bruker man ISA-kort krever det ekstra innsats. IO og IRQ på disse kortene kan håndteres av et gammelt DOS-program. Dette kan være litt vanskelig å få tak i, siden dette er nesten 20 år gammel programvare.

DOS-programmet for oppsett kalles <code>3c5x9cfg.exe</code>, og det brukes på følgende måte:

  1. Start maskinen med DOS. Man kan bruke FreeDOS, eller en oppstartsdiskett laget med Windows 95 eller 98.

  2. Straks maskinen er startet med DOS, sett inn en diskett med programmet <code>3c5x9cfg.exe</code>. Kjør programmet 3c5x9cfg.exe fra kommandolinja i DOS.

  3. Straks 3c5x9cfg.exe er startet, så kan hver av 3c509 network cardene settes opp med valget «auto»

<code>3c5x9cfg.exe</code> finner man hos Ruprecht-Karls-Universität Heidelberg: [http://www.urz.uni-heidelberg.de/Netzdienste/nm/misc/3comnic/ ]

FreeDOS finner man her: [http://www.freedos.org/ ]

Unntakshåndtering

Varsel: Flere rapporter viser at det er problemer med å bruke to 3c509-kort på samme maskin om ett av kortene er av combo-typen. Det er en korttype med forskjellige typer nettverkskontakter.

Ikke bruk kort med ISA-buss av combo-typen!

Verifikasjon

Oppdater konfigurasjonsdatabase

Nyttige linker om brannmuren Coyote

Brukertilfelle: Jeg har ikke fått nok hjelp om bruk av brannmuren på disse sidene. Hvor får jeg mere hjelp?

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Konfig:

Brukertilfelle: Hva ønskes konfigurert

Løsning

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Oppsett av infrastruktur

Nettverksarkitektur

Brukertilfelle: Skal sette opp et datanett som skalerer slik at man kan drifte systemet lokalt eller koble det til en sentralisert driftsløsning

Løsning

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Profiler for tjenermaskiner

Brukertilfelle: Hvordan kan man installere maskinene som et helt datanett for en skole eller for flere skoler i en kommune.

< FIXME: Inn med tegning som viser halvtykke klienter>

<ul> <li><p>[ATTACH]</p> <p>De forskjellige profilene på forskjellige tjenermaskiner.</p></li></ul>

Kombi-tjener som en samleløsing

To profiler med Hovedtjener og Tynnklienttjener i kobinasjon kalles en Kombi-tjener

Dette er et relativt lite steg, med kun noen håndgrep, som gjør det enkelt å bruke et passende svitsj på stamnettet, og bruke krysset kabel for å koble brannmuren med en kombi-tjener

Merk: Vær klar over at det å plassere en skriver på adressen 192.168.0.0/24 som er tynnklient-nettet virker ikke om vertsnavnet er printer00. Sørg for å redigere KDE Utskriftshåndterer som søker etter skrivere på 192.168.0.0/24-nettet. Ikke standard 10.0.2.0/23-nettet.

Beskrivelse av profilene i Skolelinux/Debian-edu

Profiler som vises under installasjon kommer fra filen: <code>src/debian-edu-install/debian/debian-edu-install.templates</code> hos alioth.debian.org

Grafisk skrivebord

Man vil stadig se referanser til grafisk skrivebord. I kortversjon betyr dette et moderne skrivebord med pek og klikk, vinduer, ikoner og filmapper. Grafisk brukergrensesnitt ble første gang laget av Xerox Parc i 1973, hele 10 år før dette kom for personlige datamaskiner som man fikk kjøpt i butikken. Dette var en svært kort presentasjon av grafisk brukergrensesnitt.

En kort oppsummering av forskjellige profiler i Skolelinux/Debian-edu og hvordan de kan kombineres

<ol style="list-style-type: decimal;"> <li><p>Hovedtjener</p> <p>VARSEL: Alle Skolelinux/Debian-edu-nettverk må ha kun en hovedtjener, og kun en installasjon med denne profilen. Profilen kan kombineres med tynnklienttjener som er det vanligste, eller bare en arbeidstasjon.</p> <p>Hvert Skolelinux-nett trenger en, eller bare en maskin kjørende med profilen «Hovedtjener». Denne maskinen gir nettverkstjenester som f.eks. nettverk, innlogging med hjelp av katalogtjener (LDAP) osv. Uten denne profilen installert vil ikke datanettet virke. Siden denne maskinen også har lagret alle datafiler er det behov for mye diskplass. Man får ikke grafisk brukergrensesnitt ved å installere denne profilen. Skal man ha grafisk brukergrensesnitt må man også installere arbeidsstasjon-profilen eller tynnklienttjener [7]</p></li> <li><p>Arbeidsstasjon</p></li></ol>

Maskiner som kjører en Arbeidsstasjon-profil er det vi kjenner som normale PC-er. Brukerne logger inn på en arbeidsstasjon, og får lagerplass på hovedtjeneren. Dokumenter, personlige innstillinger og mange nett-tjenester ligger på hovedtjeneren. Brukerprogram kjøres på arbeidsstasjonen.

Ønskes tilgang til CD/DVD-spiller/brenner, digitalkamera og skannere er dette profilen og installere.

  1. Thin client server

Maskiner som kjører som tynnklient-tjener gir støtte til tynnklienter. Denne profilen har også med arbeidsstasjon-profilen. For å hindre kapasiteten på nettet blir brukt opp (metning) kreves to nettverkskort. Profilene hovedtjener, arbeidsstasjon og tynnklienttjener kan installeres på en og samme maskin.

Denne profilen inneholder også arbeidsstasjon-profilen

  1. Halvtykke klienter

Maskiner som kjører som tynnklient-tjener gir støtte til halvtykke klienter om dette er lagt inn. I Skolelinux 2.0 må dette legges inn etterpå.. Denne profilen har også med arbeidsstasjon-profilen. Profilene hovedtjener, arbeidsstasjon og tynnklienttjener kan installeres på en og samme maskin.

Denne kombinasjonen av profiler, også kalt kombi-profilen, gir muligheten til å sette opp komplette Skolelinux/Debian-edu-nettverk med arbeidsstasjoner og tynnklienter med bare en tjenermaskin. Dette er en fullt ut brukbar løsning i et lite Skolelinux/Debian-edu-nettverk med kanskje 10-15 tynnklienter og noen arbeidsstasjoner. For større installasjoner må man vanligvis velge tjenermaskiner som er større.

  1. Hovedtjener + arbeidsstasjon

Denne kombinasjonen av profiler gir i all hovedsak en hovedtjener med grafisk brukergrensesnitt. Om man ikke liker ideen med å administrere hovedtjeneren fra kommandolinjen, er dette en god kombinasjon.

Frittstående-profilen er ikke en del av Skolelinux/Debian-edu-nettet. Hensikten med denne profilen er å støtte hjemme-PC-en eller bærbare maskiner.

  1. Frittstående

Frittstående-profilen kan ikke installeres sammen med hovedtjener, arbeidsstasjon eller tynnklienttjener.

Frittstående-profilen er best å bruke uten at den knyttes til et Skolelinux/Debian-edu-nett.

Alle programmene i Skolelinux følger med i Frittstående-profilen

Løsning

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Maskinvare tjenermaskiner

Brukertilfelle: Hva ønskes konfigurert

Løsning

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Klientmaskiner

Brukertilfelle: Valg av klientmaskiner. Skal man velge stillemaskiner eller maskiner til multimedia. Skal man ha bærbare til alle eller stasjonære.

Det er flere typer teknologier som kan gi brukerprogram på PC-en. Mest vanlig er tykke klienter med operativsystem lokalt på hver datamaskin. Men det finnes andre typer teknologi for brukerprogram på skrivebordet. Mange har hørt om grafiske terminaler. Eksempler på dette er Citrix, FreeNX og Windows Terminal Server. Det finnes også andre alternativer som halvtykke klienter og ekte tynnklienter. Denne artikkelen beskriver alternativene, og gir en oversikt over hvor de forskjellige terminal-teknologiene gjør best nytte. Bakgrunnen for artikkelen er erfaringer fra konsernløsninger med sentralisert drift av datamaskinen i mange forskjellige bygg med lav, middels eller høy nettkapasitet.

Klient-teknologiene blir beskrevet i følgende rekkefølge. Grafiske terminaler som Citrix og FreeNX, tynnklienter med X Windows, tykke klienter med Linux og Windows, halvtykke klienter med Linux, og bærbare PC-er. Deretter følger eksempler på hva som er vanlig å bruke av tjenermaskiner i forskjellige konsern-orienterte installasjoner. En nøkkelfaktor for å beregne driftskostnader er antall samtidige brukere og antall tjenermaskiner. Sentralisert drift av datautstyret på flere skoler kan i praksis sammenlignes med hvordan drift av IKT-systemer gjøres i større bedrifter. Ofte har skolene flere datamaskiner enn resten av kommunens virksomhet. Det kan fort føre til en dobling av antall ansatte i IT-tjenesten i kommunen om man ikke tenker seg godt om i det man velger klientløsninger i skolen.

Citrix er det mest kjente produktet for grafiske terminaler. Selskapet som lager dette produkter ble etablert i 1989. De første grafiske klientene ble laget for operativsystemet OS/2. Første Windows-produkt ble lansert med NT 3.51 i 1995. Det er flere konkurrerende produkter til Citrix. En av de mest vellykkede er NX-teknologien. I korthet du kjøre brukerprogram fra en tjenermaskin med Citrix eller NX. Skjermbildet eksporteres over nettet fra en tjener til en grafisk terminal på en tykk klient.

Grafiske terminaler har den styrken at det er samme hva slags operativsystem som kjører på klienten. brukerprogrammene på tjenermaskinen kan man bruke uansett. Man kan kjøre standard kontorprogram og klient for e-post over en ISDN-linje med 64 kbps. Når det er sagt er det begrensninger i forhold til grafisk programvare, enten det brukes med multimedia eller interaktiv grafikk. Løsningen kan fort bli uten praktisk nytte om en kommune har plassert ut 30 eller 50 grafiske terminaler på 5-6 skoler med bredbånd på 2-8 Mpbs. Med denne kapasitetet kan man ikke kjøre interaktive grafiske programmer. Nettet blir fyllt opp med trafikk, og Citrix-klienten kobles av tjenermaskinen.

Med grafiske terminaler må driftsavdelingen kjøre to parallelle løp for vedlikehold av programvaren. Vedlikehold skjer på alle klientmaskinene og på lokale og sentrale tjenermaskiner. For at f.eks. Citrix skal fungere rimelig godt må det utplasseres ut to ekstra tjenermaskiner i hvert bygg i tillegg til sentrale applikasjonstjenere. I tillegg er det som regel behov for en del tykke klienter også for bruk med multimedia. F.eks. er 1/3 av maskinene i Oslo-skolen tykke klienter for å gi støtte for multimedia.

Tynnklienter ble introdusert i 1984 på MIT. Dette var omtrent på samme tid som Apple lanserte Macintosh med grafisk brukergrensesnitt. Året etter kom første utgave av Windows fra Microsoft. Egentlig heter tynnklienter X Window System og kan brukes på alle mulige plattformer som f.eks. Linux, Mac eller Windows. X Windows snur verden på hode. I praksis kjører programmene på en tjenermaskin, og det grafiske brukergrensesnittet sendes over nettverket til klientmaskinen. Klientmaskinen kjører et tjenerprogram for framvising av grafiske vinduer. En X-tjener kan kjøre programvinduer fra forskjellige program som kjører på mange forskjellige tjenermaskiner. Tykke klienter kjører også X Window system, men da et lokalt nettverk på PC-en. Alle Unix-systemer med grafisk brukergrensesnitt kjører X-tjener.

Den største fordelen med tynnklienterer gjenbruk av eldre maskiner uten økning av kompleksiteten ved drift. Mange bruker PC-er med 233 MHz og 32 MB minne som tynnklienter. Det er ikke behov for lokal harddisk. Brukerne kan håndtere tyngre grafikk, lyd og enkel video. Flere skoler har åpnet for bruk av CD/DVD-rom og USB minnepenn på tynnklientene. Driftspersonellet slipper å holde orden på et eget operativsystem på hver av PC-ene. Alt håndteres fra tjenermaskinen. Hver tynnklient bruker rundt 2 Mbps nettkapasitet ved vanlig bruk. Ytelsen på tynnklienter er betydelig bedre enn grafiske terminaler. Tynnklienter trenger i snitt færre tjenermaskiner enn grafiske terminaler med f.eks. Citrix viser en utredning av Utdanningsetaten i Oslo.

Tykke klienter eller vanlige PC-er er det de fleste bruker i dag. Første gang uttrykket Peronal Computer ble brukt var 3. november 1962. Den første PC-en med nettverk og grafisk brukergrensesnitt ble laget hos Xerox PARK i 1973. I dag er det PC-konseptet IBM lanserte i 1981 som er mest kjent og utbredt. Hele operativsystemet og alle brukerprogrammene er installert på hver klientmaskin på et lokalt datalager. De mest kjente operativsystemene PC-er er Microsoft Windows og Linux. Men det er også en rekke andre systemer som mange bruker, blant annet en eller annen utgave av BSD.

Fordelen med tykke klienter er at alle programmene kjører lokalt, noe som kan gi stor fleksibilitet og god ytelse for brukerne. Siden de fleste brukerprogrammene kjører lokalt trenger man få sentrale tjenermaskiner. Løsninger med tykke klienter kan være relativt rimelig å drifte om man standardiserer. På Windows er det en stor fordel å ha mest mulig like maskiner, noe som er vanskelig over tid. Det er helt vanlig at f.eks. skolen at man både har 4 og 5 PC-typer. Dette påvirker driftskostnadene. Linux er mer fleksibel da systemet enklere kan administreres med mange forskjellige PC-typer. Linux krever også mindre minne, og tillater lengre bruk av eldre datamaskiner uten tap av ytelse rapporterer British Educational Communications and Technology Agency (BECTA).

Halvtykke klienter er en annen spennende teknologi. I dag støttes dette på Linux med Lessdisks eller ny LTSP. Novell hadde nærmest monopol på halvtykke klienter for 15 år siden. Forenklet går dette ut på at hele operativsystemet og brukerprogrammene er installert på en tjenermaskin. Operativsystem lastes opp fra tjener til klienten over nettverket. Fil, utskrift og nett-tjenester blir håndtert av et operativsystem laget for nettverk. Ved introduksjon av Windows 95 møtte Novell en teknologisk sperre. Microsoft la om til å styre Windows med registry istedenfor tekstfiler. Nå er det bare Linux og andre Unix-varianter som tilbyr halvtykke klienter.

Fordelen med halvtykke klienter er at man får ytelsen til tykke klienter med driftsfordelen til tynnklienter. Det betyr at virksomheten kan koble på svært mange klientmaskiner på en tjenermaskin, uten å installere lokalt operativsystem på hver klient. Alt håndteres fra tjenermaskinen. Systemet støtter lyd, video, CD/DVD-rom og USB minnepinne. I dag er det sjeldent at man får dårligere bruktmaskiner enn 800 MHz prosessor og 256 MB minne, noe som passer utmerket som halvtykk klient. Det er anbefalt å bruke lokal harddisk som mellomlager.

Bærbare maskiner er i all hovedsak en tykke klient. Bærbare i prinsippet brukes som tynnklient, halvtykk klient eller grafisk terminal. Men det er ikke særlig praktisk av flere grunner. Bærbar bør brukes som tykk klient. Skal man koble den bærbare til et stasjonært datanett må man velge hva slags tjenester som kan brukes.

Det er betydelige utfordringer med bærbare i trådløse nett med mange brukere. Trådløse nett har begrenset kapasitet. Bærbare maskiner er også utsatt for røff behandling, og krever oftere utskiftning enn hva som er vanlig for stasjonært utstyr. Man bør ikke kjøre grafiske terminaler på bærbare maskiner i i trådløse nett. Dette blir fort ustabilt når man har mange brukere. Tykke klienter med Linux eller Windows går fint. De kan relativt enkelt autentiseres mot datanettet. Brukeren får tilgang til filområder, utskrift og andre nett-tjenester på en trygg og sikker måte. Det er flere som tilbyr bærbare maskiner i skolen som kobles til datanettet som kjører Skolelinux.

Tabell over klienttypene

Hovedløsning

Støtte for multimedia

Kjennetegn

Tykke klienter (Windows, Linux eller Mac)

God støtte for lyd, grafikk og video gitt kraftig nok prosessor og minne på klientmaskinen.

Alle brukerprogram installert på klientmaskinen. Brukerprogrammene kjører på klientmaskinen. Klientmaskinen kan være stasjonær eller bærbar. Kjører flere tjenester i nettverk som e-post, fillagring, sak-arkivsystem ol.Fordel: Trenger få tjenermaskiner. God støtte for multimediaUlempe: Må installere og vedlikeholde all programvare på hver klientmaskin

Halvtykk klient (Linux. Tidligere var dette løsningen til Novell med Windows 3.X)

God støtte for lyd, grafikk og video gitt kraftig nok prosessor på minne klientmaskinen.

Alle brukerprogram er installert på tjenermaskin. Brukerprogram kjører på klientmaskinen. Klientmaskin er vanligvis stasjonær. Kjører flere tjenester i nettverk som e-post, fillagring, sak-arkivsystem ol.Fordeler: Samme funksjonalitet som tykke klienter. Trenger få tjenermaskiner. Klientmaskinene har ikke installert programvare.

Tynnklient (X Windows System)

Grei støtte for lyd, grafikk og video gitt kraftig nok prosessor på minne på tjenermaskin. Trenger høy kapasitet på klientnettverket.

Alle brukerprogram og tjenester er installert på tjenermaskin. Brukerprogrammene kjører på tjenermaskiner. Klientmaskinen er vanligvis stasjonær. Kjører flere tjenester i nettverk som e-post, fillagring, sak-arkivsystem ol.Fordel: Gir nytt liv til gjenbrukte datamaskiner. Klienten har ikke installert programvare.Ulempe: Krever flere tjenermaskiner enn tykke og halvtykke klienter.

Grafiske terminaler (FreeNX, Citrix, RDP)

Grei støtte grafikk gitt kraftig nok prosessor på minne på tjenermaskin, og høy kapasitet på nettverket. Svak eller liten støtte for interaktiv grafikk ved midlere nettkapasitet i nettverket.

Alle brukerprogram og tjenester er installert på tjenermaskin. Fullt operativsystem med vindussystem er vanligvis installert på klientmaskin. Brukerprogrammene kjører på tjenermaskiner. Klientmaskinen er vanligvis stasjonær. Kjører flere tjenester i nettverk som e-post, fillagring, sak-arkivsystem ol.Fordel: Gir nytt liv til gjenbrukte datamaskiner.Ulempe: Må installere og vedlikeholde operativsystem på hver klientmaskin. Krever flere tjenermaskiner enn ekte tynnklienter. Krever betydelig flere tjenermaskiner enn tykke eller halvtykke klienter. Gir dårlig ytelse eller ingen støtte for multimedia. Terminalen kobles ned ved metning i nettverket. Dette kan skje flere ganger i timen.

Laptops

God støtte for lyd, grafikk og video gitt kraftig nok prosessor og minne på klientmaskinen.

Fordel:Kan ta med PC-en hvor det måtte passeUlempe: Må installere og vedlikeholde operativsystem på hver klientmaskin. Må sette opp og vedlikeholde tjenester som gjør det enkelt og koble til og fra maskiner i datanettet. Det er betydelig brekkasje med bærbart utstyr, og levetiden er i snitt 3 år, eller 2-5 år mindre enn stasjonære maskiner. Drift av bærbart er dyrt.

Løsning

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Svitsjer

Brukertilfelle: Hva ønskes konfigurert

Løsning

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Trådløspunkter

Brukertilfelle: Hva ønskes konfigurert

Løsning

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Brannmur(er)

Brukertilfelle: Hva ønskes konfigurert

Løsning

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Rutere

Brukertilfelle: Hva ønskes konfigurert

Løsning

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Oppsett av enkel brannmur

Brukertilfelle: Hva ønskes konfigurert

Løsning

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Oppsett:

Brukertilfelle: Hva ønskes konfigurert

Løsning

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Nyttige kommandoer

Støtte for 4 GB minne &lt;-- inn under konfigurasjonstyring

Brukertilfelle: Fordi det er begrenset plass på Skolelinux/Debian-edu CD-en er det bare lagt med en Linux-kjerne, altså minste felles multiplum. Det betyr at det er lagt med en kernel som virker på flest mulig typer maskinvare.

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

Hvilken type kernel som kjører finner man ut med kommandoen uname -a. Kommandoen kan brukes senere for å sikre at man har oppgradert til ønsket kjerne. Da kan det se slik ut:

<pre>tjener:~# uname -a Linux tjener.intern 2.6.8-2-386 #1 Thu May 19 17:40:50 JST 2005 i686 GNU/Linux</pre> Her kjøres en 386-kjerne, som burde virke på omtrent alt av PC-er. Men den er ikke optimal for to prosessorkjerner eller mer enn 940 MB minne.

Ønskes en kjerne for nye tjenermaskiner med masse minne og flere prosessorer, kan du laste ned og installere dette etterpå. Pakkesystemet til Debian gjør dette enkelt.

Se på Seksjon 8.9 for en mer detaljert beskrivelse av apt-get og dpkg.

smp er nøkkelordet man må se etter når man vil ha en Linux-kjerne med støtte for mere minne enn 940MB minne og doble prosessorer. Forkortelsen smp står for Symmetric Multi-Processors. Kommandoen kjøres fra et skall som lister ut antall kjerner klar for installasjon:

apt-cache search kernel-image | grep smp

. Når dette skrives får man følgende utlisting:

<pre>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.</pre> Det er ikke behov for å oppgi en bestemt kjerne-versjon som 2.4.27 eller 2.6.8. Bare bruk 2.4 eller 2.6. Dette koker ned til

<pre>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.</pre> Nå trenger man kun å vite hva slags prosessor man har som f.eks. 686 (Intel), k7 (AMD), AMD64 eller EM64T

Straks man vet vilken kjerne som passer på maskinen kan den installeres med kommandoen

apt-get install kernel-image-2.6-<din prosessortype>-smp

Er det en Intel Xeon i maskinen kan man bruke

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

Bruker man en 2.4-kjerne

apt-get install kernel-image-2.4-<din prosessortype>-smp

Har man en AMD Athlon(TM) MP 2000 kan man bruke

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

Når man installerer ny kjerne kan man se noe som dette:

<pre>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:

Suggested packages:

Recommended packages:

The following NEW packages will be installed:

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

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) ...</pre> Som det vises ble det spurt om å installere kernel-image-2.6-686-smp, og det ble automatisk oversatt til å installere kernel-image-2.6.8-2-686-smp. Det ble også foreslått å installere noen andre pakker som kan være nyttige.

Start maskinen på ny med kommandoen: shutdown -r now

Unntakshåndtering

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

Bygge av kjerne på en Skolelinux/Debian-edu-maskin er eneste gang man behøver omstart. Når man installerer andre program er det ikke behov for omstart.

Verifikasjon

Kjører man kommandoen uname -a etter installasjon, så vil man se

<pre>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</pre> Etter installasjon av smp-kjerne, og omstart er utført, kan man kjøre kommandoen free og cat /proc/cpuinfo. Då kan man se om den nye kjernen bruker alt minne og begge prosessorer.

<pre>ltspserver00:~# free

Mem: 4074752 4045556 29196 0 339248 2327780 -/+ buffers/cache: 1378528 2696224 Swap: 1835000 5852 1829148</pre> Her er en nedkortet utskrift som har fjernet unødvendig utskrift.

<pre>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</pre>

Oppdater konfigurasjonsdatabase

Administrasjon av pakker (apt-get)

Brukertilfelle: Installere nye programmer eller oppdatere programmer.

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

For å installere pakker trenger man å forteller hvor de skal hentes fra. Altså hvilket pakkearkiv som skal brukes.

Man kan bestemme pakkearkiv i fila <code>/etc/apt/sources.list</code>

Man kan arbeide med pakkeadministrasjon på kommandolinja. Det er flere grafiske program også som f.eks. KPackage 7 eller Webmin 12

Dette avsnittet gir en rask introduksjon til bruk av kommandolinje for administrasjon av pakker.

Dette er innholdet av en fil med referanser til pakkearkiv på Internett eller fra en CD-rom:

<pre>#deb file:///cdrom/ sarge main local

deb cdrom:[Debian GNU/Linux edu _Sarge_ - Unofficial i386 Binary-1 (20050808)]/ unstable contrib loc al 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

    2. http based apt source:

  1. deb http://ftp.debian.org/debian/ sarge main contrib non-free

  2. deb http://non-us.debian.org/debian-non-US/ sarge/non-US main contrib non-free

  3. 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

  2. deb ftp://non-us.debian.org/debian-non-US/ sarge/non-US main contrib non-free

  3. deb ftp://ftp.skolelinux.no/skolelinux/ sarge local</pre>

Merk at linjene uten skigard ( # ) forran kan brukes som referanse til pakkearkiv. Eksemplet vise at man kun får pakker fra CD-rommen som ble brukt under installsjon. Andre akriv er ikke aktivisert. Skal man gjøre dette bør man åpne for sikkerhetsoppgraderinger. Så kan man prøve seg på andre akriver for flere pakker.

Som en start bør det se ut som dette:

<pre>#deb file:///cdrom/ sarge main local

cal main non-free

deb http://security.debian.org/ sarge/updates main contrib non-free

  1. Use (by uncommenting) either http or ftp, NOT both

  2. 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

  2. deb ftp://non-us.debian.org/debian-non-US/ sarge/non-US main contrib non-free

  3. deb ftp://ftp.skolelinux.no/skolelinux/ sarge local</pre>

Merk at det er plassert et #-tegn forran linjen som har «deb: cdrom». Det er ikke nødvendig å laste pakker fra CD-rom når man kan få alt og mer til fra Internett.

Legges det til en ny linje i denne fila må man også oppdatere databasen som har informasjon om hva som er tilgjengelig.

Se Kapittel 13 for andre linjer som kan legges inn som kilde for pakker.

Unntakshåndtering

Linkene til pakkearkiv har en bestemt utforming. Følger man ikke dette får man feilmelding ved oppdatering med oppfordring om å rette feilen.

Kommentartegnet ( # ) er også på plass forran flere linjer i fila. Teknikken med "å kommentere ut", er typisk for de fleste oppsettsfiler i Linux. Andre symbol som kan være i bruk er semikollon ( ; ) og doble skråstreker ( // ). Men her er det altså skigard som gjelder, og fjernes dette gjelder det som står på linja.

Oppdater pakkearkivet

Brukertilfelle: Oppdater pakkearkivet med oversikt over oppdaterte programmer.

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

Utvalget av tilgjengelige pakker oppdateres stadig. Det mest vanlige er at det kommer sikkerhetsoppdateringer. Nye versjoner av programvaren kan også bli lagt ut. Derfor må man oppdatere informasjonen om pakkearkivene. Dette gjøres med følgende kommando

<pre>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</pre> Man bør kjøre denne kommandoen før en oppgradering, eller før man legger til nye pakker.

Unntakshåndtering

Verifikasjon

Oppdater til nye pakker

Brukertilfelle: Oppdatering av installerte pakker til nyere utgave om dette er tilgjengelig

Forfatter: Klaus Ade Johnstad

Medforfatter: Knut Yrvin

Alle pakkene som allerede er installert kan oppgraderes til nyere versjoner med kommandoen

apt-get upgrade

<pre>tjener:~# apt-get upgrade Reading Package Lists... Done Building Dependency Tree... Done The following packages will be upgraded:

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]</pre> Bare trykk Enter eller 'Y' og så Enter. Pakkene vil lastes ned og installeres automatisk. Man vil få en endringslogg i det oppgraderingen starter.

Straks man har oppgradert kan man slette pakkene som er lasted ned i katalogen <code>/var/cache/apt/archives/</code>. Bruk kommandoen

apt-get clean

for å rydde i arkivet. Dette bør gjøres av og til. Ellers blir <code>/var</code> fylt opp.

Varsel

Noen ganger er det greit å se hva som kommer til å skje før man oppgraderer. Man vil gjøre en vurdering om det er behov for å laste ned flere store pakker. Kanskje må man vente til det er mer tilgjengelig nettkapasitet. Kjører man

apt-get upgrade --simulate

vil man simulere hva som vil skje, uten at det faktisk skjer. Er dette for mye informasjon på skjermen kan man kjøre

apt-get upgrade --simulate | more

Ser det greit ut, kan man kjøre kommandoen igjen uten paramteret --simulate

Det går også å bruke aptitude dist-upgrade i kombinasjon med apt-get upgrade.

Unntakshåndtering

Noen ganger vil man få en melding om endringer som berører pakker som skal oppgraderes eller installeres, som her

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

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

Bruk Mellomrom på tastaturet for å rulle gjennom meldingen. Da vil du se

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

(END)</pre> Trykk q-tasten for å avslutte, og man får

<pre>Fetched 60.2MB in 11m24s (87.9kB/s) Reading changelogs... Done apt-listchanges: Do you want to continue? [Y/n]?</pre> For å fortsette må man trykke Y for Ja.

Verifikasjon

Oversikt over installerte pakker

Brukertilfelle: Ønsker oversikt over installerte pakker

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

Man kan få en oversikt over installerte pakker med å bruke kommandoen

dpkg --list | more

Vær klar over at de to første bokstavene til pakken: "ii" betyr at en pakke er fullt installert.

Er man ute etter status på en bestemt pakke kan man bruke grep i søket etter den:

<pre>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</pre>

Finn navn til bestemt pakke

Brukertilfelle: Ofte er det vanskelig å huske navnet på en pakke.

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

For å finne en bestemt pakke kan man bruke et søkeord med kommandoen:

apt-cache search <pakkenavn>

Blir det for mye tekst på skjermen kan man prøve

apt-cache search <pakkenavn>|more

Det er to symboler < og > må ikke brukes. De er bare brukt i dette eksemplet.

<pre>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)</pre> Som skjerbildet viser er det mye som er relatert til apache enn de pakkene som allerede er installert.

Vis tilgjengelig informasjon om pakker

Brukertilfelle: Ønsker å få opplysninger om pakken. Det kan være avhengigheter til andre pakker ol.

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

Kommandoen

apt-cache showpkg <packagename>

og

<apt-cache policy <packagename>

vil gi detaljer om pakken.

<pre>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:

Så man ser pakken kdissert ikke er installert, men tilgjengelig for installasjon i versjon 0.3.8-1 fra <code>http://ftp.debian.org sarge/main</code>

Installasjon av pakker

Brukertilfelle: Ønsker å installere et program eller programpakke.

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

Når man har funnet pakken som skal installeres, kjøres kommandoen

apt-get install <pakkenavn>

Ønsker man å se hva som skjedde under installasjon bør man kjøre en simulering først med kommandoen

apt-get install <pakkenavn> --simulate

<pre>tjener:~# apt-get install aterm --simulate Reading Package Lists... Done Building Dependency Tree... Done The following NEW packages will be installed:

0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Inst aterm (0.4.2-11 3.1r0/stable) Conf aterm (0.4.2-11 3.1r0/stable) tjener:~# apt-get install aterm Reading Package Lists... Done Building Dependency Tree... Done The following NEW packages will be installed:

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) ... </pre>

Fjerning av installerte pakker

Brukertilfelle: Ønsker å fjerne bestemte pakker som ikke skal brukes.

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

For å finne en bestemt pakke som skal fjernes brukes kommandoer som er nevnt over.

Når man har funnet navnet på pakken kjører man kommandoen

apt-get remove <pakkenavn>

Ønsker man å se hva om skjer ved pakkefjerning kan man simulere dette med kommandoen

apt-get remove <pakkename> --simulate

<pre>tjener:~# apt-get remove aterm --simulate Reading Package Lists... Done Building Dependency Tree... Done The following packages will be REMOVED:

0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. Remv aterm (0.4.2-11 3.1r0/stable) tjener:~# apt-get remove aterm Reading Package Lists... Done Building Dependency Tree... Done The following packages will be REMOVED:

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 ...</pre>

Installer bestemt versjon av en pakke

Brukertilfelle: Ønsker en bestemt versjon av en pakke. Det kan f.eks være en tidligere utgave av et program.

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

Når man installerer en pakke med kommandoen

apt-get install <packagename>

er det den nyeste pakken som blir installert. Noen ganger ønsker man ikke den nyeste utgaven, men en eldre versjon.

apt-get install <pakkenavn>=eldre_versjonsnummer

Ønskes en eldre utgave av backup-modulen Webmin kan man kjøre

apt-cache showpkg webmin-slbackup

for å få en oversikt over tilgjengelig utgave

<pre>tjener:~# apt-cache policy webmin-slbackup webmin-slbackup:

Her kan man se at det er to utgaver tilgjengelig. Både 0.0.9-1 og 0.0.10-1

Ønskes versjon 0.0.9-1 av programmet kan den installeres med følgende kommando

apt-get install webmin-slbackup=0.0.9-1

<pre>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:

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 3.1r0/stable) Conf webmin-slbackup (0.0.9-1 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:

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) ...</pre>

Installer pakke med dpkg

Brukertilfelle: Noen ganger er det ønsket å laste ned en pakke fra andre som ikke ligger i et Debian nettarkiv. Operas nettleser et en slik pakke.

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

Last ned pakken fra hjemmesiden til de som har laget programmet. Det kan f.eks være Opera. Programmet installeres med følgende kommando:

dpkg -i <pakkens fulle filnavn>

. Ønsker man først å simulere dette prøv

dpkg --no-act -i <pakkens fulle filnavn>

<pre>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:

dpkg: error processing opera (--install):

Errors were encountered while processing:

dpkg krever mer håndtering enn apt-get fordi den ikke håndterer pakkeavhengigheter. Det betyr at man kanskje må kjøre apt-get umiddelbart etterpå med ekstra paramter. F.eks. hjelper det å kjøre apt-get --fix-broken for å ordne opp

<pre>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:

Suggested packages:

The following NEW packages will be installed:

0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Inst libaudio2 (1.7-2 3.1r0/stable) [opera ] Inst liblcms1 (1.13-1 3.1r0/stable) [opera ] Inst libmng1 (1.0.8-1 3.1r0/stable) [opera ] Inst libxcursor1 (1.1.3-1 3.1r0/stable) [opera ] Inst libxft2 (2.1.7-1 3.1r0/stable) [opera ] Inst libqt3c102-mt (3:3.3.4-3 3.1r0/stable) Conf libaudio2 (1.7-2 3.1r0/stable) Conf liblcms1 (1.13-1 3.1r0/stable) Conf libmng1 (1.0.8-1 3.1r0/stable) Conf libxcursor1 (1.1.3-1 3.1r0/stable) Conf libxft2 (2.1.7-1 3.1r0/stable) Conf libqt3c102-mt (3:3.3.4-3 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:

Suggested packages:

The following NEW packages will be installed:

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) ...</pre> Rustet med forskjellige kommandoer fra tidligere i kapitlet, kan man nå bekrefte at Opera allerede er installert

<pre>tjener:~# apt-cache policy opera opera:

tjener:~# dpkg --list|grep opera</pre> ii opera 8.51-20051114. The Opera Web Browser

Søk gjennom filer i en pakke

Brukertilfelle: Ønsker å finne et programnavn eller fil i en pakke

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

Man får en oversikt med kommandoen

dpkg --listfiles <pakkenavn>

<pre>tjener:~# dpkg --listfiles opera /usr/bin /usr/bin/opera . . . /etc /etc/opera6rc /etc/opera6rc.fixed</pre>

Finn hvilken pakke en fil kom fra

Brukertilfelle: Ønsker å finne pakken en fil har kommet fra.

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

dpkg --search <filename>

Dette kan se slik ut

<pre>tjener:~# dpkg --search /etc/opera6rc.fixed opera: /etc/opera6rc.fixed</pre>

Utpakking av filer fra en pakke uten å installere disse.

Brukertilfelle: Kanskje man ved et uhell har slettet en viktig systemfil, og at man ikke har tatt backup.

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

Bruker man kommandoen

dpkg --search <filename>

Advarsel: Pakk aldri ut pakker i root-katalogen <code>/</code>!

finner man hvilken pakke filen kom fra. Så kan man pakke ut pakken å få tilbake systemfilen slik vi viser videre.

Først må man få tak i den aktuelle deb-pakken. Man kan gjøre dette ved å plassere det i <code>/tmp</code>-katalogen. Man kan pakke ut filene i denne katalogen med kommandoen

dpkg --vextract <packagename> /tmp

. Da vil det lages nødvendige kataloger i <code>/tmp</code> og filene plasseres der.

dpkg --vextract <pakkenavn> /tmp

Lag ditt eget pakkespeil

Brukertilfelle: Noen pakker blir stadig installert. Andre pakker vil man unngå å laste ned fra Internett.

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

Kommandoen apt-get gjør det enkelt å installere pakker fra Internett. Men apt-get vil også bruke betydelig med nettkapasitet når program lastes ned fra debian-arkiv på Internett. Derfor kan man sende apt-get avgårde til et lokalt pakkearkiv. På den måten kan man installere pakker som allerede er lastet ned med enkel bruk av apt-get. Dette gir rask installasjon.

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

Etter dette legges en ny line til fila <code>/etc/apt/sources.list</code>:

<pre>deb file:///var/www dpkg/</pre> Så må man kjøre kommandoen apt-get update som vanlig for å uppdatere pakkene i databasen.

Sikker innlogging på brannmur (ssh)

Brukertilfelle: Noen ganger er det nødvendig å logge inn på Coyote Linux uten nettleser tilgjengelig. Kanskje kommandolinjen er å foretrekke?. Da kan man bruke ssh for å koble til Coyote Linux.

Er du logget inn på en maskin i et Skolelinux/Debian-edu kan man bruke

ssh -l root 10.0.2.1

til å logge inn på Coyote Linux

Er du utenfor et Skolelinux/Debian-edu-nett, kan man erstatte verdien 10.0.2.1 med en passende verdi for network card for WAN-et i i. I dette tilfellet kan det være ssh -l root 192.168.1.10

Her vil man møtes med samme valg som om man var logget inn på Coyote Linux vev-administrasjon. Dette presenterer i en tekstbasert meny.

<pre> Coyote Linux Gateway -- Configuration Menu

Man vil ha omtrent samme valg som når man er logget inn på Coyote Linux med vev-administrasjon. Se Seksjon 3.7 for en kort beskrivelse av meyvalgene.

Når man velger q) quit vil man ende opp med en kommandolinje i Coyote Linux. Må man tilbake til hovedmenyen i Coyote Linux, skriver man menu og trykker Enter.

Ser du dette når man forsøker å logge inn på Coyote Linux

<pre>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.</pre> Er det mest sannsynlig at man tidligere har logget inn fra en annen maskin, med IP-adressen 10.0.2.1, eller man har endret network card i Coyote Linux. Det kan også være attakk fra en ukjent mellomman. Løsningen er å fjerne nøkkelen, i dette tilfellet linje nummer 27 i fila <code>/skole/tjener/home0/klaus/.ssh/known_hosts</code>.

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Statusoversikt for brannmur (Coyote)

Brukertilfelle: Hvilke kommandoer kan brukes for å få meny eller få en oversikt over tilstanden til brannmuren?

Hovedforfatter: Klaus Ade Johnstad

Nyttige kommando i Coyote Linux

Nyttig for å finne ut om nettverket fungerer. Kommandoen ser om det er tilkobling til Skolelinux/Debian-edu-hovedtjener

<pre>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</pre>

Denne kommandoen gir tiden Coyote Linux har kjørt siden forrige omstart.

<pre> coyote# uptime\n 2:37pm up 80 days, 7:55, load average: 0.00, 0.00, 0.00</pre>

Denne kommandoen skriver ut informasjon om Linux-kernen som er kjører på maskinen. Man får ut ting som minne, prosessor, network carder. Er det for mye utdata fra dmesg kan man kjøre dette gjennom et såkalt bla-program som f.eks. «more», og bruk Mellomrom for å lese alt, dmesg|more

Viser ekstra informasjon om network cardene.

<pre>coyote# ifconfig eth0 Link encap:Ethernet HWaddr 00:50:FC:F8:D2:44

eth1 Link encap:Ethernet HWaddr 00:E0:18:A8:B1:BA

lo Link encap:Local Loopback

Denne kommandoen lister opp driver-moduler. Det er nyttig når man vil se hvilke moduler som er i bruk med network carder.

<pre>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)</pre> Dette er en listing som viser at driver-modulenene for network card er lastet. For Intel pro100 er det modulen eepro100 og 3Com har modulen 3c59x (som gjelder for kort med typebetegnelse 3c590, 3c595, 3c900, 3c905). Se Seksjon 3.12

Er nyttig for å finne hvor Internett-pakker tar veien. Ved eventuelle problemer er det kjent å se hvor Internett-pakkene tar veien.

Enda en kommando som gir informasjon om tilstanden til network carder.

<pre>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.</pre>

Kommandoen brukes for å se hvor mye minne som er tilgjengelig, og hvor mye som er i bruk. Denne maskinen har 32 MB minne.

<pre>coyote# free

Total: 30860 6004 24856</pre>

This commands starts the Coyote Linux Menu

<pre> Coyote Linux Gateway -- Configuration Menu

menu

Denne kommandoen starter menyen til Coyote Linux

<pre> Coyote Linux Gateway -- Configuration Menu\n\n\n 1) Edit main configuration file 2) Change system password\n 3) Edit rc.local script file 4) Custom firewall rules file\n 5) Edit firewall configuration 6) Edit port forward configuration\n\n c) Show running configuration f) Reload firewall\n r) Reboot system w) Write configuration to disk</pre>

coyote#reboot

Denne kommandoen gjør en omstart av Coyote Linux

coyote#halt

Her skrur man av Coyote Linux

Neste

Brukertilfelle:

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Siste

Brukertilfelle:

Forfatter: Klaus Ade Johnstad.

Medforfatter: Knut Yrvin

Unntakshåndtering

Verifikasjon

Oppdater konfigurasjonsdatabase

Vedlegg A - Avtale om drift av Skolelinux

Avtale nr: ..................

Kunde nr: ..................

AVTALE OM DRIFT AV SKOLELINUX

mellom

Driftselskapet AS, Maskinrommet 1, 0313 Oslo

Org.nr.: 989 313 313

(heretter kalt Leverandøren)

og

NN

Org.nr:

(heretter kalt Kunden)

Partene har inngått avtale om levering av driftsytelser (heretter kalt Avtalen) på etterfølgende avtalebetingelser. Følgende bilag inngår som en del av Avtalen:

Avtalen gjelder fra signeringsdato og i minimum 12 måneder fra Leveringsdag. Avtalen fornyes deretter automatisk for perioder á 12 måneder, med mindre en av partene skriftlig, tre måneder før utløpet av en avtaleperiode, har sagt opp Avtalen.

Avtalen er undertegnet i to - 2 - eksemplarer, hvorav hver av partene beholder ett - 1 - eksemplar.

Sted: .............................

Dato: .................. 2006

For Leverandøren: ....................................................

For Kunden: ....................................................

Bilag 1 - Definisjoner

Begrep

Beskrivelse

Driftsperioden

Fra Leveringsdag til den dag da Avtalen opphører å gjelde, uansett grunn.

Driftsytelsene

Tjenester fra Leverandør i Driftsperioden. Driftsytelsene er nærmere beskrevet i Bilag 3.

IKT-ansvarlig

Kompetanseperson(er) hos Kunden som er kontaktperson(er) mot Leverandøren.

Leveringsdag

Den dag Kunden kan ta i bruk Driftsytelsene.

Skolelinux

Linux-distribusjon som bygger på Debian Linux og er tilpasset bruk i norsk skole.

Bilag 2 - Kundens forpliktelser

1.Krav til IKT-kompetanse

IKT-ansvarlig (1-3 navngitte personer hos Kunden) skal håndtere henvendelser fra brukerne som er relatert til bruk av applikasjonene som inngår i Skolelinux. IKT-ansvarlig skal ha tilstrekkelig kompetanse til å gjøre en kvalifisert vurdering av om et problem er relatert til bruken eller driften av systemet.

IKT-ansvarlig skal kontakte Leverandøren på telefon eller e-post til brukerstøttesenter. Kundens brukere skal ikke kontakte Leverandøren direkte.

2.Krav til maskinutstyr

Kunden skal før Leveringsdag ha installert og testet at maskinutstyr fungerer tilfredsstillende.

3.Krav til programvare

Kunden skal før Leveringsdag ha installert Skolelinux og verifisert at installasjonen fungerer tilfredsstillende.

4.Krav til kommunikasjon

Kunden skal før Leveringsdag ha installert og konfigurert kommunikasjon mot Internett og testet at denne fungerer tilfredsstillende. Kunden må legge til rette for at Leverandøren får tilgang til Kundens IT-anlegg gjennom Internett for å kunne utføre Driftsytelsene.

5.Informasjon til Leverandøren

Når alle ovenstående krav er oppfylt, skal Kunden underrette Leverandøren skriftlig eller pr e-post om at IKT-anlegget er klargjort for at Leverandøren kan levere Driftsytelsene.

Liste over alle brukere av systemet med fullt navn, brukernavn og passord skal sendes elektronisk til Leverandøren senest samtidig med denne meldingen.

Bilag 3 - Leverandørens forpliktelser

1.Krav til Leveringsdag

Leverandøren skal etter å ha mottatt melding fra Kunden i henhold til Bilag 2, punkt 5, snarest mulig legge til rette for at Kunden kan ta Driftsytelsene i bruk. Leveringsdag skal være senest 4 uker etter at slik melding er mottatt av Leverandøren.

2.Informasjon til Kunden

Leverandøren ska underrette Kunden skriftlig eller pr e-post om hva som er Leveringsdag, dvs den dagen Kunden kan ta i bruk Driftsytelsene.

3.Krav til tjenester

Etterfølgende tabell viser alle relevante tjenester i tilknytning til drift av Skolelinux. Kryssene i tabellen viser ansvarsforholdet mellom Leverandøren og Kunden for de enkelte tjenestene:

Lev. (inkl) utføres av Leverandøren og inkludert i Avtalens pris. Lev. (løpende) utføres av Leverandøren på Kundens regning i henhold til satsene i Kapittel 7. Kunden utføres av Kunden på Kundens regning.

Tjeneste

Lev. (inkl.)

Lev. (løpende)

Kunden

Feilhåndtering og brukerstøtte på telefon og e-post

x

Deltakelse i Brukerforum

x

Utskifting av maskinutstyr<ref>Leverandoerens ansvar er begrenset til aa administrere skiftet av maskinvare. Leverandoeren har ikke ansvar for maskinvaren og garantier, priser, fraktkostnader osv maa avtales separat med maskinleverandoer.</ref>

x

Legge til, endre og slette brukere<ref>Kan gjoeres av Kunden gjennom en egen applikasjon i Skolelinux. Leverandoeren kan utfoere tjenesten for kr 50 pr bruker eks mva.</ref>

(x)

x

Passordbytte ved glemt passord

(x)

x

Sikkerhetsoppgraderinger på Skolelinux

x

Versjonsoppgraderinger på Skolelinux

x

Endre rettigheter på brukere

(x)

x

Overvåking av fyllingsgrad på disker

x

Overvåking av levetid på relevante komponenter

x

Utvidelse av filområder på disker

x

Drift og overvåking av brannmur

x

Drift og overvåking av nettverk

x

Sletting av utskrifter som sitter fast i køen på anmodning fra IKT-ansvarlig

x

Overvåking av at sikkerhetskopiering blir utført

x

Sletting av data på forespørsel fra IKT-ansvarlig

x

Skifte av medium for sikkerhetskopiering og lagring av sikkerhetskopi

x

Tilbakekopiering av sikkerhetskopi på anmodning av IKT-ansvarlig

x

Etablering av nye skrivere og skriverkøer

(x)

x

Stoppe og omstarte skriverkøer på anmodning fra IKT-ansvarlig

x

Stoppe prosesser som ”henger” på tjenermaskin som følge av applikasjonsfeil

x

4.Krav til responstid

Leverandøren skal uten ugrunnet opphold starte feilsøking og problemløsning. IKT-ansvarlig skal holdes fortløpende oppdatert om status og fremdrift på feilretting.

5.Krav til kompetanse

Leverandøren skal til enhver tid ha tilstrekkelig ressurser med relevant kompetanse til å utføre Driftsytelsene på en profesjonell måte.

Bilag 4 - Priser og betalingsbetingelser

1.Vederlag for Driftsytelsene

Vederlaget for Driftsytelsene beregnes på grunnlag av antall arbeidsstasjoner i nettverket. Avtalen omfatter minimum 60 arbeidsstasjoner. Kunden skal betale Leverandøren kr 900 pr år eks mva i vederlag for Driftsytelsene, altså kr 4.500 pr måned eks mva for 60 arbeidsstasjoner.

Hvis antallet arbeidsstasjoner endres skal Kunden gi Leverandøren skriftlig melding om dette med tilhørende dato for endringen. Justering av faktureringsgrunnlaget med eventuell etterberegning vil bli tatt med i neste faktura

2.Konsulentbistand

Timepris for konsulentbistand er kr 800 eks mva. Alt arbeid på løpende regning skal være godkjent av Kunden før arbeidet starter. Dokumenterte reiseutgifter belastes Kunden. Vederlag for reisetid beregnes etter medgått tid med timepris kr 400 eks mva.

3.Betalingsbetingelser

Vederlag for Driftsytelsene faktureres forskuddsvis for hvert kvartal. For første kvartal faktureres fra Leveringsdag og til og med utløpet av inneværende kvartal.

Vederlag for konsulentbistand faktureres etterskuddsvis på grunnlag av avtalt og utført arbeid.

All fakturering skjer med 30 dagers forfall.

4.Prisregulering

Priser kan reguleres hvert år med økningen i SSBs konsumprisindeks. Dette kan første gang skje ett år etter signering av Avtalen.

Bilag 5 - Generelle bestemmelser

1.Partenes samarbeid og plikter

Generelt

Partene skal samarbeide for å oppnå en mest mulig effektiv gjennomføring av Avtalen. Begge parter kan skriftlig innkalle den annen til møte med fem Virkedagers varsel for å drøfte forhold som oppstår i forbindelse med gjennomføringen av Avtalen. Partene plikter uten opphold å underrette hverandre om forhold som de forstår eller bør forstå kan ha betydning for gjennomføring av Avtalen. Slik underretning fritar likevel ikke partene for det ansvar som følger av Avtalen.

Leverandørens plikter

Leverandøren plikter å levere avtalte Driftsytelser på de betingelser som fremgår av Avtalen. Leverandøren plikter å allokere nødvendige ressurser for å gjennomføre forpliktelsene i Avtalen.

Kundens plikter

Kunden plikter å betale avtalt vederlag. Kunden plikter å bistå Leverandøren slik at Leverandøren ikke blir forsinket eller på annen måte forhindret i å oppfylle sine forpliktelser. Kunden plikter å allokere nødvendige ressurser, samt sørge for nødvendig bistand fra Tredjepart der dette er avtalt.

2.Konfidensialitet

Partene er gjensidig forpliktet til å bevare taushet og ikke spre informasjon som de får kjennskap til i forbindelse med gjennomføring av Avtalen, i den utstrekning slik informasjon ikke er å betrakte som offentlig kjent. Tilsvarende gjelder alt materiale som er merket med konfidensielt, samt opplysninger om noens personlige forhold, opplysninger som kan skade partene eller som kan utnyttes av utenforstående i næringsvirksomhet. Taushetsplikten gjelder partene og deres ansatte og andre som handler på vegne av partene i forbindelse med gjennomføring av Avtalen. Taushetsplikten gjelder tilsvarende etter opphør av Avtalen.

3.Force majeure

Dersom det skulle inntreffe en ekstraordinær situasjon som ligger utenfor partenes kontroll, som ikke kunne forutses ved avtaleinngåelse og som i vesentlig grad vanskeliggjør oppfyllelse av en parts plikter, skal motparten varsles om dette uten ugrunnet opphold. Den rammede parts forpliktelser suspenderes i den utstrekning som er relevant så lenge den ekstraordinære situasjonen varer. Den annen parts motytelse suspenderes i samme tidsrom. Hver av partene kan si opp Avtalen med en måneds skriftlig varsel dersom force majeure situasjonen gjør det særlig byrdefullt å opprettholde Avtalen.

4.Overdragelse av Avtalen

Partene kan bare overdra sine rettigheter og plikter etter Avtalen med skriftlig samtykke fra den annen part. Samtykke kan ikke nektes uten saklig grunn. Det regnes ikke som overdragelse hvis en av partene slås sammen med ett eller flere andre selskaper eller overdragelsen skjer til et datterselskap. Rett til vederlag etter denne Avtalen kan fritt overdras, men slik overdragelse fritar ikke vedkommende part fra hans forpliktelser og ansvar.

5.Mislighold

5.1 Forsinkelse av Leveringsdag

a. Dagbot

Dersom Leveringsdag ikke forekommer på det tidspunkt som avtalt mellom partene, og dette ikke skyldes forhold som nevnt i pkt. 3 eller forhold Kunden har ansvaret for, begynner en dagbot å løpe fra avtalt Leveringsdag. Dagboten utgjør 0,1 % av det avtalte årlige vederlag for den del av Driftsytelsene som er forsinket, regnet per kalender dag forsinkelsen varer og løper til sammen maksimalt i 60 dager. Så lenge dagboten løper kan Kunden ikke heve Avtalen, kreve prisavslag eller annen erstatning for forsinkelsen.

b. Heving

Dersom Leveringsdag ikke har inntruffet ved utløpet av dagbotperioden, kan Kunden heve Avtalen med øyeblikkelig virkning.

c. Forsinkelse som skyldes Kunden

Ved forsinkelse som skyldes Kunden kan Leverandøren med skriftlig varsel avbryte sitt arbeid inntil Kunden retter opp forholdet. Leverandøren har krav på å få dekket sine merkostnader som følge av Kundens mislighold, samt rimelig tid til omdisponering av ressurser.

5.2 Mislighold i Driftsperioden

5.2.1 Leverandørens mislighold

a. Mangler

Det foreligger en mangel fra Leverandørens side dersom Driftsytelsene ikke dekker de krav og spesifikasjoner som følger av Avtalen, og dette skyldes et forhold som Leverandøren er ansvarlig for. Dersom det foreligger en mangel i Driftsytelsene, skal Leverandøren uten ugrunnet opphold avhjelpe mangelen. Der mangelen ikke kan utbedres innen rimelig tid har Kunden krav på et forholdsmessig prisavslag, ref. pkt. b nedenfor.

b. Prisavslag for mangler

Dersom Kunden ikke har kunnet utnytte Driftsytelsene, helt eller delvis, som en følge av mangelen, har Kunden rett til i perioden fra feilen/mangelen ble skriftlig meddelt Leverandøren og frem til mangelen er rettet, å motta et forholdsmessig prisavslag. Eventuell refusjon som følge av manglende tilgjengelighet for det samme forholdet, kommer til fradrag ved beregning av prisavslag.

c. Heving

Oppstår det forøvrig en mangel som er av en slik art at den har vesentlig betydning for Kundens bruk av Driftsytelsene og mangelen ikke rettes innen 30 Virkedager etter at Kunden skriftlig gjorde Leverandøren oppmerksom på mangelen, kan Kunden skriftlig varsle Leverandøren om at Kunden ønsker å heve Avtalen. Dersom Leverandøren etter et slikt varsel ikke har utbedret forholdet innen 14 Virkedager, har Kunden rett til å heve Avtalen med øyeblikkelig virkning.

5.2.2 Kundens mislighold

Dersom Kunden ikke betaler til avtalt tid, har Leverandøren krav på rente i henhold til lov om renter ved forsinket betaling av 19. des. 1976 nr. 100, § 3, første ledd, av det beløpet som er forfalt til betaling. I de tilfeller der forfalt vederlag med tillegg av renter ikke er betalt innen 14 dager fra forfall, kan Leverandøren sende Kunden skriftlig varsel om at Driftsytelsene vil bli stanset eller at avtalen vil bli hevet, dersom oppgjør ikke har skjedd innen 7 dager etter at Kunden mottok varselet. Ved heving av Avtalen som skyldes Kunden, skal Leverandøren holdes skadesløs av Kunden for de kostnader og forpliktelser som Leverandøren har påtatt seg i forbindelse med Avtalen.

6.Erstatning

Kunden kan kreve erstattet tap som med rimelighet kan tilbakeføres til misligholdet, med mindre Leverandøren kan godtgjøre at misligholdet, eller årsaken til misligholdet, ikke kan tilskrives ham. Eventuell dagbot som følge av forsinkelse i henhold til pkt. 5 a for det samme misligholdet kommer til fradrag ved erstatningsberegningen. Dersom Kunden misligholder sine forpliktelser under denne Avtalen, har Leverandøren krav på å få dekket sine merkostnader som med rimelighet kan tilbakeføres til Kundens mislighold, med mindre Kunden kan godtgjøre at misligholdet, eller årsaken til misligholdet ikke kan tilskrives ham.

Partene er ikke ansvarlige for den annen parts indirekte tap, herunder forventet besparelse eller gevinst. Som indirekte tap inngår blant annet:

Partenes erstatningsplikt overfor hverandre er oppad begrenset til det avtalte årlige vederlaget, eller maksimalt NOK 1 million, uavhengig av antall skadetilfeller. Begrensningene i partenes erstatningsansvar gjelder ikke hvis parten eller noen han har ansvaret for, har utvist grov uaktsomhet eller forsett.

7.Rettsmangler

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 / obtained without charge to the other party. Should it be raised claims from third party against 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.

8. Responsibility for subcontractors

Counterparties are fully accountable for agreed services that are performed by subcontractors.

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 way of transportion and is responsible for transportation from the Vendors's premises. Customer undertakes immediately after termination of the Agreement to return all equipment belonging to the Vendor. The Vendor chooses mode of transport and is responsible for transportation from the Vendor's premisses.

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.

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/Fuction

Telephone

Telefax

E-mail

The vendor

Petter Smart

CEO

+47 22 31 31 31

[mailto:ps@driftselskapet.no ps@driftselskapet.no]

Kunden

<references />