LinuxQuestions.org
Share your knowledge at the LQ Wiki.
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-20-2019, 07:21 PM   #31
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware (x86 and ARM)
Posts: 403

Rep: Reputation: Disabled

And I'm now a little more educated. Thanks for the info. I do appreciate it.

I did read the source, but... honestly, my mental stamina has been suffering for a couple weeks now, since I'm doing more (literal) heavy lifting at work. 9 hrs/day, 6 days per week.
 
Old 11-21-2019, 05:52 AM   #32
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Ubuntu LXDE (desktop/laptop)
Posts: 102

Original Poster
Rep: Reputation: 109Reputation: 109
So, getting back to the topic , does anyone have any bugs or issues to report with the new rc.inet1 or netconfig scripts?
 
Old 11-21-2019, 07:18 AM   #33
_peter
Member
 
Registered: Sep 2014
Location: paris
Distribution: slackware
Posts: 151

Rep: Reputation: Disabled
Quote:
Originally Posted by tadgy View Post
1) Testing the script against your current rc.inet1.conf to make sure things are still compatible[1].
hi tadgy, so far it works for me on a simplistic static ipv4 configuration

Code:
removepkg network-scripts-14.2-noarch-1.txz
installpkg network-scripts-15.0_ipv6_vlan_bond_b4360625-noarch-1_rlw.txz 
mv /etc/rc.d/rc.inet1 /etc/rc.d/rc.inet1.bak
mv /etc/rc.d/rc.inet1.conf /etc/rc.d/rc.inet1.conf.bak
mv /etc/rc.d/rc.inet1.new /etc/rc.d/rc.inet1
mv /etc/rc.d/rc.inet1.conf.new /etc/rc.d/rc.inet1.conf
/etc/rc.d/rc.inet1 eth0_restart
 
1 members found this post helpful.
Old 12-01-2019, 10:56 AM   #34
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Ubuntu LXDE (desktop/laptop)
Posts: 102

Original Poster
Rep: Reputation: 109Reputation: 109
I've corrected a bug in rc.inet1 which was preventing clean use of the *_restart operation.

The updated rc.inet1 script is in the repository linked from the first post in this thread - I'd be very grateful if more people could test rc.inet1 and netconfig to make sure things work as expected.

Cheers
 
Old 12-12-2019, 09:29 AM   #35
Fraks
LQ Newbie
 
Registered: Sep 2019
Posts: 6

Rep: Reputation: Disabled
I just wanted to drop by to thank you for the work you have done - I've been needing a way to configure bonds and aliases via configuration files only, and you're updated script helps in both cases and makes something that I have been struggling with for weeks now as easy as pie. I have a few minor remarks from the perspective of a relatively inexperienced user, and some that might help automating network configuration / usage.

Add a short/simple description on how to update the manpages
I've been doing some googling but I honestly have no idea and the topics that I find start talking about pretty advanced topics that I don't mind diving into, but only if I would know that at least I'm on the right track. If it would be possible, could you add a readme on how to handle the manpages? Doesn't have to be a complete step-by-step instruction manual, just enough to get us inexperienced users running in the right direction.

Have the default rc.inet1.conf contain an example of IPALIASES variable containing multiple IP addresses
Since the variable name is plural and considering how slave interfaces are handled in bonds makes it relatively easy to deduce that probably the IPALIASES is a space delimited list of CIDR notated IP addresses (which they are), but this could be made even more obvious by making it explicit in an example.

Make a remark that IPALIASES[x] are only created when IPADDRESS[x] is not empty (or restore "lost functionality"?)
The original script only creates interfaces when the entry has IPADDRESS filled in, but with aliases being handled slightly different, there is minor loss of functionality when compared to the old rc.inet1 script. Using the old script, I was able to create an "eth0:0" interface without having "eth0" up. Admittedly, this worked pretty flakey (which I attributed to limitations in ifconfig), so this might be one of those cases where I perceived functionality where there was none. It could also be that this approach is considered bad practice to the extend where you deliberately chose not to support it - I'm going to take your word on it either way, because honestly I have no idea.

