Problems with running freeradius

[David Wood]

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