Conversion to Version 2
I have been using FreeRadius 1.x for a number of years. It has worked just fine. All I am using it for is to authenticate and authorize dial-in users (its about as simple as you can get). The only unusual item is I have a couple of fairly complex modules for authorization and accounting. The question is should I bother to upgrade to 2.x. I don't have a need for any of the new features it provides. I don't even use most of the features in 1.x. My largest concern is the modules. I don't recall seeing anything here about what changes would be required for them other than I believe they have to be compiled with the server. Currently the modules are compiled separately and placed in /usr/local/lib and everything just works.
Hi,
I have been using FreeRadius 1.x for a number of years. It has worked just fine. All I am using it for is to authenticate and authorize dial-in users (its about as simple as you can get). The only unusual item is I have a couple of fairly complex modules for authorization and accounting. The question is should I bother to upgrade to 2.x. I don't have a need for any of the new features it provides. I don't even use most of the features in 1.x. My largest concern is the modules. I don't recall seeing anything here about what changes would be required for them other than I believe they have to be compiled with the server. Currently the modules are compiled separately and placed in /usr/local/lib and everything just works.
in your case, reasons would be, stability, speed, bug fixes, new server statistics access (SNMP and radmin tool), easy debugging of single users or NAS etc. the new version provides all of this for you - and more for others due to its extensibility. alan
On Oct 5, 2008, at 13:27, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
I have been using FreeRadius 1.x for a number of years. It has worked just fine. All I am using it for is to authenticate and authorize dial-in users (its about as simple as you can get). The only unusual item is I have a couple of fairly complex modules for authorization and accounting. The question is should I bother to upgrade to 2.x. I don't have a need for any of the new features it provides. I don't even use most of the features in 1.x. My largest concern is the modules. I don't recall seeing anything here about what changes would be required for them other than I believe they have to be compiled with the server. Currently the modules are compiled separately and placed in /usr/local/lib and everything just works.
in your case, reasons would be, stability,
I have never had a stability issue with FreeRadius - it just works without any attention from me.
speed,
Perhaps, but with about 10-20 authentication requests per hour thats not much of an issue.
bug fixes,
Don't seem to have seen any bugs with the portions I use.
new server statistics access (SNMP and radmin tool),
I have all the stats I need (not much but with just dial-in there is no need for much).
easy debugging of single users or NAS etc.
Possibly, but never had a need for that - it just works.
the new version provides all of this for you - and more for others due to its extensibility.
No question about that. I read about all the new authentication features and its amazing how anyone can keep up with all that stuff. However, if converting my modules is going to be a big deal, I don't see any real advantage.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
No question about that. I read about all the new authentication features and its amazing how anyone can keep up with all that stuff. However, if converting my modules is going to be a big deal, I don't see any real advantage.
it 'it works for me, i cant see why I should upgrade' is your viewpoint, then fair enough. keep with 1.x - but dont expect support for it on this list for much longer ; *that* is the gotcha. alan
On Oct 6, 2008, at 01:07, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
No question about that. I read about all the new authentication features and its amazing how anyone can keep up with all that stuff. However, if converting my modules is going to be a big deal, I don't see any real advantage.
it 'it works for me, i cant see why I should upgrade' is your viewpoint, then fair enough. keep with 1.x - but dont expect support for it on this list for much longer ; *that* is the gotcha.
Thats not that big a deal as for the basic stuff, the code is quite straight forward. However, the bigger issue is for modules. The wiki page is still completely oriented towards version 1 as I have never tried version 2. What has to be changed with modules to use them with version 2? I suspect that the wiki page will quickly lose its value otherwise.
Doug Hardie wrote:
Thats not that big a deal as for the basic stuff, the code is quite straight forward. However, the bigger issue is for modules. The wiki page is still completely oriented towards version 1 as I have never tried version 2. What has to be changed with modules to use them with version 2?
A fair bit. But much of it should be simple renaming of functions. A lot of "librad_*" names have moved to "fr_*", etc. The main module structure has changed a little. But the basic functioning of the module is pretty much the same. There are still authorize, etc. functions which take the same arguments.
I suspect that the wiki page will quickly lose its value otherwise.
Feel free to update the Wiki. Alan DeKok.
On Oct 6, 2008, at 02:22, Alan DeKok wrote:
Doug Hardie wrote:
Thats not that big a deal as for the basic stuff, the code is quite straight forward. However, the bigger issue is for modules. The wiki page is still completely oriented towards version 1 as I have never tried version 2. What has to be changed with modules to use them with version 2?
A fair bit. But much of it should be simple renaming of functions. A lot of "librad_*" names have moved to "fr_*", etc. The main module structure has changed a little.
But the basic functioning of the module is pretty much the same. There are still authorize, etc. functions which take the same arguments.
I suspect that the wiki page will quickly lose its value otherwise.
Feel free to update the Wiki.
Is there still a way to compile the module away from the freeradius source structure like there was for version 1?
Doug Hardie wrote:
Is there still a way to compile the module away from the freeradius source structure like there was for version 1?
That was difficult to do in version 1. It should be a lot easier now, as all of the include files have been cleaned up and regularized. Alan DeKok.
On Feb 26, 2009, at 21:52, Alan DeKok wrote:
Doug Hardie wrote:
Is there still a way to compile the module away from the freeradius source structure like there was for version 1?
That was difficult to do in version 1. It should be a lot easier now, as all of the include files have been cleaned up and regularized.
Are there any worked examples. I have not figured out how to get it done yet.
I finally figured out how to compile the module. Its actually quite simple once you figure out the new structure. The problem I still have is how to incorporate that into the new conf file. There used to be authorize and accounting sections that listed the modules. I can't find where that has been placed in the new structure.
I finally figured out how to compile the module. Its actually quite simple once you figure out the new structure. The problem I still have is how to incorporate that into the new conf file. There used to be authorize and accounting sections that listed the modules. I can't find where that has been placed in the new structure. -
Read the comments near the end of the radiusd.conf file (where those sections used to be). Ivan Kalik Kalik Informatika ISP
On Feb 27, 2009, at 16:05, <tnt@kalik.net> wrote:
I finally figured out how to compile the module. Its actually quite simple once you figure out the new structure. The problem I still have is how to incorporate that into the new conf file. There used to be authorize and accounting sections that listed the modules. I can't find where that has been placed in the new structure. -
Read the comments near the end of the radiusd.conf file (where those sections used to be).
Thanks. Those are pretty obtuse comments. I finally figured out by trial and error you have to create those two sections as they are not in the file.
Doug Hardie wrote:
Thanks. Those are pretty obtuse comments. I finally figured out by trial and error you have to create those two sections as they are not in the file.
No. The contents that *used* to be in radiusd.conf are now in raddb/sites-available/default. They were removed from radiusd.conf because (a) they were getting too big, and (b) it enabled example files per virtual server. Alan DeKok.
On Feb 27, 2009, at 21:34, Alan DeKok wrote:
Doug Hardie wrote:
Thanks. Those are pretty obtuse comments. I finally figured out by trial and error you have to create those two sections as they are not in the file.
No.
From raddb/sites-available/README: The virtual servers do NOT have to be set up with the "sites-available" and "sites-enabled" directories. You can still have one "radiusd.conf" file, and put the server configuration there:
The contents that *used* to be in radiusd.conf are now in raddb/sites-available/default.
They were removed from radiusd.conf because (a) they were getting too big, and (b) it enabled example files per virtual server.
Actually a good idea. Its just not obvious. The previously mentioned README is very helpful. I think its in the wrong place. It should be in raddb where its easier to find. Perhaps there should also be an UPDATING file that points to it. The new structure needs a road map because things are quite difficult to find until you really understand the structure. I now have one module completely working and the other one most probably working. I don't have the complete environment on the test machine yet so it won't do everything yet. I hope to start updating the WIKI on Monday. My initial approach is to retain the existing module page but identify it as Version 1 and create a new one that is for Version 2. One significant change that took mw quite awhile to figure out was that the request arguments are addressed differently. You have to be careful in using the proper pointer for the data type. However, anything with an IPv4 address, e.g. Freamed-IP-Address, is handled quite differently. Version 1 would give you a string ("10.0.1.1") whereas Version 2 gives you the binary version as 4 bytes. I haven't checked all the other data types for changes like that. The other ones I use maintained the same format.
Thanks. Those are pretty obtuse comments. I finally figured out by trial and error you have to create those two sections as they are not in the file.
No.
From raddb/sites-available/README:
Which I wrote. I *do* understand how the server works. The *default* install does not require you to add "authorize" or "authenticate" sections to radiusd.conf. The *default* install includes a "default" virtual server, with those sections already defined. The *intent* as per the "man" page and other documentation, is for that default server to be used as the basis for your own policies. The only time you *have* to add "authorize" and "authenticate" sections to radiusd.conf is when you've edited the default install to remove all references to virtual servers.
They were removed from radiusd.conf because (a) they were getting too big, and (b) it enabled example files per virtual server.
Actually a good idea. Its just not obvious. The previously mentioned README is very helpful. I think its in the wrong place. It should be in raddb where its easier to find. Perhaps there should also be an UPDATING file that points to it. The new structure needs a road map because things are quite difficult to find until you really understand the structure.
Feel free to send a first draft of suggested documentation.
One significant change that took mw quite awhile to figure out was that the request arguments are addressed differently. You have to be careful in using the proper pointer for the data type. However, anything with an IPv4 address, e.g. Freamed-IP-Address, is handled quite differently. Version 1 would give you a string ("10.0.1.1") whereas Version 2 gives you the binary version as 4 bytes. I haven't checked all the other data types for changes like that. The other ones I use maintained the same format.
Yes. The internal data structures change. See libradius.h for complete definitions. Alan DeKok.
I finally got a chance to try to update the Wiki again. It worked fine today. Anyway, there are now instructions for creating modules for both Version 1 and Version 2.
However, the bigger issue is for modules. The wiki page is still completely oriented towards version 1 as I have never tried version 2. What has to be changed with modules to use them with version 2? I suspect that the wiki page will quickly lose its value otherwise.
Nothing needs to be changed in modules to make them work. Modules have just been copied from radiusd.conf and pasted into a different file. If you haven't made any changes to the module in 1.x you won't need to change anything in 2.x either. If you have (for instance configured ntlm_auth in mschap module) - you need to do te same in the new version. It's just not where it used to be (in radiusd.conf) but in a separate file in raddb/modules directory. Ivan Kalik Kalik Informatika ISP
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Doug Hardie -
tnt＠kalik.net