Mac- og Windows-integrasjon i Skolelinux. Sluttrapport Gruppe 7

Transkript

1 MNFIT Prosjektarbeid i informatikk Mac- og Windows-integrasjon i Skolelinux Sluttrapport Gruppe 7 Prosjektdeltagere: Svein Magne Bang, Sigurd Thune og Odd Rune Dahle Oppdragsgiver: Terje Rydland FAKULTET FOR INFORMASJONSTEKNOLOGI, MATEMATIKK OG ELEKTROTEKNIKK NORGES TEKNISK-NATURVITENSKAPELIGE UNIVERSITET

2 Sammendrag Som en del av faget MNFIT291 Informatikk prosjektarbeid II ved Institutt for datateknikk og informasjonsvitenskap ved NTNU, har denne prosjektgruppen i løpet av vårsemesteret 2003 jobbet med et oppdrag fra Skolelinux. Skolelinux er en norsk linuxdistribusjon tilrettelagt for det norske skoleverket. Distribusjonen er basert på frivillig arbeid fra et landsdekkende nett av entusiaster. Skolelinux hadde behov for å la skolenes Windows- og Macintosh-maskiner kobles til deres arkitektur. Prosjektgruppen har gjennomført denne utvidelsen av arkitekturen på en vellykket måte. Oppgaven har bestått mer av å tilpasse og dokumentere eksisterende programvare enn å implementere ny kode. 1

3 Innhold 1 Introduksjon til prosjektet Innledning Bakgrunn Hvordan rapporten skal leses Oppdragsgiver Oppgaven Oppgavebeskrivelse Hvorfor? Avgrensning Planlegging og rapportering Inndeling av prosjektet Møtevirksomhet og rapportering Organisering Fremdrift og tidsplanlegging Milestones Gantt-diagram Utviklingsmodell Risikovurdering Kravspesifikasjon Innledning Overordnet Tidsfrister Situasjonsanalyse Mål Bruker-/Målgruppe Behovsanalyse Teknisk løsning Funksjoner Bruk av standard programvare Levering

4 2.4 Dokumentasjon Brukerdokumentasjon Systembeskrivelse Utredning Innledning Ønsket arkitektur Tjenester Autentisering Tildeling av IP-adresser Navnetjener E-post Tilgang til web Fildeling Skriverdeling Klokkesynkronisering Aktuelle teknologier pgina Samba Webmin CUPS cfengine Oppsummering Utviklingsrapport Forberedelser til windows-støtte Installasjon av samba Konfigurasjon av samba Konfigurasjon av LDAP Implementering av script for windows Use Case Script for bruker- og passord-synkronisering Automatisering av klientkontoer Loginscript Avansert loginscripting MacOS X Oppsett av OS X mot Skolelinux Testing Testrapporter Test

5 5.1.2 Test Test Test Test Konklusjoner Egne erfaringer Kravspesifikasjon Risikovurdering Løsningen A Ordliste 47 A.1 Innledning B Konfigurasjon 50 B.1 smb-skolelinux.conf B.2 samba.schema C Kildekode 55 C.1 smbaddclient.pl C.2 smb create.pl C.3 login.bat C.4 shortcut.vbs C.5 mac-nfs-oppsett D Tilknytning av windowsklienter mot Skolelinux 62 D.1 Introduksjon D.1.1 Revisjonshistorie D.2 Administrativt D.2.1 Copyright D.2.2 Disclaimer E Installasjon 64 E.1 Konfigurasjon av tjeneren E.2 Konfigurasjon av klienten E.2.1 Nettverksoppsett E.2.2 Autentisering, fildeling og skriverdeling E.3 Andre tjenester E.3.1 Konfigurering Web-proxy E.3.2 Konfigurering av E-post

