Red Hat Bugzilla – Bug 25775
IPv6 initscripts fixups
Last modified: 2014-03-16 22:18:36 EDT
IPv6 initscripts had a couple of syntax errors in there. Also, there were a few
places where wording could have been much better.
Created attachment 8799 [details]
a few fixups
Will be in 5.61-1; thanks!
I finally backpatched most of your changes in my current set. Looks like that
for 5.60 not the most current ones were taken.
Because of my set is still a working beta to gamma version, it's easier for
maintenance to keep one set up to date. For that reason, I've backpatched and
add some "already-in-the-pipe" changes.
I've tagged all RH7, Info and Debug lines and create a script to strip such
You will find a current snapshot at:
Also I add some information for "sysconfig.txt"
Perhaps you'll try to sync it now with your current state and send me diffs
afterwards back to me. It's easier to maintain one set instead of some...
+As for moving the stuff into /etc/sysconfig/network, one of the
+reasons this was able to be added now is that there wasn't a chance
+of causing any problems if you didn't use it; if it's in
+that's not the case (Yes, I'm paranoid.)
Ok, I do not change the current behavior now. But perhaps I modify some tunnel &
routing configuration details, but all changes will be stay in the "IPv6
OK, some comments.
- From a distribution standpoint, testing that the tools are ipv6 capable
is pointless; they *should* be, and it requires the user doing something
odd to break this.
- As I thought I mentioned; echoing stuff into /proc is generally not
how we handle forwarding stuff anymore; you should use /etc/sysctl.conf
Is it necessary that these get processed here?
- Please be careful about the $ in front of the echo statements; a few
got removed. Also, you may want to see bug 26502.
Here's the patch I'm considering committing on top of your changes.
Created attachment 9319 [details]
changes on top of changes. :)
> - From a distribution standpoint, testing that the tools are ipv6 capable
> is pointless; they *should* be, and it requires the user doing something
> odd to break this.
Aggreed, marked for "rh7"-stripper
> - As I thought I mentioned; echoing stuff into /proc is generally not
> how we handle forwarding stuff anymore; you should use /etc/sysctl.conf
Was already on my todo-list, done now.
> Is it necessary that these get processed here?
I think so, because sysctl.cnf is AFAIK only used on bootup. But forwarding needs to be switched per device on up/down also for security reasons.
IMHO, forwarding per device should be 1) configurable 2) easy changeble. Global forwarding must be switched also to resolve dependencies.
I do not know about the current sysctl-defaults, but without switching the forwarding in initscripts it is possible that not all (i.e. tunneling) is working
> - Please be careful about the $ in front of the echo statements; a few
> got removed
Hopefully all backpatched.
> Also, you may want to see bug 26502.
Sorry, no access, even in "logged in" modus.
> Here's the patch I'm considering committing on top of your changes.
Backpatched the fixes, but not the "forwarding control issue. Should I tag them with another key for the meantime?
And now the historic versions are automatically generated every hour (if changes are applied in "current") and stored at
Other fixes to 2001-02-07 version:
prefixlength of numbered tunnel is set to 127 (128 was wrong...)
Hope this helps and the synchronize levels increases...
OK, here's the only changes I have now. Ignore the whitespace ones.
The option -> parameter conversion is what bug 26502 was about. It's from
one of our translators.
Created attachment 9359 [details]
more minor tweaks.
This will be added in 5.63-1.
Ok, I've backpatched them now into my set. I hope you're not becoming desperate because I've removed all the backward compatibility for a extra prefix
length and removed some outdated lines. But I'm hopefully that the scripts are in a stable state now (if no bugs are in..and rawhide has no other
improvements - which are welcome - for them).
You will find the new snapshot on my FTP server, too.