Hi users, I'm attempting to setup a new virtual FR server on centos6, to replace an aging FR 1.13-1.6.el5 server. I have got the new server setup per the docs at freeradius.org. I've run the simple test using radtest locally and I get an Access-Accept. Also, using NTradPing remotely I get an Access-Accept. So, I think I've got the basic freeradius and firewall setup correctly. Now the hard part... I have no documentation or knowledge base for the old FR setup. It is used to authenticate WiFi users against a proprietary system using a Sybase DB. From what I can tell, it's using a perl script to talk to the db. I say this because of two lines in the radiusd.conf. One is: Auth-Type Perl { perl } and the other is: perl { module = /etc/raddb/sjsu.pl } My question is: Is it as easy as adding the same two lines to my new FR 2.1.12 radiusd.conf and copying over the sjsu.pl to get it to use the perl script? Please advise, thanks for any help...
On 10/04/2012 02:46 PM, Andrew Precht wrote:
Hi users, I'm attempting to setup a new virtual FR server on centos6, to replace an aging FR 1.13-1.6.el5 server. I have got the new server setup per the docs at freeradius.org. I've run the simple test using radtest locally and I get an Access-Accept. Also, using NTradPing remotely I get an Access-Accept. So, I think I've got the basic freeradius and firewall setup correctly. Now the hard part... I have no documentation or knowledge base for the old FR setup. It is used to authenticate WiFi users against a proprietary system using a Sybase DB. From what I can tell, it's using a perl script to talk to the db. I say this because of two lines in the radiusd.conf. One is: Auth-Type Perl { perl } and the other is: perl { module = /etc/raddb/sjsu.pl }
My question is: Is it as easy as adding the same two lines to my new FR 2.1.12 radiusd.conf and copying over the sjsu.pl to get it to use the perl script?
Sorry, no it's not that easy :-( FreeRADIUS 1.x and 2.x are *not* configuration compatible. Your best bet is to start with the default out of the box 2.x config and make only incremental changes based on a thorough understanding of how the server works and what your requirements are. It's best to keep your config files under source code control. If something breaks you can go back to a working configuration, review history, etc. Once that's working do everyone a favor unlike your predecessor and document what you did and how it works (at the moment it sounds like you're going to have to unravel what your predecessor did, only then can you move forward). -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
participants (2)
-
Andrew Precht -
John Dennis