StockholmOpen.Net software archive

 - home page
 - comparison


 - current release
 - old releases
 - view CVS


 - manual [pdf] [ps]
 - FAQ
 - slides [tar]
 - mailing list
 - Installation instructions


 - CVS access
 - mailing list


 - StockholmOpen
 - AP Status
[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3. Step-by-step installation instructions

This is a step-by-step guide for installing the StockholmOpen.Net system. It is assumed that the reader has knowledge of Un*x administration in general and Un*x networking in particular. Installation of the StockholmOpen.Net system is more of "plug-and-pray" than "plug-and-play" right now.

  1. Choose machines

    Choose what machines should run the configuration services (BOOTP relay agent, MAC database and registration). Choose if the access server and firewall should be colocated in the same machine. A tip is to start with one machine for access server and firewall if you're not sure you will need them separated (perhaps you're using a Ciso router?). They can easily be separated later.

  2. Setup the common configuration services:
    • On the configuration machine, install a PostgreSQL database and run the initialization script (with your modifications) according to the instructions at 2.3 Setting up the MAC database.

    • Download and unpack the DHCP 3.0 sources from ISC. Patch and install the relay agent according to the instructions in 2.1 Design of the relay agent.

      The relay agent machine needs one additional interface for each operator present in order for the DHCP server to accept the request as authoritative. These interfaces should be aliases and assigned an IP address belonging to the operators subnet. In Linux aliased interfaces can be created with ifconfig eth0:0 10.0.0.1 (the first alias, starting with 0, for interface eth0).

    • Install a webserver (eg Apache) with PHP support and the relay web pages. Edit the settings in config.php. PHP should be compiled with PostgreSQL support.

  3. For each upstream provider:
    • Download and install the oasis access server. Configure and build it according to 2.4.3 Compiling oasis. Configure oasis: 2.4.4 Configuring oasis.

    • Edit the firewall script. By default it is located in /usr/local/sbin/oasis-firewall-sample. If the firewall is colocated with the access server (ie, local access to the firewall), the sample script will probably work fine (assuming you use iptables), otherwise use your imagination (SSH could be used to securely control a remote PC-based firewall, in which case you must set up public keys appropriately for automatic root access).

      In the reset section you might want to include static rules for access to an upstream DNS and other services that should be provided before authentication.

      The default firewall script includes redirection to a local webserver for unauthenticated users. If you decided to separate oasis and the firewall this will not work directly. Install a simple webserver on the firewall that issues a http redirect to the oasis web server.

    • Start oasis and test it with the included client program. It's available in the src subdirectory in the source distribution.

    • Download and install an SSL secured web server (eg Apache-SSL) with PHP support. Use the PHP web pages from oasis (by default installed in /usr/local/var/www) and tailor it to your taste. They are quite minimal in order to make it easier to modify the design/layout.

    • Configure the authentication backend. PAM is used for this and by default the PAM service in the oasis configuration file is set to "login", ie local UNIX authentication (using /etc/passwd). You might want to use some other authentication machanism such as Kerberos or RADIUS. Install the PAM module (usually under /lib/security) and create a PAM configuration file for oasis.

      Assuming you name your PAM service "gazonk", create the file /etc/pam.d/gazonk with the following contents for a Kerberos service (a Kerberos 4 PAM module is available at http://software.stockholmopen.net/):

      auth required pam_krb4.so MY.REALM

      Then point oasis to this PAM service by setting pam-service in the oasis configuration file to "gazonk". Now oasis will use the PAM rules in /etc/pam.d/gazonk when authenticating users for that domain. You can have different authentication mechanisms for different domains.

      PAM is very flexible. For example to use an existing Kerberos database but only allow a subset of the users in the Kerberos database, one can use the following in the PAM configuration file:

      @verbatim auth required pam_listfile.so onerr=fail sense=allow item=user file=/etc/userlist auth required pam_krb4.so

    • Make sure there is an entry in the PostgreSQL database (in the T_provider table) for this provider.


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated by Martin Hedenfalk on May, 2 2002 using texi2html