1. FreeBSD Software Management

2. WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Automagic Software Management 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. WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Automagic Software Management 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. WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Automagic Software Management 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. WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Automagic Software Management 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. WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Automagic Software Management 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. WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Automagic Software Management 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. WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Automagic Software Management 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. WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Automagic Software Management 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. WatITis | Collaboration in a Distributed Environment | December 2, 2003 | Automagic Software Management Further Resources FreeBSD website: www.freebsd.orgwww.freebsd.org Daemonnews: www.daemonnews.orgwww.daemonnews.org Mailing lists: freebsd-questions, freebsd-ports, freebsd-stable, freebsd-current Local resources: www.freebsd.uwaterloo.ca (Twiki hosted by Engineering Computing)www.freebsd.uwaterloo.ca Me!