segmentation fault freeradius 2.1.7 using rlm_sql

[Alan Buxey]

Hi,

> > * FreeRADIUS has no notion of a "stable release". Many projects maintain

'stable' or 'stale'


if you go for the 'stable' release of most daemons you will not
have the ability to do certain things, the latest version will have those
abilities. 

in the FR case, the most 'tested' version is often an older version...bugs
come to light, new features requested etc are in the newer version, not
backported down to older versions. it makes sense to do it that way

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

rubbish. sorry, but the number of times I've had to upgrade eg BIND, ISC DHCPD,
apache etc from 'stable' release due to a bug, or that months new vulnerability.

i dont know of ANY server daemon that could be installed and left online for years -
even if there was such a mythical beast, the server it runs on needs to be reloaded
at least 4 times a year due to kernel/OS vulnerabilities too ;-)

> > security fix. When that occurs the stable release is surgically modified
> > to fix exactly that one issue, it's minor version number is bumped.

thats the wrong way to go as you spend the effort putting features way back
down in the tree - and often reverting behaviour already known or fixed. 

ideally you have a stable version and a test-devel version - which there has been
before - however, who runs what?  often people run safe and wont run a test-devel
version where its needed - and only when the version is 'released' do they then run
it and find a bug/issue that no-one else uncovered - this has happened several
times this year with 2.1.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?

all the time. BIND and MySQL in particular. I'd add OpenSSH and Apache
to the list of daemons always being upgraded.

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

I , for one, love having frequent releases of the server - it means we get
new features. functions and fixes of behaviour rapidly in what has become
a very agile area of network access.

if you have a less frequent release you'll have a product with as much functionality
as cisco ACS of MS NPS - ie bare and basic. dull and almost useless.

of course, this depends on your market - if you are a dial-in user or run an
ISP you might want the basic functions. there. done. free. dealt with.

if, however, you are using it in an enterprise network environment and are
looking at 802.1X with SoH, new rapid policy making, advanced external auditing
using custom logging and maybe even wanting to use other RADIUS capabilities,
CUI, CoA, linked to that months common backend - or wanting to use enhanced
remote access systems like 'moonshot' then you need an agile project - FreeRADIUS
is agile enough

> > * Organize a rigorous beta test program.

using what and who?  most issues are found in demanding environments that cannot
be modelled by some simulation - this isnt Apache where you can throw a tool
at it. there isnt a 'generic config' that all people use. I'll find a bug in
postgres that noone else has found because they all use another DB or flatfile..
or if they do use postgres they wont be throwing particular things at it (like
storing a local copy of an accounting packet that wasnt received at the 
remote accounting server and couldnt be stored on sql-relay due to no disk space....)
- thats just an example by the way!  - by changing to 'stable' and having a remote 'test'
release you can pretty much say goodbye to the default presence of leading-tree
testers. i know most people will just take the latest stable.  they may have 'stable'
but they'll whine when they dont have a feature...and when posting to the list i'll
say its in 'testing' and they'll ask when thats coming to 'stable - answer? probably
never to that stable tree because the code changes to enable that feature are vast
and the profiling wont be able to pick out any weird corner cases that might
happen to that stable should the functions be backported. as alan said, 1.1.x is 'stable'
its also damn bare of any flexible functionality ;-)

alan