[debian-edu-commits] [Debian Wiki] Update of "DebianEdu/Documentation/en/ITIL" by PetterReinholdtsen
Debian Wiki
debian-www at lists.debian.org
Thu Mar 26 19:21:53 UTC 2015
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Debian Wiki" for change notification.
The "DebianEdu/Documentation/en/ITIL" page has been changed by PetterReinholdtsen:
https://wiki.debian.org/DebianEdu/Documentation/en/ITIL?action=diff&rev1=1&rev2=2
Comment:
Not yet translated.
- = Knowledge sharing for centralised administration =
+ ## page was renamed from DebianEdu/Documentation/ITIL
+ ##master-page:CategoryTemplate
+ ##master-date:Unknown-Date
+ #format wiki
+ #language no
- 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.
+ = ITIL-dokumentasjon for sentralisert drift av Skolelinux og Debian Edu =
- 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.
+ '''Innhold:'''
+ * [[DebianEdu/Documentation/nb/ITIL/Introduction|Innledning]] - Brukerlisens og bakgrunn for dokumentet.
+ * [[DebianEdu/Documentation/nb/ITIL/Support|Servicekontor]] - Dokument som beskriver hvordan IT-tjenesten, driftstjenesten bør jobbe, og viktigheten av ett kontaktpunkt.
+ * [[DebianEdu/Documentation/nb/ITIL/Delivery|Leveranse]] - Dokument som beskriver hva som forventes av en IT-leveranse, både utbygging og drift.
+ * [[DebianEdu/Documentation/nb/ITIL/Infrastructure|Infrastruktur]] - Beskrivelse av hvordan man kan bygge ut IT-løsningen med nettverk, tjenere, klientmaskiner, programvare og netttjenester.
+ * '''Problemløsing''' Utdatert og slettet. Dekket i ny dokumentasjon - Erfaringsbaserte veivisere på hvordan problemer løses ved kjøring av Skolelinux.
+ * '''Konfigurasjonstyring''' Utdatert og slettet. Dekket i ny dokumentasjon - Erfaringsbaserte veivisere på hvordan man kan sette opp Skolelinux ut fra spesielle behov.
+ * [[DebianEdu/Documentation/nb/ITIL/ExtraConfiguration|Ekstra konfigurasjonsstyring]] - Ekstra konfigurasjonstips som oppsett av brannmur osv.
+ * [[DebianEdu/Documentation/nb/ITIL/InfrastructureSetup|Oppsett av infrastruktur]] - med tips om klient-teknologi, kapasitet på datanettet osv.
+ * [[DebianEdu/Documentation/nb/ITIL/UsefulCommands|Nyttige kommandoer]] - Nyttige kommandoer til bruk ved installasjon av pakker mm.
+ * [[DebianEdu/Documentation/nb/ITIL/AppendixA|Vedlegg A]] Avtale om drift av Skolelinux
- = License =
+ Spesialsider: [[DebianEdu/Documentation/nb/ITIL|Innholdslisten]] og [[DebianEdu/Documentation/nb/ITIL/AllInOne|samleside]]
- This document is written under the GNU General Public License version 3. It means that you have:
-
- * The freedom to use the documentation for any purpose (Freedom 0).
- * The freedom to study documentation and adapt it to your needs (Freedom 1).
- * The freedom to forward copies so you can help your neighbor (Freedom 2).
- * The freedom to improve the document and distribute it with your improvements to the public, so that the whole community benefits (Freedom 3).
-
- 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:
-
- * Monica Larssen - Harstad kommune
- * Aksel Celasun - Hurum kommune
- * Trond Mæhlum - Kongsvinger kommune
- * Bjarne Nielsen - Nittedal kommune
- * Stein Lier - Akershus fylkeskommune
-
- 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.
-
- * Remember to be an active listener, not a passive one.
-
- 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.
-
- * ICT contact on each school This is often a teacher with ICT educational and/or technical background.
- * Driftsoperatør(er) som jobber i den sentrale IT-tjenesten. Dette er en fagperson på drift.
- * IKT-koordinator som organiserer den pedagogiske IT-bruken, og bidrar til å lage planer for utbygging, drift og pedagogisk bruk. Ofte er dette en lærer.
- * IKT-ansvarlig. Dette er vanligvis rektor som er ansvarlig for IT-virksomheten.
-
- 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:
-
- * Ha oppsyn med skolens maskinpark.
- * Være skolens kontaktperson mot kommunen - rapportere om feil og mangler.
- * Utføre enkelt vedlikehold eks. bytte mus, tastatur, tynnklient og enkel patching.
- * Være skolens superbruker - kunne veilede kollega med tanke på: brukergrensesnitt, e-post, videokanon og enkelte programmer.
- * Participate in ICT gatherings.
- * Create and administrate local users.
- * Utføre enkelt vedlikehold av skrivere.
- * Opprette og administrere e-postkontoer.
- * Kunne utføre enkle kommandoer og operasjoner under veiledning av IKT-veileder.
- * Legge til rette for bruk av IKT i undervisningen.
-
- Driftsoperatørens arbeidsoppgaver:
-
- * Ta imot hendelser (incidents) og forespørsler (service requests)
- * Veilede IKT-kontaktene på telefon og e-post.
- * Om det er avtalt, oppsøke skolen for utbedring av mangler og feil på datamaskiner, skrivere og server.
- * Sikkerhetskopiering (eng.: backup).
- * Sikkerhetsoppdatering av programvare på skolens maskiner (tjenermaskiner og klientmaskiner).
-
- IKT-koordinators oppgaver:
-
- * Bistå skoleledelsen og IKT-kontakter i utarbeidelse av tekniske og pedagogiske IKT-planer
- * Sørge for at servicekontoret og ledelsen får forespørsler om valg av programvare ol.
- * Bidra til at skolene har riktige IT-verktøy til undervisningen, og at datamaskiner og nettverk er riktig dimensjonert for bruk i skolefagene.
- * Gir råd og veiledning til driftstjenesten om hva som er det tekniske og pedagogiske IT-kravene i skolen.
-
- IT-ansvarliges arbeidsoppgaver (rektor, skoleleder, leder av driftstjenesten):
-
- * Gjøre felles innkjøp av datautstyr og inngå fellesavtaler osv.
- * Utarbeide kompetanseplaner.
- * Tilby skolene kurs i pedagogisk bruk av data.
- * Driftskurs.
- * Forhandle fram driftsavtaler.
- * Sørge for at IT-kontakten og IT-tjenesten har nødvendige ressurser.
-
- 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.
-
- * Få på plass personer i det forskjellige rollene som IT-ansvarlig, IKT-kontakt på skolene, driftsoperatør(er) sentralt, og IT-koordinator for alle skolene. Det er viktig å gjøre et skille mellom hva som er teknisk drift og vedlikehold, og det faglig-pedagogiske arbeidet.
- * Etabler servicekontoret der hver skole har en serviceavtale som regulerer hva som er standard driftsaktiviteter, og hva som er ekstra. Det er avgjørende at IT-ansvarlig rektorer et med i denne prosessen hele veien.
- * Få på plass system for meldingslogging (request tracker). Alle henvendelser på e-post får et saksnummer. Nesten alle henvendelser som brukere eller IT-kontakter på skolene ringer inn får også et saksnummer.
- * Sørg for at IT-budsjettet gjenspeiler den arbeidsinnsatsen som er nødvendig for å sikre forsvarlig drift av skolens datautstyr og nettverk. Kravet i dag er at IT-systemene skal brukes til nasjonale og lokale prøver med bruk av IT-verktøy med eller uten Internett.
- * Bruk i utgangspunktet standard utgave av Skolelinux med samme versjon på alle skolene. Ut fra dette gjøres endringene man ønsker. Disse endringene må man ta vare på i en konfigurasjonsdatabase med dokumentasjon av de endringene som er gjort. Man kan bruke et system for versjonshåndtering for å lagre endringene og dokumentasjonen.
-
- == 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:
-
- * en hendelse som ikke er en del av den normale driften som forårsaker, eller kan forårsake et avbrudd, eller reduksjon i kvaliteten på tjenesten.
-
- Eksempler på driftforstyrrelser kan være:
-
- * Programmer
- * kontorprogrammet (OpenOffice.org) starter ikke
- * nettleseren (Firefox) kræsjer
- * disklageret er fullt
- * Maskinvare
- * tjenermaskinen er nede
- * får ikke skrevet ut
- * får ikke logget inn
- * Henvendelser
- * spørsmål om informasjon, råd eller dokumentasjon
- * glemt passord
-
- 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
-
- * Driftsoperatør som gjør feilretting er den som melder status tilbake til IT-kontakt på skolen og/eller bruker
- * Systemet for logging av hendelser må være på plass slik at det virker både teknisk og funksjonelt for de som jobber med hendelseshåndtering på skolene og på servicekontoret
- * Systemet for hendelseslogging må brukes for så og si alle driftshendelser
- * Ved jevne mellomrom lages statistikk av loggen over hendelser. Statistikken brukes for å sette inn tiltak som fjerner problemer som går igjen, og irriterer brukerne.
-
- === 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:
-
- * Totalt antall driftsforstyrrelser
- * Gjennomsnittlig tid fra man har fått en henvendelse til at problemet er løst, brutt ned på koder (en godt organisert driftsavdeling har koder for hendelser og feiltyper).
- * Prosentvis av hendelser håndtert innen avtalt svartid (avtalt i avtalen om tjenestenivå)
- * Gjennomsnittlig kostnad for hver hendelse
- * Prosentvis av hendelsene løst av hjelpetjenesten uten å gå videre til neste nivå med driftsstøtte
- * Hendelser pr klientmaskin (arbeidsplass)
- * Antall og prosenter av hendelser som løses fra driftsenteret uten behov for besøk på skolen
-
- === Verktøy ===
-
- Det er en rekke verktøy som kan gjøre det enklere å håndtere driftsforstyrrelser.
-
- * Automatisk logging
- * Automatisk dirigering av hendelser til riktige personer
- * Automatisk uthenting av data fra databasen for konfigurasjonsstyring
- * Telefonen og e-post virker enkelt sammen med verktøy for registrering av henvendelser og hendelser.
-
- == 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;'''
-
- * Problemkontroll
- * Feilkontroll
- * Proaktiv kontroll for å hindre problemer
- * Identifisere feilmønstre ved å bruke informasjon fra f.eks. hendelseshåndteringen
-
- '''Problem kontroll'''
-
- * Identifisere problemer
- * Klassifisere problemer
- * Etterforske/Undersøke problemer
-
- '''Feil kontroll'''
-
- * Identifisere og registrere kjente feil
- * Finne midlertidige løsninger om mulig
- * Kontakte de med ansvar for endringsledelse for å få fjernet feilen permanent
-
- '''Proaktiv kontroll'''
-
- * Identifisere og løse problemer og feil før hendelsen blir rapportert av brukere.
- * Bruke logger, informasjon fra hendelseshåndteringen for å se hvor problemer kan oppstå
-
- === 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.
-
- * Identifiser og velg en struktur på konfigurasjonene på de viktige delene av IT-infrastrukturen. Det gjelder også eiere av konfigurasjonen, navnelapper (attributter), avhengigheter, og relasjoner mellom konfigurasjoner.
- * Styringen med konfigurasjonene slik at bare de som er godkjente blir tatt vare på i databasen gjennom levetiden til systemet. Styring over tilgang til konfigurasjonene kan gjøres med gruppetillatelser. Dette kan gjøres gjennom prosessen for endringshåndtering (Change Mangagement).
- * Statuslogging - holder orden på tilstanden og status til de forskjellige delsystemer. Dette gjelder hele levetid til tjenesten, programvaren eller maskinvaren. Det kan være en konfigurasjon er i produksjon, er frakoblet eller avviklet.
- * Sjekking og revisjon. Hver konfigurasjon må sjekkes for å bekrefte at riktig informasjon er lagret i databasen for konfigurasjoner (CMDB). Dette følges opp med periodiske gjennomganger for å sikre at databasen hele tiden er oppdatert.
-
- 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.
-
- * Etabler en versjonshåndtert område for lagring av konfigurasjoner til alle tjenermaskiner og utvalgte arbeidsstasjoner og bærbare. Man kan bruke versjonsystemet subversion til dette. Husk å ta daglig backup av område, og sørg for å lagre alle endringer i konfigurasjonene.
- * Bruk et elektronisk system for å ta vare på oppskrifter som forklarer konfigurasjonene til forskjellig type maskiner, nettverket og tjenester. Slike oppskrifter bidrar til at andre som hjelper eller overtar driften kan lese seg opp på hva som er gjort. En wiki kan være passende til dette.
- * Bruk en bestemt utgave av operativsystem og programvare på alle maskiner. Dette for å unngå å vedlikeholde mange forskjellige utgaver av programvaren. Sørg for at programvaren er godt testet. Derfor kan det være lurt å vente i 6-12 måneder før man tar i bruk nyeste utgave av et program.
-
- === 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:
-
- * Lagring av konfigurasjonsfiler i et system for versjonskontroll, f.eks. subversion
- * Wiki for lagring av dokumentasjon av oppsett og veivisere
- * Bruk av felles katalog for driftsdokumentasjon på Internett vedlikeholdt av de som sentraldrifter Skolelinux på mange skoler
-
- == 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 ===
-
- * Se over endringsmeldingen (RFC) og sjekk at den også har fått et unikt nummer.
- * Prioriter og kategoriser endringer
- * Fjern endringer som ikke er mulige. Dette kan gjøres ved å merke disse som ikke mulig.
- * Gi tilbakemelding til den som gav endringsmeldingen
- * Sørg for at man har en rådgivingsgruppe (eng. Change Advisory Board) der endringen blir tatt opp, diskutert og vurdert. Rådgivningsgruppa kan være utvalgte IT-kontakter og driftspersonell med lang erfaring.
- * Koordiner endringene med den som håndterer forskjellige versjoner av programmer og tjenester (eng. Release Management)
- * Se over og avslutt endringsmeldingen (RFC)
- * Husk å lagre endrede konfigurasjoner i lageret for oppsettfiler
- * Rapporter
-
- 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:
-
- * Desto høyere krav desto strengere blir kravene til de enkelte komponentene. Høye krav til oppetid resulterer også at valgene du står igjen med er gammel teknologi. Det er nemlig erfaringsmateriale over tid som kan si noe om nedetid. Vi har alle lagt merke til hvor lenge etter Red Hat og SuSE ligger på sine serverprodukter.
-
- 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.
-
- * Først gjør man en installasjon av endringene på et testnettverk. Dette er teknisk testing der man forsikrer seg at alt henger sammen på et system uten brukere. Ta vare på alle endringene i oppsettfilene.
- * Når man er sikker på at alt virker på den tekniske siden prøveinstalleres løsningen på en skole. Det er svært viktig å avtale testingen med skolens IT-kontakt. Brukerne må også få full orientering om at det vil bli endringer fordi man utfører testing. Ta vare på aktuelle justeringer i oppsettfiler som er gjort underveis ut fra de driftsmeldingene som har kommet.
- * Når man er sikker på at alt virker kan man rulle ut løsningen til alle skolene. Det gjøres enklest med å lage et skript som forenkler oppgradering av programpakker, tjenester og konfigurasjoner.
-
- === 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:
-
- * Debian-verktøy for sentralt programarkiv
- * Database for konfigurasjoner og maskinvare (subversion for oppsettfiler, regneark med oversikt over all maskinvare med fysisk plassering)
- * System for bygghåndtering
- * Maskinvare for testing og reserveløsning
-
- === 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:
-
- * økte krav fra brukerne
- * mangel på IT-kunnskap
- * budsjettbegrensninger
- * virksomheten er helt avhengig av kvaliteten på tjenesten
- * integrasjon av systemer fra flere leverandører
- * økt kompleksitet i IT-infrastrukturen
- * fremvekst av internasjonale standarder
- * økt omfang og endringer innen IT
-
- Automatiske verktøy tillater:
-
- * sentralisering av nøkkelfunksjoner
- * automatisering av funksjoner i tjenesteleveransen
- * analyse av data
- * identifisering av trender
- * preventive tiltak kan implementeres
-
- === 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:
-
- * Debian-verktøy for sentralt programarkiv
- * Database for konfigurasjoner og maskinvare (subversion for oppsettfiler, regneark med oversikt over all maskinvare med fysisk plassering)
- * System for bygghåndtering
- * Maskinvare for testing og reserveløsning
- * Hendelseslogger (Request Tracker)
- * System for overvåking (Munin)
-
- 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.
-
- * Så det første man spør om er om verktøyet er ønsket.
-
- 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.
-
- * Så her må man spørre om verktøyet er nyttig til å løse oppgaven.
- * Deretter må man spørre om verktøyet er brukbart.
-
- 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):
-
- * Arbeidstakerne og deres tillitsvalgte skal holdes løpende informert om systemer som nyttes ved planlegging og gjennomføring av arbeidet. De skal gis nødvendig opplæring for å sette seg inn i systemene, og de skal medvirke ved utformingen av dem.
-
- 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
- * Økonomistyring
- * Kapasitetshåndtering
- * Kapasitetsplanlegging
- * Tilgjengelighetskontroll
- * Driftskontinuitet
-
- == 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:
-
- * Avtale pr tjeneste for alle kunder
- * Avtale pr kunde for alle tjenester
- * Avtale pr tjeneste pr kunde
-
- 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 ===
-
- * Enighet mellom bruker og driftssenter om hva som faktisk måles. Dette må ses fra brukernes perspektiv og ikke IT-tjenestens perspektiv.
- * Målbarhet og utvetydighet på de måleverdiene som inngår i tjenestenivåavtalen
- * Fastsettelse av realistiske mål for tjenestenivå (det er ingen vits i å love mer enn det man kan holde)
- * Kontinuerlig fokus på kontroll av tjenestenivå - overvåking og periodisk rapportering av oppnådde resultater
-
- === 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
- 1. Regnskapsføring
- 1. 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:
-
- * Overvåkning av ytelsen til IKT-tjenestene med tilhørende infrastruktur
- * Konfigurasjon av systemene for å sikre at de utnyttes optimalt i forhold til det brukerne faktisk gjør
- * Forståelse av brukernes behov og planlegging av eventuelle endringer på systemene for å ivareta fremtidige behov
- * Ressursplanlegging i samarbeid med budsjettansvarlig
- * Utarbeidelse av en kapasitetsplan for å sikre leveranse av driftstjenester i samsvar med avtalt tjenestenivå
-
- Kapasitetsplanlegging handler om å balansere:
-
- * Kostnader mot kapasitet. Budsjettet setter grenser for hva slags løsninger som er mulig å implementere
- * Tilbud og etterspørsel. Systemene må ha kapasitet til å kunne håndtere de krav som stilles av brukerne
-
- 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:
-
- * Prosessorutnyttelse
- * Minneutnyttelse
- * Prosessorbruk pr oppgave
- * Svartider for brukerne pr oppgave
- * Skriverstyring - antall utskrifter, kølengder, utskriftstid
- * Lagringskapasitet
- * Antall klienter
- * Antall pålogginger
- * Antall samtidige brukere
-
- 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:
-
- * Dårlig eller ujevn utnyttelse av maskinvaren
- * Dårlig designet programvare
- * Dårlig utnyttelse av minnekapasitet
- * Flaskehalser på datalagring, minne eller prosessor
- * Bottlenecks in the network
-
- === 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:
-
- * Innledning
- * Forutsetninger
- * Sammendrag
- * Nåværende og fremtidige brukerbehov
- * Tjenestesammendrag
- * Ressurssammendrag
- * Forbedringsområder
- * Kostnadsmodell
- * Anbefaling
-
- == 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 av tekniske komponenter
- * Feiltoleranse
- * Kvalitet på vedlikehold og brukerstøtte
- * Prosedyrer og rutiner for håndtering av driftstjenestene
- * Sikkerhet, integritet og tilgjengelighet av data
-
- 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:
-
- * ''Arbeidstakerne og deres tillitsvalgte skal holdes løpende informert om systemer som nyttes ved planlegging og gjennomføring av arbeidet. De skal gis nødvendig opplæring for å sette seg inn i systemene, og de skal medvirke ved utformingen av dem.''
-
- 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
-
- * Planen til skolene, både fagplaner og virksomhetsplaner
- * Eksisterende IT-strategier
- * Forventningene til driftstjenesten
- * Gjeldende IT-systemer og driftsorganisasjonen
-
- Prosesser
-
- * gå gjennom alle innspill og dokumenter
- * se på andre som utfører design- og planaktiviteter
- * lag og vedlikehold IT-planer og beslutninger
- * lag og vedlikehold IT-arkitekturen
- * lag og vedlikehold IT-strategien
-
- Leveranser
-
- * IT-strategi
- * IT-beslutninger (med begrunnelser)
- * IT-planer
- * the entire IT architecture
- * Design og planlegging av prosesser og prosedyrer
- * organisasjonsstruktur og rammeverk
- * Design og planleggingsstandarder og beslutninger
- * SWOT-analyse (Styrker, Svakheter, Muligheter, Trusler)
- * brukertilfeller og brukbarhetsstudier
- * Kravlister og anbudsdokumenter
- * Project plans
- * Technical drawings, plans and maps
- * Kommentarer og tilbakemeldinger
-
- 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:
-
- * Dreier seg om sammensetting (implementasjon) og utrulling av virksomhet, og /eller IT-løsninger designet og planlagt med et minimum av forstyrrelser for virksomheten.
-
- 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.
-
- * Eier av utrullingsprosessen - er ansvarlig for utrullingsprosessen, og at den skjer på en god og effektiv måte.
- * Prosjektleder for utrullingen - er ansvarlig for utvikling av passende planer for utrulling av IT-løsningen og for å lede utrulling fra dag-til-dag-basis.
- * Koordinator for utrullingen - ansvarlig for koordinering av utrullingsaktiviteter. Koordinator skal sikre at prosjektet når målsetningene og akseptansekrav som gjelder for løsningen, og sikre en ordentlig overlevering.
- * Utrullingsanalytiker - ansvarlig for å sikre at det er passende omgivelser på de stedene som utstyret skal stå. Skal følge opp at utstyret og lokalene passer til de standarder, tester og utrullingen man er enige om.
- * Medarbeidere i utrullingslaget - ansvarlig for at IT-løsningen og arbeidsmiljøet, og støtter for akseptanse- og test-prosessene.
-
- 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:
-
- * Utviklingen av kunnskap for evaluering, støtte og kvalitetssikring av hele gjeldende og fremtidige infrastrukturløsninger.
-
- 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:
-
- * kjøres
- * stenges
- * avsluttes
- * startes
- * avbrytes
- * tas ut
-
- == 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:
-
- * Forskning og utvikling tilknyttet ny teknologi.
- * Tredjelinjeservice for teknisk støtte i tilknytning til hendelsesrapporter fra servicekontoret, og den generelle problemhåndteringen.
- * Leveransestyring - teknisk støtte mangler dybdekunnskap eller forståelse for teknologien som er i bruk, og trenger teknisk støtte fra andre.
- * Sammenheng med design- og planleggingen. Spesielt i forbindelse med støtte og dokumentasjon. F.eks. ved utarbeidelse av anbudsdokumenter.
- * Sammenheng med utrulling ved nye versjoner av systemene, og akseptanse i driftsmiljøet.
- * Analyse, fortolkning, og distribusjon av informasjon fra rapporter og logger.
- * Taktisk sammensetting av forbedringer i kvaliteten av IT-tjenesten som leveres.
-
- = 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
- * Forventninger til IT-verktøy og tjenester
- * Kompetansebehov
- * Investeringer
- * Målsetning
- * Elever og lærere
- * Status og mål
- * Kostnader
- * Andre innkjøpsalternativer
- * Programvare, læringsplattformer, og tjenester
- * Programvare og læringsplattformer
- * Nett-tjenester
- * Ressursbruk
- * Sentralisert drift og roller
- * Drift- og støttekostnader
- * Anbefaling
- * Vedlegg
-
- == 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:
-
- * Få økt bruk av IKT både hos elever og lærere ved å øke den fysiske tilgangen til IKT-utstyr.
- * Være verktøyorientert, og derfor å legge vekten på aktiv bruk av IKT-verktøy i skolefagene.
- * Gi full tilgang til pedagogisk programvare til alt fra musikkforming og bruk av Internett til skrivetrening, simuleringer og spill.
- * Være nøysomme og utnytte de økonomiske ressurser vi har på en best mulig måte.
-
- Gjennom disse hovedmålene vil vi oppnå at:
-
- * Lærerne får et godt arbeidsverktøy og kommunikasjonsredskap i arbeidet.
- * Elevene får mulighet til å bli personlige brukere av IKT og bruke IKT som et naturlig verktøy i skolehverdagen.
- * Skolen blir fysisk i stand til å oppfylle ulike sider ved læreplanen knyttet til IKT.
- * Drifts- og vedlikeholdskostnadene ikke er større enn skolebudsjettet tåler.
-
- == 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.
-
- * Nettverksinfrastruktur med lokalnett (LAN) og områdenett (WAN). For det meste er det enkelt å få tak i svitsjer og annet nettverksutstyr. Dette er hyllevare. Men utstyret må settes opp ut fra den planlagte arkitekturen som er laget for sentralisert drift. Dette er en jobb for fagfolk. Kommunens bygningsavdeling må godkjenne endringene som gjøres.
- * Strømforsyning (230V) til klientmaskiner, tjenermaskiner og nettverksutstyr. Mange skoler har ikke bygd ut stikkontakter til alle datamaskinen som skal plasseres ut i klasserom, på datarom eller i biblioteket. Planlegging av strømnett krever og utbygging av nok stikkontakter er en jobb for fagfolk, og er regulert i forskrifter. Kommunens bygningsavdeling må godkjenne endringene som gjøres.
- * Tjenermaskiner og klientmaskiner som støtter et større utvalg av nett-tjenester og sluttbrukerprogrammer. Å skaffe rett utstyr er en betydelig jobb. Det gjelder å finne passende kapasitet på utstyret, god kvalitet, greie garantiordninger, og lave priser.
- * Maskinoppsett og systemer for overvåking av maskinvare. For å være sikker på at alt utstyret kjører så følger det som regel med systemer for fjernovervåking. På den måten kan man ha oversikt over helsetilstanden til utstyret på et sentralisert driftssenter.
- * Utforming av passende omgivelser eller rom for plassering av utstyr som trenger kjøling. Datamaskiner og nettverkselektronikk avgir betydelig med varme. Først den senere tiden har produsenter av utstyr tatt tak i den stadig økende effektbruken. Derfor må man av og til sørge for transportere vekk overskuddsvarme. Slike kjølesystemer må eventuelt installeres av fagfolk.
- * Kjennskap til forskjellig ytelseskrav til programvaren. Et program til videoredigering må kjøre på en arbeidsstasjon med > 1,5 Ghz prosessor og mye minne. Andre program kan enkelt brukes på en tynnklient. Man må ha relativ god kjennskap til hva som kan forventes av forskjellig type klientmaskiner for å velge riktig miks av utstyr. Dette krever innsikt i hvordan datamaskinene er tenkt brukt i de forskjellige fagene og i det forskjellige rommene på skolen.
- * Installasjon og oppsett av ekstrautstyr som skrivere, videokanoner, datatavler og lignende. Det å sette opp ekstrautstyr kan fort ta betydelig med tid. F.eks. forventes det at videokanoner skal skrus fast i taket, og man må trekke fram både skjermkabler og strøm. Man må ha nettverkspunkt til skrivere, og de må kobles til nettverket. Denne type installasjoner krever som regel fagfolk både til installasjon og oppsett.
-
- I tillegg til de forskjellige fagfolkene som må på plass for å bygge ut infrastrukturen trenger man i tillegg:
-
- * Eier av utrullingsprosessen - er ansvarlig for utrullingsprosessen, og at den skjer på en god og effektiv måte. Dette kan være styringsgruppa.
- * Prosjektleder for utrullingen - er ansvarlig for utvikling av passende planer for utrulling av IT-løsningen og for å lede utrulling fra dag-til-dag-basis.
- * Koordinator for utrullingen - ansvarlig for koordinering av utrullingsaktiviteter. Koordinator skal sikre at prosjektet når målsetningene og akseptansekrav som gjelder for løsningen, og sikre en ordentlig overlevering. Dette kan være en medhjelper til prosjektleder.
- * Utrullingsanalytiker - ansvarlig for å sikre at det er passende omgivelser på de stedene som utstyret skal stå. Skal følge opp at utstyret og lokalene passer til de standarder, tester og utrullingen man er enige om. Dette kan være en medhjelper til prosjektleder, men oppgave å rapportere til styringsgruppa om avvik i forhold til planer.
- * Medarbeidere i utrullingslaget - ansvarlig for at IT-løsningen og arbeidsmiljøet, og støtter for akseptanse- og test-prosessene. Dette er medarbeidere som deltar i ett eller flere delprosjekter.
-
- 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
- 1. 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:
-
- * Tynnklient: 700,- pr. stk
- * Server: ca. 50 000 pr. stk.
- * Skjermer: 500 pr. stk
- * Bærbare maskiner: 8000 pr. stk
- * Strømstikk: 750 pr. stk
- * Bord/stol: 700,-
- * Økt ressurs betyr her økt antall timer til IKT-kontakt på skolene. Her er det regnet en timepris pr. lærer på kr 270,- pr. time, eller kr 467.100,- i året. Det er også regnet inn noe økt ressurs til sentral drift på i kommunen. Vi regner i underkant av en stilling til sentralisert drift av over 1000 klientmaskiner. I tillegg kommer IKT-kontakt på hver skole, opplæring og IKT-koordinator.
- * Lisenskostnader. Vi kan i dag installere Linux på bærbare maskiner da det er laget opplegg for kommunikasjon med skolens eksisterende nettverk. Da unngår vi leie av Microsoft-produkter som Windows og Office. Skolepriser for leie av Microsoft-program koster like mye som alle datamaskinene over en periode på 5-6 år.
- * Bredbåndsavtale, alle skoler har bredbåndstilknytning. Prisen avhenger av den enkelte skoles avtale.
-
- 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:
-
- * Vi må kjøpe Microsoft lisenser i tillegg til maskinene.
- * Maskinene har en levetid på ca. 3 år. Dvs at kommunen får en årlig utgift for å dekke nye klasser på ungdomstrinnet.
- * Økte forsikringskostnader
- * Et større behov for strømstikk da alle bærbare maskiner må ha tilgang til strøm.
- * Økt behov for ressurs til skolenes IKT-kontakt
- * Dobling av sentrale driftskostnader med klargjøring av diskbilder ol. for bærbare maskiner, og vedlikehold av lokalt installert system på 266 ekstra bærbare maskiner.
-
- 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&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 tjenere''''''Nedlåsing av tykke klienter''''''Lokale tjenermaskiner'''||'''Fjerndrift''''''Sentralisering av enkelte funksjoner''''''Lokale tjenermaskiner'''||'''Tjenermaskiner regionalt / nasjonalt''''''Sentralisering 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:
-
- * Konfigurasjonsstyring, dvs. ha oversikt og kontroll på konfigurasjon av maskiner, nettverk, programmer og tjenester
- * Programstyring, dvs. ha oversikt og kontroll på tilgangen til, bruken av og ytelsen til programmer og tjenester
- * Oppdateringer og lapping (eng.: patching)
- * Brukeradministrasjon, gjerne med et FEIDE-kompatibelt brukeradministrasjonssystem (BAS)
- * Lisensadministrasjon
- * Overvåkning og målinger
-
- 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:
-
- * Ha oppsyn med skolens maskinpark.
- * Være skolens kontaktperson mot kommunen - rapportere om feil og mangler.
- * Utføre enkelt vedlikehold eks. bytte mus, tastatur, klientmaskiner og enkel patching.
- * Være skolens superbruker - kunne veilede kollega med tanke på: brukergrensesnitt, e-post, videokanon og enkelte programmer.
- * Participate in ICT gatherings.
- * Create and administrate local users.
- * Utføre enkelt vedlikehold av printere.
- * Opprette og administrere e-postkontoer.
- * Legge til rette for bruk av IKT i undervisningen.
- * Kunne utføre enkle kommandoer og operasjoner under veiledning av IKT-veileder.
-
- 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:
-
- * Veilede IKT-kontaktene på telefon og e-post.
- * Oppsøke skolen for utbedring av mangler og feil på datamaskiner, skrivere og server.
- * Gjøre felles innkjøp av datautstyr og inngå fellesavtaler osv.
- * Sikkerhetskopiering (eng.: backup).
- * Kontinuerlig oppdatering av programvare på skolens servere.
- * Anskaffelse av utstyr og programvare med anbud i markedet.
-
- Kompetanse:
-
- * Utarbeide kompetanseplan.
- * Tilby skolene kurs i pedagogisk bruk av data.
- * Driftskurs.
- * Opplæring av IKT-kontaktene på skolene.
- * Innføring i brukergrensesnitt og standardprogrammer for lærere.
-
- 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:
-
- * Alle aktiviteter og tiltak for å levere og/eller vedlikeholde den ønskede bruken av IT infrastruktur.
-
- 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.
-
- * Fordel: Man oppnår svært høy stabilitet på systemet under forutsetning at man har tilgang til riktige verktøy og riktig kompetanse. Det blir enklere å holde vedlike flere typer datamaskiner fordi man vet om de virker eller faller ut, og kan bytte utstyr som feiler. Ulempe 1: Krever høyere teknisk kompetanse. Gir høyere kostnader ved etablering og daglig drift. Ulempe 2: Proaktiv drift er mer kostbar enn reaktiv drift om man ikke regner inn tap av arbeidstid for utstyr som er defekt. Hva man satser på avhenger av hva konsekvensene er om systemet er nede. Det er vanskelig å regne på tap av undervisning når IT-verktøyene ikke virker. Er man avhengig av at elever og lærere skal ha lite nedetid, må man investere i høy oppetid.
-
- 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*||||
-
- *) Ekstra årsverk til vedlikehold av 266 bærbare datamaskiner
-
- 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,-'''||
-
- *) kr 270,- per lærertime 1730 timer i året. IKT-kontakt på hver skole bruker 75% av tiden på fagligpedagogisk støtte.
-
- 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,-'''||
-
- *) En ekstra stilling til vedlikehold av bærbare datamaskiner.
-
- 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.
-
- * Vanligvis er det bare en eller to personer på en skole med 300 elever og lærere som har behov for opplæring i drift av datasystemene. Dette gjelder både IKT-kontakten på skolen, og driftsoperatør i kommunen.
-
- 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 =
-
- [[Image:https://wiki.debian.org//htdocs/debwiki/img/alert.png|/!\]] 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
-
- * Uavhengig om du velger å Coyote Linux-floppy på en Linux eller Windows-maskin, må følgende konfigurasjon bli burkt. Dette gjelder alle andre firewall/router enn Coyote Linux
- * lokal nettverksgrensesnitt:
-
- <pre> IP adresse (IP Address): 10.0.2.1
- Nettmaske (Netmask): 255.255.254.0
- Kringkasting (Broadcast): 10.0.3.255
- Nettverk (Network): 10.0.2.0</pre>
- * Install the Big Pond login software? [y/n]:n
-
- 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?
-
- * Do you want to enable the Coyote DHCP-server [y/n]: n
-
- Press "n"
-
- * Bruk 10.0.2.2 som en syslog-tjener. Dette er ip-adressen til hovedtjener
-
- 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
-
- Please choose the desired capacity for the created floppy:
- 1) 1.44MB (Safest and most reliable but may lack space needed for
- some options)
- 2) 1.68MB (Good reliability with extra space) - recommended
- 3) 1.72MB (Most space but may not work on all systems or with all
- diskettes)
-
- Enter selection:2</pre>
- Valget som anbefales er «1.68MB»
-
- <pre>b. Please select the type of Internet connection that your system uses.
-
- 1) Standard Ethernet Connection
- 2) PPP over Ethernet Connection
- 3) PPP Dialup Connection\n\nEnter Selection:</pre>
- Her er det best å velge 1)
-
- <pre>c. Configuring system for Ethernet based Internet connection.
- By default, Coyote uses the following settings for the local network
- interface:
-
- IP Address: 192.168.0.1
- Netmask: 255.255.255.0
- Broadcast: 192.168.0.255
- Network: 192.168.0.0
-
- Would you like to change these settings? [Y/N]: y
- Enter local IP Address [192.168.0.1]: 10.0.2.1
- Enter local Netmask [255.255.255.0]: 255.255.254.0
- Enter local Broadcast [192.168.0.255]: 10.0.3.255
- Enter local network number [192.168.0.0]: 10.0.2.0</pre>
- Disse nettverksinstilingene for lokalt nettverk må endres. Se [[#ExtraConfiguration--fwconf|A]]
-
- * Brukes denne utgaven av Coyote Linux fra [http://www.skolelinux.no/~kl%20%20%20%20%20aus/coyote-2.24-slx.tar.gz http://www.skolelinux.no/~klaus/coyote-2.24-slx.tar.gz] vil man se et skjermbilde med korrekte nett-instillinger:
-
- <pre> IP Address: 10.0.2.1
- Netmask: 255.255.254.0
- Broadcast: 10.0.3.255
- Network: 10.0.2.0
-
- e. Does your Internet connection get its IP via DHCP? [y/n]:</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
- Internet IP Address:\nInternet Subnet Mask [255.255.255.0]:
- Internet Broadcast [Enter = Default]:
- Internet Gateway Address:
- Domain Name:
- DNS Server 1:
-
- DNS Server 2 (optional):</pre>
- * Skriv inn DHCP verstsnavn:
-
- Vanligvis kan denne være blank
-
- * Install the Big Pond login software? [y/n]:
-
- 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
- network cards.
-
- If you are using PCI or EISA cards, leave the IO and IRQ lines
- blank.
-
- Enter the module name for you local network card:</pre>
- Dette er den vanskelige delen. Å vite hvilken modul som skal brukes for nettverkskorte er av og til vanskelig. Se på [[#ExtraConfiguration--clmodules|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
- Do you like to configure a different language ? [Y/N]: n</pre>
- 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.
- 1. Vær sikker på at det ikke kommer noen feilmeldinger til ukjente NIC-moduler som dette:
-
- <pre> Checking module deps for (wrong,bad)...
- Copying module: drivers/wrong.o
-
- Unable to copy module (drivers/wrong.o): No such file or directory</pre>
- Vær sikker på at man får noe lignende dette isteden:
-
- <pre> Checking module deps for (e100,3c59x)...
- Module 3c59x dep =
- Module e100 dep =
- Copying module: drivers/e100.o
- Copying module: drivers/3c59x.o</pre>
- === 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'''
-
- * {{attachment:graphics22.png}}
-
- Here you can just press "Next"
-
- '''Figur 3-3. Lokalt nettverksoppsett av LAN'''
-
- * {{attachment:graphics23.png}}
-
- Fyll inn nødvendig informasjon om nettverket her: Se [[#ExtraConfiguration--fwconf|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'''
-
- * {{attachment:graphics24.png}}
-
- Uten dette passordet kan du ikke logge inn på Coyote Linux ved en senere anledning. Se [[#ExtraConfiguration--cllogin|Seksjon 3.6]]
-
- '''Figur 3-5. Syslog-tjener'''
-
- * {{attachment:graphics25.png}}
-
- La feltet stå blankt, eller se på [[#ExtraConfiguration--clsyslog|2.l]]
-
- '''Figur 3-6. Type Internett-tilknytning (WAN)'''
-
- * {{attachment:graphics26.png}}
-
- 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'''
-
- * {{attachment:graphics27.png}}
-
- Har du en fast adresse, fyll ut de passende verdier her.
-
- '''Figur 3-8. Ikke skrup på Coyote Linux DHCP-tjener!'''
-
- * {{attachment:graphics28.png}}
-
- Ikke skru på Coyote Linux DHCP-tjener. Det er allerede en som kjører på [[#ExtraConfiguration--mainserver|hovedtjener]]
-
- '''Figur 3-9. Velg en drivermodul til nettverkskortet (NIC)'''
-
- * {{attachment:graphics29.png}}
-
- 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'''
-
- * {{attachment:graphics30.png}}
-
- Ønsker du å få god støtte på Internett, velge engelsk.
-
- '''Figur 3-11. Lag disken'''
-
- * {{attachment:graphics31.png}}
-
- 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 [[#ExtraConfiguration--makefloppy|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
- 1. 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).
- 1. Logg inn på hovedtjener. Forsøk å bruke '''pinge'''l 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'''.
- 1. 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:
- down</pre>
- 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'''
-
- * {{attachment:graphics35.png}}
-
- 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'''
-
- * {{attachment:graphics37.png}}
-
- 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'''
-
- * {{attachment:graphics38.png}}
-
- Om alt har gått bra vil begge være «oppe»
-
- Q: [[#ExtraConfiguration--AEN698|Det ser ut som network card (LAN) som går til Skolelinux/Debian-edu-nettet ikke virker: DOWN]]
-
- Q: [[#ExtraConfiguration--AEN704|Det ser ut som network card (WAN) som er tilkoblet Internett ikke virker: DOWN]]
-
- Q: [[#ExtraConfiguration--AEN724|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 [[#ExtraConfiguration--fwconf|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å [[#ExtraConfiguration--clconnectiontype|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å [[#ExtraConfiguration--clnicnames|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'''
-
- * {{attachment:graphics42.png}}
-
- Alle valg og innstillinger kan gjøres i Main Menu på venstresiden.
-
- '''Coyote Linux hovedmeny'''
-
- * {{attachment:graphics43.png}}
- * Informasjon
-
- Å velge denne gir status for network card-er, IP-adressene som er på plass, oppetid til Coyote Linux, lst og lignende.
-
- * LAN oppsett
-
- 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 [[#ExtraConfiguration--fwconf|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>
-
- * Internett oppsett
-
- 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 [[#ExtraConfiguration--clconnectiontype|2.b]]
-
- * DHCP oppsett. Varsel: Ikke sett opp DCHP-tjener i Coyote Linux!
-
- Dette gir muligheten til å sette opp DHCP-tjener som en del av Coyote Linux
-
- * Administrative innstillinger
-
- Her kan man skru på og av tjenester som navnetjener (DNS), ssh og vev-admin.
-
- * Port Forwarding
-
- 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.
-
- * Forenklet oppsett av brannmur
-
- 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.
-
- * Avansert brannmuroppsett
- * QOS oppsett
-
- Her kan man sette opp begrensninger på nettkapasiteten
-
- * Systempassord
-
- Her kan man endre root-passordet Coyote Linux, også kjent som system-passordet. Dette er på samme måte som å bruke kommandolinja [[#ExtraConfiguration--cllogin|Seksjon 3.6]].
-
- * Konfigurasjonsfiler
-
- Dette er filer som inneholder alle innstillinger.
-
- * Diagnoseverktøy
-
- Her finner man nyttige verktøy som ping, testing av porter (gateway), testing av navnetjener (DNS), og status for nettverket.
-
- * Backup nå
-
- 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.
-
- * Omstart av systemet
-
- 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?'''
-
- * {{attachment:graphics47.png}}
-
- === 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'''
-
- * Husk å svar «Yes» på spørsmålet «Do you want to enable the Coyote DHCP-server [y/n]:»
- * Straks en DHCP-tjener kjører på Coyote Linux, må man sannsynligvis bruke en annen adresse å logge på den, om man ikke endret noe på LAN-oppsettet:
-
- <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 [[#ExtraConfiguration--clgui|Seksjon 3.7]] og
-
- '''Ny adresse i dette tilfellet er:'''
-
- * ssh -l root 192.168.0.1
- * [http://192.168.0.1:8180/ http://192.168.0.1:8180]
-
- === 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
-
- * Nextgentel, Norway
- * Tele2 ADSL Privat, Norway
- * Tele2 ADSL Bedrift, Norway
- * UPC Chello Classis, Norway
- * Utdanningsetaten i Oslo (The Department of Education). Ikke testet på skoler koblet til Simens sin InnsIKT-løsning for Oslo-skolene
-
- Grunnet anderledes nettverkspolitikk på Utdanningsetaten i Oslo ''må'' man gjøre følgende endringer på [[#ExtraConfiguration--mainserver|hovedtjeneren]]:
-
- Endre følgende i filen <code>/etc/bind/named.conf</code> [[#ExtraConfiguration--FTN.AEN983|[5]]]
-
- <pre> // forwarders {
- // By special request from the good people inside the Dept of Education in
- // Oslo:
- // 193.156.192.40;
- // 193.156.192.50;
- // Dept. of Education in Oslo end of block
- // 0.0.0.0;
- // };</pre>
- endre dette til
-
- <pre> forwarders {
- // By special request from the good people inside the Dept of Education in
- // Oslo:
- 193.156.192.40;
- 193.156.192.50;
- // Dept. of Education in Oslo end of block
- // 0.0.0.0;
- };</pre>
- 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'''
-
- * Telenor ADSL, Norway
- * Høgskolen i Oslo (Oslo College)
-
- 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.
- 1. 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.
- 1. 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
-
- * [http://www.coyotelinux.com/ Coyote Linux hjemmeside]
- * [http://www.vortech.net/phorums/list.php?8 Coyote Linux brukerforum, høy aktivitet]
- * [http://www.coyotelinux.com/faq Coyote Linux, FAQ, velg 2.x - General]
- * [http://rzero.com/coyote/faq.html En annen FAQ av Todd VerBeek]
-
- === 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>{{attachment:bilder50.png}}</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
-
- * {{attachment:bilder51.png}}
-
- 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 [[#InfrastructureSetup--workstationprofile|arbeidsstasjon]]-profilen eller [[#InfrastructureSetup--workstationprofile|tynnklienttjener]] [[#InfrastructureSetup--FTN.AEN1198|[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å [[#InfrastructureSetup--mainserverprofile|hovedtjeneren]]. Dokumenter, personlige innstillinger og mange nett-tjenester ligger på [[#InfrastructureSetup--mainserverprofile|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 [[#InfrastructureSetup--workstationprofile|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å [[#InfrastructureSetup--workstation|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 [[#InfrastructureSetup--workstationprofile|arbeidsstasjon]]-profilen. Profilene hovedtjener, arbeidsstasjon og tynnklienttjener kan installeres på en og samme maskin.
-
- * Denne profilen inneholder også [[#InfrastructureSetup--workstation|arbeidsstasjon]]-profilen
- * Hovedtjener + tynnklienttjener (med arbeidsstasjon inkludert)
-
- Denne kombinasjonen av profiler, også kalt kombi-profilen, gir muligheten til å sette opp komplette Skolelinux/Debian-edu-nettverk med [[#InfrastructureSetup--workstation|arbeidsstasjoner]] og [[#InfrastructureSetup--thinclient|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 '''tynnklienter'''er 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 multimedia'''Ulempe:''' 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 passe'''Ulempe:''' 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 <-- 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å [[#UsefulCommands--apt-get|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 [[#UsefulCommands--shell|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:
- kernel-image-2.6.8-2-686-smp
- Suggested packages:
- lilo kernel-doc-2.6.8 kernel-source-2.6.8
- Recommended packages:
- irqbalance
- The following NEW packages will be installed:
- kernel-image-2.6-686-smp kernel-image-2.6.8-2-686-smp
- 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
- Need to get 15.3MB of archives.
- After unpacking 44.9MB of additional disk space will be used.
- Do you want to continue? [Y/n]
- Get:1 http://ftp.debian.org sarge/main kernel-image-2.6.8-2-686-smp 2.6.8-16 [15.3MB]
- Get:2 http://ftp.debian.org sarge/main kernel-image-2.6-686-smp 101 [2154B]
- Fetched 15.3MB in 1m13s (208kB/s)
- Selecting previously deselected package kernel-image-2.6.8-2-686-smp.
- (Reading database ... 80762 files and directories currently installed.)
- Unpacking kernel-image-2.6.8-2-686-smp (from .../kernel-image-2.6.8-2-686-smp_2.6.8-16_i386.deb) ...
- Selecting previously deselected package kernel-image-2.6-686-smp.
- Unpacking kernel-image-2.6-686-smp (from .../kernel-image-2.6-686-smp_101_i386.deb) ...
- Setting up kernel-image-2.6.8-2-686-smp (2.6.8-16) ...
- File descriptor 3 left open
- File descriptor 4 left open
- File descriptor 5 left open
- File descriptor 6 left open
- File descriptor 7 left open
- Finding all volume groups
- Finding volume group "vg_data"
- Finding volume group "vg_system"
- Searching for GRUB installation directory ... found: /boot/grub .
- Testing for an existing GRUB menu.list file... found: /boot/grub/menu.lst .
- Searching for splash image... none found, skipping...
- Found kernel: /boot/vmlinuz-2.6.8-2-686-smp
- Found kernel: /boot/vmlinuz-2.6.8-2-386
- Updating /boot/grub/menu.lst ... done
- Setting up kernel-image-2.6-686-smp (101) ...</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
- total used free shared buffers cached
- 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 [[#UsefulCommands--kpackage|7]] eller Webmin [[#UsefulCommands--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
- 1. http based apt source: ----------------
- 1. deb http://ftp.debian.org/debian/ sarge main contrib non-free
- 1. deb http://non-us.debian.org/debian-non-US/ sarge/non-US main contrib non-free
- 1. deb http://ftp.skolelinux.no/skolelinux/ sarge local
- 1. ftp based apt source: -----------------
- 1. deb ftp://ftp.debian.org/debian/ sarge main contrib non-free
- 1. deb ftp://non-us.debian.org/debian-non-US/ sarge/non-US main contrib non-free
- 1. deb ftp://ftp.skolelinux.no/skolelinux/ sarge local</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
-
- 1.deb cdrom:[Debian GNU/Linux edu _Sarge_ - Unofficial i386 Binary-1 (20050808)]/ unstable contrib lo
- cal main non-free
-
- 1.deb http://security.debian.org/ stable/updates main contrib non-free
- deb http://security.debian.org/ sarge/updates main contrib non-free
- 1. Use (by uncommenting) either http or ftp, NOT both
- 1. http based apt source: ----------------
- deb http://ftp.debian.org/debian/ sarge main contrib non-free
- deb http://non-us.debian.org/debian-non-US/ sarge/non-US main contrib non-free
- deb http://ftp.skolelinux.no/skolelinux/ sarge local
- 1. ftp based apt source: -----------------
- 1. deb ftp://ftp.debian.org/debian/ sarge main contrib non-free
- 1. deb ftp://non-us.debian.org/debian-non-US/ sarge/non-US main contrib non-free
- 1. deb ftp://ftp.skolelinux.no/skolelinux/ sarge local</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 [[#UsefulCommands--sources.list|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:
- apache apache-common apache2-utils bsdutils cfengine cfengine-doc courier-authdaemon courier-base courier-imap courier-imap-ssl courier-ldap
- courier-ssl cpio debian-edu-config debian-edu-install education-common education-main-server education-networked education-tasks libapr0 libice6
- libmysqlclient12 libpam-ldap libpcre3 libsensors3 libsm6 libsnmp-base libsnmp5 libssl0.9.7 libungif4g libx11-6 libxext6 libxft1 libxi6 libxmu6 libxmuu1
- libxp6 libxpm4 libxrandr2 libxt6 libxtrap6 libxtst6 localization-config lynx mount mysql-common ntp ntp-refclock ntp-server ntpdate openssl python2.3
- slbackup snmp squid squid-common tcpdump util-linux xdebconfigurator xfree86-common xlibs xlibs-data
- 62 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
- Need to get 23.7MB of archives.
- After unpacking 225kB disk space will be freed.
- Do you want to continue? [Y/n]</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
-
- * Rebuilt against libvorbis0a (closes: #184713).
- * Removed alpha compile flags.
- * Fresh admin/ sync.
-
- -- Ben Burton <bab at debian.org> Sun, 16 Mar 2003 16:00:19 +1100
-
- kdeaddons (4:3.1.0-2) unstable; urgency=low
-
- * First KDE3 upload to debian!
- * Applied Ewald Snel's patch for xine support.
- * Rolled the epoch to aid upgrades from the unofficial repository on
- ftp.kde.org.. *sigh*</pre>
- Bruk '''Mellomrom''' på tastaturet for å rulle gjennom meldingen. Da vil du se
-
- <pre>quanta (1:3.0pr1-1) unstable; urgency=low
-
- * New upstream release.
- * Built for KDE3.
-
- -- Ben Burton <benb at acm.org> Wed, 4 Sep 2002 10:36:12 +1000
-
- (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:
- Installed: (none)
- Candidate: 0.3.8-1
- Version Table:
- 0.3.8-1 0
- 500 http://ftp.debian.org sarge/main Packages</pre>
- 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:
- aterm
- 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
- Inst aterm (0.4.2-11 Debian:3.1r0/stable)
- Conf aterm (0.4.2-11 Debian:3.1r0/stable)
- tjener:~# apt-get install aterm
- Reading Package Lists... Done
- Building Dependency Tree... Done
- The following NEW packages will be installed:
- aterm
- 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
- Need to get 91.6kB of archives.
- After unpacking 287kB of additional disk space will be used.
- Get:1 http://ftp.debian.org sarge/main aterm 0.4.2-11 [91.6kB]
- Fetched 91.6kB in 1s (71.0kB/s)
- Selecting previously deselected package aterm.
- (Reading database ... 32924 files and directories currently installed.)
- Unpacking aterm (from .../aterm_0.4.2-11_i386.deb) ...
- Setting up aterm (0.4.2-11) ... </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:
- aterm
- 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
- Remv aterm (0.4.2-11 Debian:3.1r0/stable)
- tjener:~# apt-get remove aterm
- Reading Package Lists... Done
- Building Dependency Tree... Done
- The following packages will be REMOVED:
- aterm
- 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
- Need to get 0B of archives.
- After unpacking 287kB disk space will be freed.
- Do you want to continue? [Y/n]
- (Reading database ... 32936 files and directories currently installed.)
- Removing aterm ...</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:
- Installed: 0.0.10-1
- Candidate: 0.0.10-1
- Version Table:
- *** 0.0.10-1 0
- 500 http://ftp.skolelinux.no sarge/local Packages
- 100 /var/lib/dpkg/status
- 0.0.9-1 0
- 500 http://ftp.debian.org sarge/main Packages</pre>
- 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:
- webmin-slbackup
- 0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
- Inst webmin-slbackup [0.0.10-1] (0.0.9-1 Debian:3.1r0/stable)
- Conf webmin-slbackup (0.0.9-1 Debian:3.1r0/stable)
- tjener:~# apt-get install webmin-slbackup=0.0.9-1
- Reading Package Lists... Done
- Building Dependency Tree... Done
- The following packages will be DOWNGRADED:
- webmin-slbackup
- 0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
- Need to get 22.0kB of archives.
- After unpacking 131kB of additional disk space will be used.
- Do you want to continue? [Y/n]
- Get:1 http://ftp.debian.org sarge/main webmin-slbackup 0.0.9-1 [22.0kB]
- Fetched 22.0kB in 0s (23.6kB/s)
- dpkg - warning: downgrading webmin-slbackup from 0.0.10-1 to 0.0.9-1.
- (Reading database ... 32924 files and directories currently installed.)
- Preparing to replace webmin-slbackup 0.0.10-1 (using .../webmin-slbackup_0.0.9-1_all.deb) ...
- Unpacking replacement webmin-slbackup ...
- Setting up webmin-slbackup (0.0.9-1) ...</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:
- opera depends on libqt3c102-mt; however:
- Package libqt3c102-mt is not installed.
- dpkg: error processing opera (--install):
- dependency problems - leaving unconfigured
- Errors were encountered while processing:
- opera</pre>
- 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:
- libaudio2 liblcms1 libmng1 libqt3c102-mt libxcursor1 libxft2
- Suggested packages:
- nas liblcms-utils libqt3c102-mt-psql libqt3c102-mt-mysql libqt3c102-mt-odbc
- The following NEW packages will be installed:
- libaudio2 liblcms1 libmng1 libqt3c102-mt libxcursor1 libxft2
- 0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
- 1 not fully installed or removed.
- Inst libaudio2 (1.7-2 Debian:3.1r0/stable) [opera ]
- Inst liblcms1 (1.13-1 Debian:3.1r0/stable) [opera ]
- Inst libmng1 (1.0.8-1 Debian:3.1r0/stable) [opera ]
- Inst libxcursor1 (1.1.3-1 Debian:3.1r0/stable) [opera ]
- Inst libxft2 (2.1.7-1 Debian:3.1r0/stable) [opera ]
- Inst libqt3c102-mt (3:3.3.4-3 Debian:3.1r0/stable)
- Conf libaudio2 (1.7-2 Debian:3.1r0/stable)
- Conf liblcms1 (1.13-1 Debian:3.1r0/stable)
- Conf libmng1 (1.0.8-1 Debian:3.1r0/stable)
- Conf libxcursor1 (1.1.3-1 Debian:3.1r0/stable)
- Conf libxft2 (2.1.7-1 Debian:3.1r0/stable)
- Conf libqt3c102-mt (3:3.3.4-3 Debian:3.1r0/stable)
- Conf opera (8.51-20051114.5 )
- tjener:~# apt-get install --fix-broken
- Reading Package Lists... Done
- Building Dependency Tree... Done
- Correcting dependencies... Done
- The following extra packages will be installed:
- libaudio2 liblcms1 libmng1 libqt3c102-mt libxcursor1 libxft2
- Suggested packages:
- nas liblcms-utils libqt3c102-mt-psql libqt3c102-mt-mysql libqt3c102-mt-odbc
- The following NEW packages will be installed:
- libaudio2 liblcms1 libmng1 libqt3c102-mt libxcursor1 libxft2
- 0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
- 1 not fully installed or removed.
- Need to get 3489kB of archives.
- After unpacking 8753kB of additional disk space will be used.
- Do you want to continue? [Y/n]
- Get:1 http://ftp.debian.org sarge/main libaudio2 1.7-2 [71.5kB]
- Get:2 http://ftp.debian.org sarge/main liblcms1 1.13-1 [123kB]
- Get:3 http://ftp.debian.org sarge/main libmng1 1.0.8-1 [171kB]
- Get:4 http://ftp.debian.org sarge/main libxcursor1 1.1.3-1 [23.7kB]
- Get:5 http://ftp.debian.org sarge/main libxft2 2.1.7-1 [54.4kB]
- Get:6 http://ftp.debian.org sarge/main libqt3c102-mt 3:3.3.4-3 [3045kB]
- Fetched 3489kB in 16s (212kB/s)
- Selecting previously deselected package libaudio2.
- (Reading database ... 33027 files and directories currently installed.)
- Unpacking libaudio2 (from .../libaudio2_1.7-2_i386.deb) ...
- Selecting previously deselected package liblcms1.
- Unpacking liblcms1 (from .../liblcms1_1.13-1_i386.deb) ...
- Selecting previously deselected package libmng1.
- Unpacking libmng1 (from .../libmng1_1.0.8-1_i386.deb) ...
- Selecting previously deselected package libxcursor1.
- Unpacking libxcursor1 (from .../libxcursor1_1.1.3-1_i386.deb) ...
- Selecting previously deselected package libxft2.
- Unpacking libxft2 (from .../libxft2_2.1.7-1_i386.deb) ...
- Selecting previously deselected package libqt3c102-mt.
- Unpacking libqt3c102-mt (from .../libqt3c102-mt_3%3a3.3.4-3_i386.deb) ...
- Setting up libaudio2 (1.7-2) ...
-
- Setting up liblcms1 (1.13-1) ...
-
- Setting up libmng1 (1.0.8-1) ...
-
- Setting up libxcursor1 (1.1.3-1) ...
-
- Setting up libxft2 (2.1.7-1) ...
-
- Setting up libqt3c102-mt (3.3.4-3) ...
-
- Setting up opera (8.51-20051114.5) ...</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:
- Installed: 8.51-20051114.5
- Candidate: 8.51-20051114.5
- Version Table:
- *** 8.51-20051114.5 0
- 100 /var/lib/dpkg/status
- tjener:~# dpkg --list|grep opera</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 [[#UsefulCommands--clguishow|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
-
-
- 1) Edit main configuration file 2) Change system password
- 3) Edit rc.local script file 4) Custom firewall rules file
- 5) Edit firewall configuration 6) Edit port forward configuration
-
- c) Show running configuration f) Reload firewall
- r) Reboot system w) Write configuration to disk
-
- q) quit e) Exit
- ----------------------------------------------------------------------------
- Selection:</pre>
- Man vil ha omtrent samme valg som når man er logget inn på Coyote Linux med vev-administrasjon. Se [[#UsefulCommands--clgui|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 at 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'''
-
- * ping
-
- 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>
- * uptime
-
- 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>
- * dmesg
-
- 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'''
-
- * ifconfig
-
- Viser ekstra informasjon om network cardene.
-
- <pre>coyote# ifconfig
- eth0 Link encap:Ethernet HWaddr 00:50:FC:F8:D2:44
- inet addr:10.0.2.1 Bcast:10.0.3.255 Mask:255.255.254.0
- UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
- RX packets:314723 errors:0 dropped:0 overruns:0 frame:0
- TX packets:312105 errors:0 dropped:0 overruns:0 carrier:0
- collisions:0 txqueuelen:1000
- RX bytes:53700845 (51.2 MiB) TX bytes:277496136 (264.6 MiB)
- Interrupt:11 Base address:0x7000
-
- eth1 Link encap:Ethernet HWaddr 00:E0:18:A8:B1:BA
- inet addr:192.168.100.133 Bcast:192.168.100.255 Mask:255.255.255.0
- UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
- RX packets:307395 errors:0 dropped:0 overruns:0 frame:0
- TX packets:281202 errors:0 dropped:0 overruns:0 carrier:0
- collisions:0 txqueuelen:1000
- RX bytes:272404311 (259.7 MiB) TX bytes:47880640 (45.6 MiB)
- Interrupt:10 Base address:0xb800 Memory:e3000000-e3000038
-
- lo Link encap:Local Loopback
- inet addr:127.0.0.1 Mask:255.0.0.0
- UP LOOPBACK RUNNING MTU:16436 Metric:1
- RX packets:14565 errors:0 dropped:0 overruns:0 frame:0
- TX packets:14565 errors:0 dropped:0 overruns:0 carrier:0
- collisions:0 txqueuelen:0
- RX bytes:1290756 (1.2 MiB) TX bytes:1290756 (1.2 MiB)</pre>
- * lsmod
-
- 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 [[#UsefulCommands--clmodules|Seksjon 3.12]]
-
- * route
- * traceroute
-
- Er nyttig for å finne hvor Internett-pakker tar veien. Ved eventuelle problemer er det kjent å se hvor Internett-pakkene tar veien.
-
- * showcfg
-
- 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>
- * free
-
- 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 used free shared buffers
- Mem: 30860 6004 24856 0 0
- Swap: 0 0 0
- Total: 30860 6004 24856</pre>
- * menu
-
- This commands starts the Coyote Linux Menu
-
- <pre> Coyote Linux Gateway -- Configuration Menu
-
-
- 1) Edit main configuration file 2) Change system password
- 3) Edit rc.local script file 4) Custom firewall rules file
- 5) Edit firewall configuration 6) Edit port forward configuration
-
- c) Show running configuration f) Reload firewall
- r) Reboot system w) Write configuration to disk</pre>
- 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>
- * reboot
-
- coyote#reboot
-
- Denne kommandoen gjør en omstart av Coyote Linux
-
- * shutdown
-
- 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:
-
- * Bilag 1 - Definisjoner
- * Bilag 2 - Kundens forpliktelser
- * Bilag 3 - Leverandørens forpliktelser
- * Bilag 4 - Priser og betalingsbetingelser
- * Bilag 5 - Generelle bestemmelser
- * Bilag 6 - Fullmaktspersoner
-
- 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:
-
- * Tap som følge av minsket eller bortfalt produksjon eller omsetning (driftsavbrudd);
- * Tap som følge av at driftsytelsene ikke kan benyttes som forutsatt (avsavn);
- * Tapt fortjeneste som følge av at en kontrakt med tredjemann faller bort eller ikke blir riktig oppfylt.
-
- 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 at driftselskapet.no ps at driftselskapet.no]||
- ||Kunden||||||||||
-
- <references />
-
More information about the debian-edu-commits
mailing list