Prosjektplan SAMBA 4. Drift av nettverk og datasystemer (10HBDRA) Øystein Bjørkelo (100920) Kristofers Celms (100924) Kapilan Kumarasamy (100241)

Transkript

1 Prosjektplan SAMBA 4 Drift av nettverk og datasystemer (10HBDRA) Øystein Bjørkelo (100920) Kristofers Celms (100924) Kapilan Kumarasamy (100241) Vår 2013

2 Innholdsfortegnelse 1. MÅL OG RAMMER Bakgrunn Prosjektmål Resultatmål Målgruppe Effektmål Rammer Teknologiske rammer Tid og økonomi OMFANG Oppgavebeskrivelse Avgrensning PROSJEKTORGANISERING Ansvarsforhold og roller PLANLEGGING, OPPFØLGING OG RAPPORTERING Hovedinndeling av prosjektet Plan for statusmøter og beslutningspunkter ORGANISERING AV KVALITETSSIKRING Dokumentasjon, standardbruk og kildekode Versjonsstyring Risikoanalyse PLAN FOR GJENNOMFØRING Hovedaktiviteter og milepæler Gantt-skjema

3 1. MÅL OG RAMMER 1.1. Bakgrunn IT-tjenesten på høgskolen i Gjøvik ønsker å etterhvert gå over til å benytte Samba 4. Det vil si at det kan erstatte en Microsoft Active Directory pirmær domene server og at man kan kjøre en full Active Directory-infrastruktur uten Microsoftprodukter. Ved denne type infrastruktur er det krav til svært høy tilgjengelighet, og ny teknologi som dette må testes ekstensivt før den kan benyttes i produksjon. IT-tjenesten på høgskolen ønsker dermed at vi får utført en grundig test i simulerte stor-skala omgivelser. IT_Tjenesten ved HiG bruker idag Samba 3 som en erstatning for CIFS og Windows. IT- Tjenesten benytter seg av også av Unix identiteter gjennom LDAP oppslag for basis identitetsoppslag, mens det blir brukt WinBind for Security Identifiers (SID) til navnoppslag. Samba 4 hevder å kunne erstatte en Active Directory og fungere som en AD Domain controller. I tilegg så skal den kunne være både en Kerberos tjener, eller benytte en eksisterende kerberos infrastruktur. Samba 4 skal også kunne gjøre LDAP katalog-tjenester som Active Directory gjør Prosjektmål Resultatmål Resultatmål med dette prosjektet er å finne ut om Samba 4 tilfredsstiller de høye kravene til å være (en del av) fullstendige Active Directory domeneservere i HiGs infrastruktur. Det skal gjøres ved å teste ut forskjellige aspekter av Samba4 og dens fleksibilitet i diverse scenarioer - se punkt 2.1 for utvidet informasjon. I oppgaven skal det kartlegges om Samba 4 kan blant annet: være AD og LDAP katalog for både Windows og Unix brukere være Forest root controller 3

4 være medlem av en forest struktur som en domenekontroller være medlem av Windows 2008 server godta POSIX LDAP (FEIDE) fullstendig støtte Group Policies som AD tjener Teste MS-SNTP tidsynkronisering Målgruppe Målgruppen for resultatene og konklusjon av denne rapporten er oppdragsgiver IT-tjenesten ved Høgskolen i Gjøvik. Prosjektet skal dokumenteres og skrives slik at en enkel person med litt mer enn grunnleggende datakunnskaper skal kunne relativt lett orientere seg i dette og muligens lett reprodusere og ta i bruk det oppgaven beskriver. Dette kan også være aktuell informasjon til både de som bruker Microsoft sine løsninger, men ønsker å kunne gå over til en åpen kildekode-løsning Effektmål Målet for prosjektet er å se nærmere på hvorvidt HIG vil ha nytte av å benytte Samba 4 fremfor Microsoft Active Directory. Økonomisk lønnsomt, brukeropplevelse, hvor lett er å drifte Samba 4 i forhold til Microsoft produkter. Kan Samba 4 forenkle driftsrutiner og gjøre samme jobben? Hvis HIG innfører Samba4, må det fremdeles være mulighet for: Unix og Win-brukere ender opp med samme ID. Identitetshåndtering og passordhåndtering på et sted. Ved vellykket implementering og testing skal det oppnås god forståelse over Samba 4 sine fordeler og eventuelle ulemper. Den viktigste fordelen ved å benytte Samba 4 er å minske avhengighet av lukket kildekode programvare. Eventuelt vil IT-tjenesten basere alle sine løsninger på åpne standarder og produkter. Slik strategi gir større fleksibilitet (bedre tilpasningsmuligheter, frihet i valg av oppsett, konfigurasjon, utstyr og systemer. Løsninger som passer for både laveffekts- innebygde systemer og store skalerbare klustere) og øker effektivitet og kompatibilitet mellom Linux/Unix servere og Windows-baserte klienter. 4

