In order to have a smooth working system administration process, the various system administrators somehow have to cooperate in a specific way.

Book keeping

Some bookkeeping helps in this process:

1. /root/MUTATIONS:
   A file where each atomic action of a sysadmin is documented. Preferable with date ordered entries.
2. /var/mail:
   Make use of the e-mail phenomenon to update your co-admins of the latest important changes!
3. /etc/motd:
   Update this file to inform your co-admins and users of important changes.
4. /dev/oral/communication:
   Use this device to communicate with your collegues before doing anything that could have/will have a rather large impact on the running system.

Other points of attention

Having some standard habits and procedures can be helpful too:

1. *-dist files:
   If a sysadmin is the first to alter a certain file, for example /etc/rc.conf, it is wise to make a backup to /etc/rc.conf-dist, in order to preserve the original file. Later on, you can review the differences between the original and the new version of that file.
   If a *-dist file already exists, it should NOT be over- written. When you’d feel safer to have a backup of the latest version, copy the file to something like *-old. The *-dist files are the original files of the original installation of the Operating System you’re using.
2. installations of third party sofware:
   If you need to install a program that’s both in the binary package collection and in the /usr/ports collection, choose for the former. No needless compiling and wasting diskspace, bandwidth and CPU cycles.
3. installation of already present software:
   Make use of the already present software on the system. OpenBSD for instance, comes with Apache out of the box. No use retrieving, compiling and installing it yourself. Installed software has been reviewed by the OpenBSD team, who patch it when necessary for security fixes.

In The Netherlands there are now, as far as I know, two different ways in which ADSL users have to configure their machines. One is without hassles (good!) and one is with hassles (bad!).

The without-hassle method below is valid for people connecting to Demon in The Netherlands. Please inform me of other ISPs implementing this method.

The with-hassle method below is valid for Alcatel ADSL modems as provided by the Dutch ISPPlanet Internet. People with an ADSL connection from the Austrian ISP Inode should encounter no problems, but they may not be (entirely) correct for Other ISP’s, in The Netherlands or abroad.

ADSL without hassles

Say you have an external interface called rl0. While installing OpenBSD, configure the interfacerl0 by typing “dhcp” when asked for an IP address. If you’ve already a running install, you can edit /etc/hostname.rl0. That file should exist of only one line reading “dhcp”.

This is pretty much it. If you’re editing /etc/hostname.rl0 after you installed OpenBSD, you should either reboot or run route flush && sh -x /etc/netstart.

OpenBSD asks via the DHCP protocol your ISP to provide your machine with an IP address, gateway, DNS servers, etc. You might not like everything you receive from the remote DHCP daemon, so you might have to edit /etc/dhclient.conf in order to override some of the options the DHCP daemon whispers in your DHCP client’s ear:

supersede host-name "aurora";
supersede domain-name "intranet.hezeldrama.net";
prepend domain-name-servers 127.0.0.1;

Above three lines tell the DHCP client to use “aurora” as the hostname of the machine, “intranet.hezeldrama.net” as its domain name and to setup /etc/resolv.conf in such a way that the first nameserver line reads “127.0.0.1″. The last option is required only if you’d like to run your own caching DNS server on the localhost (= 127.0.0.1).

ADSL with hassles

