Functioneel ontwerp Linux WerkPlek

Transcriptie

1 Functioneel ontwerp Linux WerkPlek Inleiding Het project Linux WerkPlek (LWP) beoogt voor verschillende doelgroepen een Linux desktop en bijbehorende infrastructuur aan te bieden. Doelstelling daarbij is te komen tot een voor alle beheerders en gebruikers van die plekken acceptabele standaardisatie. Er zijn verschillende doelgroepen in kaart gebracht. Dit maakt het bepalen van de gewenste functionaliteit van de LWP tot een complexe opdracht. Het eerste doel van het project is dan ook het beschrijven van die doelgroepen en van de wensen van gebruikers uit die doelgroepen. In de projectgroep zitten een aantal vertegenwoordigers van afdelingen waar Unix/Linux gebruik al is ingeburgerd. Zij toetsen de voorstellen voor de functionaliteit van de LWP aan de bestaande functionaliteit van hun Unix/Linux infrastructuur. Hierbij houden zij de belangen van de wetenschappelijk onderzoeker en gevorderde student nauwlettend in de gaten. Vertegenwoordigers van het CIT zitten in de projectgroep om daar waar mogelijk en gewenst centrale oplossingen en ondersteuning aan te dragen. Een volgend doel is het daadwerkelijk realiseren van de werkplek. Daarbij wordt gekozen voor een modulaire implementatie. Doelgroepen kunnen delen afnemen van de aangeboden functionaliteit en deze inpassen in hun huidige systeem of het geheel afnemen voor een centraal beheerde en door een helpdesk ondersteunde LWP. Uitgangspunt is een robuust ontwerp waarbij de belangrijkste functionaliteit locatieonafhankelijk is (je kunt 'overal' inloggen), maar waarbij het werkstation niet onbruikbaar wordt bij uitval van centrale diensten. Linux op de RuG werkplek Afdelingen binnen de RuG waar Linux wordt gebruikt hebben dikwijls een Unix historie. De keuze van Operating Systeem voor die groepen hangt samen met de wens om wetenschappelijke software te kunnen maken voor onderzoeksvraagstukken waar nog geen software voor bestaat. Vaak wordt er bij wetenschappelijke softwareprojecten in internationale verbanden samengewerkt of afgestemd. Hiervoor is het Unix platform nog steeds het meest geschikt. Door verschillen in de gebruikte Unix systemen is de gewoonte ontstaan om de software als broncode uit te wisselen. De beschikbaarheid van compilers en de juiste bibliotheken is dan ook van groot belang voor deze groep.

2 Afdelingen met Linux zonder lange Unix historie herkennen wel de vraag van onderzoekers voor een 'ontwikkelplatform' voor wetenschappelijke software. De LWP neemt de distributie van een ontwikkelplatform als een van de uitgangspunten. Vaak maken bovengenoemde afdelingen ook gebruik van Linux voor onderwijsdoeleinden, voor ondersteuning van lokale activiteiten als lezingen en symposia en voor het regelen van dataverkeer (pipelines, grid) Eigen webservers al of niet gekoppeld aan databases kunnen daar deel van uitmaken. Huidige Linux gebruikers maken bij al deze activiteiten vaak gebruik van de mogelijkheden die de software biedt om 't werk ook op afstand te kunnen doen. Zij achten deze toegang op afstand als essentieel onderdeel van de infrastructuur. De LWP projectgroep wil bovengenoemde functionaliteit waarborgen afhankelijk van de doelgroep. De projectgroep onderkent de grote cultuurverschillen tussen afdelingen en houdt bij het functioneel ontwerp rekening met differentiatie in softwarebehoefte. Maar zij ziet ook mogelijkheden om de krachten te bundelen op het gebied van software. De basis daarvoor is een standaard in softwaredistributie. Een van de kandidaten voor deze standaard is het RedHat Package Manager (RPM) systeem. Software kan dan gemakkelijker worden uitgewisseld. Ook kunnen er voordelen zitten in de gezamenlijke inkoop van software en/of softwarelicenties. Doelgroepen Binnen genoemde afdelingen maken we onderscheid tussen afdelingen waar nu en in de toekomst het beheer decentraal (dus op locatie) wordt uitgevoerd en waar het beheer centraal (door het CIT) wordt uitgevoerd. In het eerste geval kan er ook sprake zijn van decentrale hardware. De projectgroep is zich bewust van de vraag van de onderzoeker naar hardware die soms afwijkt van wat als standaard wordt gezien. Vaak is dit soort hardware goed met Linux te installeren. Voor deze doelgroep zal geen sprake zijn van opgelegde standaardisatie van hardware. De rol die de organisatie achter de LWP hier kan spelen is die van ondersteuner van speciale hardware door het verzamelen en beschikbaar stellen van de laatste drivers. Deze beheerders staan dicht bij de eindgebruikers. Deze gebruikers willen geen functionaliteit inleveren. Voor de beheerders zit de meerwaarde van de LWP in een mogelijke tijdwinst als basis beheerswerkzaamheden en helpdeskactiviteiten uitbesteed kunnen worden. Zij kunnen zich dan toeleggen op voor de afdeling