6 F Hvordan sette opp en mac med OSX som arbeidsstasjon i et skolelinux nettverk 67 F.1 Forberedelser F.1.1 Software F.1.2 Kunnskap F.2 Nettverksoppsett F.2.1 Plassering av mac er på Skolelinux nettverket F.2.2 DHCP F.2.3 DNS F.2.4 Proxy F.3 Autentisering F.3.1 LDAP oppsett i OS X F.4 Innloggingsmeny i OS X F.5 NFS F.5.1 Sette opp nfs F.6 Tidsinstillinger i OS X F.7 Sette opp nettverksskriver i OS X F.8 Forandringer på tjener F.8.1 Forandringer i oppsettet på NFS F.9 Tillegg

7 Kapittel 1 Introduksjon til prosjektet 1.1 Innledning Bakgrunn Ved introduksjonsmøtet i MNFIT januar 2003 ved NTNU, ble det lagt frem en rekke oppdrag man kunne velge å arbeide med. Denne gruppen valgte der et oppdrag gitt av Skolelinux, via Terje Rydland (terje.rydland@idi.ntnu.no), som gikk ut på å integrere Macintosh- og Windows-maskiner i Skolelinux arkitektur. Representant fra Skolelinux og ekstern veileder, var Per Harald Westby (per.h.westby@broadpark.no). Gruppen har alle tidligere erfaring med drift av forskjellige typer nettverk, hvor man er avhengig av at datamaskiner med forskjellige typer operativsystemer snakker med hverandre. Gruppen har også en del erfaring med Linux, og mener at Skolelinux er et interessant prosjekt, med en god baktanke. Prosjektets varighet er satt til å være fra januar 2003 til innleveringsfrist 28. april 2003 i henhold til tidsskjemaet som er satt opp i dette faget Hvordan rapporten skal leses Rapportens innhold er delvis ganske teknisk, og skrevet for et varierende publikum. Den er primært en presentasjon av vårt arbeide, men også dokumentasjon for Skolelinux. IT-ansvarlige som skal bruke Skolelinux bør som et minimum lese vedleggene som omhandler installasjon av deres plattform (mac og/eller windows). Det anbefales også å lese utviklingsrapporten spesielt, og helst utredningen. 6

8 Utviklere fra Skolelinux bør i tillegg lese utviklingsrapporten spesielt nøye, samt vedleggene med konfigurasjon og kildekode. Representanter fra Instituttet har nok mest utbytte av introduksjon, kravspesifikasjon og avslutning, selv om vi håper at de klarer å lese hele dokumentet :-). Gruppen minner om ordlisten i vedlegg A på side Oppdragsgiver Dette prosjektet er bare en liten del av et langt større utviklingsprosjekt kalt Skolelinux 1. Skolelinux er en Linux-distribusjon som utvikles i regi av Linux i skolen 2. Dette er en idealistisk medlemsorganisasjon som tilrettelegger og informerer om bruk av fri programvare (opensource) i norske skoler. Linux i skolen ble stiftet 16. juli 2001 og fungerer som en paraply for flere prosjekter som arbeider med å få Linux inn i norske skoler [1]. Målet er å tilby skolen en gratis programvareplattform som er bedre tilpasset skolens behov enn tilsvarende komersielle løsninger som finnes i dag. Skolelinux kommer her inn som en komplett løsning bestående av et operativsystem og tilhørende programvare utviklet spesielt med tanke på skolen som bruker. Alle programmene som leveres med skolelinux skal være tilgjengelig på bokmål, nynorsk og i stor grad samisk. Dette er helt på linje med de anbefalinger Læringssenteret på oppdrag fra Utdanningsdepartementet har kommet med. I Språkrådets tolkning av forskriftene til opplæringsloven [2] kommer det klart frem at regelen om paralellutgaver av alle læremidler gjelder, uansett om det er et læremiddel som er papirbasert, eller på elektronisk form. Skolelinux er et distribuert prosjekt og har i dag over 50 medlemmer som arbeider med oversetting og utvikling. Arbeidet er basert på frivillig innsats. Prosjektet har en flat organisasjonsstruktur og baserer seg rundt gjørokratiet. Dette innebærer at alle kan jobbe med akkurat den biten de vil til en hver tid, noe som ofte er vanlig fremgangsmåte i opensource-miljøet. Skolelinux baserer seg på Debian GNU/Linux 3 og dermed også GNU GPL 4 lisensiering. Dette innebærer at alt som utvikles også må gjøres tilgjengelig for andre. GPL tillater fri kopiering/- distribuering og modifisering av programvaren

9 1.2 Oppgaven Oppgavebeskrivelse Oppgaven går ut på å vurdere og beskrive hvordan en Mac med Mac OS X og en PC med Microsoft Windows best kan kobles inn i Skolelinux nettverksarkitektur og utnytte de tjenester Skolelinux (tjeneren) tilbyr. Det skal med andre ord etableres en profil for mac- og/eller windows-klienter i Skolelinux. Videre skal det implementeres utvalgte deler av den/de etablerte profilen(e) for å automatisere og legge til rette for dette. Aktuelle teknologier er bl.a. OpenLDAP, Samba, Netatalk, Cups, NFS og X- tjenere, for å eventuelt kunne kjøre applikasjoner på tjenere fra mac og/eller windowsklient. Implementasjonsdelen av oppgaven vil for det meste bestå av å tilpasse allerede eksisterende og velkjent programvare for å passe in i Skolelinux arkitektur Hvorfor? Skolelinux er et frivillig prosjekt igangsatt for å hjelpe skoler med å få mer ut av sine IT-budsjett. I dag går veldig mye penger med til å betale lisenser til Microsoft for Windows og Office-programmer[3]. Mange skoler har fremdeles mange maskiner som er kraftige nok til å kjøre Windows, og ønsker å fortsette med dette. Vår oppgave var å la disse få bruke tjenester som fil- og printerdeling fra et Skolelinux-nettverk, slik at en konvertering til kun Linux skal gå lettest mulig Avgrensning Gruppen har valgt å avgrense oppgaven til å omfatte fil- og skriver-deling til Mac OS X og Windows 98, Windows NT, Windows 2000 og Windows XP Professional. Det er verdt å merke seg at Windows 95 er valgt bort på grunn av sikkerhetsmessige hensyn, mens Windows XP Home i stor grad mangler mulighet til å jobbe som en nettverksklient (mangel på funksjonalitet). Det vil vektlegges å få til automatikk i tilknytningen i form av scripting og tilrettelegging for å få konfigureringarbeidet ned på et minimum. Resterende tjenester vil bli tatt med i utrednings- og dokumentasjonsfasen, men blir ikke implementert på grunn av den begrensede tidsrammen prosjektet har. Enkelte tjenester vil i utgangspunktet også være tilgjengelig as-is for mac og windows, uten nødvendig 8

10 modifisering av hverken klient eller tjener. Valg av programvare på klientsiden for disse tjenestene (f.eks e-post) vil være opp til hver enkelt administrator å velge. 1.3 Planlegging og rapportering Inndeling av prosjektet Oppgaven er i utgangspunktet delt opp i to deler. En utredningsdel hvor man skal finne løsninger som gir mac- og windows-klienter tilgang til tjenester på Skolelinux tjener, og en del som består av å implementere utvalgte deler av denne løsninger for Skolelinux. Vi velger også å legge til en tredje usynlig del, som består i å sette seg inn i det omfattende materialet som omhandler alle løsningene Skolelinux baserer seg på. Det er et omfattende system som det tar tid å bli kjent med før man i det hele tatt kan begynne på selve oppgaven. 1. Oppstartsfase Ta kontakt med oppdragsgiver Få satt opp maskiner i et testnett Få tilgang til Skolelinux CVS Påmelding i Skolelinux mailinglister 2. Studier/research Studere Skolelinux arkitektur Utrede kravspesifikasjon og avgrense oppgave Lære om autentiseringssystemet i Skolelinux (LDAP) Finne informasjon om alternative aktuelle programvareløsninger 3. Utredningsfase Prøve ut forskjellige tjenester og sammenligne dem Danne en profil for mac/windows-klienter i Skolelinux arkitektur. 4. Implementasjon Få opp valgte programvare for fil- og skriverdeling på Skolelinux tjener med full LDAP-støtte Testing av løsning lokalt Feilretting, korrigering 9

