"authorize" etc. in v3.1

[Alan DeKok]

On Mar 11, 2015, at 8:46 AM, Sam Hartman <hartmans at mit.edu> wrote:
> That said, as a developer sometimes working on FreeRADIUS, I find the
> current config and especially its interactions with the code incredibly
> confusing.

  That’s one of the drivers.  The other is that the current complexity is hard to maintain.  So there are bugs, regressions when one bug is fixed, etc.

> Here's my best shot so far.
> You're focusing on things that coders want to think about: sending
> packets, receiving packets, processing packets.

  Which is largely what’s happening, of course.

> However, that's not what sysadmins want to do.  Sysadmins want to
> authorize and authenticate users.  They want to log
> information/accounting data.  They want to apply policy.
> You're taking the configuration further away from that and focusing it
> more on packet flows.

  Yes.  That may very well be a good thing.

  Many people on the -users list are confused because they “just want to authenticate users”.  They don’t want to know how RADIUS works, and they don’t want to know how FreeRADIUS works.  They invent some bizarre theory as to how it works, and then fight tooth and nail against being educated.  The current scheme doesn’t lend itself to being explained in simple terms.

> You're asking the sysadmins to make the kind of jumps in abstraction
> that are important to developers.

  The way people use RADIUS is *much* more complicated than the way they use DNS, DHCP, SMTP, or nearly any other protocol.  What other piece of software has an extensive policy language, and integrates with Perl, Python, SQL, LDAP, Redis, … ?

  There’s a *reason* it’s complicated.  People want to do complicated things.  And worse, they want to do complicated things without an understanding of it works.  That’s a problem.

> Also, I'd urge you to think about backward compatibility.  Again, in the
> interest of focusing on users' needs rather than developers' needs.
> being able to support configs for large numbers of years is important.

  Sure.  Version 2.2.6 is backwards compatible with previous versions going back 5 years.  That’s fine.

  Version 3 is a major upgrade, and isn’t 100% backwards compatible.  That’s why it’s a major version increment.  But it’s also about 90% backwards compatible with 2.2, which helps a lot.

> Programs like Sendmail, Postfix, Bind, etc, allow you to mostly keep the
> same conplex configuuration for 5-10 years.

  By (a) having tons of funding, (b) being compatible across *minor* versions, and (c) by not allowing complex configurations.

  Postfix has about the same amount of code as FreeRADIUS.  But it’s processing of messages is not nearly as flexible as FreeRADIUS.  It’s more on the order of “there are 3 hooks during the processing of a message, and you can run one of 10 things in each of those hooks”.

  Sendmail is insanely complex.  But it has gone through incompatible upgrades, and has a significant amount of funding behind it.

  Bind, ISC DHCP, etc. have about the same amount of code as FreeRADIUS.  Largely because they re-invent the wheel.  Badly.  ISC has tons of funding, and teams of full-time staff to each product.  They’ve released major version upgrades which are incompatible with older versions.  And the configuration for Bind or DHCP is laughably simple compared to FreeRADIUS.

  So of *course* the software you mentioned is doing better by your metrics.  They have a simpler problem to solve, or money to solve complex problems.

  The issue I’m running into is that people want new features, new functionality, integration with more databases, more performance, etc.  And they’re not willing to fund the development.  And they’re not willing to learn how the software works.  And outside of the ~20 hard-core people on this list, they’re not willing to contribute code, bug reports, etc.

  So… how do I make the software better?  BY making it simpler for *me* to continue developing it.

> Updating the default configuration is fine.
> However every time I see another config option deprecated/another
> perfectly valid existing config suddenly become invalid, I think "Ah,
> there FreeRADIUS goes hating its users again."

  I can’t think of the last time we deprecated something in 2.2.x.  It’s backwards compatible going back to 2.0, from what I recall.

  We did deprecate a lot in 3.0.  Because the old way was confusing the users, and hard to maintain for us.  The new config and code is easier to understand, and easier to maintain.  But we’re not done yet.

  I hear you.  As I said already, the plan is to allow the current configurations to continue working.  BUT to allow more complex configurations to also work, AND having those complex configurations simple to understand.  I think that addresses your concerns.

  The only downside is the attitude of “don’t change anything”.  Well, if you don’t want change, pick a version, and stick with it.  Don’t upgrade.  Don’t get new features.  Your configuration will be compatible for as long as you don’t upgrade.

  Alan DeKok.