Upgrades from Source


Upgrading from source is intended only for advanced users who are not afraid of compiling C, debugging problems, and restoring from backup. It's also the only way to get the very latest development and stable versions of OpenBSD, so it's worth learning about.

When you upgrade from source, you are essentially building the distribution sets that you installed during the CD-ROM or FTP install. They aren't bundled up as distributions, but the contents are the same. You'll still have to run mergemaster(8), and you will still need to update your installed software. The only thing building your system from source gets you is the latest version of the branch you're using.

Source Code Distribution

The first task you need to perform when building the system from source is getting the source code. The OpenBSD Project uses CVS (Concurrent Versions System) to maintain its source code repositories. When a developer implements an improvement he integrates this change into the CVS repository, which is distributed and mirrored across the world in a matter of hours. The master CVS server tracks source code, all changes made to it, and who made those changes; developers can "check in" new code, and users can "check out" the latest versions. As a user on any OpenBSD architecture, you can use CVS to get the latest version of the source code.

CVS is a decent tool for source-code management, but is a lousy tool for source-code distribution: It requires huge amounts of system resources and bandwidth and tends to chew up the server's hard drive. CVS has a more efficient older brother, CVSup — a combination of CVS and sup, the Software Update Protocol. Compared with CVS, the CVSup protocol is much faster, more efficient, easier on the servers, and generally nicer when supporting millions of users scattered around the world. It also only runs on the i386 architecture as of this writing. (Unfortunately, CVSup is written in Modula-3, which is difficult to port to new architectures.)

Because i386 is by far the most popular OpenBSD architecture, we'll consider both methods. Before that, however, let's look at some of the terms that both CVS and CVSup share.

Source Code Repositories

OpenBSD's source code is divided into repositories, or collections of code for particular subsystems. You only need to download and synchronize the collection that you want to use. The five repositories included in the OpenBSD include the following.

  • src contains all the source code for the OpenBSD core operating system.

  • X11 contains the XFree86 release 3, adapted for OpenBSD (mostly obsolete).

  • XF4 contains XFree86 release 4, as adapted for OpenBSD.

  • ports contains the OpenBSD ports tree.

  • www contains the OpenBSD website.

You only need to update or install the collections for the components you want to use. For example, if you only want to update your base system and your ports tree, grab just the "src" and "ports" repositories. If a new version of X is released, you may wish to grab the X11 and/or XF4 collections. Only those people interested in editing the OpenBSD website need the www collection.

If at all possible, you want to start with a recent version of these collections from the most recent release. This will save considerably on download time and bandwidth when making your first update; it's quickest to update a collection of source code that exists, rather than downloading the whole collection a piece at a time. We've already discussed installing the system source code and ports collection in Chapter 5, and the www collection is not generally available as part of a release, but the XFree86 version 4 source code is available as a tarball with each release. Just grab the XF4.tar.gz tarball from the FTP site or the CD-ROM and extract it directly under /usr. Here, we take the XF4 collection right off of the CD-ROM.

 # cd /usr # tar -xzf /mnt/XF4.tar.gz # 

Tags

A tag is a label for a particular version of a collection of the "src" repository. Each different branch of OpenBSD-stable has a tag indicating which set of code it represents. When you update your source code, you will want to be absolutely certain that you use the correct tag!

For example, OpenBSD 3.3-stable has a tag of OPENBSD_3_3. The tag is just the word "OPENBSD," with the version numbers separated by underscores. This is expected to be consistent in the future — even though it isn't released yet, we can easily guess that the tag for OpenBSD 3.8 stable will be OPENBSD_3_8. OpenBSD-current has no tag.

Using the correct tag is very important. If you use the wrong tag, you will get the source code for the wrong version of OpenBSD. For example, if you're trying to get the source code for the latest OpenBSD-stable but do not include a tag, you'll get OpenBSD-current instead. If you use a tag that does not exist — e.g., try to get OPENBSD3_4 instead of OPENBSD_3_4 — you'll delete all the files in your local copy of that repository.

Mixing Repository Versions

Tags are not used for the XF4, X11, ports, or www repositories. These are assumed to be synchronized to OpenBSD-current at all times. Once a version of OpenBSD is released, these tools are assumed to be complete for that release and are not updated further.

Only the src repository is branched into stable and current. The ports tree is tightly tied to the version of OpenBSD and is synchronized to current. A current ports tree will not work reliably on an OpenBSD-stable system and can in fact cause much grief. It doesn't matter if the ports tree repository is only a few months older than the source repository; compiler and header changes can render it dysfunctional or useless. If you mix repository versions, you're on your own.

