OpenBSD PortUP-dater


by I.S. van Oostveen and A. Abuseiris 05/06/04

document version: 1.0

website: http://portup.sourceforge.net






Table of Contents

1. The OpenBSD ports tree 3

1.1 The what and how 3

1.2 Release Schedule 3

2. Background 4

2.1 What's the use 4

2.2 Ease of use (aka for the lazy) 4

3. Goals 5

3.1 Primary Project Goals 5

3.3 Secondary Project Goals 5

4. The Application 6

4.1 Language 6

4.2 Reliability 6

4.3 Flavors 6

4.4 Remote updating 6

5. Package Management 7

5.1 Process of installing a package 7

5.2 Remote Packages / Getting Packages 7

5.3 Updating the ports tree 7

5.4 Package Views 7

6. Project Deadlines 8

6.1 Initiation 2004 8

6.2 Planning 8



1. The OpenBSD ports tree

1.1 The what and how

OpenBSD is a free multi platform 4.4BSD-based UNIX-like operating system. It's main focus is security, cryptography, freedom and auditing. http://www.openbsd.org

The OpenBSD ports tree is a collection of tools and files for installing additional software on a box running OpenBSD. Most files are control files and are written in BSD Make. These so called “Makefiles” allow the administrator to compile, install and remove software from the machine. The tools are to assist this purpose and are mostly used internally by the control files. Other operating systems like NetBSD, FreeBSD and Gentoo/Linux have a similar system for installing and maintaining applications. The best known is probably Gentoo/Linux version of the OpenBSD ports tree called Portage.

A directory which contains the Makefile together with information about the package, additional files and patches is called a “Port”. The binary (compiled) equivalent is called a “Package” and is stored in compressed tar file (e.g. .tgz).

1.2 Release Schedule

OpenBSD has a release schedule that covers 6 month's. This basically means that there are two new releases of OpenBSD each year, one on the first of May and the other on the first of November. With each new release comes a installer for all supported platforms, the complete source of the OpenBSD system and a ports tree for that specific release.

Most systems which use a ports tree for there packages, have one big tree that covers all versions of there Operating System. Due to the nature of OpenBSD each release comes with it's own branch of the ports tree. This branch is only updated when there are important updates, fatal flaws or security risks discovered in one of it's packages.

The reason for this is three-folded:

      1. Stability: if it ain't broke don't fix it.

      2. Security/Auditing: new versions can introduce new bugs and exploits.

      3. Man-power: auditing, updating and managing dependencies takes a lot of time.

After 2 release cycles a version of OpenBSD becomes unmaintained. This basically means that no further work is done on the source and no patches whatsoever are committed to the repository. People running such “old” releases are strongly advised by the OpenBSD crew to update to a more recent release.



2. Background

2.1 What's the use

The authors use OpenBSD for a lot different things from firewalls and cooperate servers to workstations and laptops. All these computer run typically a current stable OpenBSD system. The “thing” that makes them be a server, workstation, multimedia-box (top set-box) or whatever is solely the end-configuration of the system and the extra software installed on them.

2.2 Ease of use (aka for the lazy)

To ease keeping up-to-date with software installed, we set out to write a tool which automates this process. While for individual installs a few shells scripts would go a long way we wanted something that would help us automate the entire process. Not only installing and deinstalling software packages. But automatically checking for possible updates, keeping track of dependencies while updating, the possibility to notify a administrator with information about the updates/software status of a machine and beeing able to quickly reinstall a OpenBSD box, without having to install and configure all the installed software by hand all over again.

Closely related with running OpenBSD on a firewall, the tool should work for both local systems with compiler tools install as well as remote server without them.

From using OpenBSD in secure settings the need was seen to be able to update other/non-local machines which would not have compiler tools installed. Running a firewall without compiler tools makes the system so much more secure :-)

Being able to run a (remote) server without any compiler tools installed and still be able to easily update something like postfix or apache-modules.



3. Goals

3.1 Primary Project Goals
3.3 Secondary Project Goals