3 speciale hardware en softwareactiviteiten. Het is hierbij belangrijk dat zij hun eigen infrastructuur kunnen 'mengen' met delen van de LWP infrastructuur. Besloten is dan ook om de LWP zoveel mogelijk modulair aan te pakken met het accent op standaard protocollen. Voor de afdelingen die gekozen hebben om een centraal beheerde LWP af te nemen, is het belangrijk dat er een goed werkende helpdeskondersteuning komt. Op dit moment is die ondersteuning er niet of niet voldoende. Aan uitbreiding wordt gewerkt. Van belang hierbij is dat we onderkennen dat de activiteiten van een helpdesk voor de LWP behoorlijk kunnen verschillen met die voor Windows. Met name het aantal applicaties dat onder een LWP zal worden aangeboden is enorm. Er is ook veel overlap tussen applicaties. De doorsnee Linuxgebruiker stelt het op prijs te kunnen kiezen welke desktop hij/zij gebruikt, welke inlogshell wordt opgestart en welke programmeertaal hij/zij gaat gebruiken. Linuxgebruikers zijn hierbij gewend hun helpdesk niet te 'overvragen'. De LWP voor bovengenoemde afnemers kent de meeste hindernissen. De projectgroep heeft daarom besloten om deze eerst te duiden en vervolgens op te schalen naar een studentenwerkplek. Studenten zijn een aparte doelgroep. We moeten er rekening mee houden dat de student zal kiezen voor het gebruik van de LWP om dezelfde reden als waarom hij/zij nu Linux gebruikt of wil gaan gebruiken op bestaande Linux werkplekken voor studenten. De student kiest voor de LWP omdat deze anders is dan de UWP. De redenen zijn uiteenlopend. De beschikbaarheid van bepaalde software, de mogelijkheid om software zelf te maken of dat van anderen te kunnen bewerken en te compileren spelen een rol. Maar ook het gevoel meer controle over het systeem te hebben kan een rol spelen bij een student die kiest voor Linux. We moeten er dus voor waken dat de LWP niet een soort UWP wordt. We kennen de wensen van deze studenten niet bijzonder goed. Een standaard werkplek met software uitbreidingen die locatieafhankelijk zijn lijkt genoeg. De studenten moeten wel in staat worden gesteld om applicaties te kunnen ontwikkelen. Hier moet rekening worden gehouden bij het regelen van file permissies en andere veiligheidsoverwegingen. Als laatste doelgroep noemen we toekomstige gebruikers die om uiteenlopende reden de LWP willen proberen. Mogelijk lopen zij tegen de beperkingen van een Windows omgeving aan en willen daarom eens kijken of het gebruik van een OS gebaseerd een langere traditie in onderzoek voordelen biedt Anderen willen Linux proberen uit nieuwsgierigheid en zullen Linux met Windows willen vergelijken in termen van kantoorgebruik. Voor deze laatste groep is het belangrijk dat er een selectie van applicaties wordt gemaakt waarvoor de helpdesk goede ondersteuning kan bieden. De projectgroep heeft weinig kennis van deze doelgroep. Wel houdt zij rekening met de mogelijkheid dat door deze groep in de toekomst opschaling van de LWP nodig zou kunnen zijn.

4 FO: De doelgroepen voor de LWP zijn: 1) Huidige Linux gebruikers met decentraal beheer 2) Huidige Linux gebruikers met centraal beheer 3) Studenten die reeds Linux gebruiken 4) Studenten en medewerkers die om uiteenlopende reden in de toekomst de LWP willen gaan gebruiken. Doelen LWP Algemeen doel van de projectgroep is het definieren en implementeren van een, op doelgroep gerichte, optimale inrichting en organisatie van werkplekken met Linux als besturingssysteem om bestaande en toekomstige gebruikers een 'Open Source' platform te bieden ter ondersteuning van het wetenschappelijk bedrijf. De projectgroep definieert een aantal gemeenschappelijke doelen en een aantal doelen die specifiek zijn voor een doelgroep. Zij komt regelmatig samen om de LWP te bespreken. Deze bijeenkomsten zijn de enige waar Unix/Linux beheerders bij elkaar komen en ervaringen uitwisselen. Deze kennisuitwisseling is van grote waarde gebleken. De bijeenkomsten vinden plaats onder de vlag van het CIT maar het is duidelijk een project van de vertegenwoordigers van de diverse doelgroepen. Meningsverschillen, al of niet met een historische achtergrond, dwingen de leden van de projectgroep goed na te denken over de keuzes die zij of anderen maken op het gebied van hardware, software en organisatie. Werd eerst nog de indruk gewekt dat de LWP de Linux variant van de UWP zou worden, dan zien we nu toch steeds meer het gebruik en de wensen van de onderzoeker centraal staan; de LWP is geen verzameling van kantoorapplicaties. We denken dat de LWP hierdoor meer bestaansrecht heeft gekregen. 1) Een eerste doel van het project is om bijeenkomsten te blijven organiseren waar we nadenken over een optimale inrichting van Linux voorzieningen en de organisatie rond die voorzieningen. Nieuwe inzichten kunnen zo onmiddellijk in het ontwerp van de LPW worden verwerkt. Om namens gebruikers te kunnen spreken moeten we goed weten wat die gebruikers van de LWP verwachten. Hiervoor zijn korte gesprekken gehouden met een aantal gebruikers op diverse afdelingen. Het probleem hierbij is dat de genoteerde wensen niet gemakkelijk naar een functioneel ontwerp kunnen worden vertaald omdat er te weinig geinterviewden waren. Bovendien waren ze niet willekeurig gekozen en niet altijd goed op de hoogte van de mogelijkheden van ICT.