5 1.3. Rammer Teknologiske rammer I forbindelse med oppgaven skal det brukes en dedikert testserver levert av IT-Tjenesten. Det er en Citrix XenServer, der det skal kunne opprettes og kjøres virtuelle maskiner. Det er kun nødvendig å kjøre maksimalt fem maskiner samtidig, og etter spesifikasjoner så er det nok med en XenServer for denne oppgaven. Vi skal opprette åtte virtuelle maskiner med følgende oppsett: Microsoft - Active Directory Microsoft - Active Directory Forest Controller Microsoft - Windows-klient Linux - Samba 4 Active Directory Linux - Samba 4 Active Directory Forest Controller Linux - Samba 4 CIFS-server Linux - Samba 4 LDAP Linux - Ubuntu-klient Tid og økonomi Siden det skal benyttes eksisterende utstyr og løsninger, estimeres det ingen ekstra kostnader utenom det vanlige. Prosjektet skal være ferdig innen 15. mai Detaljert oversikt over tidsrelaterte aktiviteter finnes i punkt 6.1 Hovedaktiviteter og milepæler og punkt 6.2 Gantt-skjema. 2. OMFANG 2.1. Oppgavebeskrivelse Oppgaven generelt skal bestå av to hoveddeler - teori og praksis (med en ca 40/60 fordeling). Oppgaven skal også inneholde en del om de forskjellige teknologiene og programvaren som skal bli utprøvd i forskjellige scenarier. Oppgaven vil inneholde generelt 5

6 om Samba og Active DIrectory - hva de er og hvordan de fungerer sammen og hva de utfører av oppgaver for en IT-infrastruktur. Det vil også være informasjon om hva FEIDE er for noe, og hvordan det er implementert i nåværende løsning, og hvordan det kan bli integrert sammen med Samba 4 som oppgaven hovedsaklig dreier seg rundt. Videre vil oppgaven dekke begreper og grunnleggende prinsipper for Active Directory Forests, LDAP, CIFS, NFS, POSIX LDAP m.fl. Etter teoridelen av oppgaven, vil praksisbiten bestå av hovedsakelig fire deler: 1 Oppsett av maskinvare og programvare Opprette åtte virtuelle maskiner (tre Windows og fem Linux) som beskrevet i punkt og legge dem i et eget subnett. 2 Konfigurering og testing a Teste ni forskjellige scenarioer: i Basic AD Bli kjent med Active Directory og dets komponenter, og hvordan dette fungerer sammen med klienter. ii AD + Samba Vidreutvikler forrige trinn ved å legge til en Samba 4 CIFS tjeneste, mens Microsoft Active Directory og Windows-klienten blir beholdt. iii Samba som AD På dette stadiet skal en ren Samba-løsning utprøves. Samba skal fungere både som Active Directory som en erstatter for Microsoft sin løsning, og en CIFS-filserver. iv Kryssplatform med AD CIFS-serveren blir beholdt, mens en LDAP boks blir lagt til, kjørende med Samba sin løsning. Deretter blir Microsoft sin Active Directory fra scenario ii aktivert, og en Linux-klient lagt til. Dette blir da en kryssplattform med Microsoft AD og Samba 4 som CIFS og LDAP. v Kryssplatform kun Samba CIFS-serveren levert av Samba 4 blir beholdt, og en Active Directory og LDAP oppslagstjeneste kjørendepå Samba 4 blir lagt til. I tilegg er det 6

7 to klienter, Windows og Linux, slik at dette blir en kryssplattformsløsning med kun Samba 4. vi Samba 4 kryssplatform med ekstern LDAP Dette scenarioet er identisk med det forrige, men LDAP tjenesten kjører på en egen virtuell maskin istedet for å ha den kjørende som en tjeneste på Active Directory-serveren. vii AD forest Dette er en fullstendig Microsoft-løsning, med Active Directory Forest Controller på topp, med to Active Directory medlemmer og en klient på hver av medlemmene. viii AD forest med Samba medlem Dette er samme oppsett som vii. men et av Active Directorymedlemmene er byttet ut til å kjøre på en Samba 4 løsning. ix AD forest med Samba root Dette er det siste steget, hvor Microsoft sin Active Directory Forest Controller er byttet ut med Samba 4 sin løsning, med en Microsoft Active Directory medlem, og et Samba 4 Active Directory medlem. b Feide integrering c Noe av dette overlappes, men generelt sett de punktene fra Samling av resultater og analyse. For eksempel, oversikt, forskjellige sammenligninger og hvor tillitsfulle er oppnådde resultater. Det vil si hvor mye vil disse resultatene samsvarer med virkeligheten? 1 Konklusjon Avgrensning Bruke eksisterende løsninger så ofte som mulig hvis de passer målsettingen. Bruke automatisering (ved hjelp av scripting) for repeterende oppgaver. Gjenbruke og tilpasse virtuelle maskiner til de forskjellige scenarioene. Det er ikke ment at vanlige (ikke IT-relaterte) brukere skal kunne benytte noe av dette prosjektet. 7

