#mountain lion server

[jhochwald]

Apple Mountain Lion Server: Enable the dedication of resources to Server apps (Repost)

Apple Mountain Lion Server: Enable the dedication of resources to Server apps

A few days ago a friend called me and told me, they the performance of there Apple Mountain Lion Server seems to slow down since a while. Yesterday they gave me access… After a few research I figured out, that both 10.8 Servers didn’t run in “Server Performance Mode”!

Since 10.8 (Mountain Lion) this setting is missing in the Server.app (The GUI). If you want to figure out if your server is running in “Server Performance Mode” (enable the dedication of resources to Server apps), just fire up the following in your terminal: jhochwald@brain:~ $ serverinfo --perfmode Server performance mode is enabled. In the output above you see, that the “Server Performance Mode” is enabled!

Otherwise you’ll get: Server performance mode is NOT enabled.

Here is how to enable/disable the “Server Performance Mode”: Enable “Server Performance Mode”: jhochwald@brain:~ $ sudo serverinfo --setperfmode 1 Server performance mode was enabled.

Disable “Server Performance Mode”: jhochwald@brain:~ $ serverinfo --setperfmode 0 Server performance mode was disabled.

The alternative to the commands above is the “serveradmin” command. Here are the examples for this: Read the status of “Server Performance Mode”: sudo serveradmin settings info:enableServerPerformanceMode info:enableServerPerformanceMode = yes

Enable “Server Performance Mode”: sudo serveradmin settings info:enableServerPerformanceMode = yes

Disable “Server Performance Mode”: sudo serveradmin settings info:enableServerPerformanceMode = no

I think there is no difference, so its up to you to use the “serverinfo” or the “serveradmin” command.

Originally posted on: Apple Mountain Lion Server: Enable the dedication of resources to Server apps

[jhochwald]

Warum OS X Mountain Lion als Server? (Repost)

Warum OS X Mountain Lion als Server?

Mein Beitrag “Zurück auf dem Apple Mountain Lion Server” hat einige (Offline) Fragen ausgelöst! Meist wurde ich gefragt warum ich mir das wieder antun würde. Das ganze hat viele Gründe…

Der wichtigste Grund: Ich habe bis jetzt viel mit Google Apps gemacht, da meine Beziehung zu Google aber in letzter Zeit doch etwas kompliziert geworden ist, habe ich mich entschieden die Google Cloud so langsam, aber ganz sicher, zu verlassen!

Ein anderer Grund: Der Preis ist quasi ein echtes Schnäppchen, denn wo gibt es denn sonst ein Server Betriebsystem für knapp 40 Euro? Auch die nötige Hardware ist nicht der Rede Wert: Jeder Mountain Lion kompatible Rechner mit mindestens 4GB sollte als einfacher Server durchaus ausreichen! In meinem Fall ist es ein Mac Mini Server mit 8GB und zwei 500GB Platten (Gespiegelt). Was in meinem Fall mehr als ausreicht!!!

Apple Server (Mac Mini)

Was man noch investieren sollte: Eine zusätzliche Platte (Extern, im Fall des Mac Mini) und ganz sicher auch eine USV (Denn einen Stromausfall würde ich nicht riskieren wollen). Die externe Platte sollte zur Sicherung des Servers dienen! In meinem Fall habe ich die externe Lösung auf Basis eines NAS etabliert! Dort lagere ich diverse Daten aus. Meine Datensicherungen mache ich auf einer Time Capsule. Das liegt aber daran, dass diese schon vorhanden war ;-)

Sicher ein weiterer Grund auf den Mountain Lion als Server zu setzten ist die Mail Funktion: Da Apple hier auf sehr gute Open Source Komponenten setzt kann der vorhandene Dienst sehr gut angepasst werden. In meinem Fall nutze ich das um Dinge wie Spam Filter und Disclaimer nutzen bzw. optimieren.

AntiSpam

In meinem Fall setzte ich vor allem auf den Open Directory! Der LDAPv3 Verzeichnisdienst von Apple basiert auf OpenLDAP, dass macht es einfach! Das die ganzen Apple Dienste darauf aufsetzten ist ja klar! Mit einem Passwort auf Shares und Wiki’s zugreifen ist nett! Aber mir reichte das ganze nicht: Ich habe noch eine Menge (interne und externe) Dienste so konfiguriert, dass ich mich mit dem gleichen User & Passwort alles nutzen kann.

Der Profilemanager ist ein absolut schlagendes Argument! Bei Payloads können Apple iPhone, iPad und Macs (Ab 10.7 aka Lion) konfiguriert werden. Und das via Web-Interface, also zur Not auch von Remote (Also von überall). Selbst wenn nur wenige zu konfigurierende Geräte vorhanden sind: Die Funktion des Mobile Device Management plus Mac Management wird jeder recht schnell zu schätzen lernen!

Zum teilen von Inhalten stehen eigentlich alle wichtigen Protokolle zur Verfügung. Ganz vorne natürlich Apple Filing Protocol (AFP). Jeder der einen Mac nutzt wird das als Default schnell zu schätzen lernen. Aber auch Windows rechnet kommen nicht zu kurz: Server Message Block (SMB) bzw. Common Internet File System (CIFS) kompatible Freigaben sind kein Problem! Damit sollte das einbinden vorhandener Windows Clients einfach sein. Allerdings bietet Apple keinen Domain Support! Wer das (wirklich) braucht, der muss sich was anderes einfallen lassen. Entweder einen eigenen Active Directory (AD) Controller, oder eine Linux Box mit entsprechend konfiguriertem SAMBA. sollte eine Windows Box als Active Directory Controller zum Einsatz kommen, können die meisten Apple Mountain Lion Server Dienste anfragen auch dagegen authentisieren. Für mich aber nicht von Interesse! Aber das Teilen von Inhalten erfordert heute ja viel mehr als einfache File und Print Dienste! Apple setzt hier auf Wiki Dienste und Blogs. Die Apple Wiki Dienste sind durchaus als echte Collaboration Plattform geeignet! Neben einfachen Wiki-Seiten können auch Dokumente im Microsoft Office Format und/oder Apple iWork Format hochgeladen und angesehen werden. Zusätzlich natürlich auch Dateien im PDF Format und alle gängigen Grafik Formate. Beim Thema Collaboration: Apple bietet zusätzlich auch einen Jabber Dienst an. Der Name ist mit Nachrichten zwar etwas komisch gewählt, aber Apple bietet hier einen vollwertigen XMPP/Jabber Server. Mit dem passenden Client macht das gerade im Fall verteilter Teams nicht uns Sinn, es macht wirklich Spass! Aber auch mobile Endgeräte können auf freigegebene Daten zugreifen: Apple setzt auf WebDAV! Ich nutze WebDAV um vom iPhone/iPad auf Daten zuzugreifen, aber auch von unterwegs vom Mac auf wichtige Daten zuzugreifen ist kein Problem!

Aber um auf wichtige Dinge zuzugreifen kann auch ein VPN verwendet werden. Apple bietet neben L2TP auch PPTP als mögliche VPN Protokolle an. Ich rate jedem natürlich auf IPsec, also Layer 2 Tunneling Protocol (L2TP), zu setzten. Point-to-Point Tunneling Protocol (PPTP) ist nach meiner persönlichen Meinung nicht als wirklich sicher einzustufen. Und beim Apple Server ist die Nutzung von IPsec auch extrem einfach.

Jeder der mehr als einen Mac als Client hat wird auch den Apple Software Update Server (SuS) zu schätzen wissen! Updates können hier gezielt freigegeben werden und im lokalen Netz ist die Performance natürlich auch deutlich besser. Zusätzlich bietet Apple seit dem letzten Mountain Lion Server Update (Version 2.2) auch den Cachhing Server. Hinter dem einfachen Namen steckt ein sehr Leistungsfähiges Tool: Sobald ein Client im lokalen Netzwerk twas aus dem Apple App-Store herunter lädt (Egal ob Vollversion, oder Update) wird der Download komplett lokal zwischengespeichert. Braucht ein zweiter Client im LAN nun diese Datei erfolgt der Download komplett aus dem lokalen Speicher. Da Apple immer mehr Programme (Auch recht grosse) via App Store zur Verfügung stellt spart das recht schnell enorm an Bandbreite. Und Bandbreite ist auch 2013 immer noch kostbar :-)