To clarify the use case for the latter scenario: the only advantage it brings for me is consistent interface naming conventions regarless of whether actual aliasing is applied, which makes it (slightly) easier to automate against.

Support overruling the rc.inet1.conf file with other files
This again is mainly helpful for automation. In my use case, rc.inet1.conf contains a default configuration that ensures a sort of "fallback" or "starting" network setup. Once I installed the networking specifics of that computer, the networking will behave tailored to its specific deployment context and purpose. But there might be scenarios where the computer needs to be reinstalled. By isolating the "default" from the "custom" configuration files, reverting back to the default is a matter of toggling back to the default by removing the custom configuration(s) and doing an rc.inet1 restart. If you believe this to have value, then I wouldn't worry about the scope of a single file, I'd just read all *.conf files in a predetermined location and leave it to the user whether they want to write a file per interface, or one big file, or anything in between.

Last edited by Fraks; 12-12-2019 at 09:33 AM.
 
Old 12-12-2019, 04:45 PM   #36
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Ubuntu LXDE (desktop/laptop)
Posts: 102

Original Poster
Rep: Reputation: 109Reputation: 109
Quote:
Originally Posted by Fraks View Post
I just wanted to drop by to thank you for the work you have done - I've been needing a way to configure bonds and aliases via configuration files only, and you're updated script helps in both cases and makes something that I have been struggling with for weeks now as easy as pie.
Thanks for testing out the new script. The intent was to make it as simple as possible to configure each type of interface - I hope that's been achieved.

Quote:
Originally Posted by Fraks View Post
Add a short/simple description on how to update the manpages
If it would be possible, could you add a readme on how to handle the manpages? Doesn't have to be a complete step-by-step instruction manual, just enough to get us inexperienced users running in the right direction.
I'm not sure I understand what you're asking for?
Are you asking for a tutorial on how to write man pages? If so, I'm afraid that's beyond the scope of the project, so I don't know where/how it might fit in.

If I've misunderstood, please clarify?


Quote:
Originally Posted by Fraks View Post
Have the default rc.inet1.conf contain an example of IPALIASES variable containing multiple IP addresses
The rc.inet1.conf already has an explanation regarding the use of IPALIASES (in the examples section at the bottom):
Quote:
#IPALIASES[4]="192.168.5.10/24" # Set up an IP alias. A netmask may be given
# with a /<prefix> after the IP address - if
# not supplied, /24 will be used as default.
But I do concede that it isn't explicit about how to list multiple aliases in the one option. I'll try and clarify that better

Quote:
Originally Posted by Fraks View Post
Make a remark that IPALIASES[x] are only created when IPADDRESS[x] is not empty (or restore "lost functionality"?)
IPALIASES are created if there is an IPADDR or IP6ADDRS setting, or USE_DHCP is enabled. Basically, if any type of IP address is assigned to the interface, the IPALIASES are applied. This allows alias interfaces to be configured against both IPv4 and IPv6 addressed interfaces.

Quote:
Originally Posted by Fraks View Post
Using the old script, I was able to create an "eth0:0" interface without having "eth0" up.
I honestly can't see why or what benefit it would be to create an ethX:Y interface without having the underlying interface being up. In fact, I doubt that would even work - when the primary interface is down, so are all the alias interfaces.

Quote:
Originally Posted by Fraks View Post
To clarify the use case for the latter scenario: the only advantage it brings for me is consistent interface naming conventions regarless of whether actual aliasing is applied, which makes it (slightly) easier to automate against.
I'm not sure how alias interfaces are any more reliably named than the standard ethernet interfaces? If you configure the underlying interface with an IPv4 IP, it'll always have that IP. Then if you configure IPALIASES for additional IPs, they'll always have those IPs applied.

Quote:
Originally Posted by Fraks View Post
Support overruling the rc.inet1.conf file with other files
We already discussed (and discounted) the possibility of having 'external' files called from within rc.inet1 further up in the thread, as it was too vague as to where you'd call those scripts within rc.inet1 - people would also then be asking for pre and post interface scripts, etc, etc... it would become a mess very quickly.

Quote:
Originally Posted by Fraks View Post
This again is mainly helpful for automation. In my use case, rc.inet1.conf contains a default configuration that ensures a sort of "fallback" or "starting" network setup.
The intent of the new rc.inet1 is that you don't need to do configuration outside of rc.inet1.conf. Now it supports IPv6, bonding, VLANs and bridging in various configurations there should be little reason to need to configure networking elsewhere. But if you do need to (as discussed in the thread) there is rc.netdevice and rc.firewall for pre and post scripting.

If you have some really esoteric networking configuration requirements, your best bet is to write your own rc.inet1 that does exactly what you need - which, I'd wager, is within the capabilities of an admin who needs that esoteric networking anyway.

Thanks again for your testing!
 
Old 12-13-2019, 11:15 AM   #37
Fraks
LQ Newbie
 
Registered: Sep 2019
Posts: 6

Rep: Reputation: Disabled
Quote:
Originally Posted by tadgy View Post
Thanks for testing out the new script. The intent was to make it as simple as possible to configure each type of interface - I hope that's been achieved.
Yes, very much. Everything I am requested is just icing on the cake really, and some of the requested "icing" turns out to be better left off

Quote:
Originally Posted by tadgy View Post
If I've misunderstood, please clarify?
I can imagine, considering the ambiguity in my request. What I mean is that I expect that I need to update "something" on the slackware OS in order to use the manpages you have created, rather than getting the existing manpage. But I don't know how to replace the old manpage with your revised version?



Quote:
Originally Posted by tadgy View Post
But I do concede that it isn't explicit about how to list multiple aliases in the one option. I'll try and clarify that better
Thanks, that was what I tried to suggest here. It's really minor but still

Quote:
Originally Posted by tadgy View Post
I honestly can't see why or what benefit it would be to create an ethX:Y interface without having the underlying interface being up. In fact, I doubt that would even work - when the primary interface is down, so are all the alias interfaces.
As I said I am pretty new to all of this, so if you say that it probably doesn't even work, then I agree that there is no point to it.

Quote:
Originally Posted by tadgy View Post
I'm not sure how alias interfaces are any more reliably named than the standard ethernet interfaces?
Not more reliable, but more consistently The idea was that this way, I wouldn't have to think about how the interface needs to be called (eth[x]:[y] vs if no aliasing then eth[x] else eth[x] for the first one, and eth[x]:[y] for remaining IPs). But your arguments have already convinced me that whatever gains I might have gotten from my suggestion are vastly outweighed by the costs (if - as you stated - it is even technically possible).

Quote:
Originally Posted by tadgy View Post
We already discussed (and discounted) the possibility of having 'external' files called from within rc.inet1 further up in the thread, as it was too vague as to where you'd call those scripts within rc.inet1 - people would also then be asking for pre and post interface scripts, etc, etc... it would become a mess very quickly.
Fair enough, in this case I'm going to be stubborn though and adjust your script locally with my own "fix" as - for my specific use and context - it seems to be fairly easily built in. And if it ends up biting me in the behind, I'll remember your feedback

Quote:
Originally Posted by tadgy View Post
Thanks again for your testing!
You are most welcome!
 
Old 12-14-2019, 07:24 PM   #38
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Ubuntu LXDE (desktop/laptop)
Posts: 102

Original Poster
Rep: Reputation: 109Reputation: 109
Quote:
Originally Posted by Fraks View Post
I can imagine, considering the ambiguity in my request. What I mean is that I expect that I need to update "something" on the slackware OS in order to use the manpages you have created, rather than getting the existing manpage. But I don't know how to replace the old manpage with your revised version?
Oh, I get you now
Well, if you are using Robby's packages (linked from further up the thread), the man pages will already be in the correct place.

However, if you're using my git branch for the latest changes (there's a couple since Robby's last package, as of 20191215) you would need to gzip and copy the manpages into place in /usr/man/man5 and /usr/man/man8.

Quote:
Originally Posted by Fraks View Post
Fair enough, in this case I'm going to be stubborn though and adjust your script locally with my own "fix" as - for my specific use and context - it seems to be fairly easily built in.
Of course - that's the beauty of Open Source; you're free to modify it to suit your needs
 
Old 12-14-2019, 09:07 PM   #39
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware (x86 and ARM)
Posts: 403

Rep: Reputation: Disabled
Quote:
if you're using my git branch for the latest changes [...] you would need to gzip and copy the manpages into place in /usr/man/man5 and /usr/man/man8.
No need to zip/copy. You can view a raw man page in-place. If you have a man page file named "do-something.4s" in your current directory, uncompressed, then the command to view it is simply:

Code:
man ./do-something.4s
 
1 members found this post helpful.
Old 12-23-2019, 02:45 PM   #40
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 2,524

Rep: Reputation: 1192Reputation: 1192Reputation: 1192Reputation: 1192Reputation: 1192Reputation: 1192Reputation: 1192Reputation: 1192Reputation: 1192
New package link: http://slackware.com/~rworkman/netwo...arch-1_rlw.txz
Sources still at http://slackware.com/~rworkman/network-scripts/

This package has all of the changes as of today's git repo.
 
Old 12-24-2019, 11:29 AM   #41
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Ubuntu LXDE (desktop/laptop)
Posts: 102

Original Poster
Rep: Reputation: 109Reputation: 109
Does anyone have any more testing results they can share?

If things remain this quiet, I'm going to have to assume I did a good job!
 
Old 01-02-2020, 12:33 AM   #42
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,633

Rep: Reputation: 924Reputation: 924Reputation: 924Reputation: 924Reputation: 924Reputation: 924Reputation: 924Reputation: 924
In post #12:
https://www.linuxquestions.org/quest...0/#post6059051
I suggested & presented a routine to flush all standard and user added routing tables.
We discussed it and "agreed" that an advanced user should care about them on his/her own. Well, it turns out (just learned about it now), the "all mighty, all promising, cutting edge & revolutionizing, etc." new VPN wireguard makes use of adding additional routing tables:
https://www.linuxquestions.org/quest...nk-4175666878/
I have no experience with it for reasons mentioned in the thread above, but if you plan to support it, then I'd suggest to reconsider a routine to flush all the rules&routing tables crap, for both IPv4 & IPv6, at least for the rc.inet1 stop function.

Last edited by abga; 01-02-2020 at 12:36 AM. Reason: typo
 
Old 01-02-2020, 08:49 AM   #43
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Ubuntu LXDE (desktop/laptop)
Posts: 102

Original Poster
Rep: Reputation: 109Reputation: 109
Hey - thanks for the follow up

I'm still of the opinion that if the admin wants to use something like wireguard, which modifies the routing tables when it starts, it's either up to that application or the admin to return the system to the state it found it in.

Having rc.inet1 clear user defined tables still seems like interference with things beyond rc.inet1's remit - we can't support every possible configuration that may get set up on the system; rc.inet1 can only support things it sets up itself.

Cheers
 
Old 01-02-2020, 08:53 AM   #44
tadgy
Member
 
Registered: May 2018
Location: UK
Distribution: Slackware (servers), Ubuntu LXDE (desktop/laptop)
Posts: 102

Original Poster
Rep: Reputation: 109Reputation: 109
In other news, the scripts have now been suggested to Pat for inclusion in 15.0, so I'm hoping for some good news soon.
 
Old 01-02-2020, 09:38 AM   #45
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware (x86 and ARM)
Posts: 403

Rep: Reputation: Disabled
Re: my earlier derailing of the thread, I want to thank everyone for their clarifications about rc.firewall etc. All that info came in very handy setting up a firewall from scratch on my new Internet pipe.
 
  


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 02:48 AM
Modifications to rc.inet1, rc.inet1.conf and rc.wireless hba Slackware 1 12-07-2014 04:57 AM
Error for wireless request "Set Nickname" (8B1C) -- /etc/rc.d/rc.inet1.conf hellbillyJoker Linux - Networking 1 04-06-2010 08:24 PM
rc.inet1 doesn't give me a new DHCP IP jsmith6 Slackware 3 03-10-2008 05:38 PM
rc.inet1 and rc.inet1.conf edafe Slackware 0 02-16-2005 10:51 AM

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

All times are GMT -5. The time now is 05:34 AM.

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