Hi Leander,
In message <[EMAIL PROTECTED]>, Leander S.
<[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
