Adminday.de

Jedes System welches ich neu aufsetzte (egal ob Privat oder in der Firma) bekommt von mir mindestens 2 Standard User Accounts. Einmal einen Admin User und dann der User selbst. Bei mobilen Clients gibt es dann oft noch einen 2ten mobilen Admin User (Grund hierfür wäre zu lange zum erklären).

Damit allerdings im Anmeldefenster nicht all diese Admin Accounts rumlungern sondern nur der User Account angezeigt wird, gibt es bei OS X zwei Wege.

Auch normale User Accounts können über das Terminal versteckt werden.

Mehr…

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.

Mehr…

Ist einfach im laufendem betrieb auf meinem MacBook Pro aufgepoppt..

Irgendwie vermute ich hier die Server-Admintools als Fehlerquelle, fragt mich nicht warum aber ich bin auf die Apple Server Admin Tools Grade ehh nicht besonders gut zu sprechen!

Eben grade habe ich auf einem neuen MacBook Pro mit Mac OS 10.6 den Web´n Walk Stick Fusion (Modell MF637) versucht zu installieren. Nach der Installtion funtkionierte schon die Systemeinstllungen nicht mehr richtig… naja mal nen neustart machen und schauen was passiert.

Dumm nur das das MacBook Pro danach nicht mehr booten wollte!

Also das System im Verbose Modus (Apfel + V) gebootet und mal geschaut was los ist… das System bleibt mit folgender Meldung stehen:

Warning – com.apple.driver.InternalModemSupport declares no kernel dependencies ; using com.apple.kernel.6.0.

Yeah! Danke Telekom und Huwai für diese schadhafte Installation ! *kotz*

Nach langem suchem im Internet und debugging auf einem Testsystem nun die Lösung …

Der Installer der Telekom ersetzt unter /usr/lib/ die libcurl.4.dylib mit einer nicht 64-Bit fähigen version … WARUM AUCH IMMER DER INSTALLER SEINE EIGENE libcurl Version mitbringt! Das verstehe ich nicht!

Vorgehensweise wenn das System nicht mehr bootet:

Ihr müsst also einfach euch von einem anderem Mac mit 10.6 oder der Installtions DVD die libcurl.4.dylib besorgen.

Ich habe in meinm Fall einfach das MacBook Pro im Target Disc Modus gebootet und von einem anderem Mac (mit 10.6.) die libcurl.4.dylib auf das MacBook Pro kopiert.

Entweder macht ihr das über das Terminal mit “cp” oder über den Finder mit “gehe zu” und dann “/usr/lib/” und einfach kopieren und überschreiben, den Mac neustarten und schon läuft alles wieder! Ja, auch die Telekom Software wird dann laufen!

Vorgehensweise bei einer neuen Erstinstallation:

1. Die Datei /usr/lib/libcurl.4.dylib backupen (z.B. auf den Schreibtisch kopieren)
2. Telekom Software installieren (welche nun die Original libcurl.4.dylib überschreibt)
3. Danach das System nicht neustarten!
4. Die vorher gesichterte libcurl.4.dylib wieder zurück nach /usr/lib/ kopieren
5. System neustarten

Nun sollte der Mac und auch der UMTS Stick inkl. der Telekom Software laufen!

Danke… das hat mich grade eben 3 Stunden debugging und meine Mittagspause gekostet !

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!

Über fidel und Lasse bin ich auf das Stöckchen von Dave aufmerksam geworden. Genaugenommen hat es mit Lasse zugeworfen.

Dave möchte gern wissen was sich in unseren Docks so sammeln und wie wir Programme starten die nicht im Dock sind (Applauncher).

Mein Dock auf der Arbeit sieht so aus:

Von Links nach Rechts:

Finder, Dashboard, Safari, 4D Client, FireFox, Word, PowePoint, Excel, Entourage, GraphicConverter, Server-Admin, Arbeitsgruppenmanager, Servermonitor, Remote Desktop, Remotedesktopverbindung, VMWare Fusion, FileWave XAdmin, Kerio Admin Console, Textwrangler, Chicken of the VNC, Sequel Pro, Terminal (ganz wichtig!!!) Cyberduck, iCal, Notizzettel, Microsoft Messenger, Adium, SSH Agent.

Und mein Dock @ Home:

Wer fragen zu eines der Programme hat kann sich gern hier melden ^^

Ansonsten Starte ich Programmme die nicht im Dock sind einfach über Spotlight (oben recht, bzw. cmd + Leertaste)

[Update]
Ich habe noch mein Dock @ Home hinzugefügt

Mh, nachdem heute mein Server-Admin gestartet ist waren 3 Server ausgegraut und die Meldung lautete “Dienste nicht erreichbar” oder “Dienste nicht konfiguriert”, bekomme die genaue Fehlermeldung jetzt nicht wirklich zusammen. Selbst auf den Servern Lokal funktionierten die Server-Admin Tools nicht.

Im ersten Moment… schock… was ist passiert…. alle Dienste weg und jetzt alles neu konfigurieren ?

Naja, ganz so Schlimm war es zum glück doch nicht, die Dienste wie DNS, Open Directory, WWW, AFP, etc… liefen einwandfrei. Also wohl mal wieder ein Bug in den Server-Admin Tools :/

Etwas Recherche im Internet ergab das man den Server neustarten soll damit es wieder geht… lol… das können die Windows Admins ja gerne bei Ihren Kisten machen um ein Problem zu lösen.

Also weiteres Debugging…

Die Logfiles auf dem Server hatten zu hauf solch schöne Einträge:

23.03.09 10:01:38 Server Admin[1122] *** -[GroupTextField windowDidResignKey:]: unrecognized selector sent to instance 0x2a91e0

Diese entstanden jedoch nur wenn man den Server-Admin beendet und wieder gestartet hat.

Der Prozess servermgrd auf dem Server schien auf den ersten blick nicht zu hängen. Dieser Daemon wird gebraucht um mit dem Server-Admin den Server zu administrieren.

Um sicherzustellen das der servermgrd Daemon auf dem Server auch einwandfrei läuft kann man einfach mit einem Webbrowser die URL https://mein.server.de:311/ aufrufen. Wird hier erfolgreich etwas angezeigt läuft der Daemon auf jeden Fall einwandfrei.

Und genau das war nicht der Fall.

Um jetzt nicht den ganzen Server neustarten zu müssen killen wir einfach den Daemon:

Zuerst prüfen wir ob und unter welcher PID er läuft, also das Terminal öffnen und folgendes eingeben:

ps aux | grep servermgrd

Die Ausgabe sollte dann etwa so aussehen:

Danach einfach im Terminal den Prozess killen mit “kill (PID)” in diesem Fall also:

kill 75

und manuell Launchd anweisen den Daemon zu starten mit dem Befehl:

launchctl load /System/Library/LaunchDaemons/com.apple.servermgrd.plist

Fertig! Alles läuft wieder einwandfrei und ich musste den Server nicht neustarten !!!

Habt ihr auch schon öfter schlechte Erfahrungen mit den Server-Admin Tools von Mac OS X gehabt ?

Die Serveradmin Tools sind leider sehr oft Buggi wie sau :/

Merke! Wenn man unter OS X 10.5 mal schnell den Lokalen DNS Cache leeren möchte einfach im Terminal folgenden befehl eingeben:

dscacheutil -flushcache

Unter OS X 10.4 war das noch:

lookupd -flushcache

War grade etwas verwirrt da als den unter 10.4 bekannten Befehl eingegeben habe und der mit nur gesagt hat “-bash: lookupd: command not found” ^^

Das MacBook Air hat ja kein CD / DVD Laufwerk, kann aber jedoch von jedem beliebigen Mac das CD / DVD Laufwerk benutzen, um diese Funktion zu aktivieren muss auf dem Mac (der das CD / DVD Laufwerk hat) das CD / DVD Sharing Aktiviert werden (Zu finden in den Systemeinstellungen -> Sharing). Nun kann man über das Netzwerk mit dem MacBook Air auf das Laufwerk zugreifen.

Diese Funktion hat Apple eigentlich nur dem MacBook Air spendiert, allerdings lässt es sich auch auf jeden anderen Mac freischalten.

Dafür müssen folgende 2 Shellbefehle im Terminal eingegeben werden (alles in eine Zeile):

defaults write com.apple.NetworkBrowser EnableODiskBrowsing -bool true

und danach

defaults write com.apple.NetworkBrowser ODSSupported -bool true

Jetzt einmal das System neustarten und schon kann man schön im Finder ein freigegebenes CD / DVD Laufwerk sehen , siehe Screenshot:

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.