Adminday.de

Lang ist es her das ich im lokalen Netz einen Debian Webserver eingerichtet habe, ich habe ihn genau so eingerichtet wie alle die Server die im Rechenzentrum stehen und wunderte mich warum Exim4 meine Mails nicht an unseren internen Mailserver senden wollte.

Der Mailer Daemon meldete nur

Mail delivery failed: returning message to sender
all relevant MX records point to non-existent hosts

Der Debian Server selbst löst die MX Einträge korrekt auf und der Mailserver ist auch unter den einträgen erreichbar.

Mehr…

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…

Wow, ich kann echt nicht verstehen wie es leute schaffen soooo viele E-Mail aufzuheben und dann noch den überblick zu haben.

Die Top 10 unserer E-Mail Messies:

44 GB an E-Mails ??? Wer kann da noch den überblick behalten.

E-Mail Program != Organisations- , Ablage-, Archivprogramm, aber versucht das mal einem User zu erklähren.

Ich glaube ich werde nun anfangen einach quotas einzusetzen, die immer weiter runter geschraubt werden. Diese werden dann auch strikt eingehalten weil technisch nicht anders möglich…

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 !

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 :/