SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
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.
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.
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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:
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
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.