> As always, patches are welcome. I'll find some time to work on as many of the things I mentioned as possible.
> That's up to the individual modules. Many do, some don't. Urgh. Makes sense, but urgh anyway. > 0.5 defaults to running as 'root.root', due to the large number of > problems people had with the previous default of 'nobody.nobody' Perhaps it's time to consider a seperate local password database helper application that runs as root, knowing only how to check against the system password database? This could run as a threaded app or as a forking app, depending on the system's libraries abilities, and do the caching itself, etc. The implications of this are that radiusd would need to incorporate a way to talk to this subprocess, and supervise it. The benefits are that the codebase that needs to start and run as root are significantly reduced. The detriment is more complex code, and will be (marginally) slower and consume (marginally) more resources on heavily loaded systems. I'd consider volunteering to write this code, but I am unversed in threadded programming. To take this idea even further, one could make all authentication (or accounting) modules also be subprocesses, allowing a blocking, dying, or otherwise uncooperative module to continue to be used without crashing the core radius daemon. If raw data structures are passed via shared memory, any benefits might be defeated by bad data being passed. By having subprocesses and a well defined tcp or udp (or pipe) based protocol for talking to the subprocesses, it would be possible to do data checking of data returned by the module, and recover from bad modules. Yes, I am assuming that modules may do the wrong thing or behave inappropriately at some point. I think that this is unavoidable unless a very tightly knit core group of developers works on the entire radius daemon and all of the modules. FreeRadius now consists of over 40,000 lines of .c and .h files, and appears to have many contributors. This is great! Unfortunately, though, radius often needs to be a highly available service, and as such, I think every effort needs ot be made in the core of the radius daemon to acheive this goal. Loadable modules defeat this somewhat by being able to operate on the memory and threads of the core daemon directly. By using a TCP or UDP based protocol there is also the possibility of integrating into diverse authentication or accounting systems provided by 3rd parties who may not wish to track the development of the FreeRadius daemon, or even remote authentication protocols without needing to use Radius (the need for such a bizarre beast is questionable when Radius can proxy). All 3rd party vendors would need to do to create support for FreeRadius is use a prototype module that does nothing as a base necessary for their module and build it once for all platforms (or even distribute it as source)... This process could then be supervised by FreeRadius (or something else like daemontools or init). Upgrading FreeRadius would not require a recompile of this module even if internal structures changed. Maybe I'm off on a tangent nobody is interested in, but the thoughts are floating around in my mind since earlier in the day before I had to go into a long meeting. > > and finally: > > -0.4 is a LOT more stable than 0.3, but even quirkier > > Quirkier? How so? Kill -HUP having strange behaviour, most notably, and changes to the behaviour of the rlm_unix module. :) 0.3 didn't need source modifications to work on Solaris with NIS in shadowed mode. > The upcoming 0.5 should be much more stable then 0.4, and much less > quirky. :) I'll bet :) Roy - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
