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@wood2.org.uk