Can't start FreeRadius after 1st installation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear All, I am very new to FreeRadius. Just today, I have installed FreeRadius 1.13 from FreeBSD 6.0 (i386) ports. I am following this material from: http://www.onlamp.com/pub/a/onlamp/excerpt/radius_5/index1.html However when I try to start it using: radiusd -X, I get the following errors: Starting - reading configuration files ... reread_config: reading radiusd.conf Config: including file: /usr/local/etc/raddb/proxy.conf Config: including file: /usr/local/etc/raddb/clients.conf Config: including file: /usr/local/etc/raddb/snmp.conf Config: including file: /usr/local/etc/raddb/eap.conf Config: including file: /usr/local/etc/raddb/sql.conf main: prefix = "/usr/local" main: localstatedir = "/var" main: logdir = "/var/log" main: libdir = "/usr/local/lib" main: radacctdir = "/var/log/radacct" main: hostname_lookups = no main: snmp = no main: max_request_time = 30 main: cleanup_delay = 5 main: max_requests = 1024 main: delete_blocked_requests = 0 main: port = 0 main: allow_core_dumps = no main: log_stripped_names = no main: log_file = "/var/log/radius.log" main: log_auth = no main: log_auth_badpass = no main: log_auth_goodpass = no main: pidfile = "/var/run/radiusd/radiusd.pid" main: user = "(null)" main: group = "(null)" main: usercollide = no main: lower_user = "no" main: lower_pass = "no" main: nospace_user = "no" main: nospace_pass = "no" main: checkrad = "/usr/local/sbin/checkrad" main: proxy_requests = no proxy: retry_delay = 5 proxy: retry_count = 3 proxy: synchronous = no proxy: default_fallback = yes proxy: dead_time = 120 proxy: post_proxy_authorize = no proxy: wake_all_if_all_dead = no security: max_attributes = 200 security: reject_delay = 1 security: status_server = no main: debug_level = 0 read_config_files: reading dictionary read_config_files: reading naslist Using deprecated naslist file. Support for this will go away soon. read_config_files: reading clients Using deprecated clients file. Support for this will go away soon. read_config_files: reading realms radiusd: entering modules setup Module: Library search path is /usr/local/lib Module: Loaded exec exec: wait = yes exec: program = "(null)" exec: input_pairs = "request" exec: output_pairs = "(null)" exec: packet_type = "(null)" rlm_exec: Wait=yes but no output defined. Did you mean output=none? Module: Instantiated exec (exec) Module: Loaded expr Module: Instantiated expr (expr) Module: Loaded PAP pap: encryption_scheme = "crypt" Module: Instantiated pap (pap) Module: Loaded CHAP Module: Instantiated chap (chap) Module: Loaded MS-CHAP mschap: use_mppe = yes mschap: require_encryption = no mschap: require_strong = no mschap: with_ntdomain_hack = no mschap: passwd = "(null)" mschap: ntlm_auth = "(null)" Module: Instantiated mschap (mschap) Module: Loaded System unix: cache = no unix: passwd = "/etc/passwd" unix: shadow = "/etc/shadow" unix: group = "/etc/group" unix: radwtmp = "/var/log/radwtmp" unix: usegroup = no unix: cache_reload = 600 Module: Instantiated unix (unix) Segmentation fault: 11 (core dumped) Can somebody shed some light on this issue? - -- With best regards and good wishes, Yours sincerely, Tek Bahadur Limbu (TAG/TDG Group) Jwl Systems Department Worldlink Communications Pvt. Ltd. Jawalakhel, Nepal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFFoMAnVrOl+eVhOvYRAkQZAJ4mnkYZj5EzStO36Yl07vCrp+KjGwCgoY0U eptcoO+IV9DavLvJDl/LXow= =rnIv -----END PGP SIGNATURE-----
Tek Bahadur Limbu wrote:
Dear All,
I am very new to FreeRadius. Just today, I have installed FreeRadius 1.13 from FreeBSD 6.0 (i386) ports.
I am following this material from: http://www.onlamp.com/pub/a/onlamp/excerpt/radius_5/index1.html
Why? That information is years out of date. The server comes with more up to date documentation. As for segmentation faults on FreeBSD, I suggest asking the FreeBSD port maintainer. It works fine on other systems, so the problem is something local. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 07 Jan 2007 05:09:02 -0500 Alan DeKok <aland@deployingradius.com> wrote:
Tek Bahadur Limbu wrote:
Dear All,
I am very new to FreeRadius. Just today, I have installed FreeRadius 1.13 from FreeBSD 6.0 (i386) ports.
I am following this material from: http://www.onlamp.com/pub/a/onlamp/excerpt/radius_5/index1.html
Why? That information is years out of date. The server comes with more up to date documentation.
As for segmentation faults on FreeBSD, I suggest asking the FreeBSD port maintainer. It works fine on other systems, so the problem is something local.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Dear Alan, Thanks for you suggestions. I will get some help from the FreeBSD mailing list. But I have to get FreeRadius running on a FreeBSD box. Thanks for the 2 links you provided. I will be visiting the site (http://deployingradius.com) for more help. -- With best regards and good wishes, Yours sincerely, Tek Bahadur Limbu (TAG/TDG Group) Jwl Systems Department Worldlink Communications Pvt. Ltd. Jawalakhel, Nepal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFFoN8OVrOl+eVhOvYRAilPAKCn4LtbX0vyTg66WqOu9iW3v5FJuACfe8tH anN9hEPwKiCs7blhU3r7pVg= =3gJZ -----END PGP SIGNATURE-----
Dear Tek and everyone, In message <20070107152555.330194d2.teklimbu@wlink.com.np>, teklimbu@wlink.com.np writes
I am very new to FreeRadius. Just today, I have installed FreeRadius 1.13 from FreeBSD 6.0 (i386) ports.
I am the maintainer of the FreeBSD FreeRADIUS port starting from version 1.1.3. It's probably about time I revealed myself here.
I am following this material from: http://www.onlamp.com/pub/a/onlamp/excerpt/radius_5/index1.html
As Alan DeKok says, that material is very old (2002 vintage, which is ancient history in FreeRADIUS terms). It really can't be recommended now, and I suggest that you follow the usual advice to start from the sample configuration shipped with FreeRADIUS. As is usual for a FreeBSD port (see the FreeBSD Porter's Handbook, section 7.2), the port installs the sample FreeRADIUS configuration, but the name of each file has a suffix, in this case .sample. This is to stop port upgrades, or deinstall/reinstalls, from wiping your hand-crafted configuration. In the case of FreeRADIUS, assuming you don't set PREFIX explicitly to something else, the default configuration files go in /usr/local/etc/raddb, suffixed with .sample - so /usr/local/etc/raddb/radiusd.conf.sample and so on. I suggest, therefore, that you cd /usr/local/etc/raddb cp -p radiusd.conf.sample radiusd.conf and edit radiusd.conf to suit your environment. You will need to do the same (unless you symlink if you don't need to make any changes, or you make appropriate changes to the configuration) for: clients.conf.sample dictionary.sample eap.conf.sample hints.sample huntgroups.sample proxy.conf.sample snmp.conf.sample sql.conf.sample and probably also: acct_users.sample preproxy_users.sample users.sample If you're using EAP, I suggest that you place your own certificates in raddb/mycerts, and edit eap.conf accordingly. Placing your own certificates in raddb/certs is likely to lead to them being wiped on an upgrade. (Memo to self: changing the port to install the test certificates in raddb/certs.sample is possibly worthwhile). Do NOT use the certificates shipped with FreeRADIUS on a production server - this is a significant security hole. I've not had any reports, other than yours, of the FreeBSD port failing since I took over the maintainership. I've had a few requests for enhancement of the port, and I've dealt with all those other than ones that I've dealt with and fixed the port for. The FreeBSD port is now up to 1.1.4_1; in other words, the second revision of the port of FreeRADIUS 1.1.4. The initial 1.1.4 port didn't rm -r rlm_sql_firebird, which has already been acknowledged on this list as broken, so configure failed when experimental modules were enabled. For versions 1.1.2 to 1.1.4, I was working on FreeBSD 6.1-RELEASE i386, but I have now moved to 6.2-RELEASE i386. FreeBSD's pointyhat cluster monitors build failures on other architectures, but nothing monitors whether the software runs on other architectures. FreeBSD 6.0-RELEASE becomes end of life on 31 January 2007 - from that point on there's no more security team support. It's worth considering an upgrade to 6.2-RELEASE, though read the errata and other release notes first. I never used 6.0-RELEASE (I jumped from 5.4-RELEASE to 6.1-RELEASE on my main box). 6.0-RELEASE is very nearly end of life, and I'm not much interested in fixing the port to work on 6.0-RELEASE. If you tell me that you can't get the port working on 6.0-RELEASE, I may set up a virtual 6.0-RELEASE machine and try FreeRADIUS quickly with a configuration that I know works. However, if there's a problem for which there's not an obvious fix, I'll just mark the port as broken on 6.0-RELEASE. As the FreeBSD Porter's Handbook says, in section 5.2.2: FreeBSD only guarantees that the Ports Collection works on the -STABLE branches. You should be running 5-STABLE or 6-STABLE, preferably the latter. In theory, you should be able to get by with running the latest release of each stable branch (since the ABIs are not supposed to change) but if you can run the branch, that is even better. Considering that -STABLE is not recommended for production machines (it means stable ABI, not that the operating system you'll get by downloading -STABLE is necessarily stable), I'd upgrade to 6.2-RELEASE if you need to upgrade. Another thing that I suggest you consider is building the OpenSSL port and rebuilding FreeRADIUS (portupgrade -f net/freeradius or similar) - especially if you're going to use any part of FreeRADIUS that uses OpenSSL, such as EAP. The FreeBSD FreeRADIUS port uses the OpenSSL port if it's installed in preference to the base system's OpenSSL. Indeed, I suggest you build the OpenSSL port if you're going to use any software that uses OpenSSL, because the OpenSSL version in the base system is somewhat out of date and this won't change until FreeBSD 7.0 (7.0-CURRENT has OpenSSL 0.9.8d in the base system). Before building the OpenSSL port, you may want to add the line: USE_OPENSSL_BETA=yes to /etc/make.conf to make the ports system build OpenSSL 0.9.8d rather than OpenSSL 0.9.7l - I don't see what's so beta about the 0.9.8 branch of OpenSSL these days. In summary, my suggested way ahead if you haven't already got this working is: Upgrade the FreeRADIUS port to 1.1.4_1 and build FreeRADIUS. Build a simple configuration starting from the 1.1.4 sample configuration, and test FreeRADIUS. If you're still having problems, especially if you're attempting to use any part of FreeRADIUS that relies on OpenSSL such as EAP, build the OpenSSL port and rebuild FreeRADIUS. Consider doing this anyway. If you're still having problems, upgrade the operating system (I suggest to 6.2-RELEASE). Consider doing this anyway in the light of the upcoming end of life of 6.0-RELEASE. I have the FreeBSD FreeRADIUS port 1.1.4_1 working on 6.2-RELEASE i386 with OpenSSL 0.9.8d installed via the OpenSSL port. Best wishes, David -- David Wood david@wood2.org.uk
David Wood wrote:
I am the maintainer of the FreeBSD FreeRADIUS port starting from version 1.1.3. It's probably about time I revealed myself here.
Thanks. There's been the occasional question. Having an authority here is useful.
As is usual for a FreeBSD port (see the FreeBSD Porter's Handbook, section 7.2), the port installs the sample FreeRADIUS configuration, but the name of each file has a suffix, in this case .sample. This is to stop port upgrades, or deinstall/reinstalls, from wiping your hand-crafted configuration.
But the FreeRADIUS make files do that already... Yes, I know not all projects are that smart, but still...
In the case of FreeRADIUS, assuming you don't set PREFIX explicitly to something else, the default configuration files go in /usr/local/etc/raddb, suffixed with .sample - so /usr/local/etc/raddb/radiusd.conf.sample and so on.
That's awkward. Especially because the sample configs *work* out of the box. That's the whole point of the sample configs. And worse, there are a number of files that need to be set up properly before the server runs, which makes copying the sample files even more work. Could you update the port to install the files if they don't already exist? Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Jan 20, 2007, at 1:53 AM, Alan DeKok wrote:
In the case of FreeRADIUS, assuming you don't set PREFIX explicitly to something else, the default configuration files go in /usr/local/etc/raddb, suffixed with .sample - so /usr/local/etc/raddb/radiusd.conf.sample and so on.
That's awkward. Especially because the sample configs *work* out of the box. That's the whole point of the sample configs. And worse, there are a number of files that need to be set up properly before the server runs, which makes copying the sample files even more work.
Could you update the port to install the files if they don't already exist?
And reading the Handbook you mentioned, it seems to support Alan's suggestion that both be installed when the configuration files don't exists with only the .sample files being listed in the package list. <http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ plist-config.html> -- Dave
Hi Alan and everyone, In message <45B1CA60.5040200@deployingradius.com>, Alan DeKok <aland@deployingradius.com> writes
David Wood wrote:
I am the maintainer of the FreeBSD FreeRADIUS port starting from version 1.1.3. It's probably about time I revealed myself here.
Thanks. There's been the occasional question. Having an authority here is useful.
I'll do my best - having taken on the port, I'll do my best to support it properly.
As is usual for a FreeBSD port (see the FreeBSD Porter's Handbook, section 7.2), the port installs the sample FreeRADIUS configuration, but the name of each file has a suffix, in this case .sample. This is to stop port upgrades, or deinstall/reinstalls, from wiping your hand-crafted configuration.
But the FreeRADIUS make files do that already... Yes, I know not all projects are that smart, but still...
I know.
In the case of FreeRADIUS, assuming you don't set PREFIX explicitly to something else, the default configuration files go in /usr/local/etc/raddb, suffixed with .sample - so /usr/local/etc/raddb/radiusd.conf.sample and so on.
That's awkward. Especially because the sample configs *work* out of the box. That's the whole point of the sample configs. And worse, there are a number of files that need to be set up properly before the server runs, which makes copying the sample files even more work.
Could you update the port to install the files if they don't already exist?
I didn't design the port, I merely inherited what is already there. I agree that the behaviour to date was less than helpful, so I've made the necessary changes to the port and have submitted them. See FreeBSD PR ports/108196 at <http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/108196> for a description of the new behaviour and the patch that I hope will be committed soon. I've fixed a few minor problems whilst I was there. I've no idea when one of the committers will pick this up and commit it to the CVS, but usually updates from maintainers are committed within a few days. Anyone that uses the recommended portsnap(1) tool in recent versions of FreeBSD will then pick up the revised port. I updated the port to 1.1.2 before taking the maintainership. I took the maintainership when updating it to 1.1.3, and I have subsequently updated the port to 1.1.4. As well as the version updates and today's batch of changes, I have also: * tossed out an obsolete source patch that changed the MSCHAP behaviour, and documented with_ntdomain_hack as its replacement when necessary. With this done, the functionality of the port matches the code released by the FreeRADIUS project as the only patches the port applies are build related. * added various FreeRADIUS features to the port. * added an option to disable rlm_perl and the dependency on perl (particularly for someone wanting to build FreeRADIUS for a Soekris board or similar and not wanting all the extra weight of perl). * updated the package description to the text from the FreeRADIUS home page (as the INTRO section of doc/README that was previously used is a bit crufty, also the original description had a reference to the obsolete livingston mailing list included). See <http://www.freshports.org/net/freeradius/> I'm not saying that I've got everything yet, but I think the port is now in good shape. If anyone wants to suggest further changes, or audits the port and finds any problems, I'm listening. Patches are particularly welcome, of course. Best wishes, David -- David Wood david@wood2.org.uk
David Wood wrote:
I'm not saying that I've got everything yet, but I think the port is now in good shape. If anyone wants to suggest further changes, or audits the port and finds any problems, I'm listening. Patches are particularly welcome, of course.
Thanks. Little changes like that can have large benefits over time. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Sun, January 21, 2007 7:55 pm, David Wood wrote:
I'm not saying that I've got everything yet, but I think the port is now in good shape. If anyone wants to suggest further changes, or audits the port and finds any problems, I'm listening. Patches are particularly welcome, of course.
Thanks for taking the time to support the port. The only issue i have, and this may very well not be this ports fault, is that when defined to use mysql, the port starts before mysql is ready for it, so it dies, and never effectively starts up by itself. Here is an example of what goes on in the log: --- Sat Jan 20 23:31:35 2007 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Sat Jan 20 23:31:36 2007 : Info: rlm_sql (sql): Driver rlm_sql_mysql (module rlm_sql_mysql) loaded and linked Sat Jan 20 23:31:36 2007 : Info: rlm_sql (sql): Attempting to connect to root@localhost:/radius Sat Jan 20 23:31:36 2007 : Info: rlm_sql_mysql: Starting connect to MySQL server for #0 Sat Jan 20 23:31:36 2007 : Error: rlm_sql_mysql: Couldn't connect socket to MySQL server root@localhost:radius Sat Jan 20 23:31:36 2007 : Error: rlm_sql_mysql: Mysql error 'Can't connect to local MySQL server through socket '/tmp/mysql.sock Sat Jan 20 23:31:36 2007 : Error: rlm_sql (sql): Failed to connect DB handle #0 Sat Jan 20 23:31:36 2007 : Info: rlm_sql (sql): There are no DB handles to use! skipped 5, tried to connect 0 Sat Jan 20 23:31:36 2007 : Error: rlm_sql (sql): generate_sql_clients() returned error Sat Jan 20 23:31:36 2007 : Error: radiusd.conf[14]: sql: Module instantiation failed. Sat Jan 20 23:31:36 2007 : Error: radiusd.conf[1798] Unknown module "sql". Sat Jan 20 23:31:36 2007 : Error: radiusd.conf[1727] Failed to parse authorize section.
Hi Mike and everyone, In message <23344.209.47.38.69.1169489108.squirrel@wettoast.dyndns.org>, Mike Jakubik <mikej@rogers.com> writes
Thanks for taking the time to support the port. The only issue i have, and this may very well not be this ports fault, is that when defined to use mysql, the port starts before mysql is ready for it, so it dies, and never effectively starts up by itself. Here is an example of what goes on in the log:
This is an rcorder thing - you may find man 8 rcorder and the output of: rcorder /etc/rc.d/* /usr/local/etc/rc.d/* interesting. I probably need to add extra entries to the REQUIRE line of /usr/local/etc/rc.d/radiusd when some of the optional modules are enabled. In your case, assuming that the MySQL server runs on the same box, adding mysql to the REQUIRE line to that it reads # REQUIRE: NETWORKING SERVERS mysql should do the job. The rcorder command will help you check whether that is going to work. Maybe such an addition needs doing automagically in the port - as well as the equivalent for Postgres. It wouldn't help any if the SQL server wasn't running on the same box, but I'm not sure that it would do any harm either. I may need to think further on this one, though it's not as if a manual edit to the rc.d script is that difficult. Best wishes, David -- David Wood david@wood2.org.uk
On Mon, January 22, 2007 11:28 pm, David Wood wrote:
This is an rcorder thing - you may find man 8 rcorder and the output of: rcorder /etc/rc.d/* /usr/local/etc/rc.d/* interesting.
I probably need to add extra entries to the REQUIRE line of /usr/local/etc/rc.d/radiusd when some of the optional modules are enabled.
Indeed. However the ports should keep this in mind, and set the correct rcorder variables, to ensure they start up correctly. Most ports that depend on a DB that I've come by do take this in to account, but unfortunately not all.
In your case, assuming that the MySQL server runs on the same box, adding mysql to the REQUIRE line to that it reads # REQUIRE: NETWORKING SERVERS mysql
should do the job. The rcorder command will help you check whether that is going to work.
Unfortunately its not that simple, that addition seems to make rcorder unhappy. --- rcorder: Circular dependency on provision `DAEMON' in file `/etc/rc.d/rwho'. ... rcorder: Circular dependency on file `/usr/local/etc/rc.d/radiusd'. ---
Maybe such an addition needs doing automagically in the port - as well as the equivalent for Postgres. It wouldn't help any if the SQL server wasn't running on the same box, but I'm not sure that it would do any harm either.
Yes, thats how most ports do it, the rc script is dynamically generated depending on config options. I don't believe the lack of a local server would not do any harm either.
I may need to think further on this one, though it's not as if a manual edit to the rc.d script is that difficult.
For a port maintainer that has a good grasp of the port and rcng system, maybe not, but for a user that installs and (rightly) expects the software to start, its not as trivial.
participants (5)
-
Alan DeKok -
Dave -
David Wood -
Mike Jakubik -
Tek Bahadur Limbu