Problem with custom accounting module.

Bill Schoolfield bill at billmax.com
Tue Apr 22 18:34:29 CEST 2014



On 4/22/2014 11:14 AM, Alan DeKok wrote:
> Bill Schoolfield wrote:
>> The ability for a software vendor to use an out of the box (OS supplied
>> package) FreeRadius server is a big deal. It means we don't have to
>> distribute FreeRadius and maintain a bunch of stuff.
>
>    That's fine.
>
>> Why have modules at all (aside from the shared library benefits) if to
>> use custom ones, you have to provide the whole package?
>
>    That's not what I said.  You need only supply your module.  But it
> MUST match the package used by the vendor.
>
>> As for the wisdom of changing a structure's "structure" based on a debug
>> switch... I've never seen this.
>
>    <shrug>  I've seen it lots.
>
>> Finding the error for me at least took
>> an embarrassing long length of time.
>
>    If you had built the module using the method I recommend, you would
> never have seen the problem.
>
>> I'm not developing FreeRadius so I tread lightly saying this, but I
>> think the deployment pattern I described should not necessarily be
>> discouraged or prevented.
>
>    If you want a module to be compatible with a vendors package, you MUST
> build it with the same options, tools, etc. as the vendors package.
> That is the ONLY way you can guarantee it works.
>

Understood.

>    I've rarely seen people ship "bare" dynamic libraries for third-party
> packages.  They usually ship a package, which is compatible with the
> vendors system.
>
>    If you really care about compatibility, send us your module.  We'll
> include it in the next release.

Wow, nice gesture. I'd love that but not an option, unless we provide 
the source to our library and that of course is proprietary.

>
>    Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
>


More information about the Freeradius-Devel mailing list