Re: Upcomming FreeRadius 0.9 release
Hi Alan, That would explain it - I just copied my 0.8.1 EAP module into the 0.9 tree and tried it. I'd like to get the new EAP code in 0.9 if there's time. I havent written it yet, and I have a pretty good list of other stuff I need to get done this week. Is there a date for 0.9 yet? Hopefully I can get to it this week, if not it should happen next week. If 0.9 is getting close maybe that wont work. I'll get to it as quick as I can - in any case, if the patch shows up in CVS, I'll know I can use it without breaking anything. I assume that if I change the sub-module interface I also need to change the other sub-modules. That is, they probably dont get magically updated to fit somehow. :) I've never submitted a patch before, but the process looks straight-forward. Dave Alan DeKok wrote: Dave Mason [EMAIL PROTECTED] wrote: I'm working on a new EAP type. I did a quick test to drop in my rlm_eap module tree, which is based on v0.8.1. Everything looks OK, though I havent banged on it too hard. ;The one thing I did notice is that the new v0.9 radiusd.conf turns on eap in the post-proxy section, Yes, for LEAP weirdness. If you're using the 0.8.1 EAP module, it doesn't do LEAP. Any chance of submitting the EAP module for inclusion with the rest of the tree? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upcomming FreeRadius 0.9 release
Dave Mason [EMAIL PROTECTED] wrote: I'm working on a new EAP type. I did a quick test to drop in my rlm_eap module tree, which is based on v0.8.1. Everything looks OK, though I havent banged on it too hard. ;The one thing I did notice is that the new v0.9 radiusd.conf turns on eap in the post-proxy section, Yes, for LEAP weirdness. If you're using the 0.8.1 EAP module, it doesn't do LEAP. Any chance of submitting the EAP module for inclusion with the rest of the tree? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upcomming FreeRadius 0.9 release
Hi,
I am not subscribed so hopefully this message will come through.
Perhaps you can Cc: me.
In March I sent a mail to [EMAIL PROTECTED] and Alan DeKok
replied once.
Here is an excerpt of my mail:
--- cut ---
I have done a private update for the freeradius port on FreeBSD to
version 0.8.1.
This now includes a dozen of patches where the most notable changes are:
- updates for the usage of system libltdl (libtool)
- renaming of libradius to not conflict with /usr/lib/libradius
- fix some compiler warnings / errors
- added a own HA script (this is what radiator calls the while true
loop in a shell script ;-) )
This is done because I do not really trust the code to run
for a long time and radwatch will go away in future releases
according to the manpage.
- added another option to also write pid file when running in
foreground to be able to reload in this mode too.
There are still some itmes for the that would be needed for a clean
freebsd port on the TODO but it now works for me and I do not have
the time to further work on it.
Thus I have already send a pointer to the official FreeBSD port
maintainer and freebsd ports mailing list. Perhaps someone from there
will further work on it.
You may fetch the patches from the tarball on
http://sources.zabbadoz.net/freebsd/ports/
[I do not include as they are ~ 66k (including freebsd port specifica)]
There is also a README that tries to describe what each patch is for
and also contains the TODO.
Please feel free to take any of these and perhaps consider some for
the next release.
--- cut ---
The libltdl, libradius-libfreeradius and the option would be very
helpfull. From what I can see nothing made it to CVS.
Another point I would like to mention is that you should name the
release 0.9.0 and not 0.9 or not have an 0.9.x version in the
future. This naming scheme with wither a.b.c or only a.b breaks
some package building systems out there.
Please consider this for the release too.
PS: a full description of each patch can be found in
http://sources.zabbadoz.net/freebsd/ports/freeradius-0.8.1_2-README
and the single patch-a{a..n} files can be found in the tbz tarball in
the files/ directory. The tarball ist at
http://sources.zabbadoz.net/freebsd/ports/freeradius-0.8.1_2-src.tbz
(only port sources, no freeradius sources or binary files).
--
Greetings
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upcomming FreeRadius 0.9 release
Bjoern A. Zeeb [EMAIL PROTECTED] wrote: I have done a private update for the freeradius port on FreeBSD to version 0.8.1. The problem is that the CVS head has changed *significantly* since 0.8.1 was released. This means that it's likely that many of the fixes you did are *already* in CVS. - updates for the usage of system libltdl (libtool) - renaming of libradius to not conflict with /usr/lib/libradius This should be done before 1.0, but it's not necessary for 1.0. - fix some compiler warnings / errors - added a own HA script (this is what radiator calls the while true loop in a shell script ;-) ) This is done because I do not really trust the code to run for a long time and radwatch will go away in future releases according to the manpage. I don't see how this script does any more than what radwatch does. - added another option to also write pid file when running in foreground to be able to reload in this mode too. This patch is unnecessary, and won't go into the server. When running the server in non-daemon mode, the shell variable $$ is set to the PID of the server. So there is already a way to get the PID, and no patches to the server are required. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upcomming FreeRadius 0.9 release
On Thursday, Jun 12, 2003, at 00:27 Australia/Melbourne, Peter Nixon
wrote:
Hello List
For the MacOS X users on the list, this is built on 10.2.6, with
postgresql-7.3.3, and openssl-0.9.6i.
Seems to work nicely. I'll fire up postgres a bit later, and actually
try to log to it, but the build process works fine. Had a few problems
where EAP couldn't load any EAP modules, so I've stopped that from
loading for the time being.
Matt.
radiusd: FreeRADIUS Version 0.9-pre, for host powerpc-apple-darwin6.6,
built on 06/13/03 at 15:56:23
dhcp68 /usr/local/sbin sudo ./radiusd -X
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/sql.conf
main: prefix = /usr/local
main: localstatedir = /usr/local/var
main: logdir = /usr/local/var/log/radius
main: libdir = /usr/local/lib
main: radacctdir = /usr/local/var/log/radius/radacct
main: hostname_lookups = 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 = /usr/local/var/log/radius/radius.log
main: log_auth = no
main: log_auth_badpass = no
main: log_auth_goodpass = no
main: pidfile = /usr/local/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 = yes
proxy: retry_delay = 5
proxy: retry_count = 3
proxy: synchronous = no
proxy: default_fallback = yes
proxy: dead_time = 120
proxy: post_proxy_authorize = yes
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
read_config_files: reading clients
read_config_files: reading realms
radiusd: entering modules setup
Module: Library search path is /usr/local/lib
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: passwd = (null)
mschap: authtype = MS-CHAP
Module: Instantiated mschap (mschap)
Module: Loaded System
unix: cache = no
unix: passwd = (null)
unix: shadow = (null)
unix: group = (null)
unix: radwtmp = /usr/local/var/log/radius/radwtmp
unix: usegroup = no
unix: cache_reload = 600
Module: Instantiated unix (unix)
Module: Loaded preprocess
preprocess: huntgroups = /usr/local/etc/raddb/huntgroups
preprocess: hints = /usr/local/etc/raddb/hints
preprocess: with_ascend_hack = no
preprocess: ascend_channels_per_line = 23
preprocess: with_ntdomain_hack = no
preprocess: with_specialix_jetstream_hack = no
preprocess: with_cisco_vsa_hack = no
Module: Instantiated preprocess (preprocess)
Module: Loaded realm
realm: format = suffix
realm: delimiter = @
Module: Instantiated realm (suffix)
Module: Loaded files
files: usersfile = /usr/local/etc/raddb/users
files: acctusersfile = /usr/local/etc/raddb/acct_users
files: preproxy_usersfile = /usr/local/etc/raddb/preproxy_users
files: compat = no
Module: Instantiated files (files)
Module: Loaded Acct-Unique-Session-Id
acct_unique: key = User-Name, Acct-Session-Id, NAS-IP-Address,
Client-IP-Addre
ss, NAS-Port-Id
Module: Instantiated acct_unique (acct_unique)
Module: Loaded detail
detail: detailfile =
/usr/local/var/log/radius/radacct/%{Client-IP-Address}/de
tail-%Y%m%d
detail: detailperm = 384
detail: dirperm = 493
detail: locking = no
Module: Instantiated detail (detail)
Module: Loaded radutmp
radutmp: filename = /usr/local/var/log/radius/radutmp
radutmp: username = %{User-Name}
radutmp: case_sensitive = yes
radutmp: check_with_nas = yes
radutmp: perm = 384
radutmp: callerid = yes
Module: Instantiated radutmp (radutmp)
Listening on IP address *, ports 1812/udp and 1813/udp, with proxy on
1814/udp.
Ready to process requests.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Upcomming FreeRadius 0.9 release
Currently the script that builds the rpm package of FreeRADIUS does not
include the dictionary files as they are no longer in the /etc/raddb
directory. It's simply the case of adding the following to the %files
section in suse/freeradius.spec
# dictionary
%config /%{_prefix}/share/freeradius/*
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Nick Davis
Sent: 11 June 2003 17:31
To: [EMAIL PROTECTED]
Subject: Re: Upcomming FreeRadius 0.9 release
I just downloaded the CVS snapshotfreeradius-snapshot-20030611 .
Here is my
experience.
I compiled it with no erors. I installed it with no errors.
When I went to start radiusd it didn't start and the radius.log
had a message
telling me I was using an incorrect dictionary file. I looked at the
dictionary file in ~/snapshot-dir/raddb and found out that the dictionary
files are now installed in a different location.
I put my configs in /etc/raddb. So in my currently running
version all of the
dictionary files were in that folder. The new radius version puts the
dictionary files here: /usr/local/share/freeradius/dictionary
The end of the make install messages did not tell me the
dictionary files
were in a new location, nor inform me to update the INCLUDES in
/etc/raddb/dictionary to point to the new location.
So it might be good to put a message at the end of the make
install in the
WARNING section informing people of this.
This brings a question to mind. If radiusd has a set location
for the main
dictionary file, and that file just contains an include to the actual
dictionary files why not just put the INCLUDE line in the
radius.conf and get
rid of this extra step?
Once I fixed the dictionary file issue, radiusd started properly.
I then went and used radtest on a valid user and it worked correctly.
I am using mysql for my users and accounting. I know it can read the db,
because it accepted my radtest user. I'll just have to keep an eye on the
logs and watch for other random errors.
The dictionary file is a simple problem. Overall think freeradius is an
excellent product!
Thanks!
Nick D.
---
This email, and any files transmitted with it, is copyright and may contain
confidential information.
The contents are intended for the use of the addressee(s) only.
Unauthorized use may be unlawful.
If you receive this email by mistake, please advise sender immediately.
The views of the author may not necessarily constitute the views of Telco Electronics
Limited.
Nothing in this mail shall bind Telco Electronics Limited in any contract or
obligation.
Telco Electronics Limited
6-8 Oxford Court
Brackley
Northants
NN13 7XY
Tel 07000 701999
Fax 07000 701777
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upcomming FreeRadius 0.9 release
Sir,
As I said in my message I downloaded the CVS snapshot i.e. the tarball. I
run debian and always do a source install, so the rpm fix is irrelevant for
me.
However, I'm sure your fix could help a Suse user though.
Thanks!
Nick
On Friday 13 June 2003 06:50, Alan Litster wrote:
Currently the script that builds the rpm package of FreeRADIUS does not
include the dictionary files as they are no longer in the /etc/raddb
directory. It's simply the case of adding the following to the %files
section in suse/freeradius.spec
# dictionary
%config /%{_prefix}/share/freeradius/*
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Nick Davis
Sent: 11 June 2003 17:31
To: [EMAIL PROTECTED]
Subject: Re: Upcomming FreeRadius 0.9 release
I just downloaded the CVS snapshotfreeradius-snapshot-20030611 .
Here is my
experience.
I compiled it with no erors. I installed it with no errors.
When I went to start radiusd it didn't start and the radius.log
had a message
telling me I was using an incorrect dictionary file. I looked at the
dictionary file in ~/snapshot-dir/raddb and found out that the dictionary
files are now installed in a different location.
I put my configs in /etc/raddb. So in my currently running
version all of the
dictionary files were in that folder. The new radius version puts the
dictionary files here: /usr/local/share/freeradius/dictionary
The end of the make install messages did not tell me the
dictionary files
were in a new location, nor inform me to update the INCLUDES in
/etc/raddb/dictionary to point to the new location.
So it might be good to put a message at the end of the make
install in the
WARNING section informing people of this.
This brings a question to mind. If radiusd has a set location
for the main
dictionary file, and that file just contains an include to the actual
dictionary files why not just put the INCLUDE line in the
radius.conf and get
rid of this extra step?
Once I fixed the dictionary file issue, radiusd started properly.
I then went and used radtest on a valid user and it worked correctly.
I am using mysql for my users and accounting. I know it can read the db,
because it accepted my radtest user. I'll just have to keep an eye on the
logs and watch for other random errors.
The dictionary file is a simple problem. Overall think freeradius is an
excellent product!
Thanks!
Nick D.
--
Nick Davis
Associate Systems Administrator
[EMAIL PROTECTED]
Internet Exposure, Inc.
http://www.iexposure.com
(612)676-1946
Web Development-Web Marketing-ISP Services
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Upcomming FreeRadius 0.9 release
Oh, reading about this reminded me of something left in the spec file for 0.8.1. users.conf should be chown'd radiusd:radiusd. Otherwise, issuing a 'service radiusd reload' doesn't work (actually, it stops radiusd!), cause the radiusd-suid daemon cannot re-read that file. I have something like: --- freeradius-snapshot-20030613.org/redhat/freeradius.spec 2003-05-26 17:40:00.0 +0200 +++ freeradius-snapshot-20030613/redhat/freeradius.spec 2003-06-13 17:01:34.0 +0200 @@ -85,6 +85,13 @@ chmod 600 /var/log/$i done +mkdir -p /etc/raddb/pooles +for i in radiusd.conf clients.conf pooles +do + chown radiusd:radiusd /etc/raddb/$i +done + + %postun if [ $1 -ge 1 ]; then /sbin/service radiusd condrestart /dev/null 21 Jonathan. -- Jonathan Ruano kobalt at pobox dot com - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upcomming FreeRadius 0.9 release
posted mailed Dave Mason wrote: Hi,br I'm working on a new EAP type. nbsp;I did a quick test to drop in my rlm_eap module tree, which is based on v0.8.1. nbsp;Everything looks OK, though I havent banged on it too hard. nbsp;The one thing I did notice is that the new v0.9 radiusd.conf turns on eap in the post-proxy section, producing this error:br radiusd.conf: eap modules aren't allowed in 'post-proxy' sections -- they have no such method.br Once I commented that out, it ran fine.br That sounds like a bug to me. PS: In another thread I mentioned to Alan that I need to be able to return RLM_MODULE_HANDLED from rlm_eap in some cases. nbsp;The v0.8.1 version cant do that, so he appeared to recommend that I change the interface between rlm_eap and the eap subtypes, so the subtypes could return RLM_MODULE codes. nbsp;I wanted to confirm that with him before I get out of sync with the other subtypes. nbsp;Apparently he's on vacation now, so I may put that on hold till he gets back. nbsp;I dont know the time frame for v0.9, but if this happens it may not be till after it's out.br br OK. I am not using EAP so I can't test this myself. In the absense of Alan I am loath to commit any major changes before the release of 0.9 -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upcomming FreeRadius 0.9 release
On Thu, Jun 12, 2003 at 12:47:23PM +0200, Oliver Graf wrote:
On Wed, Jun 11, 2003 at 05:27:26PM +0300, Peter Nixon wrote:
What this means is that we need everyone who can to test the current CVS
snapshots available from ftp://ftp.freeradius.org/pub/radius/CVS-snapshots/
These should be in a pretty stable condition right now, but we need to get any
remaining bugs ironed out before we release 0.9 in a few weeks time.
Regarding the crypt mutex problem:
I have just patched freeradius that it uses PAP auth if requested. It
will autodetect the scheme by looking for either Password or
Crypt-Password pairs. Works fine.
Next steps:
- Make auth.c use rlm_pap instead of doing Local or Crypt-Local on its
own.
- Move the mutex back to rlm_pap.
The patch for the above points is appended.
It will try to locate the PAP module if it should use auth CRYPT or
LOCAL and use it instead of CRYPT. It will no longer globber an
explicit PAP entry, if Crypt-Password is given.
rlm_pap now recognizes Crypt-Password pairs and will automgically
change to crypt scheme if it finds one.
A warning is given if the CRYPT within auth.c is used (no PAP module
found).
Ugly parts:
- I don't know if I use Password and Crypt-Password attributes
correctly. If I choose == as operator, an Password entry will
be filtered by files, and so crypted passwords used with Password
attribute will not find the user. Using := instead will work.
- SHA1 and MD5 schemes will not work.
Usage:
- set auth type to nothing, local, crypt-local, or pap, and auth will
try to use rlm_pap with an Password or Crypt-Password attribute.
- Use Crypt-Password == 'crypted string' to make rlm_pap
automagically crypt scheme
- Use Password := 'password' to use the configured encryption scheme
Password == will normaly result in some autz module ignoring the
entry, if password is not plain text.
- Look after rlm_unix which uses also crypt.
This is a bit trickier. Two Possible solutions: turn this into an
authorize module which can use pap again, or call rlm_pap.auth instead
of using crypt directly...
Opinions?
Oliver.
Index: src/main/auth.c
===
RCS file: /source/radiusd/src/main/auth.c,v
retrieving revision 1.125
diff -u -r1.125 auth.c
--- src/main/auth.c 10 Apr 2003 18:09:03 - 1.125
+++ src/main/auth.c 12 Jun 2003 11:30:30 -
@@ -195,6 +195,7 @@
int result;
int auth_type_count = 0;
result = 0;
+ DICT_VALUE *rlm_pap_pair=NULL;
/*
* Look for matching check items. We skip the whole lot
@@ -236,9 +237,9 @@
* Find the password from the users file.
*/
if ((password_pair = pairfind(request-config_items, PW_CRYPT_PASSWORD)) !=
NULL)
- auth_type = PW_AUTHTYPE_CRYPT;
+ auth_type = PW_AUTHTYPE_CRYPT;
else
- password_pair = pairfind(request-config_items, PW_PASSWORD);
+ password_pair = pairfind(request-config_items, PW_PASSWORD);
if (auth_type 0) {
if (password_pair) {
@@ -255,6 +256,13 @@
}
}
+ if (auth_type == PW_AUTHTYPE_LOCAL || auth_type == PW_AUTHTYPE_CRYPT) {
+ if ((rlm_pap_pair = dict_valbyname(PW_AUTH_TYPE, PAP)) != NULL) {
+ DEBUG2( rad_check_password: using PAP module for authentication);
+ auth_type = rlm_pap_pair-value;
+ }
+ }
+
switch(auth_type) {
case PW_AUTHTYPE_CRYPT:
/*
@@ -262,6 +270,7 @@
* SHOULD be there, if it's not
* authentication fails.
*/
+ radlog(L_AUTH, WARNING: crypt is not thread-safe. please use
rlm_pap, request, 0);
auth_item = request-password;
if (auth_item == NULL) {
DEBUG2(auth: No User-Password or CHAP-Password
attribute in the request);
Index: src/modules/rlm_pap/rlm_pap.c
===
RCS file: /source/radiusd/src/modules/rlm_pap/rlm_pap.c,v
retrieving revision 1.11
diff -u -r1.11 rlm_pap.c
--- src/modules/rlm_pap/rlm_pap.c 23 Jan 2003 20:54:46 - 1.11
+++ src/modules/rlm_pap/rlm_pap.c 12 Jun 2003 11:30:30 -
@@ -159,6 +159,7 @@
char digest[20];
char buff[MAX_STRING_LEN];
rlm_pap_t *inst = (rlm_pap_t *) instance;
+ int this_sch=0;
/* quiet the compiler */
instance = instance;
@@ -187,13 +188,21 @@
DEBUG(rlm_pap: login attempt by \%s\ with password %s,
request-username-strvalue, request-password-strvalue);
- if (((passwd_item = pairfind(request-config_items, PW_PASSWORD)) == NULL) ||
- (passwd_item-length == 0) || (passwd_item-strvalue[0] == 0)) {
-
Re: Upcomming FreeRadius 0.9 release
On Thu, Jun 12, 2003 at 01:41:30PM +0200, Oliver Graf wrote: Ugly parts: - I don't know if I use Password and Crypt-Password attributes correctly. If I choose == as operator, an Password entry will be filtered by files, and so crypted passwords used with Password attribute will not find the user. Using := instead will work. - SHA1 and MD5 schemes will not work. This should read: - SHA1 and MD5 will not work AUTOMAGICALLY. Oliver. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upcomming FreeRadius 0.9 release
Sorry about the cross post, but the same information applies to both
lists. :)
On Wed, 11 Jun 2003 at 17:27 (+0300), Peter Nixon wrote:
PN to get any remaining bugs ironed out before we release 0.9 in
PN a few weeks time.
I have recently (Monday) upgraded a few machines to the latest CVS
version at the time. I had a couple of problems with it. The first
problem was with the SQL query with postgres.
The following query in postgresql.conf did not work with the versions
of postgres in use (7.2.3, and 7.3.2).
accounting_onoff_query = UPDATE ${acct_table1} SET AcctStopTime='%S', A
cctSessionTime=extract(epoch from (timestamp('%S') - timestamp(AcctStartTime))),
AcctTerminateCause='%{Acct-Terminate-Cause}', AcctStopDelay = %{Acct-Delay-Time
:-0} WHERE AcctSessionTime=0 AND AcctStopTime IS NULL AND NASIPAddress= '%{NAS-I
P-Address}' AND AcctStartTime = '%S'
I changed it to:
accounting_onoff_query = UPDATE ${acct_table1} SET AcctStopTime='%S', A
cctSessionTime=extract(epoch from timestamp '%S' - AcctStartTime), AcctTerminat
eCause='%{Acct-Terminate-Cause}', AcctStopDelay = %{Acct-Delay-Time:-0} WHERE Ac
ctSessionTime=0 AND AcctStopTime IS NULL AND NASIPAddress= '%{NAS-IP-Address}' A
ND AcctStartTime = '%S'
and FreeRADIUS stopped generating an error. I don't know if it still
has the desired affect though. Someone with more Postgres experience
should look this over and decide what the correct fix is.
The other problem I had was a segmentation fault while reading the
clients file. In specific in clients_free. Since I was on the clock
for a customer getting it setup I didn't take a lot of time to
troubleshoot it. The fix that I used was to comment out lines 765 to
771 and just skip over the clients file. Not a perfect fix but it
worked well.
Unfortunately, since my customer was paying me to fix his problem I
don't have a lot of helpful information. If anyone has specific
questions I will try to answer them the best I can.
Since the clients file is deprecated would it make sense to have
FreeRADIUS throw a warning when it tried to use it so it could be
removed in the future after given the users ample opportunity to
migrate? The same goes for naslist and realms.
Michael
--
Michael J. Hartwick, VE3SLQ [EMAIL PROTECTED]
Hartwick Communications Consulting (519) 396-7719
Kincardine, ON, CA http://www.hartwick.com
--
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upcomming FreeRadius 0.9 release
Michael J. Hartwick wrote:
Sorry about the cross post, but the same information applies to both
lists. :)
On Wed, 11 Jun 2003 at 17:27 (+0300), Peter Nixon wrote:
PN to get any remaining bugs ironed out before we release 0.9 in
PN a few weeks time.
I have recently (Monday) upgraded a few machines to the latest CVS
version at the time. I had a couple of problems with it. The first
problem was with the SQL query with postgres.
The following query in postgresql.conf did not work with the versions
of postgres in use (7.2.3, and 7.3.2).
accounting_onoff_query = UPDATE ${acct_table1} SET
AcctStopTime='%S', A
cctSessionTime=extract(epoch from (timestamp('%S') -
timestamp(AcctStartTime))),
AcctTerminateCause='%{Acct-Terminate-Cause}', AcctStopDelay =
%{Acct-Delay-Time
:-0} WHERE AcctSessionTime=0 AND AcctStopTime IS NULL AND NASIPAddress=
:'%{NAS-I
P-Address}' AND AcctStartTime = '%S'
I changed it to:
accounting_onoff_query = UPDATE ${acct_table1} SET
AcctStopTime='%S', A
cctSessionTime=extract(epoch from timestamp '%S' - AcctStartTime),
AcctTerminat eCause='%{Acct-Terminate-Cause}', AcctStopDelay =
%{Acct-Delay-Time:-0} WHERE Ac ctSessionTime=0 AND AcctStopTime IS NULL
AND NASIPAddress= '%{NAS-IP-Address}' A ND AcctStartTime = '%S'
and FreeRADIUS stopped generating an error. I don't know if it still
has the desired affect though. Someone with more Postgres experience
should look this over and decide what the correct fix is.
A fix for this has been committed to CVS.
The other problem I had was a segmentation fault while reading the
clients file. In specific in clients_free. Since I was on the clock
for a customer getting it setup I didn't take a lot of time to
troubleshoot it. The fix that I used was to comment out lines 765 to
771 and just skip over the clients file. Not a perfect fix but it
worked well.
Has anyone else see this problem?
--
Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upcomming FreeRadius 0.9 release
I just downloaded the CVS snapshotfreeradius-snapshot-20030611 . Here is my experience. I compiled it with no erors. I installed it with no errors. When I went to start radiusd it didn't start and the radius.log had a message telling me I was using an incorrect dictionary file. I looked at the dictionary file in ~/snapshot-dir/raddb and found out that the dictionary files are now installed in a different location. I put my configs in /etc/raddb. So in my currently running version all of the dictionary files were in that folder. The new radius version puts the dictionary files here: /usr/local/share/freeradius/dictionary The end of the make install messages did not tell me the dictionary files were in a new location, nor inform me to update the INCLUDES in /etc/raddb/dictionary to point to the new location. So it might be good to put a message at the end of the make install in the WARNING section informing people of this. This brings a question to mind. If radiusd has a set location for the main dictionary file, and that file just contains an include to the actual dictionary files why not just put the INCLUDE line in the radius.conf and get rid of this extra step? Once I fixed the dictionary file issue, radiusd started properly. I then went and used radtest on a valid user and it worked correctly. I am using mysql for my users and accounting. I know it can read the db, because it accepted my radtest user. I'll just have to keep an eye on the logs and watch for other random errors. The dictionary file is a simple problem. Overall think freeradius is an excellent product! Thanks! Nick D. On Wednesday 11 June 2003 09:27, Peter Nixon wrote: Hello List As Alan is going away on holidays, and no-one else was stupid enough to put up their hand, it seems that I am going to be the one rolling the new 0.9 release of FreeRadius. What this means is that we need everyone who can to test the current CVS snapshots available from ftp://ftp.freeradius.org/pub/radius/CVS-snapshots/ These should be in a pretty stable condition right now, but we need to get any remaining bugs ironed out before we release 0.9 in a few weeks time. So please download, compile and report any problems you might have. Cheering in the streets and yay it works posted to the mailing list will be taken as a sign that everything is ok, bug reports to the list (with system information please) will be taken as notice that we need to do some more work before release, and a deathly silence will be taken as a sign that no-one reads my emails :-) -- Nick Davis Associate Systems Administrator [EMAIL PROTECTED] Internet Exposure, Inc. http://www.iexposure.com (612)676-1946 Web Development-Web Marketing-ISP Services - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upcomming FreeRadius 0.9 release
Hi, I'm working on a new EAP type. I did a quick test to drop in my rlm_eap module tree, which is based on v0.8.1. Everything looks OK, though I havent banged on it too hard. The one thing I did notice is that the new v0.9 radiusd.conf turns on eap in the post-proxy section, producing this error: radiusd.conf: "eap" modules aren't allowed in 'post-proxy' sections -- they have no such method. Once I commented that out, it ran fine. Dave PS: In another thread I mentioned to Alan that I need to be able to return RLM_MODULE_HANDLED from rlm_eap in some cases. The v0.8.1 version cant do that, so he appeared to recommend that I change the interface between rlm_eap and the eap subtypes, so the subtypes could return RLM_MODULE codes. I wanted to confirm that with him before I get out of sync with the other subtypes. Apparently he's on vacation now, so I may put that on hold till he gets back. I dont know the time frame for v0.9, but if this happens it may not be till after it's out. Peter Nixon wrote: Hello List As Alan is going away on holidays, and no-one else was stupid enough to put up their hand, it seems that I am going to be the one rolling the new 0.9 release of FreeRadius. What this means is that we need everyone who can to test the current CVS snapshots available from ftp://ftp.freeradius.org/pub/radius/CVS-snapshots/ These should be in a pretty stable condition right now, but we need to get any remaining bugs ironed out before we release 0.9 in a few weeks time. So please download, compile and report any problems you might have. Cheering in the streets and "yay it works" posted to the mailing list will be taken as a sign that everything is ok, bug reports to the list (with system information please) will be taken as notice that we need to do some more work before release, and a deathly silence will be taken as a sign that no-one reads my emails -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc inline: smile_n.gif