5 2) De projectgroep stelt als doel een kanaal te openen waarover gebruikers uit de diverse doelgroepen hun wensen kenbaar kunnen maken en hun opmerkingen over de LWP kunnen plaatsen. Op dit moment wordt een startpagina bij het CIT ontwikkeld. Het plan is om hier een forum te openen en de huidige LWP wiki onder te brengen. Hierdoor sluiten we aan op de in de Linux/Open Source wereld gebruikelijke traditie van wisselwerking met gebruikers. De LWP krijgt een achterliggende infrastructuur die belangrijk is voor beheerders en eindgebruikers. Op het gebied van hardwareinfrastructuur mag dit duidelijk zijn. Falende hardware of slecht geconfigureerde hardware treft de eindgebruiker direct. Dit is de reden waarom bij de projectgroep de discussie vaak gaat over de voor en nadelen van centralisatie van hardware. Als voordeel wordt efficient beheer genoemd van robuuste en redundant uitgevoerde hardware. Als nadeel wordt genoemd dat bij uitval veel gebruikers tegelijk worden getroffen en dat is ook een kostbare zaak. Bovendien is er in die gevallen sprake van een onredelijk grote druk op de beheerders van dergelijke systemen. Voor doelgroep 1, gebruikers met decentraal beheer met eigen hardware, kan de LWP alleen winst opleveren op onderdelen. We vinden dan ook de modulaire opbouw van de technische implementatie van groot belang. Voorbeelden van dergelijke infrastructurele onderdelen zijn bijvoorbeeld centrale (RuG) authenticatie en/of centraal beheerde login of homedirectories. Ook image servers of installatie servers vallen in deze categorie. Wat kunnen de decentrale beheerders hier mee winnen? Uitgaande van de tijd die je zou kunnen besparen op standaard werkzaamheden met standaard oplossingen, zit de winst in de verschuiving van de werkzaamheden naar meer specialistische zaken als beheer van locatiespecifieke hardware en software. Voor wat betreft het beheer van afgenomen LWP onderdelen zien we organisatorische winst omdat in gevallen van calamiteiten (b.v. uitval hardware tijdens onderbemanning door ziekte) door gespreide kennis de kans groter is dat er binnen de RuG adequate ondersteuning kan worden gevonden. 3) De projectgroep kiest voor een modulaire opbouw van de technische infrastructuur zodat ook onderdelen van de LWP afgenomen kunnen worden. Dit maakt de LWP ook interessant voor beheerders van bestaande Linux systemen. Andere doelgroepen zullen alleen de desktop als onderdeel van de LWP gaan afnemen. Zij vertrouwen op de achterliggende infrastructuur. We willen graag nadenken over de meerwaarde van de LWP boven de UWP in termen van robuustheid. Hoe kunnen we (delen van) de LWP blijven gebruiken als we geen verbinding meer hebben met centrale servers? Kunnen we bijvoorbeeld werken met een lokaal profiel?

6 4) De projectgroep streeft naar een LWP die ook nog bruikbaar is als centrale servers niet bereikbaar zijn. Een andere belangrijke component van de LWP infrastructuur is de softwarevoorziening. Afgesproken is dat software op een standaard manier wordt gedistribueerd. Aangesloten werkplekken krijgen daardoor allemaal hetzelfde basispakket aan software. Voor studenten betekent dit dat ze in alle pc zalen waar de LWP beschikbaar is, over dezelfde software en bibliotheken kunnen beschikken en dat de versies van die software overal hetzelfde is. Voor anderen kan een flexibel distributiesysteem belangrijk zijn om juist af te kunnen wijken van de standaard. In het systeem van softwaredistributie zit ook een systeem verwerkt voor softwarereparaties ('patching') en bijwerken van de veiligheid van de software ('security updates'). 5) De LWP wordt van software voorzien middels gestandaardiseerde distributiemethoden. Doel is om deze distributie zoveel mogelijk te automatiseren. Voor beheerders zien we hier tijdswinst als voordeel. Gebruikers krijgen een frequent bijgewerkte verzameling applicaties. Voor het basispakket valt de software geheel onder de definitie van 'Open Source'. De projectgroep heeft nog niet een duidelijk beeld van de beschikbaarheid van de LWP. Waar kan men straks inloggen en waar niet. Willen we de beschikbaarheid dezelfde maken als voor de UWP? We kunnen hier wel naar het doel van algehele beschikbaarheid streven, maar in dit geval zullen we ook moeten kijken naar de techniek. Er is nog niet beslist of de LWP via een 'image' aanbieden of het gehele systeem op de pc installeren. In het eerste geval kan je de LWP in het bootmenu aanbieden. Als we kiezen voor het andere geval dan kunnen we ook gaan denken om voor zowel de UWP en de LWP het alternatieve OS via een virtuele machine (b.v.vmware) aan te bieden. Voor de doelgroep 4, de 'kennismakers' is er dan geen enkele drempel om een alternatief OS uit te proberen. Bevalt dat OS dan zo goed dat dit het primaire OS moet worden, dan zal je een en ander opnieuw moeten installeren. 6) Het streven is om de LWP op zoveel mogelijk plekken beschikbaar te stellen. De manier waarop hangt af van de doelgroep en de gebruikte techniek. Dit maakt het werken met de LWP locatieonafhankelijk en niemand wordt uitgesloten van de mogelijkheid om kennis te maken met Linux. In theorie is het aanbieden van een desktop voor grote groepen een prima gelegenheid om te standaardiseren. In praktijk blijkt dit echter vooral voor software niet werken. Niet alleen verschillende doelgroepen vragen om verschillende software, ook binnen onderzoeksgroepen verschilt de vraag.