11 5. Avslutningsfase Skrive ferdig prosjektrapport og dokumentasjon Møtevirksomhet og rapportering Som en del av opplegget i faget mnfit291 skal gruppen levere en ukentlig kort statusrapport til veileder. Gruppen har etter avtale satt opp et møte hver tirsdag kl 12 med veileder Sven Ziemer hvor siste ukes statusrapport gjennomgås og spørsmål vedrørende de praktiske forhold rundt prosjektet tas opp. Kontakt med arbeidsgiver skjer også på ukentlig basis gjennom et møte hver tirsdag kl 11. Resten av kontakt med andre utviklere av Skolelinux foregår via mail, samt en utviklersamling i februar hvor to av gruppens medlemmer deltok. Viktige spørsmål vedrørende oppgavens innhold taes opp på møter med Rydland, på disse møtene blir det skrevet et kort referat fra i ettertid som sendes på mail. Det er blitt tildelt et rom til prosjektet ved i IT-Syd på Gløshaugen. Dette rommet står fritt tilgjengelig for prosjektgruppen og de enkelte gruppemedlemmene disponerer egen nøkkel hit. Det er ingen faste tider satt opp for arbeid på dette rommet, medlemmene benytter seg av det etter som det passer inn i timeplanen deres. Viktige beskjeder og planlegging innad i gruppen foretas på egen mailingliste opprettet ved NTNU eller ved møter som avtales etter behov Organisering Studenter Gruppeleder Utviklere Svein Magne Bang Sigurd Thune Odd Rune Dahle Institutt Oppdragsgiver Veileder Terje Rydland Per Harald Westby Sven Ziemer 10

12 1.4 Fremdrift og tidsplanlegging Milestones Vi har satt opp en rekke milestones utover i prosjektet for å få bedre kontroll med tiden vi bruker. Vi har valgt å fastsette det på ukesbasis. En del av oppgavene strekker seg over flere uker. For å tilpasse fremdriften med de ukentlige møtene hver tirsdag velger vi å si at hvert enkelt punkt skal være fullført innen tirsdagen den gjeldende uka. Testnett på skolen februar Eget rom må være tildelt og maskiner satt på plass. Utstyret må være koblet opp i henhold til skolelinux arkitektur og nettet må fungere som et vanlig skolelinux-nett for å ha dette som utgangspunkt. Kravspesifikasjon fastsatt februar En komplett kravspesifikasjon skal være skrevet. Denne skal avklares og godkjennes sammen med oppdragsgiver. Utredelse av en profil/teknisk løsning mars En oversikt over hvordan en integrering av gitte plattformer i Skolelinux kan gjennomføres skal skrives ned. Valg av teknisk løsning skal skal dokumenteres og legges fram for oppdragsgiver. Rapport for midterm innlevering mars Midterm-rapport skal være ferdig skrevet og klar for levering. Alle punkter som kreves å være med i denne må være på plass. Ferdig mer implementering - 8. april Fil- og skriver-deling mot windows og må være ferdig implementert. Synkronisering av brukerdata mot samba må være ferdig og fungere. Alt skal være klart for demonstrasjon overfor kunde. Endringer skal være oppdatert i CVS. Endelig demonstrasjon overfor kunde april Alt må være ferdig implementert og tilstrekkelig testet slik at det er klart for komplett demonstrasjon. Ferdig skrevet dokumentasjon og rapport april Dokumentasjon i form av en howto om hvordan man skal koble til henholdsvis mac- og windows-klienter skal være klar og lagt inn i CVS. Dokumentasjonen skal også inn i rapport som vedlegg. Rapport skal være ferdig skrevet og klar til levering. Alle punkter som kreves til innleveringen skal 11

