Frontier/OSX Server Management
***in progress. Please don’t link until this notice is removed.
Taken in part from a series of my posts to the frontier-osx discussion group, updated to current practice. This is the collected knowlege of running several Frontier/OSX servers for the last 6 months. The servers run the gamut from Manila/Apache machines to heavily loaded app servers running custom web apps.
System Coordination
The idea behind system coordination is for individual frontier installations to be as independent from each other and portable from machine to machine as possible, so that any two installations could reside on the same physical machine if necessary.
Due to Frontier’s dependence on absolute pathnames, all of the installations need to have consistent but different paths. My setup has a partition creatively named ‘Frontier’ on each machine, with all of the installations having a recognizable name within that (I.e. BetaOSX, DeployOSX, etc.) The frontier executable in each folder is renamed to correspond to the installation, without special characters or spaces. This allows for easy starting and stopping of each instance from the command line. (e.g. open /Volumes/Frontier/BetaOSX/betaosx opens my beta instance.)
– or how we don’t need to be root
-email, apache, bind?
Backup Strategies
I backup frontier installations, but not the os. I believe that the combination of moving installations from machine to machine and relatively quick OS installs makes OS partition backups unnecessary.
My webapps use enough memory that Frontier needs to be restarted on a daily basis. On older machines, some of the images use enough space that additional copies of all of the guess databaese aren’t feasable. Backups are done with the following
- Frontier is asked to save all it’s databases and quit, via an XML-RPC request.
- After Frontier quits, rsync is used to copy the databases to a backup server.
- Frontier is then restarted using the open shell command.
The downside of this approach is that there is some unnessary downtime while the databases are copied to the backup server. Using rsync reduces the downtime below what would be necessary using a straight frontier copy by a factor of 2 or more in my tests. On the other hand, only one copy of the databases is required on the machine, and since Frontier is not running at the time of copy, you are gauranteed that the databases will be in a consistent state in the backup.
I have found on my servers that Manila only installations do not need to be restarted every night. Memory usage on these apps approaches a steady state after several days of usage. This may indicate somewhat lightly loaded systems, but they’re stable so I don’t worry to much about it.
I am using a modified version of the mainresponder guest database backup script that keeps exactly one complete copy of all the databases in the backups folder. A callback after this runs triggers rsync to copy the databases to the backup server.
System Monitoring
– is it down
– have you hit the tcp bug? No comments