TechComm Labs

As an approach to network administration, eBox is intended for those who don’t want to gain the expertise or spend the time needed to understand all of the nuance and interrelationships between services of a modern office network server. There are two basic approaches to simplifying things like this. One is to handle interdependencies automatically and the other is to depend upon a standard model or template for the system. eBox has a lot of work to do in both of these areas.

The sales pitch for eBox does not clearly indicate that its standard model is a server with two interfaces, each on its own network. In the eBox network settings, the interface with the ‘external’ box checked serves what is usually known as the WAN (wide area network) side that is attached to the I’net. The interface without this ‘external’ box checked is for the LAN (local area network) side. In the standard eBox network model, the eBox machine provides many services that are usually provided by standalone NAT router devices. See the eBox Network Scenario.

In the first scenario eBox is placed between your router and your local network. In the second one, eBox is installed just like another machine in your network. The latter has some limitations as we explain later.

Many micro businesses and home based businesses have a modem that connects to the broadband service, usually DSL or cable, provided by an I’net service provider. This connects to a NAT router that will have several ethernet ports and perhaps a wireless network that services the local machines. These NAT routers can run from well under $40 to several hundred and provide services such as network address translation, firewall, DHCP, and DNS configured by a web based interface. They are standard ‘off the shelf’ appliances that work very well for the basic WAN to LAN interface. If you set up an eBox machine that is a peer under this router with the other local machines, its capabilities become limited due to its model and that model’s necessary interdependencies.

The key here is whether to model is based on the assumption in between the source and destination of network traffic or just sitting in the network providing services to its peers. The eBox model is mostly based on the presumption of throughput.

Services that are strictly for a LAN, such as file sharing and user definition can avoid any interaction with upstream firewalls and traffic controls. Services like traffic shaping and load sharing seem to need to cooperate closely with firewalls yet eBox does not appear to define this interaction for the user. Then there is the proxy service which lists a dependency upon the firewall yet has no obvious need for that dependency. This is a state of confusion noted in the Firewall rework discussion.

The firewall module is one of the most criticised and controversial parts in eBox. Abstracting the firewall configuration is a tricky work, we tried our best, and it seems our approach can be improved.

It appears that eBox is rather young. It does not yet have the service coverage that its competitors like Webmin do, partly due to its primary feature of automatically managing interdependencies between services. This automation feature is perhaps also a reason why flexibility in configuring services like file sharing and web services is limited. A conservative approach to management of interdepencies is also why users may find the feature set restricted in ways that make like difficult for them, especially if not adhering to the network model presumed by eBox developers.