jdennis at redhat.com
Tue Oct 25 14:54:03 CEST 2011
On 10/25/2011 07:47 AM, Phil Mayers wrote:
> On 25/10/11 12:37, Victor Guk wrote:
>> I want to install freeradius on RHEL5.
>> I downloaded tar.bz2.(version 2.1.12)
>> Run *rpmbuild -ba freeradius.spec*, but get an error:
> There are "freeradius2" RPMs in the RHEL channels.
> I suggest you either:
> a. Install one of those, or
> b. Download the .src.rpm for one of those, and re-use the .spec file
> The problem seems to be that the .spec file is out of date and not
> naming all files, as is required.
> I don't use the bundled .spec file, so haven't looked at it in years. We
> should probably just use the one that RedHat are using these days.
Yes, the bundled spec file gets out of sync. The RHEL 5.8 update will
have freeradius2-2.1.12 in it but it won't be released until the next
quarterly update which is currently scheduled for GA in Februrary.
In RHEL 5 the package is named freeradius2 because RHEL 5 originally
shipped with freeradius 1.x and once a package ships in RHEL that
doesn't maintain it's configuration we can't rebase it, it has to stay
so as not to affect users of the original package.
For RHEL 5 you can't just take the Fedora SRPM and build it, RHEL 5
being older has some differences. (Hint: add the missing files to the
existing RHEL 5 freeradius2 spec file, there is a minor packaging bug
related to pam you'll miss and you will have to adjust the patch for the
certificate configuration (or just remove it) and that will get you
something nearly identical to what will show up in the 5.8 update.
My first inclination was to just attach the necessary files and let you
build it yourself but then I recalled how we're prohibited from sending
customers RPM's out of band from the normal distribution channel. There
is nothing dark and sinister about this, rather it's a practical
response to a serious problem. Customers who received out of band RPM's
from engineering were calling for support on those RPM's. But the
support team can't provide support for packages they've never seen, have
not been through our QE process, nor does support have any access to the
package, they can't install the package or run it. So how can they
support it? I'm sure you understand the issue.
I'm fairly certain the rule against providing pre-built RPM's outside
the distribution channel also applies to providing the SRPM, but I'll
check. FWIW when we provided freeradius2 RHEL 5 packages a while back on
my personal web page I had to apply for a waiver to do that. The reason
the waiver was granted was because we knew there was going to be a
significant delay before the freeradius2 packages appeared in the RHEL 5
channel. But in this instance the updated 2.1.12 freeradius2 packages
are currently in QE testing and are being staged for the quarterly
update. Yes, things move slower in enterprise distributions, that's why
they are more stable. And yes we do a lot of testing for RHEL.
John Dennis <jdennis at redhat.com>
Looking to carve out IT costs?
More information about the Freeradius-Users