Hello folks !
Greetings ! I am looking at a usecase wherein we want radsecproxy to handle config changes on the fly instead of having to restart the whole process. For example, say we add/del new radius servers or clients without affecting the existing sessions/threads.
As I am comparing a few design choices to make this happen, wanted to check if someone has already worked on it ? If it is in roadmap for the immediate future, any design concepts someone might have already thought of but were not able to implement it ?
Thanks, Imtiyaz
Hi Imtiyaz,
On 17.11.20, 08:23, "imtiyaz@arista.com" imtiyaz@arista.com wrote:
Greetings ! I am looking at a usecase wherein we want radsecproxy to handle config changes on the fly instead of having to restart the whole process. For example, say we add/del new radius servers or clients without affecting the existing sessions/threads.
As I am comparing a few design choices to make this happen, wanted to check if someone has already worked on it ? If it is in roadmap for the immediate future, any design concepts someone might have already thought of but were not able to implement it ?
This is on my personal wish-list, but I haven't done any work in that direction. I think it will require quite a lot of restructuring, as right now, most of the code isn't prepared for dynamic config changes (apart from the dyndisc stuff). I do want to do this some day, but I think there are more important features right now.
Regards, Fabian
-- SWITCH Fabian Mauchle, Network Engineer Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland Phone +41 44 268 15 30, direct +41 44 268 15 39
Thanks for the prompt reply Fabian. Yes, from the cursory look it does look like it will take some effort to handle all the threads and the queues to handle dynamic config. I Will try to attempt it myself in pieces, maybe support adding/deleting servers first and then look at clients and so on. Will share my progress with the forum.
On Tue, Nov 17, 2020 at 6:33 PM Fabian Mauchle fabian.mauchle@switch.ch wrote:
Hi Imtiyaz,
On 17.11.20, 08:23, "imtiyaz@arista.com" imtiyaz@arista.com wrote:
Greetings ! I am looking at a usecase wherein we want radsecproxy tohandle config changes on the fly instead of having to restart the whole process. For example, say we add/del new radius servers or clients without affecting the existing sessions/threads.
As I am comparing a few design choices to make this happen, wanted tocheck if someone has already worked on it ? If it is in roadmap for the immediate future, any design concepts someone might have already thought of but were not able to implement it ?
This is on my personal wish-list, but I haven't done any work in that direction. I think it will require quite a lot of restructuring, as right now, most of the code isn't prepared for dynamic config changes (apart from the dyndisc stuff). I do want to do this some day, but I think there are more important features right now.
Regards, Fabian
-- SWITCH Fabian Mauchle, Network Engineer Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland Phone +41 44 268 15 30, direct +41 44 268 15 39
Hey,
One more thing, I would really appreciate if you can share any thoughts around the code restructuring you have mentioned in your earlier reply. If that’s something that’s not going to take in a lot of your time.
Don’t want to take up a completely orthogonal approach or reinvent something.
On Tue, 17 Nov 2020 at 6:42 PM, Imtiyaz Mohammad imtiyaz@arista.com wrote:
Thanks for the prompt reply Fabian. Yes, from the cursory look it does look like it will take some effort to handle all the threads and the queues to handle dynamic config. I Will try to attempt it myself in pieces, maybe support adding/deleting servers first and then look at clients and so on. Will share my progress with the forum.
On Tue, Nov 17, 2020 at 6:33 PM Fabian Mauchle fabian.mauchle@switch.ch wrote:
Hi Imtiyaz,
On 17.11.20, 08:23, "imtiyaz@arista.com" imtiyaz@arista.com wrote:
Greetings ! I am looking at a usecase wherein we want radsecproxy tohandle config changes on the fly instead of having to restart the whole process. For example, say we add/del new radius servers or clients without affecting the existing sessions/threads.
As I am comparing a few design choices to make this happen, wanted tocheck if someone has already worked on it ? If it is in roadmap for the immediate future, any design concepts someone might have already thought of but were not able to implement it ?
This is on my personal wish-list, but I haven't done any work in that direction. I think it will require quite a lot of restructuring, as right now, most of the code isn't prepared for dynamic config changes (apart from the dyndisc stuff). I do want to do this some day, but I think there are more important features right now.
Regards, Fabian
-- SWITCH Fabian Mauchle, Network Engineer Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland Phone +41 44 268 15 30, direct +41 44 268 15 39
On 17.11.20, 15:06, "Imtiyaz Mohammad" imtiyaz@arista.com wrote:
One more thing, I would really appreciate if you can share any thoughts around the code restructuring you have mentioned in your earlier reply. If that’s something that’s not going to take in a lot of your time.
The structure I once imagined was to modularize the code (maybe roughly along the config blocks), and separate it from the config interpreter. Then have a central core configuring multiple instances of each module and stitching them together. This should also simplify unit testing for each module.
BR, Fabian
-- SWITCH Fabian Mauchle, Network Engineer Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland Phone +41 44 268 15 30, direct +41 44 268 15 39
Thanks Fabian. Sounds like a good plan indeed. I am giving this a shot, let's see how that goes.
On Wed, Nov 18, 2020 at 9:16 PM Fabian Mauchle fabian.mauchle@switch.ch wrote:
On 17.11.20, 15:06, "Imtiyaz Mohammad" imtiyaz@arista.com wrote:
One more thing, I would really appreciate if you can share anythoughts around the code restructuring you have mentioned in your earlier reply. If that’s something that’s not going to take in a lot of your time.
The structure I once imagined was to modularize the code (maybe roughly along the config blocks), and separate it from the config interpreter. Then have a central core configuring multiple instances of each module and stitching them together. This should also simplify unit testing for each module.
BR, Fabian
-- SWITCH Fabian Mauchle, Network Engineer Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland Phone +41 44 268 15 30, direct +41 44 268 15 39
-
Fabian Mauchle -
Imtiyaz Mohammad -
imtiyaz＠arista.com