2.5. Serversiden
Opdelingen i en serverside og en klientside er ikke valgt arbitrær, men har sin begrundelse i, at den vil være to helt forskellige opgaver. Et skifte på serversiden behøver ikke at få nogen indflydelse på organisationen, og kan gennemføres transparent overfor brugerne, hvilket betyder, at det kan foregå i et passende tempo, og ikke kræver hastige og uovervejede beslutninger. For at gøre opgaven overskuelig kommer her et par råd:
-
Gør ikke det hele på en gang. Start på serversiden og vent med brugersiden til serverudskiftningen er gennemført tilfredsstillende.
-
Undgå programudvikling.
-
Lær Linux at kende; det kan mere end Windows, så det kan anbefales, at der bruges tid på at lære det at kende, da det næsten altid viser sig, at ting der før var vanskelige under Windows, kan gøres enklere og nemmere under Linux. Frigør dig fra Windows' begrænsninger, og tænk og arbejd Linux.
-
Brug flere, mere åbne protokoller. Jo flere protokoller på netværket, jo større vil opgaven blive at administrere det.
2.5.1. Platformsskift - hvordan
I dette afsnit vil metoden for skiftet blive gennemgået nærmere, og den indeholder fire trin. De første tre giver dig et overblik over dine data, og hvordan adgangen til dem er i dag, mens det sidste trin indeholder udarbejdelsen af et diagram, der vil give dig et overblik over, hvordan server og klientløsningen skal udarbejdes.
De fire trin er følgende:
-
Lav en liste over dine data, og hvor de befinder sig. Listen skal også vise, hvem der har ansvaret for dataene - systemadministrationen eller brugerne.
-
Lav en liste over de programmer, der benyttes i dag.
-
Lav en liste over de anvendte protokoller, og hvordan kommunikationen foregår til data i dag.
-
Udarbejd diagrammet
Som man kan se, er trinene protokol og programstyret, hvilket giver mulighed for at få et overblik over de forskellige løsningsmodeller, der kan vælges, under hensyntagen til de bindinger forskellige programmer og protokoller medfører. Når man kender alle læsningsmodeller, har man mulighed for at vælge den løsning, der er mest optimal for virksomheden.
2.5.1.1. Listen over data
Verden af i dag betyder, at alle mennesker har enorme datalagre liggende på deres computere. Nogen ligger placeret de officielle steder - i hjemmekataloget på serverne, mens andre er placeret uofficielt - lokalt på arbejdsstationerne, men ligegyldigt hvor de ligger placeret, er de væsentlige for medarbejdernes arbejdsindsats, og derfor skal vi have styr på, hvor de befinder sig. Typiske eksempler på disse vigtige data er:
-
E-post og adressebøger. Hvordan er data gemt? Hvilke mailservere og protokoller anvendes? Hvilken form for autorisation bruges?
-
Kalendere og tidsplanlægningsprogrammer. Mailsystemer leveres ofte sammen med gruppebaserede tidsplanlægningsprogrammer (Microsoft Exchange, Lotus Domino etc.), og kræver ofte særlige forholdsregler, da de sjældent benytter åbne standarder.
-
Filressourcer. Brugere har ofte store mængder af fælles officedokumenter liggende, som er vitale.
-
Databaser. På serversiden er det produkter som Oracle eller Microsoft SQL server, mens det på brugersiden typisk er Microsoft Access. Målet er, at bruger ikke mærker nogen ændringer i deres daglige brug af disse. Betyder ikke produkterne er ens, men kun at brugerinterface ikke ændres.
-
Webservere. Brugere som vedligeholder dem, skal ikke mærke nogen forskel; de skal stadigvæk kunne anvende de programmer, de vedligeholder dem med i dag. Data på websider kan også være hentet udefra, og derfor skal man have styr på, hvordan data lagres og deres format samt hvilke bindinger der er - ActiveX, ASP etc.
Der findes også vigtige data på serverne, som bliver administreret af systemadministrationen. Til disse henhøre blandt andet:
-
Brugerdatabaser. Indeholder en detaljeret beskrivelse af alle brugere på virksomhedens net, og hvilke rettigheder hver enkelt bruger har.
-
Grupper og rettigheder. Hvilke grupper findes på virksomhedens net? F.eks. er salgsafdelingen en typisk gruppe, der skal kunne tilgå kundedatabasen.
Backup arkiver. I windowsverdenen er det typisk tredjepartsprogrammer, der håndtere backup, så vi skal finde ud af, om det findes på til Linux.
-
Logfiler. Vigtige hvis noget går galt, eller som bevis i en retsag vedrærende hacking mv.
2.5.1.2. Nuværende brugerprogrammer
Selvom der findes et utal af programmer til Windows, kommer de fleste programmer fra højest 10 forskellige udbydere, så hvis man kan lave en samlet aftale med nogen få af dem, er de fleste problemer på klientsiden løst.
Manglen på erstatninger for nogle programmer på klientsiden knytter sig hovedsageligt til Microsoftprodukter, men da Linux er i stand til at servicere disse programmer, og da vi benytter en flertrinsraket, giver dette sjælden nogen problemer. De færeste begynder alligevel ikke på klientsiden først, da medarbejderne først skal have den nødvendig uddannelse.
Den nemmeste måde at starte planlægningen af systemskiftet på klientsiden er at udarbejde en tabel, der adresserer firmaets specifikke behov. Denne kunne foreksempel se ud på følgende måde:
Tabel 2-1. Microsoft Windows programmer
| Program | Anvendelse | Kan benytte Linux-server | Substitueres med | Linux-version |
|---|---|---|---|---|
| MS Office | Skrive og redigere dokumenter, regneark, præsentationer mv. | Ja, via Samba | Få. WordPerfect, StarOffice og OpenOffice.org | Ja, WordPerfect, StarOffice og OpenOffice.org |
| Osv. | Osv. | Osv. | Osv. | Osv. |
2.5.1.3. Protokoller og kommunikation i dag
Det følgende afsnit vedrører protokoller, og hvordan kommunikationen foregår. Læsten skal indeholde de protokoller, som firmaets microsoftprogrammer benytter. Hvis man ikke er sikker, findes der forskellige programmer man kan bruge til at finde ud af det, forlad dig ikke udelukkende på dokumentationen. Disse programmer kaldes netværkssniffere.
Det interessante her er, at næsten alle ikke standardteknologier fra Microsoft enten er baseret på på allerede eksisterende teknologier, eller er dokumenteret på et lavere niveau. Politikken her er helt klar: Hold dig til åbne standarder[1], da det giver frihed fra producenterne.
En anden pudsig ting er, at de fleste produkter fra Microsoft udemærket kan kommunikere over standardteknologier, men er opsat til at benytte Microsofts egne ikke standardiserede teknologier, så i de fleste tilfælde er det kun et spørgsmål om at omkonfigurere programmerne.
Et eksempel på en tabel kommer her:
Tabel 2-2. Protokoller foretrukket af Microsofts produkter
| Anvendelse | Foretrukken protokol/kommunikation | Dokumenteret |
|---|---|---|
| MS Outlook til MS Exchange Server | MAPI over DCE/RPC til e-post | Krypteret på en udokumenteret måde |
| Osv. | Osv. | Osv. |
Tabel 2-3. Protokolerstatninger og implementationer
| Protokol | Fri Implementation | åben alternativ | Kommentarer |
|---|---|---|---|
| MAPI over DCE/RPC | Nej | IMAP og tilsvarende standarder | Cyrus mail suite kan erstatte MS EXchange |
| MAPI over DCE/RPC til kalender | Nej | ACAP, ICAP, vCARD og tilsvarende standarder | Hvis Outlook mail og kalender er et must, findes der HP Openmail til Linux |
2.5.1.4. Protokoldiagrammet
På baggrund af de forrige tabeller skulle du være i stand til at lave nedenstående liste. Se Figur 2-3
-
Kombinationen af protokoller/programmer der kan benyttes for at kommunikere med Linux-serveren - også kombinationer der ikke benyttes på nuværende tidspunkt, skal med.
-
De protokoller som åben server software kan benytte til at servicere eksisterende data.
-
De protokoller åbne klientprogrammer kan benytte til at kommunikere med eksisterende data
Vi har nu færdigbehandlet serversiden, og med denne gennemgang skulle du være rustet til at påbegynde din egen migrationsplan, men til slut mangler jeg lige at pointere, at de enkelte programmer og deres forskellige protokoller vil blive behandlet i deres respektive afsnit.