Automatic report from sources (radiusd) between 30.09.2006 - 01.10.2006 GMT

CVS log entries from 30.09.2006 (Sat) 08:00:01 - 01.10.2006 (Sun) 08:00:02 GMT
=====================================================
Summary by authors
=====================================================
Author: mgriego
	File: radiusd/src/main/exec.c; Revisions: 1.54

=====================================================
Log entries
=====================================================
Description:
Sleep for 1 second if the child hasn't returned yet before starting the
next iteration of the loop.
Modified files:
	File: radiusd/src/main/exec.c; Revision: 1.54;
	Date: 2006/09/30 22:21:56; Author: mgriego; Lines:  (+7 -2)
=====================================================
Summary of modified files
=====================================================
File: radiusd/src/main/exec.c
Revisions: 1.54
Authors: mgriego (+7 -2)
--

-- 
Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

Re: utilities for totaling and booting

D S wrote:
> What I am missing, Or Radius is missing, is the way to kick off users 
> that have download their fair share (like 1/2 their monthly salary)

You not missing anything. This a fairly well know problem within the 
Chillispot community - but most people there seem to just accept the 
limitation although there is no real reason that they should.

> I am assuming that I need some other scripts to add up the various 
> accounting statements that are showing up in the log and to add them to 
> the user account and somewhere another script to kick them off the NAS.

Yes - a module to do the accounting already exists and is called 
sqlcounter. The Chillispot supports some custom rad-reply attributes 
that allow you to specify how many Octets of data are allowed before the 
user is logged out.

I have been looking for a solution to the problem for a while now and I 
now finally know what needs to be done - it is just taking a little while.

What is missing is some virtual glue between sqlcounter and Chillispot. 
I already have the sqlcounter on my FreeRadius box doing all the 
accounting perfectly and correctly outputting the required download 
limit but due to the way sqlcounter is coded it outputs this value 
paired with the wrong radius attribute.

I am currently working on a patch to solve this. I will submit it when 
it is complete but it is not going as quickly as i had hoped.

If you would like to assist me with getting this patch finished and 

Query

<div>

<p dir="LTR"><span lang="en-us"></span><span lang="en-us">If I want to add in another attribute e.g. location coordinate as part of the authentication via PEAP, how may I do it?</span></p>

<p dir="LTR"><span lang="en-us"></span><span lang="en-us"></span></p>

<p dir="LTR"><span lang="en-us"></span><span lang="en-us"></span></p>

<p dir="LTR"><span lang="en-us"></span><span lang="en-us"></span><span lang="en-us"></span><a name=""><span lang="en-us"></span><span lang="en-us">With Regards,</span></a></p>

<p dir="LTR"><span lang="en-us">Chew Heng Hui Andy</span></p>

<p dir="LTR"><span lang="en-us"></span></p>

</div>

Radiusd-radrelayd config file naming

Hi Guys

The attached 2 line patch makes radiusd load the config file matching the name 
that it is called with making the -n option unnecessary in many cases. This 
makes things simpler and makes "startproc" and family much simpler to use 
with radiusd.

Example use:

symlink radiusd to radrelay and then run radrelay and it will autoload 
radrelay.conf

The -n command line option still overrides config file so everyone should be 
happy.

If no-one has any complaints I plan to apply this to cvs head.

Cheers

-- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc

Hi Guys

The attached 2 line patch makes radiusd load the config file matching the name 
that it is called with making the -n option unnecessary in many cases. This 
makes things simpler and makes "startproc" and family much simpler to use 
with radiusd.

Example use:

symlink radiusd to radrelay and then run radrelay and it will autoload 
radrelay.conf

The -n command line option still overrides config file so everyone should be 
happy.

If no-one has any complaints I plan to apply this to cvs head.

Cheers

--

-- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc

Development TODO

Hi Guys

I just copied the toto list from cvs head into:

http://wiki.freeradius.org/Development_Roadmap#URGENT

It seems that this list is a bit out of date. Can everyone have a look at this 
and help update it please?

Also should we add a section for the 1.1.x branch or have we decided the 2.0 
will definately be the next release. (ie. Should we continue to apply patches 
to sqlippool in 1.1.x or just in cvs head)

Cheers

-- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc

Hi Guys

I just copied the toto list from cvs head into:

http://wiki.freeradius.org/Development_Roadmap#URGENT

It seems that this list is a bit out of date. Can everyone have a look at this 
and help update it please?

Also should we add a section for the 1.1.x branch or have we decided the 2.0 
will definately be the next release. (ie. Should we continue to apply patches 
to sqlippool in 1.1.x or just in cvs head)

Cheers

--

-- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc

Re: Radiusd-radrelayd config file naming

Peter Nixon wrote:

> The attached 2 line patch makes radiusd load the config file matching the
> name that it is called with making the -n option unnecessary in many cases.
> This makes things simpler and makes "startproc" and family much simpler to
> use with radiusd.
> 
> Example use:
> 
> symlink radiusd to radrelay and then run radrelay and it will autoload 
> radrelay.conf
> 
> The -n command line option still overrides config file so everyone should be 
> happy.
> 
> If no-one has any complaints I plan to apply this to cvs head.

That's a problem when the binary isn't named "radiusd". In Debian for
example the binary is renamed "freeradius", so the FreeRADIUS package
doesn't conflict with "radiusd-cistron", "radiusd-livingston", etc.

With this patch either the "-n" option becomes mandatory, or you must
rename the config file. This is guaranteed to break every existing
Debian installation.

--

-- 
Nicolas Baradakis

Re: Radiusd-radrelayd config file naming

On Mon 02 Oct 2006 12:48, Nicolas Baradakis wrote:
> Peter Nixon wrote:
> > The attached 2 line patch makes radiusd load the config file matching the
> > name that it is called with making the -n option unnecessary in many
> > cases. This makes things simpler and makes "startproc" and family much
> > simpler to use with radiusd.
> >
> > Example use:
> >
> > symlink radiusd to radrelay and then run radrelay and it will autoload
> > radrelay.conf
> >
> > The -n command line option still overrides config file so everyone should
> > be happy.
> >
> > If no-one has any complaints I plan to apply this to cvs head.
>
> That's a problem when the binary isn't named "radiusd". In Debian for
> example the binary is renamed "freeradius", so the FreeRADIUS package
> doesn't conflict with "radiusd-cistron", "radiusd-livingston", etc.
>
> With this patch either the "-n" option becomes mandatory, or you must
> rename the config file. This is guaranteed to break every existing
> Debian installation.

OK. I suspected that debian did something like this.

My next suggestion for 2.0 was actually going to be that we 
rename "radiusd.conf" to "freeradius.conf" (or freeradiusd.conf) 
and "etc/raddb" to "etc/freeradius" as default. Does this suit you? (A simple 
rename of radiusd.conf on upgrade is not particularly difficult, given that 
many options on the config file have also changed)

Our default prefix should probably change from /usr/local to /opt/freeradius/ 
also in keeping with LSB. (Although I understand that this may be a slightly 
controversal change)

Cheers
-- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc

On Mon 02 Oct 2006 12:48, Nicolas Baradakis wrote:
> Peter Nixon wrote:
> > The attached 2 line patch makes radiusd load the config file matching the
> > name that it is called with making the -n option unnecessary in many
> > cases. This makes things simpler and makes "startproc" and family much
> > simpler to use with radiusd.
> >
> > Example use:
> >
> > symlink radiusd to radrelay and then run radrelay and it will autoload
> > radrelay.conf
> >
> > The -n command line option still overrides config file so everyone should
> > be happy.
> >
> > If no-one has any complaints I plan to apply this to cvs head.
>
> That's a problem when the binary isn't named "radiusd". In Debian for
> example the binary is renamed "freeradius", so the FreeRADIUS package
> doesn't conflict with "radiusd-cistron", "radiusd-livingston", etc.
>
> With this patch either the "-n" option becomes mandatory, or you must
> rename the config file. This is guaranteed to break every existing
> Debian installation.

OK. I suspected that debian did something like this.

My next suggestion for 2.0 was actually going to be that we 
rename "radiusd.conf" to "freeradius.conf" (or freeradiusd.conf) 
and "etc/raddb" to "etc/freeradius" as default. Does this suit you? (A simple 
rename of radiusd.conf on upgrade is not particularly difficult, given that 
many options on the config file have also changed)

Our default prefix should probably change from /usr/local to /opt/freeradius/ 
also in keeping with LSB. (Although I understand that this may be a slightly 
controversal change)