13 være dekket. Produktet i form av dokumentasjon og programvare skal være lagt inn i CVS hos kunde Gantt-diagram De fleste oppgavene i diagrammet utføres av utføres av samtlige av gruppens medlemmer med unntak av implementasjonen som er delt opp. Inndelingen har vært som følger: Implementering av passordsynkronisering Implementering av windowstilknytning Implementering av mactilknytning Andre oppgaver Odd Rune Dahle Svein Magne Bang Sigurd Thune Alle 12

14 , ( 1!! 13 ",( "!! #! - $ # $ %%# & $ '# &! $ & (, 2*!! )* 3 *.( 45+ +(!,! $!! *.&/) - (0# ""

15 1.5 Utviklingsmodell Etter litt dikusjon og grubling ble det valgt i å ikke bruke noe avansert og moderne utviklingsmodell. Prosjektet har i stedet basert seg rundt fossefallsmetoden. Det finnes flere årsaker til gruppen endte opp med dette. Først og fremst skyldes det at en iterativ prosess designet for programvareutvikling fort ville bli vanskelig å gjennomføre i et slikt prosjekt. Med den knappe tidsrammen og det litt uoversiktelige arbeidet som ventet tok gruppen den trygge veien. analyse design implementasjon testing Figur 1.1: Fossefall vår utviklingsmodell. 1.6 Risikovurdering Sannsynlighet og konsekvens er her delt inn i tre nivåer: lav, middels og kritisk. Ordene er i utgangspunktet ganske selvforklarende, og jo høyere risiko og jo større konsekvens man har, desto mer alvorlig er hendelsen. 14

16 15 Hendelse Sannsynl. Konsekvens Følger Tiltak Gruppemedlem slutter eller Lav Kritisk Gruppen får ikke ferdig det Redusere omfang av ferdig blir syk planlagte produktet til leve- produkt underveis dersom en Mid-term rapport blir avvist som ikke tilfredstillende Oppgavedefinisjon endres underveis. Nye krav kommer legges frem Krav blir viser seg å være uoppnåelig uten omfattende (les: tidkrevende) programvareutvikling. Valg av teknisk løsning som viser seg å by på problemer. Ferdig løsning viser seg å være ustabil/manglende funksjonalitet i praktisk bruk. ringsdato Lav Kritisk Gruppen får ikke fullføre prosjektet Middels Middels Tidsskjema sprenges, planer må endres. Lett å miste oversikt. Middels Middels Det endelige resultat vil ikke fullt ut oppfylle kravspesifikasjon. Middels Middels Mindre tid til implementasjon av rett løsning ettersom man bruker av denne tiden til feil løsning. Lav Middels Resulterende løsning som blir levert til den faste datoen er ikke fullt ut tilfredstillende. slik situasjon oppstår. Sette av nok tid til å gi en tilfredstillende rapport til uke 11, samt sørge for jevnt arbeidstempo. Sørge for en klar definisjon og målsetting i oppstart. Ved nye krav må dette forhandles med kunde og eventuelt bli plassert inn i prosjektet på bekostning av andre tidligere vedtatte krav. Få tidlig oversikt over de forskjellige løsningsalternativene og eventuelt gå tilbake til kunde for å diskutere funksjonelle krav mot tidsfrist. Bruke tid på å undersøke de forskjellige løsningene nøye og utrede disse før man begynner implementasjon. Sette av tid til testing mot slutten med mulighet for å luke ut feil i god tid før leveringsdato.

17 Kapittel 2 Kravspesifikasjon 2.1 Innledning Dette prosjektet er valgt som del av faget Informatikk prosjektarbeid II ved Institutt for datateknikk og informasjonsvitenskap ved NTNU våren Skolelinux-prosjektet har etablert en nettverksarkitektur, et antall profiler for maskiner i et Skolelinux-nettverk (tjener, tynnklient-tjener, arbeidsstasjon og tynnklient) alle basert på Debian Linux, og et sett tjenester (autentisering, autorisasjon osv). Første del av oppgaven er å vurdere og beskrive hvordan Mac med OS X og/eller PC med Windows best kan koples inn i denne nettverksarkitekturen og utnytte tjenestene den tilbyr, og derved etablere en profil for Mac- og/eller Windowsklienter i Skolelinux. Andre del av oppgaven er å implementere utvalgte deler av den/de etablerte profilene Overordnet Ordene MÅ, MÅ IKKE, BØR, BØR IKKE, PÅKREVD, ANBEFALT, KAN og VALGFRI i dette dokumentet skal tolkes likt sine engelske motstykker som beskrevet i RFC 2119[4]. Overordnede krav og målsettinger Det MÅ foreligge en rapport som beskriver hvordan OS X og/eller PC med Windows best kan kobles inn i Skolelinux nettverksarkitektur. Prioriterte versjoner av Microsoft Windows er 98 og XP. Prioriterte versjoner for Macintosh er MacOS X 10.2 og nyere. 16

18 Tilknytning av klienter MÅ være plug and play med et minimum av teknisk arbeid. Autentisering av brukere MÅ skje mot den sentrale brukerdatabasen (LDAP). Passord MÅ gå kryptert over nettverket. Autentiserte brukere MÅ få automatisk tilgang til sine hjemmeområder på Skolelinux-tjeneren. Tilgang til web/webproxy BØR være automatisk. Løsning for web/mail er VALGFRITT Tidsfrister Prosjektet har leveransedato 28. april Andre tidsfrister og milepæler vurderes løpende i samtale med kunden. 2.2 Situasjonsanalyse Skolelinux-arkitekturen er per i dag primært rettet mot skoler som vil ha en full overgang til Skolelinux-distribusjonen. Noen integrasjon av Windows- og Macintoshklienter er ikke foretatt i dag Mål Skolelinux-prosjektet satser på at overgangen til Skolelinux skal være så enkel som mulig. For å gjøre overgangen så smertefri som mulig for skolenes IT-ansvarlige er det ønskelig å la dem bruke eksisterende arbeidsstasjoner mot en Skolelinuxtjener. Dette prosjektet fokuserer på Windows og Macintosh Bruker-/Målgruppe Skolelinux er tiltenkt elevnettverk på skolene, og alle oppsettvalg som er gjort har dette som ramme. Målgruppen er altså skoler og driftansvarlige på skoler. Krav til brukeren Systemansvarlig må ha noe erfaring med bruk av Linux for å kunne installere (Gjerne igjennom kurs i regi av skolelinux for brukeradministrasjon.) 17

19 Elever må ha en grunnleggende itk-kunnskap gitt av skolen for å kunne skifte passord og logge seg på maskinene selv Behovsanalyse Kunden må ha en løsning som gjør det enkelt for skoler å beholde sine gamle klienter på allerede eksisterende operativsystemer. Det er ønskelig at klientene skal kunne dualboote - enten gammelt operativsystem eller Linux tynnklient. Løsningen MÅ være godt testet før leveringsdato. Å oppfylle få krav godt er fra kundens ståsted bedre enn å oppfylle alle krav halvveis. 2.3 Teknisk løsning Funksjoner Primærkrav til funksjoner er autentisering, fil- og skriverdeling. Det legges vekt på at driftsansvarlige MÅ ha minst mulig jobb med oppsett og vedlikehold utover førstegangs installasjon. I tillegg er det ønskelig å ha løsninger for webproxy og epost. Det er IKKE PÅKREVD at Mac- og Windows-klienter skal kunne konfigureres/administreres vha cfengine Bruk av standard programvare All programvare som leveres som en del av løsningen skal være lisensiert under GNU General Public License. Til dokumentasjon benyttes GNU Free Documentation License Levering Endelig levering er i form av at gruppens løsninger (og dokumentasjon, rapport) er med i Skolelinux-distribusjonen. Gruppens arbeide skal sjekkes inn i Skolelinux CVS tjener. Endelig levering til NTNU/IDI: demonstrasjon rapport 18

20 2.4 Dokumentasjon Prosjektgruppen MÅ produsere en rapport som beskriver hvordan MacOS X og/eller PC med Windows best kan kobles inn i Skolelinux nettverksarkitektur. Denne rapporten skal brukes som utgangspunkt i prosjektets implementasjonsfase Brukerdokumentasjon Det skal produseres dokumentasjon for hvordan driftsansvarlige på skoler kan bruke prosjektets løsning til å integrere sine eldre klientmaskiner i Skolelinuxarkitekturen Systembeskrivelse Som en del av sluttarbeidet skal det foreligge en systembeskrivelse av implementasjonsarbeidet som tar for seg minimum følgende punkter: Systemkrav. Installasjonsprosedyre. Drift / vedlikehold. Brukte komponenter. 19

21 Kapittel 3 Utredning 3.1 Innledning Oppgaven består av to hoveddeler. Først en som består av å utrede hvordan en integrering av mac og windows mot Skolelinux kan gjøres, og deretter en implementering av noen spesielt prioriterte elementer. Det første som må bringes på det rene er hvordan maskiner som kjører Mac OS eller windows kan plasseres inn i skolelinuxarkitekturen. Først må den fysiske plasseringen i nettet avklares, deretter må ressursene som tilbys fra Skolelinux sees i sammenheng med disse operativsystemene. Skolelinux-tjeneren har en rekke tjenester den tilbyr på nettet til sine klienter. En viktig del av denne oppgaven er å utrede hvordan man best kan få utnyttet disse fra de plattformene som skal integreres. Målet med denne delen av rapporten er å finne frem til hvilke tjenester støttes i utgangspunktet, hva som trenger ytterligere dokumentasjon og hva skal implementeres i dette prosjektet. 3.2 Ønsket arkitektur Som utgangspunkt har Skolelinux etablert en arkitektur bestående av en tjener, tykke klienter, tynnklient-tjenere og tynnklienter. Hver tynnklient-tjener har sitt eget separate nettverk for sine klienter. Hovednettet består av tjeneren, tynnklienttjenere og tykke klienter (arbeidssstasjoner). Første del av dette prosjekter er å etablere en profil for klienter som kjører Mac OS og windows. Første ledd i utredningen av en slik profil blir å plassere maskinene fysisk inn i nettverksarkitekturen. Figur 3.1 er et forsøk på å vise hvordan gruppen ser for seg at slike klienter er integrert med den tidligere arkitekturen. Alle klienttyper er representert. Som det fremgår av figuren blir både mac- og windowsklienter plassert på hovednettet. Dette valget er gjort ettersom begge plattformer hører hjemme under definisjonen 20

22 Figur 3.1: Ny Skolelinux-arkitektur av en tykk klient. I noen tilfeller vil det kanskje være ønskelig å kunne plassere disse på et tynnklient-nett av rent praktiske (fysiske) årsaker, men dette anbefales ikke. For Mac kan dette muligens fungere ved hjelp av en bra konfigurert NATing på tynnklient-tjeneren, men vil lett kunne få problemer. Dersom windows skal baseres rundt samba/windows-fildeling vil en slik ruting av trafikk neppe fungere tilstrekkelig. Slik trafikk er av erfaring svært vanskelig å få transportert på tvers av subnett. Den sentrale tjeneren får utvidelser i form av konfigurasjon, ny programvare og nye script for å håndtere denne nye situasjonen. 3.3 Tjenester De tjenestene som tilbys av Skolelinux som er aktuelle i forbindelse med tilknytning av mac- og Windows-klienter er: Autentisering via LDAP Tildeling av ip-adresser (DHCP) Navnetjener (DNS) E-post-tjener 21

23 Web-tjener (Apache) Web-tilgang via proxy (Squid) Fildeling (NFS og Samba) Skriverdeling (CUPS og Samba) Klokkesynkronisering (NTP) Ved å gå igjennom dem punkt for punkt forsøkes det å komme frem til en konklusjon om hva som behøves for å få tilknyttet klientene som skal integreres. Deretter dykkes det litt mer inn i dybden på de aktuelle teknologiene som finnes til en implementering Autentisering Noe som skiller Skolelinux fra mange andre linux-distribusjoner er måten brukerdata blir lagret på. I stedet for å lagre brukere og deres passord i spesielle tekstfiler, bruker Skolelinux LDAP til dette. LDAP kan for enkelthets skyld sees på som en slags database. Dette har en rekke fordeler som for eksempel at man kan distrubuere brukeredataene over nett. I forbindelse med windows-tilknytning byr dette derimot på en utfordring siden windows kan ikke benytte seg av LDAP for autentisering. For ordens skyld kan det nevnes at windows ikke kan få tilgang til tekstfilene som er alternativet heller, men mellomleddet, samba, er bedre testet og dokumentert for bruk sammen med den tradisjonelle måten å lagre brukerdata på. For mac er denne historien ganske annerledes. OS X har full støtte for LDAP og kan autentisere brukere direkte mot tjeneren Tildeling av IP-adresser Tildeling av ip-adresser gjøres automatisk av tjeneren ved help av DHCP dersom klienten er satt opp til å be om dette. Man må med andre ord sette opp klienten til å be om ip-adresse, noe som er standard på en ny installasjon av både windows og MacOS. Dersom man allerede har en ip-adresse satt manuelt, må man gå inn i nettverks-oppsettet på klienten og sette den til å tilordne adresse automatisk via DHCP. DHCP vil også tildele annet nettverksoppsett som netmask og default gateway. 22

24 3.3.3 Navnetjener Tjeneren tar seg av navnetildeling (DNS) til alle maskiner lokalt, og gir videre tilgang til eksterne navnetjenere automatisk. Oppsett av dette vil være automatisk forutsatt at man har satt klienten til å motta dette via DHCP som nevnt over for ip-adresser E-post Skolelinux tilbyr epost-tilgang gjennom Squirrelmail (en webbasert epost-leser), eller direkte mot POP 1 / IMAP 2 -protokollene. Hvis man velger å bruke protokollene direkte så må brukeren sette opp en egen post-klient på maskinen sin (f.eks. Outlook, Eudora e.l.). Med Squirrelmail, som er en web-basert klient, vil ikke brukeren ha behov for noen ekstra programvare utover en nettleser. Mac- og Windows-klienter vil i dag få automatisk tilgang til nettverksressurser som f.eks. Skolelinux Squirrelmail-løsning. Prosjektgruppen anbefaler at disse klientene benytter seg av den webbaserte løsningen. Dette har følgende fordeler: Ingen lokal konfigurasjon. Meldinger forblir lagret sentralt. Unngår å bruke Outlook, som er velkjent for sine sikkerhetsproblemer Tilgang til web Skolelinux har en egen web-tjener som kan benyttes både for interne og eksterne websider. For å få tilgang til disse behøver man kun å legge inn url til tjeneren i webleseren ( For å gi klienter tilgang til web ut bruker skolelinux en proxy. Denne må legges inn i klientens web-leser for å kunne komme ut på internett. Til windows finnes det en rekke web-lesere. De mest kjente er Internet Explorer, Netscape og Opera. Alle disse har hvert sitt sted å lagre konfigurasjon og det finnes derfor ingen standard for å legge inn denne informasjonen. Det finnes dog noe som til nøds kan kalles standard for å automatisere dette ved hjelp av DHCP, web-tjener og scripting. Samme problematikk finnes på Mac hvor det også finnes en rekke forskjellige web-lesere