Behaviour of --with-developer is changing. When --with-developer=yes compiler optimisation will now be disabled, and -g3 will be set, so gcc emitts the most complete debugging info (should include the value preprocessor macros and other useful things). --with-developer=yes is automatically set if you're building from a git repo. So if you happen to be stress testing or pushing a pre-release version into production, you will want to set --with-developer=no, which will re-enable optimisation and set -g (2). This will only be changed in master branch, because of issues with package maintainers passing --enable-developer when building binary packages. In other news, ident has been enabled in the main repo, so all the little $Id$ tags that were left over from CVS will now be expanded on checkout to contain the latest commit hash for the file. The format of RADIUSD_VERSION has now also changed. Previously it was the raw value from VERSION <major>.<minor>.<incremental> now it's a 6 digit integer <major><minor><incremental>. This is because the C preprocessor can't do comparisons between floats, only integers, so if you needed to make your custom module build with multiple versions of the server, you couldn't. Alan dislikes this approach and thinks it should die with fire, but if you don't like it, don't use it. There's also a new xlat expansion %{dhcp_options:}. Some switch vendors offer DHCP to RADIUS gateways, but don't define their own VSAs to represent DHCP options, so include the DHCP options from the DHCP packet as an opaque blob of binary data packed into a single VSA. Seeing as the server already has the code to parse dhcp options, it seemed like a fun hack to expose it as an xlat function. %{dhcp_options:} takes an attribute reference with qualifiers, and expands to the number of options in the blob. During expansion it adds all the options it finds in the blob to the request list with +=, using the FR DHCP dictionary. If anyone knows of other vendors besides the lazy lazy French one doing this, please let me know. -Arran
Arran Cudbard-Bell wrote:
When --with-developer=yes compiler optimisation will now be disabled, and -g3 will be set, so gcc emitts the most complete debugging info (should include the value preprocessor macros and other useful things).
That's good.
--with-developer=yes is automatically set if you're building from a git repo. So if you happen to be stress testing or pushing a pre-release version into production, you will want to set --with-developer=no, which will re-enable optimisation and set -g (2).
That's good.
This will only be changed in master branch, because of issues with package maintainers passing --enable-developer when building binary packages.
OK.
In other news, ident has been enabled in the main repo, so all the little $Id$ tags that were left over from CVS will now be expanded on checkout to contain the latest commit hash for the file.
Hmm... I'm a little more unsure about that.
The format of RADIUSD_VERSION has now also changed. Previously it was the raw value from VERSION <major>.<minor>.<incremental> now it's a 6 digit integer <major><minor><incremental>.
That's better.
Alan dislikes this approach and thinks it should die with fire, but if you don't like it, don't use it.
I dislike what?
There's also a new xlat expansion %{dhcp_options:}. Some switch vendors offer DHCP to RADIUS gateways, but don't define their own VSAs to represent DHCP options, so include the DHCP options from the DHCP packet as an opaque blob of binary data packed into a single VSA.
That's good.
Seeing as the server already has the code to parse dhcp options, it seemed like a fun hack to expose it as an xlat function. %{dhcp_options:} takes an attribute reference with qualifiers, and expands to the number of options in the blob. During expansion it adds all the options it finds in the blob to the request list with +=, using the FR DHCP dictionary.
Yup.
If anyone knows of other vendors besides the lazy lazy French one doing this, please let me know.
There's an RFC I keep meaning to write about that. Alan DeKok.
On Sat, Nov 03, 2012 at 12:12:30PM +0100, Alan DeKok wrote:
Arran Cudbard-Bell wrote:
In other news, ident has been enabled in the main repo, so all the little $Id$ tags that were left over from CVS will now be expanded on checkout to contain the latest commit hash for the file.
Hmm... I'm a little more unsure about that.
What would be more useful is if a git-built FR could display the latest commit hash in the "-v" version information? Then I'd stand a chance of working out exactly *what* I compiled when it breaks :-) git {blame,log,show} make the $Id$ source code strings pretty irrelevant in general I would have thought, apart from the above. Cheers Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 3 Nov 2012, at 11:59, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Sat, Nov 03, 2012 at 12:12:30PM +0100, Alan DeKok wrote:
Arran Cudbard-Bell wrote:
In other news, ident has been enabled in the main repo, so all the little $Id$ tags that were left over from CVS will now be expanded on checkout to contain the latest commit hash for the file.
Hmm... I'm a little more unsure about that.
What would be more useful is if a git-built FR could display the latest commit hash in the "-v" version information? Then I'd stand a chance of working out exactly *what* I compiled when it breaks :-)
Added that one in about a week ago (2d7d05), works for radmin, radclient and radiusd. The other utilities don't have -v arguments. There's also an easter egg in radiusd, where if you do -xv it'll print out the features available.
git {blame,log,show} make the $Id$ source code strings pretty irrelevant in general I would have thought, apart from the above.
Until the files are taken out of version control for whatever reason. I agree not overly immediately useful, but i'm sure it'll come in handy for someone, somewhere at some point. -Arran
On Sat, Nov 03, 2012 at 02:44:37PM +0000, Arran Cudbard-Bell wrote:
What would be more useful is if a git-built FR could display the latest commit hash in the "-v" version information? Then I'd stand a chance of working out exactly *what* I compiled when it breaks :-)
Added that one in about a week ago (2d7d05), works for radmin, radclient and radiusd. The other utilities don't have -v arguments.
Nice one; thanks. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 3 Nov 2012, at 11:12, Alan DeKok <aland@DEPLOYINGRADIUS.COM> wrote:
Arran Cudbard-Bell wrote:
When --with-developer=yes compiler optimisation will now be disabled, and -g3 will be set, so gcc emitts the most complete debugging info (should include the value preprocessor macros and other useful things).
That's good.
--with-developer=yes is automatically set if you're building from a git repo. So if you happen to be stress testing or pushing a pre-release version into production, you will want to set --with-developer=no, which will re-enable optimisation and set -g (2).
That's good.
Uh but make that --enable-developer. Grrr.
This will only be changed in master branch, because of issues with package maintainers passing --enable-developer when building binary packages.
OK.
In other news, ident has been enabled in the main repo, so all the little $Id$ tags that were left over from CVS will now be expanded on checkout to contain the latest commit hash for the file.
Hmm... I'm a little more unsure about that.
It doesn't cause any harm... Well, now that the badly formatted ones are fixed it doesn't cause any harm.
The format of RADIUSD_VERSION has now also changed. Previously it was the raw value from VERSION <major>.<minor>.<incremental> now it's a 6 digit integer <major><minor><incremental>.
That's better.
Alan dislikes this approach and thinks it should die with fire, but if you don't like it, don't use it.
I dislike what?
Using C preprocessor conditions to swap out bits of module code so they build against various versions of the server.
If anyone knows of other vendors besides the lazy lazy French one doing this, please let me know.
There's an RFC I keep meaning to write about that.
Didn't you say someone held the patent :(? -Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:
There's also a new xlat expansion %{dhcp_options:}. Some switch vendors offer DHCP to RADIUS gateways, but don't define their own VSAs to represent DHCP options, so include the DHCP options from the DHCP packet as an opaque blob of binary data packed into a single VSA.
Seeing as the server already has the code to parse dhcp options, it seemed like a fun hack to expose it as an xlat function. %{dhcp_options:} takes an attribute reference with qualifiers, and expands to the number of options in the blob. During expansion it adds all the options it finds in the blob to the request list with +=, using the FR DHCP dictionary.
If anyone knows of other vendors besides the lazy lazy French one doing this, please let me know.
I'm not sure what you are referring to here, but if I understand this feature correctly then I believe it will be useful with Juniper JUNOS and JUNOSe access routers as well. Newer versions decode some of the more useful DHCP options and provide them in separate attributes, but the raw list of all DHCP options is also available. E.g: ERX-Dhcp-Options = "5\001\0012\004\224z\247\0057\0103:;\001y\003!\006R'\001\033DSA13FBU atm 1/1/01/23:8.35\002\01067676775" I assume this is what the new xlat will decode? That is very useful. Bjørn
Bjørn Mork wrote:
I'm not sure what you are referring to here, but if I understand this feature correctly then I believe it will be useful with Juniper JUNOS and JUNOSe access routers as well. Newer versions decode some of the more useful DHCP options and provide them in separate attributes, but the raw list of all DHCP options is also available. E.g:
ERX-Dhcp-Options = "5\001\0012\004\224z\247\0057\0103:;\001y\003!\006R'\001\033DSA13FBU atm 1/1/01/23:8.35\002\01067676775"
I assume this is what the new xlat will decode? That is very useful.
Yes. It should be possible to extend this to similar "special" hacks, too. Alan DeKok.
On 3 Nov 2012, at 12:31, Bjørn Mork <bjorn@mork.no> wrote:
Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:
There's also a new xlat expansion %{dhcp_options:}. Some switch vendors offer DHCP to RADIUS gateways, but don't define their own VSAs to represent DHCP options, so include the DHCP options from the DHCP packet as an opaque blob of binary data packed into a single VSA.
Seeing as the server already has the code to parse dhcp options, it seemed like a fun hack to expose it as an xlat function. %{dhcp_options:} takes an attribute reference with qualifiers, and expands to the number of options in the blob. During expansion it adds all the options it finds in the blob to the request list with +=, using the FR DHCP dictionary.
If anyone knows of other vendors besides the lazy lazy French one doing this, please let me know.
I'm not sure what you are referring to here, but if I understand this feature correctly then I believe it will be useful with Juniper JUNOS and JUNOSe access routers as well. Newer versions decode some of the more useful DHCP options and provide them in separate attributes, but the raw list of all DHCP options is also available. E.g:
ERX-Dhcp-Options = "5\001\0012\004\224z\247\0057\0103:;\001y\003!\006R'\001\033DSA13FBU atm 1/1/01/23:8.35\002\01067676775"
I assume this is what the new xlat will decode? That is very useful.
Yes. Though it looks like ERX-Dhcp-Options is defined wrongly as a string in the vendor's dictionary, i'll go fix that... -Arran
On 3 Nov 2012, at 14:19, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 3 Nov 2012, at 12:31, Bjørn Mork <bjorn@mork.no> wrote:
Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:
There's also a new xlat expansion %{dhcp_options:}. Some switch vendors offer DHCP to RADIUS gateways, but don't define their own VSAs to represent DHCP options, so include the DHCP options from the DHCP packet as an opaque blob of binary data packed into a single VSA.
Seeing as the server already has the code to parse dhcp options, it seemed like a fun hack to expose it as an xlat function. %{dhcp_options:} takes an attribute reference with qualifiers, and expands to the number of options in the blob. During expansion it adds all the options it finds in the blob to the request list with +=, using the FR DHCP dictionary.
If anyone knows of other vendors besides the lazy lazy French one doing this, please let me know.
I'm not sure what you are referring to here, but if I understand this feature correctly then I believe it will be useful with Juniper JUNOS and JUNOSe access routers as well. Newer versions decode some of the more useful DHCP options and provide them in separate attributes, but the raw list of all DHCP options is also available. E.g:
ERX-Dhcp-Options = "5\001\0012\004\224z\247\0057\0103:;\001y\003!\006R'\001\033DSA13FBU atm 1/1/01/23:8.35\002\01067676775"
I assume this is what the new xlat will decode? That is very useful.
Yes. Though it looks like ERX-Dhcp-Options is defined wrongly as a string in the vendor's dictionary, i'll go fix that...
Heh. So it works as is, with no additional hacks. update request { Tmp-Octets-0 := "0x3501013204947aa7053708333a3b01790321065227011b44534131334642552061746d20312f312f30312f32333a382e333502083637363736373735" } update request { Tmp-Integer-0 := "%{dhcp_options:Tmp-Octets-0}" } update request { Tmp-String-0 := "%{string:DHCP-Relay-Circuit-Id}" Tmp-String-1 := "%{string:DHCP-Relay-Remote-ID}" } (0) update request { DHCP-Message-Type += DHCP-Discover DHCP-Requested-IP-Address += 148.x.x.x (removed because i'm nice :) ) DHCP-Parameter-Request-List += DHCP-IP-Address-Lease-Time DHCP-Parameter-Request-List += DHCP-Renewal-Time DHCP-Parameter-Request-List += DHCP-Rebinding-Time DHCP-Parameter-Request-List += DHCP-Subnet-Mask DHCP-Parameter-Request-List += DHCP-Classless-Static-Route DHCP-Parameter-Request-List += DHCP-Router-Address DHCP-Parameter-Request-List += DHCP-Static-Routes DHCP-Parameter-Request-List += DHCP-Domain-Name-Server DHCP-Relay-Circuit-Id = 0x44534131334642552061746d20312f312f30312f32333a382e3335 DHCP-Relay-Remote-Id = 0x3637363736373735 (0) expand: %{dhcp_options:Tmp-Octets-0} -> 12 (0) } # update request = notfound (0) update request { (0) expand: %{string:DHCP-Relay-Circuit-Id} -> DSA13FBU atm 1/1/01/23:8.35 (0) expand: %{string:DHCP-Relay-Remote-ID} -> 67676775 (0) } # update request = notfound Sweet :) -Arran
Yes. Though it looks like ERX-Dhcp-Options is defined wrongly as a string in the vendor's dictionary, i'll go fix that...
Heh. So it works as is, with no additional hacks.
If anyone wants the octally escaped string to hex code I put it up here: https://gist.github.com/4013951 -Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:
Yes. Though it looks like ERX-Dhcp-Options is defined wrongly as a string in the vendor's dictionary, i'll go fix that...
Heh. So it works as is, with no additional hacks.
If anyone wants the octally escaped string to hex code I put it up here: https://gist.github.com/4013951
Nice. But you do know that C isn't exactly the best language for string manipulation? Alternative version: perl -e 'print "0x", unpack("H*", eval "qq#".shift."#")' OK, yours is readable :-) Bjørn
On 5 Nov 2012, at 09:17, Bjørn Mork <bjorn@mork.no> wrote:
Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:
Yes. Though it looks like ERX-Dhcp-Options is defined wrongly as a string in the vendor's dictionary, i'll go fix that...
Heh. So it works as is, with no additional hacks.
If anyone wants the octally escaped string to hex code I put it up here: https://gist.github.com/4013951
Nice. But you do know that C isn't exactly the best language for string manipulation? Alternative version:
perl -e 'print "0x", unpack("H*", eval "qq#".shift."#")'
OK, yours is readable :-)
Hmm not really equivalent because of the pre-escaping you'd need to do to get the string into perl unmolested. I challenge you to write a one liner that'll work with an arbitrary length string from STDIN :P Also, I hate Perl, with a passion. Any time I write some I feel dirty, and it always comes out looking like someone vomited in the text editor. -Arran
On Mon, Nov 05, 2012 at 09:41:37AM +0000, Arran Cudbard-Bell wrote:
Hmm not really equivalent because of the pre-escaping you'd need to do to get the string into perl unmolested. I challenge you to write a one liner that'll work with an arbitrary length string from STDIN :P
Also, I hate Perl, with a passion. Any time I write some I feel dirty, and it always comes out looking like someone vomited in the text editor.
In Ruby: echo "foo\200bar" | ruby -e 'puts eval("\""+$stdin.read+"\"").unpack("H*").first' Or without eval: echo "foo\200bar" | ruby -e 'puts $stdin.read.gsub(/\\(\d\d\d)/) { $1.to_i(8).chr }.unpack("H*").first' Note: this will only work on ruby 1.8. Ruby 1.9 has a horrid string encoding system which requires jumping through hoops to get around.
On 5 Nov 2012, at 14:28, Brian Candler <B.Candler@pobox.com> wrote:
On Mon, Nov 05, 2012 at 09:41:37AM +0000, Arran Cudbard-Bell wrote:
Hmm not really equivalent because of the pre-escaping you'd need to do to get the string into perl unmolested. I challenge you to write a one liner that'll work with an arbitrary length string from STDIN :P
Also, I hate Perl, with a passion. Any time I write some I feel dirty, and it always comes out looking like someone vomited in the text editor.
In Ruby:
echo "foo\200bar" | ruby -e 'puts eval("\""+$stdin.read+"\"").unpack("H*").first'
Or without eval:
echo "foo\200bar" | ruby -e 'puts $stdin.read.gsub(/\\(\d\d\d)/) { $1.to_i(8).chr }.unpack("H*").first'
I guess that works if you have arbitrary amounts of memory :) -Arran
On Mon, Nov 05, 2012 at 03:06:26PM +0000, Arran Cudbard-Bell wrote:
In Ruby:
echo "foo\200bar" | ruby -e 'puts eval("\""+$stdin.read+"\"").unpack("H*").first'
Or without eval:
echo "foo\200bar" | ruby -e 'puts $stdin.read.gsub(/\\(\d\d\d)/) { $1.to_i(8).chr }.unpack("H*").first'
I guess that works if you have arbitrary amounts of memory :)
How big are your DHCP attributes then? :) OK: echo "foo\200bar" | ruby -e 'while d=$stdin.read(32); puts d.gsub(/\\(\d\d\d)/) { $1.to_i(8).chr }.unpack("H*").first; end' Still a one-liner, as long as your console is at least 104 characters wide...
On 6 Nov 2012, at 11:46, Brian Candler <B.Candler@pobox.com> wrote:
On Mon, Nov 05, 2012 at 03:06:26PM +0000, Arran Cudbard-Bell wrote:
In Ruby:
echo "foo\200bar" | ruby -e 'puts eval("\""+$stdin.read+"\"").unpack("H*").first'
Or without eval:
echo "foo\200bar" | ruby -e 'puts $stdin.read.gsub(/\\(\d\d\d)/) { $1.to_i(8).chr }.unpack("H*").first'
I guess that works if you have arbitrary amounts of memory :)
How big are your DHCP attributes then? :)
Arbitrarily big :)
OK:
echo "foo\200bar" | ruby -e 'while d=$stdin.read(32); puts d.gsub(/\\(\d\d\d)/) { $1.to_i(8).chr }.unpack("H*").first; end'
Still a one-liner, as long as your console is at least 104 characters wide...
Fine, fine, you win :p -Arran
participants (5)
-
Alan DeKok -
Arran Cudbard-Bell -
Bjørn Mork -
Brian Candler -
Matthew Newton