Forbedret tynnklientdrift med Skolelinux

Som dere alle vet har det pågått en del diskusjon i forhold til båndbreddekrav som følger med LTSP (Linux Terminal Server Project). Spesielt Roger Larsen i Fronter har stått på siden vårt møte 23. desember 2002. Selv om LTSP i dag er en stor suksess på skoler i hele Norge ønsker Utdanningsetaten i Oslo å legge til litt mer funksjonalitet. Utdannings- og forskningsdepartementet forventer at løsningene man kommer fram til kommer hele utdanningsnorge til gode. For SLX Debian Labs løses dette ved å bruke en brukervennlig lisens (GPL) på programvare og dokumentasjon av løsningene. Det blir tillagt stor vekt å få fram god praksis som gir overføringsverdi¹ sier Departementet om videreføring av Skolelinux-prosjektet den 24. september 2002. Hva som forventes er dokumentert først på en halv side.

Forventninger

Utdanningsetaten i Oslo har gjennom konseptet InnsIKT et stort ønske om å bruke tjenermaskiner plassert på et sentralt driftssenter. I dag har de en suboptimal løsning hvor skoler har plassert 1-2 tjenermaskiner med Windows server. Herfra får elevene filområd for arbeidsstasjoner, enkelte nett-tjenester, autentisering gjennom MS Active Directory pluss noe annet. Dette skyldes at skolene har båndbredde mellom 2-8 Mbps. Økes hastigheten på bredbåndet, vil kostnadene fort overstige hva det koster å drifte hele IKT-løsningen i Oslo-skolen. For å beholde mest mulig av InnsIKT-arkitekturen og gjenbruke maskinvare er ideen å redusere kravet til båndbredde mellom tynnklientene og Skolelinux applikassjonstjener, også kjent som tynnklient-tjener. Dette kan gjøres med NX fra NoMachine, også kjent som FreeNX, eller med Lessdisk. Det finnes også kombinasjonsløsninger.

Dette er en del av oppdraget som kommer direkte fra bystyret som har spurt SLX Debian Labs om å skrive en prosjektsøknad². Saken har gått til byråden for utdanning i Oslo kommune, og deretter er saken sendt til administrasjonen som i dette tilfellet er Utdaningsetaten i Oslo. Bystyret har også følgende vedtak fra 21. mai 2003³: Komiteen vil be byrådet stimulere flere skoler til å ta i bruk LINUX. Byråden bør bruke erfaringene fra blant annet Bjerke Videregående skole og Holmlia ungdomsskole som inspirasjon for å få flere til å bruke LINUX som datasystem.

Forventningene til Siemens Business Solution og Utdanningsetaten (SBS) i Oslo er at man har noen å henvende seg til for sikkerhetsoppgraderinger, vedlikehold, og nye versjoner av Skolelinux. SBS bruker samme argumentene som f.eks. Utdannings- og forskningsdepartementet som sier: «man må også være sikre på at leveranseevnen er på plass om prosjektdeltakere skulle havne i en ny livssituasjon.» sier Departementet, og det fortsetter: «Det viktigste for Departementet er om man kan anbefale Skolelinux fra den organisatoriske siden.»⁴

Departementet etterlyser en slags administrasjonsrolle hvor man kan henvende seg og plassere ansvar. Dette en rolle som kan huke inn aktører, og har langt tidsperspektiv framover. Man bør også sikre en fysisk og organisatorisk samlokalisering. En slags "driftsorganisasjon" for videreføring av Skolelinux i fem år.

Forventing til økonomisk gevinst er uttrykt i prosjektrapporten fra SLX Debian Labs skrevet på spørsmål fra bystyret i Oslo⁵. SkoleLinux-prosjektet viser at det å drifte systemet kommer på 533 kroner per bruker, redusert til 360 kroner per bruker når systemet er fullt utbygd. Det Windows-baserte alternativet koster i dag rundt 1.000 kroner per bruker, men vil komme ned i 750 kroner fullt utbygget, sier ikt-direktør Bjørn Marthinsen i Oslo kommune Utdanningsetaten⁶. I følge Utdanningsetatens budsjettforslag for InnsIKT i 2003, vil det årlig koste over 211 millioner i årlig drift av en fullt utbygd InnsIKT-løsning basert på Windows. Med tallene etaten gir i pressen er det snakk om over 50 millioner i eksterne drifttjenester. Skolelinux har vist at dette beløpet kan reduseres til 25 millioner ved bruk av Skolelinux. Trolig kan man hente ut større beløp i besparelser ved å gjøre grep på tynnklientene. Det er rom for å redusere behovet for båndbredde lokalt, og utnytte tynnklientens prosessor som halvtynne klienter.

