Schlagwort: XServe

Kein Xserve mehr von Apple… ich glaub ich kotze !

Posted on by Jann Heider

Einige haben es schon geahnt, andere wollten es nicht war haben und ich bin scheiß sauer.

Wie ich eben feststellen musste wird Apple keine Professionelle Serverlösung mehr für Unternehmen anbieten. Der Apple Xserve wir nun endgültig eingedampft.

Das beweist nun vielmehr das sich Apple eher im Consumer Bereich sieht und die Frage ist wie lange noch OS X Server entwickelt wird.

Das MacPro Rechner oft leistungsfähiger als ein Xserve waren mag sein, allerdings ist ein MacPro definitiv nicht für einen Serverschrank / Serverräume geeignet.

Für meinen Teil ist das ein herber Rückschlag als Apple Systemadministrator und IT Verantwortlicher.

Ich werde mir wohl nun in den kommenden Wochen und Monaten Gedanken machen müssen wo es mich nun hinführt… Apple wird für mich wohl nur noch als Desktop / Consumer Produkt in frage kommen.

Ich denke es wird mich nun wieder deutlich mehr in Richtung Linux ziehen, sowohl im Professionellen als auch im Privaten Bereich, da ich nicht mehr weis wie es mit Apple in zukunft weitergeht und mir das ganze für meine berufliche Laufbahn zu heikel ist sich Bedingunglos einem Unternehmen zu unterwerfen.

Ob und wie ich diesen Blog noch weiter führe bleibt abzuwarten, es war ja eh etwas lau in letzter Zeit ;)

Das hat man davon wenn man sich so sehr an ein Unternehmen bindet welches mittlerweile in meinen Augen schlimmer ist als diejenigen sind die man als „Böse Monopolisten die machen was sie wollen“ beschimpfte…

Bye bye Apple

ps.: fidel hats wohl geahnt ;)

XServe AFP Durchsatz

Posted on by Jann Heider

Als Admin bin ich naturgemäß ein liebhabe von Zahlen, Statistiken etc… mich interessiert auch immer brennend der Durchsatz unserer Server. Insbesondere die, die viel zu tun haben, denn man kann immer versuchen noch mehr performance rauszuholen :)

Auf einem unserer Fileserver verwunderte mich diese Durchsatz Statistik allerdings ein wenig.

Von 0 Byte/s bis 0Byte/s ?

Auch ein neustart der Server Admin Tools hat nichts geholfen. Erst wenn ich die Zeitlinie verändere bekomme ich wieder richtige Ergebnisse.

Jaja, die Server Admin Tools … eine Never Ending Story !

Apple Software Update Server 10.6

Posted on by Jann Heider

Zur Zeit richte ich grade wieder einen Apple Software Update Server ein.

Der Apple Softwareupdateserver ist vom prinzip ein Proxy oder Clone vom originalem Apple Software Update Server (SUS). Vorteil eines inhouse SUS liegt klar auf der Hand.

Bandbreite sparen, bestimmen welche Updates verteilt werden sollen, downloadzeit für Clients sehr gering.

Eigentlich ist die Installtion kein Hexenwerk wenn man ein paar Dinge beachtet.

Continue reading →

OS X Server – ClamAV / freshclam generve nach update auf OS X 10.5.8 Server

Posted on by Jann Heider

Am Wochenende habe ich einen unserer Apple Server geupdatet.

Nach dem Update von OS X Server 10.5.5 auf 10.5.8 haben launchd und clamav (bzw. freshclam) das System.log alle 10 Sekunden zugespammt.

Die Fehlermeldungen lauteten:

19.10.09 09:58:15 org.clamav.freshclam[9271] ERROR: Incorrect argument format for option –checks (-c)
19.10.09 09:58:15 org.clamav.freshclam[9271] ERROR: Can’t parse command line options
19.10.09 09:58:15 com.apple.launchd[1] (org.clamav.freshclam[9271]) Exited with exit code: 1
19.10.09 09:58:15 com.apple.launchd[1] (org.clamav.freshclam) Throttling respawn: Will start in 10 seconds

Anscheinen hat es hier nach dem Update eine launchd plist zerhauen oder was auch immer. Eine kurze Prüfung in der entsprechenden plist „org.clamav.freshclam.plist“ zeigte wohl auch schon das Problem… ein Leerzeichen im String welches wohl falsch übergeben wird.

Die Lösung

Per ssh auf den Server (oder  alternativ auf dem Server das Terminal öffnen) und dann:

1. ClamAV stoppen

sudo launchctl unload /System/Library/LaunchDaemons/org.clamav.freshclam.plist

2. Plist bearbeiten

vim /System/Library/LaunchDaemons/org.clamav.freshclam.plist

die entsprechende stelle…

<?xml version=“1.0″ encoding=“UTF-8″?>
<!DOCTYPE plist PUBLIC „-//Apple//DTD PLIST 1.0//EN“ „http://www.apple.com/DTDs/PropertyList-1.0.dtd“>
<plist version=“1.0″>
<dict>
<key>Iterations</key>
<integer>1</integer>
<key>Label</key>
<string>org.clamav.freshclam</string>
<key>OnDemand</key>
<false/>
<key>Program</key>
<string>/usr/bin/freshclam</string>
<key>ProgramArguments</key>
<array>
<string>freshclam</string>
<string>-d</string>
<string>-c 4</string>
</array>
<key>ServiceIPC</key>
<false/>
<key>UserName</key>
<string>_clamav</string>
</dict>
</plist>

…ändern in

<?xml version=“1.0″ encoding=“UTF-8″?>
<!DOCTYPE plist PUBLIC „-//Apple//DTD PLIST 1.0//EN“ „http://www.apple.com/DTDs/PropertyList-1.0.dtd“>
<plist version=“1.0″>
<dict>
<key>Iterations</key>
<integer>1</integer>
<key>Label</key>
<string>org.clamav.freshclam</string>
<key>OnDemand</key>
<false/>
<key>Program</key>
<string>/usr/bin/freshclam</string>
<key>ProgramArguments</key>
<array>
<string>freshclam</string>
<string>-d</string>
<string>-c</string>
<string>4</string>
</array>
<key>ServiceIPC</key>
<false/>
<key>UserName</key>
<string>_clamav</string>
</dict>
</plist>

und gut ist! Danach kann ClamAV wieder gestartet werden.

3. ClamAV wieder starten:

sudo launchctl load /System/Library/LaunchDaemons/org.clamav.freshclam.plist

Nach der Änderung sollte es im log dann wieder so aussehen:

19.10.09 10:15:17 org.clamav.freshclam[9319] ClamAV update process started at Mon Oct 19 10:15:17 2009
19.10.09 10:15:17 org.clamav.freshclam[9319] main.cld is up to date (version: 51, sigs: 545035, f-level: 42, builder: sven)
19.10.09 10:15:18 org.clamav.freshclam[9319] Trying host database.clamav.net (212.18.5.140)…
19.10.09 10:15:18 org.clamav.freshclam[9319] Downloading daily-9909.cdiff [100%]
19.10.09 10:15:18 org.clamav.freshclam[9319] Downloading daily-9909.cdiff [100%]
19.10.09 10:15:18 org.clamav.freshclam[9319] daily.cld updated (version: 9909, sigs: 86294, f-level: 43, builder: guitar)
19.10.09 10:15:18 org.clamav.freshclam[9319] Database updated (631329 signatures) from database.clamav.net (IP: 212.18.5.140)

So schaut es wieder gut aus, ClamAV kann sich wieder updaten und meine System.log wird nicht alle 10 Sekunden zugespammt :) Muchas!

Mac OS X Server – AFP kerberisieren

Posted on by Jann Heider

Eben im Testlabor wollte ich einen Fileserver in meine vorhanden Test-Domain einbinden. Die Identifizierung sollte natürlich über Kerberos laufen, dies habe ich auch fein über die Admin-Tools konfiguriert:

Dummerweise haben die Admintools den Dienst nicht kerberisiert (warum auch immer).

Prüfen kann man die übrigens über das Terminal mit dem Shell-befehl „klist -kt„.

Um den AFP Dienst nachträglich auf einem Mac OS X Server zu kerberisieren muss man das Terminal bemühen. Der Befehl zum kerberisieren lautet wie folgt:

sso_util configure -r odserver.domain.de -a odadmin afp

odserver.domain.de = euer Open Directory Master
odadmin = Das Admin-Account der eure OD verwalten darf

Nach erfolg sollte die Ausgabe so aussehen:

Contacting the directory server
/Local/Default
/BSD/local
/LDAPv3/127.0.0.1
Creating the service list
Creating the service principals
WARNING: no policy specified for afpserver/myafpserver.mydomain.de@odserver.MYDOMAIN.DE; defaulting to no policy
Creating the keytab file
Configuring services
WriteSetupFile: setup file path = /temp.l0Y3/setup

Eine erneute Prüfung mittels „klist -kt“ auf dem Fileserver sieht dann so aus:

Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp         Principal
—- —————– ——————————————————–
3 01/16/09 10:35:03 afpserver/myafpserver.domain.de@odserver.DOMAIN.DE

Somit ist der AFP Dienst auf dem Server kerberisiert und die Clients können sich mit ihrem Kerberos Ticket am Fileserver anmelden.

Intel XServe – keine Verbindung mit dem Servermonitor

Posted on by Jann Heider

Wir haben unseren ersten Intel XServe im Live Betrieb, das Teil rennt wie ne 1 :). Ein Problem hatten wir jedoch, über den Servermonitor konnten wir keine Verbindung zum Xserve aufbauen in der Zusammenfassung stand lediglich der Status : „Auf Antwort Warten„. Das Protokoll lieferte auch keine wirklich nützlichen Informationen: „Konnte Server nicht erreichen“

Nach ein wenig Recherche habe ich nun die Lösung gefunden: LOM (Lights-Out Management) ist bei einem Intel XServe nicht standartmäßig aktiviert und muss manuell konfiguriert werden.

Konfiguration von LOM

  • Auf dem Server (Lokal) den Servermonitor starten
  • Im Menü auf Server und dann auf Lokalen Computer konfigurieren gehen

Konfiguration LOM

  • Der LOM Dienst braucht eine eigene Statische IP Adresse. Man kann den LOM Dienst für eine oder beide Netzwerkkarten konfigurieren, Anschluss 1 für En0 und Anschluss 2 für En1
  • Der LOM Dienst kann nur mit einem Lokalen User Account arbeiten (z.B. der Admin-Account)
  • Nach Eingabe einer Statischen IP-Adresse, Subnetzmaske, Gateway und de Lokalem Benutzeraccount einfach über „Anwenden“ die Einstellungen speichern.

Servermonitor Konfigurieren

  • Auf dem Server lokal den Server im Servermonitor hinzufügen mit der Loopback Adresse (127.0.0.1) und dem entsprechenden User
  • Auf dem eigenen System (oder einem anderen Remote System) muss im Servermonitor die oben Konfigurierte LOM IP-Adresse und der entsprechende User eingetragen werden.

Ich hoffe ich konnte hiermit einigen anderen Mac Admins helfen :)