Dependencies of Freeradius 2.0.5

[David Wood]

Hi Leander,

In message <485EF043.70208 at gmx.net>, Leander S. 
<leander.schaefer at gmx.net> writes
>Thank you very much for your work David!
>But I rather want to compile it by myself, because:

>a) I don't want to update all my ports, because than I am "supposed" to 
>update my RELEASE version of FreeBSD to an STABLE version and reinstall 
>all packages and re-check my configuration files in etc ... bla bla ... 
>(it's a production server)

What I was suggesting is nothing like as drastic as that.


You do not need to update your operating system at all. You can leave 
your OS on any supported version for the ports tree - that's any -STABLE 
branch that isn't End of Life, or any -RELEASE that isn't End of Life. 
7.0-RELEASE is supported. The ports tree only drops support for a 
particular version once that version of FreeBSD reaches its End of Life 
date, which is when the FreeBSD Security Officer ceases security support 
for that release or branch of the operating system.


You only need to update those ports that have changed - not every port 
on the system. portupgrade or portmaster make the task of keeping your 
ports up to date easy. I recommend portmaster where possible, as it has 
no dependencies (it's a shell script, rather than the Ruby of 
portupgrade), also it's much more modern and better maintained. However, 
it lacks some of the features of portupgrade.

The only reason that I warned you that a substantial portion of your 
ports would need to be rebuilt (but not necessarily upgraded to a new 
version) is because the version of gettext in the ports tree has been 
upgraded. This means the version of the libintl shared library has been 
bumped - and the only way to ensure everything is using that new version 
is to rebuild everything that depends on gettext.

You should get into the habit of reading /usr/ports/UPDATING every time 
you upgrade your ports tree before you rebuild or upgrade anything; that 
is where you are alerted to anything you need to be aware of - like the 
change in gettext and what it means.

As a system administrator, you can choose your own trade off between how 
often you update your ports tree and upgrade your ports. You might get 
away with cherry picking one port and upgrading just that - but that 
gets increasingly less likely to work the longer it is since you rebuilt 
your ports tree. Eventually important build dependencies are too old and 
need to be rebuilt, or a new version of a port requires a feature or bug 
fix in a dependency that you haven't built, at which point you really 
need to bring all your ports up to date. If you haven't brought your 
ports up to date for some time, you may then be facing a huge number of 
updates. Arguably the more conservative option is to update your ports 
on a schedule, so that the process of change is more gradual.


There's a philosophical point here. The ultra conservative option is 
that adopted by the likes of RedHat Enterprise Linux. RHEL ships with 
particular versions of third party software that are essentially frozen 
for the lifetime of a particular version of the OS. RedHat takes it upon 
themselves to back port any necessary fixes.

This stops the system administrator being surprised by changes in third 
party software as they keep their system up to date. However, it means 
that the versions used get increasingly out of date with respect to 
releases from the third party vendors. The problem you're experiencing 
may have been fixed in a later version than is supported for your 
particular OS.

In other words, the ultra conservative option might actually be a 
liability - because you can finish up building software by yourself to 
get fixes that you need. Some of the versions supplied on old but still 
maintained versions of these operating systems are ancient - look at the 
number of threads on this mailing list that finish up with 'that version 
is old and buggy - upgrade'. It also means that when you do upgrade your 
OS, all your software goes through a significant version jump.

FreeBSD doesn't have the developer and maintainer time available to keep 
a versioned ports tree in the RedHat Enterprise Linux type model. There 
is one ports tree. You can try to cherry pick individual ports to 
upgrade, but if you come unstuck, you will probably receive no support 
beyond the advice to 'upgrade to the latest version of the ports tree 
and try again'.



To help the system administrator, ports are not allowed to touch 
configuration files that the user has changed when you upgrade them. The 
only problem comes if the upgraded port doesn't understand your 
customised configuration for an old version - but that's a problem with 
the ported software, not FreeBSD or the ports tree.

My personal strategy to keep proper version control of configurations, 
and to back-port changes in port configurations when I upgrade from one 
version to another is to use Subversion. I keep sample port 
configurations in vendor branches in Subversion, and svn merge any 
changes back to my live configurations. See the bit in the Subversion 
book (available free online) about Vendor Branches for more details.

There's no need to use a version control system. You can handle this any 
way you like, including ignoring any changes in the sample 
configurations of your ports until you hit problems - though I do not 
recommend this, not least as some of the bug fixes or new functionality 
may depend on changes in the sample configuration.

Alan de Kok has recommended keeping FreeRADIUS configurations in a 
version control system several times to my memory.


Clean copies of the sample configuration are installed elsewhere for 
your reference - if there's one or two files, they may be installed in 
/usr/local/etc with .sample or .example added to the file name. As 
FreeRADIUS has such an extensive configuration, it puts the sample 
configuration in its examples folder - by default, that's 
usr/local/share/example/raddb.


There is a particular problem for the 2.0.3 to 2.0.5 upgrade that I'm 
solving once and once only in this version.

Historically the behaviour of the FreeRADIUS port on uninstallation has 
been to go through /usr/local/etc/raddb and remove any individual files 
that are the same as the sample file installed. What is left behind in 
this system are just the files you have changed. When you install a new 
version of the port, any missing files in /usr/local/etc/raddb are 
copied from the sample configuration.

The advantage of this is that you get updated versions of files you 
haven't customised. That is also a disadvantage - in that you finish up 
with a configuration based on mixed versions of sample files that may 
have weird compatibility issues.

With the move to modules having their own configuration files in 2.0.5, 
the old behaviour is untenable - anyone who has configured the server 
would finish up with two configurations for the modules (one in 
radiusd.conf, one in the modules directory), and the configurations in 
the modules directory not linked in to the server. That is confusing, to 
put it mildly.

 From 2.0.5 onwards, the port will remove the entire configuration when 
it is uninstalled - but only if it's unmodified (it does make allowance 
for the certs folder being bootstrapped). If any part of the 
configuration has been modified, it is left alone. On installation, the 
port installs a clean configuration if you don't already have one in 
/usr/local/etc/raddb - otherwise it does nothing.

