Библиотека сайта rus-linux.net
|Maximum RPM: Taking the Red Hat Package Manager to the Limit|
|Prev||Chapter 20. Real-World Package Building||Next|
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.
As we mentioned above, the home FTP site for amanda is
ftp.cs.umd.edu. The sources are in
SOURCESdirectory, 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
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.
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:
/libon Red Hat Linux, we need to change this part of
Next, we need to take a look in
create two files:
config.h— contains platform-specific configuration information
options.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
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
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.
options.hfiles 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
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.
/etc/dumpdatesreadable and writeable by the client.
Put an amanda entry in
Put an amanda entry in
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
Once everything is ready, we run a few tests. Everything performs flawlessly.  Looks like we've got a good build. Let's start getting RPM involved.
Well, eventually it did!