All these components add up to
around $300 & and that's brand-new stuff. If you have any
old components lying around, they will be fine. You don't
need a keyboard, mouse or monitor when the system is up
and running & all maintenance on it can be done over the
network. (While you're installing the OS on the machine
you will need to hook up a keyboard, monitor and CD-ROM
drive to it, of course.)
While installing the system, I plug in a spare CD-ROM
drive, keyboard and monitor. Change the BIOS settings so
that the machine will boot without a keyboard etc. Boot
off the OpenBSD 3.3 CD and install the system. All the
hardware should be recognised without any problems.
installation guide booklet that comes with the CDs is
excellent.)
The easiest way to install OpenBSD is to buy the
distribution on CDs. Although you can install it via the
network, buying the CD will help make sure that the
OpenBSD project will continue to improve and better the
system. If you can afford an outlay of US$40, please buy
the CDs from the
When you're installing OpenBSD, the installer program will
ask you for disklabel information (partitions). On a Unix
system, a group of files organised together is called a
filesystem. The disk is partitioned into various pieces
each of which will hold one filesystem.
This is the filesystem breakup and partition sizes I'd use for a
12GB disk (if your disk is bigger, you can just increase the
size of /var (for web files) or /home (for
your personal files) & the system will be more than happy with
these sizes for /, /tmp and /usr):
(The convention is that a is always /,
b is swap and c is the whole disk.)
files will live in /var, and your other files in
T /usr only needs about 600M
or so. Say pad it to 1GB. A 2GB disk would be plenty for
the system, but if the cheapest disk you can get is 13GB....
Note for Unix newcomers: the disk is named
/dev/wd0, and in this case it has 5 partitions
with names /dev/wd0a, /dev/wd0d,
/dev/wd0e, /dev/wd0g and
/dev/wd0h. And the different partitions don't
get different "drive letters" as in some primitive
once the system is installed, it
looks to the user that there is jus
Unix will figure out the right thing to do.
system has been installed and you've booted off the hard
disk, log in and (this is important!) type
man afterboot; it will remind of some things
that you need to do to complete the installation & pick
passwords, create user accounts, check network settings
etc. Also, man hier will introduce you to the
way the system is organised & which files live where. In
fact, let me say that again:
After the first normal boot of the system, be
sure to read these manpages:
man afterboot
There! And make sure you keep reading the manpages & OpenBSD
manpages are a thing of beauty, complete, up-to-date and
informative. And also read the OpenBSD FAQ on the web --
much of this information is also found there.
Configuring the network
For my outside connection I have DSL and a static IP number
recommend them over PacBell etc. & I'm so happy I switched).
Other DSL options are PPPoE that PacBell likes to set people up
with, or DHCP which is what you usually get over cable.
completely bogus DSL installation is the USB device they try to
foist on customers with Windows. Danger, Will Robinson! They
they're unsupported on any free O/S, and even on Windows
they work about half the time.
PPPoE users: There is one case you need to handle
yourself & setting up DNS. Details will be in the section
In *BSD the network cards are named according to the
driver used. For the D-Link cards, the driver is called
rl, so my two ethernet cards are rl0
and rl1. For the inside network I use the
"private" (non-routable) IP numbers 192.168.1.* which
will make the inward-facing network card
192.168.1.1. The OpenBSD initialization asks you for IP
numbers for the two cards. Enter the appropriate ones -
the IP number your ISP gave you for rl0, and
192.168.1.1 for rl1. For PPPoE, the outside
interface is tun0 and it will figure out its
own IP address. If you're supposed use DHCP on your DSL
or cable connection, type in dhcp.
It is important to remember which network will be the
outside and which the inside. If the two cards are
identical, the easiest way is to look at the MAC number.
Every ethernet card ever made has a unique ID called its
MAC number. This will be printed on the card, usually as a
sticker. When the kernel boots up, it will print the MAC
numbers of each card it finds:
rl0 at pci0 dev 9 function 0 "Realtek 8139" rev 0x10: irq 11 address 00:50:ba:44:ab:1c
rl1 at pci0 dev 10 function 0 "Realtek 8139" rev 0x10: irq 10 address 00:50:ba:44:9c:3e
So the card that has a MAC number ending ab1c is rl0;
the other is rl1. (If the two network cards you have are
different types, there's no problem, of course.
The kernel
bootup messages will still be useful to tell you what names the
system is using for them.)
(There's some rule about where the cards are plugged in so
which one gets number 0 and which no. 1, but I can never
remember that.)
The beast! PPPoE is a pain in the ass but ISPs like it because
it makes things simpler for them & they don't have to maintain
lists of IP numbers. Also, they can run a crappy service and
keep dropping the connection and that's ok, you're expected to
reconnect. It's the Micros**t philosophy of "make something
really crappy and expect people to just re-start the whole
system a couple of times a day."
It's a pain in the ass for us
because its MTU is 1492 instead of 1500 which used to require
changes on every machine inside the network & but now thanks to
the "mssfixup" flag we don't have to any more. (You are not
expected to understand that.)
Caveat: I do not have access to any PPPoE connections
any more, so there may be changes since 3.1. Keep all this in
mind as you read this section, and please send me corrections.
The files you will need to change for PPPoE all live in
/etc/ppp/. There are other differences:
you shouldn't have /etc/mygate; and the file
describing the outside interface, /etc/hostname.dc0 in
my example, will only have one word in it: up. This
tells the system to bring up the interface at boot time, but to
do nothing else & the PPP program (daemon) will do the rest.
The network interface when using PPPoE is tun0, not the
ethernet card the PPPoE line goes into (dc0 in my
example). The PPP daemon handles the network on its own, then
passes packets on to the tun0 pseudo-device. That is
the name you'll use in any place network devices are specified,
like the firewall or network sniffing tools.
The main config file is /etc/ppp/ppp.conf and this is
what it should look like:
set log Phase Chat LCP IPCP CCP tun command
set redial 15 0
set reconnect 15 10000
set device "!/usr/sbin/pppoe -i rl0"
disable acfcomp protocomp
deny acfcomp
set mtu 1492
set speed sync
enable lqr
set lqrperiod 5
set timeout 0
set authname login
set authkey password
enable dns
enable mssfixup
Caveat: pay attention to the leading spaces.
Use your login name and password where indicated. The "set
device" line tells ppp which physical device to use to
talk to the outside world. You also have to tell the
system to start PPPoE at boot time. That can be done with
this little snippet of shell script:
echo -n "Trying to establish PPPoE DSL"; ppp -ddial pppoe
for i in 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0; do
echo -n "$i"
if /usr/local/sbin/adsl-status>/dev/ then
/usr/local/sbin/adsl-status
Where adsl-status is a little shell-script that
tests to see whether the PPP link has come up
IP=$(/sbin/ifconfig tun0 | awk '/netmask/{print $2}')
if [ -z "$IP" ]; then
echo "ADSL link is down."
echo "ADSL is up, IP address $IP"
Now the question is: where should we put the little loop
that tries to get ppp going? The right place to put all
these is in /etc/rc.local. However this has the
drawback that the outside network hasn't been initialised
while the rest of the system is coming up, which causes
some scary-looking error messages from NAT to be printed
at boot time. So I do something a little un-kosher: I put
the ppp initialisation in /etc/netstart right at
echo -n ' ADSL... '; ; ppp -ddial pppoe
for i in 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0; do
echo -n.$i"
if /usr/local/sbin/adsl-status>/dev/ then
/usr/local/sbin/adsl-status
Now remember that each time the PPP link goes up or down, the
firewall and NAT rules must be re-done. (NAT and firewalls will be
covered shortly.) The files /etc/ppp/ppp.linkup and
/etc/ppp/linkdown are scripts that get run by ppp. Here's
/etc/ppp/ppp.linkup:
! sh -c "/sbin/route del default"
! sh -c "/sbin/route add default HISADDR -mtu 1492"
! sh -c "/sbin/pfctl -e -f /etc/pf.conf"
! sh -c "/usr/local/sbin/ntpd -p /var/run/ntpd.pid"And
this is /etc/ppp/linkdown:
! sh -c "/sbin/pfctl -d"
Caveat: There is a space before the exclamation points on those lines.
As I said before, I no longer have access to any PPPoE
if you know of any inaccuracies or bogosities above, please let me know.
Configure system files
To set up the system, the files you will be editing
are:/etc/rc.conf, /etc/myname,
/etc/mygate, /etc/pf.conf,
/etc/nat.conf, /etc/*.conf,
/etc/hostname.interface,
/var/named/*.
Edit /etc/rc.conf. On my servers I run SMTP,
Apache, and ssh. In other words, from the outside it
handles email, web acess and secure shell for remote
For convenience, on the inside I have a private
name server (DNS) and NTP server for accurate time. To get
sendmail, NTP, httpd, and NAT to work, these are the lines
to change:
sendmail_flags="-bd -q30m"
# for normal use: "-bd -q30m"
named_flags=""
# for normal use: ""
ntpdate_flags="put.server.here" # for normal use: NTP run before ntpd starts
httpd_flags=""
# for normal use: "" (or "-DSSL" after reading ssl(8))
dhcpd_flags=-q
# for normal use: "-q"
# Packet filter / NAT
# run ntpd if it exists
pf_rules=/etc/pf.conf
# Packet filter rules file
Make sure that /etc/sysctl.conf has this line in
net.inet.ip.forwarding=1
# 1=Permit forwarding (routing) of packets
Get the names of NTP servers close to where you are and put
that name in the ntpdate value. Here's a list
of public NTP servers.
The system should already have setup
/etc/hostname.dc0 and /etc/hostname.fxp0
(or whatever your network device names are) for you. Each
file will have the IP number and netmask. This is what these
files would look like:
bash-2.05$ cat /etc/hostname.fxp0
inet 192.168.1.1 255.255.255.0 NONE
bash-2.05$ cat /etc/hostname.dc0
inet 123.45.67.89 255.255.255.0 NONE
(The bash-2.05$
a file out to the output.) If you're using DHCP, the outside
interface's hostname file will say dhcp. If PPPoE, then
just the word up.
Other important files: /etc/myname contains your
/etc/mygate & your default gateway
to the outside world (your ISP told you what this should be
& it's usually the same as your IP number except that the
last number is replaced with a 1 or 254) & except if you're on PPPoE, in which case you don't have one.
NAT and firewall rules
OpenBSD 3.x has a new packet filter & 2.9 used ipf but
3.x has a re-written from scratch one called pf. The
detai pf config files are much
My outside interface is dc0 and the inside interface is
fxp0. (If you're using PPPoE, the outside interface
will be tun0.) I also hav since
802.11b wireless ethernet is not particularly secure, and I
wanted my network to be freely accessible by anyone, the inside
machines need to be protected from it. The best way to do this
is to make the wireless and inside networks completely
a third network card rl0 is connected to an
802.11b access point and is assigned the network
192.168.2.0/24. I also block outbound email (port 25) from the
wireless network, since otherwise anyone on the street could use
my resources to send spam. (Regular people that use some sort of
web-based email service will not be affected.)
Firewall rules (they tell the gateway what kind of network
traffic should be allowed into the internal network) live in
/etc/pf.conf; NAT configuration is also in this file.
Here's a sample /etc/pf.conf & very little is
accessible from the outside, but machines on the inside can go
out with no restrictions. In your files you'd edit the lines
near the top of the file with the names of your outward- and
inward-facing ethernet cards, and wireless card if any. Read it,
understand it, modify it for your specific needs. Security is
not a spectator sport.
#####################################################################
# IP packet filtering rules (firewall)
# Shamim Mohamed 3/3
# See pf.conf(5) for syntax and examples
# If you change this file, run
pfctl -f /etc/pf.conf
# to update kernel tables (also run "pfctl -e" if pf was not running)
# Network interfaces (Remember, if using PPPoE the ext. interface is tun0)
internal = "fxp0"
external = "dc0"
wireless = "rl0"
unsafe = "{ dc0, rl0 }"
# Services visible from the outside & remove any you're not using
services = "{ ssh, http, https, smtp, domain }"
# The wireless interface is not allowed to send anything to the inside
# network. It can send anything out except smtp since we don't
# want being used as a spam relay. Yes, this is paranoid. Better safe
# than sorry.
# You shouldn't need to change anything below this line
#####################################################################
# Non-routable IP numbers
nonroutable = "{ 192.168.0.0/16, 127.0.0.0/8, 172.16.0.0/12, 10.0.0.0/8,
0.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, 204.152.64.0/23, 224.0.0.0/3,
255.255.255.255/32 }"
# All rules are "quick" so go strictly top to bottom
# Fix fragmented packets
scrub in all
# Create two packet queues: one for regular traffic, another for
# high priority: TCP ACKs and packets with ToS 'lowdelay'
altq on $external priq bandwidth 125Kb queue { highpri_q, default_q }
queue highpri_q priority 7
queue default_q priority 1 priq(default)
# nat: packets going out through dc0 with source addr 192.168.1.0/24
# will get translated as coming from our external address. State is
# created for such packets, and incoming packets will be redirected to
# the internal address.
# I have an experimental web server
I can test it
# from the outside by connecting to port 8042.
rdr on $external inet proto tcp to port 8042 -> 192.168.1.12 port 80
# NAT: we need a rule for the inside network as well as the wireless.
nat on $external from 192.168.1.0/24 to any -> $external
nat on $external from 192.168.2.0/24 to any -> $external
########################################################################
Don't bug loopback
pass out quick on lo0 from any to any
pass in quick on lo0 from any to any
Don't bother the inside interface either
pass out quick on $internal from any to any
pass in quick on $internal from any to any
#####################################################################
First, we deal with bogus packets.
Block any inherently bad packets coming in from the outside world.
These include ICMP redirect packets and IP fragments so short the
filtering rules won't be able to examine the whole UDP/TCP header.
block in log quick on $unsafe inet proto icmp from any to any icmp-type redir
Block any IP spoofing atempts.
(Packets "from" non-routable
addresses shouldn't be coming in from the outside).
block in quick on $external from $nonroutable to any
Don't allow non-routable packets to leave our network
block out quick on $external from any to $nonroutable
#####################################################################
# Wireless:
block SMTP from wireless - spam threat
block in quick on $wireless inet proto tcp from any to any port smtp
#####################################################################
#####################################################################
The normal filtering rules
ICMP: allow incoming ping and traceroute only
pass in quick on $unsafe inet proto icmp from any to any icmp-type { \
echorep, echoreq, timex, unreach }
block in log quick on $unsafe inet proto icmp from any to any
TCP: Allow ssh, smtp, http and https incoming. Only match
SYN packets, and allow the state table to handle the rest of the
connection. ACKs and ToS "lowdelay" are given priority.
pass in quick on $external inet proto tcp from any to any port $services \
flags S/SA keep state queue (default_q, highpri_q)
# UDP: allow DNS since I run a public nameserver (remove if you don't!)
pass in quick on $unsafe inet proto udp from any to any port domain
################
# Wireless
# allow connections from 192.168.2.0/24, the inside wired network.
pass out quick on $wireless inet proto tcp from any to any \
flags S/SA keep state queue (default_q, highpri_q)
# Everyone is allowed to send UDP and ICMP out
pass out quick on $external inet proto udp
all keep state
pass out quick on $external inet proto icmp from any to any keep state
# Block wireless -> inside network
block in quick on $wireless from any to $nonroutable
# Everything else is ok
pass in quick on $wireless from any to any
##################
Of course we need to allow packets coming in as replies to our
connections so we keep state. Strictly speaking, with packets
coming from our network we don't have to only match SYN, but
what the hell. It allows us to put those packets in the high
priority queue.
pass out quick on $external inet proto tcp from any to any \
flags S/SA keep state queue (default_q, highpri_q)
pass out quick on $external inet proto udp
all keep state
pass out quick on $external inet proto icmp from any to any keep state
End of rules. Block everything to all ports, all protocols and return
RST (TCP) or ICMP/port-unreachable (UDP).
block return-rst in log quick on $unsafe inet proto tcp from any to any
block return-icmp in log quick on $unsafe inet proto udp from any to any
block in quick on $unsafe all
End of file
#####################################################################
Configuring email
(I'm now using postfix instead of
sendmail since it has easier human- I'll
soon document that too.)
Sendmail should have been setup automatically since you
edited /etc/rc.conf but I've occasionally had to
make one change in /etc/mail/sendmail.cf:
(If you don't own a domain, or plan on having it point to
your DSL machine, you don't need sendmail.)
You should have a normal user account that you're
going to use (never log in as root! Always use su
or sudo). Administrative email should be forwarded
if your normal username is zippy edit
/etc/mail/aliases and make sure you make the
appropriate lines look like this:
# Well-known aliases & these should be filled in!
root: zippy
manager: zippy
dumper: zippy
One thing you should consider is being an email handler for
friends. My DSL service goes down too often --
every few months. This is too unreliable for my tastes. What I do
is collaborate with friends to accept and queue email for
them, and they do the same for me. For my domain
< the primary mail exchanger is
, the OpenBSD firewall/gateway. But
a secondary mail exchanger (which someone out there on the
network will use if my DSL is down) will be
, and email will wait on that site
until my machine is back on the network. I want to perform
the same service for my friend & if
is down, I want people to be able to send my machine the
email destined for <. This goes in the file
/etc/mail/relay-domains:
Now the machine will accept email for < and
fubar.org as well as for itself and then forward
the messages on. If the machine it's trying to forward to
is down, it will put them in the queue and keep re-trying
for a while.
Setting up DNS
You probably shouldn't be running the primary DNS server
for your domain on your DSL DSL may not be reliable
enough for that.
Get someone else to do it for you for
free, like .
However, it is nice to have a local private DNS because lots of
daemons (services that run in the background, like the web
server) like to do reverse lookups of IP numbers, so we should
have a DNS server for the private network. Also, this
installation will give you a caching nameserver which
should improve your browsing speed. PPPoE users: don't
forget, you have a few extra steps.
Current versions of OpenBSD use BIND 9, which is different from
before: older versions used BIND 4. The config file name and
syntax are different. The files live in
/var/named. Here's a sample named.conf:
// Update this list to include only the networks for which you want
// to execute recursive queries. The default setting allows all hosts
// on any IPv4 networks for which the system has an interface, and
// the IPv6 localhost address.
acl clients {
version "";
// remove this to allow version queries
listen-on-v6 { };
allow-recursion { };
forwarders {
// Make sure you put your ISP's nameservers here!
64.128.32.16;
4.8.16.64;
// Configuration for rndc, the namesever control program
key "rndc-key" {
algorithm hmac-md5;
// Choose a Base64-encoded 128-bit random key here!
secret "hd5I7tJGKp7sC9bg6ddsbQ==";
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
category lame-servers { };
// Standard zones
zone "." {
file "standard/root.hint";
zone "localhost" {
file "standard/localhost";
allow-transfer { };
zone "127.in-addr.arpa" {
file "standard/loopback";
allow-transfer { };
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
file "standard/loopback6.arpa";
allow-transfer { };
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" {
file "standard/loopback6.int";
allow-transfer { };
// Master zones
zone "my-domain.org" {
file "master/my-domain.org";
// Slave zones
zone "other-domain.org" {
file "slave/other-domain.org";
64.1.23.45;
// Master server for other-domain.org
(Anything starting with // is a comment.)
Change the IP
numbers in the forwarders section to the nameservers your
ISP told you to use.
To control BIND 9, a program called
rndc a secret key is specified in the
named.conf file that rndc uses to authenticate
itself to the nameserver process. I use md5 -s to hash a
quasi-random string of my choosing to get 16 bytes of key, or read
16 bytes directly from /dev/urandom using dd(1).
Other files you need are the "zone files" for the domains you are
master for, like /var/named/master/my-domain.org:
gateway.my-domain.org.
root.my-domain.org. (
10800 Refresh
3600 Retry
604800 Expire
86400 ) ; Minimum
gateway.my-domain.org.
gateway IN
192.168.1.1
libelle IN
192.168.1.2
192.168.1.4
192.168.1.3
192.168.1.5
192.168.1.12
192.168.1.13
; your static IP number
123.45.67.89
In this network, there are six machines on the inside and
those are their names and IP Number assignments. The OpenBSD
gateway machine is named "gateway". Change these entries to
names of the machines on your private network. You can give
them any IP number that starts with 192.168.1. Of course if
you have three machines on your network, there will only by
three entries.)
To control the nameserver, the program rndc is used. It
has a few simple commands: the only one you need
isrndc&reload which you should do after changing any
configs or zone files. This updates the server with your changes.
Yes, another special case for PPPoE: You don't know what your
ISP's DNS servers are. (And they could change which machines
you're supposed to use each time you connect! In which case you
may be screwed.)
What you have to do is: connect "by hand" one
time, and see which DNS servers you got. After ppp.conf
has been written, you can run ppp -ddial pppoe and
pray. If all goes well, ifconfig tun0 should show you two
/sbin/ifconfig tun0
tun0: flags=11 mtu 1492
inet 63.201.32.40 --> 63.201.39.254 netmask 0xff000000
That means everything worked. Now look at
/etc/resolv.conf & there should be one or more
lines in there that say which nameservers should be
used. Put these IP numbers in the forwarders line
in /var/named/named.boot.
One other wrinkle: the /etc/resolv.conf that PPP
makes for you doesn't know about your domain, or that
you're running a nameserver on your machine. To get around
these problems, I created another file
/etc/resolv.conf-working:
nameserver 192.168.1.1
lookup file bind
search fake-domain.org
In /etc/ppp/ppp.linkup I tell it to overwrite the
created resolv.conf with this one:
! sh -c "cp /etc/resolv.conf-working /etc/resolv.conf"
(Add that to the end of the file that you've already
created.) This allows all programs running on the machine
to be able to use all the good things about a local
caching nameserver & things like being able to refer to
internal hosts by short name etc.
Other machines on the network
Go to the other machines on your network and set them up with
the static IP numbers you assigned above, e.g. the machine
wander gets an IP number of 192.168.1.5. All the
machines should use 192.168.1.1 for the gateway
and use 192.168.1.1 for the DNS server.
For more details on DNS, read the excellent O'Reilly book
"DNS and BIND"; for more on setting up slightly more complex
DNS servers than the one described here, go
site maintained by
Samiuela LV Taufa.
Setting up DHCP
Above in the DNS setup all internal machines are assigned
their own IP numbers. Running DHCP allows guest machines to
hook up to the network without fuss. Depending on your
comfort level with setting up your other machines, you might
also prefer to use DHCP over assigning static IPs. The wireless
network also needs DHCP service so guests can get IP addresses
use the network. This is
what /etc/dhcpd.conf should look like:
$OpenBSD: dhcpd.conf,v 1.1
04:25:45 form Exp $
# DHCP server options.
# See dhcpd.conf(5) and dhcpd(8) for more information.
shared-network LOCAL-NET {
domain-name "my-domain.org";
domain-name-servers 192.168.1.1;
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1;
range 192.168.1.32 192.168.1.127;
# the laptop with a PCMCIA ethernet card
host janus {
fixed-address janus.my-domain.
# This is the Linksys card
# hardware ethernet 0:e0:98:6:38:0;
# This is the 3Com card
hardware ethernet 0:50:4:cd:33:
shared-network WIRELESS-NET {
domain-name "my-domain.org";
domain-name-servers 192.168.2.1;
subnet 192.168.2.0 netmask 255.255.255.0 {
option routers 192.168.2.1;
range 192.168.2.32 192.168.2.127;
# the laptop with the PC-card wireless ethernet
host janus {
fixed-address janus-w.my-domain.
hardware ethernet 0:6:25:ab:fe:d;
This will allow up to 96 machines on your internal network, which
should be more than sufficient. Machines you know about can be
assigned fixed addresses by associating them with the MAC address
of the network, as shown above. Create an empty temporary file for
dhcpd to use:
bash-2.05# touch /var/db/dhcpd.leases
If you make any changes to this file, run dhcpd fxp0 rl0
(or whatever your inside network(s) is/are). (Or you can reboot the
machine & but that's the Windows way, in the Unix world we
prefer to never reboot any machines.)
On boot, the DHCP server needs to know which interfaces it should
serve. Create a file /etc/dhcpd.interfaces with their
$OpenBSD: dhcpd.interfaces,v 1.1
04:25:45 form Exp $
# List of network interfaces served by dhcpd(8).
Install "ports"
"Ports" is a *BSD term for a tree of Makefiles for all the
software out there that's not part of the standard install.
I recommend this highly. It is on CD No. 2 of the OpenBSD
3.3 CD-ROM set as ports.tar.gz. Please read the Ports and
Packages page on the OpenBSD web site.
You install it
by typing (as root)
bash-2.05#
mount /dev/cd0a /mnt
bash-2.05#
bash-2.05#
tar xzf /mnt/ports.tar.gz
Once you've done this, if you want to install a package, you
cd to the appropriate directory and simply type
make all install & it will ftp the source from the
appopriate site, handle all dependencies, apply any required
patches, configure, build and install the tool.
Getting time from the Internet
Set up NTP so that your machine will always have accurate
time. Pick two servers from the public NTP server list
and make sure /etc/ntp.conf looks like this:
server ntp.server.first
server ntp.server.second
Since xntpd is not part of the standard install, you have
to compile xntpd from source.
bash-2.05#
cd /usr/ports/sysutils/xntpd
bash-2.05#
make all install
The tools will be installed into
/usr/local/sbin/ntpd.
Run ntpdate -b server where you pick a
server from the list & this will perform a coarse adjustment
of the system clock. The next time the machine reboots, it
will sync your clock and record how much your clock drifts.
Setting up other hosts with NTP
On Unix hosts, use the appropriate NTP on Linux,
it's xntpd. Set them up to use 192.168.1.1 as the
NTP server. On Windows, use
a free NTP client. In its configuration make sure it uses only
SNTP as the protocol, with 192.168.1.1 as the server. Put
AboutTime in the Startup folder so it's started
automatically.
For more details, go to .
Tips and Stuff
I have a useful shell script called
that's a front-end to
pkg_add & here's an example of it being used:
bash-2.05# pkg_install tex
These files match:
gettext-0.10.40.tgz
jadetex-3.11.tgz
latex2html-97.1.tgz
php4-4.0.6p1-gettext-imap-mhash-no_x11-mcrypt-mysql.tgz
php4-4.0.6p1-gettext-imap-mhash-no_x11-mcrypt-postgresql.tgz
php4-4.0.6p1-gettext.tgz
teTeX_texmf-1.0.2.tgz
texi2html-1.64.tgz
textutils-2.0.tgz
bash-2.05# pkg_install -n 4 texi
Using ftp5.usa.openbsd.org/pub/OpenBSD
+ pkg_add -v ftp://ftp5.usa.openbsd.org/pub/OpenBSD/3.3/packages/i386//texi2html-1.64.tgz
Trying to fetch ftp://ftp5.usa.openbsd.org/pub/OpenBSD/3.3/packages/i386//texi2html-1.64.tgz.
Extracting from FTP connection into /var/tmp/instmp.BVMJM29414
>>> ftp -o & ftp://ftp5.usa.openbsd.org/pub/OpenBSD/3.3/packages/i386//texi2html-1.64.tgz...
It has a list of all the pre-compiled
are available. You type in a string and it installs the
package. If more than one name matches, it shows you their
names. (It uses
so you can use regular expressions.) Save it to
/usr/local/bin. It handles dependencies by recursively
installing them also.
New in this version is in -n flag. The script has a
list of mirrors, and this option picks one of the
mirrors. (Currently in progress: it needs bash, and it needs
some error checking but it works.) Don't forget to edit the file
& read http://www.openbsd.org/ftp.html
and choosea list of mirrors closest to you.
Running chroot Apache
Starting with 3.3, Apache (httpd) runs in a
chroot environment, i.e. the httpd process can
only see files under the /var/www/ directory. For
serving up static files this doesn' however
CGI scripts and environments need to be modified. In my case, I
write CGI programs in a language called Unicon, which is
this means the interpreter iconx &
and any dynamic
libraries it uses & must be replicated under
/var/www/. (Note: CGI scripts and programs must always
be approached with caution, since it's very easy to make a huge
security hole by accident. There's a good reason that OpenBSD
runs Apache in the chroot environment!)
bash-2.05$ cd /var/ ls -R
libc.so.29.0
libcrypto.so.9.0
libssl.so.7.0
libwrap.so.3.0
usr/libexec:
usr/local:
usr/local/unicon:
usr/local/unicon/bin:
A common environment for web applications is PHP. Similar
considerations apply: for instance, the mail() function
of PHP expects to run sendmail; this is not good. Much
better for it to use SMTP on the local machine, i.e. connect to
port 25 on localhost. Look in php.ini.
Setting up a CVS server
(This section is probably not of int you
only need this if you want to set up a cvs server so you can put
files you're working on under source control. So it's a little
terse too.)
The changes I made: added a user and group named cvs.
All users of CVS should be in the cvs group.
directory for the repository: I put it in /var/cvsroot,
you might put it in /home or wherever. This directory
should be group writable (group cvs). Add a line to
/etc/services:
cvspserver 2401/tcp
# CVS pserver
Add this line to /etc/inetd.conf:
cvspserver stream tcp nowait root /usr/bin/cvs cvs -f --allow-root=/var/cvsroot -T /var/tmp pserver
The server uses /var/tmp as its temp directory instead
of /tmp since my root partitions are small, but I
always make /var large.
Now run cvs init in
the cvs repository and restart inetd. Voila!
Import your
directory of files from a client machine, using a
pserver CVSROOT and cvs import.
When importing a large set of files, you might want to put a
.cvswrappers file in the directory you're importing so
CVS won't try to put RCS ID strings inside your JPEG files etc.
The syntax is:
*.jpg -k 'b'
*.png -k 'b'
*.tgz -k 'b'
Coming soon: using ssh for CVS_RSH.
References
& everything written here is covered (perhaps
better) in the FAQ.
& tutorial by Real Ouellet on setting up OpenBSD
gateway/firewalls. This document inspired parts of the page
you are reading.
A Brief Overview of Unix.
Build [another] PC Build
Your Own PC (yet another)
(in RockvilleLiving)
& a free ssh client for Windows machines.
& a free ssh client for MacOS.
and OpenBSD.
DNS on OpenBSD by Samiuela LV Taufa.
(Coming soon.)
Copyright &
This work is licensed under a Creative
Commons License.
This document may be redistributed only in its
entirety and as long as all copyright notices remain intact. File
format changes & e.g.
converting from HTML to \TeX
& are allowed, but no other modifications are.
Last modified: Tue Mar 15 17:22:53 PST 2005
CVS $Date:
20:37:44 $ $Revision: 1.22 $
Many thanks to
for excellent feedback and suggestions.