not logged in | [Login]

Table of Contents

Introduction

There are several "Red Hat" distributions which address different goals and as a consequence have different philosophies driven by different constraints.

Fedora

Fedora is not a Red Hat product, rather it is a community based project which receives support from Red Hat. The goal of Fedora is to be as current with new technology and software releases as is possible. Sometimes Fedora is referred to as a "bleeding edge" distribution because of it's focus on incorporating new software. Fedora operates on an aggressive 6 month time based release cycle. Thus every 6 months there is a new major release of Fedora. In the interval between major releases it is common for packages to be updated to new versions via automated network based updates keeping a Fedora system very current. Fedora's time based release schedule is in contrast to the more traditional feature based release schedule which determines the release dates based solely on the completion of features.

RHEL (Red Hat Enterprise Linux)

RHEL (Red Hat Enterprise Linux) is a Red Hat product which is specifically targeted for enterprise installations. Enterprises require stability, robustness, and long duration support (7 years in many instances). This makes an enterprise distribution very conservative. The typical release cycle for major RHEL versions is 2 years. The basic approach is to take a snapshot of a current Linux distribution (Fedora in this instance) and freeze it so for the duration of the distribution very little changes. This is critical for enterprises which must deploy software solutions which cannot tolerate the disruptions introduced by new software, they need to know if it's working today it's going to be working exactly the same way tomorrow, often on hundreds of different nodes. Updates are low volume and are meant to address bugs and security vulnerabilities. Updates are seldom released to introduce new features, although this will occasionally happen on a case by case basis after careful deliberation considers the potential impact and rewards.

In practice the philosophical guidelines of an enterprise distribution mean the base version of any given software package remains constant for the multi-year life of the distribution. When problems with a software package (bugs or security vulnerabilities) have been identified, the normal course of action is to "back port" the fix into the version of the package the enterprise distribution originally contained. This is how the goal of version stability is achieved and is in direct contrast to the more typical approach of releasing a newer version of the package which already has the fixes. Of course not every fix can be back ported nor is it always appropriate which means there will be isolated exceptions to the rule of never updating a package version, but you should understand there is an extremely strong bias against updating package versions in RHEL.

CentOS

Essentially CentOS is a free community version of RHEL. Red Hat is very committed to the philosophy of open source and as a consequence the source code for every component in RHEL and every patch Red Hat has provided is available to anyone. The CentOS project takes the RHEL sources provided by Red Hat, rebuilds them after stripping out the Red Hat branding and makes them available for downloading. The downside of this is that you lose support from Red Hat which is often regarded as world class and an excellent value for enterprise customers.

Picking a distribution based on it's philosophy and your needs

From the above it should be obvious the different distributions take different approaches to address different needs. If you do not take these differences into account you may be frustrated. Pick Fedora if you need the latest and greatest. Pick RHEL if stability, robustness, and support are critical to long term functioning of your enterprise's IT infrastructure.

One consequence of picking an enterprise distribution is you should not expect to find new versions of any package (FreeRADIUS is just one example) in RHEL. If it's critical you run your enterprise with a new version of a package then it will be incumbent upon you to build and install the new version yourself and accept the fact that version of the package will be unsupported. It is also incumbent upon you to correctly build and install the new package such that it meets all of the packaging and installation requirements of RHEL otherwise you stand a good chance of perturbing the system in a bad way. Because Fedora is current and RHEL is a derivative of Fedora the most expedient way to meet these requirements is to obtain the source package of FreeRADIUS on Fedora and then use approved rpm utilities to perform a local build on your RHEL system from the Fedora SRPM. This will produce a collection of FreeRADIUS RPM's and should guarantee the resulting packages conform to the requirements of Red Hat based distributions. Instructions on how to do this and the reasons why can be found later in this FAQ, please see How to build an SRPM.

FreeRADIUS Red Hat FAQ

How is FreeRADIUS distributed on Fedora/RHEL/CentOS systems?

FreeRADIUS is distributed on Fedora/RHEL/CentOS systems as a set of RPM packages. There is a main package called "freeradius" and several subpackages whose name is "freeradius-XXX" where XXX is optional functionality. For example the support needed for MySQL database backend will be found in the package "freeradius-mysql".

Why are there optional subpackages instead of just one package?

The rpm package management tool will not permit installing a package unless all of it's dependencies are met on the target system, otherwise the package would fail to run correctly. FreeRADIUS can be built with many optional components, for example support for a variety of databases. Each optional component has it's own set of dependencies, for example if FreeRADIUS is built to support the MySQL database then there is a dependency on the MySQL client libraries. If rpm is asked to install a FreeRADIUS RPM which was built with MySQL then rpm will insist the MySQL support is installed as well. This type of dependency requirement extends to all optional FreeRADIUS components. If the FreeRADIUS RPM package was distributed as a monolithic package with all optional components this would force a person installing FreeRADIUS to install a lot of dependencies they are likely to never use. This can produce significant bloat on the target system. If a user never expects to run FreeRADIUS with the PostgreSQL database then why should they be forced to install PostgreSQL? The same question applies to each of the optional components.

In order to reduce the set of dependencies which need to be resolved during installation FreeRADIUS is partitioned into a number of subpackages. When you install the base freeradius rpm you won't automatically get any database support. Instead you'll need to identify which database backend you want to utilize and then install the freeradius subpackage which corresponds to it. In this way you'll only be required to install the dependencies for features you'll actually be using instead of every possible feature. Note, we've used database backends in our example because this is a common case, but the subpackages comprise other features as well, e.g. ldap, kerberos, python, perl, etc.

How can I install a new version of FreeRADIUS on a Fedora/RHEL/CentOS system?

Your best bet and easiest solution is to install a prebuilt RPM package if it's available. This relieves you of having to build the package and properly configure its installation. Plus it has the advantage of having been built in very controlled build environments.

Use the yum rpm package manager to install or upgrade FreeRADIUS. If the RPM is already installed use the upgrade command otherwise use the install command, e.g. to install FreeRADIUS

 % sudo yum install freeradius

to upgrade FreeRADIUS:

 % sudo yum upgrade freeradius

to install an optional subpackage, for example MySQL support:

 % sudo yum install freeradius-mysql

How do I update my version of FreeRADIUS to a pre-release testing version for my distribution?

Software updates appear in repositories ("repos") for specific distributions. Each distribution contains two channels, testing and stable. Normally new package versions are placed in the testing channel for a period of time before being moved to stable. By default the yum configuration only enables the stable channel. If you want a package from the testing channel you have to tell yum to enable the testing channel when you run it. So you would use the yum package updating tool but override it's repository selection.

 % sudo yum --enablerepo=updates-testing update freeradius

If you install a package, especially one from testing, then please take the time to report whether you had success with the new package or not, this helps the maintainer to know if a package is ready to be promoted from testing to stable.

How do I report success/failure for a package uprade in Fedora?

Use Bodhi, the Fedora Update System (https://admin.fedoraproject.org/updates). Locate the package via the search box, click on the link which has the exact same version identifier you installed. Toward the bottom you will see an area for comments. Bodhi also lets you see other peoples experiences with the package in question.

How do I report a bug against the Red Hat packaging of FreeRADIUS?

First, please note Red Hat repackages FreeRADIUS from the upstream FreeRADIUS project. If you believe the problem you are seeing is not specific to Red Hat but rather is an issue with FreeRADIUS in general then the issue should be raised on the FreeRADIUS user's mailing list or reported on the FreeRADIUS bug tracker. Bug reports of this nature should not be filed directly on the Red Hat Bugzilla. However, if you believe the problem you are seeing is specific to Red Hat systems only then please report the problem on the Red Hat Bugzilla.

How are configuration files handled during an RPM upgrade?

FreeRADIUS contains many configuration files under the FreeRADIUS configuration directory /etc/raddb. RPM has special support for configuration files because configuration files are designed to be modified after installation. During an RPM update all the files in the new package are copied into their destination directories. If RPM was ignorant about configuration files it would overwrite the configuration files which might have been carefully tailored to the installation. If that were the case then upgrading to a new package version would erase the careful customizations implemented by the system administrator. Clearly this is not desired behavior. To overcome this problem the author of the rpm spec file can mark files as being a configuration file. This is done with the %config tag in the spec file and causes RPM to process the file specially during an upgrade.

If the configuration file has not been modified prior to the upgrade then RPM simply overwrites the on-disk copy of the file with the new version of the file from the upgrade.

However if the configuration file had been locally modified then the best thing RPM can do is leave a copy of both the modified file and the new version of the file from the upgrade thus allowing the system administrator the option of comparing the two files so he can resolve the differences. Since there will be two copies of the configuration file left on disk after the upgrade the question arises as to which one "wins" and will be stored in the actual file name and which one gets renamed, the new update version or the old modified version? This decision is controlled by the %config tag in the spec file and the results are illustrated in the following table:

Congfiguration File Behavior During RPM Upgrade
Spec File Tag Did File Change
in RPM update?
If on-disk file is unmodified
then result is
If on-disk file is modified
then result is
%config(noreplace) No File from update Modified file
Yes File from update Modified file,
File from update saved in .rpmnew
%config No File from update Modified file
Yes File from update File from update,
Modified file saved in .rpmsave

For example if you had edited /etc/raddb/foo.cfg and that file was marked as %config then after the upgrade /etc/raddb/foo.cfg would be the version from the new upgrade and /etc/raddb/foo.cfg.rpmsave would be your old modified version. However, that file was marked as %config(noreplace) then after the upgrade /etc/raddb/foo.cfg would be your old modified version and the new version from the upgrade would be /etc/raddb/foo.cfg.rpmnew.

It can be hard to know a priori the optimal behavior, it depends on a variety of factors the package maintainer may not be privy to such as how different the new update is from the existing version, etc. The practical solution adopted in most cases is to mark all config files as noreplace, meaning locally modified configuration files always win. However, this has important ramifications after an upgrade if the old version of the modified configuration file is not compatible with the new version of the package, in this instance the program may fail to operate as expected. It is always the responsibility of the system administrator after an upgrade to verify the state of the configuration files by looking for .rpmnew or .rpmsave files and properly resolving the discrepancies. As an aid in this task RPM will always emit warnings any time it creates .rpmnew or .rpmsave files. The system administrator should carefully watch for these warnings during a package upgrade. Alternatively you can go back later and search the /etc/raddb tree for the presence of .rpmnew and .rpmsave files.

How do I determine what prebuilt FreeRADIUS RPM are available for installation?

Use the yum package installer to perform a query.

 % yum info freeradius\*

How does RPM version naming work? How do I look at an RPM name and understand what FreeRADIUS version it represents?

RPM names are always of the form Name-Version-Release, this is often abbreviated NVR. For Fedora/RHEL/CentOS systems the RPM name will always be suffixed with the "distribution tag" or disttag for short, this yields Name-Version-Release.disttag.

Let's look at an example: freeradius-2.1.1-7.fc10

The Name of this RPM is "freeradius".

The Version of this RPM is "2.1.1". The Version always matches the upstream FreeRADIUS project version. In this example it means the RPM is based on the 2.1.1 version from the FreeRADIUS project.

The Release of this RPM is "7". This means the base version (e.g. 2.1.1) has been built 7 times each with something uniquely new to the base version. Sometimes this means a patch has been added to fix a bug, or it might mean a build option in the spec file changed, or the package was rebuilt with a new compiler. The reasons why the package was rebuilt with a new release number will be captured in the RPM changelog.

The distribution or disttag of this RPM is "fc10". In this example it means the RPM was built for version 10 of Fedora. The RHEL disttag is usually "el" with a version number appended to it. The "el" stands for Enterprise Linux. For example a disttag of "el5" means RHEL 5.

How do I determine what version of the FreeRADIUS package(s) I have installed?

Use the rpm query command, this will list every installed RPM package and it's version which begins with "freeradius"

 % rpm -qa freeradius\*

How do I determine which package owns a (missing) file?

Both rpm and yum are capable of mapping a file path to the RPM package which owns it. However rpm needs to have the package installed to perform the query otherwise it won't be known to the local rpm database.

To perform an rpm query on the local rpm database use the 'f' query option. For example:

 %rpm -qf /usr/lib/freeradius/rlm_sql_mysql.so
 freeradius-mysql-2.1.1-7.fc11.i686

However if you're trying to determine which package to install because you've got a missing file then you'll have to ask the yum package manager which has knowledge about all possible packages. Note that yum accepts wildcard globbing. So let's say you got a run time error claiming FreeRADIUS could not load /usr/lib/freeradius/rlm_sql_mysql-2.1.1.so then you could ask yum to tell you every package which has a path name like that using the "whatprovides" query, for example:

 % yum whatprovides /usr/lib/freeradius/rlm_sql_mysql\*.so  
 Loaded plugins: refresh-packagekit
 freeradius-mysql-2.1.1-2.fc10.i386 : MySQL support for freeradius
 Matched from:
 Filename    : /usr/lib/freeradius/rlm_sql_mysql.so
 Filename    : /usr/lib/freeradius/rlm_sql_mysql-2.1.1.so
 freeradius-mysql-2.1.1-7.fc10.i386 : MySQL support for freeradius
 Matched from:
 Filename    : /usr/lib/freeradius/rlm_sql_mysql.so
 Filename    : /usr/lib/freeradius/rlm_sql_mysql-2.1.1.so
 freeradius-mysql-2.1.1-7.fc11.i686 : MySQL support for freeradius
 Matched from:
 Filename    : /usr/lib/freeradius/rlm_sql_mysql.so
 Filename    : /usr/lib/freeradius/rlm_sql_mysql-2.1.1.so

From above you'll see that yum has told you there are 3 different packages which contain the file. The important thing to note is the package name is identical in all cases, freeradius-mysql, they differ only by their version. What this tells you is you need to install the freeradius-mysql package. Don't worry about the version, yum will pick the correct version when you ask it to install the package, which would be done like this:

 % sudo yum install freeradius-mysql

Why should I use Red Hat RPM's instead of the raw FreeRADIUS source?

Note, you may want to refer to the FAQ entry What is the difference between building from source and building from an SRPM?

When you build from the raw source code you will have many decisions to make such as what to build, setting up the pre-requisites for building, and deciding on where things should be installed. Because Red Hat systems have established conventions should you fail to make informed decisions on any aspect of building and installing you may create needless problems which have already been addressed in the Red Hat specific versions of FreeRADIUS. You may end up confusing the Red Hat Package Manager (rpm) by overwriting files it thinks it owns. You might install files into locations which will then run afoul of the security configuration of the machine (SELinux file labeling). You might fail to recognize customizations which have been applied to the FreeRADIUS configuration files which tailor it to Red Hat systems. Or you might needlessly duplicate facilities that have already been provided for you in the Red Hat specific RPM's such as scripts to control the service, perform log rotations, etc. Also, the rpm spec files on Red Hat systems are peer reviewed and must conform to a wide range of "good practice" policies.

Simply put, it's much more efficient if you don't have to learn all the lessons and recreate the results if you just leverage what has already been provided for you. You're much better off installing prebuilt RPM's rather than trying to do a build yourself. If you do discover you must do a build yourself you're much better off using the SRPM as the source and performing an rpmbuild operation to produce the necessary RPM's. In all cases you should be using the RPM package installer to install either pre-built RPM's or any RPM you built locally.

You should never run "make install" directly. Why? Because the rpm command enforces a wide range of constraints which, if you want an easy to manage functioning system, you'll need to observe. Paramount amongst the reasons is rpm's ability to track the installed versions of every library your software has linked against. rpm will assure libraries will not be installed on your system or removed from your system if that would conflict with your software. This is a primary reason why there is no "DLL Hell" on Linux. rpm also manages configuration files preventing you from overwriting customized configuration files during installation. rpm assures files are installed with the correct SELinux security labeling. Because rpm knows the complete file manifest of a piece of software, upgrades and downgrades can be performed without leaving orphaned files behind. rpm can be aware of special installation requirements such as starting and stopping services, emitting messages to concerned parties, etc. Let rpm do its job by not side stepping its critical functionality by performing installs behind its back with a "make install".

How do I start and stop the FreeRADIUS service?

Nowadays Fedora uses systemd units and older releases of RHEL and CentOS still use System V init-scripts to control services. However, on all of them the FreeRADIUS service is called "radiusd" and the "service" command can be equally used to manage it.

To start the radiusd service:

 % sudo service radiusd start

To stop the radiusd service:

 % sudo service radiusd stop

To query the radiusd service status:

 % service radiusd status

If you want the radiusd service to be automatically started every time the system boots then you will need to use chkconfig to turn it on. chkconfig works by specifying what should happen at different run levels.

To see if radiusd is configured for automatic starting:

 % chkconfig --list radiusd
 radiusd        	0:off	1:off	2:off	3:off	4:off	5:off	6:off

The numbers listed are the individual run levels. In this example radiusd is "off" for each run level, this means it will never be automatically started.

To turn on automatic starting do this:

 % sudo chkconfig radiusd on

Now, verify which run levels it will automatically be started.

 % chkconfig --list radiusd
 radiusd        	0:off	1:off	2:on	3:on	4:on	5:on	6:off

This shows that the FreeRadius service will be automatically started whenever the system enters run levels 3,4,5 which are the defaults.

If you want to turn off automatic starting.

 % sudo chkconfig radiusd off

How do I determine what files are contained in an RPM?

Use the rpm query command passing it the 'l' flag (i.e. "list")

If the package is already installed you can just give the name of the package.

 % rpm -ql freeradius-mysql
/etc/raddb/sql/mysql/admin.sql
/etc/raddb/sql/mysql/counter.conf
/etc/raddb/sql/mysql/ippool.conf
/etc/raddb/sql/mysql/ippool.sql
/etc/raddb/sql/mysql/nas.sql
/etc/raddb/sql/mysql/schema.sql
/etc/raddb/sql/mysql/wimax.conf
/etc/raddb/sql/mysql/wimax.sql
/usr/lib/freeradius/rlm_sql_mysql-2.1.1.so
/usr/lib/freeradius/rlm_sql_mysql.so

If the package is not installed, or if you want to know the list of files in a specific rpm then pass the pathname of the rpm, e.g. along with the 'p' package flag, e.g.:

 % rpm -qlp /usr/src/redhat/RPMS/i386/freeradius-mysql-2.1.1-7.fc10.i386.rpm

How do I know which rpm package owns a specific file?

Use the rpm query command with the 'f' file flag. For example suppose you want to know what package is responsible for installing /usr/lib/freeradius/rlm_sql_mysql-2.1.1.so?

 % rpm -qf /usr/lib/freeradius/rlm_sql_mysql-2.1.1.so

freeradius-mysql-2.1.1-7.fc10.i686

What causes the "cannot open shared object file" error?

Sometimes you might see an error like this:

 radiusd: error while loading shared libraries: foo-1.2.3.so: cannot open shared object file: No such file or directory

The most likely cause is you have not installed a necessary freeradius subpackage which contains the shared library. Please refer to the areas of the FreeRADIUS Red Hat FAQ which discusses subpackages for more explanation. If you install the missing subpackage containing the shared library the problem should go away. Usually it's obvious from the name of the missing shared library which subpackage is necessary. If not please see the section of the FAQ which explains how to determine which package owns a file.

What is the difference between building from source and building from an SRPM?

When people say "build from source" they usually mean building from the sources provided by the upstream FreeRADIUS project, either from an officially released "tarball" or from the source code repository maintained by the FreeRADIUS project. The normal sequence of steps to build from sources is:

 % ./configure
 % make
 % sudo make install

The configure step typically requires passing command line parameters to the configure script directing it to produce a build with specific properties, e.g. which sub-components will be built, where items will be installed, etc. On Fedora/RHEL/CentOS systems it is very important to correctly configure the build such that the result matches expectations and conventions which have been adopted on Fedora/RHEL/CentOS installations. If these requirements are not satisfied the resulting build of FreeRADIUS may not operate correctly.

It's not always easy or obvious to determine what the requirements are for proper building and execution on Fedora/RHEL/CentOS systems. After the requirements have been identified it would also be advantageous to be able to re-execute the build with the exact same requirements. This is where SRPM's come into play. A SRPM is a Source RPM, it contains a copy of the upstream tarball for a specific release plus a file which contains exact instructions for how to build the RPM and install it, this file is called an RPM "spec" file, in the case of FreeRADIUS its named "freeradius.spec". In addition the SRPM may contain additional items not present in the upstream release such as files specific only to Fedora/RHEL/CentOS systems and patches for bugs which have been fixed in the SRPM but are not yet available in the upstream source release.

When FreeRADIUS is built using a Fedora/RHEL/CentOS specific SRPM all the leg work of figuring out how to properly configure the build, configure the installation, and install Fedora/RHEL/CentOS components not present in the upstream source release will have already been done for you. Thus it is highly recommended you build from an SRPM instead of raw upstream sources.

But the FreeRADIUS upstream release contains an RPM .spec file, why can't I just use that instead of the one from Fedora/RHEL/CentOS?

Because that is a generic spec file and has not been tailored to to Fedora/RHEL/CentOS.

A prebuilt version of FreeRADIUS in the version I need is not available for the distribution I'm using, how do I build one?

First please read the FAQ entry concerning building from sources vs. building from SRPM. To build from an SRPM you will need to execute the following sequences of steps described in How to build an SRPM

FreeRADIUS stopped working after an RPM upgrade. What's wrong?

In this circumstance there is an excellent chance configuration files were modified during the upgrade. Please read the section in this FAQ which explains how configuration files are handled during an RPM upgrade.

How to build an SRPM

Obtain a SRPM

Because Fedora by definition is the most current of the Fedora/RHEL/CentOS distributions you're likely to find a current SRPM in Fedora. The Fedora build system is called "Koji" (http://koji.fedoraproject.org) and it contains both the prebuilt RPM's and the SRPM the prebuilt version derived from. You'll want to find the freeradius package in Koji, you can either search for it or go directly to the freeradius RPM's in Koji using this link: http://koji.fedoraproject.org/koji/packageinfo?packageID=298

On that page will be a list of available freeradius RPM's, select the version you want to build. To understand the naming scheme see the FAQ entry describing RPM versioning. Click on the link for the version you want to build, this will take you to a page with all the information about that particular build including a list of the RPMS, one of those RPM's will be a source RPM (e.g. .src.rpm) commonly called an SRPM. You want to download that SRPM.

Alternatively you can get the spec file and the sources needed to build it from the Fedora CVS repository.

To use anonymous cvs access use a CVSROOT of

 :pserver:anonymous@cvs.fedoraproject.org:/cvs/pkgs

and do a CVS checkout of freeradius (e.g. cvs checkout freeradius).

This will populate several sub-directories under freeradius, each sub-directory is for a specific distribution release. The "devel" sub-directory is the most current and is sometimes referred to as "rawhide". cd into the distribution sub-directory of interest and run the command "make srpm", this will produce a .src.rpm (e.g. SRPM) equivalent to what you might have downloaded from Koji.

Install the SRPM

The RPM package builder, rpmbuild, expects to find a particular directory structure containing the following sub-directories under a root directory:

BUILD RPMS SOURCES SPECS SRPMS

By default the root directory is /usr/src/redhat, however please note this can be overridden, most notably by ~/.rpmmacros, if you have this hidden file in your home directory you can remap any of the above directories to meet your needs. However, this guide will assume the default values are in use.

The default root rpm directory gets created when you install the rpm-build package. You're going to need rpmbuild which is contained in the rpm-build package so if you don't have rpm-build installed yet now is the time to do it:

 % sudo yum install rpm-build

One of the pernicious things about the default /usr/src/redhat root is that all directories are owned by root with write and execute permissions granted only to root. We don't want to run as root unless we need to and there is seldom a reason you need to be root to build a package (installing the built packages is another story). So one of the first things I do is give normal users write and execute permissions for the directories under the root, you can do that this way:

 % su
 % find /usr/src/redhat -type d | xargs chmod a+wx

Now you can perform your builds as a normal user. If don't have permission to modify /usr/src/redhat you can always use the aforementioned ~/.rpmmacros to map the standard build directories to directories of your own choosing.

Now install the SRPM using rpm. Let's continue to use the example of freeradius-2.1.1-7.fc10:

 % rpm -ihv freeradius-2.1.1-7.fc10.src.rpm

This installs the spec file and all files necessary to perform the rpm build under the root, in other words those files are the "payload" of the SRPM, for example:

 % ls /usr/src/redhat/SPECS/

freeradius.spec

 % ls /usr/src/redhat/SOURCES/
 freeradius-logrotate	       freeradius-radiusd-init*
 freeradius-pam-conf	       freeradius-server-2.1.1.tar.bz2
 freeradius-radiusd-conf.patch

Install all necessary build requirements

When rpmbuild runs the rpm spec file will direct it to run certain commands, link against specific libraries, etc. This means those commands, libraries, etc. must be present on the the system or the build will fail. The spec file lists what it needs in order to perform the build by enumerating a list of rpm packages under the BuildRequires: tag. Every package listed in the BuildRequires must be present, if not the rpmbuild command will immediately fail.

How does one install the necessary BuildRequires packages?

There is utility tool which will help you, it's called yum-builddep and it's contained in the yum-utils package. If you don't have yum-utils installed then install it now:

 % yum install yum-utils

The yum-builddep tool is passed a src rpm on the command line, it then scans the BuildRequires and builds a list of packages required to build our package, if any of the necessary packages are not installed it will install them for you, e.g.:

 % sudo yum-builddep freeradius-2.1.1-7.fc10.src.rpm 

However yum-builddep does not currently know how to handle conditional BuildRequires and will sometimes incorrectly include or exclude a BuildRequires. This may force you do install your build dependencies manually, or you may prefer a manual process. For example at the time of this writing the perl-devel package is only available on Fedora and is not available in RHEL5. The spec file marks this BuildRequires as being conditionally required based on whether you're building on Fedora or RHEL. However yum-buliddep fails to recognize on RHEL this dependency is conditionally excluded and yum-builddep will exit with an error like this:

 Error: No Package found for perl-devel

In this case yum-builddep is not your friend and you'll just have to manually install the build dependencies.

The manual process is straightforward. To discover what build dependencies you might be missing run rpmbuild, if anything is missing it will list the missing packages and exit with an error. Then use yum to install each package rpmbuild listed as missing. For example:

 % rpmbuild -ba /usr/src/redhat/SPECS/freeradius.spec 
error: Failed build dependencies:
	openldap-devel is needed by freeradius-2.1.1-7.fc10.i386
 % sudo yum install openldap-devel

Perform the build

Now that all your build dependencies have been resolved in Step 3 you can perform the build using the rpmbuild command. You want to build everything so pass rpmbuild -ba command line arg, which stands for "build all". For example:

 % rpmbuild -ba /usr/src/redhat/SPECS/freeradius.spec

This will produce a lot of output. You might even want to redirect the output to a file so you can refer to it later if necessary.

The key information will be at the very end where it lists the rpm's which were produced, e.g.:

Wrote: /usr/src/redhat/SRPMS/freeradius-2.1.1-7.fc10.src.rpm
Wrote: /usr/src/redhat/RPMS/i386/freeradius-2.1.1-7.fc10.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/freeradius-libs-2.1.1-7.fc10.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/freeradius-utils-2.1.1-7.fc10.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/freeradius-devel-2.1.1-7.fc10.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/freeradius-ldap-2.1.1-7.fc10.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/freeradius-krb5-2.1.1-7.fc10.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/freeradius-perl-2.1.1-7.fc10.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/freeradius-python-2.1.1-7.fc10.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/freeradius-mysql-2.1.1-7.fc10.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/freeradius-postgresql-2.1.1-7.fc10.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/freeradius-unixODBC-2.1.1-7.fc10.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/freeradius-debuginfo-2.1.1-7.fc10.i386.rpm

Install the desired rpm's

The rpm's under /usr/src/redhat/RPMS are the packages you'll want to install. You don't need to install all the subpackages, install only what you intend to use. If you intend to use the mysql backend make sure you install the freeradius-mysql rpm you just created. By the same token, if you don't plan on using MySQL then don't install the freeradius-mysql subpackage. You'll always need at least the base freeradius package and the libs package, e.g.:

 % sudo rpm -Uhv /usr/src/redhat/RPMS/i386/freeradius-2.1.1-7.fc10.i386.rpm /usr/src/redhat/RPMS/i386/freeradius-libs-2.1.1-7.fc10.i386.rpm

rpm might complain about missing dependencies (when you built the rpm's in Step 4 a list of dependencies was created and inserted for each rpm you built). If you are missing a dependency then use yum to install the missing package(s).

Normally you can't update just one subpackage because there are dependencies between subpackages and the main package. In this case you'll need to update all the packages at once by passing the name of all freeradius packages currently installed on the command line to "rpm -Uhv", this causes everything to be updated in lockstep. The best way to handle this is to determine what freeradius packages are currently installed because you will have to update all the installed packages at once.

 % rpm -qa freeradius\*
 freeradius-2.1.1-7.fc11.i686
 freeradius-python-2.1.1-7.fc11.i686
 freeradius-mysql-2.1.1-7.fc11.i686
 freeradius-ldap-2.1.1-7.fc11.i686
 freeradius-utils-2.1.1-7.fc11.i686
 freeradius-libs-2.1.1-7.fc11.i686

This tell us at the minimum we have to update the packages freeradius, freeradius-python, freeradius-mysql, freeradius-ldap, freeradius-utils, and freeradius-libs all together at once. Thus the rpm upgrade command would look like this:

 % sudo rpm -Uhv /usr/src/redhat/RPMS/freeradius-2.1.1-7.fc10.i386.rpm \
 /usr/src/redhat/RPMS/i386/freeradius-libs-2.1.1-7.fc10.i386.rpm \
 /usr/src/redhat/RPMS/i386/freeradius-utils-2.1.1-7.fc10.i386.rpm \
 /usr/src/redhat/RPMS/i386/freeradius-ldap-2.1.1-7.fc10.i386.rpm \
 /usr/src/redhat/RPMS/i386/freeradius-python-2.1.1-7.fc10.i386.rpm \
 /usr/src/redhat/RPMS/i386/freeradius-mysql-2.1.1-7.fc10.i386.rpm

If figuring out what has to be simultaneously updated, including any missing dependencies, seems onerous then you're right. Normally this work is performed by a package updater such as yum which automatically does all this work for you. But because we've just locally built the packages we do not have the luxury of using the package updater because our local packages are not known to it. However, even though we didn't use the package updater we did use rpm to perform the installation and as a consequence we retain all the advantages of a rpm installation.