8 3. PROSJEKTORGANISERING 3.1 Ansvarsforhold og roller Oppdragsgiver og veileder: Jon Langseth, Erik Hjelmås Alle deltagere hver for seg er ansvarlige for å holde seg oppdatert om hele prosjektet, over de siste hendelsene og all relevant informasjon. Navn Øystein Bjørkelo Kristofers Celms Kapilan Kurumasamy Rolle Prosjektleder, hoved kontaktperson, språkansvarlig - sørger for at prosjektdokumentasjon er uten stavefeil og er vel strukturert. Webansvarlig - oppretter og holder prosjekts nettsiden oppdatert under hele prosjekttid, kontaktperson Organisering av møter og holde oppdatert fremdriftsplan internt for gruppe, logging og kontaktperson 8

9 3.2 Rutiner og regler i gruppen 4. PLANLEGGING, OPPFØLGING OG RAPPORTERING 9

10 4.1 Hovedinndeling av prosjektet Prosjektet vil benytte en inkrementell utviklingsmodell som vil bli delt opp i flere moduler, spesielt for de 9 testscenarioene der noe evolusjonær utvikling skal brukes. Modulbaser utviklingsmodell sørger for at i tilfelle der noen av modulene kan ikke gjennomføres, resultatet av prosjektet påvirkes lite. 4.2 Plan for statusmøter og beslutningspunkter Statusmøter med alle gruppemedlemmer, veileder og oppdragsgiver blir holdt annenhver uke i HIG på mandager kl På møtet gjennomgås den siste ukens arbeid og plan for fremtidig uke besluttes. 5. ORGANISERING AV KVALITETSSIKRING 5.1. Dokumentasjon, standardbruk og kildekode Dokumentering og kommentering utarbeides underveis under hele prosjektet og ferdigstilles ved leveranse Versjonsstyring Det skal benyttes Google Docs for felles dokumentering av arbeid, Lyx for strukturert og renskrevet prosjektrapport, Dropbox for deling av filer, HIG sin SVN eller Bitbucket løsninger for eventuelle kode-oppgaver Risikoanalyse Nr. Trussel Risiko Strategi for håndtering 1 Tidsrammene blir overskredet Middels Fleksibel tidsplanlegging 2 Prosjektet blir ferdigstilt bare delvis Middels Modulbasert utviklingsmodell minsker konsekvenser hvis noen av modulene blir ikke fullført 10

11 3 Det er ikke mulig å realisere en eller flere moduler Lav Direkte e-post kommunikasjon med en av Samba 4 hovedutviklere sammen med mulighet til å stille spørsmål i et av Samba 4 sine støtteforumer og erfarene IT-folk veg HIG skal kunne hjelpe oss å løse de feilene vi skal oppdage. Siden Samba 4 har blitt sluppet ut ganske nylig, regner vi med at det vil ikke bli mulig å fullføre enkelte modulene i angitt tidsperiode eller i det hele tatt. 4 Tap av prosjektdokumentasjon, virtuelle maskiner eller liknende. Lav Regelmessig sikkerhetkopiering i både nettsky og lokalt skal sørge for at risikoen for tap av informasjon blir minimalt. 5 En av medlemmene skiller seg fra gruppen Lav Tre års erfaring i samarbeid mellom hver av gruppemedlemmene reduserer mulighet for en slik hendelse. 6. PLAN FOR GJENNOMFØRING 6.1 Hovedaktiviteter og milepæler De viktige datoene for prosjektet er: 28/01/ Innlevering av forprosjektsrapport og prosjektavtale med oppdragsgiver. 20/02/ Nettside skal være etablert. 15/05/ Bacheloroppgaven (rapport med vedlegg) leveres i Fronter. 29/05/ A3 plakat til Utstilling leveres i Fronter. Ukjent - Undertegnet avtale om publisering leveres til biblioteket 11

12 6.2 Gantt-skjema Prosjektplan - Gantt-skjema 12

13 Prosjektplan - Gantt-skjema utvidet med tidslinjer 13