Cheers
--

-- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc

Re: Radiusd-radrelayd config file naming

Peter Nixon wrote:

> My next suggestion for 2.0 was actually going to be that we 
> rename "radiusd.conf" to "freeradius.conf" (or freeradiusd.conf) 
> and "etc/raddb" to "etc/freeradius" as default. Does this suit you?
> (A simple rename of radiusd.conf on upgrade is not particularly difficult,
> given that many options on the config file have also changed)

The Debian package already sets the raddbdir to "/etc/freeradius". Of
course it's OK for me to rename "radiusd.conf" to "freeradius.conf",
too. The only problem I see is it may rise many questions on the users
mailing list.

> Our default prefix should probably change from /usr/local to
> /opt/freeradius/ also in keeping with LSB. (Although I understand that
> this may be a slightly controversal change)

Speaking personally, I think it's a good thing to be standard, and I'd
like to see this change, too. I also understand that a lot of users
may be disturbed by such a change, so I don't really know what should
be done in this case.

--

-- 
Nicolas Baradakis

Re: Radiusd-radrelayd config file naming

On Mon 02 Oct 2006 15:37, Nicolas Baradakis wrote:
> Peter Nixon wrote:
> > My next suggestion for 2.0 was actually going to be that we
> > rename "radiusd.conf" to "freeradius.conf" (or freeradiusd.conf)
> > and "etc/raddb" to "etc/freeradius" as default. Does this suit you?
> > (A simple rename of radiusd.conf on upgrade is not particularly
> > difficult, given that many options on the config file have also changed)
>
> The Debian package already sets the raddbdir to "/etc/freeradius". Of
> course it's OK for me to rename "radiusd.conf" to "freeradius.conf",
> too. The only problem I see is it may rise many questions on the users
> mailing list.

Which may be answered by replying with a single url from the wiki 

> > Our default prefix should probably change from /usr/local to
> > /opt/freeradius/ also in keeping with LSB. (Although I understand that
> > this may be a slightly controversal change)
>
> Speaking personally, I think it's a good thing to be standard, and I'd
> like to see this change, too. I also understand that a lot of users
> may be disturbed by such a change, so I don't really know what should
> be done in this case.

Well, Alan has previously said that the 2.0 release should be as consistent as 
possible, and my feeling is now is the time to update this type of stuff 
otherwise it may never happen! (Most is a hangover from cistron, not a 
concious choice for FreeRADIUS)

Alan? What do you think?

-- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc

On Mon 02 Oct 2006 15:37, Nicolas Baradakis wrote:
> Peter Nixon wrote:
> > My next suggestion for 2.0 was actually going to be that we
> > rename "radiusd.conf" to "freeradius.conf" (or freeradiusd.conf)
> > and "etc/raddb" to "etc/freeradius" as default. Does this suit you?
> > (A simple rename of radiusd.conf on upgrade is not particularly
> > difficult, given that many options on the config file have also changed)
>
> The Debian package already sets the raddbdir to "/etc/freeradius". Of
> course it's OK for me to rename "radiusd.conf" to "freeradius.conf",
> too. The only problem I see is it may rise many questions on the users
> mailing list.

Which may be answered by replying with a single url from the wiki 

> > Our default prefix should probably change from /usr/local to
> > /opt/freeradius/ also in keeping with LSB. (Although I understand that
> > this may be a slightly controversal change)
>
> Speaking personally, I think it's a good thing to be standard, and I'd
> like to see this change, too. I also understand that a lot of users
> may be disturbed by such a change, so I don't really know what should
> be done in this case.

Well, Alan has previously said that the 2.0 release should be as consistent as 
possible, and my feeling is now is the time to update this type of stuff 
otherwise it may never happen! (Most is a hangover from cistron, not a 
concious choice for FreeRADIUS)

Alan? What do you think?

--

-- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc

Re: Development TODO

Peter Nixon <listuser <at> peternixon.net> wrote:
> Also should we add a section for the 1.1.x branch or have we decided
> the 2.0 will definately be the next release. (ie. Should we continue
> to apply patches to sqlippool in 1.1.x or just in cvs head)

  The next version should be 2.0.

  I may still apply patches to 1.1.x, but only for the purpose of
testing code before it's merged into 2.0.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog