Backporting rlm_rest to 2.1.x
Hi, Can someone kindly give me some hints for getting rlm_rest working with freeradius 2.1. As a web developer, this is goes beyond my limited understanding of C. The module compiles fine from the master branch (3.0) but I really need it working in 2.1. So far I have taken the following steps: 1) Checkout and build tag 2.1.12 (builds ok). 2) Copy rlm_rest into modules/ 3) Copy connections.h into /src 4) cd modules/rlm_rest/; ./configure; make; Now I get the error below which I can't make head nor tail of. Is 3.0 using different compiler options or something? If anyone can help get this working it would be greatly appreciated! rlm_rest]# make /root/freeradius-server/libtool --mode=compile gcc -g -O2 -Wall -D_GNU_SOURCE -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -g -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -W -Wredundant-decls -Wundef -I/root/freeradius-server/src -I/root/freeradius-server/libltdl -c rlm_rest.c gcc -g -O2 -Wall -D_GNU_SOURCE -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -g -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -W -Wredundant-decls -Wundef -I/root/freeradius-server/src -I/root/freeradius-server/libltdl -c rlm_rest.c -fPIC -DPIC -o .libs/rlm_rest.o rlm_rest.c:142: error: expected declaration specifiers or '...' before 'rlm_components_t' rlm_rest.c: In function 'parse_sub_section': rlm_rest.c:146: error: 'section_type_value' undeclared (first use in this function) rlm_rest.c:146: error: (Each undeclared identifier is reported only once rlm_rest.c:146: error: for each function it appears in.) rlm_rest.c:146: error: 'comp' undeclared (first use in this function) rlm_rest.c: In function 'rlm_rest_instantiate': rlm_rest.c:248: error: too many arguments to function 'parse_sub_section' rlm_rest.c:250: error: too many arguments to function 'parse_sub_section' rlm_rest.c:252: error: too many arguments to function 'parse_sub_section' rlm_rest.c:254: error: too many arguments to function 'parse_sub_section' rlm_rest.c:256: error: too many arguments to function 'parse_sub_section' make: *** [rlm_rest.lo] Error 1
Gavin Alves wrote:
Can someone kindly give me some hints for getting rlm_rest working with freeradius 2.1.
Don't. The internal APIs and data structures have changed a LOT from 2.x to 3.0. Back-porting a module really means re-writing it from scratch. Why not just run 3.0?
Now I get the error below which I can't make head nor tail of. Is 3.0 using different compiler options or something?
3.0 has data structures, functions, and other things that don't exist in 2.1. You can't just copy the module. You have to copy every single thing it depends on. Or, just use 3.0. Alan DeKok.
Thanks Alan. Pretty much the answer I was expecting but not the one I was hoping for. 3.0 is not mature enough for my requirements, especially as you say there are significant architectural changes. I've decided to try initiating the http requests using rlm_perl, which as I understand it, should have no significant overhead insofar as the interpreter is concerned. The only downside I see is that it will not be possible to reuse the curl connections. However this is compensated for by the ability to design requests in a high level language. Please shoot me down if this is a terrible idea. On 11 August 2012 07:19, Alan DeKok <aland@deployingradius.com> wrote:
Gavin Alves wrote:
Can someone kindly give me some hints for getting rlm_rest working with freeradius 2.1.
Don't. The internal APIs and data structures have changed a LOT from 2.x to 3.0. Back-porting a module really means re-writing it from scratch.
Why not just run 3.0?
Now I get the error below which I can't make head nor tail of. Is 3.0 using different compiler options or something?
3.0 has data structures, functions, and other things that don't exist in 2.1. You can't just copy the module. You have to copy every single thing it depends on.
Or, just use 3.0.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Gavin Alves wrote:
3.0 is not mature enough for my requirements, especially as you say there are significant architectural changes.
3.0 is pretty much stable. I'm just trying to get a few more minor features in before the release. And architectural changes don't make it unstable...
I've decided to try initiating the http requests using rlm_perl, which as I understand it, should have no significant overhead insofar as the interpreter is concerned. The only downside I see is that it will not be possible to reuse the curl connections. However this is compensated for by the ability to design requests in a high level language.
You should be able to have long-term connections in the Perl code. See example.pl in recent releases, IIRC. Alan DeKok.
On 11 Aug 2012, at 10:55, Alan DeKok <aland@DEPLOYINGRADIUS.COM> wrote:
Gavin Alves wrote:
3.0 is not mature enough for my requirements, especially as you say there are significant architectural changes.
3.0 is pretty much stable. I'm just trying to get a few more minor features in before the release.
And architectural changes don't make it unstable...
I've decided to try initiating the http requests using rlm_perl, which as I understand it, should have no significant overhead insofar as the interpreter is concerned. The only downside I see is that it will not be possible to reuse the curl connections. However this is compensated for by the ability to design requests in a high level language.
You should be able to have long-term connections in the Perl code. See example.pl in recent releases, IIRC.
Are those globals per-thread? Or are they *really* global. -Arran
Hi,
Thanks Alan. Pretty much the answer I was expecting but not the one I was hoping for. 3.0 is not mature enough for my requirements, especially as you say there are significant architectural changes.
how do you designate 'mature' software? old software can and does have bugs too - well used software might be 'mature' in way of updates/patches but then you have no features. we need more people to be running 3.0 so that we can find any other issues and maybe see a sooner release or 3.0.1 etc I've only running 3.0 HEAD on my test systems now - no longer looking at 2.1.x or 2.2.x updates - and it wont be long before it'll be just 3.x on production systems too. alan
how do you designate 'mature' software? old software can and does have bugs too - well used software might be 'mature' in way of updates/patches but then you have no features. we need more people to be running 3.0 so that we can find any other issues and maybe see a sooner release or 3.0.1 etc
I've only running 3.0 HEAD on my test systems now - no longer looking at 2.1.x or 2.2.x updates - and it wont be long before it'll be just 3.x on production systems too.
Point taken. The reality is that many organisations will not upgrade software until there are packages maintained in their distro, By this point a business can assume at least some minimum standard of 3rd party quality assurance and peer review. A really strong case would be needed for a home brew release (which I don't think I could make as 2.1 works very well for us). As for getting people onto 3.0; a classic catch 22. Updating the website, api docs, distributing binary packages and so on might help. I was not even aware of it until yesterday.
On 11 Aug 2012, at 10:27, Gavin Alves <gavin.alves@gmail.com> wrote:
Thanks Alan. Pretty much the answer I was expecting but not the one I was hoping for.
3.0 is not mature enough for my requirements, especially as you say there are significant architectural changes.
You know rlm_rest has (to my knowledge) never been used in a production environment right? :)
I've decided to try initiating the http requests using rlm_perl, which as I understand it, should have no significant overhead insofar as the interpreter is concerned.
Shouldn't do.
The only downside I see is that it will not be possible to reuse the curl connections. However this is compensated for by the ability to design requests in a high level language.
Please shoot me down if this is a terrible idea.
If you can stand the overhead of TCP connection setup and tear down for *every* request, then it's ok. It depends entirely on your load and acceptable latencies. It's the difference between a 2+ packet exchange and a 7+ packet exchange. If your HTTP server is local to the machine or on your LAN then it'll probably be fine, if it's on some corporate server 50ms away, then i'd strongly advise against it. (as you've seen) rlm_rest takes advantage of CURL's connection caching feature. The module itself caches the handles, and CURL uses persistent TCP connections (with HTTP/1.1) to avoid the overhead of re-establishing the TCP connection every request. Anyway. rlm_rest uses API features that are only available in 3.0. Nested configuration parsing isn't there in 2.0, nor is the connection pool API, there were also changes to xlat.c for printing escaped values in URL format and JSON, and something to parse list qualifiers in attribute names. Digging out all the core code and backporting it would be a PITA. Unless you're willing to do it yourself or contract someone to do it, it ain't going to happen. -Arran
Hi,
Can someone kindly give me some hints for getting rlm_rest working with freeradius 2.1. As a web developer, this is goes beyond my limited understanding of C. The module compiles fine from the master branch (3.0) but I really need it working in 2.1.
why? Why cant you use 3.0 ? alan
participants (4)
-
alan buxey -
Alan DeKok -
Arran Cudbard-Bell -
Gavin Alves