Setup I use:

- CPU: Intel Pentium-I 233MHz
- RAM: 128MB
- HD: 10GB, 15GB
- FD: 1,44″
- NIC: Realtek 8139, 3Com 3c905 100Base-TX

A log file of the installation process of OpenBSD 2.9 is available here. It was retrieved from a FTP mirror, not created by me. It is meant to give an impression of how the installation process looks like. The installation of OpenBSD 3.4 is just slightly different.

The OpenBSD v3.4 installation process went as follows (mail me if I forget important steps and/or info):

1. Connect to the nearest OpenBSD FTP mirror.
2. Go to the /pub/OpenBSD/3.4/i386 directory. Use something other than i386 if you install on an other platform.
3. Retrieve the installation floppy image (floppy34.fs). This should be enough to start the install in most situations.
4. Burn the installation floppy to a floppy disk:
   Example: dd if=floppy34.fs of=/dev/fd0
5. Boot the system from the floppy disk.
6. When asked for /bin/sh just hit the enter key.
7. For installation hit «i», for a upgrade «u». Only the installation option is covered here. I like clean installs.
8. If you’d like to use the complete disk for OpenBSD enter «yes».
9. Now configure your OpenBSD disk slice. This is done by the label editor. Type «?» for help, «x» to exit without saving changes and «q» to exit and save changes. To add an partition type «a x» where «x» is the partition you’d like to add. Type «p» to see all partions. Partition «a» is often the / (root) partion, «b» is reserved for a potential swap partition, «c» is a sort of symbolic partition representing the whole disk, the rest of the letters are free to (ab)use.

   You would probably a separate partition for /, /tmp, /var, /usr and /home. My suggestion for a small (2G HD, 32MB RAM) home server/workstation system:

   /     : 128 MB
swap  : 128 MB
/tmp  : 128 MB
/var  : 256 MB
/usr  : 1048 MB
/home : the rest

   If you got the space, a 10G harddisk for instance and 64MB RAM, you could do it like this:

   /     : 128 MB
swap  : 128 MB
/tmp  : 512 MB
/var  : 1024 MB
/usr  : 2048 MB
/home : 1024 MB
/vol  : the rest

   With a real small server, say 1G HD and 16MB RAM, you could probably do best by using this kind of layout:

   /     : 64 MB
swap  : 96 MB
/usr  : the rest

   And symlink /var, /tmp and /home to respectively /usr/var, /usr/tmp and/usr/home.

   Above layouts are rough indications and can vary enormously from system to system. Database servers might/should want a bigger /var for instance. A lot of users wanting space for their files could warrant more space being allocated to /home.

   Hit «q» to exit and save your configuration when done.

10. The install process then presents a chance to initialize more disks (if found) via the same process explained a step earlier. If you’re satisfied with your disk(s), enter «done» and hit return. The install process shows all partitions and their respective mount points of all disks initialized for you to review. Hitting return will show the next partition and its moint point. This is an endless loop. When everything is okay, enter «done» and hit return, to escape the endless loop and continue.
11. The install formats your disks and partitions and continues by asking if you’d like to setup networking. Answer the simple questions and hit return at the default answer of no, when it asks if you’d like to escape to a shell environment.
12. The install mounts your partitions and asks for the root password. Type it carefully and remember it! (-;
13. Next, if you’d like to run the XFree86 X Window System, answer yes to the question prompted. If your setting up a server, answering no will be a good decision in most cases.
14. Now, you’re ready to download the base install files via FTP, HTTP and some other neat protocols. Select your favourite and select which packages it should install. To select or deselect a package simply type in the full name of it, including the ending «.tgz».
15. When you’re done installing those nice tarballs answer no to the «extract more sets» question. The install creates some files in /etc and lets you choose your timezone. Select a cool looking zone and hit the return key.
16. Finally, you’re almost done! You only have to reboot the system now! But wait until the install process tells you it’s save, before doing that.

1. Edit /etc/inetd.conf to add the «cvs» service:
   cvspserver stream tcp nowait cvs /usr/libexec/tcpd /usr/bin/cvs -f --allow-root=/home/cvs pserver
2. Edit /etc/services to add the cvspserver protocol:
   cvspserver 2401/tcp
3. Edit /etc/hosts.allow to allow connections from certain hosts to the «cvs» service:
   cvs: 192.168.0. botte-coders.example.org .aars.it
4. Add the «cvs» user mentioned in /etc/inetd.conf to /etc/master.passwd:
   cvs:*:80:80::0:0:CVS:/home/cvs:/usr/local/bin/bash
   Run pwd_mkdb -p /etc/master.passwd to regenerate /etc/passwd.

   Create the group «cvs»:
   /etc/group:
cvs:*:80:

   Create the home directory for user «cvs»:
   mkdir /home/cvs
chmod 700 /home/cvs


5. Init the CVSROOT directory in /home/cvs:
   su -l cvs
cvs -d /home/cvs init

6. Create and/or edit the file /home/cvs/CVSROOT/passwd. This file will list the users able to connect to the «cvs» service:
   su -l cvs
cd /home/cvs/CVSROOT
touch passwd
chmod 600 passwd
vi passwd

   The file will look something like this:
   harry:ZrLzRsjAPL7iQ:cvs
klaas:Rf0DZbqhHM.Z.:cvs
sjaak:kLruwLTHOsOXT2:cvs
cvsusers:ORA7SfF0sRkD.:cvs

   «harry», «klaas» and «sjaak» are the cvs users. «cvsusers» is the common user account for the developers working on a certain website project. It is mainly meant for doing cvs checkouts in the production environment.
7. Finally, create the common user account «cvsusers» to keep your developers happy. You know how to do that, don’t you? (-:
8. Now all developers should set their CVSROOT environment and execute a cvs login:
   export CVSROOT=":pserver:<username>@yourserver.com:/home/cvs"
cvs login
cd ~public_html/
cvs -q checkout PROJECTNAME

Follow these pointers:

1. Edit /etc/rc.conf.local to start the DHCP server automatically:

   dhcpd_flags="-q" # for normal use: "-q"


2. Create/edit the file /etc/dhcpd.conf to configure dhcpd:

   # $OpenBSD: dhcpd.conf,v 1.1 1998/08/19 04:25:45 form Exp $
#
# DHCP server options.
# See dhcpd.conf(5) and dhcpd(8) for more information.

   shared-network LOCAL-NET {
   option routers 10.0.0.3;
   option domain-name "intranet.atomicvoid.net";
   option domain-name-servers 10.0.0.3;

   subnet 10.0.0.0 netmask 255.255.255.0 {
   range 10.0.0.100 10.0.0.200;
   }

   host miranda {
   hardware ethernet 00:00:39:3b:68:0d;
   fixed-address miranda.intranet.atomicvoid.net;
   }

   host andromeda {
hardware ethernet 00:50:fc:0c:3e:32;
fixed-address andromeda.intranet.atomicvoid.net;
}
}

   For a more detailed working example, see my dhcpd.conf file.

   The «host» directives inform the DHCP server to allocate a «fixed-address» to requests with a MAC address equal to the one listed by «hardware ethernet».
   The «subnet» directive informs the DHCP server that all DHCP requests result in a allocation of an IP address in the range of [10.0.0.100 - 10.0.0.200] if a client’s MAC address is not listed by one of the «host» directives.

3. Create/edit the file /etc/dhcpd.interfaces to list the interfaces dhcpd should listen on for DHCP requests:

   # $OpenBSD: dhcpd.interfaces,v 1.1 1998/08/19 04:25:45 form Exp $
#
# List of network interfaces served by dhcpd(8).
#
# ep0
# ed0 le0
# de1
xl0

   In this case, only DHCP request entering via the interface xl0 will be seen and handled by the DHCP daemon.

4. Reboot the system to have the changes take effect. Alternately, you can execute

   /usr/sbin/dhcpd -q xl0

   to start the DHCP server. Option «-q» quiets the chatter of the DHCP server and «xl0″ is the interface on which the DHCP server should listen for requests.

5. Check /var/log/daemon if the DHCP server was started succesfully.

1. Install the ntp package:

   pkg_add ntp-4.1.1c.tgz
pkg_add ntp-doc-4.1.1c.tgz

   The «doc» package is optional. It contains the documentation for the NTP daemon.

2. Edit /etc/rc.conf.local to start the network time services automatically.

   Set «ntpdate_flags» to the IP address of a NTP server, so that when the system boots, the local system clock is synchronized with that remote NTP server. This is a one time only action, only executed at system start.

   ntpdate_flags="129.6.15.28" # for normal use: NTP server; run before ntpd starts

   Why? Well, if the difference of the local system’s time and the remote NTP server(s) time is greater than one hour, the local running NTPD won’t synchronize the local system’s time with the time of the remote NTP server(s).

   Set «ntpd» to «YES» if you’d like to continuesly run a local NTP daemon, which synchronizes the local system’s time with the time offered by one or more remote NTP servers.

   ntpd=YES # run ntpd if it exists


3. Create a directory where ntpd can store some files like drift:

   mkdir /etc/ntp


4. Create/edit the file /etc/ntp.conf to configure the workings of ntpd:

   # Keep it rather quiet
logconfig =syncevents +allclock

   # Drift file. Put this in a directory which the daemon can write to.
   driftfile /etc/ntp/drift

   # Undisciplined Local Clock. This is a fake driver intended for backup
   # and when no outside source of synchronized time is available.
   server 127.127.1.0
   fudge 127.127.1.0 stratum 10

   # NTP servers from NIST for Atlantis
   server 129.6.15.28 iburst
   server 129.6.15.29 iburst

   # Do not allow anybody
   restrict default ignore

   # Do not peer with oneself
   restrict 127.0.0.1 mask 255.255.255.255 nopeer
   restrict 10.0.0.3 mask 255.255.255.255 nopeer
   restrict 192.168.0.3 mask 255.255.255.255 nopeer
   restrict 131.174.117.141 mask 255.255.255.255 nopeer

   # Allow NTP servers to inform us (-:
restrict 129.6.15.28 mask 255.255.255.255
restrict 129.6.15.29 mask 255.255.255.255

   For a more detailed working example, see my ntp.conf file.

5. Reboot the system to have the changes take effect. Alternately, you can execute

   /usr/local/sbin/ntpd -p /var/run/ntpd.pid

   to start the local NTP server.

6. Check /var/log/daemon if the NTP server was started succesfully.

>Installation

1. Unpack the distribution source code:
   cd /tmp
tar xvpfz /location/of/netqmail-1.04.tar.gz
cd netqmail-1.04
collate.sh
Note: watch for errors that collate.sh might produce.
2. Create the «home» directorie for Qmail:
   mkdir /var/qmail

3. Next we have to create some user and group accounts. Edit/etc/master.passwd to look like this:
   alias:*:100:101::0:0:Qmail-alias:/var/qmail/alias:/bin/true
qmaild:*:101:101::0:0:Qmail-qmaild:/var/qmail:/bin/true
qmaill:*:102:101::0:0:Qmail-qmaill:/var/qmail:/bin/true
qmailp:*:103:101::0:0:Qmail-qmailp:/var/qmail:/bin/true
qmailq:*:104:100::0:0:Qmail-qmailq:/var/qmail:/bin/true
qmailr:*:105:100::0:0:Qmail-qmailr:/var/qmail:/bin/true
qmails:*:106:100::0:0:Qmail-qmails:/var/qmail:/bin/true

   Then add two new groups to /etc/group:
   qmail:*:100:
nofiles:*:101:

4. Now we're ready to build Qmail from source:
   cd /tmp/netqmail-1.04/netqmail-1.04
make setup check
./config

   If config can't determine your hostname, you can tip it by running:
   ./config-fast mail.purebsd.com

5. More coming soon!

Links

• You want to run a secure DNS service on your system(s). (BIND is not secure, nor reliable.) Read DJBDNS’s security guarantee.
• You have three network interfaces:
  127.0.0.1 – the IP address of the localhost/loopback interface.
  192.168.0.3 – the IP address of the internal network interface.
  131.174.117.141 – the IP address of the external network interface.

  I assume that 127.0.0.1 needs no clarification. 192.168.0.3 is the IP with which the server babbles with the rest of the machines on your intranet. 131.174.117.141 is the IP address that your ISP provided to you in order to TCP/IP you into the scary dungeons of the internet.

• Your intranet domain name is «intranet.purebsd.com» and your domain name is «purebsd.com».
• The secondary name server is setup the same way like our server.
• You like to install machine dependend things into /usr/local and stuff that can grow into /var.

Goal

We are going to create a split-horizon DNS service:

• The intranet machines will contact your server for resolving DNS queries.
• The intranet machines will contact your server to query the private intranet domain «intranet.purebsd.com».
• The intranet machines will contact your server to query the public internet domain «purebsd.com».
• The server itself will be able to do all of the above.
• The server will transfer its primary zones to its secondary nameserver by means of the dnszxfr «program».
• The server will receive its secondary zones from its primary nameserver by means of the dnszxfr «program».
• The machines on the internet will only be able to query the public internet domain «purebsd.com».

Roadmap to the DJBDNS solution

This page documents one possible roadmap to install, configure and use DJBDNS.

Getting the software

For DJBDNS you need to download three tarballs:

1. The latest djbdns package: djbdns-1.05.tar.gz
   DJBDNS, obviously.
2. The latest daemontools package: daemontools-0.76.tar.gz
   Daemontools is a collection of tools for managing UNIX services. DJBDNS makes use of it.
3. The latest ucspi-tcp package: ucspi-tcp-0.88.tar.gz
   Ucspi-tcp is a collection of tools to create and accept TCP connections.

Installing the framework

To install these three packages:

1. First, create a package directory in /usr/local:
   mkdir -p /usr/local/package
chmod 1755 /usr/local/package
ln -s /usr/local/package /package
cd /package

   Extract the daemontools sources in /package:
   tar xpfz daemontools-0.76.tar.gz
cd admin/daemontools-0.76

   To compile and setup daemontools:
   package/install

   The directories /command and /service are created by the installation script./command is populated by symbolic links to programs located in /package or/usr/local/package. Symbolic links located in /service are used by svscan to start (daemontools compatible) services under supervision of supervise. DJBDNS, daemontools and ucspi-tcp need those directories by default. If you don’t like them and want to change the names or locations of those directories, make sure you know exactly what you’re doing when hacking the Makefiles and source code.

   Note: /command/svscanboot is automatically added to /etc/rc.local

2. Extract the ucspi-tcp sources somewhere:
   tar xvfz ucspi-tcp-0.88.tar
cd ucspi-tcp-0.88

   To compile and install ucspi-tcp:
   make
make setup check

3. Extract the djbdns sources somewhere:
   tar xvfz djbdns-1.05.tar
cd djbdns-1.05

   To compile and install djbdns:
   make
make setup check


Edit the /etc/dnsroots.global file to reflect the new IP address of j.root-servers.net:

• Replace 198.41.0.10 with 192.58.128.30.

Now setup some nice system accounts for DJBDNS:

1. Add «dnscache», «dnslog», «tinydns» and «dnszxfr» as new accounts to the system by adding the following four lines to /etc/master.passwd:

   dnscache:*:90:90::0:0:dnscache:/nonexistent:/sbin/nologin
dnslog:*:91:91::0:0:dnslog:/nonexistent:/sbin/nologin
tinydns:*:92:92::0:0:tinydns:/nonexistent:/sbin/nologin
dnszxfr:*:93:93::0:0:DNS zone transfer agent:/var/djbdns/public-dnszxfr:/bin/sh

   Note: make sure that each account entry is just one line. Do not spread over multiple lines or you will corrupt the file.

   Then run pwd_mkdb -p /etc/master.passwd to activate the changes.

2. Add four new groups to /etc/group:
   dnscache:*:90:
dnslog:*:91:
tinydns:*:92:
dnszxfr:*:93:

3. Change dnszxfr’s password with a string of about 10 random characters found on your keyboard:
   passwd dnszxfr

Now we can create the data directories of the various DJBDNS programs:

1. First, create a directory where DJBDNS data directories will reside:
   mkdir /var/djbdns
2. Create a caching DNS service:
   dnscache-conf dnscache dnslog \
/var/djbdns/private-dnscache 192.168.0.3
3. Create an authorative DNS service for the intranet:
   tinydns-conf tinydns dnslog \
/var/djbdns/private-tinydns 127.0.0.1
4. Create an authorative DNS service for the internet:
   tinydns-conf tinydns dnslog \
/var/djbdns/public-tinydns 131.174.117.141
5. Create a directory for the zone transfer dnszxfr:
   mkdir /var/djbdns/public-dnszxfr
chown dnszxfr:dnszxfr /var/djbdns/public-dnszxfr
chmod 700 /var/djbdns/public-dnszxfr


Getting ready

The data directories are created and already filled with some files that form the framework. We have to finetune some of these files or create some new files in order to let things run smoothly on our server.

1. Edit /var/djbdns/private-tinydns/run to increase the softlimit:
   ... vdir ./env softlimit -d500000 /usr/loc ...

2. Edit /var/djbdns/public-tinydns/run to increase the softlimit:
   ... vdir ./env softlimit -d500000 /usr/loc ...

3. To enable the intranet to use dnscache’s services:
   cd /var/djbdns/private-dnscache/root/ip
touch 192.168.0
chmod 600 192.168.0

4. In order to have dnscache resolve 192.168.0.* and *.intranet.purebsd.com, it has to know where to look:
   cd /var/djbdns/private-dnscache/root/servers
echo 127.0.0.1 > 0.168.192.in-addr.arpa
echo 127.0.0.1 > intranet.purebsd.com

   127.0.0.1 is the IP address that private-tinydns, which knows about 129.168.0.* and *.intranet.purebsd.com, listens on.
5. Edit /var/djbdns/private-tinydns/root/Makefile to read:
   data.cdb: data
   /usr/local/bin/tinydns-data

   data: private-zones-primary
cat private-zones-primary > data


6. Edit /var/djbdns/public-tinydns/root/Makefile to read:
   data.cdb: data
   @echo -n "[3] Creating 'data.cdb' from 'data'.. "
   @/usr/local/bin/tinydns-data
   @echo "OK"

   data: public-zones-primary public-zones-secondary
   @echo -n "[1] Creating 'data' from 'public-zones-primary' \
   and 'public-zones-secondary'.. "
   @cat public-zones-primary public-zones-secondary > data
   @echo "OK"

   @echo -n "[2] Copying primary zone to DNSZXFR transfer \
directory.. "
@/bin/cp -f public-zones-primary /var/djbdns/public-dnszxfr/
@echo "OK"

   Note:All indented lines should be indented with tabs instead of spaces. Make will complain if you fail to meet this requirement.

Prime time

Now we are ready to run the DJBDNS services:

1. Go to the /service directory:
   cd /service
2. Make symbolic links to public-tinydns, private-tinydns and private-dnscache:
   ln -s /var/djbdns/private-dnscache .
ln -s /var/djbdns/private-tinydns .
ln -s /var/djbdns/public-tinydns .

3. The services should be started automatically within seconds. To verify: svstat /service/*
   The output will be something similar to:
   /service/private-dnscache: up (pid 17170) 686536 seconds
/service/private-tinydns: up (pid 15258) 686536 seconds
/service/public-tinydns: up (pid 22261) 686536 seconds

4. You should let your system’s DNS resolver(s) know what IP address should be used to submit DNS queries to. Create/edit /etc/resolv.conf to have it use dnscache‘s IP address:
   nameserver 192.168.0.3

Serving DNS records

The dnscache program is already providing resolving DNS services to your system and intranet. But nothing is known about *.intranet.purebsd.com (the intranet domain) nor *.purebsd.com (the public internet domain).
First, we’re going to inform private-tinydns (the tinydns instance that knows about *.intranet.purebsd.com) what it should know about the intranet.

1. The tinydns data format is very simple (and easy to parse for programs). Make yourself acquaintable with the tinydns data format.
2. Now that you know all about the tinydns data format, go to the private-tinydnsdirectory to which tinydns chroot()’s:
   cd /var/djbdns/private-tinydns/root
3. There you create the file private-zones-primary. It could look like this:
   # Zone: *.intranet.purebsd.com
#
.intranet.purebsd.com::atlantis.intranet.purebsd.com
@intranet.purebsd.com::atlantis.intranet.purebsd.com:10
'purebsd.com:PureBSD intranet
=antarctica.intranet.purebsd.com:192.168.0.1
=aldebaran.intranet.purebsd.com:192.168.0.2
=atlantis.intranet.purebsd.com:192.168.0.3

4. To have tinydns load the new private (primary) zone file just run make. make processes the Makefile file. That copies private-zones-primary to data and callstinydns-data to generate data.cdb out of data.

   The usage of private-zones-primary looks a bit clumsy or overdone, but I found it to be more consistent with the public-tinydns approach I took.

Now we’re going to have public-tinydns publish our beloved purebsd.com domain.

1. Go to the public-tinydns directory to which tinydns chroot()’s:
   cd /var/djbdns/public-tinydns/root
2. There you create the file public-zones-primary. It could look like this:
   # Zone: *.purebsd.com
#
.purebsd.com::ns1.purebsd.com
.purebsd.com::ns2.purebsd.com
@purebsd.com::mail1.purebsd.com:10
@purebsd.com::mail2.purebsd.com:20
'purebsd.com:PureBSD - BSD resources
+ns1.purebsd.com:131.174.117.141
+ns2.purebsd.com:131.174.119.121
+mail1.purebsd.com:131.174.117.141
+mail2.purebsd.com:131.174.119.121
+www.purebsd.com:131.174.117.141

3. To have tinydns load the new public (primary) zone file just run make. make processes the Makefile file. That copies public-zones-primary and public-zones-secondary to data and calls tinydns-data to generate data.cdb out of data.

   Make also copies the file public-zones-primary to the DNSXFR directory so that DNSXFR can transfer it to the secondary nameserver(s).

Zone transfers

The setup and configuration of the The DNS zone transfer program «dnszxfr» will be coverend when the rest of the DJBDNS setup is completed (and documented here .

More reading

For more in-depth documentation for the DJBDNS, daemontools and ucspi-tcp programs:

• DJBDNS:
  - Official DJBDNS site
• Daemontools:
  - Official daemontools site
• Ucspi-tcp:
  - Official ucspi-tcp site