Hello all, We have written a custom accounting module based on rlm_detail. It is very similar except it pushes the accounting data to another app via an API call. Up until recently it has work fine. Today on a client site it is failing. It seems the "accounting method": static int modulename_accounting(void *instance, REQUEST *request) is getting passed with a request that has at least (I haven't checked further) null request->packet and request->listener addresses. The request is generated via radclient. Does anyone know under what circumstances this can occur? Happy to provide all details/source etc if it will help. The end result is the module either crashes (when referencing request->listener->type or if commented out, the do_detail() call just returns NOOP. Bill
Bill Schoolfield wrote:
We have written a custom accounting module based on rlm_detail. It is very similar except it pushes the accounting data to another app via an API call. Up until recently it has work fine.
I'd suggest looking at rlm_rest in v3. It allows for remote json calls. It's really quite nice.
Today on a client site it is failing. It seems the "accounting method":
static int modulename_accounting(void *instance, REQUEST *request)
is getting passed with a request that has at least (I haven't checked further) null request->packet and request->listener addresses.
That should never happen.
The request is generated via radclient.
Does anyone know under what circumstances this can occur? Happy to provide all details/source etc if it will help.
It only happens when the request is freed, while it's still being processed by a module. That should never happen, either. Alan DeKok.
Thanks Alan. This is from 2.1.12. Still using it because that's the default (rpm) for CentOS. If it were just us I'd look at v3 but I need for this to work w/o too much build/deployment issues for our clients. The request pointer is not null, the items within it are. Could this be a thread issue? How can I debug this further? Bill On 4/17/2014 9:19 PM, Alan DeKok wrote:
Bill Schoolfield wrote:
We have written a custom accounting module based on rlm_detail. It is very similar except it pushes the accounting data to another app via an API call. Up until recently it has work fine.
I'd suggest looking at rlm_rest in v3. It allows for remote json calls. It's really quite nice.
Today on a client site it is failing. It seems the "accounting method":
static int modulename_accounting(void *instance, REQUEST *request)
is getting passed with a request that has at least (I haven't checked further) null request->packet and request->listener addresses.
That should never happen.
The request is generated via radclient.
Does anyone know under what circumstances this can occur? Happy to provide all details/source etc if it will help.
It only happens when the request is freed, while it's still being processed by a module. That should never happen, either.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 18/04/2014 05:03, Bill Schoolfield wrote:
Could this be a thread issue? How can I debug this further?
Why would you bother? If it's a code bug, you will inevitably have to patch and rebuild. Deploying a patched 2.1.12 is madness. Try again on 2.x.x HEAD and see if it's still present. If not, deploy 2.2.4 or 2.2.5 if it's out by then. If it is still present, then debug.
Well, I tried it on 2.2.4 and same thing. I have compared the setup to other sites and I can't see any difference. Here is gdb at the point this function is called:
#0 billmax_accounting (instance=0x8222a88, request=0x82415e0) at rlm_billmax.c:662 #1 0x0806534b in call_modsingle (request=<value optimized out>, component=3, depth=1, entry=0xbffff21c) at modcall.c:305 #2 modcall_recurse (request=<value optimized out>, component=3, depth=1, entry=0xbffff21c) at modcall.c:579 #3 0x080646a7 in modcall_child (request=<value optimized out>, component=<value optimized out>, depth=1, entry=0xbffff210, c=0x8239530, result=0xbffff1dc) at modcall.c:423 #4 0x0806487c in modcall_recurse (request=<value optimized out>, component=3, depth=0, entry=0xbffff210) at modcall.c:628 #5 0x080658a9 in modcall (component=3, c=0x8239570, request=0x82415e0) at modcall.c:877 #6 0x08060e80 in indexed_modcall (comp=3, idx=0, request=0x82415e0) at modules.c:750 #7 0x0806121c in module_accounting (acct_type=0, request=0x82415e0) at modules.c:1617 #8 0x0804e38c in rad_accounting (request=0x82415e0) at acct.c:94 #9 0x08072c75 in radius_handle_request (request=0x82415e0, fun=0x804e2d0 <rad_accounting>) at event.c:3838 #10 0x0806978f in thread_pool_addrequest (request=0x82415e0, fun=0x804e2d0 <rad_accounting>) at threads.c:948 #11 0x08074182 in event_socket_handler (xel=<value optimized out>, fd=18, ctx=0x8240ad0) at event.c:3485 #12 0x00129b12 in fr_event_loop (el=0x823d180) at event.c:415 #13 0x0806f206 in radius_event_process () at event.c:3824 #14 0x080661fe in main (argc=2, argv=0xbffff804) at radiusd.c:488 (gdb) print request $1 = (REQUEST *) 0x82415e0 (gdb) print *request $2 = {magic = 136582416, packet = 0x0, proxy = 0x82416a0, reply = 0x0, proxy_reply = 0x0, config_items = 0x8241748, username = 0x0, password = 0x808fcc0, root = 0x0, data = 0x81d51e0, client = 0x0, thread_id = 1397840998, timestamp = 0, number = 136579792, listener = 0x0, proxy_listener = 0x0, simul_max = 0, simul_count = 0, simul_mpp = 2, options = 136340544, module = 0x8087b0a "accounting", component = 0x53515c66 <Address 0x53515c66 out of bounds>, received = {tv_sec = 351944, tv_usec = 1397840999}, when = { tv_sec = 351944, tv_usec = 1000000}, delay = 1, master_state = 2, child_state = 3, priority = 136582952, ev = 0x0, next_when = {tv_sec = 0, tv_usec = 0}, next_callback = 0x1, in_request_hash = 0, in_proxy_hash = 0, home_server = 0x0, home_pool = 0x0, proxy_when = {tv_sec = 0, tv_usec = 0}, num_proxied_requests = 0, num_proxied_responses = 0, server = 0x0, parent = 0x805eed0, radlog = 0, coa = 0x0, num_coa_requests = 0}
Maybe somehow the configuration is different or the test accounting data is causing this. Again, let me know what data (logs/listings) I need to send that will help identify the problem. Thanks again for your assistance. On 4/18/2014 6:45 AM, Phil Mayers wrote:
On 18/04/2014 05:03, Bill Schoolfield wrote:
Could this be a thread issue? How can I debug this further?
Why would you bother? If it's a code bug, you will inevitably have to patch and rebuild. Deploying a patched 2.1.12 is madness. Try again on 2.x.x HEAD and see if it's still present. If not, deploy 2.2.4 or 2.2.5 if it's out by then. If it is still present, then debug. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Well, I tried it on 2.2.4 and same thing. I have compared the setup to other sites and I can't see any difference. Here is gdb at the point this function is called:
#0 billmax_accounting (instance=0x8222a88, request=0x82415e0) at rlm_billmax.c:662 #1 0x0806534b in call_modsingle (request=<value optimized out>, component=3, depth=1, entry=0xbffff21c) at modcall.c:305 #2 modcall_recurse (request=<value optimized out>, component=3, depth=1, entry=0xbffff21c) at modcall.c:579 #3 0x080646a7 in modcall_child (request=<value optimized out>, component=<value optimized out>, depth=1, entry=0xbffff210, c=0x8239530, result=0xbffff1dc) at modcall.c:423 #4 0x0806487c in modcall_recurse (request=<value optimized out>, component=3, depth=0, entry=0xbffff210) at modcall.c:628 #5 0x080658a9 in modcall (component=3, c=0x8239570, request=0x82415e0) at modcall.c:877 #6 0x08060e80 in indexed_modcall (comp=3, idx=0, request=0x82415e0) at modules.c:750 #7 0x0806121c in module_accounting (acct_type=0, request=0x82415e0) at modules.c:1617 #8 0x0804e38c in rad_accounting (request=0x82415e0) at acct.c:94 #9 0x08072c75 in radius_handle_request (request=0x82415e0, fun=0x804e2d0 <rad_accounting>) at event.c:3838 #10 0x0806978f in thread_pool_addrequest (request=0x82415e0, fun=0x804e2d0 <rad_accounting>) at threads.c:948 #11 0x08074182 in event_socket_handler (xel=<value optimized out>, fd=18, ctx=0x8240ad0) at event.c:3485 #12 0x00129b12 in fr_event_loop (el=0x823d180) at event.c:415 #13 0x0806f206 in radius_event_process () at event.c:3824 #14 0x080661fe in main (argc=2, argv=0xbffff804) at radiusd.c:488 (gdb) print request $1 = (REQUEST *) 0x82415e0 (gdb) print *request $2 = {magic = 136582416, packet = 0x0, proxy = 0x82416a0, reply = 0x0, proxy_reply = 0x0, config_items = 0x8241748, username = 0x0, password = 0x808fcc0, root = 0x0, data = 0x81d51e0, client = 0x0, thread_id = 1397840998, timestamp = 0, number = 136579792, listener = 0x0, proxy_listener = 0x0, simul_max = 0, simul_count = 0, simul_mpp = 2, options = 136340544, module = 0x8087b0a "accounting", component = 0x53515c66 <Address 0x53515c66 out of bounds>, received = {tv_sec = 351944, tv_usec = 1397840999}, when = { tv_sec = 351944, tv_usec = 1000000}, delay = 1, master_state = 2, child_state = 3, priority = 136582952, ev = 0x0, next_when = {tv_sec = 0, tv_usec = 0}, next_callback = 0x1, in_request_hash = 0, in_proxy_hash = 0, home_server = 0x0, home_pool = 0x0, proxy_when = {tv_sec = 0, tv_usec = 0}, num_proxied_requests = 0, num_proxied_responses = 0, server = 0x0, parent = 0x805eed0, radlog = 0, coa = 0x0, num_coa_requests = 0}
Maybe somehow the configuration is different or the test accounting data is causing this. Again, let me know what data (logs/listings) I need to send that will help identify the problem. Thanks again for your assistance. On 4/18/2014 6:45 AM, Phil Mayers wrote:
On 18/04/2014 05:03, Bill Schoolfield wrote:
Could this be a thread issue? How can I debug this further?
Why would you bother? If it's a code bug, you will inevitably have to patch and rebuild. Deploying a patched 2.1.12 is madness. Try again on 2.x.x HEAD and see if it's still present. If not, deploy 2.2.4 or 2.2.5 if it's out by then. If it is still present, then debug. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Well this has turned out to be some sort of linkage/compile issue. On the same server, I can build the shared library for our module from either the source tree from our application or the source tree from freeradius. Building from freeradius works. The other way does not... Best I can tell the same includes and libraries are used. A ldd of both .so files show commonality though our app has many more referenced libraries. I wonder if we've got a namespace collision somewhere. Anybody got a suggestion for where to look? Bill On 4/17/2014 9:19 PM, Alan DeKok wrote:
Bill Schoolfield wrote:
We have written a custom accounting module based on rlm_detail. It is very similar except it pushes the accounting data to another app via an API call. Up until recently it has work fine.
I'd suggest looking at rlm_rest in v3. It allows for remote json calls. It's really quite nice.
Today on a client site it is failing. It seems the "accounting method":
static int modulename_accounting(void *instance, REQUEST *request)
is getting passed with a request that has at least (I haven't checked further) null request->packet and request->listener addresses.
That should never happen.
The request is generated via radclient.
Does anyone know under what circumstances this can occur? Happy to provide all details/source etc if it will help.
It only happens when the request is freed, while it's still being processed by a module. That should never happen, either.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 18/04/2014 21:23, Bill Schoolfield wrote:
Well this has turned out to be some sort of linkage/compile issue. On the same server, I can build the shared library for our module from either the source tree from our application or the source tree from freeradius. Building from freeradius works. The other way does not...
Best I can tell the same includes and libraries are used. A ldd of both .so files show commonality though our app has many more referenced libraries. I wonder if we've got a namespace collision somewhere.
Anybody got a suggestion for where to look?
Hmm. Short of a long tedious trawl with objdump/ldd you could either guess - look at the libs your module pulls in and guess which is likely troublesome - or look at all the libs on your system and try to find any with >1 ABI version present. It could still be something like threading/signals/locking/mutex or similar - it really depends on what libs you're pulling in. Can you describe the module and it's top-level architecture/dependencies?
Basically we took rlm_detail and extended it. In other words we first try to put the data to our application. If that fails then we fall back on the normal detail processing. The library we call is not thread safe so we "marked" our module accordingly. Since my last post I got it to work by re-ordering the link options. However I just tried to repeat this build on yet another box and it fails again. The dependencies in our library are long but not really unusual. Here is what worked: -lfreeradius-radius -L/usr/local/billmax/lib -Wl,-rpath=/usr/local/billmax/lib -lbillmax -lxml2 -ldecNumber -L/usr/lib/mysql -lmysqlclient -lc On 4/18/2014 5:05 PM, Phil Mayers wrote:
On 18/04/2014 21:23, Bill Schoolfield wrote:
Well this has turned out to be some sort of linkage/compile issue. On the same server, I can build the shared library for our module from either the source tree from our application or the source tree from freeradius. Building from freeradius works. The other way does not...
Best I can tell the same includes and libraries are used. A ldd of both .so files show commonality though our app has many more referenced libraries. I wonder if we've got a namespace collision somewhere.
Anybody got a suggestion for where to look?
Hmm. Short of a long tedious trawl with objdump/ldd you could either guess - look at the libs your module pulls in and guess which is likely troublesome - or look at all the libs on your system and try to find any with >1 ABI version present.
It could still be something like threading/signals/locking/mutex or similar - it really depends on what libs you're pulling in. Can you describe the module and it's top-level architecture/dependencies? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Bill Schoolfield wrote:
Well this has turned out to be some sort of linkage/compile issue. On the same server, I can build the shared library for our module from either the source tree from our application or the source tree from freeradius. Building from freeradius works. The other way does not...
It's probably a header issue. Building from within your application probably misses some headers, so the REQUEST structure ends up being a different size.
Best I can tell the same includes and libraries are used. A ldd of both .so files show commonality though our app has many more referenced libraries. I wonder if we've got a namespace collision somewhere.
Anybody got a suggestion for where to look?
Not really. In v2, the modules *might* build outside of the server source. In v3, they will not. Alan DeKok.
On 4/18/2014 7:41 PM, Alan DeKok wrote:
Bill Schoolfield wrote:
Well this has turned out to be some sort of linkage/compile issue. On the same server, I can build the shared library for our module from either the source tree from our application or the source tree from freeradius. Building from freeradius works. The other way does not...
It's probably a header issue. Building from within your application probably misses some headers, so the REQUEST structure ends up being a different size.
Close. Don't know why but not including-DNDEBUG causes the error. What is this define suppose to do? Bill
Best I can tell the same includes and libraries are used. A ldd of both .so files show commonality though our app has many more referenced libraries. I wonder if we've got a namespace collision somewhere.
Anybody got a suggestion for where to look?
Not really. In v2, the modules *might* build outside of the server source. In v3, they will not.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
...and this is probably the culprit (in radiusd.h): struct auth_req { #ifndef NDEBUG uint32_t magic; /* for debugging only */ #endif ... Moral of the story when compiling freeradius source outside of its source tree/environment, make sure this define is consistent for all sources. Bill On 4/18/2014 7:41 PM, Alan DeKok wrote:
Bill Schoolfield wrote:
Well this has turned out to be some sort of linkage/compile issue. On the same server, I can build the shared library for our module from either the source tree from our application or the source tree from freeradius. Building from freeradius works. The other way does not...
It's probably a header issue. Building from within your application probably misses some headers, so the REQUEST structure ends up being a different size.
Best I can tell the same includes and libraries are used. A ldd of both .so files show commonality though our app has many more referenced libraries. I wonder if we've got a namespace collision somewhere.
Anybody got a suggestion for where to look?
Not really. In v2, the modules *might* build outside of the server source. In v3, they will not.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 21 Apr 2014, at 14:52, Bill Schoolfield <bill@billmax.com> wrote:
...and this is probably the culprit (in radiusd.h):
struct auth_req { #ifndef NDEBUG uint32_t magic; /* for debugging only */ #endif ...
Moral of the story when compiling freeradius source outside of its source tree/environment, make sure this define is consistent for all sources.
Yeah i've bitched about this before. NDEBUG should be included in features.h really, but Alan had objections. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
I've stumbled onto this also. Suddenly my server started crashing. So I checked what I added recently. Removed stuff, until there was almost nothing left in the module, but still it crashed (on "request->packet->anything"). And then I noticed someone had changed the build procedure, adding "--enable-developer" to the FreeRADIUS build. (module wasn't built with "-DNDEBUG"). Since several (at least two !) people have had this problem, maybe something could be done. Perhaps adding a public function in FreeRADIUS, which would allow to check if it was built or not with "NDEBUG" ? This would allow a module, upon instantiate, to check that its build is consistent with the server build, and if not complain and return "fail". What do you think ?
On 21 Apr 2014, at 14:52, Bill Schoolfield <bill@billmax.com> wrote:
...and this is probably the culprit (in radiusd.h):
struct auth_req { #ifndef NDEBUG uint32_t magic; /* for debugging only */ #endif ...
Moral of the story when compiling freeradius source outside of its source tree/environment, make sure this define is consistent for all sources.
Yeah i've bitched about this before. NDEBUG should be included in features.h really, but Alan had objections.
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
On 22 Apr 2014, at 13:45, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
I've stumbled onto this also.
Suddenly my server started crashing. So I checked what I added recently. Removed stuff, until there was almost nothing left in the module, but still it crashed (on "request->packet->anything").
And then I noticed someone had changed the build procedure, adding "--enable-developer" to the FreeRADIUS build. (module wasn't built with "-DNDEBUG").
Since several (at least two !) people have had this problem, maybe something could be done.
Perhaps adding a public function in FreeRADIUS, which would allow to check if it was built or not with "NDEBUG" ? This would allow a module, upon instantiate, to check that its build is consistent with the server build, and if not complain and return "fail".
What do you think ?
I think it's dumb having a compiler macro which alters the fields in public structs in such a way that it causes these sorts of issues. We should either add NDEBUG to features.h, or always include those fields. I'm deferring to Alan D because IIRC he had strong objections to including NDEBUG in features.h last time this came up. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Arran Cudbard-Bell wrote:
I'm deferring to Alan D because IIRC he had strong objections to including NDEBUG in features.h last time this came up.
The issue is that NDEBUG is used to turn debugging on / off for many projects. I won't want to screw up someone else's project with definitions specific to FR. I don't see what's so hard about building your module with the same definitions used by FR. If you're building production systems, define NDEBUG. If you're developing, don't define NDEBUG. And do this consistently. The problem seems to be people who build modules using their own development tree, and then expect to use them with pre-built packages. This is *entirely* wrong. If you're going to build modules for (say) redhat, you will need to add your module to the "tar" file, use the RH spec files, update it for your module, and re-build the *entire* redhat package. Then, distribute only the RPM for your module. Doing anything else is a recipe for disaster. When the package maintainer sets some random build flag, your "custom built" module will stop working. And you'll blame me. If you're using packages, use packages. For EVERYTHING. Otherwise, you'll need to build a custom version of the server, and distribute that. You then have complete control over the build. But expecting to do "git checkout;make; ..." and have it build a module compatible with a random vendor re-package of FreeRADIUS is just wrong. That might work by magic, but there's no guarantee it will ever work correctly. Alan DeKok.
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. Why have modules at all (aside from the shared library benefits) if to use custom ones, you have to provide the whole package? Yes, there are some risks in building the shared library object elsewhere (on our build machines, we take the same FreeRadius src as that of the OS rpm and build it, then use it on that same host when building our shared object files) but it can be done and is being done routinely in other applications. So I think the benefits outweigh the risks. As for the wisdom of changing a structure's "structure" based on a debug switch... I've never seen this. Finding the error for me at least took an embarrassing long length of time. 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. Bill On 4/22/2014 8:46 AM, Alan DeKok wrote:
Arran Cudbard-Bell wrote:
I'm deferring to Alan D because IIRC he had strong objections to including NDEBUG in features.h last time this came up.
The issue is that NDEBUG is used to turn debugging on / off for many projects. I won't want to screw up someone else's project with definitions specific to FR.
I don't see what's so hard about building your module with the same definitions used by FR. If you're building production systems, define NDEBUG. If you're developing, don't define NDEBUG.
And do this consistently. The problem seems to be people who build modules using their own development tree, and then expect to use them with pre-built packages. This is *entirely* wrong.
If you're going to build modules for (say) redhat, you will need to add your module to the "tar" file, use the RH spec files, update it for your module, and re-build the *entire* redhat package. Then, distribute only the RPM for your module.
Doing anything else is a recipe for disaster. When the package maintainer sets some random build flag, your "custom built" module will stop working. And you'll blame me.
If you're using packages, use packages. For EVERYTHING. Otherwise, you'll need to build a custom version of the server, and distribute that. You then have complete control over the build.
But expecting to do "git checkout;make; ..." and have it build a module compatible with a random vendor re-package of FreeRADIUS is just wrong. That might work by magic, but there's no guarantee it will ever work correctly.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
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. Alan DeKok.
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
Bill Schoolfield wrote:
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.
That's not entirely how the GPL works. It doesn't require you to distribute your proprietary code. It gives you permission to distribute the GPL code, only if the GPL conditions are met. For a more in-depth explanation, see: https://github.com/FreeRADIUS/freeradius-server/tree/v3.0.x/src/modules/rlm_... We ship source code for a SecurID module with FreeRADIUS. The *binary* SecurID module can't be distributed by us, RedHat, Debian, etc. Alan DeKok.
I think I have a handle on licensing. What I meant was how are you going to build our module with our dependencies? On 4/22/2014 11:56 AM, Alan DeKok wrote:
Bill Schoolfield wrote:
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.
That's not entirely how the GPL works. It doesn't require you to distribute your proprietary code. It gives you permission to distribute the GPL code, only if the GPL conditions are met.
For a more in-depth explanation, see:
https://github.com/FreeRADIUS/freeradius-server/tree/v3.0.x/src/modules/rlm_...
We ship source code for a SecurID module with FreeRADIUS. The *binary* SecurID module can't be distributed by us, RedHat, Debian, etc.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 22 Apr 2014, at 18:19, Alan DeKok <aland@deployingradius.com> wrote:
Bill Schoolfield wrote:
I think I have a handle on licensing. What I meant was how are you going to build our module with our dependencies?
We have build machines. If you give us libraries && headers, we can test everything.
It's what we do for rlm_securid and oracle. We have a VM with all the non standard and proprietary libraries on it. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
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.
Why have modules at all (aside from the shared library benefits) if to use custom ones, you have to provide the whole package?
Well, you don't have to *distribute* the complete FreeRADIUS package. What you should however do is use the SRPM of the distribution(s) you are targeting to BUILD your package. You can do so by downloading the SRPM, 'install' it (i.e. unpack it), then adapt the SPEC or build script for the package to include your module in the build. If you look at the RHEL spec file for example, you will see that it builds many sub-packages, including the LDAP, Kerberos, PostgreSQL, MySQL and SQLite ones. If you design your module package such that it fits in with this model, you can simply distribute the output that contains your accounting module. It should however require the main package that is currently part of the distribution you are targeting. That way *you* follow what the distribution does. If it builds with -NDEBUG, *you* build with -NDEBUG. If it builds with -DEBUG, *you* do too. :-)
Yes, there are some risks in building the shared library object elsewhere (on our build machines, we take the same FreeRadius src as that of the OS rpm and build it, then use it on that same host when building our shared object files) but it can be done and is being done routinely in other applications. So I think the benefits outweigh the risks.
Ok. So you're already on the right track. You should however modify the distribution's SPEC file and build your module from there, not run a custom ./configure command, if that is what you're doing. :-) Stefan Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
On 4/22/2014 11:26 AM, Stefan Paetow 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.
Why have modules at all (aside from the shared library benefits) if to use custom ones, you have to provide the whole package?
Well, you don't have to *distribute* the complete FreeRADIUS package. What you should however do is use the SRPM of the distribution(s) you are targeting to BUILD your package. You can do so by downloading the SRPM, 'install' it (i.e. unpack it), then adapt the SPEC or build script for the package to include your module in the build.
If you look at the RHEL spec file for example, you will see that it builds many sub-packages, including the LDAP, Kerberos, PostgreSQL, MySQL and SQLite ones. If you design your module package such that it fits in with this model, you can simply distribute the output that contains your accounting module. It should however require the main package that is currently part of the distribution you are targeting.
That way *you* follow what the distribution does. If it builds with -NDEBUG, *you* build with -NDEBUG. If it builds with -DEBUG, *you* do too. :-)
Yes, there are some risks in building the shared library object elsewhere (on our build machines, we take the same FreeRadius src as that of the OS rpm and build it, then use it on that same host when building our shared object files) but it can be done and is being done routinely in other applications. So I think the benefits outweigh the risks.
Ok. So you're already on the right track. You should however modify the distribution's SPEC file and build your module from there, not run a custom ./configure command, if that is what you're doing.
:-)
I've got it. We will do it that way.
Stefan
Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Ok. So you're already on the right track. You should however modify the distribution's SPEC file and build your module from there, not run a custom ./configure command, if that is what you're doing.
I've got it. We will do it that way.
The nice thing about Git source control is too that you can manage the integration of your module with their source by pulling the upstream SPEC from here (for Fedora/RHEL/CentOS anyway): http://pkgs.fedoraproject.org/cgit/freeradius.git I don't know if the Debian folks have the same kind of nifty upstream server, but this way can keep your changes synchronised with theirs. That's how I keep my CentOS spec in tune. :-) Stefan Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
participants (6)
-
Alan DeKok -
Arran Cudbard-Bell -
Bill Schoolfield -
Chaigneau, Nicolas -
Phil Mayers -
Stefan Paetow