2010-07-04
Kommentar

Utmaningarna Apple inte tar sig an

Sedan Macpro startade 2004 så har jag i omgångar försökt använda Mac OS X Server professionellt. Redan 1999, när jag arbetade som testredaktör på nu insomnade Nätverk&Kommunikation, så testade jag Mac OS X Server 1.0, något jag kommer att delvis återvända till senare i denna text.

Jag känner många små företag som har en Mac-server ståendes som filserver på sin reklambyrå, eller som webbserver, eller som kombinerad server för webb, fil, print, mail och hantering av användarkonton, med mera.

Kort sagt, precis allt det som Apple lovar att Snow Leopard Server kan.

Problemet är att det ofta inte blir som Apple lovat.

Ärrade administratörer av tidigare versioner av Mac OS X Server har säkerligen timmar av historier att berätta, men jag tänker fokusera på Mac OS X Server 10.6 då det är den version som är relevant just nu.

Onödigt omständigt

För att vara ett serveroperativ som Apple beskriver är enkelt att hantera, så är Snow Leopard Server onödigt komplicerat.

Att installera Mac OS X Server 10.6 är som jag tidigare nämnt enklare än tidigare versioner. Ändå kan man i denna installationsprocess falla i både en och två fällor som gör att man helt sonika tvingas installera om hela maskinen.

När man installerat servern och sedan ska lägga upp användare i sitt Open Directory så ska man använda DirAdmin-användaren. Var är lösenordet dokumenterat till det? Det är alltså samma lösenord som administrationsanvändaren fått under installationen, men som användare får du aldrig reda på hur det lösenordet sattes, eller att du ens ska använda diradmin-användaren.

När man sedan lagt upp sina användare, lagt till att de exempelvis ska synkronisera sina hemkataloger mot servern, så uppstår nästa problem: att få det att fungera. En klientmaskin som tagits från Mac OS X 10.5.8 till 10.6.whatever är i princip omöjlig att synkronisera. Ibland börjar klienten synkroniseras, i andra fall händer absolut ingenting alls. Jag har själv förlorat data genom att använda funktionen så man ska ha ordentligt med backuper om man ska våga sig på att köra den regelbundet.

Om man helt blåser en klientmaskin, installerar Mac OS X 10.6 och sedan får frågan om man vill ansluta till sin nätverksserver för att få tillgång till e-post, kalendrar, adressbok och andra tjänster som man delat ut. Tackar man ja till detta så installeras tjänsterna automatiskt och vips så har man alla funktioner upplagda. Snyggt, ja absolut, men det finns två saker att fråga sig:

1. Är det så smart att bara för att man råkar ha samma loginnamn och lösenord som på nätverkskontot får man alltså tillgång till alla data som användaren har på servern?

2. Om man nu valt att ansluta sig till alla dessa tjänster, varför får man också inte frågan om att synkronisera sin hemkatalog på samma gång?

När man som användare kopplat upp sig och inser att man inte får sin synkronisering av hemkatalogen, uppstår nästa problem. För att få till synkroniseringen måste man logga in med sitt nätverkskonto. Har man då som i exemplet ovan samma inloggningsnamn som ens användare har i OD:t måste man först skapa en lokal användare till, se till att den användaren är administratör, logga in som den användaren istället, radera den användare man initialt skapat, och sedan logga ut, och till sist logga in som sin nätverksanvändare.

Synkroniseringen av hemkatalogen fungerar då, men då blir du inte erbjuden att ansluta till de andra tjänsterna som du först blev erbjuden att ansluta dig emot. Logiken i Apples design av detta, eller snarare avsaknad av densamma, ger mig huvudvärk.

Detta är bara ett exempel på hur det är att arbeta med Apples produkter i ett företagsnät. Ett annat är den interna DNS:en. I Apples värld finns det inget @-record i DNS-tabellerna. Alltså, där du istället för att koppla IP-adressen 1.2.3.4 till www.macpro.se istället kopplar den till @ i DNS-tabellen. Detta gör att om man slår in macpro.se i en webbläsare så kommer man till servern med IP-adressen 1.2.3.4 ändå.

Om man skulle ge sig på att handhacka DNS-tabellerna så är det samma sak som att skjuta sig i foten, chansen att det fungerar är inte så bra.

Kör du AFP som protokoll mellan en Snow Leopard Server och en Snow Leopard-klient kan, eller snarare kommer du, att få problem med rättigheterna förr eller senare. Lösningen på detta? Kör Samba mellan maskinerna istället. Ironiskt nog fungerar det utmärkt, ironiskt eftersom AFP, Apple Filing Protocol, är Apples egendesignade dito.

Man kan vidare ta exemplet med Apples uppgraderingar. Den gängse regeln är att man ska vänta med varje uppdatering av Mac OS X Server. Anledningen är enkel: saker och ting slutar fungera när andra saker börjar att fungera. Hade den här bloggen handlat om Windows hade man kanske förväntat sig att så var fallet, men faktum är att Microsofts buggfixar håller så otroligt mycket högre kvalitet jämfört med Apples. Alla programvaror innehåller buggar, det är inget konstigt med det, men det vore intressant att få fram hur mycket betatestande som sker av Mac OS X Server jämfört med klientversion av operativsystemet.

Filsystem

Två saker som blivit väldigt populära på senare år är stödet för iSCSI och moderna filsystem som ZFS. iSCSI är enkelt uttryckt ett sätt att skicka SCSI-kommandon över Gigabit Ethernet-nätverk, ett sätt att montera NAS- eller SAN-diskar med högre prestanda jämfört med NFS eller andra protokoll mellan server och disklåda. I iSCSI-terminologi finns det dels iSCSI-initiators, “klientdelen”, och iSCSI-targets, “serverdelen”.

Apple stödjer inte detta. Mac OS X har, vad jag lyckats hitta, tre iSCSI-initiators, varav en är gratis och inte fungerar ordentligt under Snow Leopard Server (jag testade detta genom att montera en iSCSI-disk på mitt SAN, vilket fungerade, och sedan försöka formattera den med Disk Utility. Detta fungerade inte. Däremot fungerade det utmärkt med Windows 2003-servers iSCSI-initiator…). Betalvarianterna har jag inte testat då de kostar skjortan. Någon programvara för att dela ut diskar via iSCSI från Mac OS X finns inte heller.

Inför releasen av Snow Leopard och Snow Leopard Server spekulerades det i att Apple skulle inkludera stöd för iSCSI. Så blev det inte. Istället verkar Apples enda alternativ vara XSan, ett alternativ som inkluderar Fibre Channel som i sin tur är dyrt och också en teknologi som många menar är på väg ut till förmån för Fibre Channel over Ethernet (FCoE) som erbjuder god prestanda över 10 Gigabit Ethernet med samma funktioner som Fibre Channel, fast utan dyra switchar, speciellt kablage, särskilda anslutningar, och så vidare.

På tal om andra saker som man förväntade sig i Snow Leopard Server: ZFS. Jag och många med mig har tjatat oss trötta på detta så du kan läsa hela storyn här och få hela smacket där istället. Klart är att Apple till synes står utan en framtid efter HFS+, och utan funktioner som deduplicering och snapshots som i princip samtliga konkurrenter har inbyggt som standard i sina operativsystem.

Ett ordentligt stöd för virtualisering står också på önskelistan. Många tror och tycker säkert att de inte behöver virtualisera sina servrar, men när man väl börjat arbeta med virtualiserade maskiner, och inser att man kan flytta runt dem till annan hårdvara om behovet faller på, så är det inte så illa längre. Tvärt om. Apple själva gör väldigt lite för att göra virtualisering av Mac OS X Server möjligt. Även här finns det åtskilliga frågor och så få svar från Apple om var de är på väg med detta. Ingenstans, gissar jag, då det inte ligger i deras intresse att öka marknadsandelarna för Mac OS X Server utan snarare att sälja XServes och Mac Mini Server.

Professionellt oprofessionella

Istället för att fortsätta hoppa på iPhone och dess avsaknad av pushfunktion kontra Snow Leopard Server, tänkte jag göra en jämförelse.

Tänk dig att Microsoft, när de släpper Windows Phone 7, meddelar att dess integration med Exchange Server endast fungerar till 100 procent med Microsofts egna molnvariant av Exchange Server. Tänk dig vidare att de innan de lanserat det nya mobila operativsystemet lovat att det ska fungera med Exchange Server 2010.

Tänk dig sedan vilket sjuhelsickes liv det ska bli när kunderna upptäcker att det inte var som Microsoft lovat.

Tänk dig vidare att Microsoft stoppar huvudet i sanden, vägrar svara på frågor om varför funktionen inte levererades som utlovat, varför den till och med finns tryckt i alla manualer som gått ut till användarna (och som fortfarande finns att ladda ner på företagets supportsidor) utan istället lägger upp en supportsida där de kort och koncist meddelar att det inte fungerar, och sen är det inget mer med det.

Otänkbart? Man kan säga vad man vill om Microsoft men de tjänar fruktansvärt mycket pengar på företagskunderna, och de vet att de inte kan leverera något som de lovat så kommer kunderna att få reda på det, och också när det är fixat. Så behandlar man kunder som man vill behålla.

Så jobbar, som bekant, inte Apple. De tar sina kunder för givet.

Istället gör Apple precis som exemplet ovan, fast här handlar det om iPhones funktionalitet mot Snow Leopard Server. Någon formell integration finns inte mellan de två.

Det finns ingen möjlighet att lägga upp en iPhone som en enhet i ett OD, eller att radera telefonen via 3G-nätet från Workgroup Manager. Man kan synkronisera kalendrar och adressböcker och sin mail, vilket är ju för väl, men någon pushfunktion till de tre har ingen av dem från Snow Leopard Server.

Ska man köpa den funktionen från Apple krävs det att man köper MobileMe. En tjänst för privatpersoner. Inte heller här redovisar Apple moms på kvittot när man köper ett abonnemang, för övrigt. Något Apple tycks ha förbenat svårt med.

Framtiden för Apple på företagsmarknaden

App Store är inte för företag. MobileMe är inte för företag. Apple Store är för företag (de redovisar moms på sina kvitton). Är då Snow Leopard Server, och hela Apples serversatsning, eller snarare vad som är kvar av den, för företag?

Problemet med Apple är att de är arroganta. De vill gå sin egen väg och förväntar sig att kunna göra det med vad de än företar sig. Problemet med att bygga ett operativsystem för servrar på i stora delar öppen källkod är att de inte har kontroll. Visst, de skriver över alla små egna lösningar du lagt in med varje uppdatering, och om inte Apple anser att du behöver en webbmail som faktiskt inte får dina ögon att tåras, så är det bara så. Arrogans kan vara charmigt, och när det gäller i princip hela Apples produktsortiment på konsumentsidan, också ruggigt framgångsrikt.

Frédéric Filloux har skrivit något väldigt intressant om just det här med amerikanska företags arrogans när de opererar utomlands:

Many American companies suffer from vision impairment: they consider the Rest of the World as an aggregation of second-class people. What I called in a previous column the “Burundi Syndrome”, leads to zero delegation of authority. This leads to terrible results. Each attempt from a European subsidiary to adapt company policies to its local market conditions hits a wall of a soviet-like centralization, this time epicentered on the West Coast of the United States.

This is true for Google, but also for Apple, Amazon or Microsoft. The people they maintain on this side of the Atlantic are powerless – and, often, frightened; they will constantly defer to the HQ, “la corp” in French parlance, for any decision. Such rigid stance is actually good news for alternative, more flexible players. There are local companies willing and able do what it takes to capture the markets left open by their inflexible US competitors, in digital advertising or contents delivery. One customer at a time, big companies undermine a customer and partner base that was once largely sympathetic.

In the long run, ignoring these trends can only have adverse effects.

Företagskunder vill ha framförhållning. De vill veta vad som komma skall, vad de kan förvänta sig och när. Och framför allt, de vill veta att vad deras leverantör har lovat, faktiskt kommer. Om det inte levereras i tid så vill kunderna veta när. Alla vet ju som bekant att det är inte så Apple jobbar.

Har då Apple någon framtid på företagsmarknaden? Frågan är om de vill ha det.

Deras servrar är det verkligen inget fel på, varken Xserve eller Mac Mini Server, och även om XSan är så hårt knuten till Fibre Channel så är även den en grymt kompetent produkt.

Tittar man på Mac OS X Server i övrigt så kan man, helt krasst, bygga något som fungerar minst lika bra, om inte bättre, med exempelvis Red Hat Enterprise Linux, eller varför inte Windows Server? Ska man vara krass så är ju integrationen mellan server och klient i Mac OS X-världen så bristfällig så man lika gärna kan leva utan den, och ser man till de andra tjänster man servrar sina Mac-klienter med i nätverket så spelar det ju ingen som helst roll om man kör OS X Server eller Linux på hårdvaran, AFP (som fungerar bättre under Linux än i Mac OS X Server), DHCP, DNS, IMAP, CalDav, LDAP, och mycket mycket mer, finns redan i Linux. Vill man ändå köra Mac kan man sätta upp en kombinerad CardDav och CalDav-server på en vanlig Mac och spara sköna tusenlappar.

Om man vill. Många vill inte det. Många vill ha trygghet, funktioner som lirar, och därför finns det alternativ. För tio år sedan skrev jag i en krönika följande mening:

Finns det alternativ till Microsofts Windows 2000 Server? Linux är inte riktigt där ännu, och Apples Mac OS X Server ser lovande ut men saknar fortfarande en hel del för att vara ett realistiskt alternativ.

Ironiskt nog har inte den bilden förändrats nämnvärt i Apples fall.

Avråder jag då från att köra Snow Leopard Server? Nej, inte direkt.

Väljer man att köra den här lösningen så finns ingen enkel väg ur den. På den punkten skiljer sig inte Apple nämnvärt från sina konkurrenter, men har man en gång satt upp Snow Leopard Server och börjat använda den professionellt så bör man vara medveten om vilka risker och problem som finns, och att det i vissa fall finns en väg ur dem och i andra får man helt enkelt lära sig att leva med dem.

Kör man fast så är det bara att ta hjälp av proffs, eller att sätta sig och läsa i Apples diskussionsforum. För det är där den verkliga hjälpen finns: hos andra systemadministratörer. Inte hos Apple.


Macpro är annonsfri för att göra din läsupplevelse bättre.
Läs mer här

© 2004 - 2017 Joacim Melin