Request for testing: new rc.inet1
Hi,
I have been working on updating rc.inet1 to add functionality such as IPv6, VLANs and link aggregation (bonding), and fixing a couple of niggles (like using /<netmask> in IP aliases configuration). The work has been placed on Robby Workman's git server in the 'ipv6+vlan+bond' branch, available here: https://git.rlworkman.net/slacknetse...%2bvlan%2bbond We need some real world testing of the script before it gets to Pat, so here's what I need: 1) Testing the script against your current rc.inet1.conf to make sure things are still compatible[1]. 2) Testing of the IPv6, VLAN or bonding features to see if they fit your needs or have any bugs. There are README.{IPv6,VLANs,bonding} files available in the repo - it would be a good idea to read them if you intend to test. There are pre-requesite configurations necessary[2] (see the implementation section in the READMEs) in order for things to work correctly. You should (at least) put the modprobe.d/ files into the correct location, and copy rc.inet1 and rc.wireless into place in /etc/rc.d/. Check the new rc.inet1.conf for updated instructions on new features. Code critique is not required :), unless it specifically relate to a bug. What we need in testing is how it performs in real world situations. Cheers! [1] - If you rely on IPv6 auto configuration (aka, SLAAC) you must now enable that feature for the interface you want to use it on - it is no longer on by default. [2] - Possibly including a reboot if you already have the 'ipv6' or 'bonding' kernel modules loaded and want to test that functionality. |
Let's make this easy, shall we?
Code:
Package with modprobe configs already there: http://slackware.com/~rworkman/network-scripts-15.0_ipv6_vlan_bond_b4360625-noarch-1_rlw.txz EDIT: 20191120 - rebuilt package to reflect latest git changes |
If we are currently using the NetworkManager functionality, would that preclude helping you out with this new inet1 ?
|
Quote:
If you wanted to help out, you could disable NM and try out some configs with rc.inet1, or boot a Slackware VM and try out some esoteric configurations :) |
Corner case issue: the user has explicitly disabled ipv6. The result is modprobe spew errors when running the script. There also is no notice to users in the boot sequence the script is running, which would help debugging. Possible proposed patch:
Code:
--- /tmp/rc.inet1 |
Thanks upnort :)
I've applied your suggestions, except for the first modprobe quieting - that one should really show errors to the user if it fails because the user would have explicitly added a modprobe alias for the interface (and we grep out the "off" ones). |
Quote:
|
I've pushed them to Robby's git repository (in the tadgy-for-merge branch) linked in the first post :)
Edit: Sorry, should have made it clearer - you'll need to switch branches from the one linked in the first post. Go to the summary tab and look for the above branch - that one will get merged into the main branch when Robby notices it. |
They're in the ipv6+vlan+bond branch now, with a change to use "modprobe -q" instead of sending output to /dev/null
|
Played a little with the new rc.inet1, mainly on static IPs & DHCP and it looks OK.
I'd like to suggest to flush the configuration of the devices by default - a general rule - before any attempt to configure them, even if they are not up. That's just to avoid having a secondary IP on the interface, that could have been configured before running the rc.inet1 script. |
Package link in my post above was updated; it's actually a completely rebuilt (and version bumped) package.
|
On my proposal from post #10, if the restart is used, then the configuration is flushed individually on all the adapters. But that doesn't happen if rc.inet1 is launched without parameters and leftovers (secondary IPs or user defined routes & routing tables) are not handled.
With iproute2 and kernel advancements things are getting a little more complicated, unfortunately. I tried hard not to butcher the proposed rc.inet1 and instead made use of the available functions + defined an incomplete one for handling the user defined routes (still lacks handling extra user defined routing tables). Code:
--- rc.inet1 http://linux-ip.net/html/routing-tables.html There is some inspiration on how to identify them: https://serverfault.com/questions/61...l-route-tables The following "magic" line will list only user defined routing tables that can be sequentially flushed: Code:
/usr/sbin/ip route show table all | grep -Po 'table \K[^\s]+' | grep -v "local" | sort -u Keep rc.inet1 simple (already way too long & complex) and clean (robust too - good starting point for flushing all the crap the user has tried) for basic networking configuration - loopback & HW interfaces, update it to handle IPv6 and let the more advanced users focus on a different rc. file if they feel like knowing what they're doing. Don't get me wrong, I like rc.inet*, even if I'm not using them, but my own (few lines) network setup scripts, and I'm happy with them provided by Slackware as clear text transparent ways to configure the Network & Services. I also understand the desire to keep the conf in only one place (rc.inet1.conf) but rc.inet1 is getting too complex and from my PoV advanced network config is an additional scope that should be handled separately. |
Quote:
Quote:
We believe that it isn't the job of rc.inet1 to handle every contingency that might have happened outside of the control of rc.inet1. If a user has gone to the lengths of defining custom routes and/or tables, then they should be expected to handle the clean up of those things themselves. Quote:
Quote:
It would be simple enough for a competent admin to modify rc.inet1 with custom networking set up themselves - and if they're doing that on a stable release, it's highly unlikely that rc.inet1 would be updated during a stable cycle to wipe out changes. Conversely, if you're running current, you should expect things to change and have to deal with the pain of maintaining your custom script yourself. Quote:
Quote:
Cheers! |
@tadgy
Thank you for your reply, details and Robby's feedback on my proposals. Actually I'm happy that you took the effort to intermediate the communication to Robby, because the last time we directly interacted, I was suggesting a trivial format change for the Slackware changelog - making it more human friendly (put the package action in a clearly defined and spaced column to easily spot the "Added" tag), I felt like I was taken as a machine/bot :) First time I looked over the new rc.inet1 I vaguely recalled an issue a Slackware user reported with DHCP and went looking if the interfaces are flushed before any configuration attempts. I was surprised to learn that it wasn't the general case and only calling the function if_down would do it. Meanwhile I found the thread reporting the DHCP issue: https://www.linuxquestions.org/quest...5/#post5816281 https://www.linuxquestions.org/quest...ml#post5816372 https://www.linuxquestions.org/quest...ml#post5816535 - the suggested change from the last link made its way into the -current rc.inet1, after a while, attributed to some other user. On a second closer look, literally fighting my way through the chain of conditional statements (those are the ones making the script complex), I started butchering the script and simplify it, instead of "what if" & "what if" & ... etc. I adopted the "why care" idea and just flushed the conf before re-configuring, I mean, if the "admin" called rc.inet1 and asked to bring up an interface, why care about its state? Who's the boss there BTW? I stopped when I realized that I could use the already available if_down function, not the optimal case, and only slightly modifying the original script. Thus, in my first paragraph from post #12 I already mentioned (indirectly) I brought the script behaving as always called with the restart parameter. I agree that the admin should use the script properly and always use restart if he/she wants to restart/reconfigure the network and hope it will always be the case. LQ is here to help the ones that don't conform ;) On the other points & hints, well, I'm usually setting up complex networking configs and maybe some of these recommendations were biased by my experience. I use my own scripts because I like them simpler, tailored and more "radical" - do the f... job and don't ask/check why. Never mind my inputs here, just carry on with your good work. :) |
Quote:
Seriously, sorry :/ I have no recollection at all of that exchange though, so no negative opinion was formed here :-) Quote:
|
All times are GMT -5. The time now is 02:03 PM. |