Hi all, In message <478637D5.4030206@netstumbler.com>, Mother <mother@netstumbler.com> writes

Alan T DeKok wrote:

...

January 10, 2007 - Version 2.0.0 has been released. We are pleased to announce that Version 2.0.0 has been released. This version is a tremendous step forward in functionality for the server.

This is great news Alan! Any idea if a *BSD port is going to be released for it soon? I would love to see the Oracle module fixed so it can be selected/built from the configure menu (hint hint, eye twitch -> David Wood).

After a long delay (nearly two months), 2.0.0-pre2 got committed to the FreeBSD ports tree yesterday under my maintainership - it's the net/freeradius-devel port. We needed to start somewhere with FreeRADIUS 2.x - and that was it. Actually, I was about to call off that commit waiting for 2.0.0 to release, especially as Alan DeKok had said that the 2.0.0-pre2 tarball would be withdrawn - but it's too late now. 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. Oracle support won't be in the initial port; I want to update the port with its existing database support to 2.0.0 first so that we can encourage people to start migrating to 2.x. I will try to look at Oracle later on - but any pointers you can give me would be welcome, as the bsd.database.mk setup doesn't support Oracle, so the overhead for supporting Oracle in a port is rather higher than for databases supported by bsd.database.mk (from memory, that's MySQL, PostgreSQL, SQLite, Firebird and Berkeley DB). I don't have an Oracle setup to test with here; my only SQL server runs MySQL, though I'm considering moving some databases to PostgreSQL. You said that you'd hacked the net/freeradius port to build with Oracle support. If you can send me a diff of what you did, that would be helpful so that I can unpick your work and incorporate it into the port. If you can change the arguments to configure rather than hacking the configure script (or configure.in), even better! As Alan DeKok has now fixed the problem with the bzip2 tarball for 2.0.0, I'm just about to update my Subversion development repository with the committed version of net/freeradius-devel, then set about updating it for 2.0.0 release. Best wishes, David -- David Wood david@wood2.org.uk

Hi all, In message <47870106.8060801@deployingradius.com>, Alan DeKok <aland@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@wood2.org.uk

Hi Nicolas, In message <20080112152004.GG13250@asuka.dae.sitadelle.com>, Nicolas Baradakis <nbk@sitadelle.com> writes

David Wood wrote:

...

PATCH SUBMISSION - THREADING ISSUES

[...]

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.

-pthread vs -lpthread is a long discussion. If the "configure" script says -lpthread is supported, I think we can use it in all cases. (including FreeBSD)

I know - and I'm sorry to have to ask to complicate things further. The behaviour of -pthread on at least some FreeBSD systems is explained in: http://lists.freebsd.org/pipermail/freebsd-ports/2005-January/019345.html that is, -pthread means the thread library symbols are resolved by the linker, but it doesn't emit the DT_NEEDED for the thread library when building a shared library. At the time post this was written, 7.0 didn't exist, and I can quite believe that the different gcc and bintools versions in 7.0 changes things (see later). FreeBSD 6.x is very different to 7.x - 6.x is a gcc 3.4 based toolchain, whilst 7.x is gcc 4.2 based; most of the other bintools are similarly elderly in 6.x. That said, 6.x is still a current release series, and will need supporting for around another two years. I mention this to explain why it's quite possible for 6.x and 7.x to behave quite differently. I can't check, as I haven't got a 5.x machine to hand, but I suspect 5.x behaves the same as 6.x. A further complication with -lpthread is that FreeBSD sparc64 doesn't have libpthread, just libthr. These two threading libraries both conform (as much as really matters) to the POSIX threading ABI.

I'm unsure there's a need to make one more special case in the mainstream FreeRADIUS tree. Moreover I note that -pthread has been removed from the "pthread" manpage.

The reference to gcc -pthread on the pthread man page was because that flag used to be needed to link against a thread safe libc, libc_r. libc_r disappeared from FreeBSD 5.x, as did the note about gcc -pthread on the pthread man page. -pthread is still the way that threading is handled within FreeBSD ports - I did reference the appropriate documentation in the patch. For further confirmation, look at the value of PTHREAD_LIBS in /usr/ports/Mk/bsd.port.mk - CVSweb at http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk I detest the complexity, but as the FreeRADIUS port maintainer, I have to live with it. Building FreeRADIUS outside a port could hit problems on at least some FreeBSD versions unless -pthread is used. When I was developing the patch, I found at least one other 'well known' application with logic to use -pthread on FreeBSD - but I can't remember which - sorry!

...

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.

I believe this is a problem with the python library. The linker should report the dependencies of libpython2.4.so.

I've asked a friend who is running 7.0-CURRENT and it looks OK for him:

$ ldd /usr/local/lib/libpython2.4.so.1 /usr/local/lib/libpython2.4.so.1: libutil.so.6 => /lib/libutil.so.6 (0x800c24000) libm.so.4 => /lib/libm.so.4 (0x800d32000) libthr.so.2 => /lib/libthr.so.2 (0x800e4c000) libc.so.7 => /lib/libc.so.7 (0x800632000)

If the system is showing 7.0-CURRENT, that's rather old - and python 2.5 is now the default version. Recent CURRENT is now 8.0-CURRENT, whilst 7.0 is on course for a release. [david@osmium ~]$ uname -mrs FreeBSD 7.0-BETA4 i386 [david@osmium ~]$ ldd /usr/local/lib/libpython2.5.so /usr/local/lib/libpython2.5.so: libutil.so.7 => /lib/libutil.so.7 (0x2817d000) libm.so.5 => /lib/libm.so.5 (0x2818a000) libthr.so.3 => /lib/libthr.so.3 (0x2819f000) libc.so.7 => /lib/libc.so.7 (0x28080000) This system is actually a little beyond 7.0-BETA4 - it's on the way to 7.0-RC1 level, so it's fairly recent. I shall probably rebuild it a 7.0-RC2 level when that's available. Actually this system is a VMware virtual machine - it's my 7.0 development platform. However, back on what is still the latest release: [david@titanium ~]$ uname -mrs FreeBSD 6.2-RELEASE-p9 i386 [david@titanium ~]$ ldd /usr/local/lib/libpython2.5.so /usr/local/lib/libpython2.5.so: libutil.so.5 => /lib/libutil.so.5 (0x482a6000) libm.so.4 => /lib/libm.so.4 (0x482b3000) In both cases, python was built via the lang/python25 port without any special knobs or similar configuration. Note that there's no threading library in the ldd output of 6.x, even though the library is threaded. (The lack of a libc.so dependency is because of the lack of a threading library - both libthr.so and libpthread.so depend on libc.so.)

I don't see why you would need to add -pthread to the linker command line.

Because it is quite legitimate on FreeBSD for have shared libraries - such as libpython<version>.so with thread library symbols, but without a dependency on a thread library. Without -pthread, you get an error on such systems when building rlm_python. It is for that reason that I developed the patch to the configure.in of rlm_python. It is almost certainly overkill; I suspect all it needs to do is to try -pthread on FreeBSD and not repeat all the other threading checks. Best wishes, David -- David Wood david@wood2.org.uk