Библиотека сайта rus-linux.net
| Maximum RPM: Taking the Red Hat Package Manager to the Limit | ||
|---|---|---|
| Prev | Chapter 20. Real-World Package Building | Next |
Initial Building Without RPM
Since amanda can be built on numerous platforms, there needs to be some initial customization when first building the software. Since customization implies that mistakes will be made, we'll start off by building amanda without any involvement on the part of RPM.
But before we can build amanda, we have to get it and unpack it, first.
Setting Up A Test Build Area
As we mentioned above, the home FTP site for amanda is
ftp.cs.umd.edu. The sources are in
/pub/amanda.
SOURCES directory, so that
we can keep all our work in one place:
|
amanda-2.3.0. Let's rename that directory to
amanda-2.3.0-orig, and unpack the sources again:
|
Now why did we do that? The reason lies in the fact that we will
undoubtedly need to make changes to the original sources in order to
get amanda to build on Linux. We'll do all our hacking in the
amanda-2.3.0 directory, and leave the
amanda-2.3.0-orig untouched.
Since one of RPM's design features is to build packages from the
original, unmodified sources, that means the changes we'll make will
need to be kept as a set of patches. The
amanda-2.3.0-orig directory will let us issue a
simple recursive diff command to create our patches
when the time comes.
Now that our sources are unpacked, it's time to work on building the software.
Getting Software to build
Looking at the docs/INSTALL file, we find that
the steps required to get amanda configured and ready to build are
actually fairly simple. The first step is to modify
tools/munge to point to cpp,
the C preprocessor.
munge, we find the following
section:
|
/lib on
Red Hat Linux, we need to change this part of munge to:
|
Next, we need to take a look in config/ and
create two files:
config.h— contains platform-specific configuration informationoptions.h— contains site-specific configuration information
There are a number of example config.h files for
a number of different platforms. There is a Linux-specific version,
so we copy that file to config.h and review it.
After a few changes to reflect our Red Hat Linux Linux environment, it's
ready. Now let's turn our attention to
options.h.
In the case of options.h, there's only one
example file called options.h-vanilla. As the
name implies, this is a basic file that contains a series of
#defines that configure amanda for a typical
environment. We'll need to make a few changes:
Define the paths to common utility programs.
Keep the programs from being named with the suffix
-2.3.0.Define the directories where the programs should be installed.
While the first change is pretty much standard fare for anyone used to building software, the last two changes are really due to RPM. With RPM, there's no need to name the programs with a version-specific name, as RPM can easily upgrade to a new version and even downgrade back, if the new version doesn't work as well. The default paths amanda uses segregate the files so that they can be easily maintained. With RPM, there's no need to do this, since every file installed by RPM gets written into the database. In addition, Red Hat Linux systems adhere to the File System Standard, so any package destined for Red Hat systems should really be FSSTND-compliant, too. Fortunately for us, amanda was written to make these types of changes easy. But even if we had to hack an installation script, RPM would pick up the changes as part of its patch handling.
config.h and options.h
files are perfect. Amanda builds:
|
As we noted, amanda is constructed so that most of the time changes
will only be necessary in tools/munge, and the
two files in config. Our situation was no
different — after all was said and done, that was all we needed
to hack.
Installing and testing
|
OK, no major problems there. Amanda does require a bit of additional
effort to get everything running, though. Looking at
docs/INSTALL, we follow the steps to get amanda
running on our test system, as both a client and a server. As we
perform each step, we note it for future reference:
For the client:
Set up a
~/.rhostsfile allowing the server to connect.Make the disk device files readable by the client.
Make
/etc/dumpdatesreadable and writeable by the client.Put an amanda entry in
/etc/services.Put an amanda entry in
/etc/inetd.conf.Issue a kill -HUP on inetd.
For the server:
Create a directory to hold the server configuration files.
Modify the provided example configuration files to suit our site.
Add crontab entries to run amanda nightly.
Put an amanda entry in
/etc/services.
Once everything is ready, we run a few tests. Everything performs flawlessly. [1] Looks like we've got a good build. Let's start getting RPM involved.
Notes
| [1] | Well, eventually it did! |