Paul Lynch's Pages

One of the small advantages of running MacOS X is the ability to refer to machines that aren’t represented in (a static) DNS and have dynamic IP address by a simple name. Now that we are moving away from a FreeBSD/Solaris server setup to a MacOS X one, there is still some advantage to using cheap disposable Linux servers. So how about Zeroconf names for Linux?

It turns out to be easier than I feared. I was expecting the usual Linux mess of inconsistent standard support with the resulting incomprehensible configuration script, but the Apple team have done a great job.

If you want to install Bonjour on your Linux (or BSD) server, read on.

Apple’s Bonjour developer page links to the source code for the latest stable version, or you can grab a copy from CVS. Either way, you will need an Apple id and to sign their license agreement.

I downloaded to my PowerBook, and used scp to copy the tarball over to my Asterix (Linux) server. Open the tarball, and cd into the Posix directory (cd mDNSResponder-107.1/mDNSPosix).


make os=linux
./build/prod/mDNSClientPosix
^C
make os=linux install


End of story. Reboot to make it active, although you could start it without rebooting (I like to confirm that the boot process still works correctly when adding a service). There are a couple of man pages: libnss_mdns, nss_mdns.conf, but there is nothing that you need to configure if all you want is the hostname support.

Going any deeper into zeroconf means that you need to add some support code into your apps, so refer to the documentation pages for that.

This card has the benefit that you can connect an analogue phone as an extension, and supports UK caller id in the main Asterisk source without any patches.

If you only have a X100P card, you can still connect an analogue phone, but not as an extension. By plugging it in with a splitter connector alongside the PBX to the main line, you can either pick up calls on the PBX, or on the analogue phone. This works, but isn’t great. If you have fax detection enabled, it will be immediately picked up by the PBX, so that it can analyse the signal, so this won’t work. But with fax disabled, you get a few short seconds of the analogue phone ringing before the PBX extensions start to ring. The TDM400P card will allow you to directly connect an analogue phone to the system, bypassing these problems.

It is also possible to get UK caller id to work on the X100P card (if you don’t need the analogue extensions), but you have to use an unsupported patch.

The TDM400P card is a pain to install. The X100P is very deceptive, as it is extremely forgiving and seems to work anywhere. The 400, however, requires PCI 2.2 support from your motherboard. Older machines are unlikely to have this, but you may get lucky. You also have to have a spare power cable to attach to the card. The external connectors for phone lines are RJ-45 (yes, network connectors), but US phone cables will plug into the centre of these connectors and will then work.

If you have installed the card and it doesn’t work, you can tell because the green connection lights on the back of the card will not light up, and it won’t be recognised by the driver system (assuming that you are using asterisk@home). The normal routine when changing cards is to run:

genzaptelconf -s -d

After doing this, you will want to re-edit /etc/zaptel.conf for country settings.

Depending on which route you take, you will need to edit the zaptel configuration files:

/etc/zaptel.conf:
loadzone=uk
defaultzone=uk

For the TDM400P, /etc/askerisk/zapata.conf (I still need to confirm that this really works):

usecallerid=uk

For the X100P patch, you want instead in zapata.conf:

usecallerid=yes
cidsignalling=v23
cidstart=history

Some articles on DSL, Asterisk and configuring DNS on MacOS X Server.

Is a very impressive software system for making a phone switchboard. The core software is Asterisk, which can be installed under various forms of Unix, including Linux and MacOS X. It supports the SIP protocol for network phones, various Digium cards for analogue phone line and analogue phones, and understands VoIP.

There is a substantial industry of software produced around Asterisk, and some of this is collected into a released known as ‘Asterisk @ Home’. This is a full package of some release of Linux (CentOS), with a text to speech package (Festival), AMP (Asterisk Management Portal, a configuration UI), FOP (Flash Operator Panel, a flash based monitor), a CRM package (Sugar), and various other tools.

The advantage of A@H is that most of the initial work of configuring Asterisk to create a workable PBX is already done for you, with various line configurations already made, including a full voice mail menuing system, talking weather reports (for New York only, but customisable for any major US city), music on hold, fax support – and etc.

