FreeBSD FreeRADIUS port updated to 1.1.5, with various enhancements

[David Wood]

Hi all,

Whilst this post is mainly aimed at FreeBSD users, I'd be grateful if
the developers could cast a glance at the section between the lines of
***. That section contains patches that may be relevant to all
FreeRADIUS users and be worth committing to the main FreeRADIUS CVS,
also it contains a couple of comments relating to configure.



A new version of the FreeBSD FreeRADIUS port has just been committed to
the FreeBSD ports tree. Not only is the port now based on FreeRADIUS
1.1.5, there's been various other changes.

This has taken rather longer than I'd hoped (pneumonia got in the way -
I still don't feel too great), but I hope I've caught up on the backlog
of changes people have requested as well as updating the port to 1.1.5.



My notes didn't appear in the commit message, and are only in the PR
submitting the update. I thought the other changes were worth mentioning
here for any discussion and comment.


I've gone on a further round of patch removal with this update. Since
Alan and the other developers moved to the 'new' build system in 1.1.3,
things are much cleaner than was historically the case. Rather than
maintaining historic patches, I've chosen to remove them where possible.
This seems much better from a maintenance point of view - I would rather
have the fewest possible patches, even if I risk breaking things when
initially removing a patch.


I'd removed the only historic patch that changed the functionality of
the server in one of the 1.1.4 releases - from then on, the server you
get with the port behaves exactly the same as the server you get if you
build FreeRADIUS yourself from source. That patch was pointed out to me
as redundant and I had to agree. FreeRADIUS has had with_ntdomain_hack
for some time, which allowed for the same end result.

This change didn't lead to a single complaint, though it missed the
deadline for FreeBSD 6.2-RELEASE (which actually shipped with 1.1.3), so
it may be that quite a few users haven't yet caught up with the change.


The patches I've removed this time were all build related. I hope I
haven't broken the server on non-i386 platforms - if I have, I'm waiting
for the PRs, emails of complaint or tinderbox complaining at me!
Unfortunately I don't have access to a FreeBSD amd64 box, which is the
main non-i386 platform. All I can say is that the server works fine on
my FreeBSD 6.2-RELEASE-p2 i386 box, and has done so for a couple of
weeks.

I was intending to post a candidate port here for more testing (and/or
open up my local Subversion repository for public access), but I felt
obliged to submit my own update when someone submitted a (slightly
flawed) update to 1.1.5 that I refused to approve. If the submitter is
reading, you added dictionary.asn to pkg-plist correctly, but failed to
add it to the DICTS= line in the Makefile. I may look at changing the
Makefile to be more automatic with regard to dictionaries in the future.


One group of patches that remain are patches that I believe from the CVS
comments are only needed for FreeBSD 4.x. At the moment, I believe
files/patch-src-modules-rlm_attr_rewrite-rlm_attr_rewrite.c is only
needed for 4.x. The same is true of some of the lines in the port's
Makefile.

I'm torn as to what to do with these. I don't like gratuitous breakage,
but the ports framework no longer supports FreeBSD 4.x, the FreeBSD
project regards 4.x as End of Life (whilst it still has its fans,
FreeBSD 4.x is quite outdated in various ways), I can't test the server
on FreeBSD 4.x and I've had no feedback since 1.1.3 concerning FreeBSD
4.x support. Even if 1.1.4 worked on FreeBSD 4.x, I might have broken
FreeBSD 4.x support with the changes I've made in 1.1.5. If that's the
case, I'm pretty sure I know which change has broken things, but I'll
probably forget pretty soon unless someone complains.

I'm now developing the port with the aid of my local Subversion server.
This makes tracking my changes rather easier, but even with good log
messages, there's limitations on what I can remember after a while.


Unless someone contacts me to request otherwise, I'm likely to rip out
FreeBSD 4.x support sooner rather than later. It will definitely be
removed in any FreeRADIUS 2.x port. My feeling is that I'll probably rip
out the 4.x stuff either in a few weeks' time or with the release of a
port based on a future FreeRADIUS 1.1.6 release.



