--- /dev/null
+= Introduction
+
+There are several "Red Hat" distributions which address different
+goals and as a consequence have different philosophies driven by
+different constraints.
+
+=== 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:<br><br>
+
+|===
+|Spec File Tag |Did File Change in RPM update? |If on-disk file is unmodified then result is |If on-disk file is modified<br>then result is
+|%config(noreplace) |No |File from update |Modified file
+|%config(noreplace) |Yes |File from update |Modified file, File from update saved in .rpmnew
+|%config |No |File from update |Modified file
+|%config |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 [[Red-Hat-FAQ#What-is-the-difference-between-building-from-source-and-building-from-an-SRPM%253F|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 [[Red-Hat-FAQ#How-to-build-an-SRPM|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.
projects / thirdparty / freeradius-server.git / commitdiff
