Getting OpenBSD Source Code


This guide is meant to describe the various values used, so somebody new to CVS can understand what the values are used for.

For users getting “-stable” or downloading other (updated?) code from the “-release” branch, see the section about pre-loading to save time.

Those who are then familiar with CVS might be able to hazard going straight to running OpenBSD's CVS, although that skips quite a bit of material. If there's any difficulty, consider not skipping the material, and go through this guide.

[#oblcsclc]: Loctation(s) for the extracted local copy of the source code

Before obtaining the data, it simply makes sense to consider where the data will go. (The first section of this text lists where, and the second looks at how to prepare that section, to cause a speed increase when working with files.)

Where the required files ought to go
Files for the main operating system

The /usr/src/MAKEFILE for OpenBSD system source code says, “If at all possible, put this source tree in /usr/src.  If /usr/src must be a symbolic link, set BSDSRCDIR in the environment to point to the real location.

/usr/src is the location typically shown by documentation.

Examples of such documentation using /usr/src as the path include OpenBSD FAQ 5: section on “Fetching the appropriate source code” (section 5.3.3) and OpenBSD guide to Anonymous CVS (section on starting to use the software) and OpenBSD FAQ 10.15: the section on “Applying patches in OpenBSD”. OpenBSD FAQ 4: section on partitioning notes /usr/src may have its own partition, and this FAQ describes the location as follows: “This directory holds the basic system source files, excluding X and ports. This directory is empty by default, you have to load it as detailed in” documentation.

For the sake of maximum flexibility, the example command lines may make reference to the BSDSRCDIR environment variable. However, note that using an alternate directory may not have been fully tested by the initial author of this guide at the time that this documentation was written. Using /usr/src/ is what this documentation recommends, because that is what is recommended by the The /usr/src/MAKEFILE for OpenBSD system source code.

Note that if /usr/src is where the files are going to be extracted to, then the user performing the tasks will need certain permissions to the folder. (This shouldn't be a very big inconvenience for those who can easily run commands as a superuser.)

This directory (e.g. the /usr/src directory) may need certain permissions, such as allowing the wgrp group to be able to write to the directory. This should be taken care of from when OpenBSD was installed. If, for some reason, that wasn't the case, that needs to be fixed to prevent problems using the cvs client. (Details how to rectify this are in the section describing how to deal with problems with the cvs client.)

Files for X (Xenocara)

The simple answer, for those interested in simplicity rather than customization, is to use /usr/xenocara/. (The rest of this section describes details when using a different, customized, location.)

OpenBSD's “manual page” about building an OpenBSD release states, “Xenocara sources are supposed to be in XSRCDIR which defaults to /usr/xenocara.  This variable should be set in mk.conf”.

The man page for mk.conf says, “By default, this file does not exist, and must be created from scratch.” So, don't struggle too hard to locate an pre-created file which may not exist. If the file needs to be customized, simply create a file at the appropriate location.

If a customized (non-default) location is going to be used, be sure to edit the relevant file: OpenBSD's manual for mk.conf: section listing files suggests this is /etc/mk.conf (or /usr/share/mk/*, although /etc/mk.conf is more likely what commonly applies).

There is no particular need to manually set an XSRCDIR variable in the operating system environment. Any need to set such an environmental variable should be taken care of, automatically as needed, as long as the mk.conf file has the information that is supposed to be in that file.

There is a file (located at /usr/xenocara/README if a standard directory was being used, and available online via the “download” hyperlinks from CVSWeb for Xenocara: /usr/xenocara/README file) that says, “The variable XSRCDIR can be set either in the environment or in /etc/mk.conf to point to the xenocara source tree” when a non-standard location is used.

Files for ports (and the packages, since they're derived from ports)

OpenBSD's “manual page” about building an OpenBSD release section 1: “Update sources” does refer to “the path to your ports tree sources” as being “typically /usr/ports.” (That guide also refers to the actual path used by a name of PORTSPATH. It seems likely that may lead some people to set an operating system environment variable to that value, although the document didn't make any clear explicit reference to having such an environment variable.)

A complex example

Some of the examples may show this command line:

cd ${BSDSRCDIR:-/usr/src}/.. 2>> /dev/null || cd /usr/

That is certainly a lot more complicated than what is needed in most cases. It is believed that such complexity won't be a problem in most cases where this command line may be verbatimly copied and pasted into ksh, the default shell for OpenBSD. In most other cases, if default directories are being used, cd /usr will work just as well. Feel free to just type that, if manually typing.

Speed improvement

The OpenBSD FAQ 5: section on fetching source code states, “As the source trees consist of large numbers of mostly small files, turning on soft updates for the partition the source tree is on will often give significantly better performance.” This is an idea particularly aimed for users of FFS filesystem volumes who are not using sun4 or sun4c machines (but “sun4m machines are fine”). So, this information does not apply to other situations (such as if a different filesystem type/format is used). Those who are using FFS drives may gain some speed improvement by following the recommendation (using a method about to be described).

Note, however, there may be some considerations with using this. Namely, whether data may be more likely to be saved, or more likely to be lost, in the event that the system stops working (e.g. if there is a power outage). Further details are described in documentation about filesystems, in the section about FFS Soft Updates.

[#obsctplx]: Terminal Multiplexing

This is technically optional, but is worthwhile.

Run tmux; if that command isn't available, run screen; if that command isn't available, install software. Since tmux isn't likely installable, install screen. If there are multiple screen packages offered, the one that says “static” should work well, and may be less prone to being affected by having a piece of itself being upgraded.

Some commands, that will be run shortly, may be pretty automated and take minutes. In addition to whatever other output they show, the status bar of tmux will show what command is being run. If a command like cvs ends up running another command like ssh, the status bar will change.

There are other neat features with this software, including making the long processes able to complete even if a network connection becomes broken, providing scrollback, and probably providing the fastest ability to create a new command line shell that is logged in.

Pre-loading the local source tree
[#whyobpld]: Determining whether to pre-load the local source tree

Depending on what approach is being taken, “pre-loading” a local copy of the source code tree may be a required step for working with the source code. Even when pre-loading is not required, it is recommended. Pre-loading takes some time initially, but makes things go more quickly in the long run.

For those wanting to upgrade OpenBSD snapshots to newer OpenBSD -current code, the archives needed for pre-loading may not exist. (So, for this specific type of upgrade, pre-loading may not be an option.)

For those applying errata patches, pre-loading the local source tree is required (unless the source has already been fetched, such as from prior updates from usage of a CVS client -- however, that may be a slower method).

For others, this step may be completely optional since, eventually, “Anonymous CVS” may be getting used anyway. However,'s Guide to “Getting Started Using Anonymous CVS” (section on starting to use the software) notes, “While you can download the entire source tree from an AnonCVS server, you can often save a lot of time and bandwidth by "preloading" your source tree with the source files from either the OpenBSD CD or from an FTP server. This is particularly true” for people who are (or soon will be) using -stable. As an estimate (without much in the way of figures to back up the estimate), perhaps pre-loading may go 4 to 6 times faster. This is worthwhile if interacting with the computer and waiting for it to complete, as pre-loading will save time on the first source download (and also saves time for subsequent updates, especially when pre-loading is already done). (This might not be saving interactive time if the plan is to just start a CVS download over a broadband connection, and then to leave the automated process running overnight.)

Proceeding to pre-load the local source tree

More details about performing this task are in the section about pre-loading OpenBSD's local source tree.

Getting newer source code

The precise details will depend on what source code is used. For those wanting to use the latest “-stable” code, see this first section about Getting the latest source code (e.g. of the patch branch). Following that section is a tidbit about how to specify to get code for “-current” instead of “-stable”. Following all that is a section describing an alternative approach, which is to get the published eratta. (Getting the published eratta may actually be simpler than using CVS to get the latest “-stable” code. However, updating OpenBSD with source code from Eratta may cause the eratta approach to be less simple overall.)

[#obsdlcod]: Getting the latest source code (e.g. of the patch branch)

The following is mostly a guide of using the “patch branch” by obtaining the source code for “-stable”. Some additional information about other approaches may be scattered into this section. (Some information about using “-current” may also be included.)

What the updates will include

Naturally, this will depend on what updates get applied.

The “-stable” updates/patches
Operating system updates

OpenBSD's “manual page” about building an OpenBSD release says “This branch only contains errata, no new features.” OpenBSD FAQ 5: section about the operating system's “Flavors” (FAQ 5.1), subsection called “Upgrade vs. Update”, says about the “-stable” patch branch, “Updating is the process of applying patches to a system to improve the operation WITHOUT changing the basic functionality or binary compatibility.” “The update process is typically very painless, as no /etc files or other system configurations need to be changed.”

So, no major functionality change is expected. Some details about what can be expected may be available from the Errata pages.

Some OpenBSD Journal articles mention how many updates there are to -stable ports. How was that determined?
Upgrading to a recent version with functionality changes

Upgrading to a more recent “-release” version is one method. Another is to use recent code from the “-current” branch. OpenBSD FAQ 5: section about the operating system's “Flavors” (FAQ 5.1), subsection called “Upgrade vs. Update” calls this “upgrading” (rather than “updating”).

To determine what is new when upgrading, documentation is available. OpenBSD -current changelog basically shows the changes that are both new since the last -release, and considered noteworthy. The top of the web page showing the changelog for “-current” also provides hyperlinks to the changelogs for the various “-release” versions. Other documentation about what is new with each release is also available: the main home page at has a hyperlink to the page for the latest version of OpenBSD, which may be named something like for OpenBSD 5.0. More discussion about the release may be included in the Songs page. The “Recent Updates” section of OpenBSD's FAQ might also provide some clues about changes to the operating system. The OpenBSD Journal may occasionally discuss some highlights.

Overview of process

OpenBSD's official list of HTTP, FTP, RSYNC, and AFS mirrors documents the following about /pub/OpenBSD/src/: “This is a cvs checkout of our daily source tree for those who want to access individual files. Normally we recommend the use of AnonCVS instead of mirroring this location. Thus,” not all mirror sites will have an updated copy of this folder. The most famous OpenBSD distribution site,, may not even have that directory at all. Getting updated code view a protocol like FTP might be an option, although the code offered by the mirror might be more dated than what is distributed using CVS.

So, using CVS is recommended. Code publicly available may be accessed by using the “Anonymous CVS” service which doesn't require any sort of real identifying login.

One option is to use any sort of standard web browser to access the code, using a website called CVSWeb. (Perhaps similar/related: ports/devel/cvsweb located under and/or That may be the fastest and most convenient way to access the latest version of a single file, especially from a machine that does not have CVS software on it. However, this is probably not going to be the easiest way to get many files. Therefore, devising a method to automate getting files through this interface is not the recommended approach. Instead, the recommended method is to pre-load the source tree (which can be done using very standard methods of obtaining files) and then using specialized CVS tools to get the very latest code.

Using Anonymous CVS

One option, discussed here, is to use Anonymous CVS.

Example command line syntax
There are a number of pieces to customize on the command line. Here is an overview of the general syntax of a cvs command line:
cd ${BSDSRCDIR:-/usr/src}/.. 2>> /dev/null || cd /usr/
sudo time cvs -d $CVSROOT -t -z 9 checkout -P -r OPENBSD_TAG directoryToGet || echo Err=$? 2>&1 | tee -a /tmp/cvsget.log
This example may be getting changed now/soon, to the following:
{ sudo time cvs -d $CVSROOT -t -z 9 checkout -P -r OPENBSD_TAG directoryToGet ; echo Err=$? ; } 2>&1 | tee -a /tmp/cvsget.log
That syntax, and its description, are repeated in the section of actually running Anonymous CVS software, but one thing to clearly see is that there are a few things that need to be customized.
[#obacvsrt]: Deciding on a(n anonymous) CVS root

A decision that needs to be made is which CVS “root” location is going to be the source of information to download from. (The CVS ”root” refers to the location with the data, similar in concept to a web or FTP site.) A list of recommendable, publicly-accessible options is available at OpenBSD's list of Available Anonymous CVS Servers. On that web page, each available “root” comes after the phrase “CVSROOT=”. (The CVS “root” to be looking for contains a username, an at sign, a system name, a colon, and a path starting with a slash. Most use a path of /cvs but at least one has been known to use a different path, /OpenBSD).

So, go ahead and select an available server from that list of publicly available servers.

Although the CVS “root” may appear to start with a username, some may also include a protocol reference before the username. For instance, to use a protocol of “pserver”, the part before the at sign may look something like “:pserver:username”. (For example, with the Anonymous CVS roots that start with “anoncvs@”, the result may be “:pserver:anoncvs@”.)

If using the “Remote Shell” protocol (one of the “rsh protocols), set CVS_RSH to the executable used by rsh.

Having mentioned that, using the “pserver” protocol is probably not ideal for those who are planning to download source code and then start running that source code. The protocol may have less overhead, but also doesn't have the security features. (Then again, a case could be made that relying on SSH is not significantly better if the SSH key is compared to something published over HTTP, since the data obtained from HTTP could have been tampered with. It is a valid concern, at least in theory. However, once the client does verify the SSH key, if an attack hadn't yet been successful, then the saved key will prevent future “man-in-the-middle” attacks even when the source code is obtained at a later time. So, if the source code is obtained multiple times, at least there isn't a new vulnerability, that could be exploited, each and every time the source code is obtained. Of course, even just one vulnerability can be too many.)

The pserver may be a protocol with less overhead for some other examples, though, such as obtaining a copy of a file that is going to be manually reviewed. OpenBSD's Anonymous CVS guide: section showing examples of Anonymous CVS usage notes the “pserver is primarily useful for users who are behind firewalls that block the other” supported connection methods.

(Although OpenBSD's list of Available Anonymous CVS Servers does show some CVS roots supporting SSH on a port number other than 22, the cvs command does not pass the alternate port number to use. So, in order to use an alternate port number, the SSH client directly determine, without help from the cvs command, that another port needs to be used. That may be done by specifying the Host, and later on the desired TCP Port number, inside a $HOME/.ssh/config file. This is shown in more detail later. For now, the main point being made is that since the port is not directly determined by the cvs command, the port number is NOT part of the information that needs to be given to the cvs command. The port number is NOT specified in the CVSROOT environment variable.)

Later, a cvs command will be run. One option will be to specify the CVS root on that command line. If a CVS root is not specified on a command line, the program will look for the CVS root in an environment variable called CVSROOT. Therefore, another option is to just set CVSROOT at this time and then to not need to worry about specifying it on the command line later. To do this, first check if CVSROOT is already set. (It probably is not.) That may be checked by running “ echo $CVSROOT ”.

If it is still desirable to just store the root in an environment variable, then proceed with setting the environment variable. Details are available in the documentation about operating system environment variables: If a “Bourne shell” or compatible is being used then something like the following may work.
export CVSROOT

(That second line simply shows that the environment variable was properly set by the first line.)

For example, those who wish to download from Redwood City, California, a location with in the United States of America, may wish to use:

Note to those thinking that the above server would be good since it is in the United States of America: There are (or have been) multiple other servers in the United States of America. Therefore, the nicest approach to take is not to just copy the above example verbatim. Instead, take a little bit of time to review OpenBSD's list of Available Anonymous CVS Servers and locate the closest Anonymous CVS root.

Users of a Bourne-compatible shell may then want to run:

export CVSROOT
[#obcvstag]: Determining what CVS tag should be used

While the CVS root specifies where code should be downloaded from, a “tag” helps to further limit which code from that location is the desirable code to be downloaded.

OpenBSD tags
Common tags
OpenBSD “-stable”
export CVSTag=OPENBSD_$(uname -r | sed s/\\./_/)
Newer code from OpenBSD “-release” branch
export CVSTag=OPENBSD_$(uname -r | sed s/\\./_/)_BASE
export CVSTag=HEAD
Overview: further (older) details about these recommended tags
Using “-stable”

Those who are interested in using “-stable” will be wanting to use the tag that specifies to use the code from the “patch branch” for the specific version of OpenBSD. (The term “patch branch” may not be referred to quite as often as the “flavor” name of “-stable”, but references to the term “patch branch” do exist on pages such as OpenBSD FAQ 10.15: the section on “Applying patches in OpenBSD” and a hyperlink from OpenBSD's guide to Anonymous CVS: section on getting and updating a source tree.)

The name of the tag for the patch branch includes a reference to the version number of the operating system. As an example, a reference to OpenBSD 4.8's patch branch would use a tag of OPENBSD_4_8, while a reference to OpenBSD 5.0's patch branch would use OPENBSD_5_0 as a tag. (The format of the tag is seen in official documentation, by both OpenBSD's guide to Anonymous CVS: section on getting and updating a source tree and also OpenBSD's “manual page” about building an OpenBSD release.)

It may be possible to specify the version number in the tag a bit automatically, if the version of OpenBSD being obtained is based on the same “-release” as the version of the operating system that is running. Instead of specifying something like OPENBSD_4_8, a reference could be made to something like OPENBSD_$(uname -r | sed s/\\./_/) (if using ksh as a shell). That's a lot more typing than just typing out the version number, but this longer method may be better for automation, and for documentation like this (where an example can be quickly copied and pasted).

Getting code from the latest “-release” of OpenBSD

The tag that identifies code related to a “-release” has a name such as OPENBSD_4_8_BASE for OpenBSD 4.8. (This is described by OpenBSD's “manual page” about building an OpenBSD release).

It may be possible to specify the version number in the tag a bit automatically, if the version of OpenBSD being obtained is based on the same “-release” as the version of the operating system that is running. Instead of specifying something like OPENBSD_4_8_BASE, a reference could be made to something like OPENBSD_$(uname -r | sed s/\\./_/)_BASE (if using ksh as a shell). That's a lot more typing than just typing out the version number, but this longer method may be better for automation, and for documentation like this (where an example can be quickly copied and pasted).

Using “-current”

Those who are interested in using -current will need to specify that no tag should be used during the checkout command. (Details, about how to specify which tag will be used, are described in the following section about how to run the command.)

OpenBSD FAQ 5: section about “the best way to /etc, /var, and /dev indicates that for some uses other than checking out the data, referencing a tag of HEAD may be applicable for “-current”. FreeBSD guide to CVS Tags notes about the HEAD tag, “In CVS, this is the default when no revision tag is specified.”


Note: This guide was written primarily for OpenBSD. It may not have yet been thoroughly tested for use with FreeBSD. This section is smiply for convenient reference, especially in case much of this guide moves out of the OpenBSD section to a more generalized section related to CVS.

FreeBSD Handbook Appendix A.7: CVS Tags

[#obdrcvsc]: Know what directory of sources to obtain

While the tag helps to limit what is downloaded by specifying a version of the code, another way to download desired code is to specify a directory to run.

src is used to obtain the patch branch code for the main operating system. (That super-important directory is mentioned by OpenBSD's guide to following the “-stable” flavor and by OpenBSD's guide to Anonymous CVS: section on getting and updating a source tree. It also seems to be the focus of section 3 of OpenBSD's “manual page” about building an OpenBSD release.)

OpenBSD FAQ 5: section on Building X (Xenocara) (section 5.5) shows an example of downloading source code from a xenocara directory.

Running the Anonymous CVS software to initially get the new source code
Required info

Some information needs to be passed onto the software. Before looking at how to pass this information to the software, it makes some sense to perform an overview of what the required information is.

Connection info

Some of the information that cvs will need is how to connect to the source of the source code.

How the CVS root is specified

The cvs command will need to have a CVS “root” specified. (The details of a CVS root are discussed in the previous section.) There are two ways to specify the “CVS root” information. Choose one of the following methods.

Should this be moved to an area of how to apply the info?
How to specify the CVS root using the command line

One method is to include a “ -d ” parameter, followed by a parameter which is the CVS root information. One of the parameters on the cvs command line will need to be the “CVS command code”. (The term “CVS command code” is referring to the parameter that specifies which CVS command is going to be carried out by the cvs command line.) In order to specify the CVS root on the command line, boht the “ -d ” parameter and the following parameter (which is the CVS root information) must appear early on the command line, before the CVS command code. (There are also other command line parameters that need to exist only before, or only after, the CVS command code.)

So, if the CVS command code being used is (as an example) the abbreviation co, then the -d parameter, and the following parameter which is the CVS root, must occur before that co CVS command code.

Examples: “ -d ” or a less fictional example, “ -d

Using the CVSROOT environment variable to specify the CVS root

If the “ -d ” parameter does not exist before the CVS command word, then the cvs will look inside an environmental variable called “CVSROOT”. If that environment variable has valid CVS root information, then the cvs command will use that information. Otherwise, the cvs will not be finding its required data.

In all of the following examples that show “ -d $CVSROOT ”, the example may have no impact if that is literally typed on a command line. Such an example specifies that the program should use the value of the $CVSROOT environment variable, which is the default behavior that happens even if the command line doesn't have “ -d $CVSROOT ”. Despite being unnecessary, that syntax is shown in the examples for two purposes: one is to be a reminder that the CVS root needs to be specified, somewhere, and the other purpose is to demonstrate where the CVS root may be specified on the command line. The example commands will work just fine (if they are used by including the literal text “ -d $CVSROOT ”) as long as the CVSROOT environment variable is set.

(Actually, there is a case where “ -d $CVSROOT ” may have an actual effect. If a standard use starts a command with something like “sudo time cvs -d $CVSROOT ”, then the variable may get expanded from the command line before the sudo command takes over. This would be impactful if the sudo command causes the variable to be unset while running the specified command.)

OpenBSD's page about following -stable shows a syntax of “ -d$CVSROOT ”. This implies that the space character between “ -d” and the CVS root may be an optional character. (That has not been tested by the author of this text, at the time of this writing.)


Authentication requirements may vary based on what is required by the server. The authentication requirements depend on what protocol is going to be used to transfer the data.

Authentication requirements when using SSH

If the protocol being used is the default protocol of the cvs software, SSH, then there isn't any special behavior needed before running the cvs command that gets the data. The SSH client will by authenticated by the server by using the username that is part of the “CVS root” information.

However, standard SSH client behavior may apply, so the server may be authenticated by the SSH client. For instance, when connecting to a new server, the SSH client may ask for a key to be verified. The SSH client's requirement for interaction means that interaction is required when the cvs command runs that interactive SSH cleint. To handle those keys properly, the best advice is to prepare to verify the SSH key. Finding the proper key, in order to verify the key, may be discussed a bit further in the section about choosing the CVS root to connect to. For more details about verifying the key, see the section about how to verify the SSH key. If a server has multiple key types, the client can request using a specific key type. This may be done via a configuration file, and is discussed further in the section about how an alternate TCP port is specified. (For many standard SSH connections, another option to control the desired key type (and the desired alternate TCP port) may be to use command line options. However, that isn't quite as easy with the cvs command which doesn't provide those command line options. Perhaps command line options could be passed by somehow using the CVS_RSH environment variable and, if needed, using a script file?)

Authentication requirements when using pserver

If the protocol being used is the protocol called “pserver” (which may not be recommended, as discussed in the section about choosing a CVS root), then OpenBSD's Anonymous CVS guide: section showing examples of Anonymous CVS usage notes that “you must login once”. This may be done with a command such as:

cvs -d $CVSROOT login

That login session will prompt the end user for a password, and then the command writes to the CVS password file. That file is specified by the CVS_PASSFILE environment variable or, if that variable is unset (which is probably the case if there aren't remembered efforts to set it), a filename of ~/.cvspass is used. The file will contain the CVS root, a space, and then a hash of the password.

Specifying a TCP port to use for an SSH connection

First, determine the host name that will be connected to. (This is done by following the instructions in the section about Deciding on a(n anonymous) CVS root, and specifically the step of checking OpenBSD's list of Available Anonymous CVS Servers.)

If the CVS root specifies that the ssh protocol is being used, then the port may be safely assumed to be TCP port 22, unless a different port is specified. As a general case (unless customizations have been made), nothing special needs to be done to use TCP port 22. (If anything does need to be done, basically what is required is to remove the customizations that were previously made. The following steps, of how to customize this, may provide some assistance.)

As an example, we shall use with SSH port 2022. (Note that this process may not be required for this server, and many others, since TCP port 22 is also accepted by the same server. This example is simply showing how to perform the task of using an alternate TCP port, even though the task of specifying a different TCP port is not required by this server. In theory, at least, using a different TCP port might help if traffic using TCP port 22 is blocked (probably by a firewall located on the local side of the Internet connection).

Back up the file that is about to be modified, and then type the following commands.

echo Host >> ~/.ssh/config
echo "    "Compression no >> ~/.ssh/config
echo "    "Port 2022 >> ~/.ssh/config
echo "    "HostKeyAlgorithms ssh-rsa,ssh-dss,,,, >> ~/.ssh/config

Notes: The quotation marks in the above example simply cause the command line shell to place some nice white space in the file. Presumably the shell will eat those question marks up so that they don't actually show up in the text file. Of course, that might not work in a shell that isn't compatible with sh-compatible.

If there is a desire to make these parameters stored system-wide, then, instead of specifying to use a ~/.ssh/config file, use a ssh_config file in the appropriate directory for system-wide SSH changes. The appropriate directory to use is /etc/ssh/ for an original release of OpenSSH (e.g. version 4.0), but the directory may be different directory for some operating systems using a “-p” release (e.g. version 4.0p1).

The reason to specify Compression no is because this example is used to connect to a CVS server, and so this example is simply following the advice from the web page containing OpenBSD's list of Available Anonymous CVS Servers. The page says, “most anoncvs servers no longer accept the none cipher, as it is disabled in recent versions of ssh for security reasons. Also, do not be tempted to turn on compression: CVS already compresses.”

The HostKeyAlgorithms was meant to override the default of allowing/preferring ECDSA. This was desired because the SSH server was providing an ECDSA fingerprint, but OpenBSD's list of Available Anonymous CVS Servers did not yet show an ECDSA key for that particular server. So, the safer approach was to use a key type which had a documented key on the list of CVS roots. (This might really be unnecessary, and even undesirable, once the website is updated to publish the ECDSA key.)

Specifying what source code to get

A worthwhile step to getting the source code will be to make sure that the data that goes get obtained is the desired source code. Specifying what directories/folders of software to get, and which version of those directories/folders, will be needed. Those options are generally done in the opposide order of what was just mentioned.

[#getrtver]: Specifying what version to use

In addition to specifying what software to get code for, a typical action is to also specify what version of that software is desired. This is done by specifying a “tag” that is related to the desired version. The “tag” is provided by the maintainer of the source code repository.

Overview of tag specifying

Since a public CVS root on OpenBSD's list of Available Anonymous CVS Servers will/may have multiple versions of the source code, it will be critical to specify the correct CVS tag. (This documentation is about how to specify the desired tag. It is assumed that the desired tag is known, since actions have already been taken to determine what CVS tag will be desirable. So this text is simply about how to use the tag that has already been decided.)

The simple, yet extremely incomplete (and therefore misleading) answer is to use a -r tag. However, since that only discusses part of the picture, let's review the whole story.

[#clrcvstg]: Clearing any existing CVS tag

A tag is considered to be one of the values that is “sticky” between CVS sessions. Basically what that term “sticky” means is that a previously used value may be stored, and then that saved value may be used in subsequent command lines, even if the value isn't specified again. Therefore, be careful to make sure that the desired tag is what will be used.

If there is concern about a previous “sticky” value being used, add a -A parameter (apparently that goes somewhere after the checkout CVS command, or either of the synonymous CVS command codes, co or get). That parameter resets “any sticky tags, dates, or -k options” (according to OpenBSD's man page for the cvs: section about CVS COMMANDS, subsection about the “checkout” CVS command).

This -A parameter may be required to change the behavior of the cvs command. OpenBSD's Anonymous CVS guide: section showing examples of Anonymous CVS usage notes, “If you want to update a branch (such as a patch branch) to current, you would add the -A flag to cvs, but this flag is of little use otherwise.” The reason that this would be needed is that if a patch branch is used, then presumably a tag may have been remembered from when the patch branch was obtained. Then, when upgrading to -current, the expectation is that there should be no tag that gets used. To make no tag get used, any previous tag needs to be removed by using “ -A ” command line parameter.

OpenBSD's Anonymous CVS guide: section showing examples of Anonymous CVS usage notes about using the “-A” command line parameter, “Some older versions of the OpenBSD documentation recommended use of this flag in many examples. We no longer recommend this flag unless absolutely necessary.” (This is probably just so that desired “sticky” values are not routinely overridden, which could lead to accidentally losing the effect of some value that gets lost by being overridden.)

Specifying a tag to use

For OpenBSD 4.8 stable, the branch would be -r OPENBSD_4_8 while -current doesn't need to specify a -r switch. OpenBSD Guide to using Anonymous CVS (section on using the software) doesn't have a space after -r, but the OpenBSD “manual page” in section 1 for cvs does seem to suggest a space after -r.

Note that this “ -r TAG ” command line parameter must occur after the specified CVS “command” (like “checkout”) as that parameter is different than the different -r command line option that could be used before the CVS command.) Similarly, the order of command line parameters is important in that the -d shown in the example must occur before the CVS “command” word.

[#obruncvs]: Obtaining the source code

If this is a relatively new system (perhaps one that has not been rebooted very many times since the initial installation), it may be worthwhile to verify that the Internet is working as expected (with proper network address assignments, and routing). e.g.: “ ping

Also, making sure there is sufficient free space available will be sensible. OpenBSD/i386 5.1-current base (not including Xenocara or ports) requried about 827MB in /usr/src/. Such a number, though, may not reflect various other versions/flavors/platforms.

Make sure that the $CVSROOT and ${CVSTag} values are set.

To proceed with checking out, here is the general (EXAMPLE) syntax:

cd ${BSDSRCDIR:-/usr/src}/.. 2>> /dev/null || cd /usr/
sudo time cvs -d $CVSROOT -t -z 9 checkout -P -r OPENBSD_TAG directoryToGet || echo Err=$? 2>&1 | tee -a /tmp/cvsget.log
This example may be getting changed now/soon, to the following:
{ sudo time cvs -d $CVSROOT -t -z 9 checkout -P -r ${CVSTag} directoryToGet ; echo Err=$? ; } 2>&1 | tee -a /tmp/cvsget.log

Customize the directoryToGet as needed.

The main thing to customize in the above is the name of the directory to get. The guide may also specify to use “-A” after the word “checkout”, particularly if getting “-current”. (Using a tag of “HEAD” seems to work just as well.)

The -t parameter causes the program to be more verbose (allowing the user to trace the program's activity). The “ -z 9 ” causes compression to be attempted. (However, this may simply result in a message saying “server doesn't support gzip-file-contents”, and so end up not having any real impact.) Both of these are optional.

checkout is documented (by the man page) as being a synonym with co and get. That creates a location.

The usage of the time simply shows how long this process can take. That may be affected by factors including Internet speed, and how much data is being downloaded. (Pre-loading the files has been known to save over an hour on this step.)

The purpose of using the “ -P” option is meant to make sure that dirctories are kept in sync. (This is documented by OpenBSD FAQ 5#snake: section about when “make build” fails with “cannot open output file snake: is a directory.)

e.g. for OpenBSD's “-stable” patch branch, first find the RSA fingerprint from and then use the following example (which uses sed to help specify the version number). The following command lines may need to be adjusted to specifying what tag to download if getting code other than the latest version of OpenBSD-stable. People getting OpenBSD-stable updates to the kernel that is running may be able to use this example, exactly, without requiring modification.

cd ${BSDSRCDIR:-/usr/src}/.. 2>> /dev/null || cd /usr/
sudo time cvs -d $CVSROOT -t -z 9 checkout -P -r OPENBSD_$(uname -r | sed s/\\./_/) src || echo Err=$? 2>&1 | tee -a /tmp/cvsget.log
This example may be getting changed now/soon, to the following:
{ sudo time cvs -d $CVSROOT -t -z 9 checkout -P -r OPENBSD_$(uname -r | sed s/\\./_/) src ; echo Err=$? ; } 2>&1 | tee -a /tmp/cvsget.log

Those who are downloading “-current” will be using -A instead of “ -r OPENBSD_$(uname -r | sed s/\\./_/) ”.

If the program quickly quits with the error code, see the section about CVS client errors.

If the -t parameter is being used, text such as the following may show:

 -> main loop with
 -> Starting server: ssh -l anoncvs cvs server

Next, a connection is made with the remote server. This may be a rather invisible process, and may take a while (e.g. perhaps about 30 seconds) before the cvs displays any more output.

Dealing with verification
SSH Key verification

If cvs runs an SSH client, the SSH client may show some text related to the steps taken to verify the SSH key. The following is some example output from an interactive session. (The text exceeds 80 columns in width.)

The authenticity of host '[]:2022 ([]:2022)' can't be established.
RSA key fingerprint is 49:67:9a:46:62:8a:3f:4e:b3:63:ca:d6:41:29:2a:2f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[]:2022,[]:2022' (RSA) to the list of known hosts.

In the above example, the square brackets around the host name, and the colon that follows the right square bracket, and the TCP port number that follows that colon, are all text that may show up only when using an alternate port. If using the SSH protocol's default TCP port number, which is TCP port number 22, the text may look something more like the following:

The authenticity of host ' (' can't be established.
RSA key fingerprint is 49:67:9a:46:62:8a:3f:4e:b3:63:ca:d6:41:29:2a:2f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (RSA) to the list of known hosts.

Note: The log file may not show all of this output. Specifically, the “Warning” line may show, but the line that says “The authenticity of host '” ... “' can't be estblished.” and the next line, which shows the fingerprint, and the next line, which prompts whether to continue, may not end up showing up in the log. (It isn't certain by the author of this text why that is. Perhaps when cvs runs ssh, at least some contents of ssh are not having stderr being redirected?

Note: If there are problems around this stage of the process, read the later section about problems using the cvs client.

Example output from when things work well

If the -t parameter is being used, text such as the following may show something like the following:

server doesn't support gzip-file-contents
S-> cvs_write_tagfile(., , )
S-> Module-expansion src
S-> ok

It may or may not be an acceptable thing if the cvs program stops for a while after showing “S-> ok”. If the program continues, for a while (perhaps 5 minutes or longer), to show that as the last output line on the screen, see the section about problems using the cvs client. If this is the last output on the screen, check back in several minutes.

The program will then start writing files to the local hard drive. The following example output was caused using the -t parameter, when upgrading OpenBSD 4.9 to “-stable”.

S-> cvs_write_tagfile(src, OPENBSD_4_9, )
S-> cvs_file_walklist: element 'src/Makefile'
S-> cvs_update_local(src/Makefile)
S-> cvs_file_classify(src/Makefile, OPENBSD_4_9)
S-> cvs_checkout_file(src/Makefile, 1.115, 2) -> to client
S-> Set-sticky src/
 -> Create_Admin (., ., /cvs/src, , , 0, 1)
 -> unlink_file(./CVS/Tag)
 >- Create_Admin
 -> Updated src/
 -> rename(.new.Makefile,Makefile)
 -> Register(Makefile, 1.115, DOW Mon  D HH:MM:SS YYYY, , OPENBSD_4_9 )
U src/Makefile
S-> cvs_file_walklist: element 'src/Makefile.cross'

The following example output happened (after the S-> ok
line) when the process had been resumed (after being aborted).

 -> rename(CVS/Entries.Backup,CVS/Entries)
 -> unlink_file(CVS/Entries.Log)
 -> rename(CVS/Entries.Backup,CVS/Entries)
Positive Results

To identify positive results, one thing to do is to check the error/exit/return code/value. If using the example command line above, (manually) look for output, at the very end, which says Err=. If the above command line wasn't used, but if cvs is still the last thing that was run, then run “ echo Err=$? ”. Ideally, the desired results are to see that the return code was zero.

It may also be worthwhile to check the last few lines of output to see if everything looks good, or if it looks like the program was dealing with encountered errors.

It is possible that cvs's output may end with something like:

cvs checkout: dying gasps from unexpected

The text about dying gasps probably just means that the server ended up disconnecting the session. This output may be cuased by using the -t command line option that results in more output being shown. If the previous output looks like...

S-> ok

then that probably means the server successfully completed the previous operation. So, in summary, this probably means that this is a non-issue, so there is no need to worry about it. (It may, however, be worthwhile to verify that all mounted partitions have plenty of free space.)

But “dying gasps” sounds awful!

Okay, for those who want to know more about this:

CVS documentation: error messages states, “If you see the message, you probably can just retry the operation which failed”. A public blog post about CVS: dying gasps from server indicates that this was the best information found (when looking for details about this error). However, without different input, the output may be the same: the error may just repeat itself when the command is retried.

The text comes from the gnu/usr.bin/cvs/src/client.c file's “ get_responses_and_close ()” function which seems to be trying to close the connection. Therefore, the issue is simply that the client did not get a preferred response (and perhaps actually got no response whatsoever) from the server as the connection was going to be getting closed anyway. So, this likely isn't a terribly problematic situation.

Next Step(s)
[#gtxcrasc]: Getting updated Xenocara (X) source code
Checking/dealing with free space

Also, making sure there is sufficient free space available will be sensible. OpenBSD/i386 5.1-current's Xenocara (not including ports) requried about 600MB in /usr/xenocara/. Such a number, though, may not reflect various other versions/flavors/platforms.

If /usr/xenocara/ will not have enough space, see if any other partitions do have enough space. If /usr/src/ is a separate mount, using that may be a bit confusing (as an activity like removing and re-downloading /usr/src/ would delete Xenocara when removing /usr/src/). The /usr/local/ mount might be a spot with enough such free space (using default filesystem layout on an 8GB drive). Although this data doesn't consist of user binaries, and so might not fit within the spirit of that mount point, the Xenocara source could be removed after the Release is made. Therefore, this can be a temporary situation.

To perform such a workaround, if necessary, use:

sudo mkdir -p /usr/local/xenocrsc
sudo ln -s /usr/local/xenocrsc /usr/xenocara

After the specified directory (src in the above example) is completely downloaded, it may be desirable to obtain the source code for X (Xenocara). (That doesn't need to happen before building an operating system kernel and userland, and making a release of that data. However, there may be little reason to put off getting the xenocara source code. Doing so will allow a more full release to be made.) The syntax for that would simply be a change in the directory from which to obtain sources. For example, the following may work (by using sed to help specify the tag).

The following example command assumes that any previous steps have already been taken. (Especially, this refers to having CVSROOT already being properly set. Details are in the seciton about deciding on a(n anonymous) CVS root.) The following example shows a command to get the -stable code: other goals may involving changing the parameter after the -r command line to reflect what was decided when properly determining what CVS tag should be used.

cd ${XSRCDIR:-${BSDSRCDIR:-/usr/src}}/.. 2>> /dev/null || cd /usr/
cd ${BSDSRCDIR:-/usr/src}/.. 2>> /dev/null || cd /usr/
echo Older method: sudo time cvs -d $CVSROOT -t -z 9 checkout -P -r OPENBSD_$(uname -r | sed s/\\./_/) xenocara || echo Err=$? 2>&1 | tee -a /tmp/cvsget.log
This example may be getting changed now/soon, to the following:
{ sudo time cvs -d $CVSROOT -t -z 9 checkout -P -r ${CVSTag} xenocara ; echo Err=$? ; } 2>&1 | tee -a /tmp/cvsgetx.log

(Like the previous example, users of “-current” are sometimes shown a slighty different syntax, to use “-A” after the word “checkout”, and possibly instead of specifying a tag.)

Note: If the computer has plenty of resources (available disk space, CPU time, etc.), you may use the multitasking capabilities to perform another task such as compiling the “base” source code while getting the Xenocara source code. The “base” code and the Xenocara code are sufficiently seperate that compiling base shouldn't break the process of obtaining new Xenocara source code. (However, after base is compiled, before proceeding with the “Installing” phase, it may be worthwhile to check on the download progress. Certainly the part of rebooting the system could affect the downloading of Xenocara source code.)

[#obsprtsc]: Updating ports

Building updated ports source code may be a very separate step taken after the main operating system, and after Xenocara, are rather fully updated. However, if there is a desire to update ports, then a convenient time to run the command may be after the Xenocara (X) source code is obtained. This way, the command to update the ports can be entered by simply using command line history and then editing the command that was used to get Xenocara.

The following example command assumes that any previous steps have already been taken. (Especially, this refers to having CVSROOT already being properly set. Details are in the seciton about deciding on a(n anonymous) CVS root.) The following example shows a command to get the -stable code: other goals may involving changing the parameter after the -r command line to reflect what was decided when properly determining what CVS tag should be used.

cd ${BSDSRCDIR:-/usr/src}/.. 2>> /dev/null || cd /usr/
sudo time cvs -d $CVSROOT -t -z 9 checkout -P -r OPENBSD_$(uname -r | sed s/\\./_/) ports || echo Err=$? 2>&1 | tee -a /tmp/cvsgetp.log
This example may be getting changed now/soon, to the following:
{ sudo time cvs -d $CVSROOT -t -z 9 checkout -P -r ${CVSTag} ports ; echo Err=$? ; } 2>&1 | tee -a /tmp/cvsgetp.log

(Like the previous example, users of “-current” are sometimes shown a slighty different syntax, to use “-A” after the word “checkout”, and possibly instead of specifying a tag.)

Updating source code

This section was a bit hodgepodged, and so may benefit from a review for accuracy.

To later update the location, use update instead of checkout. Also, the method shown by “OpenBSD's Anonymous CVS guide: section showing examples of Anonymous CVS usage” is to first cd to the major directory that is being changed. (So, instead of going to /usr/ and then later specifying a directory to update, such as the src/ subdirectory, instead just cd straight to the subdirectory (e.g. the /usr/src/ subdirectory, or the /usr/ports/ subdirectory, depending on what is going to be getting updated). Then, use a d parameter after the command word. So, rather than using -P, instead use -Pd. (Read onto the next paragraph before trying this.)

When doing this, “OpenBSD's Anonymous CVS guide: section showing examples of Anonymous CVS usage” shows, “NOTE: If you are updating a source tree that you initially fetched from a different server, or from a CD, you must add the -d” parameter, followed by a valid CVS root, to the command line options. Specifically, those parameters need to be added before the command word (like “up”). So, instead of starting the command line with cvs up, start it with cvs -d $CVSROOT up (assuming that the $CVSROOT variable is properly set).

OpenBSD's “manual page” about building an OpenBSD release section 1: “Update sources” shows some command lines.

[#cvsclprb]: Problems using the cvs client
[#cvsclier]: Program aborts with complaint about invalid command line

If the program quickly quits with the error code like “ cvs: unknown option -- P ” then the command line parameter that is being complained about may not actually be anywhere close to the real problem. The quoted error is misleading, since the specified command line parameter doesn't really have anything to do with the actual problem (and there may be a few parameters between the pinpointed part that is blamed, and the part of the command line that actually does relate to the problem). Such phenomona (of not pinpointing the error very well) may be common with parsers, but often the problem is then reported by the next parameter. So, understand that when the cvs command seems to be blaming a specific parameter, the program may be making a wild guess, which is quite inaccurate, when the program determines what part of the command line to blame.

Perhaps the commmand line parameter being blamed is the first parameter after the “command word” (e.g. after a word like checkout). A possible cause is copying and pasting the previous command line, without first applying earlier instructions to set $CVSROOT.

Difficulties connecting

Note: If a previous cvs instance was aborted, be sure to check for any running instances of cvs or any called programs, such as ssh (but not sshd). If there are such instances, the connection may need to be terminated before the server will allow another attempt. Terminating the backgrounded programs may help allow connections sooner, as well as reduce likelihood of problems with an abandoned program possibly getting unstuck and then making unexpected changes. Once the backgrounded processes are stopped, the server may still take a small number of minutes (1? 4?) to figure out that the old connection should go away. An alternative to waiting for the server may be to use a different public CVS server (by specifying a different CVSROOT).

CVS freezes up after connecting

The first approach may be to wait a couple of minutes. The program has been known to seem frozen at or near the beginning, but then make progress. However, attempting to wait things out has been known to produce no results after several hours, so don't wait a very long time before deciding that it may be more sensible to take some further action.

[#cvsdrprm]: Checking permissions (even as a superuser)

If changes were made to the directory with the source code (e.g. the /usr/src/ directory), the issue may be a lack of local write permissions. This might even affect a superuser, as programs may drop some privileges and then be unable to perform the specified tasks. For instance, a superuser might make changes as a result of trying to deal with free space, including removing older content and then making a new directory. However, the newly created directory may be inaccessible, even to a superuser (since the program being run by the superuser may decide to drop excess privileges).

In theory, this might be able to be worked around using some configuration methods (like using a command line parameter, or setting an environment variable), but a better approach, if available, is likely to just set the permissions as needed. If the directory was created to be similar to /usr/ (which could easily happen due to permissions inheritance), it may belong to a group called “wheel” and not have group-writable permissions.

To see if that is an issue, run:

ls -ld ${BSDSRCDIR:-/usr/src}

If the permissions need to be changed, the following may work well:

sudo chown -R :wsrc ${BSDSRCDIR:-/usr/src}
sudo chmod -R g+w ${BSDSRCDIR:-/usr/src}

While at it, go ahead and check other directories, such as /usr/xenocara/ and /usr/ports/. (Naturally, if there is an issue with the permissions, make the needed changes.)

ls -ld ${BSDSRCDIR:-/usr/src}/../xenocara
ls -ld ${BSDSRCDIR:-/usr/src}/../ports
Deleting and starting over

Sometimes the following output has been seen:

 -> main loop with
 -> Starting server: ssh -l anoncvs cvs server
server doesn't support gzip-file-contents
S-> cvs_write_tagfile(., , )
S-> Module-expansion ports
S-> ok

Then, as unglorious as possible, the program just sits there, providing no further output that may explain what is happening.

The next desired step, which will hopefully be seen, may be to deal with a CVS tag. Something such as the following will probably not be seen if this problem is occurring, but would be desirable to be seen:

S-> cvs_write_tagfile(ports, OPENBSD_4_9, )
S-> cvs_file_walklist: element 'ports/.cvsignore'
S-> cvs_update_local(ports/.cvsignore)

The above example was from trying to update the ports directory to update to OpenBSD 4.9-stable. Naturally, the directory and tag may differ based on factors such as what is being updated.

Take the time to check permissions, even if the program is being run as a superuser, in case that resolves things.

If permissions aren't causing the issue, there is one (unpleasant) workaround which has proven to be effective. Delete the contents of the specified directory. (If updating xenocara/, just remove the contents of the xenocara/ directory. There is no need to also remove other directories like src/ or ports/.) Then re-run the cvs command. This approach offsets any benefit obtained by pre-loading the local source tree, but may complete successfully which may be faster than spending hours hoping that it gets unstuck on its own. Starting over causes things to start working, and even be done working, more quickly.


Once all the desired source code is obtained, if there isn't expected to be a need to re-download the source code or to upload newly changed source code (which would only be done by developers who are probably not going to be using an anonymous account to perform that task), then there's no particular reason to keep the CVSROOT variable defined. It may be cleared, for the sakes of being organized, freeing up a bit of memory used to store the enviornment variable, and preventing problems the next time CVS is used with a different server. Then again, leaving it defined is unlikely to cause any difficulties unless CVS is going to be used to contact a different server. (The variable will also likely become undefined when the user is fully logged off, including when the system is rebooted.)

Getting updated -current source code

Note that although getting “-current” may be about as simple as getting “-stable”, effectively using the code may be a more considerable proposition. Specifically, make sure to be familiar with the discussion about “-current” in the section about preparing for working with OpenBSD source code, most especially including the hyperlinked reference, at the end, which goes to Considerations, warnings, and potential problems related to using OpenBSD snapshots (and/or “-current”).

The process for actually getting recent “-current” code is extremely similar to getting the code for the patch branch. The only difference is to make sure to use the desired OpenBSD CVS tag. In some cases, that may require clearing any previously-remembered CVS tag by using -A. Additionally, in all cases, this most certainly involves making sure to correctly handle any option related to specifying which tag to use. In some cases, this may involve simply leaving off the -r and the tag. The section about using the desired OpenBSD CVS tag also notes that a tag called HEAD may be used. There. That's it. It is no different than that.

[#obgterta]: Getting Errata patches

There are likely to be (successful) attempts to ensure that the corrections known as Errata are included in newer versions of OpenBSD. Therefore, if the goal is to increase security, the first reasonable step is to make sure OpenBSD is using a version number which is at least the latest version number of -release. If not, upgrading to that relevant -release first will likely increase stability better than going to an older -stable. (See upgrading OpenBSD to a new -release.)

To see what erratta exist for a particular version of -release, see OpenBSD Release Errata & Patch List. That page has hyperlinks referring to different versions of OpenBSD, and the hyperlinked pages describe the Errata that is available for a specific release of OpenBSD. The top of each page (that represents a specific version of OpenBSD) also links to a *.tar.gz file, which is named after the version of OpenBSD that the Errata is for, and which is located on the OpenBSD FTP site, in the OpenBSD Errata/Patches area.

Errata for a particular “-release” version might exist on the web even before the “-release” version exists on the web. For those who pre-ordered the CD, they may receive the CD a bit early (perhaps by 10 or 14 days) before the “-release” is downloadable from the public web site. An Errata patch may be made as soon as the process of making the CDs is far enough long, so multiple Errata patches could exist even before people get their CDs. However, for a recent “-release”, there is even a possibility that there might not be any released Errata patches yet.