radiusd halts when LDAP bind fails.
Hi list. I am trying to troubleshoot my radiusd occasionally halts when failing to bind with the LDAP server. I would prefer it to maybe wait a minute and restart rather than halting. Is this usual behavior? The wiki for rlm_ldap says: set the uses, lifetime and idle_timeout settings in the pool section of the LDAP module to zero But I have already set this value. I realize this means the server can't contact the LDAP server to do the auth, but I would prefer the service to be more resilient if possible. Preferably without having to do some cron or nagios scripting magic. (I'm open to it, but I wonder if there's a native handler for this?) Usually LDAP and radiusd are fine even very shortly after halting. https://directory.uark.edu/people/sgardne Senior Network Engineer University of Arkansas, ITS-NET
Version? With 3.1.x and 4.x this is all done with connection pool handler this if you have multiple ldap servers the daemon knows the state of each and therefore with eg redundant load balance pool you can work with ldap: handler and get required response. If there AREN'T any handlers available then you have issues.... a quick unlang trip to the world of 'fail' decisions would then be in order alan
I'm on version 3.0.4. Can you be more specific about the unlang solution? https://directory.uark.edu/people/sgardne Senior Network Engineer University of Arkansas, ITS-NET ________________________________ From: Alan Buxey <A.L.M.Buxey@lboro.ac.uk> Sent: Tuesday, September 27, 2016 3:43 PM To: FreeRadius users mailing list; Scott McLane Gardner Subject: Re: radiusd halts when LDAP bind fails. Version? With 3.1.x and 4.x this is all done with connection pool handler this if you have multiple ldap servers the daemon knows the state of each and therefore with eg redundant load balance pool you can work with ldap: handler and get required response. If there AREN'T any handlers available then you have issues.... a quick unlang trip to the world of 'fail' decisions would then be in order alan
On Sep 27, 2016, at 4:14 PM, Scott McLane Gardner <sgardne@uark.edu> wrote:
Hi list. I am trying to troubleshoot my radiusd occasionally halts when failing to bind with the LDAP server. I would prefer it to maybe wait a minute and restart rather than halting. Is this usual behaviour?
If you're using 3.0.4, upgrade. We've put a LOT of fixes in. I'll be releasing 3.0.12 tomorrow (yes, finally), which should help.
The wiki for rlm_ldap says:
set the uses, lifetime and idle_timeout settings in the pool section of the LDAP module to zero
But I have already set this value. I realize this means the server can't contact the LDAP server to do the auth, but I would prefer the service to be more resilient if possible.
What, exactly, do you want the server to do if LDAP is down? You can configure "unlang" to do something else if LDAP fails. See "man unlang", and look for "redundant".
Preferably without having to do some cron or nagios scripting magic. (I'm open to it, but I wonder if there's a native handler for this?) Usually LDAP and radiusd are fine even very shortly after halting.
The short answer is "don't take your database down while RADIUS is running". If LDAP is a critical component for RADIUS, ensure that LDAP is running. Always. Anything else is just a work-around. Nothing beats keeping LDAP up and operating. Alan DeKok.
Thank you. I found a workaround that works for me. Since we're using systemd, I told the service "Restart=always". This works for me for now. I will definitely look into upgrading, but we like to stay on whatever version the RHEL repo's provide.
On Sep 27, 2016, at 5:23 PM, Scott McLane Gardner <sgardne@uark.edu> wrote:
Thank you. I found a workaround that works for me. Since we're using systemd, I told the service "Restart=always". This works for me for now. I will definitely look into upgrading, but we like to stay on whatever version the RHEL repo's provide.
I wish people would complain to RedHat when their 3 year-old version of the server fails. As it stands now, you're paying RedHat for support, and are getting no support. You then ask *us* for support, and we help you, without getting paid. This should be a lesson that RH is bad, and you should upgrade to a version of the server that *we* support. Because we support you. RedHat doesn't. Alan DeKok.
Alan give me this same advice when I had problems with Redhat, LDAP and v3.0.4 back in May. I decided as we pay for support to go the correct route and ask RH to upgrade their package to 3.0.11 and put our deployment project on hold. It has been a busy summer so we probably would not have progressed too much anyway. Updating to 3.0.11 looks a long way off, perhaps more than a year away. If they do go with that version it is not likely to be the latest by the time they deploy. Although they have recently provided me with a test patched version of v3.0.4 which has fixed my particular issue it has been a long process and who knows what other bugs are lurking in there? Meanwhile I tried compiling my own version of 3.0.11, building it as a RPM package so it would nicely slot in, in the same way as the official release. It was very quick and simple to do. The following two link proved very useful during this process http://wiki.freeradius.org/guide/Red-Hat-FAQ#How-to-build-an-SRPM Download SPEC file and latest source from: http://koji.fedoraproject.org/koji/packageinfo?packageID=298 You need the src.rpm package No hint of any errors, it all seems to work brilliantly. While it is our policy to use RHEL supplied packages where ever possible, I can not think of any good reason not to continue compiling my own. When you can compile and deploy in 10 minutes and receive help here or log a case with RHEL and wait months, it is an easy decision. Dave On 27/09/16 22:29, Alan DeKok wrote:
On Sep 27, 2016, at 5:23 PM, Scott McLane Gardner <sgardne@uark.edu> wrote:
Thank you. I found a workaround that works for me. Since we're using systemd, I told the service "Restart=always". This works for me for now. I will definitely look into upgrading, but we like to stay on whatever version the RHEL repo's provide.
I wish people would complain to RedHat when their 3 year-old version of the server fails. As it stands now, you're paying RedHat for support, and are getting no support. You then ask *us* for support, and we help you, without getting paid.
This should be a lesson that RH is bad, and you should upgrade to a version of the server that *we* support. Because we support you. RedHat doesn't.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Tue, Oct 04, 2016 at 11:16:32AM +0100, David Hartburn wrote:
While it is our policy to use RHEL supplied packages where ever possible, I can not think of any good reason not to continue compiling my own. When you can compile and deploy in 10 minutes and receive help here or log a case with RHEL and wait months, it is an easy decision.
Probably also a good reminder that there is also official paid FreeRADIUS support from NetworkRADIUS. I still don't personally understand what paid "support" means in the context of Linux distributions. I've certainly never heard anything good apart from keeping management happy that the software is "supported". Maybe it's just my experience is limited. 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>
Hi,
While it is our policy to use RHEL supplied packages where ever possible, I can not think of any good reason not to continue compiling my own. When you can compile and deploy in 10 minutes and receive help here or log a case with RHEL and wait months, it is an easy decision.
;-) its the official code, compiled in the RedHat way, with RedHat locations and scripts. but this is why I prefer CentOS.... alan
its the official code, compiled in the RedHat way, with RedHat locations and scripts.
but this is why I prefer CentOS....
And officially CentOS follows RedHat. But yes, using the RHEL .SPEC file and applying it to a newer version of FR usually does the trick. :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
participants (7)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan Buxey
-
Alan DeKok -
David Hartburn -
Matthew Newton -
Scott McLane Gardner -
Stefan Paetow