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