Similarly, the XFree86 collections track current, not stable.

You can update the www collection at any time, but the documentation it contains is assumed to track current as well. Incorrect documentation can cause as many headaches as incorrect code.

In short, if you're tracking stable, only update the src repository!

Source-changes@OpenBSD.org

Every change made to any source code repository, on any branch, is announced on the source-changes@OpenBSD.org mailing list. If you are running OpenBSD-current, you really need to read this mailing list, as often this is the only announcement of new features, bugs, or other points of concern. An OpenBSD developer may well break some vital system function and announce it only via the source-changes mailing list. If you miss the update here, you can destroy your data or render the computer unbootable until you get the information you should have read in the first place!

Here's a typical message sent to source-changes for a major change:

 CVSROOT:        /cvs Module name:    src 1 Changes by:     henning@cvs.openbsd.org 2002/11/18 15:49:15 2 Modified files:         sbin/pfctl     : Makefile parse.y pfctl.c pfctl_parser.c                          pfctl_parser.h 3 Added files:         sbin/pfctl     : pfctl_altq.c pfctl_altq.h 4 Log message: altq and pf merged 5 this isn't 100% done yet: the print_ stuff isn't finished, some features will be added later, and there is no documetation yet, but committing now enables a few more people to work on. 6 print_altq_node stuff hacked by Daniel at euroBSDcon; lotsa stuff from kjc, debugging help also pb and camiel. lots of good ideas by theo. 7 "commit now" theo philipp daniel 8 

The first important thing we see is 1 which repository this change affects. This message represents a "src" repository change. To get this update, you would update your local src repository. We are also shown which 2 committer made the change, at which time. We're shown which files are 3 modified by this chang and which have been 4 added. If files had been removed, we would see those as well. Then there's the real meat of the message: the 5 nature of the change. Many commit messages end here, but this one goes on to explain some of the 6 problems and missing pieces in the commit. Various people are given 7 credit for their work on this feature. Finally, we are told why this incomplete work is being placed in the main tree — the committer was 8 urged to do so by a whole list of people. Not all commit messages are this complete, but not all commits perform this sort of wholesale surgery to a major system component.

If you were updating from source to the latest version of OpenBSD and were using altq or pf, this commit would have made your life very difficult. While the missing functionality will be restored, later, at the moment you are stuck. Even if the functionality you need is still there, the way it is used has changed. If you were reading the source-changes mailing list, you can decide if you want to upgrade or not. If you weren't, you're going to have a very bad day.

CVS Setup

To use CVS, you must be able to connect to an anonymous CVS server. You can get a complete list of official anonymous CVS servers at http://www.OpenBSD.org/anoncvs.html. This list includes the physical location of the servers, how often the server is updated, and the appropriate environment variables needed to connect to it.

While CVS can be very complicated if you're using every feature it offers to its fullest extent, to update your source code from an anonymous CVS server you only need to configure the client portion. The simplest way to use cvs(1) for our purposes is to set the environment variables CVSROOT and CVS_RSH, which will make the commands you have to type much shorter and simpler.

CVS_RSH instructs cvs(1) to use the correct network protocol when it issues commands to the CVS server and then how to transmit the patches back to the client. This defaults to "ssh," so if your anonymous CVS server permits this protocol, you don't need to set this to anything. Almost all OpenBSD anonymous CVS servers support SSH. If you cannot SSH out of your network (unlikely, but possible) you might try to use CVS_RSH=rsh instead. Updates will not be encrypted as they cross the network, but this is not generally a concern for source code updates.

CVSROOT tells cvs(1) where to go to fetch source code updates. Despite how long this variable can be, the actual interpretation is fairly simple:

 username@server:directory 

Some anonymous CVS servers support a protocol called "pserver," which runs on TCP port 2401. This protocol is most commonly used when firewalls block both SSH and rsh. You do not have to set a CVS_RSH variable to use this; instead, the pserver method is specified in the CVSROOT variable. You'll see examples on those few servers that only support the pserver method.

In general, if you leave CVS_RSH at the default and just set CVSROOT from the anonymous CVS mirror listing, you will be able to update your repositories.

Running CVS

Once you have chosen an anonymous CVS server, running CVS itself is trivial.

 # cd /usr # cvs -q get -P -rtag 1 repository 2 

