FreeBSD divides itself into the base operating system and ports. The base OS contains core components while ports contain additional software. There are two ways to upgrade each - through binary packages or by compiling from source. Ports can be installed individually and have no hierarchy, but allow differentiation from the base OS and fine-grained control. The document describes a case study where multiple FreeBSD servers were used together for development, testing, and production in a synchronized way through a build master and CVSup server.

1. FreeBSD Software Management

2. Overview FreeBSD divides itself into two parts: the base operating system (the “world”) and the ports Open and NetBSD also do this, but in slightly different ways The world contains mostly the bits from /etc, /bin, /sbin, /usr/bin, /usr/sbin and some basic applications (login shells, a text editor) Ports are everything else, typically go to /usr/local (but this can be changed)

3. Base OS Two ways to upgrade the base OS: from binaries and from source Binary upgrades typically done from CD CD used can be either the release image from the FreeBSD project, or a custom-built one Source upgrades can be done per-machine, or built on one machine and distributed to a group Several versions within FreeBSD: RELENG, STABLE, CURRENT (and technology releases too, oh my!)

4. Ports Overview Like the base OS, ports can be installed from binary packages (freebsd.org) or built from source Source building has option to build binary packages, which can be distributed This allows for local customisations to be applied Ports have no concept of hierarchies such as xhier implements  - but it is possible they could be made to

5. What does this buy us? Differentiation between base OS and ports/packages means the latter cannot affect the former (less RPM-hell or SPs killing the OS) Relatively fine-grained control over all aspects of a system

6. Case Study: Offices of Development and Alumni Affairs We initially had one server (alumni), but wanted a development/test server (alumbak) as well Problem: how to keep them generally in sync, but allow for testing new releases and new applications? Built a third server, a “build master” (odaadev) Excess of hardware allowed for a fourth as well, a cvsup server (lowe)

7. Case Study – ODAA, part 2 lowe kept a copy of the CVS repository of FreeBSD sources (all versions, all ports) Pulled a copy to odaadev and built new releases (and packages) there Distributed built worlds and packages to alumbak for testing Once satisfied with setup, distributed same to alumni

8. Case Study: ODAA, part 3 Later, added a separate database server Distributed build system made making this DB server just like the others easy, but was flexible enough to allow for different kernels on the different machines

9. Applications at UW FreeBSD is well-suited (indeed, designed) for distribution across many hosts Challenge is adapting it to use in the UW environment Leveraging xhier a possibility, and there is a project team looking at this (early infancy)

10. Further Resources FreeBSD website: www.freebsd.org Daemonnews: www.daemonnews.org Mailing lists: freebsd-questions, freebsd-ports, freebsd-stable, freebsd-current Local resources: www.freebsd.uwaterloo.ca (Twiki hosted by Engineering Computing) Me!