LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 11-15-2019, 12:07 AM   #1
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Void (desktop/laptop)
Posts: 299

Rep: Reputation: 401Reputation: 401Reputation: 401Reputation: 401Reputation: 401
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.

Last edited by tadgy; 11-15-2019 at 12:17 AM.
 
Old 11-15-2019, 12:33 AM   #2
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 2,559

Rep: Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351
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
Source: http://slackware.com/~rworkman/network-scripts/
Feedback and suggestions are *definitely* welcome. There are almost surely corner cases, and we'd like to sweep out all of the corners before this goes to Pat.

EDIT: 20191120 - rebuilt package to reflect latest git changes

Last edited by rworkman; 11-20-2019 at 12:45 AM.
 
1 members found this post helpful.
Old 11-15-2019, 01:30 AM   #3
Mark Pettit
Member
 
Registered: Dec 2008
Location: Cape Town, South Africa
Distribution: Slackware 15.0
Posts: 617

Rep: Reputation: 297Reputation: 297Reputation: 297
If we are currently using the NetworkManager functionality, would that preclude helping you out with this new inet1 ?
 
Old 11-15-2019, 01:45 AM   #4
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Void (desktop/laptop)
Posts: 299

Original Poster
Rep: Reputation: 401Reputation: 401Reputation: 401Reputation: 401Reputation: 401
Quote:
Originally Posted by Mark Pettit View Post
If we are currently using the NetworkManager functionality, would that preclude helping you out with this new inet1 ?
If you're using NetworkManager, you'll not be using the functionality of rc.inet1.

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
 
Old 11-15-2019, 10:57 AM   #5
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware
Posts: 1,893

Rep: Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161
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
+++ /tmp/rc.inet1.new
@@ -61,7 +61,7 @@
   if [ ! -e /sys/class/net/${i%%[:.]*} ]; then # no interface yet
     if /sbin/modprobe -c | grep -v "^#" | grep -w "alias ${i%%[:.]*}" | grep -vw "alias ${i%%[:.]*} off" >/dev/null; then
       debug_log "/sbin/modprobe ${i%%[:.]*}"
-      /sbin/modprobe ${i%%[:.]*}
+      /sbin/modprobe ${i%%[:.]*} 2>/dev/null
       _DID_MODPROBE=1
     fi
   fi
@@ -71,7 +71,7 @@
 # set to 0 before that happens, so try to pre-load ipv6 here.
 if [ ! -e /proc/sys/net/ipv6 ]; then
   debug_log "/sbin/modprobe ipv6"
-  /sbin/modprobe ipv6
+  /sbin/modprobe ipv6 2>/dev/null
   _DID_MODPROBE=1
 fi
 # If we did any module loading in the blocks above, sleep for a couple of
@@ -600,6 +600,8 @@
 
 # Function to start the network:
 start() {
+  # Tell the viewers what's going to happen.
+  echo "Starting the network interfaces."
   lo_up
   virtif_create
   for i in "${IFNAME[@]}" ; do
@@ -610,6 +612,8 @@
 
 # Function to stop the network:
 stop() {
+  # Tell the viewers what's going to happen.
+  echo "Stopping the network interfaces."
   gateway_down
   for (( i = $MAXNICS - 1; i >= 0; i-- )); do
     if_down ${IFNAME[$i]}
I hope that helps!
 
Old 11-15-2019, 12:03 PM   #6
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Void (desktop/laptop)
Posts: 299

Original Poster
Rep: Reputation: 401Reputation: 401Reputation: 401Reputation: 401Reputation: 401
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).
 
Old 11-15-2019, 03:29 PM   #7
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware
Posts: 1,893

Rep: Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161
Quote:
I've applied your suggestions
Where to? I don't see changes in the link in the original post.
 
Old 11-15-2019, 03:48 PM   #8
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Void (desktop/laptop)
Posts: 299

Original Poster
Rep: Reputation: 401Reputation: 401Reputation: 401Reputation: 401Reputation: 401
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.

Last edited by tadgy; 11-15-2019 at 03:51 PM.
 
Old 11-15-2019, 05:21 PM   #9
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 2,559

Rep: Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351
They're in the ipv6+vlan+bond branch now, with a change to use "modprobe -q" instead of sending output to /dev/null
 
Old 11-15-2019, 06:27 PM   #10
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
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.
 
Old 11-16-2019, 02:47 AM   #11
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 2,559

Rep: Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351
Package link in my post above was updated; it's actually a completely rebuilt (and version bumped) package.
 
Old 11-17-2019, 06:16 PM   #12
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
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
+++ rc.inet1-mod
@@ -598,12 +598,26 @@
   fi
 }

+# Function to flush routing tables
+# Needs attention! - delete/flush also custom defined routing tables
+routes_flush() {
+  info_log "De-configuring routing tables"
+  /sbin/ip route flush table local
+  /sbin/ip route flush table main
+  /sbin/ip route flush table default
+  /sbin/ip route flush cache
+}
+
 # Function to start the network:
 start() {
   echo "Starting the network interfaces..."
+  routes_flush
+  lo_down
   lo_up
+  virtif_destroy
   virtif_create
   for i in "${IFNAME[@]}" ; do
+    if_down $i
     if_up $i
   done
   gateway_up
@@ -618,6 +632,7 @@
   done
   virtif_destroy
   lo_down
+  routes_flush
 }