Problemet

1. LTSP i Skolelinux må vedlikeholdes i hennhold til Debian security policy⁷. Vi er ikke helt der i dag selv om sikkerhetsteamet i Skolelinux har nøvendig oversikt⁸. I dag har man pakket om rpm-pakker fra RedHat, og tilrettelagt dette for Skolelinux. Målet er å få debian-pakker. Til nå er det Ragnar Wisløff som i all hovedsak som har gjort repakketering. Også Linpros Rune Skillingstad, og Finn-Arne Johansen har gitt gode bidrag + Petter Reinholdtsen (har sikkert glemt noen). http://www.ltsp.org/ltsp-4.1.html

2. Båndbreddekravet til klienten kan reduseres⁹. Noen kommuner ønsker å plassere applikasjonstjenere sentralt framfor å få full effekt av maskinvaren gjennom tynnklienttjenere som «sorte bokser». På samme måte som med Citrix vil dette redusere muligheten for medierike program på klienten som bygger på flash og Java. NX-teknologi¹⁰ støttes både i KDE-miljøet og på andre måter.

3. Halvtykke klienter kan maksimere og støtte medierike applikasjoner som Java, Macromedia Flash og video. Dette kan gjøres med LTSP-opplegget, eller med Lessdisk som bl.a Jonas Smedegaard <dr@jones.dk> holder på med.

Aktuelle løsninger

• Om anslag: Begrepet anslag betyr vurdering eller overslag på godt norsk (Kilde: Bokmålsordboka). Dette er noe man setter opp fordi det er feil i utgangspunktet. Dette er i motsetning til estimat som betyr: resultat som er framkommet ved sannsynlighetsberegning.

• Om estimat: Når vi oversetter f.eks. OpenOffice har vi erfaringstall å bygge på gjennom ukerapporter. Da kan man lage svært nøyaktige estimat for hvor mye arbeid som gjenstår. Siden vi har oversatt OpenOffice med ukerapportering siden sommeren 2002, vet vi hva som gjenstår ut fra mengde tekst.

• Om anslaget i forhold til LTSP (alternativ 0): 250t = 6 uker. Ikke bare skal man pakke systemet som Debian-pakke. Man skal også bruke tid på repakking og testing av systemet ved nye utgaver. Skal en stor driftsorganisasjon som Oslo kommune bruke løsningen, må den vedlikeholdes når det kommer sikkerhetsfikser eller nye utgaver av kernel og X-tjenere osv. Med andre ord snakker vi både om tilpasning og vedlikehold. Kanskje 250 timer årlig for mye? Siden et anslag er et overslag, så vil man gjennom estimering få et bedre tall.

• Anslaget knyttet til Lessdisk (alternativ 3) er tanken følgende. Det tar 250 timer å pakke løsningen. 450 timer går med til testing slik at alt fungerer 100%. 450 timer går med til vedlikehold ved sikkerhetsfikser og nye versjoner. Samlet sett er dette 350 timer mer enn estimatet for å gjøre selve jobben. Finn-Arne haddet et anslag på 800t for å få en produksjonsklar utgave av Lessdisk. Så skal den vedlikeholdes.

Utviklingsestimering

• Hvor mye tid har du allerede brukt på din innsats. Du må regne inn all tid og gange med 2 (tid brukt x 2 = sannsynlig tidsbruk). Systemutviklere driver notorisk underbudsjettering på en faktor på 3 til 5.

• Du må legge til samme tid som brukes på tilpasning/utvikling på testing

• Du må legge til samme tid som du bruker på testing til pakking og dokumentasjon

• Man må belage seg på at 1/4-1/3 av totalttiden går med til administrasjon, ledelse og tilfeldigheter.

• Vi er ikke ferdig her. 80% av IT-kostnadene går til vedlikehold. Derfor må også dette regnes inn.

Kort oppsummering med tidsanslag ved utvikling: Man tar det man tror man har gjort og ganger med 2. Dette tallet ganger du med pi (π) <URL: http://en.wikipedia.org/wiki/Pi>