7 Mogelijkheden tot differentiatie moeten niet achteraf worden ingebouwd. Zij moet als uitgangspunt dienen van de LWP. Hiervoor lenen we het begrip softwarekanalen van RedHat. Een specifieke groep LWP gebruikers kunnen voor hun werk extra software installeren op machines waarover die groep het beheer heeft. En kanaal stelt de groep ook in staat om software af te schermen waarvoor zij zelf licenties betaald heeft. Het mag duidelijk zijn dat deze kanalen ook nuttig kunnen zijn voor onderwijs clusters. 7) De projectgroep heeft als doel een LWP te ontwerpen waarbij differentiatie en uitbreiding van software tot de basismogelijkheden behoort (specialisatie d.m.v. kanalen). Zij probeert hiermee zoveel mogelijk aan de wensen van onderzoeksgroepen te voldoen. Hierbij moeten we onmiddellijk aantekenen dat het onderhoud van software in die kanalen een probleem kan opleveren. Stel dat je centraal op een nieuwe versie van je distributie overgaat. Je wijzigt hiermee versies van bibliotheken waarvan software in de kanalen afhankelijk zijn. Het ligt voor de hand dat de belanghebbende zelf die software gaat bijwerken. Deels zal dat 'met de hand' moeten. Dit vraagt om een goede afstemming met de beheerders van het basiskanaal, maar hoe gaat dat dan in de praktijk in z'n werk? Dit is een van de vele problemen die we tegenkomen die niet specifiek met het technisch of functioneel ontwerp te maken hebben. Deze problemen vallen in de categorie organisatie. In principe is deze categorie nog steeds het meest gevuld met onbeantwoorde vragen. Voor het beheer van machines geldt ook iets dergelijks. Voor de groepen met decentraal beheer is het belangrijk te weten wat de rechten van dat beheer gaan worden op de centrale servers (bijvoorbeeld om configuraties te kunnen aanpassen). Wie gaat bepalen wat de default instellingen worden van een machine? Hoe gaat het straks met softwarelicenties? Wat wordt de rol van de facultaire demand manager Komen er SLA's voor LWP onderdelen? Wie bepaalt waar de balans ligt tussen 'cutting edge' en bewezen stabiele software? Wie bepaalt, of hoe bepalen we dat er een nieuwe versie van een distributie moet komen? Hoe organiseer je de helpdesk? Wat is je scenario als deze helpdesk het heel druk krijgt of niet voldoende is uitgerust voor haar taak? Wie bepaalt, of hoe bepalen we gebruikersrechten. Wie bepaalt, of hoe bepalen we de veiligheidsinstellingen op een machine? Wat doen we met het verzoek van een gebruiker om 'root' mogen te worden op zijn/haar machine? Wat wordt de organisatie rond de bepaling van gebruikers quota? Wat doen we met verzoeken van grootverbruikers (Gb en Tb gebruikers)? Wat doen we met accountverzoeken van mensen die (nog) geen p nummer hebben of deze niet kunnen krijgen omdat de b.v. gast zijn? 8) De projectgroep stelt zich als doel de haalbaarheid van de voorgestelde

8 functionaliteit en 't beheer van de LWP te toetsen aan de voorgestelde achterliggende organisatie. Daar waar mogelijk wil zij ook die organisatie beschrijven. Dit maakt het voor gebruikers duidelijk wat de overwegingen achter bepaalde beslissingen zijn geweest en hoe die beslissingen tot stand zijn komen. Deze transparantie wekt vertrouwen en zal bijdrage tot een snelle acceptatie van de LWP als service. Randvoorwaarden: 1) Flexibiliteit: Voor beheerders en gebruikers moet de LWP net zo flexibel zijn als de huidige werkplek. De gebruiker wil geen functionaliteit inleveren. De beheerder (centraal of de centraal) wil de mogelijkheid behouden om snel machines en/of accounts te kunnen toevoegen. Geïnterviewde gebruikers zijn bang voor langere lijnen en bureaucratische vertraging bij verwerking van verzoeken/wensen. 2) Lokale aanpassingen: Aanvullend op het eerste punt: het moet mogelijk blijven om in overleg met beheerders op zeer korte termijn lokaal op het werkstation een setting aan te passen of nieuwe software te installeren. 3) Gemeenschappelijke basis met mogelijkheid voor lokaal sausje : Binnen de projectgroep is er groot draagvlak voor het idee dat het mogelijk moet zijn een gemeenschappelijke basis te ontwerpen. Bovenop die basis moeten dan faculteits /dienstspecifieke aanvullingen op eenvoudige wijze kunnen worden geïnstalleerd en tenslotte moet de gebruiker in staat zijn om zijn/haar eigen specifieke wensen te kunnen realiseren met betrekking tot bijvoorbeeld de configuratie van een desktop en voor het gebruik van onderzoeks of onderwijsdoeleinden benodigde software. 4) Externe ondersteuning: Een aantal faculteiten/diensten gaven aan het van belang te vinden dat wordt gekozen voor een variant die het mogelijk maakt extern support in te kopen in het geval van problemen die niet of niet tijdig opgelost kunnen worden. Dit betekent dat voor het technisch ontwerp in elk geval voor een distributie zal moeten worden gekozen die die mogelijkheid biedt.

