Hi, when using FreeRADIUS 1.1, I could store RADIUS replies like Reply-Message := "Hello, %u", and get the %u expanded to the username in the reply. After upgrading to FreeRADIUS 2.1, this doesn't seem to work anymore, the reply contains the unexpanded %u. Has this feature been removed, or do I have to configure it explicitly? Best regards, Isidor Zeuner
when using FreeRADIUS 1.1, I could store RADIUS replies like Reply-Message := "Hello, %u", and get the %u expanded to the username in the reply. After upgrading to FreeRADIUS 2.1, this doesn't seem to work anymore, the reply contains the unexpanded %u. Has this feature been removed, or do I have to configure it explicitly?
Isidor, Check the man page for unlang -- man unlang -- for current details on strings and variables. For User-Name, try: > Reply-Message := "Hello, %{User-Name}" Tim
Hi List Just wondering how to install Freeradius on Centos 5.4 using YUM now that the "Tech preview" is over for redhat. Thanks -- Andrew Paternoster Senior System Engineer GPK Computers Pty Ltd T 1300 854 223 F 1300 854 228 Did you know that you can now log faults just by sending an email to support@gpk.net.au --------------------------------------------------------------------------- The information contained in or accompanying this e-mail is intended only for the use of the stated recipient and may contain information that is confidential and/or privileged. If the reader is not the intended recipient or the agent thereof, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited and may constitute a breach of confidence and/or privilege. If you have received this e-mail in error, please notify us immediately. Any views or opinions presented are those solely of the author and do not necessarily represent those of GPK Computers Pty Ltd.. Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this e-mail, the company cannot accept responsibility for any loss or damage arising from the use of this e-mail or attachments ---------------------------------------------------------------------------
On 04/18/2010 07:17 PM, Andrew Paternoster wrote:
Hi List
Just wondering how to install Freeradius on Centos 5.4 using YUM now that the "Tech preview" is over for redhat.
Your best bet is to contact centos.org and find out what their plans are for their 5.5 update. They usually follow the Red Hat release by a few weeks. (Or you might consider installing RHEL :-) Also you might want to be aware the RHEL 5.5 update contains FreeRADIUS 2.1.7, not 2.1.8 because 2.1.8 was not available when RHEL 5.5 was frozen. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Hi,
for their 5.5 update. They usually follow the Red Hat release by a few weeks. (Or you might consider installing RHEL :-)
Also you might want to be aware the RHEL 5.5 update contains FreeRADIUS 2.1.7, not 2.1.8 because 2.1.8 was not available when RHEL 5.5 was frozen.
given that 2.1.8 was bug fixes...and 2.1.9 will be likewise...with no new feature/method changes....then i'd hope that 2.1.8 (or 2.1.9) will just appear in 5.5 later as a security/bug update that yum etc get and install later...just like any other package update? ie should we worry that 2.1.7 was the point release at freeze time? alan
On 04/19/2010 10:40 AM, Alan Buxey wrote:
Hi,
for their 5.5 update. They usually follow the Red Hat release by a few weeks. (Or you might consider installing RHEL :-)
Also you might want to be aware the RHEL 5.5 update contains FreeRADIUS 2.1.7, not 2.1.8 because 2.1.8 was not available when RHEL 5.5 was frozen.
given that 2.1.8 was bug fixes...and 2.1.9 will be likewise...with no new feature/method changes....then i'd hope that 2.1.8 (or 2.1.9) will just appear in 5.5 later as a security/bug update that yum etc get and install later...just like any other package update?
ie should we worry that 2.1.7 was the point release at freeze time?
The general RHEL policy is *not* to rebase packages (i.e. change to higher upstream releases). This is done for stability reasons. However some isolated packages are permitted to be rebased, maily desktop applications such as firefox. Rebasing servers is something which rightly gives RHEL engineering management heartburn and sleepless nights wondering how that might break thousands of critical customer installations. The simple answer is that you shouldn't expect FreeRADIUS to be rebased in RHEL, however if there are enough customer issues with FreeRADIUS 2.1.7 it can be brought up for consideration. RHEL 6 which is under development and is currently in beta testing does have FreeRADIUS 2.1.8. So a possible solution would be to upgrade from RHEL 5 to RHEL 6. If FreeRADIUS 2.1.9 is released shortly I *may* be able to get it into RHEL 6, but as I said RHEL is extremely conservative and modifying versions that have already been through alpha and beta is deeply frowned upon, I wouldn't count on it. If you really want to always have available the latest upstream releases of any package then electing to install an enterprise distribution whose primary goal is stability is not the right choice (in fact the two are mutually exclusive). The correct selection of a cutting edge distribution with the latest upstream release would be Fedora, not RHEL. Fedora is the proving ground for subsequent *major* RHEL releases. Another solution is to stabilize FreeRADIUS such that the need for frequent version upgrades is not necessary. Rather than adding new features focus on bug elimination. Some projects have a stable branch and an "future" branch. The pace of version releases for FreeRADIUS is "brisk". While that has many merits and the FreeRADIUS developers should be applauded for their prolific contributions it also has some downsides, mainly it conflicts with the goals of enterprise stability. A stable branch would be a much better fit for an enterprise distribution such as RHEL. Stability vs. features is just one of the classic trade-offs in computer science, just like memory usage vs. processor cycles. They really are polar ends in continuous spectrum, RHEL clearly targets one end of that spectrum and as a consequence you lose out on the other end. While on the other hand Fedora focuses on the other end. We do both independently (Fedora and RHEL), but we can't do both in one distribution. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On 04/19/2010 11:28 AM, John Dennis wrote:
The simple answer is that you shouldn't expect FreeRADIUS to be rebased in RHEL, however if there are enough customer issues with FreeRADIUS 2.1.7 it can be brought up for consideration.
I do want to clarify the above. The general procedure in RHEL is when a *customer* reports a bug in a package we check upstream and see if they have a fix, if so we "backport" the fix into the existing version in RHEL. If upstream does not have a fix we develop a fix and give it to upstream. In either case the net result is a "surgical" fix insertion into the existing package version in RHEL, not a version upgrade, the version stays the same (with a bumped release number). Thus during the life-cylce of a RHEL major release a number of packages will have had surgical fixes (patches) applied to them based on customer needs. The idea here is that a surgical fix is less likely to break things than importing an entirely never version of the package without control over the changes. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Hi,
Another solution is to stabilize FreeRADIUS such that the need for frequent version upgrades is not necessary. Rather than adding new features focus on bug elimination. Some projects have a stable branch and an "future" branch. The pace of version releases for FreeRADIUS is "brisk". While that has many merits and the FreeRADIUS developers should be applauded for their prolific contributions it also has some downsides, mainly it conflicts with the goals of enterprise stability. A stable branch would be a much better fit for an enterprise distribution such as RHEL.
..and thats about to happen. historically this was FR 2.0.x v's 2.1.x but all the drive from people was functions...so 2.1.x got the work. however...and from recent emails..the plan is that 2.1.x will now curtail new features and will work on bug-fixes....all new exciting features are to be in 2.2.x
spectrum and as a consequence you lose out on the other end. While on the other hand Fedora focuses on the other end. We do both independently (Fedora and RHEL), but we can't do both in one distribution.
:-) i prefer a stable distribution to be one in which the base is solid and i can run whatever unstable/dodgy/bleeding edge stuff on it that i want , safe in the knowledge that it wont be the OS to blame when thigns go bang. for this reason, the marriage of a RHEL foundation with self-build packages for end-users services is the ultimate mix. alan
So what's the best way to move forward with this? It is possible for someone to take over what jdennis was providing with his YUM resp? Or do we all have to go back to building for the source if we want the latest ver? Thanks -- Andrew Paternoster GPK Computers Pty Ltd T 1300 854 223 F 1300 854 228 --------------------------------------------------------------------------- The information contained in or accompanying this e-mail is intended only for the use of the stated recipient and may contain information that is confidential and/or privileged. If the reader is not the intended recipient or the agent thereof, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited and may constitute a breach of confidence and/or privilege. If you have received this e-mail in error, please notify us immediately. Any views or opinions presented are those solely of the author and do not necessarily represent those of GPK Computers Pty Ltd.. Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this e-mail, the company cannot accept responsibility for any loss or damage arising from the use of this e-mail or attachments --------------------------------------------------------------------------- Did you know that you can now log faults just by sending an email to support@gpk.net.auSenior System Engineer-----Original Message----- From: freeradius-users-bounces+andrew=gpk.net.au@lists.freeradius.org [mailto:freeradius-users-bounces+andrew=gpk.net.au@lists.freeradius.org] On Behalf Of Alan Buxey Sent: Tuesday, 20 April 2010 2:16 AM To: John Dennis Cc: FreeRadius users mailing list Subject: Re: Centos Yum Packages Hi,
Another solution is to stabilize FreeRADIUS such that the need for frequent version upgrades is not necessary. Rather than adding new features focus on bug elimination. Some projects have a stable branch and an "future" branch. The pace of version releases for FreeRADIUS is "brisk". While that has many merits and the FreeRADIUS developers should be applauded for their prolific contributions it also has some downsides, mainly it conflicts with the goals of enterprise stability. A stable branch would be a much better fit for an enterprise distribution such as RHEL.
..and thats about to happen. historically this was FR 2.0.x v's 2.1.x but all the drive from people was functions...so 2.1.x got the work. however...and from recent emails..the plan is that 2.1.x will now curtail new features and will work on bug-fixes....all new exciting features are to be in 2.2.x
spectrum and as a consequence you lose out on the other end. While on the other hand Fedora focuses on the other end. We do both independently (Fedora and RHEL), but we can't do both in one distribution.
:-) i prefer a stable distribution to be one in which the base is solid and i can run whatever unstable/dodgy/bleeding edge stuff on it that i want , safe in the knowledge that it wont be the OS to blame when thigns go bang. for this reason, the marriage of a RHEL foundation with self-build packages for end-users services is the ultimate mix. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html __________ Information from ESET NOD32 Antivirus, version of virus signature database 5041 (20100419) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 5041 (20100419) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
On 04/19/2010 06:41 PM, Andrew Paternoster wrote:
So what's the best way to move forward with this? It is possible for someone to take over what jdennis was providing with his YUM resp? Or do we all have to go back to building for the source if we want the latest ver?
You can follow the instructions posted here: http://wiki.freeradius.org/Red_Hat_FAQ In the section labeled "How to build an SRPM" that will give you the latest version on any RHEL/CentOS system. Sorry I cannot provide pre-built RPM's for RHEL when the package is already in a RHEL distribution channel. BTW, that prohibition extends to EPEL as well. The reason is simple. Our support organization cannot provide support for packages we didn't build and distribute, if we did we would effectively be supporting any binary which could be found on the internet, an obviously impossible support scenario. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
RHEL 6 which is under development and is currently in beta testing does have FreeRADIUS 2.1.8. So a possible solution would be to upgrade from RHEL 5 to RHEL 6. If FreeRADIUS 2.1.9 is released shortly I *may* be able to get it into RHEL 6,
2.1.9 should be released in a week or two.
Another solution is to stabilize FreeRADIUS such that the need for frequent version upgrades is not necessary. Rather than adding new features focus on bug elimination. Some projects have a stable branch and an "future" branch. The pace of version releases for FreeRADIUS is "brisk". While that has many merits and the FreeRADIUS developers should be applauded for their prolific contributions it also has some downsides, mainly it conflicts with the goals of enterprise stability. A stable branch would be a much better fit for an enterprise distribution such as RHEL.
'git' has made this easier. There's a v2.1.x branch, a 'stable' branch, and a 'master' branch. v2.1.x: bug fixes only (2.1.9 so far has one minor feature over 2.1.8) stable: new development master: deprecated, will likely be replaced by 'stable'. We should be able to release 2.2.0 in a month or two. It will contain API changes that are incompatible with 2.1.x, and 2.0.x. All external modules will need to be updated. 2.1.9 is the "bug fix only" branch. We may even have a 2.1.10 and a 2.1.11.
Stability vs. features is just one of the classic trade-offs in computer science, just like memory usage vs. processor cycles. They really are polar ends in continuous spectrum, RHEL clearly targets one end of that spectrum and as a consequence you lose out on the other end. While on the other hand Fedora focuses on the other end. We do both independently (Fedora and RHEL), but we can't do both in one distribution.
Switching from CVS to git has made this a lot easier. Alan DeKok.
Thanks, Tim,
when using FreeRADIUS 1.1, I could store RADIUS replies like Reply-Message := "Hello, %u", and get the %u expanded to the username in the reply. After upgrading to FreeRADIUS 2.1, this doesn't seem to work anymore, the reply contains the unexpanded %u. Has this feature been removed, or do I have to configure it explicitly?
Isidor,
Check the man page for unlang -- man unlang -- for current details on strings and variables.
For User-Name, try: > Reply-Message := "Hello, %{User-Name}"
I also tried %{User-Name}, but it made no difference. The problem with the unlang manpage is that it doesn't make it very clear _when_ the expansions are processed. Variables are definitely expanded before the SQL server receives queries, as the query templates use variables. I get the impression that the expansions are not processed anymore on the SQL results. Best regards, Isidor
Isidor Zeuner wrote:
The problem with the unlang manpage is that it doesn't make it very clear _when_ the expansions are processed.
The expansion gets processed when the attribute is processed. It can't be earlier, because the attribute doesn't exist. It can't be later, because then the *later* expansions wouldn't work. i.e. Foo = "%{User-Name}" Bar = "%{Foo}". What's "Bar"? It's not %{User-Name}.
Variables are definitely expanded before the SQL server receives queries, as the query templates use variables. I get the impression that the expansions are not processed anymore on the SQL results.
I don't see why. That part of the code hasn't changed for a long time. Alan DeKok.
Isidor Zeuner wrote:
The problem with the unlang manpage is that it doesn't make it very clear _when_ the expansions are processed.
The expansion gets processed when the attribute is processed. It can't be earlier, because the attribute doesn't exist. It can't be later, because then the *later* expansions wouldn't work.
Ok. I was just unsure if it this also holds when the attribute comes from a source external to the configuration files, like an SQL query.
i.e. Foo = "%{User-Name}" Bar = "%{Foo}".
What's "Bar"? It's not %{User-Name}.
Interpreting this as a configuration file snippet, I fully agree. I just need to find out how the processing of the SQL results map into that. In the "DATA TYPES" section of the manpage, the distinction between single-quoted, double-quoted and back-quoted strings is pretty clear. Now the expansion behaviour on the SQL results which I am used to from FreeRADIUS 1.1 is probably the same as the double-quoted string expansion behaviour. Yet I do not get SQL results to be expanded on FreeRADIUS 2.1, no matter if I store them unquoted or double-quoted.
Variables are definitely expanded before the SQL server receives queries, as the query templates use variables. I get the impression that the expansions are not processed anymore on the SQL results.
I don't see why. That part of the code hasn't changed for a long time.
Ok, thanks. I was just wondering because FreeRADIUS 1.1 _has_ already been existing for a long time. So I only need to look at the code which could interfere with the expansion behaviour somehow, and which might have changed meanwhile. Best regards, Isidor
participants (6)
-
Alan Buxey -
Alan DeKok -
Andrew Paternoster -
Isidor Zeuner -
John Dennis -
Tim Sylvester