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.

So, getting back to the topic , does anyone have any bugs or issues to report with the new rc.inet1 or netconfig scripts?

hi tadgy, so far it works for me on a simplistic static ipv4 configuration

1 members found this post helpful.

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

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.

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.

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?


The rc.inet1.conf already has an explanation regarding the use of IPALIASES (in the examples section at the bottom):
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

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.

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.

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.

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.

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!

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

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?



Thanks, that was what I tried to suggest here. It's really minor but still

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.

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).

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

You are most welcome!

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.

Of course - that's the beauty of Open Source; you're free to modify it to suit your needs

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:

1 members found this post helpful.

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.

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!

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.

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

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.

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.