9 5) Support voor Windows only: Enkele geïnterviewden gaven aan uit hoofde van hun werkzaamheden regelmatig te moeten werken met software die alleen onder windows draait. Specifiek werden Xopus (de editor van het webplatform) en Powerpoint genoemd. Voor Xopus is een platformonafhankelijke variant in de maak. Typische Windowsapplicaties als Powerpoint kunnen niet worden ingeruild voor open source alternatieven omdat je nooit een 100% compatibiliteit kunt verzekeren. Er zal support moeten worden geboden voor toegang tot deze applicaties. Het aanbieden van de UWP onder VMware kan hiervoor een oplossing zijn. Hier en daar wordt deze manier van werken reeds met succes toegepast. 5) Open Source: Gestreefd zal worden naar het gebruik van zoveel mogelijk 'Open Source only' software. Open source is inherent aan de LWP maar laten we in het kort toch even de meest gehoorde voordelen noemen (diverse bronnen): Betere kwaliteit: OSS heeft een eigen ontwikkelmodel. De software evolueert zeer snel tot robuust, stabiel en onderhoudsvrij software. Bovendien worden fouten snel opgespoord en in een hoog tempo hersteld. Hoge innovatiesnelheid: door het publiceren van oplossingen voor problemen binnen de kennisnetwerken van programmeurs over het Internet is de Open Source gemeenschap een grote motor achter de ontwikkeling van nieuwe software technieken. Minder kosten: gebruikers van OSS hoeven niet per se te betalen voor de aanschaf ervan, noch voor de eventuele upgrades. Bovendien gaan veel OSS programma's veel economischer om met systeemvereisten. Hierdoor ben je minder afhankelijk van nieuwe hardware / nieuwe besturingssoftware. User driven: de ontwikkeling van Open Source software wordt hoofdzakelijk gedreven door de wensen van de gebruiker. Gebruikers hebben veelal direct contact met ontwikkelaars van de software. Door de gebruiker gewenste uitbreidingen worden bij een voldoende draagvlak in het product verwerkt. Indien het draagvlak ontbreekt heeft de gebruiker de vrijheid om gewenste functies zelf aan de software toe te voegen (of te laten toevoegen). We kunnen de ogen niet sluiten voor de problemen die bedrijven elkaar blijven geven als het gaat om beschuldigingen van plagiaat in de open source wereld. De bedrijven achter de grotere Linuxdistributies zullen hun afnemers daarvoor een zekere bescherming moeten bieden. Dit is een factor die kan meespelen in het besluit over de te gebruiken Linux distributie. Voor groepen die licenties hebben voor speciale bibliotheken of applicaties, moet van de strikte open source richtlijn kunnen worden afgeweken. Met name zal dit software zijn die alleen in specifieke 'kanalen' wordt opgenomen of mogelijk

10 zelfs helemaal niet in een distributiesysteem wordt opgenomen. Nu worden dergelijke licenties vaak door de gebruikers zelf geregeld en betaald. We weten nog niet wat de rol wordt van de demand manager m.b.t. deze speciale software, maar ook hier geven geinterviewden aan dat flexibiliteit en snelle respons belangrijk is. De huidige stand van zaken is dat het regelen van b.v. RedHat licenties via faculteit en Surfnet verre van optimaal is. 6) Beheerstools: Speciale aandacht voor beheerstools. Gereedschappen voor het aanmaken van (lokale) accounts, voor monitordoeleinden en voor beheer van de applicaties. 7) Support vanuit Servicedesk: Bij de servicedesk moet voldoende expertise voorhanden zijn om ondersteuning te bieden aan Linux gebruikers. De kennis van applicaties en configuraties dient beperkt te worden tot een vaste selectie. Voor overige problemen is de ondersteuning beperkt. De reden is de enorme hoeveelheid applicaties waaruit een keuze gemaakt kan worden en de uiteenlopende kwaliteit van die applicaties. 8) Beschikbaarheid Role Definitions: Om beheerders en gebruikers snel de omgeving te bieden die ze nodig hebben, moeten de bijbehorende 'role definitions' beschikbaar zijn voor de uitrol van het LWP. Karakteristieken LWP Nomaals de doelgroepen: 1) Huidige Linux gebruikers met decentraal beheer 2) Huidige Linux gebruikers met centraal beheer 3) Studenten die reeds Linux gebruiken 4) Studenten en medewerkers die om uiteenlopende reden in de toekomst de LWP willen gaan gebruiken. Scope: De infrastructuur van de LWP wordt modulair opgebouwd. Zij wordt geheel of in onderdelen getest door gebruikers uit de doelgroepen alvorens te worden

11 uitgerold. De uitrol zal plaatsvinden voor groepen met voldoende ruimte in de planning voor het verwerken van ervaringen van gebruikers en beheerders zodat aanpassingen tussendoor goed mogelijk zijn. Uitgangspunt is het dynamisch karakter van de LWP. Opbouw: Aangezien het aanbod aan software van de diverse Linux distributies niet veel van elkaar verschilt wordt gezocht naar een basisdistributie met beheertechnische voordelen. Een goede aansluiting op de 'Open Source' traditie is belangrijk. Er zal nader onderzoek plaatsvinden naar de eigenschappen van in ieder geval de enterprise versies van RedHat en SuSe. De enterprise versies bieden een basis infrastructuur die geschikt is voor professioneel gebruik. Standaard applicatiesoftware: Elke distributie komt met voldoende kantoorapplicaties. Bij de meeste toepassingen heeft een gebruiker keuze uit meerdere applicaties. Deze keuze wordt in stand gehouden maar wel zal de helpdesk zich specialiseren op een selectie van applicaties. Belangrijk is de LWP als ontwikkelplatform. Met name de Gnu compilers vormen de kern hiervan. Speciale aandacht zal worden besteed aan het actualiseren van de Java omgeving. Overige Applicaties: Bovenop deze standaard distributie wordt een standaardmethode gehanteerd om extra software te distribueren. Dit zal gebeuren via een software "kanaal model". Dit houdt in dat extra applicaties gegroepeerd zullen worden naar type, gebruikersgroep of faculteit/dienst (of een combinatie hiervan) zodat op basis van machinetype, faculteit/dienst of soort gebruiker een of meerdere van deze kanalen geactiveerd kunnen worden (een gelaagd applicatiemodel). De werkplek wordt dan automatisch voorzien van de voor die locatie of gebruiker specifieke extra applicaties. Door gebruiker ingebrachte applicaties: Het is mogelijk voor gebruikers om zelf applicaties aan te dragen voor opname in een kanaal. Dit kan van belang zijn voor onderzoeksgroepen waar één gebruiker voor de hele groep een voor die groep specifieke applicatie onderhoudt. Voorwaarden zijn wel dat deze applicatie wordt aangeleverd op een manier die inpasbaar is in de distributiemethodiek en er goedkeuring is van beheer. Updates/patches: Ook voor updates en patches zal een kanaal model gebruikt

12 worden. Met behulp van speciale management software kunnen noodzakelijke patches gekoppeld worden aan een specifiek kanaal, machinetype of zelfs individuele machine en op die manier verspreid naar de werkplekken (hetzij geïnitieerd door de gebruiker dan wel door beheer). Dit maakt het mogelijk om alle Linux werkplekken binnen de RUG met minimale inspanning te voorzien van de laatste patch niveaus. Beta software: Voor de nieuwste releases van software, betas en experimentele software zal een eigen kanaal (e.g. Beta kanaal) gebouwd worden, waar gebruikers desgewenst gebruik van kunnen maken. Support hierop zal van lager niveau zijn dan op overige software. Daar waar nieuwe hardware vraagt om beta software om goed te kunnen functioneren, zal gepaste support worden verleend. In de praktijk komt deze ondersteuning neer op het goed kunnen zoeken naar de gewenste/geschikte beta software binnen de gebruikte distributie en het op kunnen zetten van een adequate testprocedure. Beta software voor speciale configuraties leveren een ander probleem op. Als praktijkvoorbeeld kunnen we noemen het geval van een groep die een machine wil configureren waarbij disk i/o zo snel mogelijk moet zijn (b.v een database server). Zij willen het door de distributie ondersteunde file systeem vervangen door xfs dat weliswaar niet geheel beta is maar toch niet wordt ondersteund door de distributie. We moeten dan vragen beantwoorden als: 1) Hoe ver gaat je ondersteuning voor dit project? 2) Wat wordt de status van een dergelijke machine? Beheer: Voor het beheer van de werkplek zal gebruik gemaakt worden van een beheerstool. Deze tool is in staat om: Op afstand het patchniveau van OS software en applicaties van een werkstation uit te lezen. Automatisch patches of software te distribueren, hetzij geinitieerd door de gebruiker dan wel door beheerders, direct of gescheduled. Op afstand een minimale set hardware informatie van het werkstation uit te lezen. Ondersteuning te bieden voor de applicatiedistributie m.b.v. kanalen.. Authenticatie: Voor toegang tot de werkplek zal gebruik gemaakt worden van het centrale RUG account (s nummer respectievelijk p nummer). Het voordeel voor de gebruiker is dat hij in combinatie met centrale storage onafhankelijk van gebruikte werkplek/werkstation dezelfde desktop en software kan gebruiken en bovendien hiervoor dezelfde usernaam wachtwoord combinatie kan gebruiken die hij

13 ook voor andere diensten gebruikt. Daarnaast simplificeert dit het beheer (slechts 1 account waarin wachtwoordproblemen etc. kunnen optreden). Met het oog op onverhoopte downtime is het nodig om het gebruik van lokale accounts (per werkplek of per lokaal netwerk) expliciet mogelijk te maken, en voor de centrale accounts te voorzien in lokale caching, of een andere vorm van redundantie. Voor zover lokale beheerders niet in hun eigen accounts voorzien kunnen groepen gebruikers middels role definitions collectief worden toegelaten of uitgesloten van bepaalde voorzieningen (bijvoorbeeld toelating van een bepaalde groep studenten tot bepaalde practicumservices). Storage (bestandsopslag): De Linux werkplek zal gebruik maken van een combinatie van lokale en centrale storage. Zowel lokale schijfruimte (op de PC), als centrale storage op instituuts faculteits of centrale SAN's zal bereikbaar zijn. Profielen worden op centrale storage opgeslagen, zodat onafhankelijk van het gebruikte werkstation de gebruiker zijn/haar vaste desktop en software kan gebruiken. De centrale storage kan daarnaast worden gebruikt voor het opslaan van bestanden die op andere (Windows dan wel Linux) werkplekken gebruikt moeten worden, bestanden waarvan het van belang is dat ze gebackupped worden, of waartoe op externe locaties waar slechts een webbrowser beschikbaar is toegang toe moet worden geboden. Externe toegang tot de werkplek: Momenteel is het bij vrijwel alle diensten/faculteiten gebruikelijk dat de gebruiker van externe locaties de mogelijkheid geboden wordt te werken op een Linux werkplek van de RUG. Dit gebeurt veelal door toegang te bieden middels ssh. Deze functionaliteit dient ook in de nieuwe situatie te worden ondersteund. Hardware: Voor standaard gebruikers kan gestreefd worden naar uniformiteit van hardware. Dit kan voordelen opleveren bij de inkoop en een software probleem dat is opgelost voor 1 pc is ook opgelost voor identieke hardware. Met name kunnen we hierbij denken aan grafische kaarten. De LWP sluit verder aan bij de Linux traditie om een breed scala aan hardware te ondersteunen. De huidige Linuxgebruiker is gewend aan vrijheid van hardwarekeuze zodat snel kan worden aangehaakt bij nieuwe ontwikkelingen. Deze keuzevrijheid kan zich mogelijk wel vertalen in een lager niveau van ondersteuning. In de interviews met gebruikers kwam de ondersteuning van USB sticks ter sprake. Veel gebruikers zijn van mening dat Linux onvoldoende ondersteuning biedt voor

14 het gebruik van USB sticks. Zij geven aan deze ondersteuning wel belangrijk te vinden. Wat kunnen we met deze informatie. De ondersteuning zal vanuit de distributie moeten worden geregeld. Dit is niet iets wat het beheer van de LWP kan oplossen. Als er al een distributie is die meer ondersteuning biedt dan een andere distributie, maakt dat dan de keuze voor een distributie gemakkelijker? Zijn er niet heel veel andere zaken die een rol spelen? We kunnen ons afvragen of we gebruikers wel de goede vragen stellen. Nu we doelen en doelgroepen in kaart hebben gebracht, lijkt het een goede zaak om gebruikers te betrekken bij hardware keuzes middels het eerder voorgestelde forum. Disk quotum: Momenteel hebben studenten een quotum van 500 MB. Dit wordt als afdoende ervaren. In de Linuxpraktijk zullen studenten net als medewerkers steeds meer applicaties openen die profielen schrijven in de home directory. De LWP zal flexibel omgaan met verzoeken het quotum (al dan niet tijdelijk) te verhogen. Persoonlijke PC's met lokale diskopslag zijn te benaderen door gebruikers die eigenaar zijn van een directory op een dergelijke PC. De data moet dus voor die personen over het net beschikbaar zijn. Afdelingen kunnen beschikken over lokale netwerkopslag voor lokale gebruikers. Centrale (bulk )opslag wordt ook mogelijk gemaakt. File permissies: Met name studenten geven aan dat de bestaande methodiek van file permissies niet afdoende is. Regelmatig moet werk met medestudenten worden gedeeld. Dit kan nu alleen op basis van groepen. De Linux werkplek zal gebruik gaan maken van zogenaamde Access Control Lists (ACL) om fijnmazigere toegang tot bestanden te bieden. Installatie: De LWP zal door middel van unattended installs en/of images worden geïnstalleerd. Beschikbaarheid/uptime: Er wordt getracht nieuwe technieken toe te passen om de beschikbaarheid van de LWP zo hoog mogelijk te maken. Na analyse van een aantal Linuxomgevingen kunnen we tot de conclusie komen dat de voorwaarde om op willekeurige PC's te kunnen inloggen het nodig maakt dat inlogdata centraal wordt opgeslagen. Op dit moment worden daar file servers voor gebruikt. Uitval van een dergelijke file server is ernstig want veel applicaties maken gebruik van de home directory. Alleen applicaties die geschikt zijn gemaakt om lokaal te

15 draaien zullen blijven werken. De conclusie mag duidelijk zijn. Voor het beheren van profielen dient de centrale hardware zeer robuust te zijn en de verbindingen snel. In het technisch ontwerp zal de meerwaarde t.o.v. locale fileservers direct moeten blijken. Hierin spelen ook financiele overwegingen een rol. Uitval raakt immers een grotere groep dan bij decentrale opslag. De projectgroep zoekt naar een techniek die het mogelijk maakt om decentrale servers te combineren met centrale servers om volgens het 'verdeel en heers' principe een maximale beschikbaarheid van de LWP mogelijk te maken. Een ander essentiele schakel is de authenticatie. De ervaring leert dat een Linuxsysteem erg gevoelig is voor uitval van de authenticatieserver. Voor de authenticatieserver geldt dus ook het eerder genoemde principe van terugval op decentrale hardware. Hierbij moet het ook mogelijk zijn om buiten het centrale p nummer authenticatiesysteem om, gebruikers zonder p nummer toe te kunnen voegen voor gebruik van systemen op de afdeling waar deze gebruiker aan gekoppeld is. Hierdoor waarborgt de LWP de flexibiliteit die bij het huidige Linuxgebruik wordt aangetroffen. Configuratieaanpassingen door beheer: Wat wordt de rol van de decentrale beheerder? Veel van de kwaliteit van de beheerders en de achterliggende organisatie wordt afgemeten naar de snelheid waarmee nieuwe gebruikers aan een systeem kunnen worden geholpen of de snelheid van migraties van systemen naar nieuwere versies. Voor een functioneel ontwerp moeten we dan de stappen volgen die een huidige beheerder maakt om een nieuw systeem te installeren. Een nieuwe machine wordt geidentificeerd met macadres (dhcp). Een machine wordt aangemeld bij een installatieserver en krijgt een unieke id. Configuratie is afhankelijk van de hardware. In RedHat termen wordt nu een kickstart file uitgevoerd waarin de configuratie van de aangemelde machine staat beschreven. Een abstractie van deze file zou een z.g. configuratieserver kunnen zijn. Na installatie volgt een aanmelding voor een of meerdere softwarekanalen. Een post install volgt. Een nieuwe gebruiker krijgt centrale rechten (p nummer account) en eventueel lokale rechten. Centrale, maar ook decentrale beheerders die een LWP installeren moeten tot alle relevante files toegang hebben. Uitgezocht moet worden hoe de voorgestelde flexibiliteit ook veilig kan zijn. Je wilt immers niet dat een per ongeluk ingebrachte foutieve regel in een lijst met macadressen de werking van alle werkplekken in de lijst verstoord. Mogelijk zijn nieuwe technieken gebaseerd op Tripwire en/of CVS toepasbaar om ongelukken te voorkomen. Door de modulaire opbouw van de LWP kan een decentrale beheerder ook z'n eigen configuratieserver blijven gebruiken. Configuraties door eindgebruiker: Zoals eerder beschreven gaan Linuxgebruikers er van uit dat ze een hun systeem uitgebreid en flexibel kunnen configureren. Configuraties worden normaliter op de home directory opgeslagen. Bij een