************************************************************************

The second group of patches that remain I'm going to post below -
because I think they might be candidates for committing to FreeRADIUS
itself. It was clearly felt by previous contributors to the port that
the Makefiles don't always contain $(CFLAGS) when they would be expected
to.

It might be that these patches are also unnecessary with the build
system used from 1.1.3 onwards - if so, will someone explain why and
I'll remove these patches too. I believe they are still needed judging
by the output of make, but I'm willing to be corrected (in Alan's gentle
style if needs be!).

The port uses the FreeBSD ports libtool, not libtool that ships with
FreeRADIUS (not that this will necessarily make a difference, but it
seemed worth mentioning).

--- src/modules/rules.mak.orig  Mon Mar 27 15:43:04 2006
+++ src/modules/rules.mak       Mon Mar 27 15:44:11 2006
@@ -112,7 +112,7 @@

 $(TARGET).la: $(LT_OBJS)
        $(LIBTOOL) --mode=link $(CC) -release $(RADIUSD_VERSION) \
-       -module $(LINK_MODE) $(LDFLAGS) $(RLM_LDFLAGS) -o $@     \
+       -module $(LINK_MODE) $(CFLAGS) $(RLM_CFLAGS) $(LDFLAGS) $(RLM_LDFLAGS) -o $@ \
        -rpath $(libdir) $^ $(top_builddir)/src/lib/libradius.la \
        $(RLM_LIBS) $(LIBS)

--- src/modules/rlm_sql/drivers/rules.mak.orig  Mon Mar 27 15:39:02 2006
+++ src/modules/rlm_sql/drivers/rules.mak       Mon Mar 27 15:39:29 2006
@@ -100,8 +100,8 @@

 $(TARGET).la: $(LT_OBJS)
        $(LIBTOOL) --mode=link $(CC) -release $(RADIUSD_VERSION) \
-       -module $(LINK_MODE) $(LDFLAGS) $(RLM_SQL_LDFLAGS) -o $@ \
-       -rpath $(libdir) $^ $(RLM_SQL_LIBS)
+       -module $(LINK_MODE) $(CFLAGS) $(RLM_SQL_LDFLAGS) -o $@ \
+       -rpath $(libdir) $^ $(RLM_SQL_LIBS) $(LDFLAGS)

 #######################################################################
 #

--- src/main/Makefile.in.orig   Wed Feb 14 15:44:23 2007
+++ src/main/Makefile.in        Mon Mar 12 13:20:32 2007
@@ -61,9 +61,9 @@

 radiusd: $(SERVER_OBJS) $(MODULE_OBJS) ../lib/libradius.la
        $(LIBTOOL) --mode=link $(CC) -export-dynamic -dlopen self \
-               $(LDFLAGS) -pie $(LINK_MODE) -o $@ $(SERVER_OBJS)      \
+               $(CFLAGS) $(LDFLAGS) -pie $(LINK_MODE) -o $@ $(SERVER_OBJS)      \
                $(MODULE_LIBS) $(LIBS) $(SNMP_LIBS) $(PTHREADLIB) \
                $(LIBLTDL) $(OPENSSL_LIBS)

 radiusd.lo: radiusd.c ../include/request_list.h ../include/modules.h ../include/modcall.h ../include/modpriv.h
        $(LIBTOOL) --mode=compile $(CC) $(CFLAGS) -c radiusd.c


The patches might well have lost their tabs when posted above - they can
be found in the FreeBSD ports tree as /usr/ports/net/freeradius/files/,
then

patch-src::modules::rules.mak
patch-src::modules::rlm_sql::rules.mak
and
patch-src-main-Makefile.in

CVSweb is at
http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/freeradius/files


There's one patch I wrote, which I think is a bug in a Makefile for
1.1.4 and 1.1.5 (hence the file name of patch-raddb-Makefile-1.1.4_bug):