Natürlich bietet Apple auch echte Server Basis Dienste, wie DNS und DHCP! Diese sind brauchbar und absolut ausreichend. Zumindest jetzt! Denn mit erscheinen von Mountain Lion Server war das nicht der Fall.

Aber der aktuelle Apple Server bietet natürlich eine ganze Menge mehr: Apache Webserver, PHP Unterstützung und eine PostgreSQL Datenbank! Natürlich kann auch das noch erweitert werden! Neben diverser PHP Module habe ich mir auch noch einen MySQL Server installiert. Damit kann der Apple Server auch als komplette Web Development Plattform verwendet werden. Zumal auch WebApps in Python, Perl und Ruby möglich sind. Einiges bedarf zwar etwas basteln, aber machbar ist es auf jeden Fall! Echtes Hosting kommt bei meiner Bandbreite nicht in Frage, wäre aber sicher auch möglich!

Auch der Zugriff auf Kalender und Kontakte ist ein Traum! Der entsprechende Server Dienst ist einfach zu nutzen. Ich habe es sogar hinbekommen Android Devices mit den Diensten zu synchronisieren. Das macht es möglich auch nicht Apple Geräte einzubinden. Mail ist ja dank Verwendung von Standard Protokollen (POP2, IMAP4 und SMTP) eh kein Problem!

Aber wie von mir bereits mehrfach (in diversen Beiträgen) erwähnt: Wo Licht ist, ist auch Schatten. Leider ist im Fall vom Mountain Lion Server dieser Schatten immer noch recht gross! Das negative Paradebeispiel ist die Dokumentation die Apple auf seinen Webseiten anbietet! Diese Dokumentation ist unvollständig und hinkt dem aktuellen Stand auch deutlich hinterher! Schade, denn das wäre gerade für Einsteiger sicher ein Grund der positiv ankommen würde. Auch der Profilemanager ist hin und wieder echt komisch! Hier bleiben immer mal wieder Aufträge (Push) hängen… Und mit den Informationen aus den Logfiles kommt man der Lösung auch nicht näher, da es keine Dokumentation gibt! Das ist bei vielen der anderen verwendeten Produkte einfacher, denn da gibt es die Hilfe ja über die Community! Das ist beim Profilemanager anders! Schade! In der Vergangenheit haben die Updates auch immer wieder zu Problemen geführt! Apple muss also zeigen, ob sie hier dazu gelernt habe… Was ich persönlich hoffe!

Mein Fazit: Der Apple Mountain Lion Server kommt als Server für Arbeitsgruppen und kleine Teams ganz sicher in Frage! Gerade wenn es darum geht ein private Wolke (Private Cloud) aufzubauen.

In wirklich grossen Umgebungen, mit Multi-Server, würde ich aktuell nur auf den Mountain Lion setzten wenn ich müsste! Gerade beim Clustern von Diensten scheint es auch bei der aktuellen Version noch nicht immer alles ganz Rund zu laufen. Sicher auch ein Grund warum es noch so viele 10.6er (Snow Leopard) und Lion Server da draussen gibt!

Via: Warum OS X Mountain Lion als Server?

[jhochwald]

Zurück auf dem Apple Mountain Lion Server (Repost)

Zurück auf dem Apple Mountain Lion Server

Auch wenn er nicht perfekt ist: Ich bin zurück auf den Mountain Lion Server umgestiegen!

Die aktuelle Version (OS X 10.8.3 mit Server Version 2.2.1) ist besser geworden, sogar viel besser!!!

Hauptsächlich nutze ich den Wiki Server und den File-Zugriff per AFP (lokal) und WebDAV (Remote). Aber seit einigen Tagen nutze ich auch wieder den Mail-Server. Auch wenn Push anders ist (Zumindest funktioniert die schnelle Zustellung bei keinem meiner iDevices! Weder im lokalen WLAN und schon gar nicht Remote, weder in anderen WLAN Netzen noch über 3G) taugt der Dienst. Dank Roundcube kann ich auch Regeln bauen um meine eingehende Mail entsprechend sortieren, was mit mobilen Geräten sehr Hilfreich ist.

Apple Server (Mac Mini)

Die vorhandenen Tools habe ich mir noch etwas angepasst, damit diese besser zu meinen (persönlichen) Bedürfnissen passen: - Amavisd-new: Ich lasse unter alle ausgehenden Mails einen Disclaimer hängen (Pflichtangaben) - Postfix/Amavisd-new/SpamAssassin: Ich lasse natürlich alle eingehenden Mails intensiv auf Spam untersuchen und sortiere diese ggf. entsprechend aus. Und ich bekomme (leider) eine ganze Menge Spam! - Apache: Die Konfiguration habe ich mir angepasst, da die Apple Einstellungen mir an einigen Stellen nicht gefallen haben. - Roundcube: Neben der Standard Installation habe ich noch einige Plugins installiert um mir das ganze etwas anzupassen. Das wichtigste ich sicher ein CardDAV um auch per Webmail auf meine auf dem Server vorhandenen Kontakte zuzugreifen. Das verhindert Redundanzen und die Pflege an x-verschieden Stellen. - MySQL: Neben dem lokalen PostgreSQL habe ich mir noch MySQL installiert (Homebrew). Das macht das testen von Webseiten usw. für mich etwas einfacher. Aber das ist sicher auch ein wenig Geschmacksache, denn PostgreSQL ist sicher ausreichend! - Squid Proxy Cache: Auch wenn Apple das nicht anbietet… Ich finde das lokale Zwischenspeichern von Bilden usw. durchaus Hilfreich. Dank PAC Datei nutze ich das im lokalen Netz auf allen Geräten, was die Performance sicher nicht reduziert!

Server Admin

Über den Profile Server muss ich ja nicht viel sagen: Der ist Weltklasse wenn es um die Konfiguration und Verwaltung von Apple Geräten geht. In meinem Fall mache ich das mit allen iDevices (iPhone und iPad) und meinen Macs. Leider ist hier noch ein Gap: Hin und wieder scheinen iDevices die Verbindung zum Profile Server zu verlieren wenn man ein Update einspielt.

Zusätzlich habe ich die Ruby Installation deutlich aufgebohrt und Redmine installiert. Das nutze ich täglich und ich möchte es nicht mehr in der Cloud haben. Gleiches gilt in meinem Fall auch für die Kontakte und den Kalender (Diese möchte ich auch nicht in der Cloud haben.).

Also uneingeschränkt kann ich den Apple Server nicht empfehlen, aber die aktuelle Version ist wirklich noch mal deutlich besser geworden! Und wenn man etwas Arbeit investiert (Roundcube installieren usw.) kann der OS X Server eine wirklich günstige Alternative sein! Vor allem bei einem sehr guten Preis/Leistungsverhältnis :-)

Roundcube

Wer mehr als einen Apple Rechner hat, dem wird der Cache Dienst gefallen! Gerade grosse Downloads lokal zwischen zu speichern (Beispielsweise XCode) kann sehr hilfreich sein. Der Cache Dienst scheint aber nicht so 100% stabil zu sein. Seit einiger Zeit nutze ich den Software Update Service (SUS) um Apple Updates gezielt freizugeben.

Was ich jedem empfehlen kann: Den Apple Remote Desktop (ARD) sollte man sich auf jeden Fall leisten! Es kann sich wirklich lohnen, denn dann bleibt VNC aussen vor und er bietet eine Menge zusätzliche Features. Wer neben dem Server noch einige Mac Systeme verwalten muss, der wird den ARD lieben! Ich nutze diesen um Software und Daten zu verteilen und auf die unterschiedlichen Rechner (Auch von anderen) zuzugreifen :-)

Jetzt werden sich sicher einige Fragen: Warum steigt er wieder auf den Apple Server um wo er den doch vor nicht anzulanger Zeit so schlecht gemacht hat (Auch wenn es nur die Wahrheit ist/war). Die Antwort ist einfach: Ich habe an einem Server eines Bekannten eine Menge schrauben müssen und da meine Hardware eh da war, dachte ich mir: Komm versuche es doch einfach noch mal!

