Keeping FreeBSD Applications Up-To-Date

by Richard Bejtlich

This is a sequel to my previous work Keeping FreeBSD Up-To-Date.

This article presents multiple ways to keep FreeBSD applications up-to-date. I explain how to install and upgrade several applications on a FreeBSD 5.2.1 RELEASE system. In my previous article "Keeping FreeBSD Up-To-Date," I described how to patch and upgrade the FreeBSD operating system, beginning with FreeBSD 5.2.1 and ending with FreeBSD 5-STABLE. Taken as a pair, these two articles will help system administrators keep their FreeBSD OS and applications current and defensible.

I chose FreeBSD 5.2.1, released in February 2004, as my reference platform because the applications bundled with it have been updated several times in the past ten months. These updates provide good material for the case-based approach used in this article. All of the techniques explained here work on the most recent FreeBSD version, 5.3.

All of the work done in this article was done remotely via OpenSSH. One danger of performing remote upgrades is losing connection during a critical phase of the process. One software-based way to deal with this issue is to conduct all remote upgrades within a screen(1) session. [1] Should you lose connectivity during the upgrade while running screen, your session will continue uninterrupted. The screen(1) program has suffered security problems in the past, so balance its features against the possible risks.

My advice on upgrading these applications is based on deploying FreeBSD on servers, workstations, and laptops since 2000. The article represents a mix of my interpretations of official FreeBSD documentation, inputs from mentors, and the result of my own experimentation and deployment strategies. This guide cannot be anywhere near a complete reference on keeping FreeBSD applications up-to-date or maintaining secure software. I strongly recommend reading the excellent FreeBSD Handbook as well as the multiple helpful published books on FreeBSD.

Third party applications may be installed using source code, the FreeBSD ports tree, or precompiled packages. Each will be described in detail, but not exhaustively. The tips here are enough to get the novice to intermediate system administrator managing applications on FreeBSD.

Installation Using Source Code

Source code is typically packaged as an archive processed by the tar(1) and gzip(1) programs, with the .tar.gz or .tgz suffixes. In the following example, we install the Snort output reader Barnyard from source code. Until further notified, we take these actions as a user and not as root.

As a good system administration practice, one might want to create a specific directory to hold source code for third party applications. Creating /usr/local/src is the method used here.

freebsd521$ mkdir /usr/local/src

Next we download the Barnyard tarball with fetch(1), after visiting the Barnyard project page and locating a suitable distribution site. [2]

freebsd521$ fetch http://kent.dl.sourceforge.net/sourceforge/barnyard/barnyard-0.2.0.tar.gz
Receiving barnyard-0.2.0.tar.gz (161543 bytes): 100%
161543 bytes transferred in 6.6 seconds (23.78 kBps)

Now extract the contents of the archive:

freebsd521$ tar -xzvf barnyard-0.2.0.tar.gz 
barnyard-0.2.0/
barnyard-0.2.0/docs/
barnyard-0.2.0/docs/BUGS
...edited...
barnyard-0.2.0/src/input-plugins/dp_stream_stat.h
barnyard-0.2.0/src/input-plugins/dp_stream_stat.c

Once the source code is extracted, we change into the new directory and look for a configure script:

freebsd521$ cd barnyard-0.2.0
freebsd521$ ls
AUTHORS         README          config.guess    docs            src
COPYING         acconfig.h      config.h.in     etc             stamp-h.in
LICENSE.QPL     aclocal.m4      config.sub      install-sh
Makefile.am     autoclean.sh    configure       missing
Makefile.in     autojunk.sh     configure.in    mkinstalldirs

We execute the configure script and pass an optional parameter to enable MySQL output.

freebsd521$ ./configure --enable-mysql
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal-1.4... missing
...edited...
checking for strerror... yes
checking for /mysql.h... no

**********************************************
  ERROR: unable to find mysql headers (mysql.h)
  checked in the following places
        /mysql.h
**********************************************

The configure script abruptly stops because it cannot find mysql.h. This demonstrates the major weakness of installing software from source code. Administrators must be aware of any dependencies required by the application, and address them prior to installing the new software.