--- raddb/Makefile.orig Mon Apr 10 19:53:20 2006
+++ raddb/Makefile      Sun Jan 14 23:10:15 2007
@@ -7,7 +7,7 @@
          experimental.conf hints huntgroups ldap.attrmap \
          mssql.conf naslist naspasswd oraclesql.conf postgresql.conf \
          preproxy_users proxy.conf radiusd.conf realms snmp.conf \
-         sql.conf sqlippool.conf users otp.conf otppasswd.sample
+         sql.conf sqlippool.conf users otp.conf

 all:

otppasswd.sample seems to have disappeared from 1.1.4 onwards - is this
a bug in that Makefile as I believe? If so, can that be fixed in CVS?


There's two other things I'm currently modifying the source to achieve,
on which I'd appreciate comments.

patch-doc::Makefile surrounds the contents of the install target in
doc/Makefile with #ifndef NOPORTDOCS ... #endif. FreeBSD ports have to
respect this flag. Is a neater way to pass --with-docdir=/dev/null to
configure if NOPORTDOCS is defined (which I haven't tried) and abandon
the patch. Has anyone any other suggestions?


I've refined handling of the sample configuration further in 1.1.5. Up
to and including the initial release of 1.1.4 it was very unfriendly -
the sample configuration was installed with the files suffixed with
.sample. I changed this to be a bit more user friendly in a later 1.1.4
release, but there were still .sample files mixed with the 'live'
configuration.

In the 1.1.5 port, the sample configuration is now installed in
${EXAMPLESDIR}/raddb (default
/usr/local/share/examples/freeradius/raddb). These files are not
suffixed with .sample as they used to be. The 'live' FreeRADIUS
configuration stays in the same location - ${PREFIX}/etc/raddb (default
/usr/local/etc/raddb).

I had suggested mention of this change was made in /usr/ports/UPDATING,
but it didn't happen.


I feel this is much neater than the old setup (especially for those of
us that have their configuration in some sort of revision control
system). You no longer have 'sample' files mixed with live ones in the
same directory and diffing your configuration against the sample one is
much more straightforward (no need for find, sed and for loops - or
equivalent).

The port uses some intelligence - when you install it, if a particular
file doesn't exist in the 'live' configuration folder, it copies it
across from the sample configuration. When you uninstall the port, if a
file is identical in the 'live' configuration to the equivalent sample
file, the live file is deleted - otherwise it's left alone. This is
standard behaviour for FreeBSD ports.

Note that this copying / deleting behaviour now extends to raddb/certs
and all its contents - which it didn't previously. You can, if you wish,
put your own certificates in raddb/certs and the port will now leave
them alone - though my preferred solution is to use a separate folder
(raddb/mycerts on my installation).

I probably should have added some further code to chmod the files in the
'live' configuration appropriately on installation - I'll consider that
for a future release of the port.


To install the sample raddb files in the correct location, I'm running
sed across all Makefile and Makefile.in files, replacing $(R)$(raddbdir)
with the appropriate location. I'd rather do this via configure, but if
I use --with-raddbdir, that changes the install location of the files
*and* the default location the server looks for those files. The latter
change isn't wanted.

I'd somehow missed the -d flag to radiusd - even though I'd gone looking
for it and it's staring at me in man 8 radiusd. I could change the port
to use --with-raddbdir pointing at to the sample location, then have
radiusd.sh.in using -d defaulting to the 'live' location (but being
changeable via an option in /etc/rc.conf). At that point, I can ditch
the sed stuff.

The fewer changes to the source, the happier I am. However, it would
still be nice to have the default location correct in radiusd, otherwise
people using radiusd -X won't realise that that starts FreeRADIUS with
the sample configuration, not the live one (this seems a really bad
idea!). I could look at supporting a debug option to the rc.d script -
but would people know to use it?

Is it possible to have a configuration option that sets the default
configuration directory for radiusd separately to the value of
--with-raddbdir (but if not issued, it defaults to raddbdir). That would
be the best solution, rather than patching the source. I'll have a go at
this patch if nobody else is interested - so long as the developers are
happy to merge that patch into HEAD when it's done (I'd work against
1.1.5).

