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