On 02/03/2019 11:23 AM, Michael Orlitzky wrote:
Ultimately netifrc is just a shell script that parses another shell script to construct a third shell script. I don't think doing it with only two shell scripts is that much less elegant =)
The elegance, or lack there of, is not in the number of shell scripts. Rather the fact that tc (QoS) parameters are stuffed into a command line verses having things split out and parsed is what I dislike. Take VLANs for example, there is a netifrc parameter for specifying the VLAN IDs that belong on an interface. Netifrc will then construct the commands. People don't need to know how to construct the commands themselves to utilize VLANs. tc (QoS) is not anywhere nearly as nice.
Bridging and bonding is similarly more graceful than tc (QoS).
You could go all the way and write your own OpenRC service as /etc/init.d/whatever.
That's sort of where I'm gravitating at the moment. Something I can (re)start/stop via standard init commands.
You can make it depend on the network being up, and then just write everything that you want it to do into the start function with the corresponding "undo" steps in the stop function.
Maybe it will need to depend on the lowest level of networking. Maybe. Seeing as how it would provide networking between the host and the namespaces (containers), I think it would functionally be parallel to the networking services. I think namespaces could be up even if the main network was not.
If the series of commands is long and complicated and if you sometimes want to do/undo this subset of the configuration independently, then that's how I'd do it.
The number of commands is really dependent on what I'm doing at a higher level. I can see having relatively similar commands for different namespaces broken out into separate files such that it's easy to (re)start/stop individual namespaces. I might see if there's a way to re-use the same file much like net.<device> is a sym-link to net.lo.
-- Grant. . . . unix || die