Via: Zurück auf dem Apple Mountain Lion Server

[practiceofcode]

Updated PostgreSQL backup scripts for 10.8.2 / OS X Server 2.2

IMPORTANT (2013-11-19): All of this has changed in Mavericks / OS X Server 3.x. Each service has its own instance of Postgres. See some of the comments below for the new socket locations.

In Mountain Lion 10.8.2 along with OS X Server 2.2, Apple started employing two separate instances of Postgres, one for the built-in services, and the other for use by custom applications (e.g. Roundcube). My old backup script doesn't properly understand the differences, or the new socket, so I have had to rewrite it. I also quickly banged up a second version that backs up the user databases too.

First, the system databases:

#!/bin/bash backupdir='/Library/Server/Backups/PostgreSQL/'; server_root='/Applications/Server.app/Contents/ServerRoot'; psql_socket='/Library/Server/PostgreSQL For Server Services/Socket/'; day=`date +%u`; mkdir -p $backupdir/$day; echo "PostgreSQL Backup for $HOSTNAME"; echo "=================================" echo `date`; for database in `$server_root/usr/bin/psql -U _postgres -h "$psql_socket" -lt | awk '{print $1}' | grep -vE '\||^$|template|postgres'`; do printf "Exporting $database..."; $server_root/usr/bin/pg_dump -U _postgres -h "$psql_socket" -c $database | gzip -c > $backupdir/$day/$database.sql.gz; /bin/chmod 600 $backupdir/$day/$database.sql.gz; printf "done\n"; done echo `date`; echo; exit 0;

Obviously, update the backupdir to the directory of your choice.

Next, the script to backup any databases you've added:

#!/bin/bash backupdir='/Library/Server/Backups/PostgreSQL/'; server_root='/Applications/Server.app/Contents/ServerRoot'; day=`date +%u`; mkdir -p $backupdir/$day; echo "PostgreSQL Backup for $HOSTNAME"; echo "=================================" echo `date`; for database in `$server_root/usr/bin/psql -U _postgres -lt | awk '{print $1}' | grep -vE '\||^$|template|postgres'`; do printf "Exporting $database..."; $server_root/usr/bin/pg_dump -U _postgres -c $database | gzip -c > $backupdir/$day/$database.sql.gz; /bin/chmod 600 $backupdir/$day/$database.sql.gz; printf "done\n"; done echo `date`; echo; exit 0;

The only difference is that the first script uses a custom socket.

[jimharland]

[practiceofcode]

7-Day Rotating PostgreSQL Backup Script for OS X Server

2013-03-05 Update: These scripts have been updated for 10.8.2 / OS X Server 2.2 in this newer post.

Starting with Lion Server, and now with Mountain Lion Server, Apple has started bundling PostgreSQL for the database backends of services such as Contacts, Calendars, Wiki and Profile Manager. Additionally, it’s kind enough to back them all up into one dump file, typically located at:

/Library/Server/PostgreSQL/Backup/dumpall.psql.gz

Now, for migration to a newer OS or for any similar procedure, it’s a lot more convenient to have separate files for each database. Additionally, I like having a few rolling days of backups, so I’ve written a quick script to accomplish both of those goals.

#!/bin/bash backupdir='/Library/Server/PostgreSQL/Backup/'; day=`date +%u`; mkdir -p $backupdir/$day; echo "PostgreSQL Backup for $HOSTNAME"; echo "=================================" echo `date`; for database in `/usr/bin/psql -U _postgres -lt | awk '{print $1}' | grep -vE '\||^$|template0'`; do printf "Exporting $database..."; /usr/bin/pg_dump -U _postgres -c $database | gzip -c > $backupdir/$day/$database.sql.gz; /bin/chmod 600 $backupdir/$day/$database.sql.gz; printf "done\n"; done echo `date`; echo; exit 0;

I’m using a logical default directory for the backup, but feel to change it if desired. Also, the echo and printf commands are only in there due to the way I include the output of this script into a greater reporting script, so if you don’t need those, feel free to delete them. And lastly, use your own preferred methodology for running the script, but it does expect to be run as root. I recommend using launchd, or just putting a symbolic link to the script in /etc/periodic/daily.