Hendrix

Finns det någon möjlighet att köra en annan NAT-enhet än OS X-servern?

I sin egen VPN-lösning har Apple implementerat en draft av NAT-T-protokollet (NAT-Traversal) som gör deras VPN inkompatibelt med andra VPN-terminaler om man kör NAT. Jag vet inte om detta också kan ha påverkat deras implementation av NAT i OS X Server?

Manualen om Mailservice på Mac OS X Server innehåller en hel del tips på hur man kan konfigurera servern för att filtrera mail. Båda SpamAssasin och ClamAV kommer förinstallerat. Läs från sidan 46 och framåt. Är inte helt säker på huruvida den tillämpar filtrering för både inkommande och utgående mail, men jag vet att båda programmen borde kunna konfigureras för att granska även utgående mail.

Med 50'-100' mail på kö bör du nog skynda dig innan ni blir svartlistade och helt tappar möjligheten att skicka mail.

http://images.apple.com/server/pdfs/Mail_Service_v10.4.pdf

Du behöver också prenumerera på en sajtkategorisering av något slag. Du kommer omöjligen själv kunna blockera alla "dåliga sidor" Om du sköter filtreringen på OS X Server eller i någon annan burk är upp till dig.

Här är en annan tråd som diskuterar saken:
http://www.derkeiler.com/Mailing-Lists/securityfocus/security-basics/2006-05/msg00078.html

För en listning av sajter kan du kika här:
http://www.urlblacklist.com/

Om du inte vill använda proxy så är det många tillverkare av hårdvarubrandväggar som också tillhandahåller olika typer av URL-blockering med uppdaterade listor.

Hur bra är lastbalanseringen i brandväggen? Hur agerar brandväggen om en av servrarna dör/stannar? Fortsätter den dela ut anslutningar även till den trasiga servern? Någon typ av tjänsteövervakning kommer att behövas så systemet vet vad som är uppe och står och ej.

Om brandväggen skulle stanna så stannar ju alla sju 99-sajterna. Redundanta lastbalanserare (och) brandväggar är trevligare, men givetvis pilligare att konfigurera och kräver mer hårdvara. Det blir väldig panik när alla sju sajterna dör annars.

En generell iakttagelse angående replikering är att det ibland är riktigt smärtsamt att felsöka. Om något går snett i replikeringen kan administratören sitta och ladda om sidor i all oändlighet och ändå inte se fel som användaren ser från en annan server. Skillnader mellan servrarna är mer omständigt att lokalisera och åtgärda.

Jag skulle föreslå en gemensam filserver för alla servrarna som är permanent NFS-mountad. Apache cachear de vanligast använda filerna i minne så att ha diskaccesser via ett Gigabit-nätverk innebär ingen stor prestandaminskning för webbservrarna. På så sätt garanterar man att alla ser samma sak vid alla tidpunkter.

Den största anledningen till att nästa generations arbetsstationer inte dykt upp stavas Adobe. Så länge Adobe inte har sina programvaror ute kompilerade för Intel är proffsens vilja att byta till en Intel-burk (och förlora viktiga klockcykler i Rosetta) i bästa fall liten.

En opensorucelösning för lastbalansering går att hitta här (som dock kräver mycket kunskap även om programvaran är gratis):
http://www.linuxvirtualserver.org/

Här finns en lite enklare och mer komplett förpackning av LVS:
http://www.ultramonkey.org/

Jag skulle definitivt köra en xserve som master och låta de andra replikera den. På så sätt kan du ju haka på fler xservrar om antalet användare stiger eller om belastningen ökar. Det ger dig också bara ett OD att underhålla.

För e-post och web skulle jag satsa på en (eller helst två för redundans) lastbalanserare framför serverklustret så att det i praktiken bara ser ut som en server, men i verkligheten består av flera servrar i bakgrunden.

VPN funkar utmärkt och kan göra allt det du föreslår förutsatt att det är Mac:ar i andra änden.

Kryptering äter ju en del av nätverksprestandan så jag vet inte hur lätt/svårt det är att synka en roaming profile via VPN.

Om du försöker använda ditt Mac OS VPN med något annat operativsystem kommer du att få problem. Dessa går dock att komma runt genom att använda andra klientprogramvaror än t.ex. Windows XP:s inbyggda.

Det ser ut som om någon sökväg är trasig i httpd.conf eller därtill länkade filer. Ibland i samband med (säkerhets)uppgraderingar har det hänt att Apple byter konfigurationsfil för Apache. Då kan man ofta hitta den gamla filen i samma katalog med .backup eller liknande som filändelse.

En uppgradering som ju faktiskt kostar 8000kr+moms. Och ja, 10.3 patchas fortfarande när det gäller säkerhetsuppdateringar.

Liten varning för ditt utvecklingsarbete: GD varierar ganska mycket mellan olika versioner så det kan löna sig att försäkra sig om att de funktioner du använder på utvecklingsservern säkert finns i den version som du har på produktionsservern.

Att få en Apache/MySQL-installation att rulla bra (och göra mer avancerade saker, vilket du verkar ha behov av) kräver lite mer än bara en titta och tryck installation. MacOS X utgör ett utmärkt server-operativ och det tycker jag definitivt att du ska titta på. Behovet av kompetens för att ratta det hela försvinner dock inte. Mitt tips är att du kommer behöva en "Unix-pillare" även i framtiden oavsett om du kör Linux eller MacOS X.

Jag skulle kolla MeetingMaker från PeopleCube http://www.peoplecube.com/

Ett enligt min mening grymt kalenderprogram. Om än kanske en smula över er budget. Både klient och server finns för Mac/Windows och den kan integreras med LDAP.

Eftersom jag bär hem våra backup:er varje vecka så känns det som att ett band väger mycket mindre än en hårddisk. Nåja, kanske inte mycket mindre än en 2,5:a, men jag har inte sett så många slädlösningar för sådana diskar eller är det någon som har några förslag?

Om man ska ta sin kritiska data off-site, och det bör man, är band ganska praktiska trots allt.

Mac OS X inbyggda VPN använder inte den slutgiltiga standarden för NAT-Traversal (konsten att adressöversätta VPN-trafik utan att paketets integritet förstörs). Apple har istället implementerat ett av draften till standarden.

Det betyder att om adressöversättning (NAT) förekommer på vägen, till exempel i en brandvägg, funkar inte VPN om den enda änden är MacOS X och andra änden följer den slutgiltiga NAT-T-standarden.

Kan detta vara roten till ditt problem?

Jag skulle vilja påstå att linan kommer att vara flaskhalsen. En eMac borde inte ha några större problem att fylla 1 Mbit. Lite beroende på hur komplexa databas-queries vi talar om och om det är många och varierande filer som ska skickas.

Både Apache och MySQL kan fås att cachea ganska effektivt och då blir hårddiskhastigheten inte av så stor betydelse. Men om databasens totala storlek växer över vad som kan hållas i RAM eller om det är väldigt många olika filer som ska skickas vid varje given tidpunkt så kan det givetvis bli bekymmer.