Hi, I have a problem to invoke rm_ldap_groupcmp() by the users file in freeradius 3.1.x. For example, DEFAULT Huntgroup-Name == "mytest", Hint == "MYTEST", Ldap-Group == ndvm6mk9, Auth-Type := ldap-vpn Service-Type = 6, Fall-Through = Yes When entering this configuation, it only shows noop during files according to debug mode (-X) Mon Jun 20 15:59:36 2016 : Debug: (0) modsingle[authorize]: calling files (rlm_files) for request 0 Mon Jun 20 15:59:36 2016 : Debug: (0) modsingle[authorize]: returned from files (rlm_files) for request 0 Mon Jun 20 15:59:36 2016 : Debug: (0) [files] = noop Mon Jun 20 15:59:36 2016 : Debug: (0) debug_control debug_control { Mon Jun 20 15:59:36 2016 : Debug: (0) if ("%{debug_attr:control:}" == '') Mon Jun 20 15:59:36 2016 : Info: (0) Attributes matching "control:" Mon Jun 20 15:59:36 2016 : Debug: (0) EXPAND %{debug_attr:control:} Mon Jun 20 15:59:36 2016 : Debug: (0) --> Mon Jun 20 15:59:36 2016 : Debug: (0) if ("%{debug_attr:control:}" == '') -> TRUE Mon Jun 20 15:59:36 2016 : Debug: (0) if ("%{debug_attr:control:}" == '') { Mon Jun 20 15:59:36 2016 : Debug: (0) modsingle[authorize]: calling noop (rlm_always) for request 0 Mon Jun 20 15:59:36 2016 : Debug: (0) modsingle[authorize]: returned from noop (rlm_always) for request Please help, Thanks, Jon On Mon, Jun 20, 2016 at 4:33 PM, jon Yu <yunc.yu@nd.edu> wrote:
Hi,
I have a probem to invoke rm_ldap_groupcmp() by the users file in freeradius 3.1.x.
For example,
DEFAULT Huntgroup-Name == "mytest", Hint == "MYTEST", Ldap-Group == ndvm6mk9, Auth-Type := ldap-vpn
Service-Type = 6,
Fall-Through = Yes
When entering this configuation, it only shows noop during files according to debug mode (-X)
Mon Jun 20 15:59:36 2016 : Debug: (0) modsingle[authorize]: calling files (rlm_files) for request 0
Mon Jun 20 15:59:36 2016 : Debug: (0) modsingle[authorize]: returned from files (rlm_files) for request 0
Mon Jun 20 15:59:36 2016 : Debug: (0) [files] = noop
Mon Jun 20 15:59:36 2016 : Debug: (0) debug_control debug_control {
Mon Jun 20 15:59:36 2016 : Debug: (0) if ("%{debug_attr:control:}" == '')
Mon Jun 20 15:59:36 2016 : Info: (0) Attributes matching "control:"
Mon Jun 20 15:59:36 2016 : Debug: (0) EXPAND %{debug_attr:control:}
Mon Jun 20 15:59:36 2016 : Debug: (0) -->
Mon Jun 20 15:59:36 2016 : Debug: (0) if ("%{debug_attr:control:}" == '') -> TRUE
Mon Jun 20 15:59:36 2016 : Debug: (0) if ("%{debug_attr:control:}" == '') {
Mon Jun 20 15:59:36 2016 : Debug: (0) modsingle[authorize]: calling noop (rlm_always) for request 0
Mon Jun 20 15:59:36 2016 : Debug: (0) modsingle[authorize]: returned from noop (rlm_always) for request
Please help,
Thanks,
Jon
Hi,
For example,
DEFAULT Huntgroup-Name == "mytest", Hint == "MYTEST", Ldap-Group == ndvm6mk9, Auth-Type := ldap-vpn
Service-Type = 6,
Fall-Through = Yes
1) you cant just make up random values in the check line 2) you cant just make up your own layout format post the full debug and you'll see what each check item is when the packet hits the users file and then understand why it doesnt match after you've fixed the layout ;-) alan
Hi, The example configuration is currently working with Freeradius version 2 with the same huntgroups and hints. 1. file huntgroups mytest NAS-IP-Address == 172.19.xxx.xxx 2. file hints DEFAULT Suffix == ".mytest" Hint = "MYTEST" Authentication and Authorize are configured to bind and search in ldap. The following log is from version 2 rlm_ldap::ldap_groupcmp: User found in group ndrx3tv2 [ldap-vpn] ldap_release_conn: Release Id: 0 [files] users: Matched entry DEFAULT at line 212 ++[files] returns ok Is there a quick example to configure in version 3 and invoke the rm_ldap_groupcmp() ? Thanks, On Mon, Jun 20, 2016 at 6:58 PM, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
For example,
DEFAULT Huntgroup-Name == "mytest", Hint == "MYTEST", Ldap-Group == ndvm6mk9, Auth-Type := ldap-vpn
Service-Type = 6,
Fall-Through = Yes
1) you cant just make up random values in the check line
2) you cant just make up your own layout format
post the full debug and you'll see what each check item is when the packet hits the users file and then understand why it doesnt match after you've fixed the layout ;-)
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
Hi, The example configuration is currently working with Freeradius version 2 with the same huntgroups and hints.
1. file huntgroups
mytest NAS-IP-Address == 172.19.xxx.xxx
2. file hints
DEFAULT Suffix == ".mytest" Hint = "MYTEST"
Authentication and Authorize are configured to bind and search in ldap.
The following log is from version 2 rlm_ldap::ldap_groupcmp: User found in group ndrx3tv2 [ldap-vpn] ldap_release_conn: Release Id: 0 [files] users: Matched entry DEFAULT at line 212 ++[files] returns ok
Is there a quick example to configure in version 3 and invoke the rm_ldap_groupcmp() ?
you can still use the hints and huntgroup. read the README.rst file to see what the changes are and where the files now live... mods-config/preprocess/hints mods-config/preprocess/huntgroups (though , to help, there are usually top level symlinks to these new files). you then need to edit the required virtual server (eg sites-enabled/default) - ensure that preprocess is called in the authn/authz stage BEFORE your call to ldap (and you've configured the ldap module mods-enabled/ldap once you've put symlink into place....) read mods-available/README.rst and mods-available/ldap alan
On Mon, Jun 20, 2016 at 04:44:40PM -0400, jon Yu wrote:
DEFAULT Huntgroup-Name == "mytest", Hint == "MYTEST", Ldap-Group == ndvm6mk9, Auth-Type := ldap-vpn Service-Type = 6, Fall-Through = Yes
Make sure this is at the top of the file above any other DEFAULT entries that may not include "Fall-Through".
Mon Jun 20 15:59:36 2016 : Debug: (0) [files] = noop Mon Jun 20 15:59:36 2016 : Debug: (0) debug_control debug_control { Mon Jun 20 15:59:36 2016 : Debug: (0) if ("%{debug_attr:control:}" == '') Mon Jun 20 15:59:36 2016 : Info: (0) Attributes matching "control:" Mon Jun 20 15:59:36 2016 : Debug: (0) EXPAND %{debug_attr:control:} Mon Jun 20 15:59:36 2016 : Debug: (0) --> Mon Jun 20 15:59:36 2016 : Debug: (0) if ("%{debug_attr:control:}" == '') -> TRUE Mon Jun 20 15:59:36 2016 : Debug: (0) if ("%{debug_attr:control:}" == '') {
So something may not be being set. I would - remove checks from the DEFAULT line in the users file until you get something that works, then you know exactly what isn't being set. - check your hints and huntgroups files and make sure they are matching. - check you haven't removed "preprocess" (we can't as you didn't post the whole debug output, which is recommended pretty much every day on this list). - consider using unlang instead of 'hints' and 'huntgroups'. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
The log file is attached. Like to know how to configure Ldap-Group to find user in group object. Thanks, On Tue, Jun 21, 2016 at 9:06 AM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Mon, Jun 20, 2016 at 04:44:40PM -0400, jon Yu wrote:
DEFAULT Huntgroup-Name == "mytest", Hint == "MYTEST", Ldap-Group == ndvm6mk9, Auth-Type := ldap-vpn Service-Type = 6, Fall-Through = Yes
Make sure this is at the top of the file above any other DEFAULT entries that may not include "Fall-Through".
Mon Jun 20 15:59:36 2016 : Debug: (0) [files] = noop Mon Jun 20 15:59:36 2016 : Debug: (0) debug_control debug_control { Mon Jun 20 15:59:36 2016 : Debug: (0) if ("%{debug_attr:control:}" == '') Mon Jun 20 15:59:36 2016 : Info: (0) Attributes matching "control:" Mon Jun 20 15:59:36 2016 : Debug: (0) EXPAND %{debug_attr:control:} Mon Jun 20 15:59:36 2016 : Debug: (0) --> Mon Jun 20 15:59:36 2016 : Debug: (0) if ("%{debug_attr:control:}" == '') -> TRUE Mon Jun 20 15:59:36 2016 : Debug: (0) if ("%{debug_attr:control:}" == '') {
So something may not be being set.
I would
- remove checks from the DEFAULT line in the users file until you get something that works, then you know exactly what isn't being set.
- check your hints and huntgroups files and make sure they are matching.
- check you haven't removed "preprocess" (we can't as you didn't post the whole debug output, which is recommended pretty much every day on this list).
- consider using unlang instead of 'hints' and 'huntgroups'.
Matthew
-- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk>
Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 21, 2016, at 1:39 PM, jon Yu <yunc.yu@nd.edu> wrote:
The log file is attached. Like to know how to configure Ldap-Group to find user in group object.
... if (LDAP-Group == "users") { ... } ... It's that simple. The "authorize" sections from v2 will largely work in v3. See raddb/README.rst for differences between the two version. If you're having problems getting LDAP-Group to work, it's probably because you've configured one thing in v2, and something completely different in v3. The fix for that is to make the "unlang" policies in v3 look more like what you did in v2. I'll also note you're very careful to give out the absolute minimum information about the problem. That makes it very difficult to help you. The summary is you probably just made v3 do something different from v2. Well... fix that, then. Alan DeKok.
On Tue, Jun 21, 2016 at 01:48:09PM -0400, Alan DeKok wrote:
If you're having problems getting LDAP-Group to work, it's probably because you've configured one thing in v2, and something completely different in v3. The fix for that is to make the "unlang" policies in v3 look more like what you did in v2.
Copying the v2 rlm_ldap config to v3 then trying to tweak it to make it work has caused other people problems. OP should definitely start from a v3 config and configure that if they haven't already. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hello, We've installed on production yesterday FreeRADIUS version 3.0.11 (upgraded from 3.0.8). Today we've noticed that the server got blocked. All the threads got blocked on module "linelog", which we can see in the logs: Wed Jun 22 11:57:11 2016 : Error: (1774170) Ignoring duplicate packet from client *** port 21687 - ID: 186 due to unfinished request in component post-auth module linelog Then we get lots of the following messages (clients are not happy being ignored): Wed Jun 22 11:58:18 2016 : Error: (1777300) Ignoring duplicate packet from client *** port 21733 - ID: 5 due to unfinished request in component <core> module <queue> And a few minutes later, FreeRADIUS queue is full and we get: Wed Jun 22 12:11:17 2016 : Error: Something is blocking the server. There are 65536 packets in the queue, waiting to be processed. Ignoring the new request. The issue occurred less than one day after rolling out the new FreeRADIUS version (3.0.11). It never occurred on the previous version (3.0.8) we've been using for more than one year. We've not made any change to our linelog configuration (or to anything else, except for the FreeRADIUS version upgrade). So I'm suspecting this is related to FreeRADIUS. I've noticed the following commit related to locking (which is configurable for detail, but not linelog): https://github.com/FreeRADIUS/freeradius-server/commit/dd2a06aa6ba8d6b819712... Note that I didn't see anything wrong with the code, just noticed the "locking" part which made me suspicious... maybe I'm wrong, but I'd like to get your opinion. Could the locking be responsible for the behaviour we've observed ? Should we patch our linelog to force "locking" to false ? Also, I think FreeRADIUS threads should never get blocked forever when trying to acquire a lock. (if that's what is happening) Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
On Jun 22, 2016, at 9:34 AM, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
We've installed on production yesterday FreeRADIUS version 3.0.11 (upgraded from 3.0.8).
Today we've noticed that the server got blocked. All the threads got blocked on module "linelog", which we can see in the logs:
Wed Jun 22 11:57:11 2016 : Error: (1774170) Ignoring duplicate packet from client *** port 21687 - ID: 186 due to unfinished request in component post-auth module linelog
That issue was fixed in the v3.0.x branch already.
So I'm suspecting this is related to FreeRADIUS.
Yes.
I've noticed the following commit related to locking (which is configurable for detail, but not linelog):
https://github.com/FreeRADIUS/freeradius-server/commit/dd2a06aa6ba8d6b819712...
Note that I didn't see anything wrong with the code, just noticed the "locking" part which made me suspicious... maybe I'm wrong, but I'd like to get your opinion.
It's related.
Could the locking be responsible for the behaviour we've observed ? Should we patch our linelog to force "locking" to false ?
That may help.
Also, I think FreeRADIUS threads should never get blocked forever when trying to acquire a lock. (if that's what is happening)
While I agree, the problem is that it's difficult to know whether a thread is blocked due to a lock, or just busy. And you can't just signal a thread which is in a lock, the code will just retry the lock. And you can't cancel the thread, because it then leaks all memory which the thread was using. You can't just say "software should work perfectly no matter what". Things go wrong, and sometimes they just can't be fixed. Alan DeKok.
Thanks for the quick answer :) We'll roll back the 3.0.11 upgrade, and then upgrade to the 3.0.x HEAD. Regards, Nicolas. -----Message d'origine----- De : Freeradius-Users [mailto:freeradius-users-bounces+nicolas.chaigneau=capgemini.com@lists.freeradius.org] De la part de Alan DeKok Envoyé : mercredi 22 juin 2016 15:54 À : FreeRadius users mailing list Objet : Re: 3.0.11 - all threads blocked in "linelog" On Jun 22, 2016, at 9:34 AM, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
We've installed on production yesterday FreeRADIUS version 3.0.11 (upgraded from 3.0.8).
Today we've noticed that the server got blocked. All the threads got blocked on module "linelog", which we can see in the logs:
Wed Jun 22 11:57:11 2016 : Error: (1774170) Ignoring duplicate packet from client *** port 21687 - ID: 186 due to unfinished request in component post-auth module linelog
That issue was fixed in the v3.0.x branch already.
So I'm suspecting this is related to FreeRADIUS.
Yes.
I've noticed the following commit related to locking (which is configurable for detail, but not linelog):
https://github.com/FreeRADIUS/freeradius-server/commit/dd2a06aa6ba8d6b819712...
Note that I didn't see anything wrong with the code, just noticed the "locking" part which made me suspicious... maybe I'm wrong, but I'd like to get your opinion.
It's related.
Could the locking be responsible for the behaviour we've observed ? Should we patch our linelog to force "locking" to false ?
That may help.
Also, I think FreeRADIUS threads should never get blocked forever when trying to acquire a lock. (if that's what is happening)
While I agree, the problem is that it's difficult to know whether a thread is blocked due to a lock, or just busy. And you can't just signal a thread which is in a lock, the code will just retry the lock. And you can't cancel the thread, because it then leaks all memory which the thread was using. You can't just say "software should work perfectly no matter what". Things go wrong, and sometimes they just can't be fixed. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Hello again, We've not rolled back yet. The issue has occurred a second time, but nothing more since then. I'm currently trying to reproduce the issue on our test lab with FreeRADIUS 3.0.8 (so I can check it doesn't occur anymore with the 3.0.x HEAD), but so far without success. (even with a heavy load, having linelog write in many different files...) Do you have a test case which triggers the issue, that you could share ? I've noticed the Changelog entry has been added on February 18, 2016. There are several commits the day before, I assume one of them did fix the issue but I'm not sure which... could you specify which one I should look at ? Thanks for your help. Regards, Nicolas.
On Jun 22, 2016, at 9:34 AM, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
We've installed on production yesterday FreeRADIUS version 3.0.11 (upgraded from 3.0.8).
Today we've noticed that the server got blocked. All the threads got blocked on module "linelog", which we can see in the logs:
Wed Jun 22 11:57:11 2016 : Error: (1774170) Ignoring duplicate packet from client *** port 21687 - ID: 186 due to unfinished request in component post-auth module linelog
That issue was fixed in the v3.0.x branch already.
So I'm suspecting this is related to FreeRADIUS.
Yes.
I've noticed the following commit related to locking (which is configurable for detail, but not linelog):
https://github.com/FreeRADIUS/freeradius-server/commit/dd2a06aa6ba8d6b819712...
Note that I didn't see anything wrong with the code, just noticed the "locking" part which made me suspicious... maybe I'm wrong, but I'd like to get your opinion.
It's related.
Could the locking be responsible for the behaviour we've observed ? Should we patch our linelog to force "locking" to false ?
That may help.
Also, I think FreeRADIUS threads should never get blocked forever when trying to acquire a lock. (if that's what is happening)
While I agree, the problem is that it's difficult to know whether a thread is blocked due to a lock, or just busy. And you can't just signal a thread which is in a lock, the code will just retry the lock. And you can't cancel the thread, because it then leaks all memory which the thread was using.
You can't just say "software should work perfectly no matter what". Things go wrong, and sometimes they just can't be fixed.
Alan DeKok.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Hello again,
We've not rolled back yet. The issue has occurred a second time, but nothing more since then.
I'm currently trying to reproduce the issue on our test lab with FreeRADIUS 3.0.8 (so I can check it doesn't occur anymore with the 3.0.x HEAD), but so far without success.
I meant 3.0.11. There is no problem with 3.0.8 ! :)
(even with a heavy load, having linelog write in many different files...)
Do you have a test case which triggers the issue, that you could share ?
I've noticed the Changelog entry has been added on February 18, 2016. There are several commits the day before, I assume one of them did fix the issue but I'm not sure which... could you specify which one I should look at ?
Thanks for your help.
Regards, Nicolas.
On Jun 22, 2016, at 9:34 AM, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
We've installed on production yesterday FreeRADIUS version 3.0.11 (upgraded from 3.0.8).
Today we've noticed that the server got blocked. All the threads got blocked on module "linelog", which we can see in the logs:
Wed Jun 22 11:57:11 2016 : Error: (1774170) Ignoring duplicate packet from client *** port 21687 - ID: 186 due to unfinished request in component post-auth module linelog
That issue was fixed in the v3.0.x branch already.
So I'm suspecting this is related to FreeRADIUS.
Yes.
I've noticed the following commit related to locking (which is configurable for detail, but not linelog):
https://github.com/FreeRADIUS/freeradius-server/commit/dd2a06aa6ba8d6b819712...
Note that I didn't see anything wrong with the code, just noticed the "locking" part which made me suspicious... maybe I'm wrong, but I'd like to get your opinion.
It's related.
Could the locking be responsible for the behaviour we've observed ? Should we patch our linelog to force "locking" to false ?
That may help.
Also, I think FreeRADIUS threads should never get blocked forever when trying to acquire a lock. (if that's what is happening)
While I agree, the problem is that it's difficult to know whether a thread is blocked due to a lock, or just busy. And you can't just signal a thread which is in a lock, the code will just retry the lock. And you can't cancel the thread, because it then leaks all memory which the thread was using.
You can't just say "software should work perfectly no matter what". Things go wrong, and sometimes they just can't be fixed.
Alan DeKok.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
On Jun 23, 2016, at 4:40 AM, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
I'm currently trying to reproduce the issue on our test lab with FreeRADIUS 3.0.8 (so I can check it doesn't occur anymore with the 3.0.x HEAD), but so far without success. (even with a heavy load, having linelog write in many different files...)
OK...
Do you have a test case which triggers the issue, that you could share ?
No, sorry. Just reports, and a close reading of the code.
I've noticed the Changelog entry has been added on February 18, 2016. There are several commits the day before, I assume one of them did fix the issue but I'm not sure which... could you specify which one I should look at ?
I don't see why it's relevant. v3.0.x head has a number of fixes over 3.0.11, and it's just not worth it to re-visit all of those patches. If v3.0.x head works, then it's fine. Alan DeKok.
On Jun 23, 2016, at 4:40 AM, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
I'm currently trying to reproduce the issue on our test lab with FreeRADIUS 3.0.8 (so I can check it doesn't occur anymore with the 3.0.x HEAD), but so far without success. (even with a heavy load, having linelog write in many different files...)
OK...
Do you have a test case which triggers the issue, that you could share ?
No, sorry. Just reports, and a close reading of the code.
I've noticed the Changelog entry has been added on February 18, 2016. There are several commits the day before, I assume one of them did fix the issue but I'm not sure which... could you specify which one I should look at ?
I don't see why it's relevant. v3.0.x head has a number of fixes over 3.0.11, and it's just not worth it to re-visit all of those patches.
If v3.0.x head works, then it's fine.
Yes, of course. But my concern is that I'm unable to guarantee to our customer that the issue is fixed in 3.0.x, because I can't reproduce the issue in our test lab. So I can't check that it does not happen anymore in 3.0.x... Did you get feedback of people having experienced this issue previously, and reporting that it does not happen anymore ? This would be reassuring :) Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
On Jun 23, 2016, at 9:42 AM, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
But my concern is that I'm unable to guarantee to our customer that the issue is fixed in 3.0.x, because I can't reproduce the issue in our test lab. So I can't check that it does not happen anymore in 3.0.x...
Well, that's the issue with open source software. There just isn't time / money to write test cases for everything.
Did you get feedback of people having experienced this issue previously, and reporting that it does not happen anymore ? This would be reassuring :)
That's what I recall. Alan DeKok.
On Jun 23, 2016, at 9:42 AM, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
But my concern is that I'm unable to guarantee to our customer that the issue is fixed in 3.0.x, because I can't reproduce the issue in our test lab. So I can't check that it does not happen anymore in 3.0.x...
Well, that's the issue with open source software. There just isn't time / money to write test cases for everything.
Did you get feedback of people having experienced this issue previously, and reporting that it does not happen anymore ? This would be reassuring :)
That's what I recall.
Alan DeKok.
Here's some feedback that may be useful (I could not find any in the mailing archives or on GitHub). FreeRADIUS 3.0.11 got blocked three times (requiring a restart) with this issue within 24 hours (after that it was rolled back to 3.0.8). After installing 3.0.x HEAD (18cc48e2d8fcd533e06eefaa5d81d4a96d01532e), it did not happen again. So I confirm that the issue is indeed fixed. So, a word of advice, if you're using the linelog module and considering deploying FreeRADIUS 3.0.11 on production: *don't*. Upgrade to the 3.0.x HEAD. Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Hi,
Did you get feedback of people having experienced this issue previously, and reporting that it does not happen anymore ? This would be reassuring :)
look in the mailing list archives and on the github issues archive for freradius, the fix was fairly recent and I'm sure the submitter of the bug (using same error message as you had) responded... alan
Hi,
Did you get feedback of people having experienced this issue previously, and reporting that it does not happen anymore ? This would be reassuring :)
look in the mailing list archives and on the github issues archive for freradius, the fix was fairly recent and I'm sure the submitter of the bug (using same error message as you had) responded...
alan
Good suggestion. Unfortunately, I could not find anything related, either on the github issues, or in the users and devel list archives :/ Thanks anyway! This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Chaigneau, Nicolas -
jon Yu -
Matthew Newton