16 herinstallatie van een systeem blijven deze configuraties behouden. Dat geldt in mindere mate voor een migratie naar nieuwere versies van een distributie. Zelfgemaakte applicaties of zelf geinstalleerde software, opgeslagen onder de home directory blijven ook behouden. Voor sommige gebruikers is de beschikbaarheid van dergelijke software op meerdere werkplekken belangrijk. Er zal dan ook flexibel met de quotering moeten worden omgegaan. Zeggenschap machines: Machines voor dataverwerking en analyse zullen snel een persoonlijk karakter dragen omdat ze dikwijls zijn opgetuigd met speciale hardware. In de meeste gevallen is de gebruiker ervan ook een soort beheerder van de machine. Toch past het niet in een professionele omgeving om een dergelijke gebruiker root rechten te geven. In het verleden zijn hier en daar wel dergelijke rechten aan gebruikers verleend en in veel gevallen is dat i.v.m. de veiligheid niet een goede keus geweest. Indien een gebruiker staat op root rechten dan verandert de status van een desktop in die van een laptop. Voor laptops gelden andere regels. De beperkingen op het netwerk zijn duidelijk. Vaak worden ze opgenomen in speciale, met een firewall beveiligde netwerken opgenomen. Voordelen zijn de absolute controle over de machine. Nadelen zijn: Een beperkte toegang tot opslag via het netwerk Een grote verantwoordelijkheid voor de veiligheid van de 'eigen' machine Geen support voor installaties en configuraties. Geen patching en updates. Persoonlijke firewalls zijn geen alternatief voor een beveiligd apart netwerk omdat iemand deze firewall met root rechten kan wijzigen. Bovendien ontbreekt dikwijls de kennis bij gebruikers om dergelijke firewalls goed te configureren. Door de toename van laptopgebruik moeten we scherp in de gaten houden wat de meerwaarde is van de LWP. Systeem en netwerkveiligheid: De veiligheid van de LWP systemen wordt gecontroleerd door de security manager van de RuG. We identificeren de zwakke punten in de organisatie en beveiligen deze extra. Hierbij zoeken we de balans tussen veiligheid en functionaliteit. We kunnen b.v. het gebruik van onversleutelde protocollen onmogelijk maken maar we willen wel een goede toegang op afstand op machines op het werk. Binnen een afgebakend netwerk is triviaal. Voor toegang vanaf een locatie buiten zo'n netwerk zou je gebruik moeten maken van een 'inlogserver'. Deze authentiseert en bepaalt tot welke machines een gebruiker toegang heeft. Hiermee voorkom je dat een gebruiker van een zekere afdeling vanuit huis een allerlei processen gaat starten op beschikbare machines in een studentencluster van een andere afdeling. We zoeken naar een techniek die

17 maximale veiligheid biedt bij een minimale administratieve inspanning. Voor de toegang op afstand tot de systemen zal ssh worden gebruikt. De firewalls zullen zo worden geconfigureerd dat men X kan tunnelen zodat ook remote X applicaties kunnen worden opgestart. Gebruikers dienen op de hoogte te zijn van de gevaren van 'social engineering' voor de veiligheid van systemen. In een starters guide voor de LWP dienen diverse aspecten van veilig computergebruik te worden opgenomen. Wellicht dienen hierin ook aangepaste regels voor de 'acceptable use policy' te worden opgenomen. Webservers, ftp servers: Er zijn voldoende voorbeelden van onderzoeksgroepen die een eigen ftp server en een eigen webserver in de lucht houden. De LWP maakt het gebruik van deze services niet onmogelijk. Achterliggende organisatie: De rol van de achterliggende organisatie rond de LWP is afhankelijk van de afgenomen modules. Welke modules er ook worden gebruikt, men heeft altijd te maken met een opgesplitste organisatie. Een decentrale beheerder in de oude situatie is iemand die tegelijk netwerkbeheerder, serverbeheerder en helpdesk is. In principe zal deze beheerder dus snel en efficient kunnen werken. In de nieuwe situatie moet een gebruiker via een helpdesk mondeling een probleem voorleggen. De helpdesk moet dan besluiten of het probleem server of netwerkgerelateerd is. Wellicht moeten de twee afdelingen overleggen, maar dat zal waarschijnlijk via de helpdesk gaan. Deze koppelt dan weer terug met de klager. Uiteindelijk blijkt dat het (hypothetisch) probleem met de Java omgeving te maken heeft. De Java specialist werkt echter alleen op maandag en wel in het biologiegebouw. Hoe goed dit systeem ook zal worden georganiseerd en hoe goed gemotiveerd het personeel ook is, je zult moeten inleveren t.o.v. de oude situatie. Een mogelijke verbetering zou de mogelijkheid zijn om via de helpdesk een 'vliegende keep' te kunnen regelen. Deze persoon is gespecialiseerd in het oplossen van niet triviale LPW problemen. Hij/zij gaat op een afdeling met de afdelingscontactpersoon kijken wat het probleem is. Benadert de juiste personen op de juiste afdelingen en lost het probleem ter plekke op. Een dergelijke persoon kan ook optreden als 'accountbemiddelaar'. Voor de lijst met vragen zoals opgesomd voor punt 8 van de doelen, zullen we antwoorden moeten bedenken in termen van organisatie. De antwoorden zijn essentieel voor een goede beschrijving van het functioneel ontwerp.