************************************************************************


The other changes relate purely to FreeBSD.


Firstly, as requested here by Mike Jakubik, I'm now automagically
configuring the REQUIRES line of the rc.d script for FreeRADIUS to add
dependencies on OpenLDAP, MySQL and PostgreSQL if the appropriate
options are enabled when the port is built.

Mike - I hope it works - I had to remove the old BEFORE: DAEMON
stipulation to avoid circular dependencies in rcorder as we discussed
here on freeradius-users.

I'm really not sure why BEFORE: DAEMON was the default. Other similar
ports don't have it, so I took the decision to remove it. Removing it
might break some people's setups (depending on how they're using
FreeRADIUS), but I'll wait for the complaints and, if necessary, support
the 'old' situation via an option.

I hope that I've helped more people than I've hindered. The 'recovery'
code that's been added to CVS for offline SQL servers will help when it
appears in 1.1.6, but I still would rather have the correct dependencies
for rcorder.


On that note, Alexander Klepikov - I did consider your patch, but
decided that as Alan finished up committing a rather more extensive
change to the behaviour of rlm_sql to FreeRADIUS CVS, which I didn't
really want to backport to 1.1.5. I'm afraid it's going to be a case of
waiting until 1.1.6 is released.

One possible future project is to add optional support to the port to
build from a CVS checkout of branch_1_1 or a CVS snapshot. Is anyone
interested? If I'm going to consider this, I need to minimise the number
of patches first for such a feature to have the best chance of success.


Following a request from a developer working on one of the firewall /
router products that's FreeBSD based, I've added a freeradius-mysql
slave port. This is exactly the same as the main freeradius port, except
that MySQL support is always configured on (and isn't, therefore,
available as an OPTION).

I suggest people keep using net/freeradius, turning on the MySQL option
if they need it. The slave port is simply to ensure that there will be a
freeradius-mysql package on the FreeBSD FTP servers which contains MySQL
support for rlm_sql as well as the rest of FreeRADIUS. (Unlike on some
Linux distributions, the packages that result from this sort of slave
port are complete - they don't just contain the 'extra' files to add to
the same version of the server).


I've added support for the Firebird module - but judging by the comments
in the FreeRADIUS CVS, I'm not sure whether this will work until 1.1.6
is released. It appears to compile and install - but I can't test it.

I've tidied up the SQL sections of the port's Makefile - this was really
just to add robustness, but it seemed worth doing whilst I was adding
Firebird support.

Finally, there's two minor changes I didn't document anywhere else. I
found and fixed one SQL related glitch in pkg-plist - I wonder if anyone
noticed (I'm not sure how many versions that problem was there for, but
it predated 1.1.5). I've also moved to using the .tar.bz2 tarball -
downloading smaller files from the FTP servers seemed to make sense. If
this is less 'official' than the .tar.gz, I'll change back.


Apart from automatic chmodding of files in raddb on installing the port
(by this I mean running a chmod g-w,o-rwx on the files in raddb), which
I will consider adding, as well as trying the two changes I comment on
above that avoid patching the source, is there anything else I've missed
or that people want to suggest for the FreeBSD port?

Is there any interest in access to my local Subversion repository and/or
ViewVC for the port? If someone makes a case, I'd propose that such
access would be read only. However, if someone wants to make a case for
write access, especially if that person is a FreeRADIUS developer, I am
prepared to listen.

Write access would require a client certificate from CAcert. There's no
need to have your name assured with CAcert, as the Subversion setup uses
the email address that is in all CAcert client certificates as the user
name - but if you have your real name in the certificate, it makes my
logging tidier. I may also add support for Thawte Freemail client
certificates (especially as I regard Thawte's system as that bit more
robust than CAcert).


Best wishes,




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