Assume we take care of the dependency (using a method to be demonstrated shortly). We re-run the configure script:

freebsd521$ ./configure --enable-mysql
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
...edited...
checking for strerror... yes
checking for /usr/local/include/mysql/mysql.h... yes
checking for mysql_real_connect in -lmysqlclient... no

**********************************************
  ERROR: unable to find mysqlclient library
  checked in the following places
        /usr/local/lib/mysql
**********************************************

Now we see a new error. Although the mysql.h file was found, the configure script is not finding the MySQL client library where it expects to find it. A look in /usr/local/lib/mysql shows the following:

freebsd521$ ls /usr/local/lib/mysql/
libmysqlclient.a        libmysqlclient.so       libmysqlclient.so.10

It appears the files needed are in place. This error demonstrates the second weakness of installing software from source. Sometimes it does not work as expected, and administrators must tweak installation files to accommodate their systems.

The resolution to this problem surfaces by doing a Google search. If we modify the configure script as shown, it fixes the problem:

original configure script:

  LIBS="${LIBS} -lz -lssl -lmysqlclient"

modified configure script:

  LIBS="${LIBS} -lz -lssl -lcrypto -lmysqlclient"

Rerun the configure script:

freebsd521$ ./configure --enable-mysql
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
...edited...
checking for strerror... (cached) yes
checking for /usr/local/include/mysql/mysql.h... yes
checking for mysql_real_connect in -lmysqlclient... yes
...edited...
creating config.h
config.h is unchanged

Because the configure script completed, we can now execute make(1) and begin compiling Barnyard:

freebsd521$ make
make  all-recursive
Making all in src
Making all in output-plugins
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../src  -I/usr/local/include/mysql
 -DENABLE_MYSQL  -g -O2 -Wall -c op_decode.c
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../src  -I/usr/local/include/mysql
 -DENABLE_MYSQL  -g -O2 -Wall -c op_fast.c
...edited...
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I..  -I/usr/local/include/mysql -DENABLE_MYSQL 
 -g -O2 -Wall -c barnyard.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I..  -I/usr/local/include/mysql -DENABLE_MYSQL 
 -g -O2 -Wall -c mstring.c
...edited...
ProgVars.c:672: warning: long unsigned int format, time_t arg (arg 3)
gcc  -g -O2 -Wall -L/usr/local/lib/mysql -o barnyard  barnyard.o mstring.o
 strlcatu.o strlcpyu.o util.o  spool.o sid.o debug.o classification.o
  CommandLineArgs.o ConfigFile.o  ProgVars.o output-plugins/libop.a
   input-plugins/libdp.a -lz -lssl -lcrypto -lmysqlclient

At this point we assume root privileges and execute 'make install' to copy the Barnyard executable to /usr/local/bin:

freebsd521# make install
Making install in src
Making install in output-plugins
Making install in input-plugins
/bin/sh ../mkinstalldirs /usr/local/bin
  /usr/bin/install -c  barnyard /usr/local/bin/barnyard

On FreeBSD systems where the root shell is tcsh or csh, administrators must run rehash(1) to recompute the hash table for the PATH variable. If one does not do this, the system will not find barnyard(1). For example:

freebsd521# barnyard -h
barnyard: Command not found.
freebsd521# ls /usr/local/bin/barnyard 
/usr/local/bin/barnyard
freebsd521# rehash
freebsd521# barnyard -h
Barnyard Version 0.2.0 (Build 32)
Usage: barnyard [OPTIONS]...             (continual mode)
   or: barnyard -o [OPTIONS]... FILES... (batch mode)
...truncated...

Barnyard is now installed.

Installation from source code has four main weaknesses:

• Administrators must resolve dependencies manually.
• Administrators may have to tweak configuration scripts to accommodate their systems.
• Administrators may have to take additional actions to install code without configure scripts or Makefiles.
• Software installed from source can not usually be managed by the native FreeBSD package management tools.

Installation from source code has two main advantages:

• Developers publish their code in source archive form. Therefore, it is typically the freshest version available.
• Administrators have maximum flexibility when working with source code.

My personal preference is to avoid installing source code in this manner if at all possible. I prefer one of the two methods that follow.

Installation Using the FreeBSD Ports Tree

FreeBSD offers an extremely powerful means of installing software. This system is known as the ports tree. Administrators have the option of adding this structure to their system during installation. Alternatively, a recent copy of the source tree archive can be downloaded from www.freebsd.org/ports/ and extracted to the /usr/ports directory.

The FreeBSD ports tree is a system to facilitate the installation of third party applications. The FreeBSD Handbook and other references already comprehensively explain this resource, so I will restrict this text to demonstrating the installation of a tool, FreeBSD Update, using the ports tree. In the previous article we used FreeBSD Update to keep the OS up-to-date. As such it may be considered a "security tool."

A quick look at /usr/ports shows multiple files and directories, corresponding to categories of tools:

freebsd521# cd /usr/ports
freebsd521# ls
.cvsignore      audio           finance         math            shells
INDEX           benchmarks      french          mbone           sysutils
INDEX-5         biology         ftp             misc            textproc
LEGAL           cad             games           multimedia      ukrainian
MOVED           chinese         german          net             vietnamese
Makefile        comms           graphics        news            www
Mk              converters      hebrew          palm            x11
README          databases       hungarian       picobsd         x11-clocks
README.html     deskutils       irc             polish          x11-fm
Templates       devel           japanese        portuguese      x11-fonts
Tools           distfiles       java            print           x11-servers
arabic          dns             korean          russian         x11-toolkits
archivers       editors         lang            science         x11-wm
astro           emulators       mail            security

A quick look inside the security directory shows tools which provide security functions:

freebsd521# ls security | head
ADMsmb
ADMsnmp
IMHear
Makefile
README.html
aafid2
acid
aescrypt
aide
altivore

In fact, we see 'freebsd-update' listed, if we use grep(1) to narrow down the directory listing:

freebsd521# ls security | grep -i update
freebsd-update

If we were not able to guess at the location of our tool of interest, we could turn to other resources. Two Web-based options exist. Search functions at www.freshports.org or www.freebsd.org/ports reveal that the FreeBSD Update program is found in the security/freebsd-update portion of the tree.

The ports tree itself offers two other methods to find tools of interest. From the /usr/ports directory, use make(1) to find ports with the "update" keyword:

freebsd521# make search key=update | more
...edited...
Port:   freebsd-update-1.4
Path:   /usr/ports/security/freebsd-update
Info:   Fetches and installs binary updates to FreeBSD
Maint:  cperciva@daemonology.net
Index:  security
B-deps: 
R-deps: bsdiff-4.1
...truncated...

If we were sure of the tool's name (i.e., "freebsd-update"), we could leverage that knowledge directly to check if the tool is in the ports tree:

freebsd521# make search name=freebsd-update
Port:   freebsd-update-1.4
Path:   /usr/ports/security/freebsd-update
Info:   Fetches and installs binary updates to FreeBSD
Maint:  cperciva@daemonology.net
Index:  security
B-deps: 
R-deps: bsdiff-4.1

At this point we've used several means to locate freebsd-update(1). Now we install it as user root by running make(1) inside the /usr/ports/security/freebsd-update directory. Assume you are taking this action just after FreeBSD 5.2.1 was released, so the freebsd-update(1) version shown (1.4) is the newest available:

freebsd521# cd security/freebsd-update/
freebsd521# make
>> freebsd-update-1.4.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
>> Attempting to fetch from http://www.daemonology.net/freebsd-update/.
Receiving freebsd-update-1.4.tar.gz (29567 bytes): 100%
29567 bytes transferred in 0.1 seconds (236.29 kBps)
===>  Extracting for freebsd-update-1.4
>> Checksum OK for freebsd-update-1.4.tar.gz.
/usr/bin/sed -e "s#PREFIX=/usr/local#PREFIX=/usr/local#g" 
 /usr/ports/security/freebsd-update/work/freebsd-update-1.4/freebsd-update >
 /usr/ports/security/freebsd-update/work/freebsd-update-1.4/freebsd-update.new
 /bin/mv /usr/ports/security/freebsd-update/work/freebsd-update-1.4/freebsd-update.new
 /usr/ports/security/freebsd-update/work/freebsd-update-1.4/freebsd-update
===>  Patching for freebsd-update-1.4
===>  Configuring for freebsd-update-1.4
===>  Building for freebsd-update-1.4
cc -O -pipe -mcpu=pentiumpro -mcpu=pentiumpro -O3 -I lib  -o freebsd-update-verify verify.c
 lib/hashtab.c lib/hash.c lib/fftlut.c lib/fft.c lib/smpa.c lib/numt.c lib/rsa.c

We see the freebsd-update-1.4.tar.gz source code archive is retrieved from www.daemonology.net/freebsd-update. The archive is extracted, patched, configured, and compiled. Next we run 'make install' to install the program:

freebsd521# make install
===>  Installing for freebsd-update-1.4
===>   freebsd-update-1.4 depends on executable: bspatch - not found
===>    Verifying install for bspatch in /usr/ports/misc/bsdiff
>> bsdiff-4.1.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
>> Attempting to fetch from http://www.daemonology.net/bsdiff/.
Receiving bsdiff-4.1.tar.gz (7721 bytes): 100%
7721 bytes transferred in 0.0 seconds (156.32 kBps)
===>  Extracting for bsdiff-4.1
>> Checksum OK for bsdiff-4.1.tar.gz.
===>  Patching for bsdiff-4.1
===>  Configuring for bsdiff-4.1
===>  Building for bsdiff-4.1
cc -O -pipe -mcpu=pentiumpro -mcpu=pentiumpro -O3  bsdiff.c  -o bsdiff
cc -O -pipe -mcpu=pentiumpro -mcpu=pentiumpro -O3  bspatch.c  -o bspatch
===>  Installing for bsdiff-4.1
===>   Generating temporary packing list
===>  Checking if misc/bsdiff already installed
install -c -s -m 555 bsdiff bspatch /usr/local/bin
install -c -m 444 bsdiff.1 bspatch.1 /usr/local/man/man1
===>   Compressing manual pages for bsdiff-4.1
===>   Registering installation for bsdiff-4.1
===>   Returning to build of freebsd-update-1.4
===>   Generating temporary packing list
===>  Checking if security/freebsd-update already installed
install  -s -o root -g wheel -m 555 freebsd-update-verify /usr/local/sbin
install  -o root -g wheel -m 555 freebsd-update /usr/local/sbin
install  -o root -g wheel -m 444 freebsd-update.conf.5 /usr/local/man/man5
install  -o root -g wheel -m 444 freebsd-update.8 /usr/local/man/man8
mkdir /usr/local/freebsd-update
install  -o root -g wheel -m 444 freebsd-update.conf  /usr/local/etc/freebsd-update.conf.sample
mkdir /usr/local/share/doc/freebsd-update
install  -o root -g wheel -m 444 LICENSE README VERSION /usr/local/share/doc/freebsd-update
...edited...
===>   Compressing manual pages for freebsd-update-1.4
===>   Registering installation for freebsd-update-1.4

During this process, something interested happened. The installation process recognized that freebsd-update(1) had an unresolved dependency. Freebsd-update(1) requires the bsdiff(1) program, but bsdiff(1) was not installed. Thanks to the power of the ports tree, the installation process first installed bsdiff(1) and then continued with the installation of freebsd-update(1). If bsdiff(1) had any unresolved dependencies, the installation process would have taken care of those before declaring bsdiff(1) ready. This incredible ports tree feature makes installing software much simpler than compiling source code manually.

When done, the new applications are installed as packages. This is a crucial point to understand. Any application installed through the ports tree, or as a precompiled package (shown next), ends up as a package on the system. For example, the native pkg_info(1) tool reveals the packages installed on our test system:

freebsd521# pkg_info
bash-2.05b.007      The GNU Bourne Again Shell
bsdiff-4.1          Generates and applies patches to binary files
freebsd-update-1.4  Fetches and installs binary updates to FreeBSD
mysql-client-3.23.58 Multithreaded SQL database (client)
perl-5.6.1_15       Practical Extraction and Report Language

Installation using the ports tree has three main weaknesses:

• If a tool you want (like Barnyard) is not in the ports tree, you can't install it using the ports tree.
• The versions of applications in the ports tree may lag their source code counterparts.
• The ports tree must be kept up-to-date in order to install the latest applications. (This process is explained later.)
• Although the ports tree resolves dependencies, the dependencies are specified by the ports maintainer. For example, a port may say it needs Tcl 8.3, but you may want it to use Tcl 8.4. Usually these problems can be resolved manually, but at the cost of "breaking" the tree with your own modifications.

Installation using the ports tree has five main strengths:

• Dependencies are resolved efficiently and with little or no manual intervention.
• Little or no manual tweaking is required, unlike source code installations. The patching process incorporates tweaks done by the port maintainers.
• An application found in the ports tree has some level of guarantee of working on FreeBSD, thanks to the testing and work of the port maintainers.
• Browsing the ports tree is a great way to find tools to accomplish many tasks.
• Applications deployed using the ports tree can be maintained using native package tools or other third-party applications.

When possible, I install applications using the ports tree. I find this aspect of FreeBSD to be one of its most compelling features.

Installation Using Precompiled Packages

While installing Barnyard from source code, we came across a dependency for the MySQL client. This section shows how I quickly resolved this dependency by installing the MySQL client as a precompiled package.

Each FreeBSD release (at least for i386) is shipped with a set of packages. These are found on CD-ROMs shipped by vendors like FreeBSDMall.com or on the FreeBSD FTP mirrors. For example, the following FTP directory on FTP mirror nine contains packages for the i386 platform:

ftp://ftp9.freebsd.org/pub/FreeBSD/ports/i386/packages-5.2.1-release

Within that directory, the 'All' directory shows the actual packages:

ftp> cd All
250 "/pub/FreeBSD/ports/i386/packages-5.2-release/All" is new cwd.
ftp> ls freebsd-update*
227 Entering Passive Mode (128,10,252,13,223,67)
150 Data connection accepted from 69.243.15.208:49163; transfer starting.
-rw-r--r--   1 ftpuser  ftpusers     28927 Dec  9  2003 freebsd-update-1.4.tbz
226 Listing completed.

The 'Latest' directory is a collection of symbolic links using the base name for each package. Here we see that Latest/freebsd-update.tbz is a link to the real package, which bears a version number of 1.4. This is the same version we installed using the ports tree.

ftp> cd ..
250 "/pub/FreeBSD/ports/i386/packages-5.2-release" is new cwd.
ftp> cd Latest
250 "/pub/FreeBSD/ports/i386/packages-5.2-release/Latest" is new cwd.
ftp> ls freebsd-update*
227 Entering Passive Mode (128,10,252,13,223,69)
150 Data connection accepted from 69.243.15.208:49164; transfer starting.
lrwxrwxrwx   1 ftpuser  ftpusers        29 Aug 26 20:58 freebsd-update.tbz -> ../All/freebsd-update-1.4.tbz
226 Listing completed.

Returning to our problem of resolving Barnyard's dependency on the MySQL client, we can install the program using the pkg_add(1) command. The -v switch enables verbose output and the -r switch denotes fetching the package from a remote location. If we had already downloaded the package locally, -r is not needed. I prefer to install all packages using -r, because the installation process will also download any dependencies:

freebsd521# pkg_add -vr mysql-client
looking up ftp.freebsd.org
connecting to ftp.freebsd.org:21
setting passive mode
opening data connection
initiating transfer
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5.2.1-release/Latest/mysql-client.tbz...+CONTENTS
+COMMENT
+DESC
+MTREE_DIRS
man/man1/isamchk.1.gz
man/man1/isamlog.1.gz
man/man1/mysql.1.gz
...edited...
lib/mysql/libmysqlclient.so.10
tar command returns 0 status
 Done.
Package 'mysql-client-3.23.58' depends on 'perl-5.6.1_15' with 'lang/perl5' origin.
 - already installed.
extract: Package name is mysql-client-3.23.58
extract: CWD to /usr/local
extract: /usr/local/man/man1/isamchk.1.gz
extract: /usr/local/man/man1/isamlog.1.gz
...edited...
extract: /usr/local/lib/mysql/libmysqlclient.so.10
extract: execute '/sbin/ldconfig -m /usr/local/lib/mysql'
extract: CWD to .
Running mtree for mysql-client-3.23.58..
mtree -U -f +MTREE_DIRS -d -e -p /usr/local >/dev/null
Attempting to record package into /var/db/pkg/mysql-client-3.23.58..
Trying to record dependency on package 'perl-5.6.1_15' with 'lang/perl5' origin.
Package mysql-client-3.23.58 registered in /var/db/pkg/mysql-client-3.23.58

First the pkg_add(1) process retrieves the mysql-client.tbz package from the "All" directory. This package name is really a symlink to the mysql-client-3.23.58.tbz package.

The package installation process also resolves dependencies automatically. The mysql-client-3.23.58 package depends on perl-5.6.1_15. Since Perl is already installed, the package deployment continues. When done, we have our MySQL client and Barnyard can be installed from source code.

Installation using precompiled packages has five main weaknesses:

• Because the software is precompiled, it uses a "least common denominator" approach. Some customizations used by your system will not be applied to the software installation process.
• Packages tend to lag the ports tree and source code by several weeks.
• Some applications are not available as packages. Programs like OpenOffice.org take such a long time to compile that they put an unwanted strain on the FreeBSD package generation cluster. Others like the Java JDK can not be redistributed in package form. For some architectures, packages may not be available.
• Package dependencies can be more onerous than port dependencies. In other words, packages tend to be stricter about the dependencies they require. While you can tweak the dependencies needed by the ports tree manually, there is no similar capability when using precompiled packages.
• When you install a package, you trust that the package source to not provide trojaned code.

Installation using precompiled packages has four main strengths:

• Package installation is much faster than compiling from source, using normal archives or the ports tree.
• Code than may not compile in the ports tree due to problems with your system or the tree may be available as a package.
• Slow systems that could spend hours or days compiling software can be maintained fairly inexpensively by using precompiled packages.
• Like tools installed with the ports tree, precompiled packages can be administered with native or third-party package management tools.

For initial system setup I tend to install what I need using precompiled packages. Once the system is running, I tend to use the ports tree for most situations.

Updating Applications Installed from Source Code

The most direct way to update an application installed from source code is to uninstall the old version and install the new version. First, execute 'make uninstall' in the directory from which you executed 'make install'. For example:

freebsd521# cd /usr/local/src/barnyard-0.2.0
freebsd521# make uninstall
Making uninstall in src
Making uninstall in output-plugins
Making uninstall in input-plugins
list='barnyard'; for p in $list; do  rm -f /usr/local/bin/`echo $p|sed 's/$//'|sed 's,x,x,'|sed 's/$//'`;  done
freebsd521# ls /usr/local/bin/barnyard
ls: /usr/local/bin/barnyard: No such file or directory

Now, download the new version of Barnyard, extract it, and follow the installation instructions already posted.

Updating Packages by Deletion and Addition

Now we turn to keeping packages up-to-date. There is no section on keeping "ports" up-to-date or "packages" up-to-date. To reiterate, applications installed using the ports tree or precompiled packages all end up as packages on the system. While we will see tools with "port" or "pkg" in their names, all tend to act on packages installed on FreeBSD.

The most direct way to "update" a package is to remove it and install a new version. Earlier we used pkg_info to show installed packages. A check in /var/db/pkg also shows the packages installed.

freebsd521# cd /var/db/pkg
freebsd521# ls
bash-2.05b.007          freebsd-update-1.4      perl-5.6.1_15
bsdiff-4.1              mysql-client-3.23.58

I prefer to use pkg_delete(1) from this directory, because I can use tab-completion to specify the entire package name:

freebsd521# pkg_delete -v mysql-client-3.23.58
Change working directory to /usr/local
Delete file /usr/local/man/man1/isamchk.1.gz
Delete file /usr/local/man/man1/isamlog.1.gz
...edited...
Delete file /usr/local/man/man1/safe_mysqld.1.gz
Execute 'rm -f /usr/local/man/cat1/isamchk.1 /usr/local/man/cat1/isamchk.1.gz'
Execute 'rm -f /usr/local/man/cat1/isamlog.1 /usr/local/man/cat1/isamlog.1.gz'
...edited...
Execute 'rm -f /usr/local/man/cat1/safe_mysqld.1 /usr/local/man/cat1/safe_mysqld.1.gz'
Delete file /usr/local/bin/mysql
Delete file /usr/local/bin/mysqladmin
...edited...
Delete file /usr/local/lib/mysql/libmysqlclient.so.10
Delete directory /usr/local/include/mysql
Delete directory /usr/local/lib/mysql
Execute 'if [ -f /usr/local/info/dir ]; then if sed -e '1,/Menu:/d'
 /usr/local/info/dir | grep -q '^[*] '; then true; else rm /usr/local/info/dir; fi; fi'
Execute '/sbin/ldconfig -R'
Change working directory to .
Trying to remove dependency on package 'perl-5.6.1_15' with 'lang/perl5' origin.

The package is gone, according to pkg_info(1) and a listing of /var/db/pkg:

freebsd521# pkg_info 
bash-2.05b.007      The GNU Bourne Again Shell
bsdiff-4.1          Generates and applies patches to binary files
freebsd-update-1.4  Fetches and installs binary updates to FreeBSD
perl-5.6.1_15       Practical Extraction and Report Language
freebsd521# ls
bash-2.05b.007          freebsd-update-1.4
bsdiff-4.1              perl-5.6.1_15

Now that the package is gone, we must look for a newer version. The package we deleted, mysql-client-3.23.58, was the version shipped with FreeBSD 5.2.1 RELEASE. It was found in the following FTP directory. We show the contents of FTP mirror 9, but you are free to use whatever mirror you like;

ftp://ftp9.freebsd.org/pub/FreeBSD/ports/i386/packages-5.2.1-release/All

Packages compiled from the latest source code on the most recent version of FreeBSD, 5-STABLE, are found here:

ftp://ftp9.freebsd.org/pub/FreeBSD/ports/i386/packages-5-stable/Latest

In this directory we find a new version of the MySQL client, namely mysql-client-3.23.58_3.tbz. We can install this version using pkg_add(1) if we change our PACKAGESITE environment variable:

freebsd521# setenv PACKAGESITE ftp://ftp9.freebsd.org/pub/FreeBSD/ports/i386/packages-5-stable/Latest/

We check to see what package are available there:

ftp> pwd
257 "/pub/FreeBSD/ports/i386/packages-5-stable/Latest" is cwd.
ftp> ls mysql*client*
227 Entering Passive Mode (128,10,252,13,224,196)
150 Data connection accepted from 69.243.15.208:49184; transfer starting.
lrwxrwxrwx   1 ftpuser  ftpusers        33 Nov 17 21:01 mysql323-client.tbz -> ../All/mysql-client-3.23.58_3.tbz
lrwxrwxrwx   1 ftpuser  ftpusers        30 Nov 17 21:01 mysql40-client.tbz -> ../All/mysql-client-4.0.22.tbz
lrwxrwxrwx   1 ftpuser  ftpusers        29 Nov 17 21:01 mysql41-client.tbz -> ../All/mysql-client-4.1.7.tbz
lrwxrwxrwx   1 ftpuser  ftpusers        29 Nov 17 21:01 mysql50-client.tbz -> ../All/mysql-client-5.0.1.tbz
226 Listing completed.

Notice that the various MySQL clients now all have version numbers. We are interested in using mysql323-client.tbz with Barnyard.

Now we use pkg_add(1) to install the newest MySQL 3.x client listed in the STABLE package directory:

freebsd521# pkg_add -vr mysql323-client
looking up ftp9.freebsd.org
connecting to ftp9.freebsd.org:21
setting passive mode
opening data connection
initiating transfer
Fetching ftp://ftp9.freebsd.org/pub/FreeBSD/ports/i386/packages-5-stable/Latest/mysql323-client.tbz...
...edited...
extract: /usr/local/lib/mysql/libmysqlclient_r.so.10
extract: execute '/sbin/ldconfig -m /usr/local/lib/mysql'
extract: CWD to .
Running mtree for mysql-client-3.23.58_3..
mtree -U -f +MTREE_DIRS -d -e -p /usr/local >/dev/null
Attempting to record package into /var/db/pkg/mysql-client-3.23.58_3..
Package mysql-client-3.23.58_3 registered in /var/db/pkg/mysql-client-3.23.58_3

When pkg_add is done, the new version is installed:

freebsd521# pkg_info | grep mysql
mysql-client-3.23.58_3 Multithreaded SQL database (client)

This process seems fairly simple, but there are problems. First, we had to manually verify that a new version of the MySQL client was available. Then we deleted it and reinstalled it. If any other packages (not source code like Barnyard) required mysql-client as a dependency, pkg_delete(1) would have complained and not let us delete mysql-client. We could have forced deinstallation, but that's a sloppy system administration practice.

Should other applications have required the MySQL client, we could have deleted them, then deleted mysql-client, and reinstalled everything. Again, that is a lot of work. Fortunately, alternatives (described next) exist.

Incidentally, you can use sysutils/pkg_tree to see package dependencies. Here we see what dependencies freebsd-update has:

freebsd521# pkg_tree freebsd-update
freebsd-update-1.4
 \__ bsdiff-4.1

We now know that if we tried to pkg_delete(1) the bsdiff package, the system would complain because freebsd-update(1) depends on bsdiff(1):

freebsd521# cd /var/db/pkg
freebsd521# pkg_delete bsdiff-4.1/
pkg_delete: package 'bsdiff-4.1' is required by these other packages
and may not be deinstalled:
freebsd-update-1.4

A tool one can use to trim installed packages is sysutils/pkg_cutleaves. This tool begins with "leaf" packages, asking if you want to remove them, followed by the packages upon which they depend. In the following example, we hit [return] whenever we see a package we want to keep. When we come to nmap(1), we decide to remove it with 'd':

drury:/root# pkg_cutleaves
Package 1 of 42:
XFree86-4.3.0,1 - X11/XFree86 core distribution (complete, using mini/meta-ports)
XFree86-4.3.0,1 - [keep]/(d)elete/(f)lush marked pkgs/(a)bort? 
** Keeping XFree86-4.3.0,1.
...edited...
Package 21 of 42:
nmap-3.77 - Port scanning utility for large networks
nmap-3.77 - [keep]/(d)elete/(f)lush marked pkgs/(a)bort? d
** Marking nmap-3.77 for removal.
...edited...
Deleting nmap-3.77 (package 1 of 1).
--->  Deinstalling 'nmap-3.77'
[Updating the pkgdb <format:bdb1_btree> in /var/db/pkg ... - 104 packages found (-1 +0) (...) done]

At this point, pkg_cutleaves(1) asks if we want to continue. If we do, we have the option of deleting a nmap(1) dependency, pcre:

Go on with new leaf packages ((y)es/[no])? y

Package 1 of 1:
pcre-5.0 - Perl Compatible Regular Expressions library
pcre-5.0 - [keep]/(d)elete/(f)lush marked pkgs/(a)bort? d
** Marking pcre-5.0 for removal.

Deleting pcre-5.0 (package 1 of 1).
--->  Deinstalling 'pcre-5.0'
[Updating the pkgdb <format:bdb1_btree> in /var/db/pkg ... - 103 packages found (-1 +0) (...) done]
** Didn't find any new leaves to work with, exiting.
** Deinstalled packages:
nmap-3.77
pcre-5.0
** Number of deinstalled packages: 2

Since there are no longer any dependencies for nmap(1), the process ends. Using a tool like pkg_cutleaves(1) allows us to trim down unnecessary packages very easily.

We will continue the package upgrading in part 2 of this article.