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
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
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
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
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
Nicolas Baradakis <nbk@sitadelle.com> wrote:
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.
Leave the stuff that gets mangled by "configure" in radiusd.conf, and put comments at the start saying "just an include file... look elsewhere". freeradiusd.conf can then just $INCLUDE radiusd.conf, and then we don't need a freeradiusd.conf.in. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
If you are changing the config file I would like to see an $INCLUDE for my.modules, my.authorization, my.accounting ... at the beginning of each section so I can make sure my configurations are what's causing problems with new versions. If I can install freeradius and touch an empty my.whatever.file and it works it's easy to know where to start looking. It's not a bug or enhancement it's just easier for users. Alan DeKok wrote:
Nicolas Baradakis <nbk@sitadelle.com> wrote:
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.
Leave the stuff that gets mangled by "configure" in radiusd.conf, and put comments at the start saying "just an include file... look elsewhere".
freeradiusd.conf can then just $INCLUDE radiusd.conf, and then we don't need a freeradiusd.conf.in.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Peter Nixon <listuser@peternixon.net> 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)
Yeah, I'll be typing '/etc/raddb' for the next 2 years, but the change makes sense.
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)
LSB? How does that affect my Solaris machines? :) The default prefix can easily be changed by any package manager, so I'm OK with leaving it as /usr/local/ which shouldn't affect any packages. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Mon 02 Oct 2006 17:57, Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> 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)
Yeah, I'll be typing '/etc/raddb' for the next 2 years, but the change makes sense.
Sure. A simple symlink will take care of that though :-)
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)
LSB? How does that affect my Solaris machines? :)
The default prefix can easily be changed by any package manager, so I'm OK with leaving it as /usr/local/ which shouldn't affect any packages.
Sorry. I should has said FHS not LSB (I get them confused sometimg :-) See: http://www.pathname.com/fhs/ http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard It's not critical, although isn't Solaris moving to /opt/whatever also for third party software also? (I thought I saw Oracle 10g installed in there on a Solaris machine recently..) In any case FHS is for Unix systems... Not just linux.. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Mon, 2006-10-02 at 13:01 +0300, Peter Nixon wrote:
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)
Why wreck a good thing! /usr/local is the BSD standard. I have no idea why LSB did not stay with the BSD standards.
On Wed, Oct 11, 2006 at 10:48:23AM -0600, Guy Fraser said:
On Mon, 2006-10-02 at 13:01 +0300, Peter Nixon wrote:
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)
Why wreck a good thing!
/usr/local is the BSD standard. I have no idea why LSB did not stay with the BSD standards.
It actually did, at least in this instance. The rule of thumb is distros go in /usr/{s,}bin, '3rd part software suites' (think loads of java and marketing speak - oracle, for instance) live under /opt/$package, and /usr/local is for local admin installed software. /usr/local seems to perfectly describe the normal target audience of freeradius, so I would think it's perfect where it is. If a '3rd party' wants to come along and provide a fully integrated, web2.1-ready, blah blah radius solution and charge you lots of money for the priviledge, that should definitely go under /opt. But I don't think that's the goal or the distribution method here. -- -------------------------------------------------------------------------- | Stephen Gran | A friend is a present you give | | steve@lobefin.net | yourself. -- Robert Louis Stevenson | | http://www.lobefin.net/~steve | | --------------------------------------------------------------------------
participants (6)
-
Alan DeKok -
Guy Fraser -
Kenneth Grady -
Nicolas Baradakis -
Peter Nixon -
Stephen Gran