In the default /etc/raddb configuration of net-dialup/freeradius-1.0.2-r4 (and -r3, at least), an ippool called "main_pool" is defined in /etc/radiusd.conf. If you actually attempt to *use* the main_pool module (or any other ippool module you might define) by uncommenting the "main_pool" lines in the accounting section (at line 1790) and/or the post_auth section (at line 1822), then radiusd will crash immediately when starting (uncommenting either one will do it). Please note that if you try it with any debugging turned on (such as "radiusd -X"), then ironically, it runs fine. Read on for why... Here are all of the messages in /var/log/radius/radiusd.log: ############################################################################## Thu May 19 03:31:05 2005 : Info: Using deprecated naslist file. Support for this will go away soon. Thu May 19 03:31:05 2005 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Thu May 19 03:31:05 2005 : Error: Couldn't fork ############################################################################## The first two lines are separate configuration issues in the default config built by the ebuild, and are for another bug. The last line is the problem. For some reason, this bug only manifests itself when radiusd runs in threaded mode (which it does by default). Since turning on debugging makes the server stay attached and run in "single-server" mode, it runs fine when you turn on debugging (I may never forgive upstream for making debugging mode act so fundamentally different from "real-world" mode :P ). Obviously, RADIUS-managed IP pools are a feature that should be working. My workaround for the moment is to change the start line in /etc/init.d/radiusd to "start-stop-daemon --start --quiet --background --exec /usr/sbin/radiusd -- -s ${RADIUSD_OPTS} >/dev/null", thus making it run in single-server mode. Unfortunately that breaks the ability to "/etc/init.d/radiusd stop" and impacts the performance due to the loss of threading. ############################################################################## # emerge info Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.11-hardened-r13 i686) ================================================================= System uname: 2.6.11-hardened-r13 i686 AMD Duron(tm) processor Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.5 [2.3.5 (#1, May 2 2005, 03:20:41)] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-tbird -fomit-frame-pointer -fforce-addr -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-tbird -fomit-frame-pointer -fforce-addr -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig buildpkg ccache collision-protect confcache digest distlocks fixpackages sandbox sfperms strict test userpriv userpriv_fakeroot usersandbox verify-rdepend" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo http://mirrors.tds.net/gentoo ftp://linux.thai.net/pub/mirrors/gentoo" LANG="en_US" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.nerone.org/gentoo-portage" USE="x86 3dnow 3dnowext acl alsa apm arts avi bash-completion bitmap-fonts caps crypt cups emboss encode foomaticdb fortran gif hardened imlib ithreads jpeg libg++ libwww mad mailwrapper mikmod mmap mmx mmxext motif mp3 mpeg ncurses nls nptl nptlonly oggvorbis opengl pam pcre pdflib perl pic pie png python quicktime readline sasl sdl sse ssl svga threads truetype truetype-fonts type1-fonts xml xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LC_ALL, LDFLAGS, LINGUAS ##############################################################################
Actually, I'm assuming the "threading" part based on the man page. It may actually just be child processes.
The /etc/raddb directory gets installed having root:radiusd as owner/group, with 0750 permissions. From the security point of view, it's best to deny write access rights in config directory. This will not going to change. I've uncommented both main_pool lines and tried to start radius. The result was : config not ok! (try /usr/sbin/check-radiusd-config ) After I launched check-radiusd-config, I've learned that it requires write access in /etc/raddb, so I've set 0770 on /etc/raddb. I've started again, and it worked. As I've said before, freeradius has a very complex config file which makes configuration part of the service a little bit bumpy, but check-radiusd-config exist for that reason.
I appreciate your advice, but I'm pretty positive that this problem has nothing to do with directory permissions (see below). I do also know about check-radiusd-config, and it has reported a good config all along (sorry I forgot to mention that - it might have prevented the report from being immediately pigeon-holed). ############################################################################### # grep main_pool /etc/raddb/radiusd.conf # Show that lines are *not* commented ippool main_pool { main_pool main_pool # true > /var/log/radius/radius.log # Clear the log # tail -f /var/log/radius/radius.log & # So we can see the log output [1] 26879 # ls -ld /etc/raddb # Currently 750 drwxr-x--- 3 root radiusd 1024 May 19 03:47 /etc/raddb # check-radiusd-config # "Killed" line is normal. Looks good. /usr/sbin/check-radiusd-config: line 55: 26882 Killed $sbindir/radiusd -X -p 32768 >startup.log 2>&1 Radius server configuration looks OK. # radiusd # Attempt to start service Fri May 20 01:50:01 2005 : Info: Starting - reading configuration files ... Fri May 20 01:50:01 2005 : Info: Using deprecated naslist file. Support for this will go away soon. Fri May 20 01:50:01 2005 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Fri May 20 01:50:01 2005 : Error: Couldn't fork <<<<<----- It dies # chmod 770 /etc/raddb # radiusd Fri May 20 01:51:06 2005 : Info: Starting - reading configuration files ... Fri May 20 01:51:06 2005 : Info: Using deprecated naslist file. Support for this will go away soon. Fri May 20 01:51:06 2005 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Fri May 20 01:51:06 2005 : Error: Couldn't fork <<<<<----- It *still* dies # radiusd -s & [2] 26903 Fri May 20 01:51:23 2005 : Info: Starting - reading configuration files ... Fri May 20 01:51:23 2005 : Info: Using deprecated naslist file. Support for this will go away soon. Fri May 20 01:51:23 2005 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Fri May 20 01:51:23 2005 : Info: Ready to process requests. <<<<<----- Single-server mode works fine. # killall radiusd # [2]+ Done radiusd -s # [[[ Here, I edit radiusd.conf and simply recomment the two lines ]]] # radiusd # Start service normally again Fri May 20 02:01:28 2005 : Info: Starting - reading configuration files ... Fri May 20 02:01:28 2005 : Info: Using deprecated naslist file. Support for this will go away soon. Fri May 20 02:01:28 2005 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Fri May 20 02:01:28 2005 : Info: Ready to process requests. <<<<<----- Works fine with those lines commented. ############################################################################### I can further assure you that I didn't mess up the config, because I used the default config to test the issue before reporting it. The only extra action I took was "cd /etc/raddb; touch db.ipindex db.ippool; chown radiusd:radiusd db.ip*" in order to solve the permissions problem without opening up the whole directory. In fact, I just repeated this test from a fresh ebuild-provided config, with the same results: uncommenting those lines produces the failure and the same error message as above and in my original report. Just to really convince you, I repeated the test from the default config *again*, but this time using your recommendation: I removed /etc/raddb and reinstalled freeradius, then did "chmod 770 /etc/raddb", and tested that radiusd runs correctly (it did). I then uncommented the two lines I've referenced, and tested that it failed. It did, with the same error message once again. Truly, I'm not crazy, and I'm not altogether unintelligent. :P There's a problem here - whether it's architecture-specific or something like that I do not know, but it exists.
By the way, it makes sense that check-radiusd-config detects no errors, because it relies on running radiusd in single-server mode (-X has that effect, too) to do its detection.
do the following test: - stop de radius daemon - rename /etc/raddb - upgrade to freeradius-1.0.2-r5 - run etc-update and replace the files with the newer version - uncomment main_pool lines - set 0770 permissions on /etc/raddb - run /etc/init.d/radiusd start
btw, this is my use configuration (on which main_pool works): equery uses freeradius [ Searching for packages matching freeradius... ] [ Colour Code : set unset ] [ Legend : Left column (U) - USE flags from make.conf ] [ : Right column (I) - USE flags packages was installed with ] [ Found these USE variables for net-dialup/freeradius-1.0.2-r5 ] U I + + edirectory : Enable Novell eDirectory integration - - frascend : Enable Ascend binary mode - - frnothreads : Disable thread support - - frxp : Enable experimental modules + + kerberos : Adds kerberos support + + ldap : Adds LDAP support (Lightweight Directory Access Protocol) + + mysql : Adds mySQL support + + pam : <unknown> + + postgres : Adds support for the postgresql database + + snmp : Adds support for the Simple Network Management Protocol if available + + ssl : Adds support for Secure Socket Layer connections - - udpfromto : Compile in UDPFROMTO support radius.log is: Fri May 20 10:58:42 2005 : Info: Using deprecated naslist file. Support for this will go away soon. Fri May 20 10:58:42 2005 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Fri May 20 10:58:42 2005 : Info: Ready to process requests.
Though the bug itself doesn't seem to be solved, the new init.d method appears to work around it. Using radwatch (which the init.d script did not use before -r5), radiusd is run with "-f", making it stay in the foreground and not do the initial fork. As long as this doesn't prevent threading or forking *children* (whichever the case may be), I'm ok with that. Can you possibly confirm that this is the case? I.e. that this is not actually single-server mode in disguise? Anyways, here is my log which shows that the root problem still exists, though: ############################################################################## # ps auxww | grep -v grep | grep radiusd (Check it's not running) # true > /var/log/radius/radius.log # Clear the log # tail -f /var/log/radius/radius.log & # So we can see the log output [1] 25963 # mv /etc/raddb /etc/raddb.bak # emerge =freeradius-1.0.2-r5 <SNIP> # etc-update <SNIP - /etc/init.d/radiusd was the only update, which I accepted> # ls /var/run/radiusd ls: /var/run/radiusd: No such file or directory [Bug #93152 hasn't been fixed yet, so next couple of lines:] # mkdir /var/run/radiusd # chown radiusd:radiusd /var/run/radiusd # chmod 770 /etc/raddb # radiusd # Just to make sure it starts off working Fri May 20 03:35:33 2005 : Info: Starting - reading configuration files ... Fri May 20 03:35:33 2005 : Info: Using deprecated naslist file. Support for this will go away soon. Fri May 20 03:35:33 2005 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Fri May 20 03:35:33 2005 : Info: Ready to process requests. <<-- Works for now. # killall radiusd # vim /etc/raddb/radiusd.conf <I uncommented the two main_pool lines here> # radiusd Fri May 20 03:38:22 2005 : Info: Starting - reading configuration files ... Fri May 20 03:38:22 2005 : Info: Using deprecated naslist file. Support for this will go away soon. Fri May 20 03:38:22 2005 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Fri May 20 03:38:23 2005 : Error: Couldn't fork <<-- Busted. # /etc/init.d/radiusd start * Re-caching dependency info (mtimes differ)... * Starting radiusd... [ ok ] Fri May 20 03:49:51 2005 : Info: Using deprecated naslist file. Support for this will go away soon. Fri May 20 03:49:51 2005 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Fri May 20 03:49:51 2005 : Info: Ready to process requests. <<-- Yippee! I think. # equery uses freeradius [ Searching for packages matching freeradius... ] [ Colour Code : set unset ] [ Legend : Left column (U) - USE flags from make.conf ] [ : Right column (I) - USE flags packages was installed with ] [ Found these USE variables for net-dialup/freeradius-1.0.2-r5 ] U I - - edirectory : Enable Novell eDirectory integration - - frascend : Enable Ascend binary mode - - frnothreads : Disable thread support - - frxp : Enable experimental modules - - kerberos : Adds kerberos support - - ldap : Adds LDAP support (Lightweight Directory Access Protocol) - - mysql : Adds mySQL support + + pam : <unknown> - - postgres : Adds support for the postgresql database - - snmp : Adds support for the Simple Network Management Protocol if available + + ssl : Adds support for Secure Socket Layer connections - - udpfromto : Compile in UDPFROMTO support # ##############################################################################
BTW, the new initscript works with my actual config, as well. That includes the mode 750 /etc/raddb (though, as I said, I had to touch and chown the actual files radiusd wants write access to in there).
Another BTW...I just noticed that the radwatch manpage complains rather loudly that it should not be used. Hrm...
I'm afraid that freeradius is filled with such half-implemented features. Nothing we can do, so I will mark it as CANTFIX. As for the future possible removal of the radwatch, nothing to be afraid of. After all, it is a very simple bash script, so it could easily be replaced by us. I prefer to use init scripts than use daemontools and instruct our users how to get things done. Remember, every package should work out of the box, which is kind of impossible with daemontools. Sure, no one says you cannot use a daemontools script if you want to, but most users are expecting a proper init script.
Have you already moved the bug upstream (http://bugs.gentoo.org/whatisthis.html)?
feel free to send upstream a bug report.
Submitted upstream at http://bugs.freeradius.org/show_bug.cgi?id=238, including another tidbit my tests have shown, which is that this only seems to affect my Duron machine.
