I have a server that is running a relatively clean install of Ubuntu 9.10 Server. Due to the known licensing issue restrictions I cannot simply use the debian freeradius package. I would like to know if the following outline would install freeradius with support for SSL on my server. Comments from those who actually run freeradius on Ubuntu 9.10 server would be appreciated. $cd ~ $apt-get source freeradius $cd ./freeradius-2.1.0+dfsg [change ./debian/rules as follows: change --without-rlm_eap_tls \ --without-rlm_eap_ttls \ --without-rlm_eap_peap \ to --with-rlm_eap_tls \ --with-rlm_eap_ttls \ --with-rlm_eap_peap \ change --without-openssl \ to --with-openssl \ ] [change ./debian/control add 'libssl-dev' to the end of the line that starts 'Build-Depends:' ] $fakeroot dpkg-buildpackage -b -uc $sudo dpkg -i ../freeradius_2.1.0-0_i386.deb These have been the instructions that I have garnered from the Internet at large, yet I doubt they are complete. Is there anything the freeradius community would like to add?
Huckle Berry wrote:
I have a server that is running a relatively clean install of Ubuntu 9.10 Server. Due to the known licensing issue restrictions I cannot simply use the debian freeradius package.
This was fixed in 2.1.8.
I would like to know if the following outline would install freeradius with support for SSL on my server. Comments from those who actually run freeradius on Ubuntu 9.10 server would be appreciated.
http://wiki.freeradius.org/Build Has instructions for building on debian && ubuntu. I've updated the Wiki to reflect this.
These have been the instructions that I have garnered from the Internet at large, yet I doubt they are complete. Is there anything the freeradius community would like to add?
Please check out the wiki.... type "ubuntu", and the second or third page is "build", with text about building debian packages. Alan DeKok.
On Thu, Apr 29, 2010 at 07:55:25AM +0200, Alan DeKok wrote:
Huckle Berry wrote:
I have a server that is running a relatively clean install of Ubuntu 9.10 Server. Due to the known licensing issue restrictions I cannot simply use the debian freeradius package.
This was fixed in 2.1.8.
I would like to know if the following outline would install freeradius with support for SSL on my server. Comments from those who actually run freeradius on Ubuntu 9.10 server would be appreciated.
http://wiki.freeradius.org/Build
Has instructions for building on debian && ubuntu.
I've updated the Wiki to reflect this.
When someone searches e.g. http://www.google.com/search?q=freeradius+debian the first result is building from source. I think you really need to put a link to http://packages.debian.org/freeradius right at the top of that section. The text currently there says that building packages with dpkg-buildpackage is "best", but it's actually now second best to installing working packages from the official repositories. Also, http://wiki.freeradius.org/Binary_packages is obsolete, but has some content still, probably confusing to the users. It would be good for this page to have an explicit pointer to http://freeradius.org/download.html where there is a section Binary packages (maybe make a HTML anchor too). -- 2. That which causes joy or happiness.
On Thu, Apr 29, 2010 at 6:52 AM, Josip Rodin <joy@entuzijast.net> wrote:
On Thu, Apr 29, 2010 at 07:55:25AM +0200, Alan DeKok wrote:
Huckle Berry wrote:
I have a server that is running a relatively clean install of Ubuntu 9.10 Server. Due to the known licensing issue restrictions I cannot simply use the debian freeradius package.
This was fixed in 2.1.8.
As of this morning, the latest version of freeradius in the (karmic 9.10) repos is 2.1.0. Although 2.1.8 is availible as a lenny backport for debian, I get the feeling that your suggestion is to stick with distribution packages whenever possible. Supposing I wanted to use the debian package to install 2.1.8 onto my ubuntu system the following (taken from http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html) should do the trick, correct? $dpkg-source -x foo_version-revision.dsc $cd foo-version $dpkg-buildpackage -rfakeroot -b $dpkg -i ../foo_version-revision_arch.deb
I would like to know if the following outline would install freeradius with support for SSL on my server. Comments from those who actually run freeradius on Ubuntu 9.10 server would be appreciated.
http://wiki.freeradius.org/Build
Has instructions for building on debian && ubuntu.
I've updated the Wiki to reflect this.
The text currently there says that building packages with dpkg-buildpackage is "best", but it's actually now second best to installing working packages from the official repositories.
Version 2.1.8 is available for the lucid lynx (10.04) which just released (non-beta) this morning. I'm not a firm believer in 'version 1' software and generally avoid getting new distro-upgrades the day they come out. However since 10.04 is a long-term-support I may consider installing it. Do you think that re-installing the OS is worth it in this case, or will I be fine running the above and building it from source?
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Thu, Apr 29, 2010 at 02:07:50PM -0400, Huckle Berry wrote:
I have a server that is running a relatively clean install of Ubuntu 9.10 Server. Due to the known licensing issue restrictions I cannot simply use the debian freeradius package.
This was fixed in 2.1.8.
As of this morning, the latest version of freeradius in the (karmic 9.10) repos is 2.1.0. Although 2.1.8 is availible as a lenny backport for debian, I get the feeling that your suggestion is to stick with distribution packages whenever possible. Supposing I wanted to use the debian package to install 2.1.8 onto my ubuntu system [...]
You shouldn't have to recompile anything in order to use Debian's lenny packages on Ubuntu's karmic - the latter is just a bit newer base, but there should be no differences so critical that you couldn't share packages that are relatively standalone, such as FreeRADIUS packages. You probably can't share something major like glibc, or something huge like gnome, but FR should be relatively fine. Try adding a Debian lenny-backports repository to your sources.list, for example: deb http://www.backports.org/debian lenny-backports main Then update the package list (apt-get update) and then just try installing the main FreeRADIUS package from there, for example with: apt-get install -t lenny-backports freeradius If it errors out or tries to add more than a dozen packages, especially something that doesn't seem related to FR, abort and paste the output here for examination. -- 2. That which causes joy or happiness.
I added the lenny-backport repo and updated. I then ran $sudo apt-get install freeradius I cannot copy and paste the output because I'm sshing on my mobile but apt essentially reports that libltd13 (1.5.2-2+) is a dependency but it cannot be found. On 4/29/10, Josip Rodin <joy@entuzijast.net> wrote:
On Thu, Apr 29, 2010 at 02:07:50PM -0400, Huckle Berry wrote:
I have a server that is running a relatively clean install of Ubuntu 9.10 Server. Due to the known licensing issue restrictions I cannot simply use the debian freeradius package.
This was fixed in 2.1.8.
As of this morning, the latest version of freeradius in the (karmic 9.10) repos is 2.1.0. Although 2.1.8 is availible as a lenny backport for debian, I get the feeling that your suggestion is to stick with distribution packages whenever possible. Supposing I wanted to use the debian package to install 2.1.8 onto my ubuntu system [...]
You shouldn't have to recompile anything in order to use Debian's lenny packages on Ubuntu's karmic - the latter is just a bit newer base, but there should be no differences so critical that you couldn't share packages that are relatively standalone, such as FreeRADIUS packages. You probably can't share something major like glibc, or something huge like gnome, but FR should be relatively fine.
Try adding a Debian lenny-backports repository to your sources.list, for example:
deb http://www.backports.org/debian lenny-backports main
Then update the package list (apt-get update) and then just try installing the main FreeRADIUS package from there, for example with:
apt-get install -t lenny-backports freeradius
If it errors out or tries to add more than a dozen packages, especially something that doesn't seem related to FR, abort and paste the output here for examination.
-- 2. That which causes joy or happiness. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Thu, Apr 29, 2010 at 08:11:15PM +0000, Huckle Berry wrote:
I added the lenny-backport repo and updated. I then ran $sudo apt-get install freeradius I cannot copy and paste the output because I'm sshing on my mobile but apt essentially reports that libltd13 (1.5.2-2+) is a dependency but it cannot be found.
Ah, karmic moved on from LTDL 3. Then you can try moving to the freeradius package in Debian squeeze which depends on libltdl7. Try using a squeeze sources.list line, for example: deb http://ftp.us.debian.org/debian squeeze main But do remember to comment that out after installing FR! Leaving it in could easily make it pollute the Ubuntu system with random other packages later (because unlike lenny-backports, squeeze is marked as suite testing and will make APT behave differently). -- 2. That which causes joy or happiness.
Josip Rodin wrote:
Ah, karmic moved on from LTDL 3. Then you can try moving to the freeradius package in Debian squeeze which depends on libltdl7.
Arg. For 2.2.0, I'm looking to replace libtool, autoconf, and libltdl. I've had too many problems with them over the years, and I've pretty much had it with the level of complexity that they add. They have magic undocumented interactions, new versions are *silently* incompatible with old versions. I've never regretted avoiding automake. So getting rid of the other pieces is looking like a good idea, too. It turns out that a plain dlopen() pretty well on most modern systems. If you're not on a modern system... maybe libltdl will work: good luck! Once you don't need libltdl, libtool becomes less useful. The Apache project has a program "jlibtool" which works pretty darned well on modern systems once a few hacks are added. As a bonus, builds take 1/4 of the time! Then moving to a non-recursive "make" simplifies the build even more. And getting rid of autoconf becomes easier when the configure checks are integrated into the non-recursive "make" system. Alan DeKok.
On Fri, Apr 30, 2010 at 11:11:45AM +0200, Alan DeKok wrote:
Josip Rodin wrote:
Ah, karmic moved on from LTDL 3. Then you can try moving to the freeradius package in Debian squeeze which depends on libltdl7.
They have magic undocumented interactions, new versions are *silently* incompatible with old versions.
Well, at least you can't complain about that in this case - the new libltdl had its SONAME upgraded, which caused the package to change correspondingly. This is not a critical issue, it's just a matter of convenience. Another method to install the lenny-backports freeradius on karmic is just to fetch the old package from http://packages.debian.org/stable/libltdl3 and install it with dpkg. It's inconvenient only because you need to fetch it manually, which is something apt normally does. -- 2. That which causes joy or happiness.
I've got to agree libtool is evil, it causes more breakage than anything it purports to fix. Autoconf is a great idea, but a horrible implementation because of it's insane complexity and utterly unreadable machine generated code. It's wonderful when it works, but pure hell when it doesn't. I've found myself in autotool hell more often than I would care to remember. However, at the moment I don't know what a viable alternative to autoconf would be. I suppose if you believe you won't ever need per OS configuration it's not necessary, but are we at that point of compatibility? -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
I've got to agree libtool is evil, it causes more breakage than anything it purports to fix. Autoconf is a great idea, but a horrible implementation because of it's insane complexity and utterly unreadable machine generated code. It's wonderful when it works, but pure hell when it doesn't. I've found myself in autotool hell more often than I would care to remember.
Yup.
However, at the moment I don't know what a viable alternative to autoconf would be. I suppose if you believe you won't ever need per OS configuration it's not necessary, but are we at that point of compatibility?
No. Samba is switching to "waf", which is based on Python. It works for them, but I'm not sure it's OK for FreeRADIUS. I've been experimenting with some replacements based on GNU Make. They look simple for the common case. For the uncommon cases, we can fall back to autoconf. Alan DeKok.
On Fri, Apr 30, 2010 at 5:15 AM, John Dennis <jdennis@redhat.com> wrote:
I've got to agree libtool is evil, it causes more breakage than anything it purports to fix. Autoconf is a great idea, but a horrible implementation because of it's insane complexity and utterly unreadable machine generated code. It's wonderful when it works, but pure hell when it doesn't. I've found myself in autotool hell more often than I would care to remember.
However, at the moment I don't know what a viable alternative to autoconf would be. I suppose if you believe you won't ever need per OS configuration it's not necessary, but are we at that point of compatibility?
FWIW, I've been migrating my project (tcpreplay) from Auto* to Cmake. It's a huge win if you're targeting Win32 (which I know freeradius isn't), but I've been pretty happy with it under various flavors of UNIX as well. Syntax is sane, it's well maintained and good active community. Unfortunately, the U in UNIX doesn't stand for "unified". -- Aaron Turner http://synfin.net/ Twitter: @synfinatic http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin "carpe diem quam minimum credula postero"
Aaron Turner wrote:
FWIW, I've been migrating my project (tcpreplay) from Auto* to Cmake. It's a huge win if you're targeting Win32 (which I know freeradius isn't), but I've been pretty happy with it under various flavors of UNIX as well. Syntax is sane, it's well maintained and good active community.
Hmm.. it's also C++ (ugh), and about 300K LoC. But yes, it works, and lots of people use it. One of my requirements is that *normal* people can do builds with a standard Unix SH and Make. That means the build system should generate old-style Makefiles. I also think that the build system *itself* should never be installed. That way lies madness. I've had too many problems over the years with a project using a "wonderful" build system... that requires me to download it and 40 dependencies... then the *latest* version of the build system isn't compatible with the project, so I have to find an old version of the build system... autoconf, et. al. are horrible, but they satisfy my requirements, and they don't have the problems noted above (except for libtool and libltldl, wich should *die*) Alan DeKok.
On Mon, May 3, 2010 at 8:10 AM, Alan DeKok <aland@deployingradius.com> wrote:
Aaron Turner wrote:
FWIW, I've been migrating my project (tcpreplay) from Auto* to Cmake. It's a huge win if you're targeting Win32 (which I know freeradius isn't), but I've been pretty happy with it under various flavors of UNIX as well. Syntax is sane, it's well maintained and good active community.
Hmm.. it's also C++ (ugh), and about 300K LoC. But yes, it works, and lots of people use it.
I've never felt the need to hack on Cmake or Autotools so the size or language choice wasn't a factor.
One of my requirements is that *normal* people can do builds with a standard Unix SH and Make. That means the build system should generate old-style Makefiles. I also think that the build system *itself* should never be installed. That way lies madness.
It is annoying you need Cmake install to do a build, but I figure 95% of my users are installing pre-built packages and the other 5% are advanced enough to figure it out. 20 years ago when everyone was building everything from source rather then installing binary packages, it would of been a deal breaker for me too, but things have changed sufficiently that I'm willing to accept it.
I've had too many problems over the years with a project using a "wonderful" build system... that requires me to download it and 40 dependencies... then the *latest* version of the build system isn't compatible with the project, so I have to find an old version of the build system...
autoconf, et. al. are horrible, but they satisfy my requirements, and they don't have the problems noted above (except for libtool and libltldl, wich should *die*)
Honestly, if Auto* does what you need, then it's probably not worth moving to another system. I can't say I was "happy" with autoconf/automake but it worked and when I got bug reports from users I was able to fix them without too much effort. As I said, the reason I moved to Cmake was I wanted a unified build system for my Win32 port and Cmake allows me to generate standard Makefile's, and XCode/MSVC++ project files. If it wasn't for that, I'd still be using Auto* even though I find it impossible to master regardless of effort- I always felt like I'm just getting by and there's gotta be a better way of doing things, but I never can figure it out. -- Aaron Turner http://synfin.net/ Twitter: @synfinatic http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin "carpe diem quam minimum credula postero"
Aaron Turner wrote:
It is annoying you need Cmake install to do a build, but I figure 95% of my users are installing pre-built packages and the other 5% are advanced enough to figure it out. 20 years ago when everyone was building everything from source rather then installing binary packages, it would of been a deal breaker for me too, but things have changed sufficiently that I'm willing to accept it.
Good point.
Honestly, if Auto* does what you need, then it's probably not worth moving to another system. I can't say I was "happy" with autoconf/automake but it worked and when I got bug reports from users I was able to fix them without too much effort.
Pretty much. We're seeing more problems now with libtool && libltdl. So those are the higher priority for removal. Luckily, that looks easy to do. Alan DeKok.
I replaced the apt source, ran apt-get update and let it rip. It updated the following: freeradius-common freeradius-utils libdb4.5 libfreeradius2 libltdl-dev libltdl7 libncursesw5 libperl-dev libperl5.10 libsqlite3-0 libssl-dev libssl0.9.8 perl perl-base perl-modules python2.5 python2.5-minimal freeradius-ldap freeradius-postgresql freeradius-mysql freeradius-krb5 libtool-doc perl-doc libterm-readline-gnu-perl libterm-readline-perl-perl python2.5-doc python-profiler binfmt-support freeradius freeradius-common freeradius-utils libdb4.5 libfreeradius2 python2.5 python2.5-minimal libltdl-dev libltdl7 libncursesw5 libperl-dev libperl5.10 libsqlite3-0 libssl-dev libssl0.9.8 perl perl-base perl-modules installation worked like a charm, so for future reference the correct procedure is: 1) edit /etc/apt/sources.list to include "deb http://ftp.us.debian.org/debian squeeze main" 2) sudo apt-get install freeradius 3) sudo apt-get install (suggestions from prior command) 4) edit /etc/apt/sources.list to remove "deb http://ftp.us.debian.org/debiansqueeze main" ~Matthew Berry
On Friday 30 April 2010 01:21:47 pm Huckle Berry wrote:
installation worked like a charm, so for future reference the correct procedure is: 1) edit /etc/apt/sources.list to include "deb http://ftp.us.debian.org/debian squeeze main" 2) sudo apt-get install freeradius 3) sudo apt-get install (suggestions from prior command) 4) edit /etc/apt/sources.list to remove "deb http://ftp.us.debian.org/debiansqueeze main"
This goes against recommended package management procedures in Debian. Mixing two different distributions can have unpredictable consequences. Is there a reason for not using the Backports distribution? Installing from backports may not bring in as many new libraries, dependencies, and installs, but the system will work with the existing versions. You should also look into the documentation on "apt pinning" if you insist on mixing releases. I am running 2.1.8 from lenny backports and it works well for me.
On Fri, Apr 30, 2010 at 02:21:47PM -0400, Huckle Berry wrote:
I replaced the apt source, ran apt-get update and let it rip. It updated the following:
freeradius-common freeradius-utils libdb4.5 libfreeradius2 libltdl-dev libltdl7 libncursesw5 libperl-dev libperl5.10 libsqlite3-0 libssl-dev libssl0.9.8 perl perl-base perl-modules python2.5 python2.5-minimal freeradius-ldap freeradius-postgresql freeradius-mysql freeradius-krb5 libtool-doc perl-doc libterm-readline-gnu-perl libterm-readline-perl-perl python2.5-doc python-profiler binfmt-support freeradius freeradius-common freeradius-utils libdb4.5 libfreeradius2 python2.5 python2.5-minimal libltdl-dev libltdl7 libncursesw5 libperl-dev libperl5.10 libsqlite3-0 libssl-dev libssl0.9.8 perl perl-base perl-modules
installation worked like a charm,
Ah, but you got too much. Now you have Perl, Python, the SSL library and all those other things with a newer version than those in karmic. That is all right now, but it means that if e.g. a security update comes out for the versions in karmic, you won't get it automatically because the version of the package you have is higher than that of the update. I advised you to avoid this situation... but now that you've already done it, it would be a good idea to restore the squeeze sources.list line at least as a comment and occasionally uncomment it and apt-get install the above package list - which will pick up any upgrades - and the comment it back. A switch to newer Ubuntu (lucid) could get all those packages to an upgradable situation, too. -- 2. That which causes joy or happiness.
On Fri, Apr 30, 2010 at 3:33 PM, Josip Rodin <joy@entuzijast.net> wrote:
On Fri, Apr 30, 2010 at 02:21:47PM -0400, Huckle Berry wrote:
I replaced the apt source, ran apt-get update and let it rip. It updated the following:
freeradius-common freeradius-utils libdb4.5 libfreeradius2 libltdl-dev libltdl7 libncursesw5 libperl-dev libperl5.10 libsqlite3-0 libssl-dev libssl0.9.8 perl perl-base perl-modules python2.5 python2.5-minimal freeradius-ldap freeradius-postgresql freeradius-mysql freeradius-krb5 libtool-doc perl-doc libterm-readline-gnu-perl libterm-readline-perl-perl python2.5-doc python-profiler binfmt-support freeradius freeradius-common freeradius-utils libdb4.5 libfreeradius2 python2.5 python2.5-minimal libltdl-dev libltdl7 libncursesw5 libperl-dev libperl5.10 libsqlite3-0 libssl-dev libssl0.9.8 perl perl-base perl-modules
installation worked like a charm,
Ah, but you got too much. Now you have Perl, Python, the SSL library and all those other things with a newer version than those in karmic. That is all
I don't see how having newer versions of perl/python could be an issue. As far as SSL is concerned, see below, as this server will be wiped soon.
right now, but it means that if e.g. a security update comes out for the versions in karmic, you won't get it automatically because the version of the package you have is higher than that of the update. I advised you to avoid this situation... but now that you've already done it, it would be a good idea to restore the squeeze sources.list line at least as a comment and occasionally uncomment it and apt-get install the above package list - which will pick up any upgrades - and the comment it back. A switch to newer Ubuntu (lucid) could get all those packages to an upgradable situation, too.
I have a feeling that this server will eventually be wiped anyway, it's more of an experiment right now than anything. Initial tests using radtest showed positive results, however even after reinstalling with libmysqlclient-dev, freeradius still fails to start with the error /etc/freeradius/sites-enabled/default[159]: Failed to find module "sql". /etc/freeradius/sites-enabled/default[62]: Errors parsing authorize section. Which may or may not be related to the versions of the installed packages and the configuration script's ability to determine what is and is not installed. I'm assuming at this point that the difference between freeradius with sql and w/o sql is determined by whether certian header packages are installed on the system at the time freeradius is complied? ~Matthew Berry
-- 2. That which causes joy or happiness. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Fri, Apr 30, 2010 at 05:02:48PM -0400, Huckle Berry wrote:
Ah, but you got too much. Now you have Perl, Python, the SSL library and all those other things with a newer version than those in karmic.
I don't see how having newer versions of perl/python could be an issue. As far as SSL is concerned, see below, as this server will be wiped soon.
Practically any package could need security updates in the future. For reference, http://security-tracker.debian.org/tracker/source-package/perl http://security-tracker.debian.org/tracker/source-package/python2.5
I have a feeling that this server will eventually be wiped anyway, it's more of an experiment right now than anything.
OK, then you should be reasonably safe. Just remember not to do this in production. :)
Initial tests using radtest showed positive results, however even after reinstalling with libmysqlclient-dev, freeradius still fails to start with the error
/etc/freeradius/sites-enabled/default[159]: Failed to find module "sql". /etc/freeradius/sites-enabled/default[62]: Errors parsing authorize section.
Which may or may not be related to the versions of the installed packages and the configuration script's ability to determine what is and is not installed. I'm assuming at this point that the difference between freeradius with sql and w/o sql is determined by whether certian header packages are installed on the system at the time freeradius is complied?
No, assuming you installed a freeradius-*sql package you want, this is simply a configuration issue - you need to define a sql module, which is usually done by adding $INCLUDE sql.conf to the modules section of the configuration, which is done for example by adding an /etc/freeradius/modules/local-sql.conf file with something like that inside. -- 2. That which causes joy or happiness.
On Fri, Apr 30, 2010 at 5:52 PM, Josip Rodin <joy@entuzijast.net> wrote:
On Fri, Apr 30, 2010 at 05:02:48PM -0400, Huckle Berry wrote:
Ah, but you got too much. Now you have Perl, Python, the SSL library and all those other things with a newer version than those in karmic.
I don't see how having newer versions of perl/python could be an issue. As far as SSL is concerned, see below, as this server will be wiped soon.
Practically any package could need security updates in the future.
For reference, http://security-tracker.debian.org/tracker/source-package/perl http://security-tracker.debian.org/tracker/source-package/python2.5
I have a feeling that this server will eventually be wiped anyway, it's more of an experiment right now than anything.
OK, then you should be reasonably safe. Just remember not to do this in production. :)
Initial tests using radtest showed positive results, however even after reinstalling with libmysqlclient-dev, freeradius still fails to start with the error
/etc/freeradius/sites-enabled/default[159]: Failed to find module "sql". /etc/freeradius/sites-enabled/default[62]: Errors parsing authorize section.
Which may or may not be related to the versions of the installed packages and the configuration script's ability to determine what is and is not installed. I'm assuming at this point that the difference between freeradius with sql and w/o sql is determined by whether certian header packages are installed on the system at the time freeradius is complied?
No, assuming you installed a freeradius-*sql package you want, this is simply a configuration issue - you need to define a sql module, which is usually done by adding $INCLUDE sql.conf to the modules section of the configuration, which is done for example by adding an /etc/freeradius/modules/local-sql.conf file with something like that inside.
Looking back I did miss that step in the guide. Overall this process has been much more straight forward than my last attempt at freeradius. With the proper documentation i shouldn't have any problem reproducing this on the new server (less the debian bits)
-- 2. That which causes joy or happiness. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 2010/04/30 11:02 PM, Huckle Berry wrote:
I don't see how having newer versions of perl/python could be an issue. As far as SSL is concerned, see below, as this server will be wiped soon.
The problem is that newer versions could have bugs. Stable distributions are much better. The problem is now IMHO an 'invalid guide' to install a later version is out there. I realize that you might your server soon, but others (that may not wipe their server soon), may try this. The backports route is still better. -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782
OK so one last question before I go and install Lucid on the machine. I set up SQL authorization and it works fine when I radtest it from several clients.
SELECT * FROM radcheck WHERE UserName='04:1e:64:d4:3a:11'; +----+-------------------+-----------+----+----------+ | id | UserName | Attribute | op | Value | +----+-------------------+-----------+----+----------+ | 4 | 04:1e:64:d4:3a:11 | Password | == | asdfasdf |
I then start freeradius -X and it reports it's ready to process requests. $radtest 04:1e:64:d4:3a:11 asdfasdf 192.168.1.3 1812 testing123 Sending Access-Request of id 56 to 192.168.1.3 port 1812 User-Name = "04:1e:64:d4:3a:11" User-Password = "asdfasdf" NAS-IP-Address = 127.0.1.1 NAS-Port = 1812 rad_recv: Access-Accept packet from host 192.168.1.3 port 1812, id=56, length=20 Yet when I attempt to connect for real, freeradius never receives the Access-Request. This seems like a NAS issue to me, since FR never even gets the packet. Currently I have DD-WRT v24 (micro) installed on my WRT54Gv5 router. Under Wireless >> Radius I have the option of turning the 'MAC Radius Client' on. When on, I set it to the following values: MAC Format: aa:bb:cc:dd:ee:ff RADIUS Server Address: 192.168.1.3 RADIUS Server Port: 1812 Maximum Unauthenticated Users: 0 Password Format: (*) Shared Key ( ) MAC Address RADIUS Shared Secret: testing123 Override if RADIUS is unavailable: [ ] Not sure if anyone uses DD-WRT here. All the guides over at their site require the use of chillispot or some other AAA service. I've played around with the values but regardless of the configuration, FR never receives any packets.
participants (7)
-
Aaron Turner -
Alan DeKok -
Huckle Berry -
Johan Meiring -
John Dennis -
Jonathan Hutchins -
Josip Rodin