I have just started upgraded from 3.0.15 to 3.0.16 (the latter being installed directly from http://packages.networkradius.com/centos/7/repo/) I now cannot start up the daemon and in debug mode it fails : radiusd -X ... # Instantiating module "eduroammschap" from file /etc/raddb/mods-enabled/eduroammschap /etc/raddb/mods-enabled/eduroammschap[10]: 'winbind' auth not enabled at compiled time /etc/raddb/mods-enabled/eduroammschap[10]: Instantiation failed for module "eduroammschap" My eduroammschap module is configured to use a winbind handle rather than a call to ntlm_auth, as recommend by Matthew Newton a while ago. [jg4461@radius-dev ~]$ cat /etc/raddb/mods-enabled/eduroammschap | grep -v '#' mschap eduroammschap { winbind_username = "%{%{Stripped-User-Name}:-%{eduroammschap:User-Name}}" winbind_domain = "%{eduroammschap:NT-Domain}" pool { start = ${thread[pool].start_servers} min = ${thread[pool].min_spare_servers} max = ${thread[pool].max_servers} spare = ${thread[pool].max_spare_servers} uses = 0 retry_delay = 30 lifetime = 86400 cleanup_interval = 300 idle_timeout = 600 } passchange { } allow_retry = no retry_msg = "Verify username and re-enter your password" } I've been building the RPM myself from the official tarball + spec file up until now, but is the official RPM built differently? Thanks, Jonathan
Hi As the feature isn't there then I guess so, yes. Probably related to the specific extras needed for winbind support to be compiled in. Matthew, if this is the case then can the offices build please support winbind asap? ;) alan On 25 Jan 2018 12:44 pm, "Jonathan Gazeley" <jonathan.gazeley@bristol.ac.uk> wrote:
I have just started upgraded from 3.0.15 to 3.0.16 (the latter being installed directly from http://packages.networkradius.com/centos/7/repo/)
I now cannot start up the daemon and in debug mode it fails :
radiusd -X ... # Instantiating module "eduroammschap" from file /etc/raddb/mods-enabled/eduroammschap /etc/raddb/mods-enabled/eduroammschap[10]: 'winbind' auth not enabled at compiled time /etc/raddb/mods-enabled/eduroammschap[10]: Instantiation failed for module "eduroammschap"
My eduroammschap module is configured to use a winbind handle rather than a call to ntlm_auth, as recommend by Matthew Newton a while ago.
[jg4461@radius-dev ~]$ cat /etc/raddb/mods-enabled/eduroammschap | grep -v '#' mschap eduroammschap { winbind_username = "%{%{Stripped-User-Name}:-%{ed uroammschap:User-Name}}" winbind_domain = "%{eduroammschap:NT-Domain}" pool { start = ${thread[pool].start_servers} min = ${thread[pool].min_spare_servers} max = ${thread[pool].max_servers} spare = ${thread[pool].max_spare_servers} uses = 0 retry_delay = 30 lifetime = 86400 cleanup_interval = 300 idle_timeout = 600 } passchange { } allow_retry = no retry_msg = "Verify username and re-enter your password" }
I've been building the RPM myself from the official tarball + spec file up until now, but is the official RPM built differently?
Thanks, Jonathan
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list /users.html
On Thu, 2018-01-25 at 13:00 +0000, Alan Buxey wrote:
As the feature isn't there then I guess so, yes. Probably related to the specific extras needed for winbind support to be compiled in. Matthew, if this is the case then can the offices build please support winbind asap? ;)
Investigating... -- Matthew
On 25/01/18 13:02, Matthew Newton wrote:
On Thu, 2018-01-25 at 13:00 +0000, Alan Buxey wrote:
As the feature isn't there then I guess so, yes. Probably related to the specific extras needed for winbind support to be compiled in. Matthew, if this is the case then can the offices build please support winbind asap? ;) Investigating...
Any progress on this? I also noticed that since upgrading to the official 3.0.16 RPM, radiusd does not survive a reboot and fails with: [jg4461@radius-jg4461 ~]$ sudo radiusd -X ... radiusd: #### Opening IP addresses and Ports #### listen { type = "control" listen { socket = "/var/run/radiusd/radiusd.sock" uid = "radiusd" gid = "radiusd" mode = "rw" peercred = yes } Failed creating control socket "/var/run/radiusd/radiusd.sock": Failed binding to /var/run/radiusd/radiusd.sock: No such file or directory The path and config are the same as our home-built 3.0.15 so there could be a problem with the packaging process and the way it creates directories. We don't do anything funky with the default paths in our installation. We've had to roll back to our known-good 3.0.15 for now but I'm happy to prod around at my dev system if that helps. Thanks, Jonathan
On 30/01/18 13:49, Jonathan Gazeley wrote:
On 25/01/18 13:02, Matthew Newton wrote:
On Thu, 2018-01-25 at 13:00 +0000, Alan Buxey wrote:
As the feature isn't there then I guess so, yes. Probably related to the specific extras needed for winbind support to be compiled in. Matthew, if this is the case then can the offices build please support winbind asap? ;) Investigating...
Any progress on this?
I also noticed that since upgrading to the official 3.0.16 RPM, radiusd does not survive a reboot and fails with:
[jg4461@radius-jg4461 ~]$ sudo radiusd -X ...
radiusd: #### Opening IP addresses and Ports #### listen { type = "control" listen { socket = "/var/run/radiusd/radiusd.sock" uid = "radiusd" gid = "radiusd" mode = "rw" peercred = yes } Failed creating control socket "/var/run/radiusd/radiusd.sock": Failed binding to /var/run/radiusd/radiusd.sock: No such file or directory
The path and config are the same as our home-built 3.0.15 so there could be a problem with the packaging process and the way it creates directories. We don't do anything funky with the default paths in our installation.
We've had to roll back to our known-good 3.0.15 for now but I'm happy to prod around at my dev system if that helps.
Thanks, Jonathan
Do you run this by any chance on AWS EC2 instance? Cause if yes AWS seems to be removing the custom directories from /var/run. Regards, Krzysztof
On 30/01/18 13:15, Krzysztof Grobelak wrote:
Do you run this by any chance on AWS EC2 instance? Cause if yes AWS seems to be removing the custom directories from /var/run.
No, this is a stock CentOS 7 system installed locally on VMware. I think we came to lose this directory by removing the 3.0.15 RPM, taking the directory with it, and then installing 3.0.16 didn't replace it.
Yes, need to check the paths created and ensure the service and scripts are using the right place and there isn't a discrepency alan On 30 Jan 2018 1:17 pm, "Jonathan Gazeley" <jonathan.gazeley@bristol.ac.uk> wrote:
On 30/01/18 13:15, Krzysztof Grobelak wrote:
Do you run this by any chance on AWS EC2 instance? Cause if yes AWS seems to be removing the custom directories from /var/run.
No, this is a stock CentOS 7 system installed locally on VMware.
I think we came to lose this directory by removing the 3.0.15 RPM, taking the directory with it, and then installing 3.0.16 didn't replace it.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list /users.html
On Tue, 2018-01-30 at 12:49 +0000, Jonathan Gazeley wrote:
On 25/01/18 13:02, Matthew Newton wrote:
On Thu, 2018-01-25 at 13:00 +0000, Alan Buxey wrote:
As the feature isn't there then I guess so, yes. Probably related to the specific extras needed for winbind support to be compiled in. Matthew, if this is the case then can the offices build please support winbind asap? ;)
Investigating...
Any progress on this?
I did a fix for v4, but haven't pushed to v3 yet. Will have work out if it can make it into the packages, though.
Failed creating control socket "/var/run/radiusd/radiusd.sock": Failed binding to /var/run/radiusd/radiusd.sock: No such file or directory
I'll try and take a look. May not be this week. -- Matthew
Failed creating control socket "/var/run/radiusd/radiusd.sock": Failed binding to /var/run/radiusd/radiusd.sock: No such file or directory
We hit this issue after going to FR3.15. We overcame it by creating /usr/lib/tmpfiles.d/radiusd.conf with the following contents: d /var/run/radiusd 0755 radiusd radiusd – This ensures that the directory /var/run/radiusd is created when the server boots up, and so radiusd can start successfully. Regards, Stuart
participants (5)
-
Alan Buxey -
Jonathan Gazeley -
Krzysztof Grobelak -
Matthew Newton -
Stuart Anderson