Functioneel ontwerp Linux WerkPlek

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.

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 

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.

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. 

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?

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. 

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

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.

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 

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 

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 

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 

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 

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 

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 

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 

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.