On Mar 16, 2019, at 2:47 AM, Joshua Marshall <j.marshall@arroyo.io> wrote:
Thank you for the speedy reply. We're implementing stuff with FreeRadius and are having to abuse it in a few unorthodox ways. Config files with silent errors or misconfigurations, using what seems to be undocumentd interactions with LDAP to handle passwords securely -- challenges which feel like they're from a bygone era.
If you could provide some actual concrete examples of the above, then I'm sure the issues could be addressed. Having written the majority of the LDAP code I have to say I have no idea what you're talking about regarding "undocumented interactions". There are four methods of authenticating users with LDAP: - Retrieving the password hash with a search operation and comparing the hash with the received password. - Binding to LDAP using a simple bind with the user's plaintext password and using the result of that operation to decide on whether the user should be authenticated or not. - Binding to LDAP with a SASL bind. - Using eDirectory's Universal Password feature to retrieve the cleartext password for the user. All of these are well documented.
Looking at the roadmap, and you've probably had to answer these before, why not switch the codebase to C++ which has wrapped up much of the threading
Last time I checked it didn't have any better support for stack suspension and resumption than C does which is one of the issues which has taken a significant amount of time. When your target is millions of requests in flight simultaneously, stack memory usage, parallelisation, network data path and memory zone alignment, and asynchronous I/O are the main issues you end up hitting. We already offload memory management to libtalloc, eventing to libkqueue and crypto to OpenSSL, and use tens of other auxiliary libraries in the modules.
and modularization work already
Not an actual issue we've faced.
and has a number of good libraries to handle networking?
Not an actual issue we've faced.
Why not use Antlr4 to run your grammars and make start and runtime problems more apparent as well as providing a more robust parsing method?
It doesn't currently have a code generation target for C, and you provided absolutely no compelling reasons to switch the code base to C++.
What we are really feeling over here is a lack of modern behavior and features.
As someone who's done multiple, complex, commercial deployments with FreeRADIUS I disagree. If you don't like the policy language or feel that you'd be more at home writing all your business logic in C++, you can wrap it in a REST API and punt the request processing over to an external process using the REST module. Or you can use the Python, Perl, Mruby or Lua embedded interpreters. The reality is though, that the policy language is sufficient for the vast majority of deployments. What a lot of people miss is that the policy language actually does a pretty excellent job of handling the simple cases, in that it requires the users to have absolutely zero programming knowledge and configuration is done by shuffling module call orders around.
Which isn't just one thing, but an enormous amount of work and polish.
I disagree.
That isn't a thing we could ever just ask for and get -- it iosn't that easy and we know that.
I disagree.
But to know what is OK to ask and what might be possible requires context.
Not sure what you mean here as the context is ambiguous. -Arran