Chapter 4. Basic System Configuration

Table of Contents

4.1. Adding a regular user
4.2. fstab
4.3. Email delivery for system notifications
4.4. Network interfaces
4.4.1. Internet interface configuration
4.4.2. LAN interface configuration
4.4.3. Hostnames
4.4.4. Bringing it all online
4.5. Secure Shell daemon
4.6. Network Time Protocol daemon

4.1. Adding a regular user

Logging in as root is fine for doing quick configuration work on the console, but it's a good idea to have a non-superuser account for other purposes, or for logging in with Secure Shell (as will be described in Section 4.5, “Secure Shell daemon”).

Type the command adduser on the shell and follow the prompts to interactively configure a new user account. Be sure to change the user's login class to "staff", and add the new user to the wheel group when prompted for additional group memberships. Next, uncomment the line in /etc/sudoers (using visudo(8)) which provides all members of wheel with sudo(8) privileges:


4.2. fstab

In order to prevent unnecessary writes to the CF card, add the noatime option to all the partitions listed in /etc/fstab, as follows:

/dev/wd0a /     ffs rw,noatime              1 1
/dev/wd0g /home ffs rw,nodev,nosuid,noatime 1 2
/dev/wd0d /tmp  ffs rw,nodev,nosuid,noatime 1 2
/dev/wd0f /usr  ffs rw,nodev,noatime        1 2
/dev/wd0e /var  ffs rw,nodev,nosuid,noatime 1 2

You will need to reboot the system to bring this change into effect.

4.3. Email delivery for system notifications

In BSD it is customary for the system maintenance cron(8) jobs to email the root user account with regular status reports or notifications of certain conditions. If you will primarily be logging into the system with the non-superuser account created in Section 4.1, “Adding a regular user”, it would therefore be convenient to have root's email forwarded to this account.

To achieve this, create a file /root/.forward like the following, substituting your own username for "mshroyer":


4.4. Network interfaces

4.4.1. Internet interface configuration

With OpenBSD up and running on the ALIX board, it is time to set up basic Internet connectivity by establishing a PPPoE connection with our DSL provider. OpenBSD provides two means of establishing this connection: there is the highly-configurable pppoe(8) userland daemon, and the less flexible but lower-overhead pppoe(4) kernel driver. Features offered by pppoe(8) – but lacking in the kernel driver – include automatically adding PPPoE-specified DNS servers to /etc/resolv.conf and mangling the MSS of TCP packets to accommodate the PPPoE MTU bottleneck. However, we will be running our own DNS server on this device (making the servers specified by the PPPoE server irrelevant) and PF can perform the necessary MSS mangling on its own, so in our case it will be simpler to use the kernel PPPoE driver.

First, select an Ethernet interface to serve as the router's PPPoE interface to the DSL modem. You will not need to assign an IP address to this interface, but it will need to be brought "up" by ifconfig(8). Supposing that you will use the interface vr0 for this purpose, create a configuration file /etc/hostname.vr0 with the following single line:


Next, create a PPPoE configuration file /etc/hostname.pppoe0, which will contain the settings necessary to connect to your DSL provider. Enter something like the following, replacing the strings YOUR_USERNAME and YOUR_PASSWORD with your actual PPPoE authentication tokens for your ISP:

inet NONE \
    pppoedev vr0 authproto pap \
    authname 'YOUR_USERNAME' authkey 'YOUR_PASSWORD' up
!/sbin/route add default -ifp pppoe0

4.4.2. LAN interface configuration

Since our consumer DSL Internet connection only affords us one public IPv4 address, we will of course be putting our LAN behind a NAT, on a private (RFC 1918) network block. Setting up packet forwarding and the NAT will be covered in a following section; but first, let us bring up the router's LAN interface.

Assuming you will be using the ALIX's vr1 interface to connect to the LAN, create the interface configuration file /etc/hostname.vr1 with the following contents:

description " LAN"

4.4.3. Hostnames

Enter the full system hostname as a single line in the file /etc/myname:

Also, place lines like the following in /etc/hosts so that the system can resolve its own hostname without relying upon DNS:

::1    localhost localhost
::1    midgard midgard

4.4.4. Bringing it all online

Now that your configuration files are in place, run OpenBSD's netstartscript to put them into effect:

# sh /etc/netstart

After the script has run, use the ifconfig(8) command to verify that all configured interfaces are up, and that the interface pppoe0 has authenticated and acquired an IP address from your DSL provider.

4.5. Secure Shell daemon

In Section 3.3.1, “Basic setup” we specified that the Secure Shell daemon should run at boot time. However, there are some optimizations that we can make to the daemon's configuration which should increase our system's overall security, for instance preventing root logins and accepting only public key authentication. Implement these changes by merging the following configurations into /etc/ssh/sshd_config:

PermitRootLogin no
AllowUsers mshroyer
StrictModes yes
RSAAuthentication no
PasswordAuthentication no
ChallengeResponseAuthentication no

Make sure that ~/.ssh/authorized_keys contains the public keys for the keypair(s) you intend to use to log into the router, so that you will still be able to log in once password authentication has been disabled, then send the Secure Shell daemon the SIGHUP signal to force it to reload its configuration file:

# kill -HUP `cat /var/run/`

4.6. Network Time Protocol daemon

OpenNTPD allows us to keep the system clock synchronized with accurate Internet time servers across the world, and to provide similar time service to the local network as well. During the system installation we configured the NTP daemon to run at boot; now we need only specify which servers it should query for the time, and which other machines it should offer service to. Edit the file /etc/ntpd.conf as follows:

listen on *

By allowing the daemon to listen on all network interfaces, you are making it available to the entire Internet. In theory this represents a potential security vulnerability, but OpenNTPD is cleanly implemented and runs with minimal permissions, so the potential for exploit is probably negligible. And by configuring this so, you will be able to keep any laptops synchronized with your home NTP server while you are away.

Kill and restart ntpd(8) to load the new configuration.