Afstudeerscriptie. Afstudeerscriptie Peter Hoogkamer (# ) Leiden, januari Stagebegeleider: Jan Hordijk

Afstudeerscriptie

Afstudeerscriptie Peter Hoogkamer (#1226887) Leiden, januari 2007 Stagebegeleider: Jan Hordijk Afstudeerbegeleider: Dhr. van Nimwegen Studierichting: Hogere Informatica

2

Voorwoord Het boekwerk dat hier voor u ligt, is het resultaat van 4 jaren deeltijd studie aan de Hogeschool van Amsterdam en de Hogeschool Utrecht. Hiermee rond ik mijn studie Hogere Informatica af, een periode waarin ik veel geleerd heb en leuke tijden heb meegemaakt. Aan het einde van de zomer in 2006 ben ik op zoek gegaan naar een stageplaats om mijn afstudeerstage te doorlopen. Waar anders tegenwoordig te zoeken dan op het internet. Na een tijd zoeken werd ik door mijn vrouw gewezen op de site van het R@sto. Het R@sto is een stichting met een bijzondere bedrijfsfilosofie die mij erg aan stond. Na het lezen van een aantal verhalen van eerder stagiaires heb ik de stap gemaakt om een afspraak te maken. Het R@sto heeft mij een leuk stage bezorgd. Als ik aan het R@sto denk, dan denk ik aan de maandagochtend vergadering die altijd verbazend snel voorbij gingen, de leuke gesprekken met iedereen, het leuke kerstfeest en natuurlijk aan alles wat ik daar geleerd heb. Ik wil dan ook Jan Hordijk, Wilfred Boersma, Dennis Boot en Rutger Doresteijn bedanken voor een leuke tijd bij het R@sto. Gedurende mijn stage en daarna heb ik begeleiding gehad van Henk van Nimwegen. Hij heeft mij geholpen met zeer nuttige tips en begeleiding bij het schrijven van mijn scriptie en het voorbereiden van mijn verdediging. Daarom wil ik Henk bedanken voor het prettig samenwerken en alle steun die hij mij gegeven heeft om mijn afstuderen tot een goed einde te brengen. Als laatste maar als minste wil ik mijn vrouw Marrit bedanken die geduld met mij heeft moeten hebben wanneer ik weer eens in het weekend moest studeren, en die door mijn schoolvakanties gedwongen werd om altijd in de kerstvakantie te gaan skiën. Nee, vanaf nu beloof ik je dat wij lekker eind januari gaan skiën. Ik heb genoten van deze tijd en kijk uit naar de toekomst waarin ik als HBO-er aan de slag kan gaan.

3

Inhoudsopgave Voorwoord........................................................................................................................ ................3 Inleiding.................................................................................................................................... ........7 H1 Bedrijfsanalyse ............................................................................................ .............................8 1.1 Historische schets van de oprichting tot huidige situatie................................................. ..8 1.2 Missie en doelen van het R@sto............................................................................ ..........9 1.2.1 Het ICTaL........................................................................................................... .....10 1.2.2 Het doel van het R@sto.................................................................................... ......10 1.2.3 ICT omgeving van het R@sto..................................................................... ............10 1.3 Organisatie en personeelsbezetting................................................... ............................11 1.4 Organogram................................................................................................... ................13 1.5 De kernactiviteiten van het R@sto ........................................................ ........................14 1.6 Het huidige Microsoft netwerk.................................................................. ......................14 1.6.1 Onderzoek en aanpak voor de opzet van het huidige Microsoft netwerk................15 1.6.2 Opzet en layout van het huidige netwerk............................................. ...................16 1.7 Voorlopige conclusie van de analyse ........................................................................... ..18 H2 Probleemstelling en opdracht omschrijving.................................................................... ..........19 2.1 Probleemstelling...................................................................................................... .......19 2.2 Opdrachtomschrijving................................................................................................. ....19 2.3 Vraagstelling en taken..................................................................................... ...............20 2.5 Op te leveren producten..................................................................................... ............21 2.6 Planning en tijdspad....................................................................................... ................21 2.7 Scope................................................................................................................. ............22 2.8 Begeleiding........................................................................................ ............................23 2.9 Afspraken.................................................................................................. .....................23 2.10 Uitdagingen................................................................................................. .................23 H3 Software naar keuze van besturingssysteem...................................................................... .....24 3.1 FOSS: een eerste korte introductie....................................................... .........................24 3.2 Inventarisatie applicatie behoeften.............................................................. ...................24 3.3 Software mogelijkheden............................................................................... ..................25 3.4 Wat zijn de voor- en nadelen van gekozen software......................... .............................27 Binnen de tabel worden in de kolom van de kosten onder de Closed Source software een aantal services genoemd die allen tot een softwarepakket behoren, namelijk Microsoft Server 2003. Hierdoor is er echter niets te zeggen over de kosten van deze afzonderlijke pakketten. Hier is dan ook gekozen om deze niet van toepassing te laten zijn................................ .......29 3.5 Conclusie en aanbevelingen............................................................... ...........................30 4

H4 Open Source voor het R@sto ..................................................................................... ............31 4.1 Beschrijving van de beginsituatie........................................................... ........................31 4.2 Free Open Source Software ................................................................................. .........32 4.2.1 Redenen om voor FOSS te kiezen............................................. ............................32 4.2.2 Redenen om niet voor FOSS te kiezen............................................................. ......35 4.3 Closed Source software......................................................................... ........................36 4.3.1 Redenen om wel voor Closed Source software te kiezen..................... ..................36 4.3.2 Redenen om niet voor Closed Source software te kiezen.................................. .....37 4.4 Voorlopige keuzebepaling..................................................................... .........................37 4.5 Voorlopige aanbeveling softwarekeuze.................................................... ......................38 4.6 Mogelijke combinaties binnen de netwerkinfrastructuur...................... ...........................38 4.6.1 Windows server met Windows clients (Closed)........................ ..............................39 4.6.2 Linux server met Windows clients (Open/Closed)............................................ .......39 4.6.3 Linux server met Linux clients (Open/Open)........................................... ................40 4.6.4 Windows server met Linux clients (Closed/Open)............................................ .......40 4.7 Samenvatting in tabel......................................................................................... ...........40 4.8 Voorlopige aanbeveling netwerkinfrastructuur.................................................. ..............41 4.9 Total Cost of Ownership....................................................................... ..........................42 4.9.1 Directe kosten van kapitaalgoederen............................................................ ..........42 4.9.2 Directe kosten van arbeid................................................................. ......................43 4.9.3 Indirecte kosten van arbeid........................................................................... ..........44 4.9.4 Migratiekosten............................................................................. ...........................45 4.10 Mogelijke migratietrajecten van Windows naar Linux............................... ....................45 4.10.1 Eerst clients dan servers.................................................................................... ...46 4.10.2 Eerst servers dan clients.................................................................................... ...46 4.10.3 Servers en clients tegelijk migreren............................................... .......................47 4.10.4 Alleen de servers migreren............................................................ .......................47 4.10.5 Alleen de clients migreren........................................................................... ..........47 4.11 Samenvatting............................................................................................................... .47 4.12 Voorlopige voorkeur migratie.............................................................................. ..........48 4.13 Situatieanalyse................................................................................................ .............49 4.14 Conclusie en aanbeveling.................................................................. ..........................49 H5 Roadmap voor migratie/opzet van een netwerk.......................................................... .............51 5.1 Inventarisatie van de huidige infrastructuur.................................................. ..................51 5.1.1 Inventarisatie van servers....................................................................... ................51 5.1.2 Inventarisatie van de desktops................................................................................ 52 5.1.3 Het creëren van een infrastructuur diagram.................................................... ........52 5.1.4 Extra informatie voor de inventarisatie........................................................ ............53 5

5.2 Vereisten bepalen voor het netwerk .................................................... ..........................54 5.4 Ontwerpen van de infrastructuur............................................................ ........................56 5.5 Het testen van de nieuwe infrastructuur................................................... ......................56 5.7 Het migreren naar de nieuwe infrastructuur.................................... ...............................58 H6 Conclusies en aanbevelingen.............................................................................. ....................61 H7 Evaluatie procesgang van de gehele stage................................................. ............................62 Gebruikte bronnen.................................................................................. ..............................64 Bijlagen.......................................................................................................... .......................65 Bijlage 1 Lijst met afkortingen............................................................................. ..............65 Bijlage 2 Tabellenlijst........................................................................... .............................66 Bijlage 3 Plan van Aanpak.............................................................................. ..................67 Bijlage 4 Projectvoorstel............................................................................ .......................72 Bijlage 5 Verslag van inventarisatie.......................................................... ........................76

6

Inleiding Als afsluiting van mijn studie Hogere Informatica aan de Hogeschool van Utrecht heb ik tussen september 2006 en januari 2007 mijn afstudeerstage afgerond. Deze afstudeerstage heeft plaats gevonden bij het R@sto te Leiden. Het R@sto is een stichting van het ROC (Regionaal Opleidings Centrum) Leiden die stagiaires de mogelijkheid geeft om ervaring op te doen in de ICT door middel van het uitvoeren van ICT projecten. Het R@sto heeft mij dan ook de mogelijkheid geboden om mijn afstudeerstage bij hun te doorlopen. De opdracht bestond uit het implementeren van een netwerk en het doen van onderzoek naar de mogelijkheden tot het gebruik van Open Source software binnen het R@sto en hun projecten. In het begin van mijn stage heb ik bij het R@sto een netwerk voorbereid en geïmplementeerd. Hoewel ze hier tevreden over waren, hadden ze twijfels over het voortzetten van het huidige netwerk. De reden is dat ze twijfelen omdat R@sto nieuwe projecten wil opstarten en die zijn niet mogelijk bij het huidige netwerk systeem. Dat betekend dat ze of die projecten moeten laten schieten of dat ze moeten gaan rond kijken voor andere mogelijkheden. Hiermee kom ik tot de essentie van dit onderzoek wat de de volgende centrale probleemstelling oplevert: Afhankelijkheid van het ROC Leiden beperkt het R@sto in het uitvoeren van haar projecten en verwezenlijken van haar ambities. In dit onderzoek zal door middel van een aantal vragen een antwoord gezocht worden op de probleemstelling. Zo zal er onderzocht worden naar de eisen die het MKB (Midden- en Kleinbedrijf) stelt aan een netwerk en of Open Source software kan voldoen aan deze eisen. Als Open Source kan voldoen aan de eisen van een netwerk voor het MKB dan is de volgende stap om te kijken hoe de software vervolgens geïmplementeerd kan worden en hoe een eventueel migratietraject aangepakt zal moeten worden. Daarna wordt nog gekeken waarom Open Source software met als zijn voordelen nog niet breed geaccepteerd is binnen het MKB. De scriptie zal in hoofdstuk 1 het R@sto onder de loep nemen door middel van een bedrijfsanalyse. Daarna zal in hoofdstuk 2 de omschrijving van de probleemstelling worden uitgevoerd met daarnaast ook de afkadering van de afstudeeropdracht. In hoofdstuk 3 zal begonnen worden met het daadwerkelijke inhoudelijke onderzoek door een keuze te maken tussen de verschillende softwarepakketten die het netwerk dient te bevatten. Hoofdstuk 4 zal dieper in gaan op de keuze tussen Open en Closed Source software en hoe deze gecombineerd kunnen worden binnen een netwerk. Om ook het kostenaspect mee te nemen wordt er in hoofdstuk 4 ook ingegaan op de TCO (Total Cost of Ownership) van software. Het hoofdstuk wordt afgerond met een afweging en vergelijking tussen manieren om een client/server netwerk te migreren naar een nieuwe situatie. Voor de volledigheid zal in hoofdstuk 5 een roadmap worden aangeboden waarmee een migratie naar Open Source software soepel uitgevoerd kan worden. De scriptie wordt afgesloten met conclusies en aanbevelingen in hoofdstuk 6. In hoofdstuk 7 zal ik een evaluatie van mijn afstudeerstage doen. Om de vele afkortingen die voorkomen in dit verslag is in bijlage 1 afkortingenlijst opgenomen. 7

H1

Bedrijfsanalyse

In de bedrijfsanalyse zal een oriënterende analyse plaats vinden van het bedrijf waar mijn afstudeeropdracht heeft plaats gevonden. Hierbij is het van belang om in eerste instantie de organisatie in kaart te brengen, zodat er een goed beeld gevormd kan worden van de afstudeerplaats. In paragraaf 1.6 wordt aandacht besteed aan het huidige netwerk dat destijds door mijzelf opgezet is aan de hand van de toenmalige wensen van het R@sto. Vervolgens wordt een voorlopige conclusie getrokken over de problematiek waar het R@sto op dit moment tegen aan loopt en in welke richting een eventuele oplossing gezocht kan worden.

1.1

Historische schets van de oprichting tot huidige situatie

In het jaar 2001 hebben de schoolbesturen van alle scholen binnen Leiden besloten om samen met de gemeente Leiden een samenwerkingsverband aan te gaan om de ICT-voorziening van alle basisscholen in Leiden te realiseren. Hieruit is het DDS (De Digitale Sleutel) ontstaan. De Digitale Sleutel is een overlegorgaan waarin de gemeente en schoolbesturen samen naar oplossingen zoeken voor ICT-problematiek op het gebied van infrastructuur, het aanschaffen van hard- en software en onderzoek doen naar onderwijstoepassingen. Het uitvoerende orgaan van dit overlegorgaan is het DDS. De projectleiding van het DDS is samen met haar contacten binnen het ROC Leiden een project begonnen om de ICT-problemen van scholen binnen Leiden het hoofd te bieden. Uit dit samenwerkingsverband is het R@sto ontstaan als stichting van het ROC Leiden. De naam R@sto staat voor Regionaal @utomatiserings Steunpunt van het Onderwijs. Hierin hebben de projectleiding van het DDS en haar contacten binnen het ROC Leiden zich gevonden in een ‘ideaal samenwerkingsverband’, waarbinnen het ROC Leiden haar stagiaires praktisch kon opleiden. Dit opleiden vond plaats door de stagiaires werkzaamheden te laten doen die nodig waren voor het onderhoud van de ICT voorzieningen op de Leidse scholen. De Leidse scholen kregen op deze manier tegen een zeer aantrekkelijk tarief de diensten en kennis aangeboden om een goede ICT voorziening te realiseren. Hierbij kan men denken aan het neerzetten en inrichten van een server met Active Directory, mail en back-up functionaliteiten. Het onderhoud van de gehele ICT voorziening lag bij het R@sto en haar stagiaires. DDS werd hierdoor de spreekbuis van de schoolbesturen. Wekelijks overleg zorgt ervoor dat bij het R@sto bekend is wat er precies leeft. Alles wat met de scholen afgesproken wordt, gaat via DDS en visa versa. Door de communicatielijnen zo kort en strak mogelijk te houden, werd de ‘ruis’ geminimaliseerd. Later bleek dit concept de dienstverlening naar de scholen toe te verbeteren.

8

De overeenkomsten die DDS en R@sto bereikten, werden vastgelegd in een dienstencatalogus. In deze dienstencatalogus is precies terug te vinden wie waar voor verantwoordelijk is. Het R@sto bood onder andere de volgende diensten aan de scholen aan: ●

Onderhoud en beheer van de werkstations en de server.

●

Het testen en uitrollen van Software.

●

Het maken en/of aanpassen van een website voor de scholen.

Door de jaren heen is het R@sto zodanig gegroeid dat er op een gegeven moment de behoefte ontstond om ook HBO (Hoger Beroeps Onderwijs) studenten een stage/afstudeerplek aan te bieden. Dit was voornamelijk het gevolg van de groeiende vraag naar ICT voorzieningen die het R@sto kreeg. De HBO-stagiaires gingen implementatie- en onderzoeksprojecten doen en konden op hun beurt de aanwezige MBO (Middelbaar Beroeps Onderwijs) stagiaires begeleiden in het uitvoeren van zowel de MBO als HBO projecten. Daarnaast dienen de HBO stagiaires vaak ook als contactpersoon voor externe opdrachtgevers waarvoor een project wordt uitgevoerd. Om een indicatie te geven van de personele bezetting bij het R@sto zal ik deze hieronder kwantificeren. Het aantal MBO en HBO stagiaires kan sterk variëren naar gelang het aantal projecten en de hoeveelheid stagiaires die per half jaar nodig zijn. De volgende aantallen zullen dan ook de aantallen zijn die in mijn afstudeerperiode aanwezig waren. Er zal een onderverdeling gemaakt worden tussen vaste medewerkers, stagiaires HBO en stagiaires MBO. ●

Vaste medewerkers

:

4 personen

●

Stagiaires HBO

:

8 personen

●

Stagiaires MBO

:

20 personen

1.2

Missie en doelen van het R@sto

Het R@sto is een stichting van het ROC in Leiden. Het is een leerbedrijf en onderdeel van de ICTaL (ICT Academie Leiden). Op het R@sto werken veel stagiaires die begeleidt worden door gecertificeerde IT (Informatie Technologie) professionals, hierdoor is het mogelijk om betaalbare en kwalitatief volwaardige diensten aan te bieden. Het R@sto is een speciaal leerbedrijf wat een onderdeel is van het ICTal. Het ICTal is een onderdeel van het ROC Leiden en het ROC ID college. Het ROC Leiden en het ID college zijn beide opleidingscentra, beide verzorgen zij opleidingen voor middelbaar beroepsonderwijs en bieden cursussen aan voor volwassenen. Het R@sto is een stichting die gelieerd is aan het ROC, maar door gebruik te maken van stagiaires en de projecten die zij uitvoeren voor gemeenten en sociale instellingen dienen zij tevens een maatschappelijk belang. Doordat het R@sto een stichting is mag zij geen winstoogmerk hebben. Er mag wel winst gemaakt worden, maar dit mag niet het hoofddoel van de stichting zijn. Mocht er winst worden gemaakt dan gaat er een deel naar 9

het ICTal en een ander deel wordt weer gestoken in ICT projecten bij het R@sto zelf.

1.2.1

Het ICTaL

De ICT Academie Leiden is een samenwerkingsverband tussen het ROC ID College en het ROC Leiden. Het ICTaL verzorgt studies op het gebied van informatie- en communicatietechnologie, zoals een opleiding tot applicatieontwikkelaar of netwerkbeheerder. Aan het hoofd van dit samenwerkingsverband staat Dhr. W. Kerkhofs die tevens directeur is van het R@sto.

1.2.2

Het doel van het R@sto

Het R@sto heeft als doel om op ICT gebied diensten en projecten te leveren aan geïnteresseerden. Deze projecten en diensten worden uitgevoerd door middel van stagiaires. De stagiaires zijn afkomstig van MBO en HBO scholen en worden geworven via de eigen website van het R@sto (http://www.rastovooriedereen.nl), maar ook via sites al Monsterboard. Op wat voor gebied het R@sto stagiaires nodig heeft hangt sterk af van de soort projecten die het R@sto aangeboden krijgt. Deze manier van werken van het R@sto heeft voor beide partijen zo zijn voordelen. Zo kan de stagiaire zijn werk- of afstudeerstage doorlopen en kan het R@sto er voor zorgen dat haar projecten worden uitgevoerd.

1.2.3

ICT omgeving van het R@sto

Voor de ondersteuning van stagiaires en het uitvoeren van bovengenoemde werkzaamheden maakt het R@sto gebruik van pc's die geleverd zijn door het ROC Leiden. Als file- en printserver wordt er gebruik gemaakt van een standaard desktop pc. Deze loopt regelmatig vol en er zit vrijwel geen softwarematige of hardwarematige beveiliging op. De mening over welke software gebruikt dient te worden op desktop en servers is verdeeld bij het R@sto. Dhr. Hordijk, bedrijfscoordinator, ziet software van Microsoft als een virus, dit omdat de Microsoft software als een virus de computer controleert en meer dingen doet die je niet wil dan die je wel wil. Hij zou dan ook veel liever alles op FOSS zien draaien, terwijl Dhr. Boersma en Dhr. Boot, beide bedrijfscoordinatoren, meer de voorkeur geven aan Microsoft software. Veel van de Microsoft software kan via het ROC Leiden worden verkregen door middel van volume licenties. Andere software dient echter door het R@sto zelf aangeschaft te worden. Hierdoor is men afhankelijk van een leverancier waaraan ieder jaar een aardige som aan licentiegeld voldaan dient te worden.

10

1.3

Organisatie en personeelsbezetting

Vanuit het ICTal is Dhr. W. Kerkhofs de directeur van het R@sto. Daarnaast ligt de directe leiding van het R@sto in de handen van een viertal bedrijfscoördinatoren waarvan Jan Hordijk en Wilfred Boersma de leiding hebben over de verschillende afdelingen binnen het R@sto. In het organogram van paragraaf 1.4 zijn beide terug te vinden binnen de rode rechthoek. Hieronder worden beide voorgesteld: Jan Hordijk Jan Hordijk is de directe contactpersoon voor de stagiaires en de scholen van de stagiaires. Daarnaast houdt Jan zich bezig met de organisatorische kant van de stages en projecten die gerelateerd zijn aan websites. Wilfred Boersma Wilfred houd zich bezig met het PR en markering gedeelte van het R@sto. Daarnaast houd hij zich bezig met de projecten van Computer Compleet en de reparatiebalie.

Dennis Boot en Rutger Dorresteijn zijn verantwoordelijk voor het systeembeheer en alle projecten die gerelateerd zijn aan webdesign. In het organogram van paragraaf 1.4 zijn beide terug te vinden binnen de rode rechthoek. Hieronder worden ook zij voorgesteld : Dennis Boot Dennis Boot is systeembeheerder. Daarnaast is hij de technisch en organisatorisch coördinator van de reparatiebalie en van het systeembeheer. Ook verzorgt hij op technisch vlak het PC uitleen gedeelte. Rutger Dorresteijn Rutger Dorresteijn is webcoördinator. Hij coördineert de flash-ontwikkeling, webdesign, de internetcafe’s en het XML project.

11

De positie die ik tijdens mijn afstudeerstage binnen het R@sto heb bekleed is die van Coördinator Systeembeheer geweest. Binnen het organogram van paragraaf 1.4 ben ik zelf terug te vinden in het gele vierkant. Overleg tussen leidinggevenden/coördinatoren vindt veelal een op een plaats. De reden hiervoor is dat er teveel verschillende afdelingen en projecten lopen om dit allemaal bij elkaar te bespreken. Daarnaast heeft een afdeling Balie niets aan een gesprek over het ontwikkelen van XML (eXtensible Markup Language) bestanden. Deze individuele gesprekken worden voornamelijk gedaan door de bedrijfscoördinatoren. Daarnaast vindt er ook overleg plaats tussen de aanwezige HBO-ers en de hun toegewezen MBO-ers in verband met de aansturing en voortgang van de projecten. Uiteraard blijven er altijd nog mededelingen over die voor iedereen gelden. Deze worden mede gedeeld op de maandagmorgen wanneer iedereen zich in de kantine verzamelt voor de wekelijkse algemene vergadering.

12

1.4

Organogram

Figuur 1

Organogram

14

1.5

De kernactiviteiten van het R@sto

Het R@sto heeft als kernactiviteit het begeleiden van MBO en HBO stagiaires bij het uitvoeren van hun werk- of afstudeerstage. Door stagiaires aan te nemen die geschikt zijn voor projecten die door het R@sto uitgevoerd worden kan er gezorgd worden dat zowel de stagiaires als het R@sto voorzien worden in hun behoeften. De diensten die het R@sto levert zijn: ●

het repareren en onderhouden van pc's, zowel van scholen als van particulieren

●

het maken en onderhouden van netwerkomgevingen

●

onderhoud van websites

●

ondersteuning bij het maken van back-ups voor scholen en instellingen

●

ondersteuning bij email en centrale agenda's om de communicatie binnen andere bedrijven efficiënter te laten verlopen

●

ondersteuning bij sociale projecten van gemeenten en gemeentelijke instanties

De hoeveelheid projecten die er per half jaar lopen, liggen ongeveer tussen de 8 en 12 projecten en hangen voornamelijk af van het aanbod aan opdrachten die het R@sto krijgt. Daarnaast geeft het R@sto ondersteuning bij twee internetcafe's in Leiden, namelijk in de Slaaghwijk en de Fortuinwijk. De diensten die vanuit de internetcafe's worden gegeven zijn : ●

het aanbieden van goedkope internettoegang, uitleg en ondersteuning

●

het aanbieden van een goedkope bel mogelijkheid naar zowel binnen- als buitenland

●

het goedkoop verkopen van vele soorten telefoonkaarten

●

het geven van computercursussen

●

het repareren kleine defecten aan pc's

Voor de nabije toekomst zijn er plannen om MKB bedrijven in de regio Leiden netwerkoplossingen aan te gaan bieden. Bij voorkeur gaan deze oplossingen bestaan uit FOSS (Free Open Source Software), omdat dit de kosten terug dringt en het flexibel is toe te passen. Deze flexibiliteit heeft voornamelijk een voordeel bij het aanpassen van software op de wensen en eisen van de bedrijven.

1.6

Het huidige Microsoft netwerk

In deze paragaaf zal een beschrijving worden gegeven van het voorbereiden en implementeren van het huidige netwerk. Deze paragraaf geeft een beschrijving van de voorbereiding tot opzetten en layout van het huidige Microsoft netwerk. Zo zal in paragraaf 1.6.1 uiteen gezet worden hoe er 14

tot de vereisten voor het netwerk gekomen is en waar het netwerk aan diende te voldoen. Vervolgens zal in paragraaf 1.6.2 de daadwerkelijke inhoud en opzet van het netwerk aan bod komen. Deze beschrijving van het huidige netwerk dient er voor om aan te geven wat de beginsituatie van het R@sto netwerk is.

1.6.1

Onderzoek en aanpak voor de opzet van het huidige Microsoft netwerk

Met het huidige netwerk wordt het netwerk bedoeld dat ik in de beginfase bij het R@sto heb ontwikkeld. Omdat dit een onderdeel van mijn stage was licht ik in deze paragraaf mijn werkzaamheden die ik in de beginfase heb gedaan toe. Voor het ontwikkelen van het destijds gebouwde netwerk heb ik er voor gekozen om een inventarisatie uit te voeren en heb de wensen en behoeften van de medewerkers in kaart gebracht. In de inventarisatie heb ik ook de wensen van de stagiaires, die gedurende hun stageperiode van het netwerk gebruik zullen gaan maken, meegenomen. Deze inventarisatie had ik uitgevoerd onder de toenmalige bedrijfscoördinatoren. Uit deze inventarisatie bleek dat er behoefte was aan een eigen netwerk in de vorm van een Active Directory domein welke voorzien diende te worden van een eigen mail server (Exchange), een eigen proxy server (ISA) en een file/print server (Server 2003). De mail server spreekt voor zich, terwijl de proxy server in samenwerking met een goed policy beleid moest gaan zorgen voor een optimale beveiliging van het netwerk. Beveiliging zou tevens plaats gaan vinden door middel van het zetten van permissies, het aanmaken van beheerdersaccounts en het fysiek beveiligen van servers. Bijvoorbeeld door het plaatsen van de servers in een afgesloten ruimte waar alleen de beheerders de sleutel van hebben. Daarnaast wilde het R@sto dat er voor alle pc's de mogelijkheid kwam om, door middel van een Ghost server, op ieder gewenst moment bepaalde besturingssystemen met bijbehorende software te laden. Hierdoor zou er snel gewisseld kunnen worden tussen verschillende configuraties, bijvoorbeeld een configuratie systeembeheer of softwareontwikkeling. Ook zou dit tijd besparen en schelen in het onderhoud. Optioneel kon er onderzoek gedaan worden naar het invoeren van een sharepoint server. Voor het verwerken en organiseren van documentatie lag er een plan om een CRM pakket in te voeren waarin handleidingen, werkinstructies, hard- en softwareoverzichten georganiseerd en opgeslagen dienen te worden. Voor het verkrijgen van een stabiele ICT infrastructuur is destijds gekozen tot het invoeren van twee onderdelen van ITIL (Information Technologie Infrastructure Library), namelijk incident- en configuratiemanagement. Na deze inventarisatie heb ik mij gericht op de voorbereidingen voor het inrichten van de servers. Voor het inrichten van de servers was het van belang dat er gekeken werd naar wat voor software er geïnstalleerd diende te worden om te voldoen aan de wensen van het R@sto. Deze software diende voorzien te worden van instellingen en structuren die opgezet diende te worden voor de verschillende gebruikersaccounts, centrale documentopslag en het opzetten van rechtenstructuren voor toegang tot verschillende document- en datalocaties. Hiervoor is destijds een 15

implementatieplan uitgewerkt. Hierdoor werd een degelijke voorbereiding bewerkstelligd. Na deze voorbereidende werkzaamheden kwam het daadwerkelijke uitvoerende gedeelte van de serverinstallatie aan bod. Voor de uitvoerende taken had ik 2 MBO stagiaires tot mijn beschikking. Zij hebben mij ondersteund bij het opzetten van de servers. Na het uitvoerende gedeelte te hebben voltooid werd er vervolgens een pilot fase opgestart. In deze pilot fase werd een omgeving opgezet door middel van de geïnstalleerde servers en 6 gebruikers. De pilot groep bestond uit 1 persoon van iedere afdeling binnen het R@sto en de systeembeheerder van het R@sto. De pilot fase heeft 1 week in beslag genomen waarin de laatste problemen verholpen werden die alleen in een praktijksituatie naar voren kunnen komen. Na het succesvol afronden van de pilot fase werd er over gegaan naar de implementatiefase van het netwerk. In deze implementatiefase ging het gehele R@sto netwerk over naar de nieuwe servers. In het gehele traject heb ik de voortgang van het project bewaakt en er tevens voor gezorgd dat de 2 MBO stagiaires voldoende begeleid werden om hun werkzaamheden goed uit te voeren.

1.6.2

Opzet en layout van het huidige netwerk

Het huidige netwerk bestaat uit 4 servers met daarbij ongeveer 28 desktop pc's en 2 of meer laptops. De servers bestaan uit een server voor netwerkservices (file, print, DHCP en DNS), een groupware server en 2 webservers. Daar aan gekoppeld zitten de 28 desktop pc's welke bedoeld zijn als werkstations voor de verschillende MBO- en HBO stagiaires van de verschillende projecten. Er zijn minimaal altijd 2 laptops van 2 medewerkers, maar daarnaast kunnen ook stagiaires hun eigen laptops mee nemen. Voor deze laptops bestaat de keuze om via een wireless AP (Access Point) of via een ethernet kabel connectie te maken met het netwerk. Het wireless AP is voorzien van MAC-filtering voor beschermde toegang. Voor de back-up oplossing is gekozen voor Ntbackup wat mee geleverd wordt met de Microsoft server software. De back-ups worden naar een aparte schijf op de file server geschreven. Van deze back-ups wordt 1 keer per maand en kopie gemaakt voor externe opslag. In de opzet die genoemd wordt in het projectvoorstel komt ook het inzetten van een ghost server aan bod. Deze server zorgt er door middel van een client/server systeem voor dat men ten alle tijden een nieuw besturingssysteem met bijpassende configuratie op een willekeurige of meerdere computers kan zetten. Dit proces gaat via het netwerk. Om te kijken of dit mogelijk was bij het R@sto zijn er een 3 tal tests uitgevoerd. Hieruit is gebleken dat het netwerk en netwerapparatuur niet geschikt is om deze data te verwerken zonder dat dit nadelige gevolgen heeft voor andere services die gebruik maken van het netwerk. Het bleek zelf dat als er 2 pc's ge-imaged worden dat dan het hele netwerk al niet meer beschikbaar was. Ghost maakt namelijk gebruik van multicast die de images (gehele besturingssystemen) over het netwerk stuurt naar de betreffende computers. Financieel was het niet haalbaar om het netwerk op te schalen naar een Gigabit netwerk, dus viel deze optie af en is alles bij het oude gebleven. Er is voor bovenstaande opzet gekozen omdat men wilde dat elke groep services op een aparte hardwarematige server ging draaien. Dit heeft vooral te maken met veiligheid en redundantie. 16

Mocht namelijk een van de servers crashen, dan liggen niet gelijk alle servers eruit. De andere servers kunnen dan altijd nog het een en ander opvangen of kunnen de nog draaiende servers voorzien worden van de services die door de gecrashte servers werden verzorgd. Voor bovengenoemde opzet waren de hardwarematige benodigdheden reeds aanwezig, waardoor het netwerk met een minimum aan kosten gerealiseerd kon worden. Figuur 2

Netwerkdiagram van de huidige situatie

17

1.7

Voorlopige conclusie van de analyse

Uit bovenstaande bedrijfsanalyse kan geconcludeerd worden dat er een wens is om minder afhankelijk te worden van het ROC Leiden. Het R@sto wil als zelfstandige stichting opdrachten en projecten gaan uitvoeren. Om deze projecten tot een goed einde te brengen heeft het R@sto softwarematige hulpmiddelen nodig, maar omdat het R@sto een stichting is en niet over een groot budget beschikt is het vaak moeilijk om investeringen te doen in hard- en software. Hiervoor is het R@sto dan ook afhankelijk van het ROC Leiden. Deze zorgt voor licenties van Microsoft software en voor de ter beschikking stelling van desktop pc's. Om onafhankelijk te worden van het ROC Leiden is het overgaan op FOSS een optie die in overweging wordt genomen. Daarnaast is het R@sto van plan om een project op te starten waarbij zij FOSS servers aan het MKB binnen de regio Leiden wil gaan aanbieden. Mocht dit project goed lopen, dan wil het R@sto kijken of het voor hen tevens interessant is om over te stappen naar een FOSS netwerk.

18

H2

Probleemstelling en opdracht omschrijving

In hoofdstuk 1 is door middel van een bedrijfsanalyse de bedrijfsopbouw en werkzaamheden van het R@sto beschreven. Daarnaast is stilgestaan bij het netwerk dat door mij geïmplementeerd is. Uit de in hoofdstuk 1 uitgevoerde bedrijfsanalyse is gebleken dat er behoefte is aan het veranderen van de IT infrastructuur. Met deze verandering wil het R@sto een onafhankelijke positie verkrijgen ten opzichte van het ROC Leiden. Dit is tevens het kernonderzoek tijdens mijn afstudeerstage geweest. In dit hoofdstuk zal hier dieper op worden ingegaan.

2.1

Probleemstelling

Op dit moment is het R@sto van mening dat zij te afhankelijk is van ROC Leiden. Onder deze afhankelijkheid wordt het gebruik van software en hardware van het ROC Leiden verstaan. Vooral het kostenaspect beperkt het R@sto bij het aanschaffen van bepaalde softwarepakketten welke benodigd zijn voor de projecten die het R@sto uitvoert. Closed Source pakketten die het ROC Leiden niet heeft, dienen aangeschaft te worden door het R@sto zelf. Deze zijn vaak vrijwel onbetaalbaar voor de stichting. Uit eerdere onderzoeken is een mogelijke oplossing voortgekomen in de richting van FOSS. Deze onderzoeken zijn gedaan bij het implementeren van het Open Source CMS Joomla en het Open Source CRM pakket SugarCRM. Centrale Probleemstelling: Afhankelijkheid van het ROC Leiden beperkt het R@sto in het uitvoeren van haar projecten en het verwezenlijken van haar ambities.

2.2

Opdrachtomschrijving

Het R@sto is een onderdeel van het ROC Leiden, maar wil een onafhankelijkere positie verkrijgen ten opzicht van het ROC Leiden. Om dit te realiseren wil het R@sto niet meer afhankelijk zijn van servers en netwerkfaciliteiten van het ROC Leiden. En zou het daarnaast haar software willen veranderen naar FOSS. Hierdoor is het R@sto ook op softwaregebied niet meer afhankelijk van het ROC Leiden. Daarnaast is het R@sto van plan een project op te starten om Open Source MKB servers te gaan leveren aan bedrijven. Hierdoor kan het R@sto ervaring op doen met Open Source software en zelf ook de overweging maken om over te stappen op FOSS. Reden om dit nu nog niet te doen, zijn de onbekendheid met FOSS, weinig ervaring, de eventuele risico's die het met zich mee kan brengen en het ontbreken van kennis op het gebied van FOSS. Daarnaast is er ook een tweedeling in het bedrijf tussen mensen die Windows als een virus zien en mensen die zweren bij Windows. Men zal moeten kijken wat de wensen van de verschillende personen zijn en tot een compromis dienen te komen. Het netwerk wat gebaseerd zal worden op FOSS zal dezelfde functionaliteiten gaan krijgen als het Windows netwerk. Men wil hier vooral naar over gaan in

19

verband met de (licentie) kosten. FOSS is vrijwel gratis en brengt dan ook geen hoge kosten met zich mee, terwijl de functionaliteiten van een behoorlijk aantal Open Source pakketten op een prima kwalitatief niveau ligt. Het R@sto is een stichting, mag geen winst maken en heeft financieel niet zoveel ruimte om veel kosten te maken voor het aanschaffen van dure Closed Source software. Om bovenstaande redenen is mij gevraagd onderzoek te doen naar de mogelijkheden voor het R@sto om FOSS te gaan gebruiken voor hun projecten en eventueel ook voor het implementeren van FOSS bij het R@sto zelf. Centrale Opdrachtomschrijving : Onderzoek in hoeverre FOSS een reële optie is om het R@sto meer vrijheid te geven in het ontwikkelen en uitvoeren van projecten voor derden.

2.3

Vraagstelling en taken

Centrale vraagstelling: Wat zijn de mogelijkheden tot het implementeren van een Open Source Server binnen het MKB. Deelvragen: 1. Wat zijn de eisen die het MKB aan een ICT netwerk stelt? 2. Kan een Open Source netwerk voldoen aan deze eisen? 3. Wat zijn de verschillende mogelijkheden tot implementatie van FOSS? 4. Hoe kan een migratietraject zo succesvol mogelijk doorlopen worden? 5. Waarom is Free Open Source Software nog niet breed geaccepteerd door het MKB? Naast bovenstaande ga ik onderzoek doen naar mogelijke alternatieven voor een volledig FOSS of Closed Source netwerk. Deze alternatieven bestaan uit combinaties van de verschillende soorten software (closed of open) op server of cliënt, danwel beide.

2.4

Onderzoeksmethode en aanpak van FOSS netwerk

Als resultaat van dit onderzoek dienen er antwoorden gegeven te worden op bovenstaande deelvragen, waarmee uiteindelijk de centrale vraagstelling beantwoord dient te worden. Om dit alles tot een goed einde te brengen zal er een literatuuronderzoek plaats vinden. Voordat er echter gericht gezocht kan gaan worden naar literatuur moet er eerst een beeld gevormd worden van het R@sto. Voor deze beeldvorming zullen resultaten uit de bedrijfsanalyse van hoofdstuk 1 gebruikt worden. Resultaten uit de bedrijfsanalyse worden vervolgens getoetst door middel van korte interviews met de bedrijfscoordinatoren van het R@sto om zeker te weten of deze resultaten nog

20

actueel zijn. Hier hoeft niet een geheel nieuwe bedrijfsanalyse voor uitgevoerd te worden. Daarna kan in het literatuuronderzoek aandacht besteed worden aan het fenomeen FOSS, de minimaal benodigde software voor een netwerkserver(s), wat voor netwerk- en migratiemogelijkheden er zijn en wat de voor- en nadelen zijn van Open en Closed Source software. Aan de hand van de conclusies en aanbevelingen die uit dit onderzoek naar voren komen zal een beslissing worden genomen. Wordt het Open of Closed Source en zo ja, in wat voor samenstelling. Aan de hand van deze beslissing zal ik een migratie roadmap opzetten waarmee een eventuele migratie naar een FOSS server zo goed mogelijk zal verlopen.

2.5

Op te leveren producten

In de voorbereidende fase van de afstudeeropdracht wordt een Projectvoorstel opgeleverd waarin een eerste voorstel gedaan wordt voor de afstudeeropdracht. Dit Projectvoorstel is bijgevoegd als bijlage 3. Daarna levert de afstudeeropdracht ook een Plan van Aanpak op die een beschrijving geeft van hoe de afstudeeropdracht aangepakt gaat worden. De afstudeeropdracht dient te resulteren in een scriptie waarin aanbevelingen staan met betrekking tot de beste softwarekeuze voor het R@sto. Als gekozen wordt voor een FOSS oplossing voor het netwerk voorziet de scriptie in een roadmap die gevolgd kan worden teneinde de migratie naar een FOSS netwerk tot een goed einde te brengen. Daarnaast dient de scriptie antwoord te geven op de centrale vraagstelling en de deelvragen.

2.6

Planning en tijdspad

Mijn stage bij het R@sto zal een tijdsbestek van 5 maanden in beslag nemen. In deze 5 maanden zal ik mij bezig gaan houden met het onderzoeken en uitvoeren van mijn afstudeeropdracht. De maand september zal besteed worden aan het inventariseren van de wensen en behoeften die het R@sto in het nieuwe netwerk terug wil zien. In oktober ben ik mij bezig gaan houden met de voorbereidingen voor het installeren de benodigde servers voor het Microsoft netwerk. Na de installatie van de servers heb ik samen met mijn MBO stagiaires kleine tests gehouden om zeker te weten of alles goed zou werken. Na het slagen van deze tests is over gegaan tot de pilot fase. Hieraan hebben gedurende 1 week 6 mensen aan deel genomen. Na het oplossen van kleine probleempjes en het doen van benodigde aanpassingen is besloten om het gehele netwerk te migreren naar het Microsoft netwerk. In november ben ik mij bezig gaan houden met het literatuuronderzoek naar het invoeren van FOSS binnen het R@sto. Dit onderzoek kreeg nog extra belang door het idee van het R@sto om MKB servers uit te gaan leveren. In deze periode heb ik het beheer en onderhoud zo veel mogelijk over gedragen aan mijn MBO stagiaires. In de maand november ben ik mij bezig gaan houden met het opstellen van de probleemstelling en het opstellen van de deelvragen. Daarop volgend heb ik een opzet gemaakt voor de aanpak van het literatuuronderzoek. Dit literatuuronderzoek zal door middel van verdere informatie inwinning een

21

totaal plaatje op moeten leveren en antwoorden dienen te geven op de probleemstelling en deelvragen. Door het doen van onderzoek naar de literatuur ben ik in december begonnen met het schrijven van mijn scriptie. In de laatste maand januari zal ik een pilot/test netwerk opzetten bestaande uit een Open Source server met twee testpc's. Hieronder zal ik bovenstaande planning in een tijdspad schematisch weergeven. Tabel 1

Tijdspad netwerk implementatie en literatuuronderzoek Opzetten huidige netwerk

Activiteiten

Tijdsbestek

Stap 1

Inventarisatie behoeften/eisen

1 week

Stap 2

Inlezen en voorbereiding

2 weken

Stap 3

Installatie en configuratie software

2 weken

Stap 4

Pilot fase met pilot groep

1 week

Stap 5

Implementatie in netwerk

2 week

Literatuuronderzoek FOSS Activiteiten

Tijdsbestek

Stap 1

Inventarisatie netwerk en behoeften/eisen 2 weken

Stap 2

Bepalen probleemstelling en deelvragen

1 week

Stap 3

Opzet aanpak literatuuronderzoek

1 week

Stap 4

Informatieinwinning en literatuur vergaren 2 weken

Stap 5

Onderzoek doen en scriptie schrijven

6 weken

Stap 6

Opzet pilot/test netwerk

4 weken

Na mijn afstudeerperiode heb ik een grote overbruggingsperiode gehad naar mijn afstudeerdatum. In die tijd heb ik verder aan mijn scriptie kunnen werken. Deze heb ik dan ook pas afgerond na mijn afstudeerperiode.

2.7

Scope

Uiteraard zal in dit onderzoek niet ieder aspect van het invoeren van FOSS software in het MKB bedrijf onderzocht worden. Hiervoor zal er een bepaalde inkadering plaats dienen te vinden van wat er wel en niet onderzocht gaat worden. In de centrale vraagstelling en deelvragen is reeds aangegeven wat wel onderzocht gaat worden. Hieronder zal ik aangeven wat buiten de scope van dit onderzoek zal vallen: ●

hoe een Open Source of Closed Source server op uitvoerende niveau ingericht wordt

●

hoe deze in de praktijk geïmplementeerd gaat worden

●

in hoeverre het project van het R@sto voor het uitleveren van kant-en klare Open Source servers een succes zal zijn, of in hoeverre er reeds andere bedrijven (misschien in de regio Leiden) al hetzelfde doen en wat voor impact dat zal hebben op het project van het R@sto

●

wat voor hardwarematige benodigdheden voor dit project nodig zijn en wat de kosten hiervan zullen zijn. 22

2.8

Begeleiding

Bij het juist afronden van mijn afstudeerstage krijg ik begeleiding uit verschillende richtingen. Vanuit mijn stageplaats heb ik begeleiding gekregen van Dhr. J. Hordijk en Dhr. W. Boersma. Zij hebben mij vanuit het R@sto begeleid met advies en tips voor het juist uitvoeren van het praktijkgedeelte van mijn afstudeerstage. Van de kant van de Hogeschool Utrecht krijg ik begeleiding van Dhr. Nimwegen. Hij ondersteund mij tijdens mijn stage en geeft mij adviezen over mijn scriptie. Daarnaast zal hij mij begeleiden bij het aanlooptraject naar mijn verdediging eind juni. Samengevat staan in onderstaande opsomming mijn begeleiders: ●

Dhr. H. van Nimwegen Stagebegeleider vanuit de Hogeschool Utrecht

●

Dhr. J. Hordijk en Dhr. W. Boersma Stagebegeleiders bij het R@sto

2.9

Afspraken

Afspraken die gemaakt worden binnen een afstudeeropdracht hebben als nut om de afstudeeropdracht af te ronden op een manier die voor zowel de Hogeschool Utrecht, het R@sto en de afstudeerbegeleider als voldoende wordt beschouwd. Met de Hogeschool Utrecht heb ik de afspraak gemaakt dat ik aan de hand van een door de examencommissie goed gekeurd Projectvoorstel en Plan van Aanpak mijn afstudeeropdracht zal doorlopen. Een logisch gevolg hiervan is dat ik de producten op zal leveren die in deze documenten aangegeven worden. Mochten er bij de afronding van de afstudeerstage producten zijn die ik niet op heb kunnen leveren dan zal dit met een goede reden moeten zijn welke ik ook voldoende kan beargumenteren. Uiteraard heeft ook het R@sto naar het Projectvoorstel en Plan van Aanpak gekeken en zijn hier mee akkoord gegaan.

2.10

Uitdagingen

Naast het feit dat ik ervaring op kan doen met de praktische bedrijfsuitoefening, heb ik ook de kans om ervaring op te doen met rapporteren, analyseren en het planmatig werken. Tijdens de stage zal ik mijn kennis kunnen verdiepen op een aantal gebieden, hierbij kan gedacht worden aan het actief deelnemen aan vergaderingen, coördinatie van taken en andere organisatorische aspecten. De grootste uitdaging bestaat mijns inziens uit het opdoen van ervaring met planmatig werken; namelijk gesprekken aan gaan met een opdrachtgever, de wensen van de opdrachtgever vertalen in een plan van aanpak en deze goed ten uitvoer brengen.

23

H3

Software naar keuze van besturingssysteem

In de hoofdstukken 3 en 4 zal de opbouw en keuze voor software en netwerkstructuren aan bod komen. Zo zal in hoofdstuk 3 aandacht besteed worden aan de softwarepakketten die binnen een netwerk nodig zijn om te voldoen aan de vereiste services die een netwerk dient te leveren. In hoofdstuk 3 zullen de termen Open Source en Closed Source software geïntroduceerd worden. Op basis van 3 criteria zullen vervolgens de eerste aanbevelingen volgen. Om deze aanbevelingen verder te onderzoeken wordt in hoofdstuk 4 dieper ingegaan op fenomeen FOSS, de voor en tegens van open en closed software en de verschillende mogelijkheden om deze software binnen een netwerk te gebruiken. Als laatste zal er gekeken worden naar het begrip TCO (Total Cost of Ownership) en wat dit voor invloed heeft op de overstap naar FOSS.

3.1

FOSS: een eerste korte introductie

In hoofdstuk 4 volgt een uitgebreide toelichting van FOSS, maar om dit hoofdstuk goed te begrijpen is het nodig om FOSS hier kort toe te lichten. Het fenomeen Open Source bestaat reeds sinds begin jaren tachtig, maar is echter door het extensief gebruik van Closed Source licenties en patenten nooit echt van de grond gekomen. Echter met de opkomst van Linux als besturingssysteem is ook de Open Source gedachte mee gelift op het succes van Linux. Dit is echter niet de enige reden waarom Open Source software populair aan het worden is. Het grove geld wat tegenwoordig betaald dient te worden voor Closed Source software gaat ook veel mensen/bedrijven tegen zitten. Doordat Open Source op dit moment toch populair aan het worden is, gaat het commerciële bedrijfsleven er ook mee aan de haal en wordt de Open Source licentie GPLv2 behoorlijk uitgepluist. Zo kan er ook software uitgebracht worden waarbij de broncode wel open is, maar waar dan wel voor betaald dient te worden. Technisch gesproken is dit Open Source software, maar het is niet gratis. In paragraaf 4.2 wordt dieper ingegaan op het begrip Open Source software. Om software aan te duiden die geheel gratis en open is wordt sinds kort de term FOSS gebruikt.

3.2

Inventarisatie applicatie behoeften

Bij een inventarisatie van de applicatie behoeften binnen een netwerk gaat men inventariseren wat medewerkers verwachten van het netwerk. Wat voor printer, opslag of email toepassingen worden verwacht. Gaat men thuis werken of op locaties buiten het kantoor? Hierbij dient van te voren rekening gehouden te worden. Uiteraard gebeurt eenzelfde inventarisatie op het beheerders niveau. Wat verwachten zij aan tools en mogelijkheden om het netwerk te onderhouden. Bij deze inventarisatie worden de eisen die resulteren uit de inventarisatie onderverdeeld volgens de MoSCoW methode. De MoSCoW methode is een wijze om prioriteiten aan te brengen aan resultaten die uit een onderzoek/rapport komen. In het woord MoSCoW staat iedere hoofdletter voor een prioriteit. De M van Must Haves staat voor punten die minimaal in het eindresultaat van 24

het project aanwezig dienen te zijn. De S van Should Haves staat voor eisen die zeer gewenst zijn, maar ook in een andere vergelijkbare vorm aanwezig mogen zijn. De C van Could Haves staat voor eisen die aan bod mogen komen als hier tijd voor over is. Als laatste staat de W voor Would Haves. Deze eisen zullen nu niet aan bod komen, maar kunnen wel interessant zijn voor de toekomst.

3.3

Software mogelijkheden

Binnen een ICT netwerk verwachten gebruikers gebruik te maken van bepaalde services die door het netwerk aangeboden worden. Deze services worden mogelijk gemaakt door het draaien van programmatuur op de servers binnen het netwerk. De eisen die het MKB stelt aan de services die binnen een netwerk draaien hangen vaak af van de grote en de markt van het MKB bedrijf. Om erachter te komen waar het MKB over het algemeen behoefte aan heeft binnen haar netwerken heb ik bij een twee tal aanbieders voor MKB servers informatie hierover opgevraagd. Verder heb ik gekeken bij het bedrijf waar ik zelf werk, dit is een MKB bedrijf met 60 medewerkers. Hieruit zijn de volgende tien meest voorkomende netwerkapplicaties naar voren gekomen: 1. Groupware services, zoals email, gedeelde kalenders en het centraal regelen van afspraken 2. File services, het delen van bestanden via een centrale server inclusief beveiliging door middel van het aanbrengen van rechten en het aanmaken van gebruikersgroepen 3. Print services, het centraal beheren en delen van printers binnen een netwerk zodat vanuit het hele netwerk naar netwerkprinters geprint kan worden 4. Centraal gebruikers management, hiermee kan vanaf een centrale lokatie het beheer over het aanmaken van gebruikersaccounts en gerelateerde instellingen worden gevoerd 5. DCHP services, het uitdelen van IP adressen samen met netwerkinformatie (DNS server, domein naam, gatewayadres en subnetmask) binnen een netwerk 6. DNS services, het omzetten van domeinnamen en internetadressen naar ip-adressen voor het opvragen van webpagina's en communicatie binnen het netwerk 7. Proxy services, hierbij kan gedacht worden aan content filtering voor internet gebruik, voorkomen van spam en beheersing van internettoegang 8. Firewall services, met een firewall wordt gezorgd dat er geen of beheerste toegang mogelijk is tot het lokale netwerk vanaf het internet 9. Backup services, hiermee wordt data veilig gesteld voor het geval dat calamiteiten als brand de servers vernietigd, maar ook voor het herstellen van verloren gegane bestanden 10. CMS, Content Management Systeem, een CMS zorgt voor het eenvoudig en overzichtelijk onderhouden van een website Bovengenoemde services zijn binnen Closed Source netwerken allemaal aanwezig, veelal in de vorm van Microsoft producten. Sinds een aantal jaren zijn voor deze top tien ook tegenhangers in 25

de Open Source wereld beschikbaar die kwalitatief op een zelfde niveau kunnen presteren als hun Closed Source tegenhangers. Vaak worden Open Source programma's nog gezien als software die door individuen in elkaar is geprogrammeerd en waarvan de kwaliteit niet erg hoogstaand is. Uiteraard is dat voor een aantal Open Source programma's ook zeker het geval, al is dit in het Closed Source software circuit niet anders. Bij Closed Source is de kwaliteit van de software veel moeilijker te toetsen, omdat de code niet openbaar is. Voor een groeiend aantal Open Source programma's is door de groeiende populariteit van deze software het schrijven van kwalitatief goede programma's noodzaak geworden en wordt hier dus ook serieus mee aan de gang gegaan. Voorbeelden hiervan zijn : ●

Novell

●

Red Hat

●

Openoffice (Sun)

●

Apache webserver.

In het Open Source Jaarboek 2006/2007 wordt aangegeven dat de twijfel aan de kwaliteit of functionaliteit van FOSS geen gegronde reden is om niet voor FOSS te kiezen. Het uitbrengen van een tweetal tools door Cap Gemini geeft een bedrijf de mogelijkheid om eventueel aan te schaffen Open Source software te toetsen. Deze tools zijn het Capability Maturity Model uit 2004 en het BRR (Business Readiness Rating) uit 2005. Met deze tools kunnen programma's getoetst worden op basis van de aanwezigheid en kwaliteit van documentatie, frequentie van releases, gebruikersvriendelijkheid en technische kwaliteit. Vervolgens kan op basis van deze criteria de software in kaart worden gebracht. In onderstaande tabel worden de Closed en Open Source vormen voor de meest voorkomende services binnen een netwerk weergegeven. In de tabel worden dezelfde services gebruikt die in het begin van deze paragraaf zijn besproken. Tabel 2

Softwarepakketten voor netwerkservices

Services/soort software

Closed Source software

Free Open Source Software

Groupware services

Exchange servers

Kerio Mailserver

File services

Server 2003

Samba

Print services

Server 2003

CUPS

Gebruikers management

Active Directory

OpenLDAP

DHCP services

Server 2003

dhcp3-server

DNS services

Server 2003

bind

Proxy services

ISA server

Squid

Firewall services

Windows firewall

Shorewall

Backup services

Ntbackup

Backuppc

CMS

Tridion CMS

Drupal

26

Van de in de tabel genoemde Closed Source pakketten is bekend dat deze software als een geheel samen kan werken en op deze manier een goed functionerend netwerk kan vormen. De vraag is nu of dit bij de Open Source tegenhangers ook het geval is. De Open Source pakketten die hierboven genoemd worden zijn allen los van elkaar staande programma's. Toch kunnen deze programma's prima met elkaar samenwerken zodat zij tevens een goed functionerend netwerk kunnen vormen. Voorbeelden hiervan zijn bedrijven als Novell en Red Hat die met bovenstaande pakketten Enterprise servers uit brengen. Daarnaast zijn er in Nederland een aantal bedrijven die complete Open Source serveroplossingen aan de man brengen. Voorbeelden hiervan zijn: ●

Kratz Business Solutions B.V., http://www.kratz.nl/

●

Hippo, http://www.hippo.nl/

●

Xenon Systems, http://www.xenon-systems.com/

In zowel de Enterprise als de MKB serveroplossingen worden in grote lijnen de bovenstaande Open Source pakketten gebruikt. Echter kan het bij de grote bedrijven het geval zijn dat zij contracten hebben gesloten met andere softwarebedrijven voor het leveren van software of wordt er software gebruikt die binnen het eigen bedrijf is ontwikkeld. Deze bedrijven bieden naast een volledig Open Source pakket om netwerken op te zetten ook ondersteuning en advies voor hun producten. Vaak wordt gedacht dat er bij Open Source software geen garantie wordt gegeven dat de software ook daadwerkelijk werkt en dat de software op eigen risico gebruikt dient te worden. Dit geldt echter net zo goed voor Closed Source software als voor Open Source software. Veel Open Source projecten zijn ontwikkeld omdat een bepaalde functionaliteit of handig programma er nog niet is. Hier kunnen andere mensen dan ook van profiteren of mee helpen ontwikkelen. Als ze dit soort programma's niet goed in elkaar worden gezet, zijn zij daar eigenlijk zelf de dupe van. Bij de grote Open Source projecten gaat het natuurlijk wel om het geld verdienen, maar is er een andere insteek dan bij Closed Source software. Bij Closed Source software wordt vaak geld verdient door middel van het betalen van licentiegeld met daarnaast nog eens geld voor advies en ondersteuning. Bij Open Source software wordt voor de licentie geen geld gevraagd, maar wordt voor eenzelfde of een lager bedrag advies en ondersteuning geboden. Dit geeft veel meer efficiëntie aan de software en het bedrijf wat de software gebruikt. Ondersteuning vanuit het bedrijf waar de software ontwikkeld is, zeker bij de grote jongens als Novell en Red Hat, is altijd goed aanwezig. Daarnaast zijn Open Source softwarepakketten ook altijd voorzien van uitstekende documentatie. Met een community van ontwikkelaars wordt er voor gezorgd dat het aanbrengen en oplossen van bugs en het zoeken naar veel voorkomende problemen beschikbaar wordt gesteld aan iedereen die daar aan wil deelnemen of bijdragen. En dus ook oplossingen vandaan kan halen.

27

3.4

Wat zijn de voor- en nadelen van gekozen software

In deze paragraaf zullen de Closed en Open Source software pakketten worden vergeleken aan de hand van 3 criteria. Alle criteria waarop de softwarepakketten worden beoordeeld hebben eenzelfde relevantie voor het goed functioneren van het netwerk. Verder zal een score het uiteindelijke eindresultaat aan gaan geven. Deze score zal niet per softwarepakket gedaan worden, maar per criteria. Het is immers zo dat alle pakketten binnen het netwerk samen dienen te werken om te voldoen aan de gestelde criteria gebruikersvriendelijkheid, beheersbaarheid en kosten. Binnen de tabel worden in de kolom van de kosten onder de Closed Source software een aantal services genoemd die allen tot een softwarepakket behoren, namelijk Microsoft Server 2003. Hierdoor is er echter niets te zeggen over de kosten van deze afzonderlijke pakketten. Hier is dan ook gekozen om deze niet van toepassing te laten zijn. In deze tabel maak ik gebruik van een cijfermatig beoordelingssysteem. Dit systeem loopt van 1 tot en met 5 waarbij 1 zeer slecht is en 5 zeer goed. 1

zeer slecht

2

slecht

3

gemiddeld

4

goed

5

zeer goed

28

Tabel 3

Voor- en nadelen van gekozen software Closed Source software

Servicetype Software-pakket

Open Source software

Gebruikers-

Beheers-

vriendelijkheid

baarheid

Kosten Software-pakket Gebruikersvriendelijkheid

Beheers-

Kosten

baarheid

Groupware Exchange 2003

4

4

2

Kerio Mailserver

4

4

3

File

Server 2003

4

5

2

Samba

4

5

5

Print

Server 2003

4

5

nvt

CUPS

4

5

5

Gebruikers Active Directory

4

4

nvt

OpenLDAP

4

3

5

DHCP

Server 2003

4

4

nvt

dhcp3-server

5

4

5

DNS

Server 2003

4

4

nvt

bind

3

4

5

Proxy

ISA server

3

3

3

Squid

4

4

5

Firewall

Windows Firewall

3

3

nvt

Shorewall

4

4

5

Backup

Ntbackup

4

4

nvt

Backuppc

5

5

5

CMS

Sharepoint 2003

3

3

2

Drupal

4

4

5

4

4

2

4

4

5

Score

14

3.5

Conclusie en aanbevelingen

Uit de tabel blijkt dat zowel Open als Closed Source software bij de beheersbaarheid en de gebruikersvriendelijkheid redelijk tot goed uit de bus komen. Het grootste verschil zit hem echter in de kosten voor de software. Hier komt de Closed Source software veel duurder uit. Er zijn uitschieters bij waarbij Sharepoint Server 2003 enkele duizenden euro's koste, terwijl een CMS als Drupal gratis is. Als gevolg van deze hoge kosten zal bij een Closed Source varianten bij de aanschaf in de eerste plaats gekeken naar de prijs en vervolgens naar de functionaliteiten. Hierop wordt dan ook de overweging gemaakt tot het niet of wel aanschaffen van een product. Bij Open Source pakketten wordt vaak in eerste instantie gekeken of het wel een volwassen product is en vervolgens naar de functionaliteiten. Bij FOSS komen de kosten voornamelijk uit het advies en onderhouds aspect wat bij de software geleverd wordt. Voordeel hierbij is dat men zich volledig kan richten op het al dan niet passen van het product binnen de organisatie. En mocht het ene pakket niet voldoen, dan kan er naar een alternatief gekeken worden. Zeker voor een stichting als het R@sto, welke een beperkt budget heeft, is het aantrekkelijk om naar Open Source alternatieven te gaan kijken. Daarnaast kan het implementeren van Open Source software niet alleen zinvol zijn voor het R@sto, maar wellicht ook voor eventuele klanten die het R@sto via projecten krijgt. Een nadeel van Open Source software aan de beheerders kant kan zijn dat er nog niet er veel grafische beheer tools ontwikkeld zijn, terwijl dit aan de Closed Source kant wel goed voor elkaar is. De conclusies en aanbevelingen die ik in deze paragraaf heb opgeschreven zijn gebaseerd op 3 criteria beheersbaarheid, gebruikersvriendelijkheid en de kosten. Op basis van deze 3 criteria lijkt voor R@sto FOSS het beste uit de bus te komen. Echter om een definitieve uitspraak te kunnen doen is het noodzakelijk om deze 3 criteria verder onder te verdelen en meer gedetailleerd te kijken naar de verschillen. Hierbij kun je denken aan verschil in licenties, inzicht in de code en transparantie van producenten. Dit zal dan ook nader onderzocht worden in hoofdstuk 4.

30

H4

Open Source voor het R@sto

In hoofdstuk 3 is aan de hand van 3 criteria vluchtig gekeken naar Open Source en Closed Source software. In dit hoofdstuk zullen de verschillen tussen Open Source en Closed Source software verder onderzocht worden ten einde een definitieve aanbeveling te doen aan het R@sto over welke softwarevorm te kiezen. In paragraaf 4.1 zal een beschrijving plaats vinden in wat voor situatie het R@sto zich op dit moment bevindt. Daarna zal in paragraaf 4.2 en 4.3 dieper in gegaan worden op de voor- en nadelen van zowel Open als Closed Source software. Hiervan zal in paragraaf 4.4 een tussenstand gegeven worden. Een logische opvolging is om vervolgens in paragraaf 4.5 te kijken naar de mogelijke vormen van netwerkstructuren die mogelijk zijn. Een samenvatting hiervan wordt gegeven in paragraaf 4.6. Als de softwarevorm (Open of Closed) en de netwerkstructuur duidelijk zijn, wordt er in paragraaf 4.7 in gegaan op de kosten van de twee softwarevormen. Als laatste worden de verschillende vormen van migratie belicht. Tenslotte worden in de laatste paragrafen conclusies getrokken en een aanbeveling gedaan aan de hand van tussenconclusies en bevindingen uit het gehele hoofdstuk.

4.1

Beschrijving van de beginsituatie

Het R@sto is een stichting en is budgettair niet in staat om dure software aan te schaffen. Dit wordt gedeeltelijk gecompenseerd doordat het R@sto een onderdeel is van het ROC Leiden en dus ook mee kan profiteren van de licenties die door het ROC aangeschaft worden. De licenties van het ROC Leiden zijn door het R@sto gratis te gebruiken. Mocht het R@sto echter software willen gebruiken die niet door het ROC gebruikt wordt, dan zal deze software door het R@sto zelf aangeschaft moeten worden. Hier komt dan een flinke som geld aan te pas. Het R@sto heeft daarnaast de wens uitgesproken om op netwerkgebied niet meer afhankelijk te willen zijn van het ROC Leiden. De reden dat het R@sto niet eerder over is gegaan naar een volledig Open Source netwerk is het gebrek aan kennis bij de vaste medewerkers van het R@sto. Een tweede reden is dat de software die het R@sto van het ROC Leiden krijgt gratis gebruikt mag worden. Waarom dan overstappen naar Open Source? Met voorgaand wordt echter wel een stuk afhankelijkheid gecreëerd van in eerste instantie het ROC Leiden en in tweede instantie closed source software. Closed Source software kan immers niet aangeschaft worden, omdat dit te duur is. Om onafhankelijk te worden van het ROC Leiden zal het R@sto kennis moeten gaan vergaren over Open Source software en zal het R@sto zich af moeten vragen of zij de stap naar Open Source software durft te zetten. Om te bepalen of het R@sto naar een Open Source ICT omgeving kan en wil migreren zal er onderzoek gedaan moeten worden naar de mogelijkheden hoe en in wat voor vorm er naar Open Source gemigreerd kan worden. Wat zijn de voor en tegens van zo'n migratie? Zal het R@sto er op vooruit gaan?

31

4.2

Free Open Source Software

In de afgelopen jaren is de populariteit van FOSS sterk gestegen en zijn er grote en kleine bedrijven FOSS gaan produceren of hebben hun producten onder de General Public License (GPL) licentie uitgebracht. Deze software wordt voornamelijk gebruikt door grote bedrijven en een aantal Internet Service Providers (Xs4all). Nu het midden- en kleinbedrijf de successen van grote bedrijven gaat zien begint ook deze groep interesse te tonen in het gaan gebruiken van FOSS. Het daadwerkelijk invoeren en gebruiken van FOSS verschilt vaak per regio of per bedrijf. Redenen hiervoor zijn dat bijvoorbeeld een gemeente erg pro FOSS is waardoor ook bedrijven in die gemeente gestimuleerd worden om FOSS te gaan gebruiken of te leveren, terwijl andere gemeenten hier niets voor voelen en tevreden zijn met de huidige software. Voorgaande kan ook opgaan voor bedrijven of scholen. Reden voor het wel of niet gebruiken van FOSS wordt beschreven in paragraaf 4.2. Software kan op verschillende manieren worden uitgegeven, zo is er niet geheel een strakke afsplitsing tussen Closed Source software en FOSS, maar zijn er ook nog een aantal tussenvormen. Hieronder worden de vier meest voorkomende vormen kort beschreven. 1. Software die juridisch beschermd wordt door een bedrijf. Voorbeelden hiervan zijn Microsoft Word of Adobe Photoshop. Bedrijven hebben hierop een licentie genomen en tenzij een dergelijke licentie aangekocht wordt, is het niet toegestaan hier gebruik van te maken. 2. Software die publiek beschikbaar is, maar wordt beschermd door bedrijven. Hierbij is te denken aan het PDF (Postscript Document Format) formaat van Adobe of de programmeertaal java van Sun. Beide standaarden kunnen door het grote publiek min of meer gratis gebruikt worden. Wie echter met de code van deze standaarden aan de slag wil, zal een overeenkomst moeten sluiten met de bedrijven die achter deze standaarden zitten. Zij maken gebruik van een eigen Open Source licentie. 3. Software die vrij is van juridische beperkingen, maar hoeft niet altijd om algemeen goedgekeurde standaarden te gaan. 4. Software waarbij de verschillende standaarden goedgekeurd moeten zijn door een organisatie voor open standaarden. Bijvoorbeeld html, xml of jpeg.

4.2.1

Redenen om voor FOSS te kiezen

Over het ontstaan van de term Open Source zegt de website Wikipedia.org het volgende “Het "Open Source"-label ontstond tijdens een strategiesessie in Palo Alto, Californië, als reactie op Netscape's mededeling in januari 1998 dat de broncode van Navigator zou worden vrijgegeven. De leden van de sessie, Christine Peterson, Todd Anderson, Larry Augustin, Jon Zaal, SAM Ockman, en Eric S. Raymond, stelden voor om voor deze release de term "Open Source" te gebruiken om de ideologische en verwarrende connotaties van de term free software te 32

voorkomen. Uiteindelijk werd de open-sourcelicentie ondergebracht bij de Mozilla Foundation.” Het Open Source Initiative werd in 1998 door Eric S. Raymond en Bruce Perens opgericht om de voordelen van Open Source te promoten in de commerciële markt. Bruce Perens gebruikte hierbij de Free Software Guidelines van Debian om de Open Source Definition te creëren. Critici wijzen erop dat de term "Open Source" dubbelzinnig is en dat het verwarring schept over de volledige beschikbaarheid van de bronnen met de vrijheid van gebruik, modificatie en herverspreiding. Softwareontwikkelaars gebruiken daarom liever de term Free Open-Source Software (FOSS), of Free/Libre/Open-Source Software (FLOSS) om open-sourcesoftware te beschrijven die vrij en gratis beschikbaar is. Het ontwikkelen en gebruiken van FOSS onderscheidt zich van Closed Source software door een aantal kenmerkende aspecten. Zo zijn de bedrijven die FOSS produceren transparant doordat zij de ontwikkeling en voortgang van de te produceren software en bugs publiceren op websites en in nieuwsbulletins. Hierdoor is er altijd inzicht in het reilen en zeilen van de ontwikkeling. Daarnaast wordt een goede continuïteit van de software gegarandeerd door het geregeld uitbrengen van nieuwe releases en bugfixes. De software wordt op een eenvoudigere en stabielere manier geprogrammeerd waardoor de software duidelijker in elkaar zit en het beheer ervan simpeler wordt. FOSS dient door het open karakter van de broncode duidelijk geprogrammeerd te worden, goed te worden voorzien van commentaar binnen de code zodat andere programmeurs ook nog wijs uit de code kunnen en deze naar wens aan kunnen passen. Daarnaast wordt Open Source software zodanig geprogrammeerd dat er alleen het noodzakelijke in verwerkt hoeft te worden. Wil men meer dan kan dit altijd toegevoegd worden door het toevoegen van nieuwe modules of extra programmacode. Hierdoor wordt de gebruiker niet overspoeld met functies die voor het grootste gedeelte nooit gebruikt zullen worden, zoals in Closed Source software het geval is. Een voorbeeld van simpeler beheer is de rechtenstructuur die bij Linux wordt toegepast ten opzichte van die bij Microsoft wordt toegepast. De rechtenstructuur die bij Linux van toepassing is op mappen en bestanden bestaat uit rechten voor de eigenaar, de groepen binnen het systeem en “overigen”. Deze 3 groepen kunnen ieder een combinatie hebben van lezen, schrijven en uitvoeren. De rechtenstructuur van Microsoft is zo ingewikkeld dat deze niet in een paar zinnen uit te leggen is. Door bovengenoemde voordelen zullen de kosten van Open Source software lager uitkomen dan bij Closed Source software. Deze lagere kosten worden onderbouwd door verschillende onderzoeken. Een voorbeeld is een onderzoek dat de Deense overheid uit 2002 heeft uitgevoerd. Hieruit is gebleken dat het installeren van Open Source op 2000 desktops kostenbesparingen oplevert op het gebied van licentiekosten en het feit dat er geen gedwongen upgrades zijn. Daarnaast worden ook kosten bespaart doordat Open Source software minder belastend is voor de hardware, waardoor deze langer mee gaat. Door de licentiekosten van Closed Source software te vervangen door het geven van adviezen en ondersteuning voor dezelfde of een lagere prijs kan 33

de software veel efficiënter en klantvriendelijker ingezet worden. Door de broncode vrij te geven is de klant ook niet meer afhankelijk van een leverancier waardoor de zogenaamde vendor lock-in vermeden wordt. Om het FOSS model compleet te maken wordt het ondersteund door open standaarden, zoals XML of Java. Door gebruik te maken van XML wordt software toepasbaar op een grote variëteit aan besturingssystemen, zoals Windows, Apple of Solaris. Een voordeel hiervan is dat er, bij een integratie van closed software met FOSS, er aanknopingspunten en tools beschikbaar zijn in de FOSS die deze integratie mogelijk maken. In de Closed Source software zijn die aanknopingspunten niet nodig, omdat deze alleen rekening hoeft te houden met de eigen standaarden. Een voorbeeld hiervan is dat Microsoft Word alleen Word documenten hoeft te kunnen openen en geen ODF (Open Document Format) hoeft te kunnen openen. Het gebruik van open standaarden heeft als voordeel dat het formaat niet gebonden is aan een leverancier. Hierdoor is de documentatie altijd beschikbaar ook al is de maker van een bepaald document reeds verdwenen of niet meer beschikbaar. FOSS garandeert kwaliteit en continuïteit in het gebruik, omdat: ●

de gebruiker niet meer afhankelijk is van de overlevingskans van softwareleveranciers

●

de gebruiker kan laten door ontwikkelen op de aangekochte software (voor eigen aanpassingen of behoeften binnen de software)

●

de gebruiker kan profiteren van succesvolle ontwikkelingen van (voorgaande) collega gebruikers/programmeurs

●

de data-uitwisseling via open standaarden zoals XML verloopt en daardoor universeel is

Voorbeelden van open standaarden zijn: ●

XML (eXtensible Markup Language)

●

ODF (Open Document Format)

●

PHP (PHP: Hypertext Preprocessor)

●

HTML (Hyper Text Markup Language)

Open standaarden dienen te voldoen aan: ●

het vaststellen van de standaard door een open beslissingsprocedure

●

open beslissingsprocedures dienen openlijk gepubliceerd te worden

●

de gebruikerskosten laag zijn waardoor de drempel laag is voor toegang tot de standaard

●

het intellectuele eigendom van de standaard ligt bij non-profit organisaties die een volledig vrij toetredingsbeleid kent

●

er geen beperkende voorwaarden zijn voor het hergebruik van de standaard

Wanneer er geen gebruik wordt gemaakt van open standaarden dan is het vaak niet duidelijk hoe informatie aangeleverd dient te worden en in wat voor vorm deze informatie gepresenteerd dient te 34

worden. Een goed voorbeeld hiervan is het maken van reclamefolders door een bedrijf welke vervolgens door een drukker dienen te worden gedrukt. Het bedrijf zal zijn folders vaak in Word of met een tekenprogramma maken, terwijl de drukker het liefst PDF aangeleverd wil hebben. Door gebruik te maken van open standaarden wordt de duurzaamheid van de data bevordert door informatieuitwisseling tussen verschillende versies van software en besturingssysteemen mogelijk te maken. De voordelen van het gebruik van open standaarden zijn: ●

toegankelijkheid, het vermogen tot uitwisseling tussen ICT-systemen

●

gemakkelijk aan te passen, door gebruik te maken van standaard programmeertalen

●

duurzaamheid, maakt gebruik binnen en uitwisseling tussen verschillende besturingssystemen en versies mogelijk

●

interoperabiliteit en herbruikbaarheid, door gebruik te maken van een vaste standaard voor gegevensuitwisseling

●

concurrentie effect, door een open standaard is de klant niet meer afhankelijk van een leverancier

FOSS wordt dus ondersteunt door open standaarden en heeft als voordeel dat de uitwisseling en hergebruik van data tussen eigen systemen en Open Source systemen van andere bedrijven vergemakkelijkt wordt. Daardoor zijn open standaarden cruciaal voor het optimaal gebruiken en hergebruiken van informatie.

4.2.2

Redenen om niet voor FOSS te kiezen

De sterke opkomst van FOSS heeft natuurlijk niet voor iedereen alleen maar voordelen. Er bestaan ook nadelen van FOSS. Deze kunnen voortkomen uit motivaties van bedrijven die door prima ervaringen met Closed Source software alles bij het oude willen houden, omdat het prima functioneert. Deze bedrijven krijgen vaak ook grote kortingen op de hoeveelheid licenties die zij afnemen. Een ander nadeel is dat de volwassenheid van FOSS nog steeds ter discussie staat, met daarnaast onduidelijkheid wie aansprakelijk gesteld kan worden voor een Open Source product. Dit vanwege het openbaar zijn van de code, waardoor iedereen deze aan kan passen. De tegenstanders van FOSS proberen uit alle macht de opkomst van deze soort software te dwarsbomen. Dit doen ze door middel van tegenonderzoeken en marketingtactieken, zoals FUD (Fear, Uncurtenty and Doubt). Deze strategie zorgt ervoor dat een afschrikeffect ontstaat bij mensen zodat deze zich behoudend op gaan stellen. Een goed voorbeeld hiervan is het nieuwsbericht van Microsoft dat Open Source software wel 235 Microsoft patenten zou schenden. Vervolgens blijkt uit een poll in het blad Computable waarin gevraagd wordt of men zich nu terughoudender op gaat stellen hier 98% voor ja kiest. Men gaat als gevolg van dit soort tactieken vast houden aan het bekende. En dus aan het bekende Closed Source software. Andere nadelen zijn: ●

Crackers kunnen in de software makkelijk gaten vinden, omdat deze vrij beschikbaar is en 35

dus ook door iedereen aangepast kan worden. Ook met slechte code ●

Door het open karakter van de code kunnen programmeurs veel makkelijker kwaadwillende code in de programma's verstoppen

●

Over het algemeen is het niet zo gebruiksvriendelijk voor de grote massa gebruikers , omdat deze reeds decennia gewend zijn aan het Microsoft besturingssysteem

●

Open Source software zal altijd door middel revers engineering moeten proberen om met de closed source software mee te gaan. Daardoor zal het altijd achter lopen op protocollen en bestandsformaten die gebruikt worden door Closed Source software. Dit bemoeilijkt de communicatie tussen Open en Closed source software. Bijvoorbeeld met de nieuwe Office 2007 formaten.

4.3

Closed Source software

De redenen om wel of niet voor Closed Source software te kiezen kunnen ver uit elkaar liggen en zijn vaak afhankelijk van de wensen van klanten en het doel waarvoor de software gebruikt gaat worden.

4.3.1

Redenen om wel voor Closed Source software te kiezen

De voornaamste reden waarom er voor Closed Source softwarepakketten gekozen wordt is dat ze bekend zijn bij vrijwel alle gebruikers. Door bekendheid met de software is er geen sprake van een inwerk of gewennings periode waardoor tijd verloren kan gaan. Al zal bij een migratie naar nieuwe software altijd een inwerk periode nodig zijn. Doordat de Closed Source software op zo'n grote schaal in gebruik is (Office en Internet Explorer wel 90% van het totaal aantal gebruikers) is er genoeg ondersteuning mochten er problemen ontstaan. Netwerk- en systeembeheerders zijn vaak op de hoogte van het hoe en wat van Closed Source omgevingen, maar hebben een te kort aan kennis als het een Open Source omgeving betreft. Daarnaast is een Closed Source omgeving minder sterk onderhevig aan verandering waardoor het beter te behappen is voor het grootste deel van de gebruikers. Een voordeel van het niet openbaar zijn van de broncode is dat beveiligingsgaten niet snel worden gevonden en dus ook niet snel misbruikt kunnen worden door hackers. Doordat de broncode gesloten is, kan men het als product verkopen en levert het dus geld op. Bij games is het voordeel dat er niet zo snel gecheat kan worden. In het kort zijn de voordelen om voor Closed Source te kiezen: ●

bekend bij de gebruiker waardoor deze niet voor verassingen komt te staan

●

gemakkelijke ondersteuning bij problemen, netwerkbeheerders zijn bekend met closed software

●

groot marktaandeel (iedereen gebruikt het dus het zal wel goed zijn)

●

broncode is onbekend

●

product levert geld op voor ontwikkelaars

●

is niet aan echter verandering onderhevig 36

●

is moeilijk voor gamers om te spelletjes niet via de officiële manier te spelen

4.3.2

Redenen om niet voor Closed Source software te kiezen

Bedrijven die Closed Source software produceren zijn vaak niet transparant voor de klant en zijn voornamelijk gericht op het verkopen van softwarelicenties, dit blijkt uit het niet inzichtelijk zijn van de status van bugs, roadmaps voor softwareontwikkeling en de broncode van de software. Hierdoor kost Closed Source software over het algemeen geld en wordt de klant bij problemen met de software nogal eens geadviseerd om te wachten op de volgende serie, omdat daar het probleem dan verholpen zal zijn. Mochten fouten in de software voor komen die door crackers misbruikt kunnen worden dan blijven deze fouten lange tijd beschikbaar, omdat het lang duurt voordat zo'n fout verholpen is door middel van updates en patches. Deze fouten treden op doordat de programmeur bij een Closed Source softwarepakket vaak niet door externe programmeurs op fouten gewezen wordt, omdat de broncode niet openbaar gemaakt wordt. Doordat de broncode niet openbaar gemaakt, wordt is de klant afhankelijk van de functionaliteiten die de producent in de software stopt. Hierdoor wordt de vrijheid en flexibiliteit van de software sterk beperkt. In het kort zijn de nadelen van Closed Source software: ●

geen transparantie van Closed Source bedrijven

●

dure softwarelicenties

●

geen inzichtelijkheid in bugs, ontwikkeling en broncode

●

lange oplostijd van bugs

●

beperkte vrijheid en flexibiliteit

4.4

Voorlopige keuzebepaling

Binnen deze voorlopige keuzebepaling voor Open of Closed Source software worden de voor- en nadelen in een tabel tegen elkaar uit gezet. Deze beoordeling vind plaats op basis van 6 criteria, namelijk: ●

Wat voor softwarelicenties horen bij het product?, wordt hier voor betaald of niet, hoeveel mogen er gebruikt worden per product

●

Hoe toegankelijk is de software? Is het mogelijk om de software gemakkelijk naar eigen wens aan te passen of dient gebruik gemaakt te worden van geboden opties

●

Wat zijn de kosten van de software? Liggen deze absurd hoog, zijn ze redelijk of goed.

●

Hoe zit het met de beveiliging van de software? Is de code op een zodanig goede manier geschreven dat er moeilijk misbruik van gemaakt kan worden? Worden er regelmatig patches uit gebracht?

●

In hoeverre is de software te beheren? Zijn hier goede tools voor aangeboden? Gaat de software niet teveel beslissingen zelf nemen terwijl dat niet gewenst is.

37

Als invulling voor de criteria zal ik gebruik maken van een systeem bestaande uit cijferreeks. Deze cijferreeks zal ik punten van 1 tot 5 lopen, waarbij 1 zeer slecht en 5 zeer goed is. Hieronder volgt de legenda: 1

zeer slecht

2

slecht

3

gemiddeld

4

goed

5

zeer goed

Tabel 4

Voor- en nadelen van open en Closed Source software

Voor- en

Software- Toegang

nadelen

licenties

Open Source

Kosten Beveiliging Beheers- Vertrouwdheid/ Score

tot software

baarheid bekendheid

5

4

4

4

4

2

4

3

1

1

4

3

5

3

software Closed Source software

4.5

Voorlopige aanbeveling softwarekeuze

Bij het bepalen van een keuze tussen Open of Closed Source software wordt voor veel bedrijven een grote stap gemaakt. Er gaat immers met een geheel andere, onbekende vorm van software gewerkt worden. Het bedrijf moet dan ook bereid zijn om hier in te investeren, zowel financieel als op het gebied van kennis, en zal deze stap goed en doordacht aan dienen te nemen. Echter zal gekeken dienen te worden welke criteria belangrijk zijn voor het bedrijf en of deze criteria beter naar voren komen in Open Source software of Closed Source software. Uit de bovenstaande tabel en de literatuur uit paragraaf 4.5 komt naar voren dat Open Source en Closed Source allebei zo hun voor en nadelen hebben. Maar omdat de criteria die voor het R@sto van belang zijn vooral liggen bij lage kosten en het flexibel zijn van de software ligt een keuze voor Open Source software voor de hand.

4.6

Mogelijke combinaties binnen de netwerkinfrastructuur

Binnen de huidige netwerken wordt vaak gesproken over een client-servermodel. Dit model zorgt voor het verdelen van taken tussen clients (desktops) en servers. Netwerktaken komen voor de rekening van de servers en alles wat lokaal op de clients geregeld kan worden komt op rekening van de clients. In deze paragraaf wordt dieper in gegaan op de mogelijke combinaties die mogelijk zijn tussen Open en Closed Source software op clients of servers of beide.

38

4.6.1

Windows server met Windows clients (Closed)

Een netwerkmodel wat volledig bestaat uit Microsoft clients in combinatie met Microsoft servers is een model dat goed op elkaar is afgestemd en prima met elkaar samen kan werken. Zo kunnen clients volledig gebruik maken van alle faciliteiten en functionaliteiten van de servers, kunnen alle clients in een Active Directory aangemeld worden en kunnen er servers worden ingericht als proxy, file en print servers. Voor het afhandelen van zogenaamde groupware (email, kalender, taken, afspraken, etc.) functionaliteiten is de alom bekende Exchange server volledig in een Active Directory structuur te integreren. Al deze functionaliteiten zijn door middel van het configureren van een VPN (Virtual Private Netwok) van buiten het eigen netwerk te benaderen en te gebruiken. Daarnaast biedt Microsoft nog een heleboel mooie pakketten aan die veel functionaliteit aan uw netwerkmodel en bedrijf kunnen toevoegen. De kwaliteit van de software is met de laatse releases sterk verbeterd en stabieler geworden. Waar Microsoft software vroeger nog wel eens wilde crashen met het Blue Screen Of Death wordt dit met de laatste releases steeds minder. Dit geeft aan dat de software steeds stabieler gaat draaien, al draait het grootste gedeelte nog wel op oude code. Het grootste voordeel ligt echter in het feit dat iedereen de software door een door kent, met al zijn nukken en foefjes. Van zowel het Office pakket als van het Windows besturingssysteem weet het grootste gedeelte van de gebruikers hoe deze software werkt. De nadelen van een netwerkmodel wat volledig gericht is op Microsoft komen om de hoek kijken als er bijvoorbeeld een upgrade van de software dient te worden gedaan. Dit kan het geval zijn als oude software niet meer ondersteund of geleverd wordt of bepaalde applicaties niet meer op oudere software draait. Op dat moment dient er nieuwe software aangeschaft te worden en dit hangt samen met het aanschaffen van dure licenties en vaak ook met de aanschaf van nieuwe hardware. Zo is het dat voor een pc bijvoorbeeld een licentie voor het operating system aangeschaft dient te worden, maar ook voor het office pakket en voor het aansluiten van de pc aan een server. Bij gebruik van een terminal server dient er zelfs voor iedere connectie een licentie aanwezig te zijn. Door al deze kosten wordt een bedrijf steeds afhankelijker van Closed Source softwareleveranciers. Hiermee wordt een vendor lock-in gecreëerd en wordt de drempel om over te stappen naar een andere aanbieder, die misschien wel de functionaliteit heeft die de ander niet heeft, steeds moeilijker. Een bedrijf zal het met de service en aangeboden functionaliteiten van de softwarepakketten die de softwareleverancier aanbied moeten doen. Tevens streven deze pakketten er vaak naar om zo volledig mogelijk te zijn, terwijl in de meeste gevallen minder dan de helft van de functionaliteiten maar gebruikt wordt. Voor de overige helft wordt echter wel betaald.

4.6.2

Linux server met Windows clients (Open/Closed)

Een netwerkmodel op basis van Linux servers en Windows clients is een netwerk wat prima kan functioneren. Linux servers zijn namelijk volledig transparant voor Windows clients waardoor de clients niet door hebben dat ze met een Linux server aan het communiceren zijn. Een ander voordeel van deze opzet is dat de gebruikers reeds bekend zijn met de Windows clients en dus 39

niet opgeleid hoeven te worden om met een ander besturingssysteem te gaan werken. Nadeel kan zijn dat er bepaalde applicaties “geport” dienen te worden naar de nieuwe netwerk omgeving. Het porten van een applicatie wil zoveel zeggen als het aanpassen van de applicatie zodat deze ook in de nieuwe omgeving kan draaien. Hierbij valt te denken aan administratiepakketten of financiële pakketten. Deze draaien vaak op een Windows omgeving, maar kunnen niet op een Open Source omgeving draaien. Eventuele oplossingen hiervoor zijn het opzetten van een terminal server of het aanschaffen van virtualisatie software. Met dit laatste kan een Windows omgeving ge-emuleerd worden of zelfs een gehele virtuele installatie van een Windows omgeving gedaan worden.

4.6.3

Linux server met Linux clients (Open/Open)

Linux server met Linux clients is een volledige Open Source oplossing. Nadeel van deze opstelling is dat de gebruikers met Linux dienen te gaan werken. Hier zal dus opleiding voor gevolgd moeten worden wat weer resulteert in extra kosten bij een eventuele migratie. Aan de kant van de beheerders kunnen er problemen ontstaan met applicaties die niet op een Open Source omgeving draaien. Vaak komen dit soort problemen al naar voren bij de inventarisatie die voor een migratie plaats vindt.

4.6.4

Windows server met Linux clients (Closed/Open)

Het opzetten van een netwerkinfrastructuur die gebaseerd is op Microsoft Windows Server en Linux desktop clients is op dit moment wel mogelijk, alleen wordt niet standaard door de Microsoft Servers ondersteund. De voornaamste reden is dat de Active Directory applicatie van een Windows server niet standaard is ingericht op het opnemen van Linux clients in het systeem. De Microsoft Active Directory is daardoor niet transparant voor Linux Clients. Daarnaast wordt er door Microsoft pas in de allerlaatste versie van Server 2003 ondersteuning geleverd voor het gebruik van sommige Linux clients (Red Hat en Novell Suse) in hun Active Directory. Uiteraard kunnen er bepaalde redenen zijn om dit wel te doen, zoals het hebben van verouderde desktops waarop Linux beter draait dan Windows of het hebben van een breed draagvlak onder de netwerkgebruikers om Linux op de desktops te gaan draaien

4.7

Samenvatting in tabel

In onderstaande tabel wordt aan de hand van 5 criteria een vergelijk gemaakt tussen de 5 verschillende netwerkstructuren uit paragraaf 4.7. De voor- en nadelen van deze structuren komen naar voren vanuit de tekst en zullen gebundeld worden binnen deze 5 criteria. Deze criteria zijn belang voor het verkrijgen van een goed werkend homogeen netwerk. Om de relevantie van de criteria ten opzichte van de netwerkstructuren aan te geven maak ik gebruik van een plus (+) voor belangrijk en een min (--) voor minder belangrijk. De notatie zal tussen haakjes achter de waardering komen te staan. De criteria met een min zullen voor de helft in de score worden meegenomen. 40

Voor de waardering zal ik gebruik maken van een cijfermatig systeem waarbij de waarden van 1 tot 5 lopen. Hier staat een 1 voor zeer slecht en een 5 voor zeer goed. 1

zeer slecht

2

slecht

3

gemiddeld

4

goed

5

zeer goed

Tabel 5

Voor- en nadelen behandelde netwerkstructuren

Voor- en nadelen

Transparantie

Haalbaarheid

Samenwerking

Gebruikers

netwerkstructuren

(--)

(+)

(+)

vriendelijkheid

Score

(+) Windows server/

5

5

5

5

4

3

3

3

4

3

4

4

5

5

4

5

5

5

5

4

Windows clients Windows server/ Linux clients Linux server/ Windows clients Linux server/ Linux clients Argumenten die binnen de tabel worden gebruikt wegen niet allemaal even zwaar mee in de beoordeling. Zo is de transparantie van een netwerk niet essentieel voor het goed functioneren van het netwerk. Gebruikers zullen niet gaan kijken of ze connectie maken met een Windows of een Linux server. Mocht de gebruiker wel zelf connectie dienen te maken, dan zal dit het aanleren van een handeling zijn.

4.8

Voorlopige aanbeveling netwerkinfrastructuur

Uit bovenstaande tabel en de literatuur uit paragraaf 4.8 kan geconcludeerd worden dat er 3 netwerkinfrastructuren als optie eruit springen. Gaan we echter naar de situatie van het R@sto kijken dan valt de optie voor Windows server/Windows clients af. Men wil immers van de hoge kosten van deze software af. Daarna blijven de opties Linux server/Windows clients en Linux server/Linux clients over. Met deze opties worden de kosten gedrukt en kunnen zowel Linux clients (desktops) als Windows clients (laptops stagiaires) op een transparante manier gebruik maken van de Linux servers. De voordelen die dit oplevert zijn namelijk gebruikersgemak, het scheelt kosten en het scheelt in het onderhoud. Dit is met name handig in een omgeving waar elke 6 maanden nieuw personeel rond loopt. Bij veel onderhoud aan de software kost dit geld en tijd. Mijn voorkeur gaat dan ook uit naar een infrastructuur die Linux servers met Linux/Windows clients bevat. 41

4.9

Total Cost of Ownership

Na bovengenoemde analyse kun je ook een TCO onderzoek uitvoeren om aan te tonen of bepaalde software het waard is om aan te schaffen. Dit heeft in een industrie als die van de software een ware wapenwedloop ontketend heeft. Er zijn dan ook weinig rapporten die een onafhankelijk oordeel vellen over de onderzochte softwarepakketten. Sommige rapporten worden als paginagrote advertenties gebruikt en andere worden weer gefinancierd door het bedrijf wat de software dient te verkopen. Door al deze tegengestelde rapporten wordt een soort rookgordijn op geworpen wat de zogenaamde FUD strategie in de hand werkt. Met deze strategie spelen de huidige softwaremonopolisten in op het effect wat gecreëerd wordt bij mensen die twijfelen. Deze mensen zullen zich terughoudender op gaan stellen ten opzichte van nieuwe software en bij het oude bekend blijven. In het rapport “Investeren in Openheid” worden de kostenverschillen tussen open en Closed Source software bepaald aan de hand van directe kosten en indirecte kosten van software. Ik zal dezelfde indeling aanhouden, omdat dit een goed beeld geeft van de kosten die komen kijken bij softwaregebruik.

4.9.1

Directe kosten van kapitaalgoederen

De directe kosten van kapitaalgoederen wordt opgesplitst in twee onderdelen, namelijk de hardware en de software. Hardware In de eerste plaats zal ik de hardware behandelen waarvoor uit verschillende onderzoeken blijkt dat er met het gebruik van Linux bespaart kan worden op de hardware. Er zijn twee oorzaken die aan de grondslag liggen van deze besparing. De eerste oorzaak is dat Linux veel flexibeler is wat betreft de verschillende hardwarearchitecturen waarop het kan draaien. Linux kan namelijk op 15 verschillende architecturen draaien. Daar in tegen kan Windows maar op een architectuur draaien en dat is de x86 Intel architectuur. Dit levert een sterke beperking op voor de hardware die men aan wil schaffen. Een tweede oorzaak die regelmatig terug komt in onderzoeken is dat Open Source software veel minder eisen stelt aan de hardware waar het op draait. Dit in tegenstelling tot Closed Source software. Nu geldt niet voor ieder Open Source software pakket dat deze minder eisen stelt aan de hardware, maar Open Source software kan, door het open karakter, wel optimaal aangepast worden voor bepaalde, vaak oudere, systemen. Software In het geval van de software wordt er bij Open Source software geen gebruik gemaakt van licentiekosten. Daardoor hoeft men geen rekening te houden met EULA (End User License Agreements) of CAL (Client Access License). Licenties die gebruikt worden voor Open Source 42

software geven veel vrijheden waardoor de software zonder kosten of gevolgen verspreid kan worden of op meerdere systemen geïnstalleerd kan worden. Echter kan het wel voorkomen dat er betaald dient te worden voor de aanschaf van de software. Zo vragen distributeurs die verschillende pakketten samen tot een goed werkend product of distributie maken wel een kleine vergoeding. Deze vergoeding staat echter in geen verhouding die men betaalt voor aanschaf en licenties van Closed Source producten. Uit bovenstaande informatie blijkt dat Open Source software wel degelijk kostenvoordelen biedt. Over het aandeel van deze kosten in het totale pakket van kosten is men nog sterk verdeeld. Deze kosten worden echter sterk bepaald door omstandigheden. De grootste posten binnen de totale kosten van software zijn voornamelijk de kosten van arbeid, die samenhangen met administratie en operatie. Deze bepalen wel de helft van de totale TCO . Het aandeel van licentiekosten binnen de TCO ligt tussen de 20% en 50%. Dit zijn vaak directe kosten welke het beste bekend en beïnvloedbaar zijn. Dit in tegenstelling tot bijvoorbeeld de kosten die horen bij arbeid. Uiteraard is ook de levensduur van software bepalend voor de kosten die software met zich mee brengt. In de regel ligt de levensduur van software tussen de 3 en 5 jaar. Als software voor langere duur ingezet kan worden, kunnen de kosten ook over een langere tijd uitgesmeerd worden. Aan de ene kant wordt de levensduur van software bepaald door de technische ontwikkeling, maar aan de andere kant ook door de commerciële strategie van de softwareleverancier. Als deze de software niet meer ondersteund wordt de klant gedwongen over te stappen naar nieuwere versies. In veel gevallen heeft dit ook gevolgen voor de hardware. In het geval van Open Source software is de broncode open, dus kunnen ook andere partijen dan de producent wijzigingen aanbrengen aan de software. Hierdoor kan de doorontwikkeling en ondersteuning overgenomen worden waardoor de software toch nog actueel blijft. Oudere versies van Linux blijven altijd op het internet beschikbaar.

4.9.2

Directe kosten van arbeid

De directe kosten van arbeid worden uitgesplitst in twee onderdelen, namelijk arbeidskosten voor operatie en arbeidskosten voor administratie. Arbeidskosten voor operatie Met betrekking tot operatie kan men twee aspecten onderscheiden, dit zijn namelijk de mate van specialisatie en de mate van automatisering. Bij de mate van specialisatie komt naar voren dat de salarissen van technisch personeel hoog liggen. De voornaamste oorzaak hiervan is dat de mate van specialisatie hoger ligt voor het beheer van veel Open Source software. De verwachting is

43

echter dat naarmate Open Source software populairder wordt er meer specialisten komen op Open Source gebied. Als gevolg hiervan zullen ook de salarissen gaan zakken. Met betrekking tot automatisering wordt in het onderzoek “Get the truth on Linux Management by EMA uit 2006” dat een beheerder van Open Source software meer systemen kan beheren dan binnen een Windows omgeving. Dit kan vervolgens een positief effect hebben op de operationele kosten. Deze hogere mate van automatisering is het gevolg van de mogelijk om Open Source netwerken te beheren door middel van scripts. Dit geeft tevens een verklaring voor de schaalvoordelen die uit verschillende onderzoeken naar voren komen. De besparing van de inzet van Open Source software stijgt meer dan evenredig met de grote van de organisatie. Arbeidskosten voor administratie Closed Source software wordt verkocht met licenties die gelden per gebruiker of per machine. Deze licenties brengen het gevaar met zich mee dat als de licentie niet geheel na geleefd wordt dat de producent van de software de gebruiker hier op kan aanspreken en de gebruiker hier een boete voor kan krijgen. Om dit te voorkomen dient er voor alle software die aangeschaft is een nauw licentiebeheer gedaan te worden. Dit licentiebeheer brengt behoorlijk wat kosten met zich mee. Open source software daarintegen verschaft zijn gebruikers veel vrijheden. Daardoor is de kans dat er inbreuk gemaakt wordt op de licentie van Open Source software vrij klein en worden kosten bespaard op het licentiebeheer. Terwijl dit wel een kostenbesparend aspect is van Open Source software komt het niet vaak terug in TCO onderzoeken. Trainingskosten hangen sterk af van de kwaliteit van software, de mate van verandering ten opzichte van de uitgangssituatie en de flexibiliteit van het personeel. Verschillende onderzoeken wijzen uit dat de trainingskosten voor zowel closed als Open Source software op het gebied van servers nauwelijks verschil maakt. Op desktopniveau zijn er wel verschillen in trainingskosten. Deze kosten kunnen, bij een volledige migratie, zo'n 1,5 tot 1,9 keer hoger liggen dan bij Closed Source software.

4.9.3

Indirecte kosten van arbeid

De indirecte kosten van arbeid zijn voornamelijk kosten die moeilijk meetbaar en dus ook moeilijk beïnvloedbaar zijn. Deze kosten worden bepaald door de ervaringen van de eindgebruiker en computeruitval. Uit Duits onderzoek op de website http://www.relevantive.de/Linux.html is gebleken dat op het gebied van gebruikersvriendelijkheid een Linux desktop nauwelijks onder doet voor een Windows desktop. Daarnaast kan de Open Source software door beheerders makkelijk aangepast worden aan de behoeften van eindgebruikers. Gevolg hiervan is dat ook onnodige functionaliteiten kunnen worden weg gelaten. In het geval van computeruitval scoren Open Source producten als Linux en webserver Apache hoge ogen op het gebied van stabiliteit. Dit blijkt uit verschillende onderzoeken, onder andere uit

44

een onderzoek van Bloor Research. Bij Linux is de stabiliteit voornamelijk te danken aan het feit dat er vrijwel nooit herstart hoeft plaats te vinden na een update.

4.9.4

Migratiekosten

Migratiekosten worden alleen meegenomen in TCO onderzoeken waarbij een bestaand netwerk gemigreerd wordt naar een nieuw netwerk. Het overgrote deel van de TCO onderzoeken worden echter uitgevoerd op een bestaand netwerk waardoor migratiekosten niet mee worden gerekend. Het wel of niet meerekenen van migratiekosten hangt dus sterk af van de uitgangssituatie van het TCO onderzoek. In de case specifieke TCO onderzoeken is de uitgangssituatie bekend en kan er wel met migratiekosten gerekend worden. Met case specifieke onderzoeken worden dan ook onderzoeken bedoeld die uitgevoerd worden op een echt bedrijf en niet op een Windows netwerk of een Linux netwerk. Kosten van migratie komen vaak terug in trainingskosten, het converteren van macro's en templates en het aanpassen van applicaties voor het nieuwe platform. De laatste twee activiteiten kunnen onder de kosten van operatie vallen. In veel gevallen is het uitgangspunt een Microsoft omgeving. Logischerwijs zal de overschakeling naar een niet Microsoft omgeving hogere migratiekosten met zich mee brengen dan wanneer men over schakelt naar een nieuw Microsoft platform. De voornaamste reden van de hogere migratiekosten ligt in het omzetten van de gesloten standaarden naar de nieuwe open standaarden. Hoge migratiekosten kunnen het onaantrekkelijk maken om te migreren naar een Open Source omgeving. Er dient echter wel rekening gehouden te worden met het feit dat deze kosten eenmalig zijn en dat zij zichzelf door jaarlijkse besparingen terug aan verdienen. Dit zal echter wel per geval bekeken moeten worden.

4.10

Mogelijke migratietrajecten van Windows naar Linux

Mocht uit voorgaande gebleken zijn dat het migreren naar of installeren van een Open Source netwerk de juiste keuze is dan zijn er een aantal manieren om dit migratie traject aan te pakken. Hieronder zal ik de 5 meest voorkomende methoden onderzoeken om een bestaand netwerk te migreren naar een Open Source netwerk. Deze methode zijn gebaseerd op een migratievolgorde van server naar client of andersom. Door middel van een tabel zal een duidelijk overzicht van de voor- en nadelen per methode uiteen worden gezet. Iedere methode zal getoetst worden op een 5tal criteria, namelijk: 1. Wat is het draagvlak bij het bedrijfsmanagement? 2. Hoe is de beleving van gebruikers ten aanzien van het gaan gebruiken van FOSS? 3. Hoe is de beleving van beheerders ten aanzien van het gaan gebruiken van FOSS?

45

4. Wat wordt het kostenplaatje van de gehele migratie? 5. Wat is de kans van slagen van de migratiemethode?

4.10.1

Eerst clients dan servers

Deze methode migreert het netwerk op een manier waarbij in de eerste stap de gebruikers desktop gemigreerd wordt naar een platform wat bestaat uit een Open Source besturingssysteem met bijbehorende applicaties. Daarna zal het servergedeelte gemigreerd worden naar een platform op basis van een Open Source besturingssysteem. Uiteraard worden de netwerkservices die door de gebruikers en het netwerk vereist worden met de servermigratie mee gemigreerd. Aan deze methode zijn een aantal voorwaarden verbonden en een aantal factoren die een soepelere migratie in de hand werkt. Als voorbeeld voor dit soort migraties kan de gemeente München dienen. Deze gemeente zag zich gedwongen te migreren, omdat haar computersoftware (Windows NT met Office 97) sterk verouderd was en deze niet meer door Microsoft ondersteund werd. Er is vervolgens gekeken wat de beste optie was voor het vernieuwen van het netwerk. Daar is een migratie naar FOSS uit gekomen. Bij de gebruikers van de gemeente München bestond er reeds een groot draagvlak voor het gebruik van FOSS en was er ook al enige expertise aanwezig. Dit laatste beperkt de opleidingskosten enigszins, omdat mensen kunnen leren van diegene die de expertise op Open Source gebied bezitten en dus minder opleiding hoeven te volgen om om te gaan met de nieuwe software. De top van de gemeente is slim in gesprongen op het grote draagvlak bij de gebruikers door deze groep goed op de hoogte te houden van beslissingen en voortgang ten aanzien van het invoeren van de FOSS bij de gemeente. Hiermee wordt namelijk begrip en betrokkenheid onder de gebruikers gecreëerd.

4.10.2

Eerst servers dan clients

Deze methode van migratie zal over het algemeen de meest voorkomende vorm van migratie zijn. Het voordeel van het eerst migreren van de servers en dan de clients is dat de gebruiker nog gewoon op het oude vertrouwde systeem door kan werken zonder dat deze rigoureuze veranderingen aan het netwerk of de desktop ondervind. De servers kunnen transparant worden gemigreerd naar een Open Source omgeving. Hierdoor kan de afdeling systeembeheer ervaring op doen met het werken met de Open Source servers en als dit dan allemaal stabiel en naar wens draait, kan men gaan kijken naar het migreren van de desktops. Op deze manier kan dan volledig op de desktops gefocused worden. Dit geeft een goed en vertrouwd gevoel bij de gebruikers van het netwerk. Zo zal een gefaseerde migratie altijd beter verlopen dan een migratie van het gehele netwerk in een keer.

4.10.3

Servers en clients tegelijk migreren

Als gekozen wordt voor de methode om servers en clients tegelijk te migreren zullen zowel gebruikers en beheerders goed op de hoogte dienen te zijn van Open Source applicaties en 46

netwerken. Het risico bij het migreren van een geheel netwerk is dat de hoeveelheid complicaties die op kunnen treden vaak meer is dan bij een migratie die stapsgewijs wordt uit gevoerd. Ook dienen gebruikers en beheerders beide moeten wennen aan het nieuwe netwerk en brengt een bepaald risico met zich mee.

4.10.4

Alleen de servers migreren

Hierbij wil men de gebruiker niet belasten met een keuze voor Open Source of Closed Source en wordt het serverpark gedeeltelijk of geheel over gezet op Open Source servers. Dit kan vanwege de transparantie die Linux heeft ten opzichte van Windows clients. Linux servers kunnen in de basis goed overweg met Windows clients. Gebruikers hoeven bij deze methode niet te wennen aan nieuwe software en hoeven daar ook geen training voor te krijgen. Dit scheelt in de kosten. Aan de serverkant kan men experimenteren met het gebruik van Open Source servers en applicaties. Hierdoor kan kennis en ervaring opgedaan worden met Open Source applicaties waardoor een eventuele toekomstige gefaseerde overgang naar een volledig Open Source netwerk soepel kan verlopen.

4.10.5

Alleen de clients migreren

Bij een migratiemethode waarbij alleen de clients worden gemigreerd naar FOSS zal men de Microsoft servers aan moeten gaan passen zodat deze overweg kunnen met de Linux clients. Alleen Microsoft server 2003 en hoger heeft de mogelijkheid om samen met Linux clients in een netwerk samen te werken.

4.11

Samenvatting

Hierin worden aan de hand van hierboven gevonden feiten/onderzoeksresultaten conclusies en aanbevelingen gedaan om gestelde doelen te bereiken. Deze conclusie zal getrokken worden vanuit het theoretische onderzoek. Van de 5 hierboven besproken methodes zijn er echter 3 relevant. Deze 3 methodes representeren een volledige netwerkmigratie van Closed Source naar Open Source. Om de relevantie van de criteria ten opzichte van de migratiemogelijkheden aan te geven maak ik gebruik van een plus (+) voor belangrijk en een min (--) voor minder belangrijk. De notatie zal tussen haakjes achter de waardering komen te staan. De criteria met een min zullen voor de helft in de score worden meegenomen. Voor de waardering zal ik gebruik maken van een cijfermatig systeem waarbij de waarden van 1 tot 5 lopen.

47

Hier staat een 1 voor zeer slecht en een 5 voor zeer goed. 1

zeer slecht

2

slecht

3

gemiddeld

4

goed

5

zeer goed

Tabel 6

Voor- en nadelen behandelde migratiemogelijkheden

Voor- en

Draagvlak

nadelen

Beleving

Beleving beheerders Kostenplaatje Kans van Score

gebruikers

slagen

(+)

(+)

(--)

(+)

(+)

3

3

4

2

3

2

5

4

4

2

4

3

3

2

2

2

3

2

Alleen servers

4

5

4

4

4

4

Alleen clients

3

2

3

3

3

2

Eerst client dan server Eerst server dan client Servers en clients tegelijk

4.12

Voorlopige voorkeur migratie

Uit de bovenstaande tabel komt naar voren dat een migratiemogelijkheid de voorkeur heeft, namelijk die van server eerst, daarna de clients. Er is wel een migratiemogelijkheid die hoger scoort, alleen deze valt niet binnen de scope. Binnen het R@sto zullen verschillende clients gebruikt worden, zowel Linux clients als Windows clients. Dit komt doordat er ieder half jaar een nieuwe groep stagiaires komt bij het R@sto komt te zitten. Zeker een groep zal aan de slag gaan met Linux, terwijl de rest op de desktops van het R@sto gaat werken of een eigen laptop mee neemt. Hiermee dient in de migratie wel rekening gehouden te worden. Doordat de clients niet homogeen zijn is een migratie van server naar client de beste optie. Hierdoor kunnen de servers op de verschillende clients ingesteld worden in plaats van andersom. Servers zijn immers flexibeler dan clients. Mijn aanbeveling aan het R@sto is dan ook om eerst de servers te migreren en gereed te maken voor het accepteren van verschillende clients en daarna de clients te migreren.

48

4.13

Situatieanalyse

Alvorens op basis van bovenstaande een aanbeveling te kunnen doen moeten we ons realiseren dat zich bij het R@sto een aantal situaties op de werkvloer voorkomen die specifiek voor het R@sto zijn. Zo zijn de meeste stagiaires, die bij het R@sto stage komen lopen, ICT studenten en weten dus al het een en ander van ICT. Dit kan voordelig zijn, maar ook nadelig in verband met illegale praktijken. Zij weten dan van wanten. Daarnaast wordt het grootste deel aan personeel ieder jaar vervangen door een nieuwe lichting stagiaires. Dit betekent dat ieder half jaar de pc's opnieuw geïnstalleerd dienen te worden om weer gereed te zijn voor een nieuwe lichting stagiaires. De clients binnen het netwerk die stabiel blijven zijn de 2 desktop pc's en 2 laptops van de coördinatoren van het R@sto. Een laatste opmerking over de hardware die gebruik wordt bij het R@sto, dit kan van belang zijn voor de keuzebepaling. Deze hardware wordt namelijk afgenomen van het ROC Leiden en is geen eigen hardware. Hierdoor worden er beperkingen vanuit het ROC Leiden opgelegd aan de samenstelling van de desktop pc's en ook wat voor software erop geïnstalleerd mag worden. In het kort zullen alle bovengenoemde situaties nog eens op een rijtje gezet worden: ●

grootste gedeelte van stagiaires zijn ICT studenten

●

alle stagiaires worden na een half jaar vervangen door een nieuwe lichting

●

ieder half jaar opnieuw installeren van alle pc's die door stagiaires in gebruik zijn

●

stabiele desktops zijn die van de 4 coördinatoren (2 laptops en 2 desktops)

●

alle hardware wordt afgenomen van het ROC Leiden (beperking software en samenstelling)

Nu er binnen deze situatieanalyse aan is gegeven wat specifieke situaties bij het R@sto zijn dient gekeken te worden of het mogelijk is om de eisen die aan het begin gesteld zijn uit te voeren. Deze eisen zijn terug te vinden in het inventarisatieverslag in bijlage 5. Als bovengenoemde voor het R@sto specifieke situaties in ogenschouw worden genomen is het zeker mogelijk om aan de vooraf gestelde eisen te voldoen.

4.14

Conclusie en aanbeveling

In hoofdstuk 3 werd al aangegeven dat de open source software mogelijk het meest geschikt was voor R@sto. Dit was gebaseerd op 3 criteria: gebruikersvriendelijkheid, beheersbaarheid en de kosten. In hoofdstuk 4 is dieper ingegaan op de verschillen tussen Open en Closed Source software. Hierbij zijn de voor-en nadelen van beide mogelijkheden door middel van 6 criteria onderzocht. Deze criteria zijn softwarelicenties, toegang tot de software, kosten, beveiliging, beheersbaarheid en vertrouwdheid/bekendheid. Enkel op de criteria vertrouwdheid/bekendheid scoorde de Closed Source software beter. Op de andere 5 criteria scoorde de Open Source software gelijk of ietsje beter. Hieruit blijkt dat er een lichte voorkeur voor Open Source software bestaat. Om het geheel volledig te maken is er tevens gekeken naar de opzet van het netwerk. Het is

49

namelijk mogelijk om combinaties van Open en Closed software binnen een netwerk te hebben. Hiervoor zijn verschillende mogelijkheden vergeleken, variërend van Open/Open source tot Closed/Closed source. Rekening houdend met het feit dat R@sto een organisatie is die met stagiaires werkt, er slechts 4 stabiele desktops zijn en R@sto, voor wat betreft zijn hardware, afhankelijk is van ROC Leiden, komt de voorkeur voor een gemengd netwerk van Linux servers met Linux/Windows clients als beste uit de bus. De belangrijkste argumenten om voor dit gemengde netwerk te kiezen, is dat deze niet alleen lage kosten met zich meebrengt, het is tevens gebruiksvriendelijk waardoor er geen extra opleiding nodig is voor het personeel. Op deze manier is de Linux server volledig transparant voor Windows clients waardoor de clients niet door hebben dat ze met een Linux server aan het communiceren zijn. Ze hebben dus de voordelen van een Windows server, gecombineerd met het kostenplaatje van een Linux server. Om er zeker van te zijn dat het kostenplaatje van de Open Source software lager is dan die van een Closed source software, is dit ook onderzocht middels de Total Cost of Ownership. Deze ondersteunt de stelling dat de Open Source software inderdaad goedkoper is. Dit is zeker voor het R@sto een belangrijk voordeel. Als voor deze vorm gekozen wordt dan zal er een migratie plaats moeten gaan vinden. Als gekeken wordt naar mogelijke migratietrajecten, dan blijkt dat er grote voordelen zitten in het eerst migreren van servers naar Open Source om vervolgens te beginnen aan het migreren van de clients. Het belangrijkste voordeel hierbij is dat de gebruiker nog gewoon op het oude vertrouwde systeem door kan werken zonder dat deze rigoureuze veranderingen aan het netwerk of de desktop ondervind. Bovendien kunnen de servers transparant worden gemigreerd naar een Open Source omgeving. Een gefaseerde migratie zal tenslotte altijd beter verlopen dan een migratie van het gehele netwerk in een keer. Samenvattend, uit het onderzoek komt naar voren dat R@sto het beste af is met een gecombineerde netwerkinfrastructuur in de vorm van een Linux server met Linux/Windows clients. Bij de migratie dienen eerst de servers en daarna de clients gemigreerd te worden voor een optimaal effect.

50

H5

Roadmap voor migratie/opzet van een netwerk

In hoofdstuk 4 is nader onderzocht welk systeem het beste past bij R@sto hierbij is naar voren gekomen dat en Open Source systeem, waarbij sprake is van Linux/Windows, voor R@sto de beste oplossing is. Hierbij zal een migratie noodzakelijk zijn. Om een migratie vlot te laten verlopen is het altijd zinvol om van te voren een goede voorbereiding op papier te zetten. Hierin komen onderdelen als inventarisatie, vereisten, testen en invoeren aan de orde. Dit hoofdstuk zal een migratieplan uitwerken wat tevens gebruikt wordt in het boek “Windows Linux Migration Toolkit” van David Allen. In dit migratieplan wordt reeds rekening gehouden met een migratie van een Closed Source netwerk naar een Open Source netwerk. De gegevens die gebruikt zijn in tabellen en diagrammen zijn fictief en dienen ter illustratie om de werking van de roadmap te verduidelijken. Mocht er op basis van de aanbeveling een beslissing worden genomen tot migratie dan kunnen de tabellen en diagrammen ingevuld worden naar de feitelijke situatie. Op dit moment valt dit echter buiten de scope van dit hoofdstuk.

5.1

Inventarisatie van de huidige infrastructuur

Een migratie traject lijkt een beetje op een tochtje in een auto. Ze hebben allebei een startpunt, een reis en een eindpunt. Bij het plannen van een migratie is de eerste stap: iets te weten te komen over het startpunt. Dit wordt bereikt door het doen van een inventarisatie van de huidige IT infrastructuur van de organisatie. Een inventarisatie dient minimaal alle data te bevatten die gerelateerd is aan de gebieden waarop de migratie zich gaat richten. Omdat een inventarisatie van de infrastructuur meestal een eenmalige actie is het verstandig om op dit moment zo veel mogelijk informatie te verzamelen over het systeem en netwerkinfrastructuur.

5.1.1

Inventarisatie van servers

De eerste stap in de inventarisatie bestaat uit de servers. Van deze servers dient minimaal de naam, het IP-adres, netwerk service applicaties, besturing systeem revisie en hardware details te worden verzameld. Zorg er voor dat de informatie die in dit vroege stadium over de infrastructuur verzameld wordt correct is, omdat verkeerde informatie in de loop van de migratie ook weer foute beslissingen en informatie tot gevolg kan hebben. Tabel 7

Server inventarisatie

Naam server OS

Software

Geheugen Processor

IP adres

Server 1

Windows NT File,print,authenticatie 128 MB

PIII 933 Mhz 10.0.0.2

Server 2

Windows NT Exchange 5.5

128 MB

PIII 933 Mhz 10.0.0.3

Server 3

Windows NT Backup

128 MB

PIII 933 Mhz 10.0.0.4

51

5.1.2

Inventarisatie van de desktops

Naast een inventarisatie van de servers dient er ook een inventarisatie van de desktop plaats te vinden. Dit is vooral handig als er naast het migreren van de servers ook een migratie op de desktops plaats gaat vinden. Het inventariseren van de desktop helpt in vele gevallen ook het identificeren van de netwerk service applicaties die op de server gaan draaien. Voor een desktop inventarisatie dient men minimaal de naam van de pc, het besturingssysteem, de software, CPU en ip-adres te inventariseren. Tabel 8

Desktop inventarisatie

Desktop

OS

Software

Geheugen Processor IP adres Aantal

Dell Dimension 2200 Windows XP Office 2000 512 MB

1 Ghz

DHCP

10

Dell Optiplex GX1

Windows 98 Office 97

600 Mhz

DHCP

40

Dell Inspiron 1150

Windows XP Office 2000 1024 MB

2.6 Ghz

DHCP

10

5.1.3

256 MB

Het creëren van een infrastructuur diagram

Het creëren van een infrastructuur- en netwerkdiagram geeft een visuele presentatie van het startpunt van de migratie. In dit diagram dienen minimaal de volgende onderdelen van het te ontwikkelen systeem grafisch te worden weergegeven: ●

verschillende soorten desktops/laptops, eventueel met aantallen

●

verschillende soorten servers, eventueel met aantallen

●

centrale dataopslag

●

eventueel draadloze AP's

●

verschillende netwerkaparatuur

●

onderlinge samenhang van bovenstaande onderdelen

●

hoe wordt toegang verkregen naar andere netwerken (bv. Internet)

Op de volgende pagina zal een voorbeeld gegeven worden van een netwerkdiagram.

52

Figuur 3

Voorbeeld infrastructuur- en netwerkdiagram

5.1.4

Extra informatie voor de inventarisatie

Om een volledige inventarisatie te hebben dienen de volgende onderdelen in de documentatie aanwezig te zijn: ●

hardware labels en/of serie nummers

●

hardware producenten en model nummers

●

harddisk capaciteiten en mogelijkheden

●

configuratie, producent en model van de netwerk onderdelen

Hierin wordt een inventarisering van de wensen van het R@sto gedaan met betrekking tot het in te voeren Windows netwerk. 53

5.2

Vereisten bepalen voor het netwerk

Met de inventarisatie van de huidige netwerkinfrastructuur achter de rug is het tijd om de vereisten te gaan bepalen die men in de nieuwe structuur graag wil gaan implementeren. Hierbij wordt er naar gestreefd om dezelfde functionaliteit te verkrijgen als dat men in de oude Windows structuur had. Om zo goed mogelijk met de migratie van start te gaan, is het zaak om op een zo vroeg mogelijk tijdstip zoveel mogelijk vereisten te onderkennen als mogelijk. De vereisten worden voornamelijk gebaseerd op de wensen van de business. Het kan verleidelijk zijn om meer vereisten te definiëren dan nodig zijn, alleen het nadeel daarvan is dat daar dan extra kosten aan verbonden zijn voor ontwikkeling en implementatie. Een handige methode is om alle vereisten een waarde te geven door middel van de MoSCoW methode. Door het gebruik van deze methode worden aan de vereisten waarden toegekend als Must Haves, Should Haves, Could Haves en Would Haves. In de prioritering van vereisten wordt uiteraard ook een kostenafweging meegenomen, waarin de tijd, training, manuren en ondersteuning belangrijke criteria zijn. Als alle vereisten bepaald zijn en er prioriteiten toegekend zijn kan er een functioneel ontwerp voor opgesteld worden. Dit document beschrijft de functionaliteit die een infrastructuur dient te hebben om acceptabel te zijn voor de organisatie. Organisatorisch is het document zo opgebouwd dat de vereisten zijn ingedeeld in netwerk service groepen zodat er in de volgorde en groep voor groep gemigreerd kan worden. Dit document wordt later gebruikt om het testplan mee op te stellen. Tabel 9

Functioneel Ontwerp

Services

Vereisten

Basis netwerk services Adres toewijzing

Gebruik dhcpd voor DHCP

Name resolution

Gebruik bind voor DNS

Tijd synchronisatie

Gebruik NTP (Network Time Protocol)

Directory services Directory services

Installeren en configureren van OpenLDAP

Directory services migratie

Migreren van informatie van Exchange en NT SAM naar OpenLDAP

Authenticatie services Authenticatie services

Installeren van Samba authenticatieservice

Authenticatie services migratie

Opnieuw instellen van gebruikerswachtwoorden

File services File services

Installeren van Samba file services.

File services migratie

Kopiëren van alle data naar de nieuwe server en aanmaken van nieuwe share

Print services Print services

Installeren van configureren van CUPS 54

Print services migratie

Migreren van printer queue informatie vanuit Windows naar CUPS

Messaging services MTA (Mail Transfer Agent) services

Installeren en configureren van Courier-MTA

Mailopslag services

Installeren en configureren van Courier-IMAP

Webmail services

Installeren van Squirrelmail

Anti-spam

Installeren van Spamassin

Anti-virus

Installeren van ClamAV

Messaging services migratie

Migreren van mailbox informatie

Groupware en Calendaring services Calendaring services

Installeren configureren van eGroupWare

Groupware services

Installeren aan de hand van vereisten

Calendaring services migratie

Migreren van gebruikers kalenders en taken

Groupware services migratie

Migreren wat van toepassing is

Web services Web services

Apache webserver

Web services migratie

Migreren van data en websites

5.3

Identificeren van beperkingen

Naast de organisatorische en technische vereisten kunnen er ook nog wettelijke, kosten, tijd, procedurele en andere beperkingen zijn. Deze beperkingen kunnen gevolgen hebben voor de volgorde van het invoeren van netwerkvereisten of misschien worden om deze redenen bepaalde vereisten wel geschrapt. Om hier een goed overzicht op te krijgen is het nodig om deze beperkingen met gevolgen en oplossingen in een document te zetten. Tabel 10

Migratie beperkingen en aanpassingen

Beperking

Voorbeeld

Oplossing

Kosten beperkingen

Er is niet genoeg geld voor het

Er zal gekeken moeten worden

aanschaffen van benodigde

of oude hardware gebruikt kan

hardware

worden.

Tijd beperkingen

Als gevolg van een belangrijk project De migratie zal een maand later bij het management kan de migratie

plaats vinden.

pas over een maand plaats vinden. Functionele beperkingen Email van het management mag niet Er zal een aparte server voor op dezelfde server opgeslagen

aangeschaft dienen te worden.

worden als die van medewerkers. 55

Procedurele

Vanwege de verloning op het einde

Werkzaamheden of reboots

beperkingen

van de maand mag er niks aan de

zullen op het begin van de

servers gebeuren.

maand plaats moeten vinden.

5.4

Ontwerpen van de infrastructuur

Na het vaststellen van de vereisten voor de netwerkinfrastructuur kan een high-level ontwerp gemaakt worden. In dit ontwerp wordt de strategie ontwikkeld voor een post-migratie infrastructuur waarin de netwerk en server strategie bepaald gaat worden. In dit ontwerp wordt besloten welke systemen er blijven, vervangen, ge-update of toegevoegd gaan worden. Er wordt echter wel rekening gehouden met de plaatsing van servers op eventuele locaties buiten het hoofdkantoor. Deze locaties dienen ten minste voorzien te zijn van een server met file, authenticatie en email services.

5.5

Het testen van de nieuwe infrastructuur

Het testen van de nieuwe infrastructuur is essentieel voor het goed en zelfs beter functioneren dan de oude infrastructuur. Uiteraard is het doel van een migratie naar een nieuwe infrastructuur dat de vooraf gestelde doelen gehaald gaan worden of zelfs overtroffen worden. In een testplan staan procedures vermeld op wat voor manier ieder onderdeel van de nieuwe infrastructuur getest dient te worden als het ingevoerd wordt. De nieuwe infrastructuur zal alleen geaccepteerd worden als alle tests naar wens zijn doorstaan. Voor het goed kunnen testen van alle onderdelen zal een testplan opgezet dienen te worden. In een testplan dienen alle onderdelen uit het document met vereisten genoemd te worden samen met de manier waarop deze getest gaan worden. De nauwkeurigheid van het plan kan per onderdeel verschillen en hangt af van het onderdeel dat getest wordt en de eisen die eraan gesteld worden. Voor het uitvoeren van een testplan is het aan te raden om gebruik te maken van een testlab dat geen onderdeel is van het productienetwerk. In een testlab is het mogelijk om verschillende configuraties van software en hardware uit te testen. Deze dienen ook eerst in het testlab uit getest te worden voordat deze in het productienetwerk ingevoerd worden. Tabel 11

Test plan

Services

Test Procedure

Basis netwerk services Adres toewijzing

Gebruik ping om de connectiviteit te testen

Name resolution

Kijk of iedere host op naam te pingen is.

Tijd synchronisatie

Check op iedere computer of de tijd wel klopt. 56

Directory services Directory services

Gebruik gq om te checken of LDAP queries operationeel zijn.

Directory services migratie

Gebruik gq om te verifieren dat alle entries van Exchange en NT SAM goed naar OpenLDAP gemigreerd zijn.

Authenticatie services Authenticatie services

Verifieer dat gebruikers in kunnen loggen op hun desktops.

Authenticatie services migratie

Verifieer dat alle gebruikers hun wachtwoord verandert hebben.

File services File services

Gebruik smbmount om de connectiviteit van de file services te checken.

File services migratie

Verifieer dat alle data en files juist zijn gekopieerd.

Print services Print services

Print een testpagina uit alle netwerkprinters.

Print services migratie

Verifieer of alle computers kunnen printen.

Messaging services MTA (Mail Transfer Agent) services

Verzend een testmail naar een adres op het internet en naar een intern adres.

Mailopslag services

Gebruik Outlook en Evolution om mailbox toegang te testen.

Webmail services

Verifieer van buiten het netwerk om het mogelijk is om toegang te krijgen tot webmail.

Anti-spam

Stuur spam mail naar de mailserver.

Anti-virus

Stuur een mail met een testvirus naar de mailserver.

Messaging services migratie

Verifieer dat mailboxen van gebruikers juist zijn gemigreerd.

Groupware en Calendaring services Calendaring services

Creëer een testafspraak en vergadering.

Groupware services

Test de geinstalleerde onderdelen met tests.

Calendaring services

Verifieer dat afspraken en vergaderingen juist zijn aangekomen en opgeslagen.

Groupware services

Verifieer of geïnstalleerde onderdelen juist functioneren.

Web services Web services

Verifieer of de webserver toegankelijk is.

Web services migratie

Verifieer of alle gemigreerde data en websites beschikbaar zijn. 57

5.6

Het uitrollen van de nieuwe infrastructuur

Na het succesvol afronden van alle tests in de testfase kan begonnen worden met het invoeren van de nieuwe infrastructuur. Hiervoor wordt een bepaalde groep gebruikers aangesteld, de zogenaamde pilot groep. Deze groep dient een vertegenwoordiging te zijn van alle soorten gebruikers die in het bedrijf aanwezig zijn. Zij zullen aan de hand van een test- en evaluatieformulier gaan bepalen of de nieuwe infrastructuur naar behoren functioneert. Het voordeel van een zodanig samengestelde groep is dat er vanuit allerlei perspectieven naar de nieuwe infrastructuur gekeken gaat worden. Aan het einde van de pilot wordt iedere deelnemer afzonderlijk geïnterviewd over zijn mening en bevindingen die opgevallen zijn gedurende de pilot.

5.7

Het migreren naar de nieuwe infrastructuur

Nadat de pilot groep is geëvalueerd en men zeker is van het juist en naar wens functioneren van de nieuwe omgeving kan men beginnen aan het migreren van gebruikers en systemen naar de nieuwe omgeving. De meest voor de hand liggende gebruikers om als eerste te migreren zijn diegene die in de pilot groep gezeten hebben. Andere factoren die een rol kunnen spelen bij het migreren van gebruikers en/of systemen zijn: ●

gebruikers of systemen die afhankelijk zijn van de nieuwe capaciteiten van het netwerk (capability-driven)

●

gebruikers of systemen die bij een bepaalde afdeling of unit horen (business-group-driven), bijvoorbeeld een financiële afdeling die voorrang krijgt om zo spoedig mogelijk met werkzaamheden door te kunnen

●

gebruikers of systemen die op een bepaalde locatie zitten (geography-driven), een reden van geography-driven migratie kan zijn dat er een tijdsverschill bestaat met de locatie waar vandaan de migratie gecoördineerd wordt

Er is een aantal manieren om een migratie in een tijdsschema te zetten. De moeilijkheidsgraad van het tijdsschema hangt af van de hoeveelheid gebruikers en complexiteit van de hoeveelheid gebruikers en de complexiteit van de organisatie. Om de migratie zo goed mogelijk te laten verlopen, is het aan te raden om voor iedere groep die gemigreerd dient te worden een contactpersoon aan te stellen. De taak van de contactpersoon is om de communicatie op gang te houden tussen de IT groep en de groep die vertegenwoordigd wordt. Er dient duidelijk vast gelegd te worden wat de verantwoordelijkheden en taken van iedere groep zijn. Uiteraard moeten deze afspraken wel wederzijds ondersteund en overeengekomen zijn. Dit voorkomt misverstanden en verbetert de duidelijkheid binnen het migratietraject. Als de migratie van start gaat dient men

58

rekening te houden met eventuele gevolgen van de migratie voor gebruikers. Soms dienen gebruikers hun pc te rebooten om een bepaalde verandering van kracht te laten zijn (authenticated services), soms ook zal de gebruiker niets merken van een bepaalde service (file services). Echter dient de gebruiker altijd op de hoogte gebracht te worden van de migratiestappen die plaats vinden. Dit is vaak een indicatie voor de gebruiker dat er goed is na gedacht over de migratie, maar ook dat de gebruiker weet dat er dingen veranderen in het netwerk, zodat hij misschien dingen tegen kan komen die niet herkend worden. Bij het migreren van grote groepen gebruikers, bijvoorbeeld bij een file server met inlogscripts en printermappings, is het zaak om alles zo veel mogelijk te automatiseren. Dit gaat sneller en verkleint de kans op menselijke fouten. Na de migratie is het zaak om training en opleidingen aan te gaan bieden aan de gemigreerde gebruikers. Hierdoor hebben de gebruikers het gevoel dat ze gesteund worden in het gebruik van hun nieuwe applicaties en dat ze voldoende aanspreekpunten hebben mochten ze tegen problemen aan lopen. Volg zo veel mogelijk richtlijnen voor change management, zodat alles goed gedocumenteerd kan worden. Zorg voor regelmatig overleg tussen de technische staf en degene die verantwoordelijk zijn voor de uiteindelijke beslissingen. Hierdoor worden alle beslissingen wel overwogen en begrepen voordat ze door gevoerd worden. In hoofdstuk 5 is in zes stappen een roadmap besproken. Deze roadmap zorgt voor een vlotte migratie van een oude netwerkinfrastructuur naar een nieuwe Open Source infrastructuur. Om deze stappen nog eens kort en overzichtelijk weer te geven bevind zich op de volgende pagina een flowchart. Dit flowchart geeft aan welke stappen ondernomen dienen te worden. Daarnaast wordt aangegeven naar welke stap men terug dient te keren als aan een bepaalde stap niet voldaan is.

59

Figuur 4

Flowchart van roadmap migratieplan

60

H6

Conclusies en aanbevelingen

In hoofdstuk 5 is besproken hoe een migratie traject naar een Open Source netwerk succesvol uitgevoerd kan worden. In hoofdstuk 6 zal een uiteindelijke conclusie en aanbeveling worden gedaan. Ook zal gekeken worden of er antwoorden zijn gevonden op alle deelvragen. Voor het project waarin het R@sto MKB servers uit wil gaan leveren aan MKB bedrijven dient bekend te zijn wat deze bedrijven van zo'n server eisen. Hierop is antwoord gegeven in paragraaf 3.3. Dit zijn tevens dezelfde eisen die een bedrijf als het R@sto van een netwerk verwacht. Uit het literatuuronderzoek is naar voren gekomen dat Open Source voldoet aan de eisen die door het R@sto gesteld zijn aan een netwerkinfrastructuur. Zo sluit de Open Source filosofie beter aan bij het bedrijfstype dat het R@sto is. In deze bedrijfsfilosofie zijn voornamelijk de kosten en flexibiliteit van de software van belang. Doordat het R@sto veel projecten uitvoert voor derden en jaarlijks een wisseling heeft van de volledige groep stagiaires is het nuttig om flexibel te zijn. Deze eigenschappen zijn van belang bij projecten die het R@sto uitvoert voor derden en ook voor de half jaarlijkse wisseling van stagiaires. Om deze infrastructuur te implementeren wordt in hoofdstuk 4 gekeken naar de implementatie mogelijkheden van een Open Source netwerkinfrastructuur. De opbouw van het netwerk zal dan gaan bestaan uit Linux servers met Linux en Windows clients. De Linux clients zijn de vaste desktop pc's die bij het R@sto aanwezig zijn. Daarnaast worden door stagiaires of medewerkers laptops gebruikt die draaien op Windows. Hier dienen de Linux servers ook op ingesteld te zijn. Als laatste onderzoeksvraag wordt gevraagd waarom FOSS nog niet breder geaccepteerd is binnen het MKB. Uit mijn onderzoek is gebleken dat dit ver uiteenlopende oorzaken kan hebben. Deze oorzaken zijn eigenlijk te vinden door het gehele onderzoek heen. Enkele voorbeelden zijn dat bepaalde bedrijven, vooral de wat grotere, zoveel korting krijgen van Microsoft dat het voor hen voordeliger is om bij Microsoft te blijven. Weer andere kunnen door de agressieve marketingstrategie bang worden gemaakt en niet het risico durven te nemen om over te stappen naar een Open Source omgeving. Ook kunnen sommige bedrijven niet over, omdat deze zo verweven zitten in een afhankelijke positie ten opzichte van Closed Source software dat zij niet hier uit kunnen stappen. Als aanbeveling wil ik R@sto meegeven dat ze het beste kunnen kiezen voor de Open Source software zoals dat in hoofdstuk 4 naar voren is gekomen. In hoofdstuk 5 heb ik een roadmap geschreven die door toekomstige stagiaires gebruikt kan worden om de nieuwe infrastructuur te implementeren. Op lange termijn zal dit leiden tot onafhankelijkheid van ROC leiden, lage kosten en goed gebruikersgemak. Bovendien kan deze server de toekomstige projecten en ambities van het R@sto verwezenlijken

61

H7

Evaluatie procesgang van de gehele stage

De maagecombineerde Open Source softwarend augustus was voor mij de maand om op zoek te gaan naar een afstudeerbedrijf. Om een goed een leuk bedrijf te vinden ben ik gaan speuren op het internet en ben daar terecht gekomen op de website van het R@sto. De filosofie van het R@sto stond mij erg aan, want ik had nog nooit van het bestaan gehoord van een bedrijf dat door middel van stagiaires projecten uitvoert. Ik vond dit een mooi initiatief en na een aantal interessante stukjes van ex-stagiaires te hebben gelezen heb ik gebeld om een afspraak te maken bij het R@sto. Zo is het gekomen dat ik van september 2006 tot januari 2007 mijn afstudeerstage heb doorlopen bij het R@sto in Leiden. De stageopdracht die ik bij het R@sto uit ging voeren was het invoeren van een nieuw netwerk bij het R@sto en daarnaast een literatuuronderzoek naar de mogelijkheid tot invoering van Open Source software binnen het R@sto en haar projecten. Mijn stageperiode heb ik met plezier doorlopen waarbij ik bij het R@sto mijn opdracht heb uit kunnen voeren en een heleboel geleerd heb. Mijn projectvoorstel en plan van aanpak zijn in eerste instantie meer gefocused op het implementeren van een Microsoft netwerk dan het doen van literatuuronderzoek naar FOSS. De oorzaak hiervan is dat het R@sto nog geen ervaring en kennis van FOSS had en daarom een Microsoft netwerk wilde implementeren. Echter dit netwerk was al vrij snel gerealiseerd. Daarna werd door het R@sto het idee geopperd om een project op te starten om FOSS servers uit te gaan leveren aan het MKB. Een van de leuke dingen die ik gedaan heb was het ondersteuning geven aan 5 MBO stagiaires die zich een boek over Ubuntu Linux eigen moesten maken. Zij hadden totaal nog geen kennis van Linux en ik vond het leuk om die kennis op hun over te brengen. Voor mijn project heb ik ervaring gekregen in het geven van leiding en coördinatie over 2 MBO stagiaires die mij toe waren gewezen om mij te ondersteunen in uitvoerende werkzaamheden. Daarnaast heb ik geleerd om in een echte situatie een geheel project te doorlopen van inventarisatie, voorbereiding en onderzoek naar de uitvoerende fase. Een leerpunt voor mijzelf is dan ook geweest om beter controle te houden over het opgestelde plan van het project en niet af te wijken naar andere projecten/opdrachten waardoor de eigen opdracht in gevaar komt. Een project bestond uit het Computer Compleet project wat door een stagiaire in de vorige periode was opgestart, maar verre van af was achtergelaten. Hier heb ik samen met een MBO stagiaire aan gewerkt om dit af te krijgen. Hier is echter meer tijd in gaan zitten dan gedacht. Er zijn echter ook een aantal punten binnen het project die volgens de van te voren opgestelde planning uitgevoerd zijn. Zo was er zonder mijn medeweten reeds een stagiaire aangewezen voor het implementeren van de ITIL modules. Ook is het niet mogelijk geweest om een Ghost server neer te zetten. Dit had als oorzaak dat het netwerk bij het R@sto niet geschikt was voor het verwerken van alle data die Ghost gebruikt zonder dat de performance van het netwerk hier onder leed. Daarnaast zou ik op het einde van het literatuuronderzoek en dus ook van mijn stageperiode 62

een test/pilot netwerk opzetten met een Open Source server en 2 clients. Vanwege een verkeerde planning en het toebedelen van andere taken aan mijn MBO stagiaires heb ik dit niet tot een volledig einde kunnen brengen.

63

Gebruikte bronnen Websites ●

http://www.ososs.nl bezocht op 1 juni 2007

●

http://www.livre.nl bezocht op 1 juni 2007

●

http://nl.wikipedia.org bezocht op 1 juni 2007

●

http://www.relevantive.de/Linux.html bezocht op 1 juni 2007

●

http://www.bloor-research.com/research/research_report/468/linux__enterprise_ready_.html bezocht op 1 juni 2007

Onderzoeken ●

Mr.drs. Bart S.J. Knubben, Investeren in Openheid, januari 2004

●

EMA (Enterprise Management Associates), Get the Truth on Linux Management, februari 2006

●

M. Theunissen, Vrije Universiteit Amsterdam, Factoren die bepalend zijn voor de keuze van Open Source, augustus 2004

Boeken ●

H. Sleurink, Media Update Vakpublicaties, Open Source jaarboek 2006/2007

●

J. Baten, Addison Wesley, Open Source binnen bedrijf en overheid, 2003

●

D. Allen, Windows Linux Migration Toolkit, 2004

64

Bijlagen

Bijlage 1

Lijst met afkortingen

AP

Access Point

BRR

Business Readiness Rating

CAL

Client Access License

CMS

Content Management System

CRM

Customer Relations Management

CUPS

Common UNIX Printing System

DDS

De Digitale Sleutel

DHCP

Dynamic Host Configuration Protocol

DNS

Domain Name Service

EULA

End User License Agreements

FOSS

Free Open Source Software

FUD

Fear, Uncurtenty and Doubt

HBO

Hoger Beroeps Onderwijs

HTML

Hyper Text Markup Language

ICTaL

ICT Academie Leiden

ICT

Informatie en Communicatie Technologie

IP

Internet Protocol

ISA

Internet Security and Acceleration

ITIL

Information Technology Infrastructure Library

IT

Informatie Technologie

MBO

Middelbaar Beroeps Onderwijs

MKB

Midden en Kleinbedrijf

MTA

Mail Transfer Agent

NTP

Network Time Protocol

ODF

Open Document Format

PDF

Postscript Document Format

PHP

PHP Hypertext Preprocessor

ROC

Reginaal Opleidingscentrum

TCO

Total Cost of Ownership

XML

eXtensible Markup Language

65

Bijlage 2

Tabellenlijst

Tabel 1

Tijdspad literatuuronderzoek

22

Tabel 2

Softwarepakketten voor netwerkservices

27

Tabel 3

Voor- en nadelen van gekozen software

29

Tabel 4

Voor- en nadelen van open en Closed Source software

38

Tabel 5

Voor- en nadelen behandelde netwerkstructuren

41

Tabel 6

Voor- en nadelen behandelde migratiemogelijkheden

48

Tabel 7

Server inventarisatie

51

Tabel 8

Desktop inventarisatie

52

Tabel 9

Functioneel Ontwerp

54

Tabel 10

Migratie beperkingen en aanpassingen

55

Tabel 11

Test plan

56

66

Bijlage 3 1.

Plan van Aanpak

Opdrachtformulering en producten

De opdrachtformulering geeft de afbakening van de opdracht aan, hierin wordt aangegeven wat het einddoel van het project is. Daarnaast komen de eindproducten en de geleverde diensten aan bod. 1.1

Opdrachtformulering

Ontwikkel een Active Directory netwerk met domain controller, mail- en ghost server. Zorg tevens voor juiste en volledige documentatie door middel van CRM en ITIL. 1.2

Op te leveren producten en diensten

Het resultaat van het project zal bestaan uit een Active Directory netwerk. Hierin bevinden zich twee Windows 2003 server installaties. De eerste zal dienst doen als een Domain Controller en heeft de functionaliteit van DHCP, DNS, File server en Ghost server. De tweede server zal gaan dienen als Exchange- en ISA server. Naast deze twee servers zal er ook een documentatie poel afgeleverd worden met daarin handleidingen, werkinstructies en hard- en software overzichten. Dit is van belang voor het latere onderhoud en eventuele herstelwerkzaamheden. Als laatste wordt ook een ITIL incident en configuratie implementatie afgeleverd. Hierdoor blijft het overzicht over de hardware actueel en kan er door middel van het registeren van incidenten gekeken worden naar de stabiliteit van de infrastructuur. 2.

Verantwoordelijkheden en projectorganisatie

Binnen een project heeft iedereen een bepaalde taak of verantwoordelijkheden, deze dienen vast gelegd te worden in het plan van aanpak om verwarring achteraf te voorkomen. 2.1

Verantwoordelijkheden

De verantwoordelijkheden voor het project worden gedragen door een viertal mensen, namelijk: 1. Dhr. Hordijk 2. Dhr. Boot 3. Dhr. Hoogkamer 4. Dhr. Lempke De begeleiding zal worden verzorgd door de manager van R@sto, Jan van Hordijk. Hij zal het beleidsmatige gedeelte van het project ondersteunen. Daarnaast krijg ik voor het vakinhoudelijke gedeelte begeleiding van een technische begeleider die over een ruime werkervaring beschikt in het opzetten van netwerken onder Windows. Verder zal ik het project zelfstandig uitvoeren met eventueel nog uitvoerende ondersteuning van Dhr. Lempke. Hij is een stagiair van het MBO. 2.2

Projectorganisatie

In de eerste plaats zal het Plan van Aanpak opgesteld worden en ter inzage getoond worden aan

67

technisch begeleider Dhr. Boot en stagebegeleider Dhr. Hordijk. Mochten er verbeterpunten zijn voor het Plan van Aanpak dan wordt hier een overleg gepland waarin de juiste aanvullingen worden besproken. Vervolgens zullen deze in het Plan van Aanpak aanpast worden. 2.3

Relaties met andere projecten

Binnen het project Netwerk bestaat een relatie met het project CRM van Patrick Kester. Bij het project wordt gebruik gemaakt van het open source programma SugarCRM. Hierin gaat de documentatie en eventuele gegevens van de configuratie- en incidentmodules van ITIL opgenomen worden. 2.4

Kwaliteitsaspecten

Op het einde van het project dienen alle opgeleverde producten naar de wensen van de opdrachtgever, maar binnen de grenzen van de projectformulering, te functioneren. De bijgeleverde documentatie dient voldoende getest te zijn en begrijpelijk geformuleerd. 3.

Aanpak

Hierin worden de subproducten van het project door middel van een stappenplan uiteen gezet. 3.1 Stap 1

Stappenplan Oriëntatie en inventarisatie (eerste week van september) In deze stap zal een interview plaats vinden met de huidige systeembeheerder om uit te vinden hoe de huidige netwerkstructuur in elkaar zit en wat de wensen zijn voor de nieuwe structuur. Product :

Stap 2

Opstellen van plan van aanpak (tweede week van september) Product :

Stap 3

Verslag met bevindingen en antwoorden op gestelde vragen.

Plan van Aanpak

Implementatie (vanaf maandag 18 september tot eind oktober) ●

Installatie van Server 2003 op server 1 (1 week)

●

Installatie van DHCP op server 1 (1 week)

●

Installatie van DNS op server 1 (1 week)

●

Server 1 configureren als file server (1 week)

●

Installatie en configuratie van Ghost op server 1 (1 week)

●

Installatie en configuratie van Exchange op server 2 (1 week)

●

Installatie en configuratie van ISA op server 2 (1 week) 68

Product :

Een 2 tal servers die verschillende functionaliteiten bieden binnen het nieuwe netwerk.

Stap 4

Implementatie van ITIL modules incident- en configuratiemanagement (november) In deze fase vindt een inventarisering plaats van alle hard- en software die aanwezig is bij het R@sto. Hierna worden deze gegevens verwerkt in een ITIL systeem waarin wijzigingen in de ICT-infrastructuur wordt geregistreerd en bijgehouden. Ook voorkomende problemen worden geregistreerd en mogelijk worden hier rapporten van gemaakt. Product :

Stap 5

Implementatie van incident- en configuratiemanagement.

Verwerken en afronden van documentatie in CRM systeem. (december) Deze stap zal documentatie opleveren zoals handleidingen, werkinstructies en documentatie in verband met de registratie van hard- en software in de ITIL implementatie. Product :

Stap 6

Een pakket aan documentatie geordend in een CRM systeem.

Evaluatie en afronding van het project ( januari) Voor de evaluatie en afronding van het project wordt er besproken en gekeken of van te voren gestelde doelen en eisen zijn bereikt. En als dit niet het geval is geweest wat dan de oorzaak is geweest voor een eventuele alternatieve koers die gevolgd is. Product :

Het eindproduct zal een evaluatieverslag zijn van het project. En tevens zal hier de oplevering van het netwerk plaats vinden.

3.2

Server indeling

In de nieuwe netwerkstructuur zullen 2 servers komen te staan die beide uitgerust zullen worden als multifunctionele servers. Beide servers zullen dus meerdere functionaliteiten krijgen. De server indeling op basis van functionaliteiten zal als volgt zijn: Server 1 ●

Domain Controller 69

●

DNS (Domain Name System)

●

DHCP (Dynamic Host Configuration Protocol)

●

File Server

●

Ghost

Server 2 ●

Exchange server

●

ISA server (Internet Security and Acceleration)

Eventuele extra onderdelen Mocht de tijd het toelaten, dan is het mogelijk om de volgende onderdelen extra te implementeren : ●

Windows Server Update Service server

●

ISA Server

4

Eindresultaat en planning

4.1

Eindresultaat

Een onafhankelijk netwerk dat alleen voor R@sto toegankelijk is. Aan het einde van de stage zal er een Active Directory netwerk met domain controller, mail- en ghostserver beschikbaar zijn voor gebruik. Het netwerk zal bestaan uit dertig computers. Daarnaast zal er beperkte ITIL structuur geïmplementeerd zijn en zal er voldoende documentatie aanwezig zijn om het onderhoud van het netwerk af te handelen. 4.2

Planning

Stap 1

Oriëntatie en inventarisatie

Stap 2

Opstellen van plan van aanpak

Stap 3

Planning

Stap 4

Inlezen en voorbereiden op implementatie

Stap 5

Implementatie

Stap 6

●

Installatie van Server 2003 op server 1

●

Installatie van DHCP op server 1

●

Installatie van DNS op server 1

●

Server 1 configureren als file server

●

Installatie en configuratie van Ghost op server 1

●

Installatie en configuratie van Exchange op server 2

●

Installatie en configuratie van ISA op server 2

Implementatie van ITIL modules incident- en configuratiemanagement 70

Stap 7

Verwerken en afronden van documentatie in CRM systeem.

Stap 8

Evaluatie en afronding van het project

De afstudeerstage heeft een tijdsduur van vijf maanden en is fulltime. De voorlopige planning is dat ik de eerste maand besteed aan het verdiepen in de verschillende netwerkomgevingen die bestaan. Daarnaast richt ik mij in de eerste maand op de door het R@sto gestelde eisen voor de gebruikersvriendelijkheid en de benodigde hard- en software binnen het netwerk. Tevens zal ik deze tijd gebruiken om het bedrijf beter te leren kennen. De maanden erna zal ik het netwerksysteem ontwerpen en implementeren. Waarna hiervan een evaluatie en eindverslag van opgesteld wordt. 4.3

Nevenactiviteiten

Daarnaast zal er tijd ingeruimd worden om deel te nemen aan andere aspecten van het bedrijf, zoals : ●

Onderzoek en begeleiding van Linux

●

Deelnemen aan vergaderingen

●

Andere nader in te vullen activiteiten

Bijlagen In dit hoofdstuk wordt verwezen naar de relevante standaards en projectprocedures. In het voorkomend geval zal verwezen worden naar reeds bestaande c.q. gebruikelijke bedrijfsstandaards. Voorwaarde is wel dat deze gedocumenteerd zijn. In de bijlagen worden ook Begrippen en definities opgenomen om begripsverwarring te voorkomen. De begrippenlijst hoeft niet uitputtend te zijn, alleen de gehanteerde begrippen in het Plan van Aanpak komen hiervoor in aanmerking.

71

Bijlage 4 1.

Projectvoorstel

Afstudeeronderwerp

Het ontwerpen en implementeren van een nieuwe netwerkinfrastructuur bij R@sto. 2.

Een beschrijving van het bedrijf

Het R@sto is een IT-bedrijf dat speciaal is opgericht om stageplaatsen te verzorgen voor MBO- en HBO studenten. Het vormt een onderdeel van de ROC Leiden. Op dit ogenblik verzorgen ze het systeembeheer van bijna alle basisscholen in Leiden en van een aantal scholen van voortgezet onderwijs. Ook worden er websites ontwikkeld. Daarnaast beheren ze twee internetcafe's en doen ze ICT projecten in achterstandswijken. Binnen het bedrijf zijn twee systeembeheerders werkzaam. Zij zorgen ervoor dat er voldoende begeleiding is voor de stagiaires, daarnaast zorgen zij ervoor dat het netwerk dat momenteel gebruikt wordt binnen R@sto naar behoren werkt. 3.

Positie van de student binnen de organisatie

Het R@sto is mede ontwikkeld door stagiaires. Hierdoor verwachten zij dat stagiaires actief meedenken over de ontwikkelingen bij en de organisatie van het R@sto. Ze hebben veel ervaring met de begeleiding van stagiaires, waardoor de student in de gelegenheid is om veel te leren. Mijn positie zal die zijn van netwerkbeheerder. Ik zal een netwerkinfrastructuur ontwikkelen die door de medewerkers en stagiaires gebruikt zal worden. Dit project zal zelfstandig worden uitgevoerd. Voor het implementeren van het netwerk zal ik eventueel ondersteund worden door MBO stagiaires. Daarnaast zal ik onderzoek gaan doen naar het opzetten van een netwerk op basis van open source. Dit netwerk dient dezelfde functionaliteiten te krijgen als een op windows gebaseerd netwerk. Hierdoor zal ik eveneens ervaring opdoen in coördineren en leiding geven. 4.

Globale probleembeschrijving

Het netwerk dat R@sto op dit moment gebruikt, is onderdeel van het ROC Leiden. Hierdoor zijn zij afhankelijk van mail en andere diensten van het ROC. R@sto wil echter een onafhankelijk netwerk wat onderhoudsvriendelijk is en toegespitst is op het flexibel ondersteunen van stagiaires. 5.

Globale formulering van de afstudeeropdracht

Ontwikkel een nieuw netwerk met mail, proxy en ghost server. 6.

Onderzoek naar open source alternatief voor Windows netwerk

Op dit moment wordt er bij het R@sto al zoveel mogelijk gebruik gemaakt van open source software voor het ondersteunen van de stagiaires in hun werkzaamheden. Echter zijn dit allemaal open source programma's die onder Windows werken. Er is zelfs een aangepaste versie van Ubuntu ontwikkeld voor een pc project voor lage lonen gezinnen. Aan het begin van de

72

stageopdracht is aan gegeven dat er tevens een wens is om in de nabije toekomst over te gaan op een open source netwerk. Dit netwerk zal dezelfde functionaliteiten krijgen als het Windows netwerk. Men wil hier vooral naar over gaan in verband met de kosten, aangezien het R@sto een stichting is. Onderzoek zal gedaan worden naar : ●

voor- en nadelen van een open source netwerk

●

migratie naar een Linux/Windows netwerk of volledig open source netwerk

●

mail programma's

●

verschillende functionaliteiten binnen het domein

●

compatibiliteit met Windows programmatuur

7.

Te gebruiken technieken/methoden en ontwikkelomgeving

Binnen het eigen netwerk zal er een Active Directory domein opgezet worden met een eigen mail server (Exchange), en een eigen proxy server (ISA). De mail server spreekt voor zich, terwijl de proxy server in samenwerking met een goed policy beleid moet gaan zorgen voor een optimale beveiliging van het netwerk. Beveiliging zal tevens plaats gaan vinden door middel van het zetten van permissies, het aanmaken van beheerderaccounts en het fysiek beveiligen van servers, etc. Daarnaast wil het R@sto dat er voor alle pc’s de mogelijkheid komt om, door middel van een Ghost server, op ieder gewenst moment bepaalde besturingsystemen met bijbehorende software te laden. Hierdoor kan er snel gewisseld worden tussen verschillende configuraties, bijvoorbeeld systeembeheer, softwareontwikkeling, etc. Ook bespaart dit tijd en scheelt het in het onderhoud. Optioneel kan er onderzoek gedaan worden naar het invoeren van een sharepoint server. Voor het verwerken en organiseren van documentatie zal er een CRM pakket worden ingevoerd waarin handleidingen, werkinstructies, hard- en softwareoverzichten zullen worden georganiseerd en opgeslagen. Om een stabiele ICT infrastructuur te verkrijgen worden twee onderdelen van ITIL ingevoerd, namelijk incident- en configuratiemanagement. Indien het nodig is, zal ik bepaalde taken uitbesteden aan aanwezige MBO stagiaires. Hierbij zal ik de voortgang van het project bewaken. Verder ben ik vrij tot het ontplooien van eigen initiatieven, zoals het adviseren en onderzoeken van Open Source alternatieven voor netwerk functionaliteiten. Bij aanvang van mijn stage zal ik een Plan van Aanpak opstellen waarbij ik een (tijds)planning zal opstellen. Daarbij zal ik met de manager van het bedrijf overleggen om zo zijn wensen m.b.t. het netwerk helder te krijgen. Zodra dit bekend is zal een plan opgesteld worden waarbij gekeken zal worden welke software hiervoor het meest geschikt is. 8.

Projectactiviteiten ●

Overleg met manager over gewenste infrastructuur. Hierbij zal stagiaire een actieve inbreng in hebben doordat hij zich zal inlezen in verschillende opbouw van netwerken. Hij zal de manager adviseren over hard- en software. 73

●

N.a.v. het overleg zal stagiair een voorstel opstellen en deze ter goedkeuring voorleggen.

●

Inventariseren van beschikbare hard- en software en hierbij keuze maken van de te gebruiken hard- en software

●

Rapportage van hard- en softwaremogelijkheden en de bijbehorende voor- en nadelen en deze voorleggen aan manager

●

Opstellen van een tijdsplanning

●

Eventueel coördineren en leiding geven bij de implementatie

●

Vergaderingen bijwonen. Hierbij wordt verwacht dat student o.a. meedenkt over de organisatie van R@sto en andere onderwerpen.

9.

●

Overige activiteiten

●

Onderzoek doen naar een open source netwerk gebaseerd op open source software Op te leveren product

Een onafhankelijk netwerk dat enkel toegankelijk is voor R@sto. Aan het einde van de stage is het de bedoeling dat er een netwerk met mail, proxy en ghostserver beschikbaar is voor gebruik. Het netwerk zal bestaan uit dertig computers. Daarnaast zal er beperkte ITIL structuur geïmplementeerd zijn en zal er voldoende documentatie aanwezig zijn om het onderhoud van het netwerk af te handelen. Als laatste wordt een geteste netwerkomgeving opgeleverd op basis van open source software. 10.

De projectorganisatie

De begeleiding zal worden verzorgd door de manager van R@sto, Jan van Hordijk. Hij zal het beleidmatige gedeelte van het project begeleiden. Daarnaast krijg ik voor het vakinhoudelijke gedeelte begeleiding van twee systeembeheerders die over een ruime werkervaring beschikken. Verder zal ik het project zelfstandig uitvoeren. 11.

Planning

De stage zal vijf maanden duren en zal fulltime zijn. De voorlopige planning is dat ik mij de eerste maand met name ga verdiepen in de verschillende netwerkomgevingen die bestaan. Bovendien zal ik mij de eerste maand gaan richten op de eisen die gesteld zullen worden aan het netwerk qua gebruiksvriendelijkheid en de benodigde hard- en software. Daarnaast zal ik deze tijd gebruiken om het bedrijf beter te leren kennen. De maanden erna zal ik het netwerksysteem ontwerpen en hier een rapportage van maken. De laatste twee maanden zullen besteed worden aan het implementeren van de infrastructuur. Deze planning is nog globaal en zal mogelijk herzien worden. Door middel van een Plan van Aanpak zal ik bij aanvang van de stage een (tijds)planning opzetten voor de precieze invulling en tijdschema van het project. 12.

Uitdaging 74

Naast het feit dat ik ervaring op kan doen met de praktische beroepsuitoefening, heb ik ook de kans om ervaring op te doen met rapporteren, analyseren en het planmatig werken. Tijdens deze stage zal ik mijn kennis kunnen verdiepen op een aantal gebieden, hierbij kan gedacht worden aan het actief deelnemen aan vergaderingen, coördinatie van taken en andere organisatorische aspecten. De grootste uitdaging bestaat er mijns inziens in dat ik ervaar hoe het is om projectmatig te werken; namelijk gesprekken aangaan met een opdrachtgever, de wensen van de opdrachtgever vertalen in een plan en deze goed ten uitvoer brengen.

75

Bijlage 5

Verslag van inventarisatie

Verslag van inventarisatievragen Gestelde vragen 1. Wat is de huidige structuur? 2. Hoe zit het met de email in de huidige structuur? 3. Hoe worden de praktijkzalen voorzien van de juiste software? 4. Op wat voor wijze vindt accountbeheer plaats in de huidige structuur? 5. Wat zijn de wensen voor de nieuwe structuur? 6. Wat zijn de voor- en nadelen van de huidige structuur? 7. Hoe wordt internet verkregen? Via het ROC of met een aparte verbinding? 8. Tot hoever komt het Rasto los te staan van het ROC op netwerk gebied? 9. Heeft het Rasto een eigen ip-range/subnet? 10. Hoe zit het met de internetverbinding? 11. Routers en switches in het gebouw? 12. Wat voor servers staan hier en welke bij het ROC Leiden? 13. Hoe wordt de verdeling van de servers in de nieuwe structuur? Huidige situatie Opbouw van het netwerk In het gebouw staat een patchkast die zorgt voor netwerk- en telefoonaansluitingen. Deze faciliteiten worden geleverd door het netwerk van het ROC Leiden. Echter ligt het gehele netwerk van het R@sto in een eigen lokaal netwerk. Namelijk 10.0.0.0-255 (?) Computerpark Het aantal computers bij het R@sto ligt op plus minus 25. Bij de balie staat een pc waarin een dataschijf ligt die zorgt voor een locatie waar men gezamenlijke data kwijt kan. Daarnaast staat er een printer (HP Laserjet 2200d) bij die via de lpt-1 poort aan de balie pc gekoppeld is om als gedeelde printer beschikbaar te zijn voor het gehele R@sto netwerk. Internet- en mailvoorziening De internet voorziening wordt verzorgt door een ADSL modem van Xs4all. Deze dient tevens als DHCP en DNS server. De mailvoorziening wordt verzorgt door Groupwise mail van het ROC Leiden. Hierdoor eindigen alle adressen van R@sto medewerkers op @rocleiden.nl.

76

Images voor stagaires Op dit moment worden voor de verschillende stagiaires of images geconfigureerd of de stagiaires maken de images zelf. Nadeel hiervan is dat het erg rommelig met software en dat iedere pc apart geconfigureerd moet worden. Nieuwe situatie Opbouw van het netwerk De opbouw van het netwerk zal in de nieuwe situatie hetzelfde blijven. Er zal een lokaal netwerk blijven bestaan en er vinden ook geen veranderingen plaats aan de patchkast en de walloutlets. Computerpark Het computerpark zal aangevuld worden met 2 nieuwe servers, namelijk : ●

Windows Server 2003 DC voor DNS, DHCP, AD, proxy en file server

●

Windows Exchange Server en Ghost

Hiermee komt de computer bij de balie te vervallen als computer voor de gedeelde printer en data server. Internet- en mailvoorziening In de nieuwe structuur zal DHCP en DNS geleverd gaan worden door de Domain Controller. Het voordeel daarvan dat alles in een server zit en het makkelijker wordt om dit te onderhouden en aan te passen. In de toekomst wordt het R@sto voorzien van een eigen Exchange mail server die zal zorgen voor een eigen mailomgeving en email adressen die eindigen op @rasto.nl. De exchange zal ervoor zorgen dat ook de mail los komt te staan van het ROC Leiden. Images voor stagiaires In de toekomst wil men een standaard images (Windows XP met Office applicaties). Voor alle nietstandaard software wordt een gedeelde map Applicatie aangemaakt op de file server en hier vandaan wordt het dan mogelijk om de software, die stagiair voor een specifieke taak nodig heeft, te installeren. Alle images komen te staan op de Ghost server. Nieuwe datastructuur De gedeelde dataschijf van de computer bij de balie zal komen te vervallen. In de plaats hiervan zal een nieuwe file server met server 2003 ingericht worden. Hierop zal de data verdeeld worden in 3 verschillende dataschijven : ●

een dataschijf voor alle home directories

●

een dataschijf voor alle applicaties (d.m.v. een link naar de gedeelde map “Applicaties” op 77

de server) ●

een dataschijf voor algemeen gebruik (voor gedeelde data van iedereen bij Rasto)

Deze indeling zal er ongeveer zo uit gaan zien als in de groene handleiding voor de installatie van Windows 2000 Server. Profielen in de nieuwe structuur Een eventuele optie voor 2 verschillende profielen in het netwerk van Rasto zijn : ●

profielen voor medewerkers die zwervend worden en dus hun profieldata backup-en op de file server

●

profielen die gebruikt worden op de computers van stagiaires die mandatory zijn (veranderen mag, maar worden niet bewaard)

Ghost server De ghost server zal gaan dienen voor het distribueren van images naar verschillende groepen computers. Tevens gaat de ghost server dienen als opslag en backup voor reeds bestaande en nieuwe images. Implementatie van ITIL Voor een goed overzicht van de aanwezige apparatuur en verschillende configuraties gaat er op kleine schaal incidentmanagement en configuratiemanagement ingevoerd worden. Dit zal voornamelijk gaan aan de hand van Excel sheets of een klein gratis software pakket. Beveiliging Ook gaat er natuurlijk een stuk beveiliging in het netwerk komen. Deze kan op verschillende manieren worden ingevoerd. Voor de files en data zal gebruik worden gemaakt van share en NTFS permissies. Ook zullen een aantal beveiligingsmaatregelen worden ingevoerd door middel van policies. Hierbij kan bijvoorbeeld gedacht worden aan het afdwingen van eisen aan wachtwoorden. Documentatie Er zal het een en ander gedocumenteerd worden. Dit zal allemaal zoveel mogelijk terecht moeten gaan komen in een CRM systeem wat door een andere stagiair geïmplementeerd wordt. Documentatie zal bestaan uit : ●

een overzicht met alle configuraties van computers

●

handleidingen

●

werkinstructies

●

projectdocumentatie

MoSCoW 78

Hieronder worden de eisen voor de nieuwe situatie van het netwerk in de MoSCoW methode onderverdeeld. Must Haves ●

Server 2003 met DNS, DHCP, print, file en Active Directory services

●

Exchange server 2003 en daardoor email adressen eindigend op @rasto.nl

●

ITIL implementatie door middel van incidentmanagement en configuratiemanagement

●

Fysieke en softwarematige beveiliging van servers

●

Goede documentatie

Should Haves ●

Ghost server

Could Haves ●

ISA server

Would Haves ●

VPN verbinding voor toegang van buitenaf

79