FreeBSD port for 2.0.0 (and a FreeRADIUS patch submission)

[David Wood]

Hi all,

In message <47870106.8060801 at deployingradius.com>, Alan DeKok 
<aland at deployingradius.com> writes
>David Wood wrote:
>> I am about to start working on an update of that port to 2.0.0 - and it
>> will likely be renamed net/freeradius2 at the same time, as it's no
>> longer a development version. My part of this isn't likely to take too
>> long (hopefully <12 hours to submit the FreeBSD PR barring unexpected
>> problems as I start to work on it this evening), but getting it
>> committed to the FreeBSD ports tree will take longer.
>
>  Sounds good to me.

I was a little bit slower than I'd hoped, but I've now submitted FreeBSD 
PR ports/119582 to create the net/freeradius2 port (and get rid of the 
net/freeradius-devel port which was pretty much stillborn this time 
round).

The PR can be viewed at:
http://www.freebsd.org/cgi/query-pr.cgi?pr=119582


If you want a copy of the port now, make a copy of an up to date (that's 
important!) /usr/ports/net/freeradius outside /usr/ports, apply the 
patch in the PR to your copy, uninstall your current FreeRADIUS (follow 
the advice in the suggested entry for /usr/ports/UPDATING please), then 
'make config clean install' should give you a working FreeRADIUS 2.0.0.

Whilst this may not be exactly the form that the port is committed as, 
it is working fine on my system.



PATCH SUBMISSION - THREADING ISSUES


I'd be grateful if someone from the FreeRADIUS team could look over 
files/patch-pthread for inclusion in FreeRADIUS itself.

<http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/freeradius-devel/files/p
atch-pthread?rev=1.1> is a version of the patch that should apply 
cleanly against 2.0.0. If you want a 1.1.7 version, look at the same 
file in freeradius rather than freeradius-devel. It would be useful if 
both 1.1 and 2.0 could be patched in this way.

The patch solves two problems.

Firstly, for threading on FreeBSD you should just use -pthread (and not 
use -lpthread). There are different threading libraries available on 
FreeBSD; the OS does the correct thing if you just use -pthread.

Secondly, it deals with the case where python is built with threads (as 
is now the default for python on FreeBSD). As I don't use rlm_python, I 
can't test whether it works after this patch, but rlm_python won't even 
build on FreeBSD without it.




FREEBSD PORTING ISSUES FOR 2.0.0


When creating the 2.0.0 port, I made a couple of decisions that may be 
unpopular amongst embedded system users.


Firstly, NOPERL is now only available as a knob, and has been removed 
from the options. It was a horrid hack as I've explained in some new 
Makefile comments. If you really need it use make -DWITH_NOPERL - but 
building FreeRADIUS without perl available is not recommended.


I've also chosen to depend unconditionally on python for 2.0.0, and 
always build rlm_python. Of course, I could configure 
--without-rlm_python. The problem is that, at the moment, the FreeBSD 
ports system doesn't allow a conditional dependency on python without 
the nasty hack previously used when the experimental option was 
selected. The hack causes portlint to declare the port has a FATAL 
error, and I didn't think I'd get away with moving it elsewhere in the 
Makefile.

bsd.options.mk will solve this problem. When it's available, ports will 
be allowed to act on their options before including any of the 
bsd.port.mk stuff, which means all USE options can be conditional on 
options.

Unfortunately, bsd.options.mk can't be used yet as the necessary OS 
support only exists in the as yet unreleased FreeBSD versions 6.3 and 
7.0. At minimum I think it will need passing the End of Life date of the 
entire 5.x branch and the subsequent ending of ports support for 5.x, as 
well as passing the End of Life date for 6.2 before ports are allowed to 
use bsd.options.mk. This could all happen on or shortly after 31 May 
2008.

Porting is a bit of a nightmare at the moment, as you have to support 
5.x, 6.x, 7.x and the development 8.x tree. There are no plans for 
another 5.x release, and I'm one of those that was no great fan of 5.x.

Anyone who has a machine running any version of FreeBSD earlier than 6.x 
is encouraged to consider an upgrade to 7.0-RELEASE when that is 
available, hopefully within the next two months. If 7.0-RELEASE is too 
bleeding edge for you, try 6.3-RELEASE (also currently in RC) instead.



I could be persuaded to revisit the NOPERL stuff, though I can only 
really see two ways to do this properly. One is a conditional patch 
configure.in to disable all the perl tests, which is a maintenance 
nightmare for me. The other is to persuade the FreeRADIUS developers 
included a configure flag to disable perl globally.

The final option was to go back to the messy 1.x situation; my reading 
of the configure.in is that the absence of perl merely generates a 
warning and that disabling rlm_perl is enough.

There is the risk of strange brokenness in following the messy route if 
FreeRADIUS's dependency on perl ever changes; most desktop and server 
FreeBSD installations do have perl installed, and it will be available a 
lot of the time when a FreeRADIUS package is built, so configure will 
detect perl. If that package is then installed onto a system without 
perl, is it guaranteed to work properly?


As I've explained, my hands are rather tied over Python at the moment. 
If the inclusion of Python causes real problems for embedded users, 
maybe the answer for now is a slave freeradius2-without-python port. I 
don't want to go down that route unless I really have to, however.



Best wishes,




David
-- 
David Wood
david at wood2.org.uk