I am attempting an rpmbuild of freeradius due to the version included in Centos (1.14)- We are experiencing issues with windows vista, and read something in an earlier post regarding such a bug that 1.17 and later will fix. However, during the build, I receive this error: See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- + RADDB=/var/tmp/freeradius-server-root/etc/raddb + perl -i -pe 's/^#user =.*$/user = radiusd/' /var/tmp/freeradius-server-root/etc/raddb/radiusd.conf + perl -i -pe 's/^#group =.*$/group = radiusd/' /var/tmp/freeradius-server-root/etc/raddb/radiusd.conf + perl -i -pe 's/# shadow =/shadow =/' /var/tmp/freeradius-server-root/etc/raddb/radiusd.conf + rm -f /var/tmp/freeradius-server-root/usr/sbin/rc.radiusd + install -m 0644 CREDITS /var/tmp/freeradius-server-root/usr/share/doc/freeradius-server-2.0.3 + install -m 0644 COPYRIGHT /var/tmp/freeradius-server-root/usr/share/doc/freeradius-server-2.0.3 + install -m 0644 LICENSE /var/tmp/freeradius-server-root/usr/share/doc/freeradius-server-2.0.3 + cd redhat + install -m 755 rc.radiusd-redhat /var/tmp/freeradius-server-root/etc/rc.d/init.d/radiusd + install -m 644 radiusd-logrotate /var/tmp/freeradius-server-root/etc/logrotate.d/radiusd + install -m 644 radiusd-pam /var/tmp/freeradius-server-root/etc/pam.d/radius + cd .. + /usr/lib/rpm/brp-compress + /usr/lib/rpm/brp-strip + /usr/lib/rpm/brp-strip-static-archive strip: Unable to recognise the format of the input file `/var/tmp/freeradius-server-root/usr/lib64/rlm_perl.a(DynaLoader.a)' strip: Unable to recognise the format of the input file `/var/tmp/freeradius-server-root/usr/lib64/rlm_perl.a(DynaLoader.a)' + /usr/lib/rpm/brp-strip-comment-note Processing files: freeradius-server-2.0.3-0 error: File not found: /var/tmp/freeradius-server-root/usr/share/freeradius-server error: File must begin with "/": %{_incdir}/freeradius/* RPM build errors: File not found: /var/tmp/freeradius-server-root/usr/share/freeradius-server File must begin with "/": %{_incdir}/freeradius/* ANY assistance in this issue would be wonderful! Thank you, Austin G. Smith, A+, MCP Digital Son, I.T. Services www.digitalson.com 678.213.0550 x:101 Office 678.213.0535 Fax Need reliable hosting? www.digitalsonhosting.com
Hi,
I am attempting an rpmbuild of freeradius due to the version included in Centos (1.14)- We are experiencing issues with windows vista, and read something in an earlier post regarding such a bug that 1.17 and later will fix.
the package is suffering from split personalities. it doesnt know if its 'freeradius' or 'freeradius-server'. i would advise the simple action (unless you want to trawl the SPEC) download freeradius-server-2.0.3.tar.gz extract it, move the directory to just 'freeradius-2.0.3' then tar back up into freeradius-2.0.3.tar.gz then edit the freeradius-spec file and at the near top, change the line that says Name: freeradius-server to just Name: freeradius it should then work. alan
Hi,
I am attempting an rpmbuild of freeradius due to the version included in Centos (1.14)- We are experiencing issues with windows vista, and read something in an earlier post regarding such a bug that 1.17 and later will fix.
you can ignore my previous message - there are still underlying issues and a tweak of the spec file is needed. I've attached a SPEC file which should work fine on redhat/centos systems - basically, incdir and datadir have been changed to be appropriate to the new naming. tested this on a couple of boxes just now alan
Thanks!! That worked like a champion! As note, I had to go to /etc/raddb/certs and run ./bootstrap to gen the certs then recursively chown the /etc/raddb directory to the radiusd user. After that, radiusd fired up with no errors whatsoever! I am off to configure now ;) If anyone needs this rpm, it can be found at http://www.digitalson.com/freeradius-server-2.0.3-0.x86_64.rpm Hopefully this will help someone else out, as I have been helped ;) Cheers, Austin G. Smith, A+, MCP Digital Son, I.T. Services www.digitalson.com 678.213.0550 x:101 Office 678.213.0535 Fax Need reliable hosting? www.digitalsonhosting.com -----Original Message----- From: freeradius-users-bounces+austin=digitalson.com@lists.freeradius.org [mailto:freeradius-users-bounces+austin=digitalson.com@lists.freeradius. org] On Behalf Of A.L.M.Buxey@lboro.ac.uk Sent: Sunday, April 06, 2008 8:20 AM To: FreeRadius users mailing list Subject: Re: RPM Build Errors Hi,
I am attempting an rpmbuild of freeradius due to the version included in Centos (1.14)- We are experiencing issues with windows vista, and read something in an earlier post regarding such a bug that 1.17 and later will fix.
you can ignore my previous message - there are still underlying issues and a tweak of the spec file is needed. I've attached a SPEC file which should work fine on redhat/centos systems - basically, incdir and datadir have been changed to be appropriate to the new naming. tested this on a couple of boxes just now alan
Hi,
Thanks!!
That worked like a champion! As note, I had to go to /etc/raddb/certs and run ./bootstrap to gen the certs then recursively chown the /etc/raddb directory to the radiusd user.
so long as the correct user (radius?) exists, all you need to do is chown -R radius:radius /path/to/raddb run radiusd - the first time you run it, it will generate the certs, then chown -R radius:radius path/to/raddb again
If anyone needs this rpm, it can be found at http://www.digitalson.com/freeradius-server-2.0.3-0.x86_64.rpm
64 bit eh? keep us up to date with any quirks you might find. alan
10-4 will do. Thanks again for your assistance, I really do appreciate it! Austin G. Smith, A+, MCP Digital Son, I.T. Services www.digitalson.com 678.213.0550 x:101 Office 678.213.0535 Fax Need reliable hosting? www.digitalsonhosting.com -----Original Message----- From: freeradius-users-bounces+austin=digitalson.com@lists.freeradius.org [mailto:freeradius-users-bounces+austin=digitalson.com@lists.freeradius. org] On Behalf Of A.L.M.Buxey@lboro.ac.uk Sent: Sunday, April 06, 2008 11:28 AM To: FreeRadius users mailing list Subject: Re: RPM Build Errors Hi,
Thanks!!
That worked like a champion! As note, I had to go to /etc/raddb/certs and run ./bootstrap to gen the certs then recursively chown the /etc/raddb directory to the radiusd user.
so long as the correct user (radius?) exists, all you need to do is chown -R radius:radius /path/to/raddb run radiusd - the first time you run it, it will generate the certs, then chown -R radius:radius path/to/raddb again
If anyone needs this rpm, it can be found at http://www.digitalson.com/freeradius-server-2.0.3-0.x86_64.rpm
64 bit eh? keep us up to date with any quirks you might find. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
Thanks!!
That worked like a champion! As note, I had to go to /etc/raddb/certs and run ./bootstrap to gen the certs then recursively chown the /etc/raddb directory to the radiusd user.
its just shameful that no distros feel like updating their default version from 1.1.dinosaur to 2.0.recent alan
On Sun, Apr 06, 2008 at 04:29:36PM +0100, A.L.M.Buxey@lboro.ac.uk wrote:
its just shameful that no distros feel like updating their default version from 1.1.dinosaur to 2.0.recent
IIRC, you were talking about CentOS (== RHEL rebuild). One of the fundamental issues with enterprise-grade (and long-term-supported) Linux distros is that they want to stay as compatible as possible during its life-time. If possible, they backport security fixes, etc. Although sometimes I would also like to have a newer version of something, this *does* pay back in overall stability and API/ABI compatibility throughout the OS's life time. Otherwise you should use Fedora (the fast-moving alternative for RHEL/CentOS). And if you really do need newer packages on CentOS, take the latest Fedora source RPM and rebuild it on RHEL/CentOS. That is usually "integrated" in the OS environment in the same way as RHEL/CentOS (but always be careful and inspect the spec file carefully for new things). For the same reason, I'm still using a (very) old FreeRADIUS on my RHEL4-compatible systems, although I've been flamed for doing that on this list earlier ;-). -- -- Jos Vos <jos@xos.nl> -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204
Jos Vos wrote:
Although sometimes I would also like to have a newer version of something, this *does* pay back in overall stability and API/ABI compatibility throughout the OS's life time.
It pays *them*. It doesn't pay *us*. They have a *great* business model: sell "long term support" for packages, and push most of the questions onto the public forums such as this list. Their customers should have HUGE warnings in all of the documentation, saying "THIS PACKAGE IS YEARS OUT OF DATE." Alan DeKok.
On Sun, Apr 06, 2008 at 07:17:27PM +0200, Alan DeKok wrote:
Jos Vos wrote:
Although sometimes I would also like to have a newer version of something, this *does* pay back in overall stability and API/ABI compatibility throughout the OS's life time.
It pays *them*. It doesn't pay *us*.
It pays back to the customers. They want a stable OS environment, not one where the software interfaces may change at every update.
They have a *great* business model: sell "long term support" for packages, and push most of the questions onto the public forums such as this list.
The only way to solve is is to "forbid" long-term-support type Linux distros. And due to the facts that there is a need for that distros and that we live in free (software) world, this won't happen. Sorry...
Their customers should have HUGE warnings in all of the documentation, saying "THIS PACKAGE IS YEARS OUT OF DATE."
People running a 7-year supported OS *do* know (well, they should) that their software cann be up to 7-8 years old. -- -- Jos Vos <jos@xos.nl> -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204
Jos Vos wrote:
It pays back to the customers. They want a stable OS environment, not one where the software interfaces may change at every update.
Then the customers can pay for that. Since they're often paying the distro for LTS, they can go to the distro for help. However, most distros know nothing about the packages they're supporting, so the users end up here.
The only way to solve is is to "forbid" long-term-support type Linux distros. And due to the facts that there is a need for that distros and that we live in free (software) world, this won't happen. Sorry...
That's not what I said. When you sell something, your customers should go to *you* for support. You can afford to support them, because you're getting paid. My issues with the distros && LTS is that the *distros* are often getting paid, and *we're* being asked to do support. e.g. Try bringing your car into a tobacco shop for an oil change. They'll laugh at you, or think you're crazy. The real issue, IMHO with LTS distros is people doing something *new* with them. LTS is fine for a box that gets built, configured, shipped, and never touched again. If someone is going to keep poking the box over time, and trying to get it to work with *new* configurations, than they have chosen LTS in error.
People running a 7-year supported OS *do* know (well, they should) that their software cann be up to 7-8 years old.
Not from the messages I've seen on this list. "upgrade? But I'm at the newest version my distro supports! I didn't know that there were newer versions..." And (see above) the problems are usually because they're *changing* the configuration of a box that worked 3 years ago. Well, if it worked then, why the heck are you breaking it now? Alan DeKok.
On Mon, Apr 07, 2008 at 07:50:06AM +0200, Alan DeKok wrote:
Then the customers can pay for that. Since they're often paying the distro for LTS, they can go to the distro for help. However, most distros know nothing about the packages they're supporting, so the users end up here.
This is a correct observation. But note that the vendors do not really sell detailed support for all apps, but they sell a warranty to maintain the distro for 7 years, especially related to security fixes, while keeping the interfaces unchanhged (with exceptions). For all the 1000+ apps in a distro, there are mailing lists, forums, or additional commercial support.
That's not what I said. When you sell something, your customers should go to *you* for support. You can afford to support them, because you're getting paid. My issues with the distros && LTS is that the *distros* are often getting paid, and *we're* being asked to do support.
I understand your point, but this is the way it all works. And, again, the same happens for all other apps. Still, vendors *do* a lot of work to maintain their distro, backport security fixes etc.
The real issue, IMHO with LTS distros is people doing something *new* with them. LTS is fine for a box that gets built, configured, shipped, and never touched again. If someone is going to keep poking the box over time, and trying to get it to work with *new* configurations, than they have chosen LTS in error.
Not necessarily. When they have production servers and at some point people want to include a RADIUS server, or start using webmail, or want to enable some other subsystem, then they are going to start using a new feature on their (old) boxes. -- -- Jos Vos <jos@xos.nl> -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204
Jos Vos wrote:
For all the 1000+ apps in a distro, there are mailing lists, forums, or additional commercial support.
Uh... no. If you want to work for such a distro for free, go ahead.
I understand your point, but this is the way it all works. And, again, the same happens for all other apps. Still, vendors *do* a lot of work to maintain their distro, backport security fixes etc.
That's their business. I'm happy for them to make money doing that. But if their customers are expecting third-party support, they're sadly mistaken. The only support they'll get is "UPGRADE!"
Not necessarily. When they have production servers and at some point people want to include a RADIUS server, or start using webmail, or want to enable some other subsystem, then they are going to start using a new feature on their (old) boxes.
Then they are welcome to upgrade to a version *we* support. If they're not willing to do that, they can pay support to Redhat. If they're not willing to do that, then *you* can support them. I don't see any reason I should support them. Alan DeKok.
I agree. I am going to open a bug report on this one with the centos team. Hopefully they will update. Thanks, Austin G. Smith, A+, MCP Digital Son, I.T. Services www.digitalson.com 678.213.0550 x:101 Office 678.213.0535 Fax Need reliable hosting? www.digitalsonhosting.com -----Original Message----- From: freeradius-users-bounces+austin=digitalson.com@lists.freeradius.org [mailto:freeradius-users-bounces+austin=digitalson.com@lists.freeradius. org] On Behalf Of A.L.M.Buxey@lboro.ac.uk Sent: Sunday, April 06, 2008 11:30 AM To: FreeRadius users mailing list Subject: Re: RPM Build Errors Hi,
Thanks!!
That worked like a champion! As note, I had to go to /etc/raddb/certs and run ./bootstrap to gen the certs then recursively chown the /etc/raddb directory to the radiusd user.
its just shameful that no distros feel like updating their default version from 1.1.dinosaur to 2.0.recent alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sun, Apr 06, 2008 at 11:54:58AM -0400, Austin G. Smith wrote:
I agree. I am going to open a bug report on this one with the centos team. Hopefully they will update.
They won't. CentOS stays fully compatible with RHEL. Open a bug report on Red Hat's bugzilla for RHEL instead. -- -- Jos Vos <jos@xos.nl> -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204
Hi,
On Sun, Apr 06, 2008 at 11:54:58AM -0400, Austin G. Smith wrote:
I agree. I am going to open a bug report on this one with the centos team. Hopefully they will update.
They won't. CentOS stays fully compatible with RHEL. Open a bug report on Red Hat's bugzilla for RHEL instead.
whilst MOST of the FR 1.x config files are forward compatible to FR 2.x, there are some quirks and incompatibles. for this reason, FR 2.x will never be available to older releases because of the required compat. i expect the next version of RHEL to come with FR 2.x though. alan
-----Original Message----- From: freeradius-users-bounces+ben=wisper- wireless.com@lists.freeradius.org [mailto:freeradius-users- bounces+ben=wisper-wireless.com@lists.freeradius.org] On Behalf Of A.L.M.Buxey@lboro.ac.uk Sent: Sunday, April 06, 2008 12:15 PM To: FreeRadius users mailing list Subject: Re: RPM Build Errors
Hi,
On Sun, Apr 06, 2008 at 11:54:58AM -0400, Austin G. Smith wrote:
I agree. I am going to open a bug report on this one with the centos team. Hopefully they will update.
They won't. CentOS stays fully compatible with RHEL. Open a bug report on Red Hat's bugzilla for RHEL instead.
whilst MOST of the FR 1.x config files are forward compatible to FR 2.x, there are some quirks and incompatibles.
for this reason, FR 2.x will never be available to older releases because of the required compat. i expect the next version of RHEL to come with FR 2.x though.
CentOS 5.1 is still installing 1.1.3 and I haven't found any official repo for either CentOS or RHEL that is pushing anything newer. Ben
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
A.L.M.Buxey@lboro.ac.uk wrote:
its just shameful that no distros feel like updating their default version from 1.1.dinosaur to 2.0.recent
There's a way to fix that: issue 1.1.8 with a few patches, and a large WARNING in the README's, configuration files, man pages, etc. saying "NO LONGER SUPPORTED: UPGRADE!" After the 1000's email from their annoyed customer asking why they're distributing an old version, they'll upgrade. Alan DeKok.
Hi,
A.L.M.Buxey@lboro.ac.uk wrote:
its just shameful that no distros feel like updating their default version from 1.1.dinosaur to 2.0.recent
There's a way to fix that: issue 1.1.8 with a few patches, and a large WARNING in the README's, configuration files, man pages, etc. saying "NO LONGER SUPPORTED: UPGRADE!"
After the 1000's email from their annoyed customer asking why they're distributing an old version, they'll upgrade.
that'd only work if the distros actually took the latest 1.1.x's and didnt touch the distributed configs either... eg tonight I cam face to face with a defalt 1.1.6 - :-( alan
A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
A.L.M.Buxey@lboro.ac.uk wrote:
its just shameful that no distros feel like updating their default version from 1.1.dinosaur to 2.0.recent There's a way to fix that: issue 1.1.8 with a few patches, and a large WARNING in the README's, configuration files, man pages, etc. saying "NO LONGER SUPPORTED: UPGRADE!"
After the 1000's email from their annoyed customer asking why they're distributing an old version, they'll upgrade.
that'd only work if the distros actually took the latest 1.1.x's and didnt touch the distributed configs either... eg tonight I cam face to face with a defalt 1.1.6 - :-(
I can see two options, neither very pleasant :o( 1. For the short term distributions (Fedora, Ubuntu), volunteer to be a packager. In principle I could do this for Fedora; in practice I have no time or patience for the politics involved. 2. For the long term distributions (e.g. RHEL, CentOS, Ubuntu LTS) politely ask the distribution to either track no more than 6 months old, or if they are unable/unwilling, ask them not to include FreeRadius. It's GPLed software so of course they're free to refuse the latter; but they would probably honour it. Whether it's desirable is another matter I suppose you could always put a #define RELEASETIME 12xxxxx ...in a header and an "if gettimeofday() > RELEASETIME: printf(HUGERR)" in the source but as you point out, it only solves the problem from this point onwards. Sadly, people want packaged software, they want package updates to not cause major upheaval, and distributions fill that niche. Many heavily modified and/or legacy packages have notices in the distro packages stating this and asking bugs to be filed on the distro bug finder (e.g. dhclient on redhat/fedora) but people don't read this, google for the package name and come straight here. Sigh.
On Sun, Apr 06, 2008 at 08:06:40PM +0100, Phil Mayers wrote:
I can see two options, neither very pleasant :o(
1. For the short term distributions (Fedora, Ubuntu), volunteer to be a packager. In principle I could do this for Fedora; in practice I have no time or patience for the politics involved.
Fedora does follow the releases pretty close, I think. They now have version 2.0.2. You can always trigger the maintainer (who's name is in the spec file) for upgrading.
2. For the long term distributions (e.g. RHEL, CentOS, Ubuntu LTS) politely ask the distribution to either track no more than 6 months old, or if they are unable/unwilling, ask them not to include FreeRadius.
It's GPLed software so of course they're free to refuse the latter; but they would probably honour it. Whether it's desirable is another matter
I don't think they will honour that. And I think it's a unrealistic request. As I said in an old thread (when I asked something related to version 1.0.1 (!), as included in RHEL4): on this list you're of course all free to ignore questions you don't like, but I honoustly hope we also stay all free to ask questions about older releases. -- -- Jos Vos <jos@xos.nl> -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204
Jos Vos wrote:
On Sun, Apr 06, 2008 at 08:06:40PM +0100, Phil Mayers wrote:
I can see two options, neither very pleasant :o(
1. For the short term distributions (Fedora, Ubuntu), volunteer to be a packager. In principle I could do this for Fedora; in practice I have no time or patience for the politics involved.
Fedora does follow the releases pretty close, I think. They now have version 2.0.2. You can always trigger the maintainer (who's name is in the spec file) for upgrading.
In Fedora 9 beta, yes. Fedora 7 & 8 have 1.1.7, which is nice. Maybe that other, non-Fedora distros are equally up-to-date; if so, it's not an issue.
2. For the long term distributions (e.g. RHEL, CentOS, Ubuntu LTS) politely ask the distribution to either track no more than 6 months old, or if they are unable/unwilling, ask them not to include FreeRadius.
It's GPLed software so of course they're free to refuse the latter; but they would probably honour it. Whether it's desirable is another matter
I don't think they will honour that. And I think it's a unrealistic
Shrug. I disagree on both counts, but I don't see the point in arguing with you.
request. As I said in an old thread (when I asked something related to version 1.0.1 (!), as included in RHEL4): on this list you're of course all free to ignore questions you don't like, but I honoustly hope we also stay all free to ask questions about older releases.
You're free to ask what you like, in that context. People might not answer, and in my opinion you'll be degrading the signal/noise ratio, but I'm not the boss of anyone - ask away. For example: on several occasions I've fired up 1.1.7 or 2.0.x and tested a suggestion before I've answered i.e. I'm actually doing a little bit of work, because the mailing list has given me so much I feel I should give back. I've even pulled source tarballs and given the source code for a module a quick look over to clarify exact behaviour before replying. I'm not going to waste time doing that for 1.0.1, and I feel pretty confident when I hazard a guess that few people will.
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Austin G. Smith -
Ben Wiechman -
Jos Vos -
Phil Mayers