Hoe kan een Windows desktop of server geïntegreerd worden in een wereld van Linux- en Unix-systemen?
Niet alle bedrijven kiezen voor en werken uitsluitend met Windows. De hele netwerkomgeving kan best gebaseerd zijn op Unix of Linux. Dat wil zeggen dat alle servers Unix of Linux draaien, en misschien gebruikt het bedrijf voor de gebruikersdesktops Sun Ray thin clients en bijbehorende applicatieserver(s) (die draaien dan Suns Unix-variant Solaris), of gewoon Linux-desktops.
Een bedrijf waarvan het netwerk op die manier gegroeid is, heeft wellicht niet zoveel rekening gehouden met Windows omdat dat gewoon niet nodig was. Maar stel dat een bedrijf – om wat voor reden dan ook – besloten heeft om Windows-desktops of -servers toe te voegen. Kan dat dan zomaar? Is bijvoorbeeld bidirectioneel verkeer mogelijk tussen Linux en een andere Windows-centrische omgeving zoals .NET? Werken Linux-ontwikkelaars hieraan of zijn het allemaal arrogante kwasten die met stijve nek en opgeheven hoofd alles wat met Windows te maken heeft verafschuwen en dus negeren?
Op de desktop draait bijna altijd wel Windows.Het toevoegen van Windows-desktops in een Unix-omgeving stelt vaak niet zo heel veel problemen, omdat de meest recente Unix-achtige platformen zoals Linux en Solaris goed rekening houden met Windows. Ze hebben alle benodigde uitwisselingsprotocollen standaard aan boord.
Nu is het wel mogelijk dat de in het bedrijf gebruikte servers die protocollen niet geïnstalleerd of draaiend hebben. Misschien willen of kunnen de bevoegde beheerders die functionaliteit ook niet voorzien, bijvoorbeeld om veiligheidsredenen. Dan nog hoeft het geen probleem te zijn. Mocht als filesharingprotocol NFS in gebruik zijn, dan kan Windows daar ook wel mee werken.
Je kunt voor alle andere Unix-protocollen gratis software voor Windows vinden om die te ondersteunen. Zelfs als dat niet zo is, zou je er nog zelf voor kunnen zorgen, vermits alle door Linux ondersteunde protocollen sowieso open source zijn. Je eigen ict-mensen zouden dus prima een versie voor Windows kunnen compileren.
Applicatiespecifieke protocollen
Protocollen die bij een specifieke Windows-applicatie horen, worden niet gebruikt in Linux/Unix-serveromgevingen. Het kan dus nodig zijn die ofwel te omzeilen, ofwel op een andere manier in te voegen. Een voorbeeld is de overweging om een Exchange-mailserver in gebruik te nemen. Op zich is er geen enkel probleem zo’n Exchange-server in een netwerk van Linux/Unix-systemen bij te plaatsen om die dan te gebruiken met Windows-desktops en Outlook.
Maar dat vereist licenties voor een Windows-server, Exchange en de clientconnecties daar naartoe. Bovendien moet elk Windows-systeem en dus ook de servers voorzien worden van antimalwaresoftware. Het mag dus geen verwondering wekken dat Linux/Unix-beheerders het absoluut niet zien zitten om een Windows-server toe te voegen aan hun netwerk als dat niet essentieel is. Dat is immers een kwestie van beveiliging. En ja, daar kan ook aversie tegen alles van Microsoft mee te maken hebben.
Maar de techneuten nemen dergelijke beslissingen doorgaans niet, de directie wel. Die laat zich natuurlijk (hopelijk) adviseren. Voor Exchange is er wel degelijk een alternatief: Open-Xchange Server. Voor Outlook-clients onder Windows en Evolution-clients onder Linux-desktops ziet die server er volledig uit als een Microsoft Exchange Server met dezelfde functionaliteit. Alleen gaat het dus om een dienst die onder Linux draait. Een echte ‘drop-in’-vervanger dus.
Een ander voorbeeld is SAP. Dat is heus niet beperkt tot Windows. En ook hier biedt bijvoorbeeld Novell een oplossing in de vorm van Novell SuSE Linux Enterprise Server for SAP. Zelfs een SQL Server kun je onder Linux emuleren als dat nodig zou zijn voor een of andere Windows-applicatie. Zo kan een Oracle-databaseserver zich standaard voordoen als een SQL Server. In geval van nood kan altijd nog een SQL Server opgesteld worden als front-end die dus vóór de gewenste database wordt geplaatst.
.NET en MONO
MONO zorgt ervoor dat .NET draait op Linux.Een .NET-omgeving is per definitie Windows-centrisch. Het lijkt dus voor de hand te liggen Windows-systemen te gebruiken in bedrijven die absoluut een .NET-omgeving willen draaien. En hoewel .NET in zijn ontwerp platformagnostisch is, blijkt de praktijk doorgaans uitsluitend Windows te omvatten. Laten we eerlijk zijn: Microsoft heeft een versie van .NET voor FreeBSD, dus het bestaat wel degelijk buiten Windows. Maar in realiteit wordt buiten Windows niets daarvan gebruikt vanwege de beperkingen in de licenties van Microsoft.
Toch bestaan ook hier alternatieven in de Linux-wereld. Zo bestaat er MONO, een door Novell gesponsord .NET-compatibel raamwerk voor Linux en andere platformen inclusief Windows zelf. Daarmee kunnen Linux-programmeurs applicaties bouwen die door Windows-systemen herkend worden als .NET, maar die gewoon onder Linux draaien. Er was oorspronkelijk heel wat discussie over de levensvatbaarheid van MONO, aangezien beweerd werd dat het project verschillende patenten van Microsoft zou schenden en dat het bedrijf dus op ieder moment de stekker er kan uittrekken.
Microsoft heeft echter nooit laten weten welke patenten precies geschonden zouden worden, net zomin als het dat voor Linux zelf deed. Daar zal zeker een deel FUD (fear, uncertainty and doubt) in meespelen. Als je een klant van Novell bent, ben je wel via de overeenkomst tussen Novell en Microsoft gevrijwaard van elke patentvervolging door Microsoft – of zijn vertegenwoordigers – voor alle producten die Novell maakt of sponsort.
Rauw beheer
Linux/Unix-omgevingen worden heel vaak op de meest rauwe manier op afstand beheerd via ssh (een beveiligde opdrachtregel). De grote beheersuites van CA, HP en IBM ondersteunen natuurlijk ook Linux en Unix-systemen en sowieso Windows, dus daarmee kun je gemakkelijk genoeg Windows-systemen beheren in een Linux/Unix-wereld.
Zonder zo’n beheersuite ligt het iets moeilijker aangezien Windows zelf geen met Linux vergelijkbare opdrachtregel kent. Met de komst van Microsofts PowerShell is dat natuurlijk wel veranderd, maar een Linux/Unix-beheerder zal het begrijpelijkerwijs niet zien zitten PowerShell aan te leren om een paar Windows-systemen op afstand te kunnen beheren. Als het maar om een paar systemen gaat, kunnen die vanuit Linux op afstand beheerd worden via een RDP-client. Dat vereist van de beheerder natuurlijk wel enige Windows-kennis.
In feite kom je er niet omheen om Windows-kennis nodig te hebben voor het beheer van elk Windows-systeem. Het beheer daarvan is immers totaal verschillend van Linux/Unix. Via RDP werk je met een GUI en dan is het beheer niet moeilijk, maar nog steeds anders dan je met Linux/Unix gewend bent. Het vereist toch wel dat je weet waar alle beheer- en configuratieparameters te vinden en in te stellen zijn.
Dankzij virtualisatie gaat Windows veel beter samen met Linux of zelfs Unix.Je merkt dat er veel minder moeite gedaan wordt om enkele Windows-systemen in een Linux/Unix-wereld te integreren buiten de allerbekendste protocollen zoals SMB (via SAMBA) om. Voor beheer op afstand ben je bijna helemaal op jezelf aangewezen. Omgekeerd is er heel wat meer beschikbaar om Linux-systemen te integreren in een Windows-wereld. Je zou dat kunnen toeschrijven aan de hier al genoemde dedain, maar dat zou al te simpel zijn.
Voor iedereen die dergelijke platformoverbruggende software maakt, is het namelijk voor de hand liggend om te veronderstellen dat een Linux-systeem in een Windows-omgeving geïntegreerd moet worden in plaats van omgekeerd. Simpelweg omdat dat veel vaker voorkomt. In Linux-omgevingen zul je over het algemeen Windows-functionaliteit het liefst toevoegen als virtuele systemen op Linux via VMware of via de tegenwoordig in de Linux-kernel ingebouwde hypervisor.
Andere mogelijkheden van virtualisatie voor Windows-applicaties zijn: WINE, Bochs en CrossOver Linux (dat heette vroeger CrossOver Office). Dat laatste hebben we ooit getest in het kader van de Xandros Linux-desktop en daarmee kun je inderdaad specifieke Windows-applicaties op Linux draaien. Wij probeerden Office 2003 en dat werkte feilloos. Gewoon de software vanaf cd installeren en het draait. Deze software bestaat trouwens ook voor Mac OS X als CrossOver Mac. Voor de duidelijkheid: deze CrossOver-software van de Amerikaanse firma Codeweavers is niet gratis (kost tussen de 39,95 en 69,95 dollar), maar vereist geen Windows-licentie. Je kunt dus Windows-applicaties draaien zonder een extra Windows-licentie per client te moeten betalen. Zeker het overwegen waard, lijkt ons.
De Kern
Windows desktops en servers kunnen doorgaans alleen voor basisfunctionaliteit in een Linux/Unix-omgeving opgenomen worden.
Meer functionaliteit vergt Windows-expertise en vaak installatie van bijkomende Windows-servers, maar eventueel kun je Windows ook virtualiseren onder Linux.
