Hi Guys I am doing some work on cleaning up and integrating a CoA script and web interface to share its configuration with FreeRADIUS. Now, in future we are going to need some type of CoA support inside FreeRADIUS, so I want to make sure I do things in a way to works going forward. My initial issue is moving the list of CoA secrets I have from inside my python code into a place where FreeRADIUS can use the info also. Now, to me it makes sense to keep the CoA secret in the NAS table (or clients.conf) as a RADIUS client and a CoA server are almost always going to share information (ie. be the same thing) and in cases where they are not we could either leave out the CoA secret or the RADIUS shared secret.. With that logic I plan to add a "coasecret" field to the NAS table (same can be done for clients.conf). Does anyone have anything against this plan? Cheers -- Peter Nixon http://peternixon.net/
Peter Nixon wrote:
Now, to me it makes sense to keep the CoA secret in the NAS table (or clients.conf) as a RADIUS client and a CoA server are almost always going to share information (ie. be the same thing) and in cases where they are not we could either leave out the CoA secret or the RADIUS shared secret..
Sure.
With that logic I plan to add a "coasecret" field to the NAS table (same can be done for clients.conf). Does anyone have anything against this plan?
Nope. For 2.0, the NAS table should also have a "listener" or "virtual server" key. Clients can have different shared secrets with each socket that the server is listening on... Alan DeKok.
On Thu 19 Jul 2007, Alan DeKok wrote:
Peter Nixon wrote:
Now, to me it makes sense to keep the CoA secret in the NAS table (or clients.conf) as a RADIUS client and a CoA server are almost always going to share information (ie. be the same thing) and in cases where they are not we could either leave out the CoA secret or the RADIUS shared secret..
Sure.
With that logic I plan to add a "coasecret" field to the NAS table (same can be done for clients.conf). Does anyone have anything against this plan?
Nope.
For 2.0, the NAS table should also have a "listener" or "virtual server" key. Clients can have different shared secrets with each socket that the server is listening on...
Hmm.. OK. I was looking at that stuff today and wondering about that. Can we call them vhosts? Everyone already knows what that means from apache... Also, I was thinking that, while we are on a roll, maybe we should rename clients.conf to nas.conf given that with CoA the hosts listed there may be client, server or both.... Cheers -- Peter Nixon http://peternixon.net/
Peter Nixon wrote:
Hmm.. OK. I was looking at that stuff today and wondering about that. Can we call them vhosts? Everyone already knows what that means from apache...
Sure.
Also, I was thinking that, while we are on a roll, maybe we should rename clients.conf to nas.conf given that with CoA the hosts listed there may be client, server or both....
If we're going to do that, I suggest also reformatting the "clients" entry to match the "home_server" entry: nas short_name { ipaddr = 1.2.3.4 secret = testing123 } Which may clean up some of the parsing. We can keep the "client" parsing code in there for backwards compatibility, I guess. Alan DeKok.
On Thu 19 Jul 2007, Alan DeKok wrote:
Peter Nixon wrote:
Hmm.. OK. I was looking at that stuff today and wondering about that. Can we call them vhosts? Everyone already knows what that means from apache...
Sure.
Also, I was thinking that, while we are on a roll, maybe we should rename clients.conf to nas.conf given that with CoA the hosts listed there may be client, server or both....
If we're going to do that, I suggest also reformatting the "clients" entry to match the "home_server" entry:
nas short_name { ipaddr = 1.2.3.4 secret = testing123 }
Which may clean up some of the parsing.
We can keep the "client" parsing code in there for backwards compatibility, I guess.
Sounds good to me. -- Peter Nixon http://peternixon.net/
On Thu 19 Jul 2007, Alan DeKok wrote:
Peter Nixon wrote:
Hmm.. OK. I was looking at that stuff today and wondering about that. Can we call them vhosts? Everyone already knows what that means from apache...
Sure.
Whats the max possible length of a vhost name? -- Peter Nixon http://peternixon.net/
Peter Nixon wrote:
Whats the max possible length of a vhost name?
A shade under 8k, which is the limit of most things in the conf files. Let's call it 256 characters. DNS names can get that long. Anything more than that, and the poor administrator will want to call it something else, to save typing. Alan DeKok.
Alan DeKok wrote:
Peter Nixon wrote:
Hmm.. OK. I was looking at that stuff today and wondering about that. Can we call them vhosts? Everyone already knows what that means from apache...
Sure.
Also, I was thinking that, while we are on a roll, maybe we should rename clients.conf to nas.conf given that with CoA the hosts listed there may be client, server or both....
Are you sure ? Clients.conf is more universal as you need to list proxy servers in clients too.... Which aren't technically Network Authentication Servers.
If we're going to do that, I suggest also reformatting the "clients" entry to match the "home_server" entry:
nas short_name { ipaddr = 1.2.3.4 secret = testing123 }
Which may clean up some of the parsing.
And allows you to use configuration variables in clients configuration.
We can keep the "client" parsing code in there for backwards compatibility, I guess.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Arran Cudbard-Bell wrote:
Are you sure ? Clients.conf is more universal as you need to list proxy servers in clients too.... Which aren't technically Network Authentication Servers.
Hmm.. good point. While logically they are NASes to the RADIUS server, calling them that may confuse administrators.
We can keep the "client" parsing code in there for backwards compatibility, I guess.
That can still still be done. Alan DeKok.
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Peter Nixon