1. Reconfigure and recompile your kernel if you run the GENERIC OpenBSD kernel or a custom one, built with GRE (Generic Route Encapsulation) support. GRE eats the packets that are actually meant for the PPTP daemon software we’re about to use, resulting in a not working ADSL connection and the following error: LCP: timeout sending Config-Requests.So search for the line pseudo-device gre 1 in your kernel configuration file and disable it by putting a hash-sign (#) in front of that line. See the section updating for more information on recompiling your kernel.

   Doing sysctl -w net.inet.gre.allow=0 does not work. Reconfigure & Recompile(tm).

2. Now you configure the network interface connected to your modem. Create or edit for this/etc/hostname.<if>, where if is the devicename of the interface: inet 10.0.0.150 255.0.0.0 NONE
3. Download PPTP software from packetst0rm. Extract the source, runmake and copy pptp and pptp_callmgr to /usr/sbin.
4. Edit /etc/ppp/options to read the following: name "LOGINNAME"
noauth
noipdefault
defaultroute
debug

   Replace LOGINNAME with the loginname/username/user-id that you need to dial-in to your ISP.
5. Edit /etc/ppp/pap-secrets to read the following: LOGINNAME 10.0.0.138 PASSWORD

   Replace LOGINNAME with the loginname/username/user-id that you need to dial-in to your ISP. The same goes for PASSWORD.

6. If you do not run your own (caching) nameserver, you may like to edit/etc/resolv.conf to use the nameservers of your ISP: search speed.planet.nl
nameserver 195.121.1.34
nameserver 195.121.1.66

7. Run pptp 10.0.0.138 to login to your ISP. The ADSL internet link should now be up.
8. Credits:
   Michael Kummer for his OpenBSD ADSL howto
   Lukas Ertl for his FreeBSD ADSL howto

ADSL with hassles: Afterwards

1. For OpenBSD versions below 3.0:If you’d like to use NAT over your ADSL connection, disable the ipnat in your/etc/rc.conf, since ppp0 is not a valid configured interface at the time when/etc/netstart is run. Though ipfilter should be enabled.

   ipfilter=YES
ipnat=NO

   Only when your ADSL connection is running and ppp0 is configured you should run:

   /sbin/ipnat -CF -f /etc/ipnat.conf

   For OpenBSD versions above 2.9:

   You’re probably running PF and not IPFilter. I’m not sure if you need to do special things in order to have NAT work automatically when connected to the internet via de ADSL line. I’ll ask around.

2. You could optionally download this ADSL reconnect script from packetst0rm and run it from crontab to reestablish a broken connection. But that’s not a usable script.Don’t panic! I wrote one myself. Though it is very brutal, it does reconnect in all possible situations as far as I know. Packetst0rm’s script didn’t.

   - View adsl_reconnect.sh
   - Download adsl_reconnect.sh (gzipped)

   The only thing you should configure is the REMOTE_IP variable, which is the IP address of the remote end of your PPTP tunnel. This IP can be found easily when ADSL is running:

   $ ifconfig ppp0
ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 62.131.xx.yyy --> 195.190.aaa.bbb netmask 0xff000000

   Here, the “195.190.aaa.bbb” is the value you should assign to the REMOTE_IP variable.
   Note: some ISPs drop/block ping packets directed to the remote end of the PPTP tunnel or most if not all of their other servers. So it is advised to check if the IP you’d like to use is returning ping packets before using it in the reconnect script.

   To have that reconnection script executed every five minutes you could edit root’s crontaband insert the following somewhere:

   # Check ADSL connection
*/5 * * * * /root/bin/adsl_reconnect.sh > /dev/null


Introduction

With OpenBSD updating the kernel, the system utilities or the ports collection is a rather simple and straightforward process. All sources of the above mentioned pieces that make up the OpenBSD operating system are stored in CVS.

CVS is a system that allows for Concurrent Versions Control for one or more software projects. It allows the people of the OpenBSD project to work on the same set of sources.

For you, the end-user of OpenBSD it is handy too. It allows you to retrieve via a simple CVS command to retrieve the latest set of patches from a certain branch of OpenBSD.

Here, we’ll concentrate on updating the stable branch of the OpenBSD 3.4 kernel and system utilities.

Getting the sources

First, we need to lay our hands on the system sources. There are roughly three places to get them:

1. One of the two of your OpenBSD CDs if you have those
2. A FTP mirror containing a OpenBSD tree
3. From a OpenBSD CVS server

I myself prefer method two, for it’s faster than downloading it from CVS and I don’t have the official CDs. On one of the many mirrors you should cd your way into the subtree of the OpenBSD version you’re interested in and download the following three files:

1. ports.tar.gz
2. src.tar.gz
3. srcsys.tar.gz

Create a directory called src in /usr if it doens’t exists. cd to /usr/src and extract the filessrc.tar.gz and srcsys.tar.gz in that directory.
cd to /usr and extract ports.tar.gz.

# cd /usr/src
# tar xfz ~alex/download/src.tar.gz
# tar xfz ~alex/download/srcsys.tar.gz
# cd ..
# tar xfz ~alex/download/ports.tar.gz

Updating the sources

Now, we’ll try to contact a friendly CVS server and try to squeeze some updates and/or patches out of it.

First, set these environment variables:

export CVS_RSH="/usr/bin/ssh"
export CVSROOT="anoncvs@anoncvs.se.openbsd.org:/cvs"
export CVS_IGNORE_REMOTE_ROOT="1"

Then change your working directory to /usr/src and update the source tree by issueing this command:

cvs -d $CVSROOT -q update -rOPENBSD_3_4 -Pd

Recompiling the kernel

See Configuring the kernel for this.

Recompiling the software in the base system

su to root and change directory to /usr/src/dir/toolname

# cd /usr/src
# cd libexec/telnetd
# make obj
# make depend
# make
# make install

Recompiling software in the ports collection

Coming soon..