You just need to fill in the CVS 1 tag and the 2 repository you want to grab. Note the lack of a space between the -r and the tag. For example, to grab the latest OpenBSD 3.2 source repository, you would run:

 # cvs -q get -rOPENBSD_3_2 -P src U src/gnu/usr.sbin/sendmail/smrsh/smrsh.c U src/kerberosV/src/kadmin/version4.c U src/lib/libc/net/getnetnamadr.c U src/share/zoneinfo/datfiles/southamerica ... 

Each file listed has been updated since the last time I updated this source code. In this case, I'm updating the source code as distributed with OpenBSD 3.2 to 3. 2-stable. You'll also notices as CVS finds files that have been removed from or added to the repository.

Be warned; there may be a delay of several minutes between starting the command and seeing updates start to arrive. The cvs(1) program is not a very well-optimized tool for downloading source code. If you want the latest and greatest downloading tool, and you're on i386 hardware, run cvsup(1) instead.

CVSup Setup

If you're running on the i386 architecture, update your repositories with CVSup instead of CVS. CVSup is much faster and more efficient than CVS, is easier on the server, and consumes less bandwidth than vanilla CVS. You can install CVSup from /usr/ports/net/cvsup.

CVSup uses a configuration file, also called a supfile, which identifies which repositories it should update, the servers it should use, and how the updates should be made. This supfile is generally stored as /etc/supfile. Once you have created a supfile, you can continue to use it forever. The supfile has the following basic entries:

 1 *default release=cvs 2 *default delete use-rel-suffix 3 *default umask=002 4 *default host=cvsup.usa.openbsd.org 5 *default base=/usr 6 *default prefix=/usr 7 *default tag=OPENBSD3_2 8 *default compress 9 OpenBSD-src 

Generic configuration options begin with an asterisk. The 1 first entry tells CVSup that it is talking to a CVS repository. While this is the most common sort of repository to be used with CVSup, it is possible to use CVSup with other sorts of repositories. We then tell CVSup that it is to 2 delete files that are no longer in the master repository and that all of the directories specified are relative instead of absolute. We set a 3 umask of 002 for the times that we do touch files.

You then need to set a 4 CVSup server. CVSup is not the same as CVS, and you cannot run CVSup off of a CVS server. You can find a complete list of official OpenBSD CVSup mirrors at http://www.OpenBSD.org/cvsup.html. There are far fewer CVSup mirrors than CVS mirrors, but the CVSup mirrors do far less work to service each user, so things even out.

The 5 base is the location where CVSup keeps its status files, including a list of updated files, so it can accelerate further updates. It will create a directory called "sup" under this directory for these files. If you set this to /usr (the default), your updates will be stored in /usr/sup.

The default 6 prefix is the directory tree where the repository you've chosen will go. If you want to use the standard OpenBSD locations of /usr/src, /usr/XF4, and so on, set this to /usr.

The 7 tag is the CVS tag you want to use. In this example, we want to grab OpenBSD 3.2-stable. Remember, tags are only used for the main src collection; the other repositories only have a current branch! If you do not specify a tag, CVSup will assume you mean current.

The default 8 compress keyword tells CVSup to compress data before sending it across the network. If your connection is a T1 or faster, compressing the data isn't that important, and you can remove this entire line, which will reduce the CPU load while increasing the bandwidth needed. Because today's processors are usually much cheaper than bandwidth (in North America, at least), there are very few circumstances where not using compression makes sense.

Finally, we tell 9 CVSup which repository to update. Not all CVSup mirrors carry all the repositories, so be certain you check the mirror list! You have the following choices:

OpenBSD-src

The src repository

OpenBSD-www

The www repository

OpenBSD-ports

The ports repository

OpenBSD-x11

The XFree86 version 3 repository

OpenBSD-xf4

The XFree86 version 4 repository

OpenBSD-all

All available OpenBSD repositories

If you want to track OpenBSD-current, do not define a default tag in your supfile. Remember, you can choose to track stable, in which case you only want to update your src repository, or you can choose to track current, in which case you can update any repository.

Running CVSup

Now that you have a configuration, you can run cvsup(1).

 # cvsup /etc/supfile 

If you're running X, cvsup(1) will open a GUI on your display. (The "-g" option tells cvsup to not open the GUI, but just print its results on the terminal.) If you have the GUI you must hit the green arrow to start the update process, but with the "-g" flag cvsup(1) just starts going. The output is similar to that from cvs(1), but the whole process runs much faster.




Absolute Openbsd(c) Unix for the Practical Paranoid
Absolute OpenBSD: Unix for the Practical Paranoid
ISBN: 1886411999
EAN: 2147483647
Year: 2005
Pages: 298

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net