Skolelinux - Arkitekturbeskrivelse Petter Reinholdtsen Skolelinux er en Debian-baseret Linux-distribution m lrettet til elevnetv rk i grundskolen (6-16 r). Dette dokument beskriver hvordan netv rket struktureres, og hvordan tjenesterne i netv rket kommer til at fungere. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents 1. Netv rk 2. Tjenester 2.1. Tjenester for tynde klienter 3. Drift 4. Installation A. File system access configuration B. Stikkord ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Chapter 1. Netv rk [network-ar] Netv rksarkitektur Figuren viser en skitse over antaget netv rkstopologi. N r et Skolelinux-netv rk s ttes op i standard-ops tningen, antages der at v re een tjener, en eller flere arbejdsstationer og LTSP-tjenere, og ingen eller flere LTSP-klienter. LTSP-klienterne er p separate netv rk, for at undg at trafikken mellem LTSP-tjener og klienter p virker andre tjenester p netv rket. Et netv rk kan kun have een DHCP-tjener. Dette er rsagen til at der aldrig m v re mere end een tjener p samme netv rk. Tjenester p tjeneren kan flyttes til andre maskiner ved at flytte konfiguration og tjeneste, og derefter opdatere DNS-ops tningen s DNS-henvisningen peger p den rigtige maskine. Det forventes at forbindelsen ud p Internet g r via en separat router. Denne foruds tning er for at forenkle den standardiserede ops tning af Skolelinux. Det er muligt at s tte Debian op b de med modem og ISDN-forbindelse, men der g res ikke fors g p at f dette til at fungere automatisk med Skolelinux. En s dan ops tning skal tilpasses hver enkelt installation, og dokumenteres separat. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Chapter 2. Tjenester Vi tilbyder kun tjenester via IPv4. Alle tjenester s ttes som udgangspunkt op p en central maskine (skolelinux-tjeneren), med undtagelse af styring af tynde klienter som anbefales spredt til andre maskiner af ydelses-hensyn. Alle tjenesterne f r tildelt eget DNS-navn, s enkelt-tjenester kan flyttes fra hovedtjeneren til andre maskiner ved blot at stoppe tjenesten p skolelinux-tjeneren og ndre i DNS-ops tningen s den peger p den nye maskine. Der m aldrig sendes adgangskoder i klartekst over netv rket. Alle forbindelser hvor der sendes adgangskoder over netv rket skal v re krypterede. F lgende tjenester settes op [med DNS-navnet i lodrette klammer]. DNS-navnet skal stemme overens med tjenestenavnet i /etc/services. Da dette mangler bruges det alment brugte navn p tjenesten som DNS-navn. Alle ops tningsfiler skal s vidt muligt referere til tjenesterne ved navn, og uden dom nenavn, s det er enklere at ndre dom nenavn p de skoler som har eget DNS-dom ne, og enklere at ndre IP-nummer p de skoler som nsker det. • Central indlogning [syslog] • DNS (Bind?) [domain] • Automatisk netv rksops tning af maskiner (DHCP) [bootps] • Tidssynkronisering (NTP) [ntp] • Hjemmeomr der via netv rksfilsystem (SMB/NFS/Appletalk) [homes] • Elektronisk postkontor (Limacute) [postoffice] • Katalogtjeneste (OpenLDAP) [ldap] • webtjener (Apache/PHP/eZ) [www] • SQL tjener (PostgreSQL) [database] • Central backup (?) [backup] • web-cache / proxy (Squid) [webcache] • Udskrift (CUPS) [ipp] • Fjern-indlogning (OpenSSH) [ssh] • Automatiseret ops tningsstyring [cfengine] • Tjenere for tynde klienter (LTSP) [ltsp-server-\#] • Maskin- og tjenesteoverv gning med fejlrapportering, + statusoversigt og historik p web. Fejlrapportering via mail. Tjeneren uddeler filsystem over netv rket, og tilbyder brugernes hjemmeomr der til alle arbejdsstationer. Vi bruger NFS til Unix-klienter, SMB til Windows-klienter og Appletalk til Macintosh-klienter. Alle personlige filer skal gemmes p hjemmeomr det, s der er tilgang til de samme filer uanset hvilken maskine der arbejdes p . Intern postkontor-tjeneste s ttes op, med lokal levering og tilgang til personlig mail vha. POP og IMAP. Mail kan s ttes op til at levere til Internet hvis skolen har fast linje til netv rket. Vi ops tter mailinglister baseret p brugerdatabasen, s d hver klasse har tilgang til egne mailinglister. Alle klienter indstilles til at levere mail til tjeneren (dvs bruger "smarthost"). Der ops ttes en central brugerdatabase til godkendelse og tildeling af adgangsrettigheder, s brugeren har samme brugernavn og adgangskode ved alle tjenester som kr ver indlogning. Tilgang til WWW s ttes op til at g via en web-proxy (Squid), med lokal mellemlagring af filer. Dette ger ydelsen p ofte brugte sider, og muligg r sammen med sp rring af web-trafik i router adgangskontrol til Internet pr. maskine. IP-nummer til klienterne tildeles via DHCP. Vi v lger et privat IP-net, og tildeler IP i dette net. Vi har valgt at bruge subnet 10.0.2.0/23. Tynde klienter kobles til LTSP-tjeneren via et separat subnet 192.168.0.0/24 tilkoblet hver enkelt LTSP-tjener. Central logning s ttes op s alle maskinerne sender sine syslog-meldinger til tjeneren. syslog-tjenesten s ttes op s den kun accepterer indkommende meldinger fra lokalnettet. Tjeneren s ttes op som DNS-tjener for et DNS-dom ne som kun bruges internt (*.intern.), og frem til hvor et officielt ("eksternt") DNS-dom ne kan s ttes op. Denne DNS-tjener fungerer desuden som mellemlagrende DNS-tjener, s alle maskiner p netv rket kan s ttes op til at have denne som sin hoved-DNS-tjener. Der ops ttes en webtjener med publiceringsl sning til brug af elever og l rere. Websystemet skal have mekanismer til at kunne godkende brugerne, og til at begr nse adgangen til enkeltsider og underkataloger til enkeltbrugere og grupper af brugere. Websystemet skal v re programm rbart p tjenersiden, s brugerne kan gemme dynamiske websider. Der ops ttes en central katalogtjener s information om brugere og maskiner kan ndres p eet centralt sted, og automatisk g res tilg ngeligt p alle maskinerne p netv rket. Kataloget skal indeholde information om brugere, brugergrupper, maskiner og maskingrupper. For brugere skal der ikke skelnes mellem arkivgrupper, mailinglister og netv rksgrupper, for at undg forvirring om hvilken gruppetype en bruger er lagt ind under. Dette indeb rer, at maskingrupper som skal v re netv rksgrupper har samme navnerum som brugergrupper og mailinglister. Administrationen af tjenester og brugere skal stort set v re webbaseret, og f lge etablerede standarder og fungere med de netl sere som f lger med Skolelinux. Det webbaserede administrationssystem skal kunne h ndtere uddelegering af enkelte opgaver til enkeltbrugere eller grupper af brugere. Ens tid p alle maskiner er en n dvendighed for at undg en del problemer n r der bruges NFS, og g r det enklere at fejls ge en r kke problemer. For at holde urene synkroniseret p tv rs af maskiner ops ttes Skolelinux-tjeneren som en lokal Network Time Protocol-tjener. Alle arbejdsstationer og klienter s ttes op til at synkronisere sin tid med tjeneren. Tjeneren b r s ttes op til at synkronisere sit ur via NTP op imod maskiner p Internet med korrekt tid, s hele netv rket f r korrekt tid. Printere kobles op hvor det passer bedst, enten direkte p netv rket, tilkoblet tjener, arbejdsstationer eller LTSP-tjenere. Printere skal have kvotestyring og adgangskontrol, hvor enkeltbrugere gives forskellig adgang alt efter hvilke grupper de tilh rer. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.1. Tjenester for tynde klienter Ops tningen til tynde klienter er baseret p The Linux Terminal Server Project (LTSP). Dette er et system som lader en PC fungere som X-terminal. Det lader maskiner starte fra diskette eller netkort-PROM og indl ser system direkte fra en tjenermaskine uden at bruge klientens lokale harddisk. Tjenesten bruger DHCP og TFTP til at forbinde til netv rket og starte op fra netv rket. Derefter monteres filsystem via NFS fra en LTSP-tjener og X11 startes op og kobles til samme LTSP-tjener vha XDMCP. Resultatet er en arbejdsstation hvor alle programmer k rer p en LTSP-tjener. Tjeneren til tynde klienter s ttes op til at modtage syslog fra de tynde kliente, og til at videreformidle disse meldinger til den centrale syslog-modtager. [1] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Chapter 3. Drift Alle linux-maskiner installeret ved hj lp af Skolelinux-CD'en skal lade sig administrere fra en central maskine, fortrinsvis tjenermaskinen. Der skal kunne logges ind p alle maskinerne vha. ssh, og dermed v re fuld tilgang til maskinerne. Vi bruger cfengine til at redigere ops tningsfiler. Disse filer opdateres fra tjeneren til klienterne. For at ndre ops tning p klienterne er det nok at ndre ops tningen p tjeneren og lade automatikken sprede ndringerne. Information om alle brugere ligger i en SQL-database. Opdatering af brugere sker op imod denne database. Informationen eksporteres til et LDAP-katalog som bruges af klienterne til brugergodkendelse. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Chapter 4. Installation Installation skal kunne foreg enten fra CD, eller vha. diskette fra tjener. M let er at kunne installere en tjener fra CD, og resten af klienterne over netv rket ved at opstarte alle de andre maskiner fra netv rket. Installatioon skal fungere helt uden tilgang til Internet. Installationen skal ikke stille sp rgsm l, undtagen sp rsm l om sprog (dansk, bokm l, nynorsk osv.) og maskinprofil (tjener, arbejdsstation, tjener til tynde klienter). Al vrig ops tning skal vi s tte automatisk til rimelige v rdier, og lade systemadministrator ndre fra centralt hold efter installationen. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Appendix A. File system access configuration Each Skolelinux user account is assigned a section of the file system on the file server. This section (home directory) contains the user's configuration files, documents, email and web pages. Some of the files should be set to have read access for other users on the system, some should be readable by everyone on the internet, and some should not be accessible for reading by anyone but the user. To ensure that all disks that are used for user directories or shared directories can be uniquely named across all the computers in the installation, they can be mounted as /skole/host/directory/. Initially, one directory is created on the file server, /skole/tjener/home0/, in which all the user accounts are created. More directories may then be created when needed, to accomodate particular user groups or particular patterns of usage. To enable shared file access control using the file groups, each user must be assigned a primary group with no other members. The name of this private group should be identical to the username. [2] This allows for all new files created by the user to be set with full access for the file's group. Together with set-gid bit on directories and inheritance of rights, this enables controlled file sharing between the members of a file group. Therefore, the users' umask should be 00X. [3]. The initial access settings for newly created files is a matter of policy. They may either be set to give read access to everybody, which can later be removed by explicit user action, or they may be initially blocked, necessiating user action to make them accessible. The first approach encourages knowledge sharing, and makes the system more transparent, whereas the second method decreases the risk of unwanted spreading of sensitive information. The problem with the first solution is that it is not apparent to the users that the material they create will be accessible to all other users. This is detectable only upon inspection of other users' directories, where one can see that the files are readable. The problem with the second solution is that few people are likely to make their files accessible, even if they do not contain sensitive information and the content would be helpful to inquisitive users who want to learn how others have solved particular problems (typically configuration issues). Suggestion: The files are initially set to be readable by all, but particular directories are created in which the content is initially blocked. This will simplify deciding whether the file should be made readable or not. Concretely, umask should be set to 002, and ~/ created with priviliges 0775, ~/priv/ given 0750,and ~/pub/ given 0775. Files that should not be readable by others should be put in ~/priv/, whereas public files will be put in ~/pub/. Other files will initially be accessible, but may be blocked as needed. ssh requires that the home directory can only be written to by the owner, thus the maximum access privilege for ~/ is 755. - access to home directories (*~/.)? - home directories - shared directories? ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Appendix B. Stikkord Dette er tilf ldige noter over ting som skal ind i resten af dokumentet • central brugerdatabase med gruppering og mulighed for at styre hvilke grupper som har adgang til (indlogge p ) hvilke maskiner. • gruppering af maskiner og mulighed for at regulere tilgangen til netv rkstjenester for disse grupper (blokere tilgang til Internet via squid) Notes [1] Hm, de tynde klienter har ikke unikke navne p tv rs af LTSP-tjenerne. Hvordan identificerer vi hvilken tynd klient er indlogget hvad p den centrale tjener? [2] More info on private groups is available from Redhat. [3] If all users initially should be able to read newly created files, then X= 2. If only the relevant group should be given initial read access then X= 7.