4. The Application

4.1 Language

The application should be written in a language which is supported by the base OpenBSD System without further need of any other additional programs.

Since version 3.6 the packages tools are rewritten in Perl. So the choice of which language to use is not hard. Perl is well known for its text-parsing capabilities and has proved itself as a useful language for system administration tools.

4.2 Reliability

When updating it must be assured that no problems will arise after updating. To assure this the following requirements must be met:

4.3 Flavors

Packages can have certain configurable optional functionality called “flavors”. Flavors are used to compile programs in specific ways and more then one flavor can be set for a package.

If a package for example has the ability to use SSL for networking then the user should set the FLAVOR=”ssl” option before compiling the port to include ssl functionality in the program.

To be able to support flavors on a package by package basis, the administrator can optionally insert flavor information to the configuration file of Port-Up.



4.4 Remote updating

For the first complete working version of Port-Up the decision was made to only do updating of remote hosts by running Port-Up from the remote host itself. This because of the difficulties of transferring all specific information about that host to the initiating machine.

This could be done in two ways:

  1. Manually running Port-Up on the remote machine with a configuration file on that machine, stating that it should download pre-compiled packages from a certain location if an update needs to be installed. In this case all packages that will be updated should be available on the location stated in the configuration file.

  2. Running Port-Up on a local/master machine and then using ssh to remotely execute Port-Up piping the configuration to it over the established ssh connection. The local machine could compile any non-existing updated packages locally and then push then over the ssh connection or let the remote machine download it be using another network protocol (ftp/http).

The first option is by far the most easiest solution, for version 1.0 of Port-Up this should be in there. The second option will follow closely in a release after 1.0.

In future versions a sort of master/slave mode for Port-Up would be preferable since that would give greater flexibility to how the update process is ran.

Another important thing to check when updating remote hosts is that the version number of the OpenBSD installation and the platform which it is installed on must be the same. OpenBSD supports a large number of different platforms to run on ranging from embedded computers, Intel (i386) and alpha machines to large Sun enterprise computers.

Since packages for different platforms are not compatible with each other it's important that the programs checks the versions number of OpenBSD and platform type before installing or updating a package.



5. Package Management

5.1 Process of installing a package

Each Makefile in the ports collection controls:

These controls layout the building plan for a port. When all steps are completed a package is successfully build. Then the last step for the controlling Makefile is to register the package to the system by using pkg_add.

5.2 Remote Packages / Getting Packages

Port-Up focuses on compiling sources from the ports tree, one of the important features to be implemented is the ability to update machines which do not have compilation tools themselves by using an other OpenBSD box and transferring the created packages to the machine(s) in question. Most important reason for this is, that normally firewalls/routers and other critical machines would not have compilation tools out of security considerations. Still packages that have fixes or security patches should be updated as soon as possible.


A large collection of packages is available from ftp mirror servers around the world. This is very handy for slow systems where compiling or downloading large packages is a problem.

5.3 Updating the ports tree

The ports tree itself, located normally under /usr/ports, must be updated before updating of the packages can begin. To ease the entire update process Port-Up must be able to download the newest version of the ports tree from the (Internet) network. Most commonly cvs is used for the ports tree, but other methods like cvsup, sup or downloading from a ftp mirror should also be available.

5.4 Package Views

A package view, is a complete list of all installed packages on the computer. With this a remote system can be updated without having any compiler tools installed. It is also used to reinstall all wanted packages on a machine after a clean reinstall or update of OpenBSD. Having a complete and definite list of all installed packages could also assist the administrator to check if unwanted packages have been installed on the machine.

6. Project Deadlines

6.1 Initiation 2004

The project was initiated in January 2004, originally the planning was to get a working version before the 3.5 release of OpenBSD which was in May 2004. Because of serious lack of time and an overestimation of the authors this was not possible. The new planning was set to complete the project before the end of the year 2004. At the time of writing a beta implementation of the update tool is working on the current 3.6 release of OpenBSD.

6.2 Planning

The current outline planning of the project is as follows: