segmentation fault freeradius 2.1.7 using rlm_sql

[Alan DeKok]

John Dennis wrote:
> FreeRADIUS has some problems which other projects have avoided.

  Sure.  The reasons are pretty straightforward.  The contribution from
the community is small.  The people who contribute get few rewards, and
lots of arrows.  The people who complain don't contribute.

  It's really that simple.  All of the rest you posted below is
engineering process.  It's all nice.  But it requires someone to do the
work.  And I don't see anyone volunteering.  The few times I've asked,
everyone says they're busy.

> * FreeRADIUS has no notion of a "stable release". Many projects maintain
> both a stable production version and a current version (which is not the
> same as the "tip", rather it's tagged in source code control, tested and
> released just like any other release, it's just got a few more features
> than the rock solid stable release). The rock solid stable release has
> been field proven, should have the absolute confidence of system
> administrators and be viable for multiple years (in other words you can
> install it and be confident once it's put in production you're good to
> go for several years. Occasionally a stable release needs a bug or
> security fix. When that occurs the stable release is surgically modified
> to fix exactly that one issue, it's minor version number is bumped.
> System administrators are never told to upgrade to a significant new
> version because of the bug/security issue, instead they reinstall a
> patched version of "stable".

  Great.  That's done with 1.1.x.  Who's going to do it for 2.x?

> * FreeRADIUS has way too much churn for a critical system service. Think
> about other system services, how often do you see kerberos, bind,
> iptables, pam, MySQL, etc. going through significant revisions? Are the
> administrators of those services constantly being told to upgrade the
> service because of the bug/feature du jour?

  Git is useful here.  The difference between 2.1.10 and 2.1.11 is 4K
LoC added, ~1K deleted, out of more than 80K.  That's less than 5%.  And
a lot of that is adding "extern C" headers to files.

> * The QE component of FreeRADIUS has proven to be inadequate. I know
> Alan runs a set of tests and he calls for testing prior to a new
> release. But we've seen the amount of testing which actually occurs is
> inadequate because releases have gone out with significant problems and
> those releases have gotten pushed into production. I think part of the
> problem is the frequent release schedule (measured in months) and the
> lack of a coordinated beta testing program. Releases should not occur
> until after they've successfully navigated a beta program.

  Great.  Help.

> I humbly would suggest the following:
> 
> * Create and maintain a "stable" version.

  Perhaps.  I plan on releasing 3.0 within a few months.  The 2.1.x
branch can then be re-labeled 2.2.0.  I can be marked "stable", if
someone is willing to put work into maintaining it.

  And we're already doing this for 1.1.x.  It works, it's shipped in
many "legacy" packages.  It hasn't changed in years.

> * Organize a rigorous beta test program.

  <crickets>

  Right.  Lots of volunteers there.

> * Slow down the release schedule, avoid the temptation to cut a new
> release because of minor new features. If production servers can't run
> successfully without a feature that's an indication the prior release
> was too hasty. Critical bug fixes should occur in the release branch and
> the release branch re-released. The release interval for a system
> service like FreeRADIUS should be measured in years, not months or weeks.

  Absolutely not.  There are a TON of changes being made to RADIUS.
It's simply not feasible to have release intervals of years.

  And let me remind you: we DO have a "stable" release with a release
interval of years.  What happens?  People don't even use the most recent
version of that (1.1.8).  Instead, they use an older version (1.1.3),
because that's the only thing that THEIR OS VENDOR SUPPORTS.

  Hint?

  Then they ask for help here.  It's ridiculous.

  I'll bet RH is making more money off of FreeRADIUS than I am.  So if
you want a stable release, contribute.  Otherwise, I'm tired of the
complaints.

  You've sent me email off-list complaining that YOUR CUSTOMERS are
upset about the quality of the FR documentation.  Fine.  When I asked if
you were willing to pay for better documentation, you didn't respond.

  And again here, you've posted a long message detailing work that
*other people* are supposed to do.  There is a conspicuous failure to
volunteer for ANY of the things on your list.  So... thanks for the
contribution.  Doing what you want (for free) is not really high on my
list of priorities.

  I'll do what I can to make FR better.  But that's only because I want
to, and I'm spending *my* hard-earned money to do so.

  i.e. I'm putting MY money where my mouth is.  I invite others to do
the same.

  Alan DeKok.