Problems with running freeradius
David Wood
david at wood2.org.uk
Fri Jan 26 02:12:58 CET 2007
Hi Jacek and everyone,
In message <45B93F8D.5020203 at jpol.waw.pl>, Jacek Burszta
<jacek at jpol.waw.pl> writes
>Hi !
>> I've a problem with my new version FreeRADIUS 1.1.0_2 on FreeBSD 7.0 CURRENT
I got a fuller version of this report from Jacek directly and have sent
a longer reply by private mail. I see Phil's suggestion to follow
doc/bugs, and that is the eventual conclusion of this, but I don't
believe that's the first step.
In summary:
Running an obsolete version of FreeRADIUS on a development branch of the
underlying operating system is not the best option for stability. At the
very least build the latest version of FreeRADIUS using the latest
version of the port - but if it still doesn't work, my options as the
maintainer are limited, especially as I don't have access to a FreeBSD
amd64 box of any description.
The development FreeBSD -CURRENT branch has unstable ABI / API. It isn't
even guaranteed to compile let alone run, and if it runs it may
malfunction. Further, the environment is different in -CURRENT to the
-STABLE branches supported by the Ports Collection. Most notably,
6-STABLE has stuck with gcc 3.4, whereas 7-CURRENT is using gcc 4.1.
-CURRENT is also different to -STABLE in various other ways (such as
OpenSSL 0.9.8d in the base system).
FreeBSD -RELEASE is recommended for production machines, or -STABLE at a
push. (For those not used to FreeBSD, -STABLE means stable ABI / API -
it's still a development branch and it may not actually be stable).
In this case, FreeRADIUS has segfaulted as it attempts to use OpenLDAP
(comparing to a debug run on an older version of the server), which is
why I suspect an incompatible ABI / API snafu or similar. Updating
/usr/src from the CVS without building and installing that version as
your kernel and user mode should be OK on -STABLE, but can break things
on -CURRENT as you can finish up with headers that don't match the
system binaries.
Only when you've upgraded the ports tree and ensured that everything on
the system (kernel, user land and ports) are compiled from the same CVS
checkout or snapshot of the OS is it time to turn to doc/bugs, and even
then the problem may be down to something not being right in your
development operating system.
My recommended way ahead, which is somewhat more terse than my reply by
private mail:
FreeRADIUS 1.1.0 has a known security flaw, and 1.1.0_2 is nearly a year
old. The latest version of the port is 1.1.4_1, which should be
retrieved using portsnap(1), csup(1) or another suitable method. I'd
upgrade the whole ports tree, as if you've somehow got 1.1.0_2 on your
box, the rest of the ports tree could be 11 months out of date also, and
that's a lot of fixes and updates.
There is no point proceeding any further until you have the latest
version of the port installed and built.
As I said, FreeRADIUS segfaulted when attempting to use LDAP; I suspect
that something is wrong with the OpenLDAP shared library. Such are the
perils of running FreeBSD -CURRENT - the 'bleeding edge' branch where
the ABI and API can change without warning. -CURRENT is where the
operating system is developed, and isn't even guaranteed to compile, let
alone work properly.
The first stage is to back up everything (level 0 dumps of all
filesystems or similar), as any fixing may make things worse.
If building freeradius-1.1.4_1 doesn't solve the problem, rebuild
FreeRADIUS and all the ports it depends on (portupgrade -fR
net/freeradius or similar). You may have to rebuild all the ports on the
machine if you have problems with incompatible ABI.
Indeed, you may have to rebuild world - make buildworld, make
buildkernel, make installkernel, reboot into single user mode, make
installworld - read the full instructions in the FreeBSD Handbook (you
should use mergemaster at the appropriate points, for example) and make
doubly sure you have good backups first. You have been warned - even if
a checkout of -CURRENT compiles it could panic on boot. When you've done
that, you may need to rebuild all the ports - and I'm still not going to
guarantee it will work.
If that doesn't solve it, the debugging steps to take are in
/usr/local/share/doc/freeradius/bugs, which is the doc/bugs file
referred to Phil's reply. There's no easy way of issuing
--enable-developer via the port - maybe I should add that to the options
in the port. It would likely be a case of getting busy with gdb and
finding out exactly what is causing the segfault. There is, of course,
no point doing this on the obsolete 1.1.0 code.
The ports collection is only guaranteed to work on supported -STABLE
branches, which means 5-STABLE or 6-STABLE at the moment (see
<http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/a
rticle.html#AEN165> ). FreeBSD -CURRENT isn't recommended for a
production machine; indeed, -STABLE isn't really recommended for a
production machine either. At this time, 6.2-RELEASE (which ideally
means tracking RELENG_6_2 to get security fixes and errata) is arguably
the best version to use for production machines, assuming that it
supports all your hardware.
Really, you're on your own with -CURRENT to a large extent; technical
competence is expected, as is following the freebsd-current mailing list
and being able to help troubleshoot your own problems.
As I said in the private reply, I'm particularly limited in what I can
do in this case, as I don't have a FreeBSD amd64 box, nor do I run
-CURRENT. However, I hope this helps.
Best wishes,
David
--
David Wood
david at wood2.org.uk
More information about the Freeradius-Users
mailing list