headers
John Dennis | 2 Aug 2011 15:48
Picon
Favicon

Re: segmentation fault freeradius 2.1.7 using rlm_sql

>> Upgraded freeradius to 2.1.11 (built from source)

> Don't use 2.1.11 it segfaults, checkout the head of the 2.1.X branch in git

> Notice how I DIDN'T suggest upgrading to 2.1.11, but to v2.1.x of git
> branch? There's a reason for that, and you just found out the hard
> way.

"Houston, we have a problem" ;-)

This is not the first time a FreeRADIUS release was not ready for 
production when it was released. Those of us who package upstream 
projects for distribution worry a lot about stability and robustness. 
I've said this before so forgive me, but I'm going to reiterate it 
again. Please don't get mad at the messenger, I have only the best 
intentions with these observations.

FreeRADIUS has some problems which other projects have avoided.

* FreeRADIUS has no notion of a "stable release". Many projects maintain 
both a stable production version and a current version (which is not the 
same as the "tip", rather it's tagged in source code control, tested and 
released just like any other release, it's just got a few more features 
than the rock solid stable release). The rock solid stable release has 
been field proven, should have the absolute confidence of system 
administrators and be viable for multiple years (in other words you can 
install it and be confident once it's put in production you're good to 
go for several years. Occasionally a stable release needs a bug or 
security fix. When that occurs the stable release is surgically modified 
to fix exactly that one issue, it's minor version number is bumped.
(Continue reading)

Permalink | Reply | 6 comments |
headers
David Bird | 2 Aug 2011 21:09
Favicon

Re: segmentation fault freeradius 2.1.7 using rlm_sql

Houston, who's having the problem? :)

Perhaps in a perfect world, everyone writing open-source is fully
employed by RedHat, Google, IBM, or some other company who directly or
indirectly benefits from the software. Where you have (paid) teams of
people to patch, maintain, and test features and releases. Of course,
we'd all would like to see and benefit from more rigorous testing and
packaging in open-source. But, isn't that part of your (paid) job? :) 

I don't really see the argument being made why the FR team should do all
that you ask; it doesn't put their kids through school or put food on
their tables; and obviously doesn't keep people from using the
software... 

You also suggest "Organize a rigorous beta test program." Well, do you
test FR when asked to? Are you suggesting they _pay_ testers? Perhaps
releasing new versions is the only way they eventually get people to
test and report problems... 

I know you have the best intentions in mind, but I think it's wrong to
imply the FR team does not...

David

On Tue, 2011-08-02 at 09:48 -0400, John Dennis wrote:
> >> Upgraded freeradius to 2.1.11 (built from source)
> 
> > Don't use 2.1.11 it segfaults, checkout the head of the 2.1.X branch in git
> 
> > Notice how I DIDN'T suggest upgrading to 2.1.11, but to v2.1.x of git
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alan DeKok | 2 Aug 2011 23:33
Favicon
Gravatar

Re: segmentation fault freeradius 2.1.7 using rlm_sql

David Bird wrote:
> Perhaps
> releasing new versions is the only way they eventually get people to
> test and report problems... 

  Yes.

  Look at the release history on this mailing list.

"A new release will come soon, here's a link to a beta TGZ"

  <crickets>

"OK, the release is ready"

  OMG! It doesn't work!

"Arg... GTFO"

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Permalink | Reply | 0 comments |
headers
Stephen R. van den Berg | 12 Aug 2011 23:44
Picon
Gravatar

Re: segmentation fault freeradius 2.1.7 using rlm_sql

John Dennis wrote:
>"Houston, we have a problem" ;-)

The "we" part is presumptuous in this case.

>* FreeRADIUS has no notion of a "stable release". Many projects

That is matter of definition.
My definition of the "stable release" is that bleeding edge 3.x snapshot
that still appears to be stable about 6 months in the future.
And yes, that's right, it means that whatever is "stable" will not be known
until about 6 months after it has been "published".  This mechanism works
just fine for anyone running it in production servers or needing to wrap
it in a distribution package.

>I humbly would suggest the following:

>* Create and maintain a "stable" version.

That is already being done, just adjust your definition.

>* Organize a rigorous beta test program.

Well, sounds like a plan.  Does that mean you are volunteering to
organise it?
--

-- 
Stephen.

Confidence is that feeling you have before you understand the situation.
-
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan DeKok | 15 Aug 2011 15:43
Favicon
Gravatar

Re: LDAP timeouts during failure conditions

Phil Mayers wrote:
> https://github.com/philmayers/freeradius-server/commit/58e545bd183029da9cdb1e591cd38ca208f55f87
> 
> 
> ...this is *not* a connection pool, but an example of one way to solve
> the problem; spawn a child thread to create connections.

  See git "master".  There is now src/main/connection.c, which handles
pools of connections.  It *should* work for you.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Permalink | Reply | 0 comments |
headers
Oliver Schröder | 17 Aug 2011 10:38
Picon
Favicon

some patches for branch v2.1.x


While migrating the configuration of our commercial radius to freeradius 
I needed to customise (parts of) the freeradius sources to our needs. 
Perhaps those patches are useful for others, so I want to contribute 
them and ask if you are willing to accept them:

rlm_linelog:

The original module does not create parent directories when needed. The 
patch fixes this behavior, so you can define filenames for logging like:
	filename = ${logdir}/whatever/%Y/%m/detail.%d

This patch is trivial and has no effects to in-use installations.

rlm_ldap:

Our LDAP scheme provides 4 data fields, two for check-items and two for 
reply-items (RadiusReplyattrDSL/RadiusCheckattrDSL and 
RadiusReplyattr/RadiusCheckattr). Those fields contain attributes/value 
pairs in one row, eg:
RadiusReplyattrDSL: Framed-IP-Address = 1.2.3.4, Session-Timeout = 
86400, Uni-Egress-Policy-Name="pol6144",Uni-Ingress-Policy-Name="pol512"
Which pair is used depends on values found in the request, i.e. if the 
request was sent by a BRAS then RadiusReplyattrDSL/RadiusCheckattrDSL 
are used, if sent by a (ISDN-) NAS then RadiusReplyattr/RadiusCheckattr 
are used. So I needed a way to extract those one-liners to a list of 
attribute/value pairs.
To avoid rlm_perl I patched rlm_ldap, so you can configure the rows to 
use via configuration, especially in the hints file. While working on 
this module I also found it useful to be able to set the basedn via
(Continue reading)

Permalink | Reply | 5 comments |
headers
Arran Cudbard-Bell | 17 Aug 2011 12:01
Gravatar

Re: some patches for branch v2.1.x


On 17 Aug 2011, at 10:38, Oliver Schröder wrote:

> 
> While migrating the configuration of our commercial radius to freeradius I needed to customise (parts
of) the freeradius sources to our needs. Perhaps those patches are useful for others, so I want to
contribute them and ask if you are willing to accept them:
> 
> rlm_linelog:
> 
> The original module does not create parent directories when needed. The patch fixes this behavior, so you
can define filenames for logging like:
> 	filename = ${logdir}/whatever/%Y/%m/detail.%d
> 

There's already code to recursively create directories in /src/main please call this if you want to add the functionality.

> This patch is trivial and has no effects to in-use installations.
> 
> 
> rlm_ldap:
> 
> Our LDAP scheme provides 4 data fields, two for check-items and two for reply-items
(RadiusReplyattrDSL/RadiusCheckattrDSL and RadiusReplyattr/RadiusCheckattr). Those fields
contain attributes/value pairs in one row, eg:
> RadiusReplyattrDSL: Framed-IP-Address = 1.2.3.4, Session-Timeout = 86400, Uni-Egress-Policy-Name="pol6144",Uni-Ingress-Policy-Name="pol512"
> Which pair is used depends on values found in the request, i.e. if the request was sent by a BRAS then
RadiusReplyattrDSL/RadiusCheckattrDSL are used, if sent by a (ISDN-) NAS then
RadiusReplyattr/RadiusCheckattr are used. So I needed a way to extract those one-liners to a list of
attribute/value pairs.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Oliver Schröder | 17 Aug 2011 12:34
Picon
Favicon

Re: some patches for branch v2.1.x

Am 17.08.2011 12:01, schrieb Arran Cudbard-Bell:
>
> On 17 Aug 2011, at 10:38, Oliver Schröder wrote:
>> The original module does not create parent directories when needed. The patch fixes this behavior, so
you can define filenames for logging like:
>> 	filename = ${logdir}/whatever/%Y/%m/detail.%d
>>
>
> There's already code to recursively create directories in /src/main please call this if you want to add
the functionality.

My patch uses this code. See the attached .diff

>> DEFAULT NAS-IP-Address =~ "(1.2.3.4|4.3.2.1)"
>> 	LDap-basedn             := "ou=Service-11200,ou=people,dc=company,dc=com",
>> 	LDap-Multimap-reply     := "RadiusReplyattrDSL",
>> 	LDap-Multimap-check     := "RadiusCheckattrDSL"
>>
>> rlm_ldap will then look for values in these fields and attach them to the reply set.
>>
>
> No, the same can be achieved with unlang.

I have not found any documentation helping me to implement this via 
unlang. Can you nudge me in the right direction?

Regards,
Oliver
Attachment (rlm_linelog.diff): text/x-patch, 1227 bytes
(Continue reading)

Permalink | Reply | 3 comments |
headers
Arran Cudbard-Bell | 17 Aug 2011 13:32
Gravatar

Re: some patches for branch v2.1.x


On 17 Aug 2011, at 12:34, Oliver Schröder wrote:

> Am 17.08.2011 12:01, schrieb Arran Cudbard-Bell:
>> 
>> On 17 Aug 2011, at 10:38, Oliver Schröder wrote:
>>> The original module does not create parent directories when needed. The patch fixes this behavior, so
you can define filenames for logging like:
>>> 	filename = ${logdir}/whatever/%Y/%m/detail.%d
>>> 
>> 
>> There's already code to recursively create directories in /src/main please call this if you want to add
the functionality.
> 
> My patch uses this code. See the attached .diff

Could you please submit it via GitHub. http://wiki.freeradius.org/GitHub

That way you get the credit/blame :)

> 
> 
>>> DEFAULT NAS-IP-Address =~ "(1.2.3.4|4.3.2.1)"
>>> 	LDap-basedn             := "ou=Service-11200,ou=people,dc=company,dc=com",
>>> 	LDap-Multimap-reply     := "RadiusReplyattrDSL",
>>> 	LDap-Multimap-check     := "RadiusCheckattrDSL"
>>> 
>>> rlm_ldap will then look for values in these fields and attach them to the reply set.
>>> 
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan DeKok | 18 Aug 2011 03:26
Favicon
Gravatar

Re: some patches for branch v2.1.x

Oliver Schröder wrote:
> My patch uses this code. See the attached .diff

  OK... what is "libgen"?  And why is its header file included in the patch?

  And the patch doesn't apply to the git head.  This is why github is best.

  Anyways, I've fixed the patch && applied it.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Permalink | Reply | 1 comment |

Gmane