@@ -637,6 +652,7 @@
   start
   ;;
 lo_start|lo_up) # Start the loopback interface:
+  lo_down
   lo_up
   ;;
 lo_stop|lo_down) # Stop the loopback interface:
@@ -644,6 +660,7 @@
   ;;
 *_start|*_up) # Example: "eth1_start" (or "eth1_up") will start the specified interface 'eth1'
   INTERFACE=$(echo ${1} | /bin/cut -d '_' -f 1)
+  if_down $INTERFACE
   if_up $INTERFACE
   gateway_up
   ;;
On the routes_flush() function, it needs also to list and handle (flush) all the user defined routing tables (if any), other than the default/reserved ones, that are already handled.
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
I remember discussing and expressing my PoV on the network (& services) configuration rc.inet1 & rc.inet2 under Slackware and I proposed an extra rc. - call it rc.advanced-network or rc.inet1-point-5 (just to fit between rc.inet1 and rc.inet2) for handling the advanced network configuration. Advanced configuration should comprise vlans, bondings, virtual interfaces/tunnels and advanced routing that the average Slackware user doesn't really care about. Well, VPNs are increasingly used/popular.
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.
 
1 members found this post helpful.
Old 11-17-2019, 09:41 PM   #13
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Void (desktop/laptop)
Posts: 299

Original Poster
Rep: Reputation: 401Reputation: 401Reputation: 401Reputation: 401Reputation: 401
Quote:
Originally Posted by abga View Post
On my proposal from post #10
I've implemented the flush from your post as I could see that flushing the interface to create a clean starting point was a good idea. It's in the git tree now

Quote:
Originally Posted by abga View Post
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.
I've had a chat with Robby regarding handling of user defined routes and tables..
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:
Originally Posted by abga View Post
Code:
[...]
 # Function to start the network:
 start() {
   echo "Starting the network interfaces..."
+  routes_flush
+  lo_down
   lo_up
+  virtif_destroy
   virtif_create
   for i in "${IFNAME[@]}" ; do
+    if_down $i
     if_up $i
   done
   gateway_up
@@ -637,6 +652,7 @@
   start
   ;;
 lo_start|lo_up) # Start the loopback interface:
+  lo_down
   lo_up
   ;;
 lo_stop|lo_down) # Stop the loopback interface:
@@ -644,6 +660,7 @@
   ;;
 *_start|*_up) # Example: "eth1_start" (or "eth1_up") will start the specified interface 'eth1'
   INTERFACE=$(echo ${1} | /bin/cut -d '_' -f 1)
+  if_down $INTERFACE
   if_up $INTERFACE
   gateway_up
   ;;
Your suggestions above make all the *start functions the same as restart, essentially - I don't see the point of that? It's the responsibility of the admin to run the script with the correct arguments.

Quote:
Originally Posted by abga View Post
I remember discussing and expressing my PoV on the network (& services) configuration rc.inet1 & rc.inet2 under Slackware and I proposed an extra rc. - call it rc.advanced-network or rc.inet1-point-5 (just to fit between rc.inet1 and rc.inet2) for handling the advanced network configuration.
I pitched this idea to Robby and (without wishing to speak for him), he wasn't keen.
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:
Originally Posted by abga View Post
Advanced configuration should comprise vlans, bondings, virtual interfaces/tunnels and advanced routing that the average Slackware user doesn't really care about. Well, VPNs are increasingly used/popular.
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.
I'm in favour of having one single place where all networking is configured. The syntaxes that I've added to rc.inet1 are quite simple and in keeping with the standard Slackware way of configuring networking. Keeping it all confined to one configuration file just makes sense to me.

Quote:
Originally Posted by abga View Post
but rc.inet1 is getting too complex
It's less than 650 (give or take comments) lines - not a huge project

Cheers!

Last edited by tadgy; 11-17-2019 at 09:45 PM.
 
1 members found this post helpful.
Old 11-18-2019, 12:34 PM   #14
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
@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.
 
Old 11-18-2019, 06:19 PM   #15
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 2,559

Rep: Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351
Quote:
Originally Posted by abga View Post
@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
I do not recall that interaction. Are you sure you don't have memory corruption? ;-)
Seriously, sorry :/ I have no recollection at all of that exchange though, so no negative opinion was formed here :-)
Quote:
I use my own scripts because I like them simpler, tailored and more "radical" - do the f... job and don't ask/check why.
That has also been my typical method for doing anything that isn't supported by the stock scripts - just replace them wholesale and keep on trucking.
 
1 members found this post helpful.
  


Reply

Tags
bond, ipv6, networking, rc.inet1, slackware, testing, vlan


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] slackware current, typo in new rc.inet1, also is gtk3 now required for firefox? pataphysician Slackware 23 05-24-2017 01:48 AM
Modifications to rc.inet1, rc.inet1.conf and rc.wireless hba Slackware 1 12-07-2014 03:57 AM
Error for wireless request "Set Nickname" (8B1C) -- /etc/rc.d/rc.inet1.conf hellbillyJoker Linux - Networking 1 04-06-2010 07:24 PM
rc.inet1 doesn't give me a new DHCP IP jsmith6 Slackware 3 03-10-2008 04:38 PM
rc.inet1 and rc.inet1.conf edafe Slackware 0 02-16-2005 09:51 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 05:41 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration