Owl is a small security-enhanced server platform, and as such it contains little more than a bare minimum set of packages typically required on Internet servers. Owl 2.0 contains a total of 135 “source” packages (that exist as subdirectories in the source trees), which produce around 200 "binary" packages (RPMs). 1) As of this writing, Owl-current adds a couple of packages on top of that - here are the full package lists for i686 and x86_64. Please note that when you install Owl, all of the Owl packages are installed right away (except for backwards-compatibility packages, if any). Owl is small enough for this (a full install occupies around 400 MB of disk space).
Additional software may be built on Owl (since the system includes C and C++ compilers, as well as other essential “development” tools) and installed under
/opt, or with custom-created or rebuilt RPM packages - or it may be installed using pre-built RPM packages. This wiki page is primarily about the latter, although it is debatable whether use of pre-existing packages contributed by Owl users or taken from or intended for another distribution is actually a “better” thing to do (“more correct”, easier, quicker - with all of these being questionable) than doing your own builds or not. Please use your own judgment on a case-by-case basis.
Please note that there's added security risk from using unofficial and/or currently not maintained packages, such as many packages referenced below (NetBSD and RHEL/CentOS 4 packages are the major exception - they're not official for us, but they're maintained by NetBSD contributors, Red Hat and the CentOS community, respectively). Your possible use of them is at your own risk.
There are user-contributed RPM packages for Owl 2.0 and 2.0-stable. These may be found under
/pub/Owl/contrib/2.0 on the FTP mirrors. As of this writing, there are 60 source (.src.rpm) and the corresponding 116 binary packages for x86 (.i386.rpm), which have been contributed by op5 AB.
In almost all cases, it is possible to install packages from (or intended for) RHEL4, CentOS 4, FC3 (and usually also FC4) on Owl 2.0 and 2.0-stable (and usually also on Owl-current). The few known issues with using these packages on Owl are documented in Owl/doc/REDHAT.
CentOS 4 packages (both source and binary) may be found here:
For example, CentOS 4 packages pre-built for i386 are here:
The end-of-life (upstream maintenance) for CentOS 4 is Feb 29, 2012. This means that until that date updates for CentOS 4 packages were being released, such as fixing any important security vulnerabilities that were being discovered, but no further security updates will be made. Before you install a CentOS 4 package, it is a good idea to check the updates directory for a possible newer revision of the package.
Red Hat's packages, including those available via CentOS, sometimes have non-obvious knotty dependencies. However, there's the
rpmdb-CentOS package (and similar
rpmdb packages in Red Hat's own/other distributions), which helps to solve the puzzle; install it (something like
rpmdb-CentOS-4.8-0.20090804.i386.rpm), and then you'll be able to query the database for “metadata” (dependencies, files, etc.) of other (not yet installed) CentOS packages.
For example, to show all the files and packages on which a given package depends, you can use something like:
rpm --dbpath /usr/lib/rpmdb/i386-redhat-linux/CentOS -qR httpd
httpd is the name of the not yet installed CentOS package, which you might not even have downloaded yet, or if you already have the
.rpm file you can simply do:
rpm -qRp httpd-2.0.52-41.ent.4.centos4.i386.rpm
The latter command does not require nor make use of the
rpmdb-CentOS package, reading the “metadata” directly from the package file.
If you don't know which package to download and install to get the file
/etc/mime.types (needed by some other packages), simply issue the command:
rpm --dbpath /usr/lib/rpmdb/i386-redhat-linux/CentOS -qf /etc/mime.types
Fedora packages (both source and binary) may be found here:
For example, FC4 core packages pre-built for i386 are here:
and the extras are here:
FC3 and FC4 are no longer maintained, which means that there will be no further official security updates, and there haven't been any for quite some time already.
Dag Wieërs maintains (although probably not in the sense of being responsible to issue security updates) a large repository of add-on RPM packages for Red Hat/Fedora. As of this writing, the repository contains over 95,000 different builds of over 4,000 different pieces of software. The builds are for different versions of RHEL, Fedora, and even the legacy Red Hat Linux. As indicated above, the builds for RHEL4 and FC3 are generally usable on Owl 2.0.
Remi maintains repositories with additional/newer packages for Red Hat'ish distributions, including for RHEL4 (and thus likely usable on Owl). For example, as of this writing (August 23, 2011), the repository for RHEL4 contains the latest PHP 5.3.7 (released just a few days ago), and moreover with an additional post-5.3.7 security fix.
It is possible to rebuild and use source packages from up to Fedora 10 on Owl 2.0. (Unfortunately, Fedora 11+ changed/broke the RPM package format, and Owl does not yet support the newer format.) To do this, under a non-root account issue commands like:
rpminit # needed the first time per account only MAKEFLAGS=-j2 nice -n 19 rpmbuild --rebuild alsa-lib-1.0.18-6.rc3.fc10.src.rpm
MAKEFLAGS=-j2 nice -n 19 part is optional and may be adjusted to fit your needs.)
For many packages you will need to satisfy their build-time dependencies first. For example, the
alsa-lib rebuild shown above will require that you install the
doxygen package first (also rebuilt from Fedora 10, pre-built from FC4, or otherwise). Of course, all of this is a bit dirty, and you're unlikely to be able to maintain a system with up-to-date packages in this way (such as because of not being able to go beyond Fedora 10 yet). However, in some cases this approach may be useful, such as when you merely need to test-install something “big” on Owl and you need to satisfy the dependencies in a quick-n-dirty way first (so you install the prerequisite libraries, etc., in this way), or if you “know what you are doing” by using a slightly outdated version of some package.