Vedlikeholdsestimering

• Når du har utviklet løsningen må du bruke 1/3 av total utviklingtid på ny utgave av systemet. Man har så og si alt med unntak av ny kode. Det er ikke nødvendig å finne opp byråkratiet på nytt. Man har enhetstester fra forrige gang som kan gjenbrukes osv. Alt ligger i CVS.

• Man må regne inn tiden det tar å bygge ny debian-pakke med fikkerhetsfiks. Dette må testes. Har man enhetsteser osv. fra utviklingen, så kan dette gjenbrukes. Man må nok belage seg på å pakke systemet på ny 3-4 ganger i året (med tanke på sikkerhetsfikser i kernel, og kernel brukes i LTSP/Lessdisk).

• Man må håndtere meldinger fra sine kunder som ofte koster 1/4-1/3 av tiden totalt

Kilder:

• Project Estimation in the Norwegian Software Industry – A Summary http://www.simula.no/publication_one.php?publication_id=720

• National Science Foundation (USA) Faster, Better, Cheaper: Open-Source Practices May Help Improve Software Engineering http://www.nsf.gov/od/lpa/news/03/pr03132.htm

• The Development of Interactive Systems: Bridging the Gaps Between Developers and Users http://www.ics.uci.edu/~grudin/Papers/IEEE91/IEEE91.html

• Rapport om oversetting av OpenOffice http://developer.skolelinux.no/rapporter/ooo_ks_finans.pdf

Vedlikeholdbarhet

Dagens LTSP-løsninge er relativt sett svært enkel å vedlikeholde om man lemper på kravene i forhold til Debian-pakking. Arbeide som gjøres på dugnad av Ragnar Wisløff og Finn-Arne Johansen. LTSP 4.1 ligger med i testutgaven av Skolelinux sarge (som bygger på Debian testing) . Ragnar har binærkompilert herligheten, laget tar-filer, og pakket dette som Debian-pakker. Finn-Arne har tilrettelagt systemet slik at det installeres rett fra CD. Jonas Smedegaard <dr(at)jones.dk> fremhever behovet for vedlikehold av løsningen:

Der arbejdes aktivt på at justere uoverensstemmelserne mellem Debian og Skolelinux. [...] Et eksempel på uoverensstemmelser er brugen af LTSP som i sin nuværende form ikke overholder Debian Policy. Måske lykkes det at pakke nyere versioner af LTSP på en måde som overholder Debian Policy. Alternativt kan Skolelinux overveje at bruge lessdisks eller et andet tyndklient-system, som er inkluderet i Debian.

Hvor hurtigt kan sikkerhedshuller rettes - og hvor stor er chancen for at de overhovedet opdages? Med LTSP er det mig bekendt en relativt kompliceret affære at udskifte Linux-kernen, og endnu værre at udskifte et X11-bibliotek. Med lessdisks er al(!) binær kode pakkerne officielt vedligeholdt af Debian - X11-bibliotekerne er dem som Branden Robinsom kærligt nusser om, og Linux-kernen opdateres lisså snapt som når du udskifter kernen på din "fede" arbejdsstation eller tjener.

Metode

Jeg har spurt Johnny som er daglig leder i InOut om vi kan ta et åpent møte om dette av følgende årsaker:

1. Å bruke studenter til dette kan gå av sporet. De er bedre på å lage prototyper enn kjørbar kode i driftsstabile løsninger.

2. En del Debian-utviklere er bedre på vedlikehold av pakker og plastring enn nyutvikling. Skal man integrere f.eks. NX-teknologi i X-protokollen (som drar ned båndbredden på standardprogram fra 2 Mbps til 20-40 kbps), kan dette kreve mer utviklingskompetanse.

3. Har spurt Jim McQuillan <jam(at)Ltsp.org> (far for LTSP), om han kan hjelpe oss med estimering, og noe strategi. Han har tatt med våre spørsmål i sin presentasjon på GUADEC 2004 på Høgskolen i Agder.

4. Jonas Smedegaard <dr(at)jones.dk> har sendt svar¹¹ på spørsmål om Lessdisk og behovet for vedlikehold, uavhengig om dette gjelder Lessdisk eller LTSP¹².

Krav til løsningen

