Add radius server hostname to tickets
Hi, i'd like to add the radius server's hostname to the tickets, do be able to identify over which server it came in later. For that i've added a new internal freeradius attribute "Server-Hostname" and a block with a gethostname() call to xlat.c. I now update the requests with unlang and add an attribute with %{Server-Hostname} as value. Would you accept a patch for this? Or this there a better way to do this? Regards Stephan Jaeger
Stephan Jaeger wrote:
i'd like to add the radius server's hostname to the tickets, do be able to identify over which server it came in later. For that i've added a new internal freeradius attribute "Server-Hostname" and a block with a gethostname() call to xlat.c.
I now update the requests with unlang and add an attribute with %{Server-Hostname} as value.
Why not just statically configure the hostname in radiusd.conf? ... server_hostname = "foo.example.com" ... And then update the code at run time, with: Server-Hostname = "%{config:server_hostname}" The configuration files are actually a list (in the lisp sense), with nested lists, and arbitrary values. You can put pretty much anything you want in them, so long as it's properly formatted. Alan DeKok.
Alan DeKok wrote:
Stephan Jaeger wrote:
I now update the requests with unlang and add an attribute with %{Server-Hostname} as value.
Why not just statically configure the hostname in radiusd.conf?
... server_hostname = "foo.example.com" ...
And then update the code at run time, with:
Server-Hostname = "%{config:server_hostname}" Yes that would be a possibility too. I just found the other way easier. I have the configuration in svn and i would need to include another file than e.g. "hostname.conf" so the main configuration does not differ on every host. I already do this for the db configuration where i have a dev.conf, prod.conf, staging.conf and a symlink (local.conf ) to one of these which is included from the main config file. So I thought this might be useful for someone else too.
Regards Stephan
--On Thursday, April 09, 2009 10:39:36 AM +0200 Alan DeKok <aland@deployingradius.com> wrote:
Stephan Jaeger wrote:
i'd like to add the radius server's hostname to the tickets, do be able to identify over which server it came in later. For that i've added a new internal freeradius attribute "Server-Hostname" and a block with a gethostname() call to xlat.c.
I now update the requests with unlang and add an attribute with %{Server-Hostname} as value.
Why not just statically configure the hostname in radiusd.conf?
Because that makes it harder to share identical configuration among several servers?
Jeffrey Hutzelman wrote:
Why not just statically configure the hostname in radiusd.conf?
Because that makes it harder to share identical configuration among several servers?
<grumble> I hate it when people affect my delusions with reality. Ok... this is something which should be addressed. The simplest thing maybe to update the configuration parser to allow it to environment variables, e.g. $HOSTNAME, or something similar. Suggestions? Alan DeKok.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
Ok... this is something which should be addressed. The simplest thing maybe to update the configuration parser to allow it to environment variables, e.g. $HOSTNAME, or something similar.
that'd be perfect. +1 vote from me for that one. Second that. Would mean I could get rid of the branches in subversion and the raddb.local files.
Arran -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknegccACgkQcaklux5oVKK6sgCfSeAk77nBMd+xhWaNNKK3Wpas pYgAnA7ii5SEYLW5eMnNFw2qqHs0UO4i =8//f -----END PGP SIGNATURE-----
Arran Cudbard-Bell wrote:
A.L.M.Buxey@lboro.ac.uk wrote:
Ok... this is something which should be addressed. The simplest thing maybe to update the configuration parser to allow it to environment variables, e.g. $HOSTNAME, or something similar.
that'd be perfect. +1 vote from me for that one.
Second that. Would mean I could get rid of the branches in subversion and the raddb.local files.
Hmm... I think this is one of those things I did a while ago, and then forgot about. "git" says that the code went in on March 1, 2001. You can refer to environment variables via $ENV{var}. i.e. If you do this in radiusd.conf: ... $INCLUDE sites-enabled/$ENV{foo} ... $ foo=default radiusd -X It will load the "default" virtual server. $ foo=bar radiusd -X Will fail, because there's no virtual server named "bar". The only issue with this method is that there is no conditional expansion. i.e. If $ENV{foo} doesn't exist, there's no way to say "use something else". So you could put the configurations for multiple machines into one directory, and then have radiusd.conf do little more than: $INCLUDE $ENV{HOSTNAME} And it would read configuration files based on the host name, with no other run-time changes. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
Jeffrey Hutzelman wrote:
Why not just statically configure the hostname in radiusd.conf?
Because that makes it harder to share identical configuration among several servers?
<grumble> I hate it when people affect my delusions with reality.
Ok... this is something which should be addressed. The simplest thing maybe to update the configuration parser to allow it to environment variables, e.g. $HOSTNAME, or something similar.
Yeah, then instead of putting your customisations in the config file you are hacking something horrible like /etc/init.d/freeradius instead. :-/ Eugh.
Suggestions?
Unsure how much of a ball-ache it would be but I would suggest a C-esque 'static' RADIUS attribute that is primed in 'instantiate'[1]; don't make it read-only as someone might want to do something crazy and interesting with it. Of course for logging which RADIUS server handled the result, I ask my central logging servers (in my case SQL) to automatically fill in a field with the SQL client's IP (I make it part of the table schema)...aka the RADIUS server logging a particular request. Bah, maybe that's just how I roll my dice. Cheers [1] people can then use 'exec' when priming to extract external stuff -- Alexander Clouter .sigmonster says: Q: Why did the WASP cross the road? A: To get to the middle.
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Alexander Clouter -
Arran Cudbard-Bell -
Jeffrey Hutzelman -
Stephan Jaeger