may2003.tar

Managing Third-Party Software Installation with pkgsrc

Jan Schaumann

Many systems administrators pride themselves on maintaining a plethora of different operating systems, however, when it comes to managing the installation of third-party software, nothing beats a homogeneous environment. Even with just one operating system to support, package management can be time consuming and frustrating. It can be difficult, and sometimes even impossible, to use only packages provided by a specific vendor; newer versions with added features are required, and security patches must be applied, yet the required version may not be available.

Installing software from different vendors can break dependencies among already installed or future packages. For example, consider the various RPM-based Linux distributions. It should be possible to install an RPM from Mandrake on a Red Hat or SuSE box, but they are often named differently, and a package that depends on foo-1.2.rpm, for example, may not correctly detect the installed foo-1.2.mdk3.rpm package.

Manually installing software can be cumbersome, and you can easily lose track of which software installed which files in which directories. Manual installation, however, has the advantage of allowing administrators to optimize software for the specific systems, which is why source-based package management tools are often the better choice. These tools automate the tasks of downloading, configuring, building, and installing the software, as well as tracking the location of the installed files. In this article, I will describe NetBSD's Packages Collection for efficient third-party software management.

NetBSD's Packages Collection, generally referred to as "pkgsrc", is a source-based package system. It can be found at:

http://www.netbsd.org/Documentation/software/packages.html

The collection was originally based on the FreeBSD Ports Collection, but has since evolved, and true to the spirit of the NetBSD Project, has been ported to other operating systems. Systems administrators can now take advantage of the large collection (more than 3400 packages at the time of writing) of available software not only on NetBSD, but also on Solaris, Linux, Darwin, FreeBSD, OpenBSD, and Irix. This makes pkgsrc ideal for package management in a multi-OS environment.

With pkgsrc, it is easy to maintain an identical user environment across several platforms, because all installed packages are of the same version and can conveniently be built from one centrally located source tree. Also, security audits of the installed packages can be automated through the use of NetBSD's "audit-package" package, which matches the list of installed packages against a published list of known vulnerabilities that is maintained by the NetBSD Security Officer. If a certain piece of software is known to contain a security hole, it can be easily detected, patched, and updated across all platforms without tracking down various operating system vendors to get the latest secure and stable version.

Installing pkgsrc

To use the NetBSD Packages Collection, you will need about 1500 MB of free disk space for the pkgsrc hierarchy and about 1500 MB of temporary disk space for extracting and compiling the various packages. A full set of binary packages currently requires approximately 1000 MB of disk space, but if you install a lot of software, you will require more. A system with more than 900 packages installed (including large packages such as KDE3, GNOME, or Mozilla) can easily use more than 3 GB.

Unless you are using NetBSD as the host operating system, you will need to download the "bootstrap-pkgsrc" kit from:

http://www.netbsd.org/Documentation/software/packages.html#bootstrap

to install the tools required to use pkgsrc on your platform. These tools include:

bmake -- This version of "make" is significantly different from GNU make (or "gmake") and other versions and its features are used extensively within the Packages Collection. bmake is a portable version of NetBSD's make, maintained by one of the NetBSD developers.
digest -- "digest" is a wrapper for the md5, sha1, and rmd160 routines and is used by pkgsrc to verify the integrity of a package's distfiles and any patches.
lukemftp -- This is the portable version of NetBSD's ftp client, named after its author Luke Mewburn. This version has many enhanced features compared to other ftp clients.
mtree -- "mtree" is a utility to compare directory hierarchies, useful for detecting trojans.
pax -- "pax" is an extremely powerful archive tool. On NetBSD, pax has replaced the traditional "tar".
pkg_* tools -- The "pkg_add", "pkg_admin", "pkg_create", "pkg_delete", and "pkg_info" tools perform the various administrative tasks on the pkg-system and binary packages.
Several default configuration files included by make.

While binary bootstrap-kits are available for several platforms, it may be preferable to build these tools from scratch to customize them for your specific environment. You can download the bootstrap sources from:

ftp://ftp.netbsd.org/pub/NetBSD/misc/grant/pkgsrc/

or retrieve them via cvs:

$ export CVS_RSH=ssh
$ cvs -d anoncvs@anoncvs.netbsd.org:/cvsroot checkout \
  othersrc/bootstrap-pkgsrc

Study the README files that are relevant for your OS and decide where you would like to install pkgsrc. If your OS is not listed, adjust the necessary files and submit your changes to:

http://www.netbsd.org/Misc/send-pr.html

or send them to the tech-pkg@netbsd.org mailing list. Then, install the tools by issuing the following command:

$ cd othersrc/bootstrap-pkgsrc
$ su
# ./bootstrap

The bootstrap process, and later pkgsrc, will install into /usr/pkg/ and register packages in /var/db/pkg by default, but you can specify other directories on the command line. For the purposes of this article, assume the default locations for your installation. This particularly makes sense for installations across several operating systems, and I recommend keeping /usr/local (another popular location) for system-specific programs and homegrown scripts truly local to the machine.

Once the bootstrapping process is completed, it is recommended that you copy the file mk.conf.example to /etc/mk.conf and adjust a few system-wide variables. In particular, add /usr/pkg/{bin,sbin} to your user's default PATH as well as /usr/pkg/man to the MANPATH. After that, it may be a good idea to read the rather extensive packages manual page (packages(7)) and set the appropriate variables for your environment in /etc/mk.conf, as explained later.

At this time, your system is ready to make use of the NetBSD Packages Collection. Download the pkgsrc tarball from:

ftp://ftp.netbsd.org/pub/NetBSD-current/tar_files/pkgsrc.tar.gz

and extract it into /usr/pkgsrc. Alternatively, you can use "cvs" to fetch the necessary files, which ensures that you retrieve the latest files with all the most recent changes:

# cd /usr
# export CVS_RSH=ssh
# cvs -d anoncvs@anoncvs.netbsd.org:/cvsroot checkout -P pkgsrc

You will need to have CVS and SSH already installed in order for this to work. Note that it is reasonable (and even desirable) to perform a barebones installation of your OS and then install all software using pkgsrc, including tools such as CVS, SSH, and Perl. If you are experienced in creating your own packages, it is possible to maintain an entire Linux system, for example, under pkgsrc by first performing a barebones install and then replacing the systems tools and libraries one by one with those from the packages collection.

Once you have extracted the pkgsrc files into /usr/pkgsrc, you will find more than 3400 packages in 42 categories available for your use. The extensive documentation provided in /usr/pkgsrc/Packages.txt should, together with the previously mentioned manual page, provide all the information necessary to install, maintain, and create packages.

Unless you have a homogenous environment, in which you can build packages on one host, install them, and then NFS export /usr/pkg, I recommend that you make /usr/pkgsrc an NFS share for the build-hosts. For example, suppose you have a NetBSD, a Linux, and a Solaris server and a mixed environment of workstations. In this case, you could export /usr/pkgsrc from the NetBSD machine to the Linux and the Solaris box, which would then export /usr/pkg to the appropriate clients.

Using pkgsrc to Install Software

Before you start installing software, you should set a couple of variables that apply to your environment in the file /etc/mk.conf (in addition to the variables already set by the bootstrapping process). Since some of these may be platform dependent, I recommend the following setup. In /etc/mk.conf of each build-host, only information that differs from the general setup is entered. Then, you can include a file from the NFS shared directory, where you can create a local hierarchy for your own modifications or packages. See Listings 1 and 2.

Assuming that you installed the NetBSD packages collection from ftp on a basic installation of your operating system, you'll probably want to install SSH (/usr/pkgsrc/security/openssh) and CVS (/usr/pkgsrc/devel/cvs). To do so, simply enter the following commands:

$ cd /usr/pkgsrc/security/openssh
$ bmake
$ bmake install

Then repeat these steps for CVS.

These three steps will do all the work for you and, as you will see, there is quite a bit of work to be done. To begin, the source files must be fetched, then the dependencies determined and, if necessary, installed (most notably OpenSSL and Perl, in this case), and OpenSSH must be built and installed. Meanwhile, the package's source files and the integrity of any patches are checked. Also, note that you can issue these commands as a normal user, as long as that user has write permissions to the pkgsrc directories and the work directories. The last step, bmake install, will perform what is referred to as "just-in-time su" (i.e., it will perform as many steps as possible without requiring superuser privileges, and will then prompt the user for root's password to actually install the files).