Hovedpoenget er å 1) sikre lavere båndbredde. Det andre 2) er å sikre trygt og godt vedlikehold av løsningen ved sikkerhetsoppgraderinger og nye utgaver gjennom vedlikeholdbare debian-pakker. Derfor må det bestemmes hvilke strategi(er) man velger for optimalisering av tynnklienter. Løsningen må forankres oppstrøms både i LTSP-prosjektet/Lessdisk og Debian :-)

1. En god kravspesifikkasjon over hva som skal gjøres med estimater (ikke anslag som var situasjonen 29. sept. 2004).

2. En god beskrivelse av hva man forventer seg av leveransen som:

• Kode i CVS oppstrøms til LTSP og Lessdisk

• Vedlikeholdte Debian-pakker

• Dokumentasjon

• Test- og leveranserapportering

Oversikt over studentprosjekt som berører temaet:

http://developer.skolelinux.no/info/studentprosjekter/studentprosjekter.html

http://developer.skolelinux.no/info/studentgrupper/2004_kandidater.txt

Finansiering

Først litt bakgrunn før man ser på finansiering av et forbedret opplegg med tynnklienter. Departementet mente at det er urimelig at dugnad skal være den eneste måten å sikre finansiering. Det er en rekke roller i et utviklingsprosjekt som kan være umulig å få folk til på dugnadsmåten. På møte i Departementet nevnes UNINET som et eksempel. De er et AS overfor Departementet og får sine inntekter fra brukerorganisasjonene forteller Odd Asbjørn Halseth. Alle inntekten kommer fra det offentlige, men man har altså en selvstendig organisering. Foreløpig er alt arbeidet i Skolelinux privat finansiert gjennom dugnad, eller gjennom SLX Debian Labs.

Stiftelsen SLX Debian Labs ble etablert for å møte Departementets krav til troverdig organisering i minst 5 år, og for å håndtere vedlikehold av sentrale debian-edu-komponenter hvor skoleeiere forventer trygt og godt vedlikehold av systemet fra lønnet personell. Etableringen og rollen til SLX Debian Labs er forankret i alle deler av Skolelinux-organisasjonen gjennom møte om organisatorisk troverdighet i 29. april 2003¹³.

Om finansiering av et forbedret tynnklientopplegget

Disse forbedringene er ønsket av Fronter gjennom Roger Larsen, InOut gjennom Johnny som er daglig leder, og Utdanningsetaten i Oslo. Knut Yrvin har sagt at alt er mulig, og vi har nøyaktig samme mål. Men vi må gjøre en analyse over hvilket omfang arbeidet har, og hvilken fremgangsmåte som er best. Fremgangsmåten er viktig da man ønsker å unngå framtidige lisenskostnader og unødvendig vedlikeholdsansvar. Det forventes at brukerorganisasjonene betaler tilpasning og vedlikehold. Ingen ting er avklart i forhold til hvem som bør gjøre jobben, og vedlikeholde løsningen. Men med tanke på den svært gode kontakten LinuxLabs <firmapost(at)linuxlabs.no> har med Jim McQuillan, vil dette spare mye tid i prosjektet om man unngår høyre transaksjonskostnader i det å få til løsningen. Dette vil være en prosess i hennhold til forventningen fra Departementet hvor SLX Debian Labs huker inn aktører, og har langt tidsperspektiv framover for vedlikehold av løsningen som blir valgt.

Knut Yrvin fra SLX og Tor Johnny Flaa <johnny(at)inout.no> fra InOut kommer tilbake med forslag til møtedato for overnevnte opplegg. Det er viktig å få på plass en ugreing som holder faglig forsvarlig nivå før man bestemmer seg for å bruke alt fra 250-1500 timer pluss vedlikehold på å supplere tynnklientopplegget i Skolelinux med ny funksjonalitet.

Hvem er orientert

Kopi av dette er sendt på Skolelinux-lista med spørsmål om gode innspill og forbedringer ut fra dialogen med Utdanningsetaten i Oslo. Før dette har både Vidar Bakke (SLX Debian Labs) og Erlend Reitan (InOut) blitt orientert. Roger Larsen <roger.larsen(at)fronter.com> (Fronter) har sagt kjør på med utgreing senest under NKUL 2004, så her er all ledelse orientert. Ragnar Wisløff og Finn-Arne Johansen har begge fått kopi av kort referat fra samtaler med Tor Johnny Flaa i InOut tidlig i september.