Hi, I wonder if one way to deal with the network configuration issue is to try and help different configuration systems work with each other, rather than to try and create one system which does everything. Last time I looked into this there were various things which could be done to allow peaceful coexistence of various configuration tools, but which were missing. One of these is related to routing. Routes can be tagged with an originator protocol (/etc/iproute2/rt_protos) with the default being "kernel" for routes which are generated automatically, say on interface being brought up. This means that utilities which do some form of dynamic routing (and I include NetworkManager, dhcp clients, etc in this) should only remove or change routes which are either marked "kernel" or which are marked with their own protocol id. I brought this issue up some time ago (I did look for a reference but didn't find one immediately), but without seeing much enthusiasm for resolving it. My point is not so much that this particular issue should be fixed (and maybe it has been since it is a while since I last checked) but that by careful use of the available functions (and maybe with the odd extension here and there) it should be possible to allow many different tools to cooperate with each other. I'm just using the route issue as an example. Obviously there needs to be some coordination when it comes to dealing with an interface coming up and which particular tool will deal with the set up, but there is still scope for allowing multiple tools to cooperate too. That way we can have specialist tools to deal with the less common situations without needing to clutter up those tools dealing with the more common case with more advanced features. So my take on the problem is to consider how it would be possible to have different tools cooperating in the same space, and then maybe to extract the common functions which allow this into a small library which could then be used by each tool. I'm not sure if this is useful in the context of the original post, but it is what it brought to mind while I was reading it, Steve. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel