Archive for September, 2007

Safari Shortcuts

Sunday, September 23rd, 2007

Some useful shortcuts for Safari users: Command-N opens a new Window Command-T opens a new tab Command-Option-V – views the page source Command-Up Arrow scrolls to the top of a page Command-Down Arrow scrolls to the bottom of a page Spacebar – scrolls down Command-Shift-+ Zooms in Command-Shift– Zooms out Command-W closes the current tab Command-Q quits Safari Command-M minimizes Safari Command-R reloads a page Command-Shift-H takes you home Command-Shift-D bookmarks the current page Command-K enables or disables the pop-up blocker Command-Option-V views page source Command-Shift-A autofills forms Command-Option-F takes you to the Google box Command-Option-K marks a page Command-} takes you to the next tab Command-{ takes you to the previous tab Command-Option-P returns to a marked page Command-Shift-N creates a new Bookmarks folder Command-[ goes to the previous page Command-] goes to the next page (if there is one)

Migrating CommuniGate Pro Mail Servers

Wednesday, September 12th, 2007

Communigate is a great mail server that is probably one of the easiest programs to move to another server. This is due to the fact that all it’s information is stored in flat files that you simply have to move from one place to another to activate or deactivate. If only Exchange was this easy!

The following is an overview of the steps involved in migrating a Communigate server from one OSX host to another. These are the 3 basic steps

1. Backup the Communigate settings and user databases 2. Install Communigate onto the new machine 3. Unpack and move the communigate files to the appropriate location

Here is a detailed step-by-step way to move a communigate install from one machine to another.

1. On the original mail server open a terminal and become root > sudo su

2. Next we should stop the CGServer so that it isn’t writing to the files as we back them up. Note: those are backticks below NOT single quotes. The backtick is usually left of the number 1 on the keyboard > kill `cat /var/Communigate/ProcessID`

3. Now we backup the files. This command places the archive at the root of the boot drive. > tar -zcvf /CommunigateBackup.tar.gz /var/Communigate

4. Copy CommunigateBackup.tar.gz to the new machine any way you please. I’ll use scp here. > scp /CommunigateBackup.tar.gz 318admin@newmailhost.local:/

5. Go to the new machine, open a terminal, become root and unpack the archive > sudo su > tar -zxvf /CommunigateBackup.tar.gz

6. Install the same communigate version as was on the the old box and reboot. It MAY work without the same version but I don’t recommend it. If you don’t know the version that was running on the old server, maybe it crashed, you can find out by running this command: > grep SYSTEM /Communigate/SystemLogs/* | grep started | awk ‘{print $5}’ | sort | uniq

7. Once the server is installed we should stop it so that there isn’t any file corruption while we restore. > kill `cat /var/Communigate/ProcessID`

8. Now we remove the current empty installation of communigate > cd /var > rm -rf CommuniGate Or if you’re like me and don’t like to rm -rf stuff as root > mv CommuniGate Communigate.old

9. Now simply move the backed up database to it’s intended destination > mv /CommuniGate /var/

10. Reboot and you’re done! You’ll notice that everything copies over, the license, the accounts, the passwords. This can be done in about 15 minutes once you get the hang of it!

Trixbox (previously Asterisk@Home)

Wednesday, September 12th, 2007

First let’s start off with what Asterisk is. Asterisk is an open source PBX (FreePBX) application that can be run on most versions of Linux. It is usually compiled from a tarball, and then configured from there. It allows you to use that Linux computer as a PBX, and add other add-ons as necessary. Without a 3rd party add-on, Asterisk is completely command line driven, and is difficult for most people to administer who are not familiar with command line operations. It allows you to use your current telephone line and/or VoIP for calls.

Asterisk@Home was the package that was on an ISO that you would run to completely reformat your PC and install a ready made configuration of Asterisk for you, with a lot of other 3rd party add-ons to the main Asterisk application. It came with SugarCRM (a client relations management software package), AMP, the Asterisk Management Portal, which allowed you to interact with Asterisk realtime, and without knowing too much about the scripting and command line aspect of Asterisk, and built in IVR (Interactive Voice Response), that allowed for greetings, timed greetings, menus, extension options, etc.. It ran on the CentOS flavor of Linux.

Trixbox version 1.0 was released (and would have been Astersik@Home version 3.0), on May 31, 2006. It still retains the previous add-ons, plus a lot more, and still runs on CentOS. The name was reportedly changed due to the moniker “@home” possibly causing an image that didn’t sit well with its potential business class clientele.

Trixbox is based on the same code as Asterisk@Home, and works with the Digium hardware, that allows you to use FXO cards for POTS lines, or FXS cards for plain old telephones inside the business or household.

Trixbox is considered “turn-key” software because of the low amount of configuration required to get it running, when compared to Asterisk proper. Trixbox can be used with standard telephone lines (POTS) or separately or in conjunction with VoIP.

Some cool features with Trixbox:

For the home user, you can have extensions at home that will ring your computer with the use of softphones You can have your softphone on your laptop and use it to receive and make outgoing calls at any hotspot (Trixbox will direct your call to you appropriately) to any phone number You can have “Bluetooth Proximity Checking” setup and enabled. This will allow Trixbox to determine if it should route calls to your desk when you are within range, or to your cell phone when out of range With the proper amount of storage, you can record outgoing and incoming calls, or only specific calls Video phone calls (using softphones) More information on Trixbox can be found here:

Information on VoIP in general can be found here:

Preparing FileMaker Databases for Backup By An External Backup Agent

Tuesday, September 11th, 2007

First and foremost, it must be clear to the person building the system that FileMaker MUST back itself up. Depending on the version of FileMaker being used, this is done in the FileMaker Server Admin. Therefore, when final, the steps for a backup will be:

1. The FileMaker Server backs itself up to pre-determined folders in the folder structure of the server. This allows to folders that are NOT in use when the external backup agent runs. In addition, this allows the architecture of highly specific and timely backups of the database.

2. Using the destination folders for the backup performed by FileMaker as the source, we will use the backup agent on the server (Retrospect, Veritas,, etc) to move that data to the onsite backup drive and therefore be folded into the general machine backups.


Backups of the live database will be done using FileMaker Server Admin. Connect to the server, and then choose ‘Schedules’ in the icon list.

From this screen, we will be creating our backup times and choosing the folders to backup to. While this window is open, you should also choose a default folder for the backups to be stored. This does not need to be in any particular location for technical reasons, but the 318 standard is:

/server HD/Library/FileMaker Server/Data/Backups/

This default backup location can be specified in the Configure > Default Folders area. Once specified, that will be the default location for all the backups built in the Schedules area.

To create a new Schedule entry for backup, click New (bottom right). Typically, these databases are backed up at hourly intervals throughout the day, daily through the week, and then with backups on individual days of the month. This tiered approach allows the database to be rolled back. In the event of unrecognized data loss for a period of time, you can roll a database back a number of days, weeks, etc and reconstruct your data.

With regard to the logistics of building such a tiered topology, it is typically easiest to use the Default Backup Folder (specified above) as the root of the backup directory and create subfolders within that directory. That is, if the server will be backing up in 2 hour increments from 6am until 10pm, you should have folders named 0600, 0800, 1000, 1200, 1400, 1600… 2200. Using a 24 hour clock time removes the need for AM/PM specifications. Similarly, when creating the daily backups, folders should be named 01-Mon, 02-Tue, 03-Wed, etc. Depending on the specific topology, these folders can either have the hourly folders in them, if it is necessary to keep a full week of hourly backups. The specific organization and scheduling is always going to vary based on the client’s specific needs.

Once the logistics of the backup plan have been worked out, create the necessary subfolders in the Default Backup Folder. At that point, you have the folders in place to create the Schedule items that will populate those backup folders with data.

When the Schedule in FileMaker is complete, there are a number of things that need to be done to ensure that the backups can run properly.

1. Verify permissions on the backup folders. The group should be fmsadmin, with full control. This ensures that the FileMaker Server will be able to back itself up to the backup folders.

2. Build an exception in the external backup agent (Retrospect, Veritas, etc) that protects the live database from any scanning by the external backup agent.

3. Verify the backups are running properly. As with any backup solution, you must ensure that the backups are actually firing. Make sure that the backups are showing up in the correct folders, and that the date and time stamps are accurate.

4. Configure the external backup agent to use one of the backups in the FileMaker Default Backup Folder as the source for the scripts that will provide onsite and offsite backups. Typically clients keep the final hourly backup for the day as the daily backup, however this can be changed based on the specific topology.

* A note about using .Mac Backup, iDisk syncing, etc. The purpose of backups such as these are to keep a single iteration of the database backed up offsite immediately. This is the backup that we would rely on to have more recent information than the last physically rotated offsite backup. That said, there are many difficulties that come hand-in-hand with using a remotely mounted volume for such tasks. The primary obstacle is that .Mac does not support a duplicate type of script, only incremental backups. This means that the most effective way to keep the database uploaded without filling the iDisk in 2 days (DB ~ 500Mb, iDisk = 1Gb) is to turn on iDisk syncing in the System Preferences. This will keep a local copy of the iDisk on the desktop to be the destination of a Retrospect (,etc.) script and then use its own syncing daemon to automatically push the contents of the backups in the local iDisk up to the .Mac servers.

Fining Mac OS X Server’s Serial Number

Monday, September 10th, 2007

In Mac OS X Server, the serial number can be viewed by opening the Server Admin utility. However, if the service for controlling this utility is crashed or the Server Admin Utility does not launch, you can browse the serial in the following file path:


This information can be handy if you need to reinstall the OS but need to know the serial number before doing so.

Installing Mac OS X Server 10.4 On A Mac Mini

Friday, September 7th, 2007

Retail copies of Mac OS X Server 10.4 (for PowerPC-based Macs) and Mac OS X Server 10.4.7 Universal (for PowerPC-based and Intel-based Macs) can be used to upgrade Mac OS X 10.4.x client installations to server installations. The process is a “Meta-package” upgrade and is described in this article.

Performing a Meta-package upgrade on Mac OS X 10.4.10 or later clients

Mac OS X Server 10.4.x (PowerPC or Universal) install discs cannot perform a Meta-package client upgrade on clients which have already been updated to Mac OS X 10.4.10 or later.

To workaround this issue, download MacOSXServerInstall.dmg. The package can be downloaded here. The requirements and installation process to use MacOSXServerInstall.dmg are detailed below:

Requirements -A Mac with Mac OS X 10.4.10 or later (client) installed that you wish to upgrade to -Mac OS X Server 10.4.x. -Mac OS X Server 10.4 installation DVD (to upgrade PowerPC-based Macs). -Mac OS X Server 10.4.7 Universal installation DVD (to upgrade Intel-based Macs).

Installation 1. On the client computer you will be upgrading, download MacOSXServerInstall.dmg from here. 2. Double-click the downloaded MacOSXServerInstall.dmg file to mount the disk image in the Finder. 3. Insert the appropriate Mac OS X Server installer disc. 4. Double-click MacOSXServerInstall.mpkg in the Mac OS X Server Install window. 5. The installer will confirm that you have the appropriate Mac OS X Server installer disc mounted. 6. Follow the instructions presented in the installation window.