wiredfool

The Problem

On Osx, Frontier runs as a user process, not as root. Therefore, it can’t bind to ports below 1024. We have been using port forwarding to forward low numbered ports to high numbered ports. This is a manually maintained script that resides in /Library/StartupItems/Multihoming/.

There are 2 major drawbacks:

• It is manually maintained, and I’m tired of doing that for complicated systems.
• There is an issue with loopback tcp where either the operating system or applications that don’t know about port forwarding assume that [publicip]:port is equivalent to [loopback]:port. If frontier can parse the forwarding data, then it can do the right thing. We are seeing this with xml-rpc requests from instance to instance.

Proposal

Automated Maintenance

There should be a frontier tool that can make the Multihoming directory, write all associated scripts, and add a file with its information into a subdirectory of the Multihoming startup item. Sudo should be used as necessary to write the config files, but the datafiles should be writable and readable by user processes. A sudo execution shall not be necessary for frontier to read this data. The port forwarding script will have to be run as root, so it should be triggered by a menu item or run from the command line.

The datafiles should be text files that are named for the ip address being forwarded and one line per port forward request, source port [space] destination port. Lines should be written in unix native format. Comment lines are delimited by #. The multihoming script should ensure that all ip addresses referenced are aliased to en0. (Aside, should there be seperate configuration directories for en0,1,2?)

Configuration data should be stored in config.root.

Loopback Bug Fix

When Frontier starts up, and every so often thereafter, it should read the datafiles and parse them into an internal structure. When making a tcp connection, Frontier should examine this structure and determine if the connection end point should be rewritten to a local high port. This change will probably make sense in tcp.httpClient, but could also be added to tcp.openStream and tcp.sendMail. This should handle communication between one frontier process and other processes on the same machine.

There should also be recognition of the apparent ip address of the http inetd listener so that communication within frontier correctly intreprets if the request is loopback or not. I propose the following:

1. request port == apparentPort and request ip == apparentIp -> process internal loopback
2. request port == port and request ip == loopback -> process internal loopback
3. request port == apparentPort and request ip == apparentIp -> process internal loopback
4. request ip, request port are forwarded -> machine loopback to target port.