Problem with custom accounting module.
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.
> 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