Your SlideShare is downloading. ×
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply



Published on

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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 ( 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:
    • Daemonnews:
    • Mailing lists: freebsd-questions, freebsd-ports, freebsd-stable, freebsd-current
    • Local resources: (Twiki hosted by Engineering Computing)
    • Me!