RedHat FreeRadius reload or restart?
I've been running the RedHat "version" of FreeRADIUS Version 2.1.3 for a few years. Each morning I update the users authorization file and run "service radius reload" for the changes to take affect. I recently patched the system, which updated FreeRADIUS to version 2.1.12. I find now that after reloading, using the same script, it appears to reload successfully but my authentications (through ntlm_auth to an MS AD) begin failing. If I instead use "service radiusd restart", it's fine. Did anything change between versions that would explain this? Oct 5 07:30:02 radserv radiusd[3825]: Login OK: [xxxx] (from client wlc-7 port 0 via TLS tunnel) Oct 5 07:30:02 radserv radiusd[3825]: Login OK: [xxxxx] (from client wlc-7 port 13 cli 6c-c2-6b-98-06-52) Oct 5 07:30:02 radserv radiusd[15741]: Loaded virtual server <default> Oct 5 07:30:02 radserv radiusd[15741]: Loaded virtual server inner-tunnel Oct 5 07:30:02 radserv radiusd[15741]: ... adding new socket proxy address * port 0 Oct 5 07:30:02 radserv radiusd[3825]: Received HUP signal. Oct 5 07:30:02 radserv radiusd[3825]: HUP - Re-reading configuration files Oct 5 07:30:02 radserv radiusd[3825]: HUP - loading modules Oct 5 07:30:02 radserv radiusd[3825]: Module: Reloaded module "radutmp" Oct 5 07:30:02 radserv radiusd[3825]: Module: Reloaded module "suffix" Oct 5 07:30:02 radserv radiusd[3825]: Module: Reloaded module "attr_filter.access_reject" Oct 5 07:30:02 radserv radiusd[3825]: Module: Reloaded module "attr_filter.accounting_response" Oct 5 07:30:02 radserv radiusd[3825]: Module: Reloaded module "detail" Oct 5 07:30:02 radserv radiusd[3825]: Module: Reloaded module "mschap" Oct 5 07:30:02 radserv radiusd[3825]: Module: Reloaded module "pap" Oct 5 07:30:02 radserv radiusd[3825]: Module: Reloaded module "files" Oct 5 07:30:02 radserv radiusd[3825]: Loaded virtual server <default> Oct 5 07:30:02 radserv radiusd[3825]: Loaded virtual server inner-tunnel Oct 5 07:30:04 radserv radiusd[3825]: Login incorrect (mschap: External script says ): [xxxxx] (from client wlc-6 port 0 via TLS tunnel) Oct 5 07:30:04 radserv radiusd[3825]: Login incorrect: [xxxxx] (from client wlc-6 port 13 cli 00-26-08-e6-13-90) Oct 5 07:30:04 radserv radiusd[3825]: Login incorrect (mschap: External script says ): [xxxxx] (from client wlc-7 port 0 via TLS tunnel) Oct 5 07:30:04 radserv radiusd[3825]: Login incorrect: [xxxx] (from client wlc-7 port 13 cli 7c-11-be-c3-20-72) Oct 5 07:30:05 radserv radiusd[3825]: Login incorrect (mschap: External script says ): [xxxxx] (from client wlc-6 port 0 via TLS tunnel) Oct 5 07:30:05 radserv radiusd[3825]: Login incorrect: [xxxxx] (from client wlc-6 port 13 cli 48-60-bc-f4-1d-31) Oct 5 07:30:07 radserv radiusd[3825]: Login incorrect (mschap: External script says ): [xxxxx] (from client wlc-7 port 0 via TLS tunnel) Oct 5 07:30:07 radserv radiusd[3825]: Login incorrect (mschap: External script says ): [xxxxxx] (from client wlc-6 port 0 via TLS tunnel) Oct 5 07:30:07 radserv radiusd[3825]: Login incorrect: [xxxx] (from client wlc-6 port 13 cli 48-60-bc-f4-1d-31) -Mike
On 05/10/12 14:24, Mike Diggins wrote:
I've been running the RedHat "version" of FreeRADIUS Version 2.1.3 for a
Try 2.2.0; this might be a combination of: https://github.com/FreeRADIUS/freeradius-server/commit/3b11ce9a33333d2091209...
few years. Each morning I update the users authorization file and run "service radius reload" for the changes to take affect. I recently patched the system, which updated FreeRADIUS to version 2.1.12. I find now that after reloading, using the same script, it appears to reload successfully but my authentications (through ntlm_auth to an MS AD) begin failing. If I instead use "service radiusd restart", it's fine. Did anything change between versions that would explain this?
Oct 5 07:30:02 radserv radiusd[3825]: Login OK: [xxxx] (from client wlc-7 port 0 via TLS tunnel) Oct 5 07:30:02 radserv radiusd[3825]: Login OK: [xxxxx] (from client wlc-7 port 13 cli 6c-c2-6b-98-06-52) Oct 5 07:30:02 radserv radiusd[15741]: Loaded virtual server <default> Oct 5 07:30:02 radserv radiusd[15741]: Loaded virtual server inner-tunnel Oct 5 07:30:02 radserv radiusd[15741]: ... adding new socket proxy address * port 0 Oct 5 07:30:02 radserv radiusd[3825]: Received HUP signal. Oct 5 07:30:02 radserv radiusd[3825]: HUP - Re-reading configuration files Oct 5 07:30:02 radserv radiusd[3825]: HUP - loading modules Oct 5 07:30:02 radserv radiusd[3825]: Module: Reloaded module "radutmp" Oct 5 07:30:02 radserv radiusd[3825]: Module: Reloaded module "suffix" Oct 5 07:30:02 radserv radiusd[3825]: Module: Reloaded module "attr_filter.access_reject" Oct 5 07:30:02 radserv radiusd[3825]: Module: Reloaded module "attr_filter.accounting_response" Oct 5 07:30:02 radserv radiusd[3825]: Module: Reloaded module "detail" Oct 5 07:30:02 radserv radiusd[3825]: Module: Reloaded module "mschap" Oct 5 07:30:02 radserv radiusd[3825]: Module: Reloaded module "pap" Oct 5 07:30:02 radserv radiusd[3825]: Module: Reloaded module "files" Oct 5 07:30:02 radserv radiusd[3825]: Loaded virtual server <default> Oct 5 07:30:02 radserv radiusd[3825]: Loaded virtual server inner-tunnel Oct 5 07:30:04 radserv radiusd[3825]: Login incorrect (mschap: External script says ): [xxxxx] (from client wlc-6 port 0 via TLS tunnel) Oct 5 07:30:04 radserv radiusd[3825]: Login incorrect: [xxxxx] (from client wlc-6 port 13 cli 00-26-08-e6-13-90) Oct 5 07:30:04 radserv radiusd[3825]: Login incorrect (mschap: External script says ): [xxxxx] (from client wlc-7 port 0 via TLS tunnel) Oct 5 07:30:04 radserv radiusd[3825]: Login incorrect: [xxxx] (from client wlc-7 port 13 cli 7c-11-be-c3-20-72) Oct 5 07:30:05 radserv radiusd[3825]: Login incorrect (mschap: External script says ): [xxxxx] (from client wlc-6 port 0 via TLS tunnel) Oct 5 07:30:05 radserv radiusd[3825]: Login incorrect: [xxxxx] (from client wlc-6 port 13 cli 48-60-bc-f4-1d-31) Oct 5 07:30:07 radserv radiusd[3825]: Login incorrect (mschap: External script says ): [xxxxx] (from client wlc-7 port 0 via TLS tunnel) Oct 5 07:30:07 radserv radiusd[3825]: Login incorrect (mschap: External script says ): [xxxxxx] (from client wlc-6 port 0 via TLS tunnel) Oct 5 07:30:07 radserv radiusd[3825]: Login incorrect: [xxxx] (from client wlc-6 port 13 cli 48-60-bc-f4-1d-31)
-Mike
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 05/10/12 14:46, Phil Mayers wrote:
On 05/10/12 14:24, Mike Diggins wrote:
I've been running the RedHat "version" of FreeRADIUS Version 2.1.3 for a
Try 2.2.0; this might be a combination of:
Damn stupid mail client. This is probably a combination of: https://github.com/FreeRADIUS/freeradius-server/commit/3b11ce9a33333d2091209... ...and the followup fix: https://github.com/FreeRADIUS/freeradius-server/commit/d3504e1766ae965c2983f... ...which post-dated 2.1.12. So - try 2.2.0
On 10/05/2012 09:46 AM, Phil Mayers wrote:
On 05/10/12 14:24, Mike Diggins wrote:
I've been running the RedHat "version" of FreeRADIUS Version 2.1.3 for a
Try 2.2.0; this might be a combination of:
FWIW, I pushed 2.2.0 to updates testing on Fedora 17 a day or so ago. It's also scheduled to appear in the upcoming Fedora 18. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On 10/05/2012 09:24 AM, Mike Diggins wrote:
I've been running the RedHat "version" of FreeRADIUS Version 2.1.3 for a few years. Each morning I update the users authorization file and run "service radius reload" for the changes to take affect. I recently patched the system, which updated FreeRADIUS to version 2.1.12. I find now that after reloading, using the same script, it appears to reload successfully but my authentications (through ntlm_auth to an MS AD) begin failing. If I instead use "service radiusd restart", it's fine. Did anything change between versions that would explain this?
Nothing changed with respect to how reload operates on Red Hat systems. However I seem to recall some issue with mschap after the server was HUP'ed to reload the config in some versions of FreeRADIUS I don't remember the details of that issue, it's probably in the list archive. Maybe someone else remembers better than I. However, if you use a backend data store (i.e. sql or ldap) to store your user data you won't have to reload your configs, just a suggestion. John -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
participants (3)
-
John Dennis -
Mike Diggins -
Phil Mayers