"authorize" etc. in v3.1

Sam Hartman hartmans at mit.edu
Wed Mar 11 13:46:10 CET 2015

Alan, I've been thinking about this, and trying to come up with
something coherent to say.

First, I have high confidence that were this change implemented, it
would have made it somewhat harder for me to learn FreeRADIUS back when
I started.  (That was about a year before I got involved with moonshot
for an entirely different project).
I was vaguely familiar with RADIUS, certainly knew what an access-accept
and access-request packet were, but had never read RFC 2865.  I did know
where RFC 2865 was if I wanted it.
I was acting as a sysadmin, not a developer with regard to FreeRADIUS at
the time.

That said, as a developer sometimes working on FreeRADIUS, I find the
current config and especially its interactions with the code incredibly
I agree that your proposal would make things easier for developers.

Unfortunately, I also agree with the comments that say you're making
things easier for developers at the expense  of your users.
I think this will be harder for sysadmins.

I've been struggling trying to figure out why in hopes that I could
explain it.

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

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.
You're asking the sysadmins to make the kind of jumps in abstraction
that are important to developers.

Yeah, the best devops people will be able to follow you.
Even they will struggle a bit if they are not developers for your

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.
Programs like Sendmail, Postfix, Bind, etc, allow you to mostly keep the
same conplex configuuration for 5-10 years.
That's really important when I have my sysadmin/devops hat on.

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."


More information about the Freeradius-Devel mailing list