User choice

Many other Internet server and gateway systems currently available require the use of specialised hardware, either in the form of a vendor-supplied special-purpose box (as in the Cobalt Qube) or by limiting the range of supported hardware.

Similarly, some systems provide for only a limited range of Internet connection types, network services, etc.

One of the aims of the e-smith server and gateway is to handle as wide a range of configurations as possible:

• Almost any commodity Pentium-grade PC

• Wide range of network cards

• Dialup, DSL, cable, T1, PPPoE...

• Permanent connection or not

• Permanent or dynamic DNS

• A range of Dynamic DNS providers supported

• Any kind of service or application (provided someone makes an e-smith contrib module for it)

While some of these options are not formally supported, all of them can be made to work on the e-smith server and gateway platform, and users are actively encouraged to tailor the system to suit their own needs, and to contribute any improvements back to the project.

Policies, not individual config files

One of the ways in which the e-smith server and gateway differs from webmin or many other web-based system administration tools is in the way it allows administrators to set general policies for the server rather than individual configurations for each application.

For instance, an i-bay which is configured for use on the organisation's intranet will automatically cause appropriate configurations (i.e. no access from outside the local network) to be generated for Apache, ProFTPd, Samba, etc.

Coherent modularity

The overall design of the e-smith server and gateway can be described in two words as "coherent modularity".

The system is designed to allow the installation of add-on/contrib packages via RPM. However, these packages all appear in a consistent manner in the e-smith manager, by providing a "panel" (effectively a web page (or set of web pages) embedded within the framed interface) as part of the package. These panels maintain a consistent style, and appear to the user as a coherent whole.

As simple as possible, but no simpler

The design of the e-smith server and gateway shows a definite tendency towards simplicity. Wherever possible, functionality is implemented using simple techniques easily understood by programmers of less than wizardly skill.

For instance, the core configuration is stored in a single text file in the following format:

AccessType=dedicated
ExternalDHCP=off
ExternalNetmask=255.255.255.0

This is parsed by simple Perl code that anyone could understand, rather than using a more complex (and more failure-prone) database, registry, or other form of storage.

The rest of the system is similarly simple to understand; in fact, the key concepts are documented on the developer website in a document only 8 (printed) pages long.

While it is not the purpose of this paper to reiterate that document, the following brief list of concepts demonstrates the application of the "KISS" (Keep It Simple, Stupid) principle within e-smith.

• Master configuration file: as described above, the master configuration file contains information related to system-wide settings and policy decisions.

• Account file: Information about accounts on the system is kept in a similar file, /home/e-smith/accounts. This contains more information than /etc/passwd would normally contain, including such things as email forwarding, groups belonged to, etc.

• Configuration templates: Templates for all the configuration files normally found in /etc are kept in /etc/e-smith/templates. These are parsed using Perl's Text::Template module, which parses template files like the following example, interpreting anything inside braces and putting the returned value in that place.

  search { $DomainName }
  nameserver 127.0.0.1

  Text::Template can also loop through arrays of data, or interpret other Perl code within the template.

• Events: An event is typically triggered by the submission of a form in the e-smith manager. Events include:

  • console-save

  • ibay-create

  • ibay-delete

  • ip-change

  • manager-misc

  • post-install

  • user-create

  • user-delete

  Each of these events is represented by a subdirectory under /etc/e-smith/events, which contains symlinks to each of the actions to be triggered by that event.

• Actions: Actions are triggered by events. Each action is a Perl script stored in /etc/e-smith/events/actions. Examples of actions include:

  • conf-dialup

  • conf-servers

  • create-ibay

  • create-user

  • rebuild-ldap

  • restart-servers

  • update-dns