After installing the software, you can query and manipulate the package with the various tools -- pkg_add, pkg_admin, pkg_create, pkg_delete, and pkg_info. Refer to the manual pages installed during the bootstrap process for details.

Since you installed pkgsrc from ftp, the sources may be a few days out of date, so it is a good idea to update it before continuing to install packages. To do so, first clean the working directories (not strictly necessary, but good housekeeping practice) and update the tree using CVS:

$ cd /usr/pkgsrc/security/openssh
$ bmake clean-depends clean
$ cd ../../devel/cvs
$ bmake clean-depends clean
$ cd ../..
$ cvs update -dP

Alternatively, you could have done a bmake clean from the pkgsrc-root. Refer to Packages.txt and packages(7) for details on the various available targets. Note that you use the -d and -P flags for CVS to create any new and purge any obsolete directories.

It is recommended that you update your entire pkgsrc tree on a regular basis using this procedure. If you want to be informed of changes to the NetBSD Packages Collection, subscribe to the pkgsrc-changes@netbsd.org mailing list. It is also recommended that you subscribe to the tech-pkg@netbsd.org mailing list at: http://www.netbsd.org/MailingLists/.

Security and pkgsrc

Among the many features of the NetBSD packages collection, some are particularly important because they improve the overall security on your system. As mentioned, pkgsrc comes with the "digest" program to verify a package's distribution files integrity. The maintainer of a package generates the checksum for each of the files that need to be downloaded to build this package, as well as for any patches that are applied. This information is stored, together with the file sizes, in a package's "distinfo" file. When you start to build a package, the files are downloaded and their checksum is matched against the pre-recorded information. This ensures that the file has not been corrupted during the download and prevents accidental installation of a trojaned version of the software in question -- if the checksums don't match, the build is aborted.

With other traditional package management systems, it can be difficult to maintain an overview of which versions of software contain vulnerabilities. To solve this problem, pkgsrc offers a special package called "audit-packages", which performs automatic security checks.

The NetBSD Packages Team maintains an up-to-date list of package versions that contain security holes at:

ftp://ftp.netbsd.org/pub/NetBSD/packages/distfiles/vulnerabilities

"Audit-packages" downloads this list and matches any installed packages against those reported on this list, so it's easy to determine which packages need to be updated. Thus, it is highly recommended to install this package early on:

$ cd /usr/pkgsrc/security/audit-packages
$ bmake install

After that, adjust your crontab as suggested to automatically download the list of vulnerabilities on a regular basis. Furthermore, execute the installed script /usr/pkg/sbin/audit-packages together with your other regularly scheduled security checks.

When Problems Arise

Because pkgsrc has been developed for, and is used primarily on NetBSD, you may encounter minor problems when trying to compile a package for your non-NetBSD OS. In the majority of the cases, these can easily be fixed by adding the appropriate conditionals to the pkgsrc Makefile (/usr/pkgsrc/<category>/<pkgname>/Makefile). For example, lang/sun-jre13/Makefile.common contains the lines:

.if ${OPSYS} == "NetBSD"
DEPENDS+=       suse_compat-[0-9]*:../../emulators/${SUSE_DIR_PREFIX}_compat
DEPENDS+=       suse_x11-[0-9]*:../../emulators/${SUSE_DIR_PREFIX}_x11
.endif

.if ${OPSYS} == "Linux"
NO_PATCH=       # defined -- no need for patches on Linux
.endif

This indicates that, if the package is built under NetBSD, the Linux-emulation packages are required. On the other hand, if the package is built on Linux, no patches are required, so this step can be skipped in the build-process.

As another example, assume that you know that a package should not be compiled with any optimization under Irix. To achieve this, include the following in its Makefile:

.include "../../mk/bsd.prefs.mk"
.if ${OPSYS} == "IRIX"
CFLAGS:=                ${CFLAGS:C/-O[0-9]*/-O0/}
.endif

After making these modifications and verifying that everything works well, you can submit your changes for other people to note. To do so, generate a diff against the CVS repository:

$ cvs diff -bu > /tmp/<pkgname>.diff

and submit it to the packages maintainer via email or through the Web at http://www.netbsd.org/Misc/send-pr.html.

Tricks and Tips

While the NetBSD packages collection contains excellent documentation, there are plenty of tips on the tech-pkg@netbsd.org mailing list. Here is some additional information you may find useful:

If you want to update a certain package on which many other packages depend, I recommend using the "bmake replace" target rather than "bmake update". The latter will remove the package along with all packages that depend on it, thus forcing a rebuild of all those packages. This can lead to the system being in an inconsistent state for a long period of time (e.g., if the update of a basic library forces the rebuild of most of the other applications). If it is known that the dependencies will be able to deal with the new version of the library (e.g., no change in major version number, but an important security fix), "bmake replace" can update that package in place. "bmake replace" requires the package "pkgtools/pkg_tarup" to be installed.
Per default, pkgsrc installs all applications that use X11 into ${X11BASE} (/usr/X11R6, usually). If you want to use the installed packages on several hosts but only want to NFS export the /usr/pkg hierarchy, or to keep your third-party vendor software in one place rather than two, you can do so by installing pkgtools/xpkgwedge before installing any X11 application.
If you are building your own packages, look at the various packages available in the "pkgtools" directory. It contains many tools that complete or simplify otherwise tedious tasks.
If you know the name of a package you want to install, but do not know the category it is in, you can easily find the right directory through this little trick:

$ cd /usr/pkgsrc/*/<name>

Because all packages are uniquely named, this should get you to the right location.

You can sort the list of mirrors according to your geographical location using the MASTER_SORT variable. Alternatively, you can use MASTER_SORT_REGEX for more control. These variables and many others are described in /usr/pkgsrc/mk/bsd.pkg.defaults.mk.
When debugging a package, it is often useful to check the value of a given variable using the "bmake show-var" target $ bmake show-var VARNAME=DISTFILES.
To get a visual representation of all your installed packages, their dependencies, and any update- or security-related issues, install pkgtools/{pkgdepgraph,lintpkgsrc} and graphics/graphviz, then run:

$ lintpkgsrc -i > pkgdepgraph.in
$ audit-packages >> pkgdepgraph.in
$ pkgdepgraph -clv pkgdepgraph.in > pkgdepgraph.dot
$ dot -Tps pkgdepgraph.dot > pkgdepgraph.ps

Conclusion

The NetBSD Packages Collection allows for simple yet efficient third-party software management on a variety of platforms. As with any change, moving from another package management system to pkgsrc may initially feel unfamiliar, but the ease of use, advanced features, and extensive support provided through the mailing lists can quickly convince systems administrators to adopt and deploy pkgsrc across their systems. The many available packages continue to grow, patches to the packaged software continue to develop, and wondering which file belongs to which package and where packages are installed become distant memories.

Resources

NetBSD packages collection (pkgsrc): http://www.netbsd.org/Documentation/software/packages.html

Bootstrapping pkgsrc: http://www.netbsd.org/Documentation/software/packages.html#bootstrap

Bootstrap sources: ftp://ftp.netbsd.org/pub/NetBSD/misc/grant/pkgsrc/

NetBSD problem reports: http://www.netbsd.org/Misc/send-pr.html

Pkgsrc tar files: ftp://ftp.netbsd.org/pub/NetBSD-current/tar_files/

NetBSD mailing lists: http://www.netbsd.org/MailingLists/

Vulnerabilities: ftp://ftp.netbsd.org/pub/NetBSD/packages/distfiles/vulnerabilities

Jan Schaumann works as a system administrator in the Department of Computer Science at Stevens Institute of Technology in Hoboken, NJ, where he has the privilege of maintaining a large, almost homogenous NetBSD environment. To simplify his work on the few non-NetBSD machines under his supervision, he recently brought the Packages Collection to Irix and continues to use it on Linux. Jan joined the NetBSD Project as a developer in January 2002 and can be contacted at: jschauma@netmeister.org.