Installation is like any Linux; download an iso image, burn it to CD (this is very simple on MacOS X, just fire up Disk Utility (which will probably come up automatically when you insert a black CD), select the iso image in its browser, and click on the ‘Burn’ button.

Insert this CD into a PC, and boot it. This process will reformat the hard drive. Back track for a moment: if you want to connect your switchboard to an analogue line (or ISDN, for that matter), you will need to buy a PC card. Because the authors of Asterisk (the base package, not A@H) are Digium, they support cards using the Digium chipset. For testing or simple installations, the Wildcard X100P is very cheap (around £10), and lets you receive and make calls on a standard trunk line. If you want to connect your current analogue phones to the PBX, then a more expensive card, the Digium TDM400P is required, with at least one FXO mini-card (for the external line), and at least one FXS card (for your internal phone or phones) installed. The TDM400P can take any combination of up to 4 cards. Our TDM400P, with one FXO and one FXS, cost £146 (inc VAT). Both cards were sourced from eBay vendors.

You need to have the card already installed in the PC before installing A@H (I didn’t when I first did this, and ended up reinstalling as the fastest way of getting running).

When the machine has finished installing CentOS, it needs to reboot to build Asterisk; this can take a little while. I found this process faultless, provided I had the Digium card pre-installed.

You should then log in to the system and set passwords. Do not connect to the Internet until this is done. The MOTD will be set to some useful hints, including the advice to type help-aah. You may need to set the time zone, configure the network interface, and you must set the root and admin user passwords and web maint passwords.

After that, you can connect to the web server on your PBX, and enter AMP. Select ‘Setup’ from the menu, and add an extension – I used a copy of X-Lite that I downloaded. The AAH handbook gives instructions on configuring this soft phone. You should also check the AMP Setup->General Settings and Incoming Calls pages. Everything else should already be configured to place a call.

Check the AAH handbook for useful PBX commands, and remember that it is 9 for an outside line now!

You will probably want to check out the rest of the information in the handbook to configure your Digital Receptionist, and perhaps to install any VoIP accounts that you have, but the above was all I needed to get started.

I set up two different ring groups, one work, one home, and configured a virtual extension to handle group office voice mail. The ring groups are set to transfer on no answer to the voicemail of the virtual extension, and that has the message set to our standard ‘out of office’ message. That replicates our previous voicemail system using BT services.

Our existing server environment is getting old, and with changing requirements, is getting harder to maintain. Time for a change!

Starting from the outside in, the router connects to a firewall, which is an old box (an AST) running FreeBSD. Inside that is an Airport, which is used to partition off all the workstations and personal machines, and our remaining server.

The primary server handles mail, DNS and doubles as our CVS repository, which needs to have external access. This is a very old custom assembled PC in a large tower case, running FreeBSD. Upgrading new versions is a bit of a pain, as several services need to be reviewed and upgraded for new features at once – notably the mail service, which hasn’t kept pace: no SSL login, no webmail, minimal spam filtering. It also runs a nightly network wide backup to tape.

We have two ‘production’ web servers: the main one is an oldish Sun Ultra 5, running Solaris with WebObjects 4.5 installed and OpenBase. This holds our main company web sites, including our Mesa license server (both the shopping cart application and the internal use licensing databases). The next web server is used for personal sites, and is a mid-era iMac (graphite); it runs WebObjects 5.2 and OpenBase, and is used for a couple of old WebObjects content management applications that should really be converted into blogs. It also runs blosxom for blogs (this one comes to mind, while it is still there), and a PHPbb, which means also MySQL, all for internal use.

Another web server is used for fallback, rapid deployment of test WebObjects applications, hosting for clients (which is usually an emergency service), etc.

We moved over to this system round about 1997, from a mainly NeXT based server structure, and it has worked reliably since then – with several hardware changes, mostly upgrades rather than failures, along the way.

This configuration gives me several worries – although it does run very stably. As already mentioned, upgrades and adding new required functionality is troublesome. Then if either of the three main servers suffer a hardware failure, replacing them will be time consuming, as well as a high priority task. I don’t necessarily have instant memory recall of what is required to rebuild any of them, either at the system software level, or in terms of my own data and applications. It isn’t as simple as just restoring from a backup.

Effectively, our site functions, despite being on three boxes, represent a single failure point.

My solution is to merge all the functions under MacOS X Server, using the ‘easy’ administration tools to allow me to easily upgrade and add new functions. At first, I was considering an XServe, but that is still a single point of failure with significant replacement time involved. However, the Mac Mini has sufficient power for the tasks required, and is significantly cheaper than the XServe (because it is a lot less powerful, there are good reasons for the price difference), sufficiently so that buying two of them isn’t an issue. One disadvantage of this is that the Minis only have a single network port, and so I won’t be able to migrate the firewall onto the Minis as well. Frustrating, but not unreasonable.

I intend to keep both with identical configurations and data. In MacOS X Server, there is a fallover option whereby a backup machine can quickly take over a main servers IP address – but I suspect that I don’t need to use this, I will investigate later on. If a failure occurs, we can manually switch over fast enough to keep me happy. The only worry then will be the risk of a second failure within Apple’s normal (slow) delivery times.

My switch over plan is to configure one Mini to handle DNS and mail, then swap it in for the old main server, which will suffer a name (and IP address) change. If that goes well, then I will fold in the web sites, coping with an upgrade of the main applications to WebObjects 5.2 along the way (the apps have already been upgraded, but the server hasn’t).

I will document whatever is required to make MacOS X Server work productively, and will stick to basic admin applications if at all possible. I can already see that DNS requires more effort to maintain than ‘classic’ DNS configuration files, and switching from blosxom to blojsom may be quite intensive.

Backup strategy will change to a manually driven ‘burn a DVD’ process, as well as the network backups between the two Minis.