However, I can't change the behaviour of older versions of the port on 
uninstallation - they will remove unmodified files in 
/usr/local/etc/raddb. The only way out of this is a message in 
/usr/ports/UPDATING to tell users to back up their configuration (or 
move it to another location than the default) whilst they upgrade the 
port. After upgrading to 2.0.5 (or later), you can then delete the newly 
installed configuration in /usr/local/etc/raddb and put their old 
configuration back. It's a one-time operation - the problem will not 
recur because of changing the behaviour of the port.

If you land up with a partial configuration, you still have your changed 
files; the problem is just missing unchanged files.


You can try to cherry pick individual ports to upgrade, but this can be 
problematic. There isn't sufficient effort available within the FreeBSD 
project to branch the ports tree. In particular, there is no notion of 
-RELEASE branches of the ports tree.

FreeBSD adopts a different model to the likes of RedHat Enterprise 
Linux, where RedHat takes on the support of the versions of third party 
software they shipped. The vendor back-ports security patches and any 
essential bug fixes to the versions they shipped. This is a conservative 
option, in that you won't be surprised by changes in third party 
software, but it leads to increasing divergence from the 'state of the 
art' in that software.


To help reduce the overhead of updating ports, no port is allowed to 
touch configuration files that the user has changed.


>b) I might need to upgrade FreeRADIUServer in future ... and _only_ 
>FreeRADIUServer .. so it might be a good exercise for me to get know 
>about how to compile FreeRADIUServer and also of the dependencies I'll 
>need in my case to be a little more independent and flexible of the 
>provided binary packages of FreeBSD.

I suggest not using the binary packages - I'm talking about ports 
really. You can't use a binary package if you want PostgreSQL support.


FreeRADIUS is relatively awkward to build correctly on FreeBSD.


FreeBSD uses -pthread for threading libraries. You should not use 
-lpthread on FreeBSD, as the toolchain and dynamic linker do the right 
thing with -pthread alone.

The issue here is that there are several threading libraries on FreeBSD 
(up to three, depending on the OS version) and you should leave the 
dynamic loader to follow its configuration rather than force dependency 
on libpthread.

files/patch-pthread in the port patches three Makefile.in files to fix 
this, which then need rebuilding with autoconf. It also patches the 
Makefile.in for rlm_python to deal with libpython being threaded by 
default on FreeBSD - that really needs rebuilding with autoconf, too.

I have offered this patch to the FreeRADIUS developers, but Nicolas 
Baradakis rejected it - if I remember rightly with a comment along the 
lines of not wanting to obfuscate the autoconf stuff for one operating 
system. I had hoped that the patch was clear, transparent and properly 
commented <sniff>.

I hereby offer it again - http://tinyurl.com/6ezh7e will bring up a 
clean copy of the patch from FreeBSD's CVSweb that should apply cleanly 
against FreeRADIUS HEAD. I would be very grateful if this was applied to 
the FreeRADIUS CVS. Maybe I should open a bug for it on 
bugs.freeradius.org.

I'm going to leave it out of the instructions below, because it's rather 
tricky to get the autoconf port working outside the ports framework.


You must use GNU make, not BSD make - this can come from the devel/gmake 
port. BSD make has a different syntax for conditionals that is 
incompatible with FreeRADIUS's makefiles.

configure needs quite a few arguments passed to it to be compliant with 
hier(7) and to find all the libraries. Your inability to build the 
PostgreSQL module indicates you haven't understood this, despite the 
advice you have been given several times.


After untarring the FreeRADIUS 2.0.5 tarball and changing directory to 
the root of the untarred tarball, these steps are roughly what you need:

LDFLAGS="-L/usr/local/lib -pthread" ; \
  CFLAGS+="-I/usr/local/include -L/usr/local/lib" ; \
  ./configure --prefix=/usr/local --libdir=/usr/local/lib \
  --localstatedir=/var --with-docdir=/usr/local/share/doc/freeradius \
  --with-logdir=/var/log \
  --with-openssl-includes=/usr/local/include/openssl \
  --with-openssl-libraries=/usr/local/lib

gmake install


You must add --with-pic to the first command if using FreeBSD amd64. You 
should omit the two openssl lines if you don't have the OpenSSL port 
included.

I don't recommend this - I really do believe it's better to use the 
port.



Best wishes,




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