It's not a real language, honest
This is now working: ... if (`/bin/echo foo` == "foo") { update reply { User-Name = `/bin/echo bar` Reply-Message = "bar" } } ... With that functionality, rlm_exec becomes almost redundant. (almost). The "hints" and "users" files become almost redundant. The "policy" module becomes very redundant. The server becomes MUCH easier to configure... I still have to do some performance tests, but I expect the code to still be faster than 1.1.x, even with the run-time parsing of these strings. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan Dekok wrote:
This is now working:
As is this: ... if ("%{User-Name}" =~ /^bob/) { ... } ... Much of the realms handling can now be done directly from radiusd.conf. OK. I think I'm going to do something else for today. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan Dekok wrote:
Alan Dekok wrote:
This is now working:
As is this:
... if ("%{User-Name}" =~ /^bob/) { ... } ...
Much of the realms handling can now be done directly from radiusd.conf.
if ("%{User-Name}" =~ /^bob/) { update config { Proxy-To-Realm = "bob_realm" } } ? Think you can now deprecate, all the realm handling modules, the hints module the attribute rewrite module. Heh, very nice work :) Just the return codes now :P
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Arran Cudbard-Bell wrote:
if ("%{User-Name}" =~ /^bob/) { update config { Proxy-To-Realm = "bob_realm" } } ?
Almost: if ("%{User-Name}" =~ /^(.*)@(example.com)$/) { update config { Proxy-To-Realm := "%{2}" } update request { Stripped-User-Name := "%{1}" Realm := "%{2}" } } That's much of the functionality of the "realms" module. Not all, but most of it. As I said, I have to do performance checks to see how much different this is over using the "realms" module, but I don't expect it to be that bad.
Just the return codes now :P
That will take a little more work, but perhaps add even more functionality as a side-effect. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Previously Alan Dekok wrote:
Arran Cudbard-Bell wrote:
if ("%{User-Name}" =~ /^bob/) { update config { Proxy-To-Realm = "bob_realm" } } ?
Almost:
if ("%{User-Name}" =~ /^(.*)@(example.com)$/) { update config { Proxy-To-Realm := "%{2}" } update request { Stripped-User-Name := "%{1}" Realm := "%{2}" } }
Does this mean that you will have to duplicate that or use a much more complex expression to allow both user@realm and realm/user syntaxes for a realm? That would be slightly inconvenient. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote:
Does this mean that you will have to duplicate that or use a much more complex expression to allow both user@realm and realm/user syntaxes for a realm? That would be slightly inconvenient.
The "realms" module won't be deleted. But yes, replicating the "realms" module functionality in the new config language requires re-writing *all* of the C code in rlm_realms.c, which may not be worth it for most people. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Previously Alan Dekok wrote:
Wichert Akkerman wrote:
Does this mean that you will have to duplicate that or use a much more complex expression to allow both user@realm and realm/user syntaxes for a realm? That would be slightly inconvenient.
The "realms" module won't be deleted.
But yes, replicating the "realms" module functionality in the new config language requires re-writing *all* of the C code in rlm_realms.c, which may not be worth it for most people.
Perhaps it would be interesting if a module could register a function for the 'not a real language'. That would allow the realm module to allow you to do something like: if (HasRealm('IPASS', %{User-Name})) { ... } Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote:
Perhaps it would be interesting if a module could register a function for the 'not a real language'. That would allow the realm module to allow you to do something like:
if (HasRealm('IPASS', %{User-Name})) { ... }
(cough) As always, patches are welcome. :) But yes, that's a good idea. The only problem is that the unlanguage ends up turning into something like PHP, which worries me. The goal is to avoid variables other than RADIUS attributes, loops, goto's, subroutines, etc. But allowing the registration of new commands would be too useful to avoid, I think. Maybe in 2.1. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan Dekok wrote:
Wichert Akkerman wrote:
Perhaps it would be interesting if a module could register a function for the 'not a real language'. That would allow the realm module to allow you to do something like:
if (HasRealm('IPASS', %{User-Name})) { ... }
(cough) As always, patches are welcome. :)
But yes, that's a good idea. The only problem is that the unlanguage ends up turning into something like PHP, which worries me.
Mmm realms # Ipass if("%{User-Name}" ~= "^([-._[:alnum:]]*)/([-._[:alnum:]]*)$"){ update request { Stripped-User-Name = "%{2}" Realm := "%{1}2 } } # @ if("%{User-Name}" ~= "^([-._[:alnum:]]*)@([-._[:alnum:]]*)$"){ update request { Stripped-User-Name = "%{1}" Realm := "%{2}" } } # % if("%{User-Name}" ~= "^([-._[:alnum:]]*)%([-._[:alnum:]]*)$"){ update request { Stripped-User-Name = "%{1}" Realm := "%{2}" } } # NT if("%{User-Name}" ~= "^([-._[:alnum:]]*)\\\\([-._[:alnum:]]*)$"){ update request { Stripped-User-Name = "%{2}" Realm := "%{1}" } } update config { Proxy-To-Realm := "%{Realm}" } Ooo can you use group declerations with the new unlanguage ? group realms { ... }
Hi, # Ipass if("%{User-Name}" ~= "^([-._[:alnum:]]*)/([-._[:alnum:]]*)$"){ update request { Stripped-User-Name = "%{2}" - Realm := "%{1}2 + Realm := "%{1}" } } alan
A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
# Ipass if("%{User-Name}" ~= "^([-._[:alnum:]]*)/([-._[:alnum:]]*)$"){ update request { Stripped-User-Name = "%{2}" - Realm := "%{1}2 + Realm := "%{1}" } }
alan
Hehe, first typo correction for the unlanguage :)
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Arran Cudbard-Bell wrote:
Ooo can you use group declerations with the new unlanguage ?
group realms { ... }
Yes. The "update" and "if" statements can be used any place where a module name is valid. So groups Just Work. In your example, you probably want to do: if () { } elsif () { } Which means that the first matching one causes the rest of the checks to be skipped. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
hi, noted another issue with latest CVS version. after upgrading as per normal to todays code i find that my SQL system doesnt understand what ${nas_table} is anymore... ie nas_table is defined in sql.conf and the SELECT query is in the mysql-dialup.conf. this was working under last weeks code... now when I run it, I get told that theres an error...it doesnt know (nas_table). if i change ${nas_table} in that select statement with its real name (ie ditch the variable name) then FR loads and runs okay alan
A.L.M.Buxey@lboro.ac.uk wrote:
hi,
noted another issue with latest CVS version. after upgrading as per normal to todays code i find that my SQL system doesnt understand what ${nas_table} is anymore...
ie nas_table is defined in sql.conf and the SELECT query is in the mysql-dialup.conf. this was working under last weeks code... now when I run it, I get told that theres an error...it doesnt know (nas_table). if i change ${nas_table} in that select statement with its real name (ie ditch the variable name) then FR loads and runs okay
Sounds like user defined configuration variables are broken. Oh was my JRS proxy configuration file ok btw ? It can be condensed down quite a bit since Alan D added the auth+acct host type. --- Arran
Hi,
Sounds like user defined configuration variables are broken.
Oh was my JRS proxy configuration file ok btw ? It can be condensed down quite a bit since Alan D added the auth+acct host type.
yes...the question is, what is supported. 1.1.6 is a fair request to make of the users... 2.0-preX ? not yet I feel. too much of demand to make. i recieved your JRS stanza recipe - but havent setup location on the support server for it yet. alan
A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
Sounds like user defined configuration variables are broken. Confirmed, all ${variable} declarations are broken in all modules.
Means the authorization queries in rlm_sql don't work anymore :/
yes...the question is, what is supported. 1.1.6 is a fair request to make of the users... 2.0-preX ? not yet I feel. too much of demand to make.
Well you can provide the configuration files, and if they decide they want to switch then they can. I agree there should be no official support for 2.0-preX , it's changing too much. The documentation you write for it one week will be out of the date the next. Like all the emergency fail over stuff I did last week is now broken with the new configuration system *glares*, but I guess thats the price of progress :)
i recieved your JRS stanza recipe - but havent setup location on the support server for it yet.
If Alan D decided to change the format of client listings you could use config vars to define the hosts in clients.conf too, which would be neat . Instance name is used as shortname and ipaddr contains dotted quad / domain name. templates { client { nastype = other } } client jrs0 { ipaddr = ${jrs_config.server0} secret = ${jrs_config.secret0} } client jrs1 { ipaddr = ${jrs_config.server1} secret = ${jrs_config.secret1} } client jrs2 { ipaddr = ${jrs_config.server2} secret = ${jrs_config.secret2} } See neatness, and it would match the proxy format for hosts... go on you know you want to :D
Arran Cudbard-Bell wrote:
Sounds like user defined configuration variables are broken. Confirmed, all ${variable} declarations are broken in all modules.
Whoops. That's probably a side-effect of enabling the "attribute = value" stuff in radiusd.conf. I had to poke the parser, and it's pretty fragile. I'll take a look.
I agree there should be no official support for 2.0-preX , it's changing too much. The documentation you write for it one week will be out of the date the next.
Some features are stabilizing, hopefully.
If Alan D decided to change the format of client listings you could use config vars to define the hosts in clients.conf too, which would be neat .
That may be useful. I'll see if I can make it backwards compatible, too... Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
A.L.M.Buxey@lboro.ac.uk wrote:
noted another issue with latest CVS version. after upgrading as per normal to todays code i find that my SQL system doesnt understand what ${nas_table} is anymore...
I don't use SQL, but it seems to work for me. Can you post something that breaks but *isn't* an SQL config? Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan Dekok wrote:
A.L.M.Buxey@lboro.ac.uk wrote:
noted another issue with latest CVS version. after upgrading as per normal to todays code i find that my SQL system doesnt understand what ${nas_table} is anymore...
I don't use SQL, but it seems to work for me.
Can you post something that breaks but *isn't* an SQL config?
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html Dammit,
secret = ${jrs_config.secret0} Appears correct secret = "the value of jrs_config.secret0" Anyway the error I get with SQL authorize_check_query = "SELECT id, UserName, Attribute, Value, op FROM ${authcheck_table} WHERE UserName = '%{SQL-User-Name}' WARNING: Unknown module "authcheck_table" in string expansion "%{authcheck_table} . But this only happens when the query is actually executed ... And it shouldn't really ... The configuration variables should be substituted when the config file is being parsed ... not when the query is being executed.. So that should be, all run time configuration variable substitutions are broken and the SQL module happens to be the only one that seems to do them ? -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Arran Cudbard-Bell wrote:
Anyway the error I get with SQL
OK. The issue is that strings like "${foo}" don't get expanded. I've just committed a fix. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan Dekok wrote:
Arran Cudbard-Bell wrote:
Anyway the error I get with SQL
OK. The issue is that strings like "${foo}" don't get expanded. I've just committed a fix.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Yep , can confirm fixed :) thanks. -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Arran Cudbard-Bell wrote:
Alan Dekok wrote:
Arran Cudbard-Bell wrote:
Anyway the error I get with SQL OK. The issue is that strings like "${foo}" don't get expanded. I've just committed a fix.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Yep , can confirm fixed :)
thanks.
Though regular expressions no longer work :( # Stripped username if("%{User-Name}" =~ "([-[:alnum:]._^@]+)@([-[:alnum:]._]*)"){ update request { Stripped-User-Name = %{1} Pre-Proxy-Realm = %{2} } } elsif("%{User-Name}" =~ "*.-emergency.*"){ update request { Stripped-User-Name = "%{1}" } } Module: Checking authorize {...} for more modules to load Expected string or numbers at 2 0: "([-[:alnum:]._^@]+)@([-[:alnum:]._]*)") radiusd.conf[1986] Failed to parse authorize section. Errors setting up modules -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Arran Cudbard-Bell wrote:
Though regular expressions no longer work :(
# Stripped username if("%{User-Name}" =~ "([-[:alnum:]._^@]+)@([-[:alnum:]._]*)"){
That *never* worked in the config files. Use: if ("%{User-Name}" =~ /([-[:alnum:]._^@]+)@([-[:alnum:]._]*)/) { i.e. /regex/ just like other languages. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan Dekok wrote:
Arran Cudbard-Bell wrote:
Though regular expressions no longer work :(
# Stripped username if("%{User-Name}" =~ "([-[:alnum:]._^@]+)@([-[:alnum:]._]*)"){
That *never* worked in the config files. Use:
if ("%{User-Name}" =~ /([-[:alnum:]._^@]+)@([-[:alnum:]._]*)/) {
i.e. /regex/ just like other languages.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
ohhh, sorry i'm not used to everything following convention :) -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Alan Dekok wrote:
Wichert Akkerman wrote:
Perhaps it would be interesting if a module could register a function for the 'not a real language'. That would allow the realm module to allow you to do something like:
if (HasRealm('IPASS', %{User-Name})) { ... }
(cough) As always, patches are welcome. :)
But yes, that's a good idea. The only problem is that the unlanguage ends up turning into something like PHP, which worries me.
And what do you have against PHP ? I've always liked PHP, specially over Perl *eww*
The goal is to avoid variables other than RADIUS attributes, loops, goto's, subroutines, etc. But allowing the registration of new commands would be too useful to avoid, I think.
Maybe in 2.1.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Arran Cudbard-Bell wrote:
And what do you have against PHP ?
Vulnerability vulnerability vulnerability ... Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan Dekok wrote:
Arran Cudbard-Bell wrote:
And what do you have against PHP ?
Vulnerability vulnerability vulnerability ...
Like what ? You have to be really quite stupid to write PHP code with vulnerabilities ... Hmm which may be why the pages written by "Client services" keep getting overwritten mysteriously. *sigh* Fluffy people should not be allowed to code !
Previously Arran Cudbard-Bell wrote:
Alan Dekok wrote:
Arran Cudbard-Bell wrote:
And what do you have against PHP ?
Vulnerability vulnerability vulnerability ...
Like what ?
You have to be really quite stupid to write PHP code with vulnerabilities ...
Unfortunately security is a complex subject and there are lots of people out there who are not familiar with its intricacies. And a fair number of them seem to want to write PHP applications. Additionally PHP itself is not without its own share of problems, as is immediately obvious if you look at http://www.php-security.org/ for example. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote:
Previously Arran Cudbard-Bell wrote:
Alan Dekok wrote:
Arran Cudbard-Bell wrote:
And what do you have against PHP ?
Vulnerability vulnerability vulnerability ...
Like what ?
You have to be really quite stupid to write PHP code with vulnerabilities ...
Unfortunately security is a complex subject and there are lots of people out there who are not familiar with its intricacies. And a fair number of them seem to want to write PHP applications. Yes it's a fluffy language, and so attracts fluffy people. But it's fluffy reputation isn't justified, it's also a great hacking language. It's just as happy writing out configuration changes to hundreds of switches using interactive ssh sessions, as it is running a web forums... I guess it's just a preference, I learned PHP while others learned Perl, Python and Ruby. Additionally PHP itself is not without its own share of problems, as is immediately obvious if you look at http://www.php-security.org/ for example.
I'm sure Perl has it's fair shared of security issues, just the people who write it tend to be sysadmins, used to annoying people breaking things in new and horrible ways.. Whereas the people who tend to write PHP tend to be web designers, more concerned with how pretty the page looks than how secure it is. Two completely different ways of thinking...
Arran Cudbard-Bell wrote:
Like what ?
fopen() can open URL's. Unexpected behavior... Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
That's much of the functionality of the "realms" module. Not all, but most of it.
Never used realms, always a hints file and proxy-to-realm. Seemed a bit weird to me, though i'm sure they helped the the non regexp literate people :)
As I said, I have to do performance checks to see how much different this is over using the "realms" module, but I don't expect it to be that bad.
If there any reason to still call the pre process module ? Does it still add Client-IP-Address as the documentation suggests ? *sigh* vqp.c: In function 'vqp_decode': vqp.c:491: error: 'PW_VQP_PACKET_TYPE' undeclared (first use in this function) vqp.c:491: error: (Each undeclared identifier is reported only once vqp.c:491: error: for each function it appears in.) vqp.c:502: error: 'PW_VQP_ERROR_CODE' undeclared (first use in this function) vqp.c:513: error: 'PW_VQP_SEQUENCE_NUMBER' undeclared (first use in this function) vqp.c: In function 'vqp_encode': vqp.c:611: error: 'PW_VQP_PACKET_TYPE' undeclared (first use in this function) vqp.c:626: error: 'PW_VQP_ERROR_CODE' undeclared (first use in this function)
Arran Cudbard-Bell wrote:
If there any reason to still call the pre process module ? Does it still add Client-IP-Address as the documentation suggests ?
No.
*sigh*
vqp.c: In function 'vqp_decode': vqp.c:491: error: 'PW_VQP_PACKET_TYPE' undeclared (first use in this function)
$ cvs update $ make distclean $ ./configure ... Sorry... doing massive commits, and occasionally forgetting things. Also, now see: $ man vmpsd $ man vmpsd.conf And see the simple example at the tail end of vmpsd.conf. It can send/receive VMPS packets, so long as you're willing to write all of the logic in the new configuration unlanguage. :) Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On 5/28/07, Alan Dekok <aland@deployingradius.com> wrote:
Arran Cudbard-Bell wrote:
If there any reason to still call the pre process module ? Does it still add Client-IP-Address as the documentation suggests ?
No.
Is there any replacement for Client-IP-Address? Any variable with client IP, which is set by server and not read from (contents of) client request? th.
Tomas Hoger wrote:
Is there any replacement for Client-IP-Address? Any variable with client IP, which is set by server and not read from (contents of) client request?
Packet-Src-IP-Address Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Mon, May 28, 2007 at 04:40:51PM +0100, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
Sorry... doing massive commits, and occasionally forgetting things.
may be caught..but latest CVS does want to 'make install' fails due to the
sed -i .bak '/s/^freeradius-devel ....blahblah line
(in src/include/Makefile )
a quick removal of the .bak part fixes this.
Without the ".bak", FreeBSD's (version 5 and higher) sed will choke on this. Does your sed work with: sed -i.bak .... (i.e., no space between -i and its argument? If so, that'll work for both of us.) Otherwise, the most portable would be to avoid sed -i and do: sed $RE < file > file.new && mv file.new file or use "perl -i.bak -pe $RE" -- Chris Mikkelson | For example, I could be a sentient PERL script. That cmikk@qwest.net | pretty much assumes that someone brilliant enough to | write me was also stupid enough to program in PERL. | Not a likely explanation. -- Terry Lambert
Previously Chris Mikkelson wrote:
On Mon, May 28, 2007 at 04:40:51PM +0100, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
Sorry... doing massive commits, and occasionally forgetting things.
may be caught..but latest CVS does want to 'make install' fails due to the
sed -i .bak '/s/^freeradius-devel ....blahblah line
(in src/include/Makefile )
a quick removal of the .bak part fixes this.
Without the ".bak", FreeBSD's (version 5 and higher) sed will choke on this.
As far as I know -i is not a portable option for sed. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Chris Mikkelson wrote:
Otherwise, the most portable would be to avoid sed -i and do:
sed $RE < file > file.new && mv file.new file
Since the files are being installed in another directory anyways, there's no need for the ".bak". They can just be modified as they're being written to the installation directory. I also turned it into a loop, rather than installing each header file manually. This allows the 'sed' script to be run on every file, which now needs it. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan Dekok -
Arran Cudbard-Bell -
Chris Mikkelson -
Tomas Hoger -
Wichert Akkerman