Initscripts - Keeping It Simple
I've been reviewing Roy Marples' 0.5.0 release of OpenRC for inclusion in Funtoo (we're currently at 0.4.2,) and the big change with 0.5.0 is that Roy has ripped out the existing networking functionality, and replaced it with something a lot simpler.
I think this is a step in the right direction, but I'm leaning towards "going all the way" and ripping out networking support entirely, in favor of having Funtoo-supplied /etc/init.d/net.* templates that actually call the route/ifconfig/ip/vconfig/brctl commands directly, and users can modify to suit their needs.
Why do this? Here are some reasons:
- WYSIWYG - no need to figure out some kind of distro-specific network configuration layer that is supposed to make things easier for you.
- It encourages (but does not force) users to become familiar with the ifconfig/ip/route commands, which is a good thing.
- It is the most flexible option, since it allows you do get as freaky with your network as you want.
- It allows users to leverage the dependency-based functionality in the initscripts for their own purposes - the dependency functionality was designed to be used by end-users.
- Theoretically faster.
- Self-documenting.
- Simpler.
- Reduces footprint of the initscript code (reduced maintenance.)
Now, here are some negatives, along with how I hope to address them:
- It's more complicated - Yes, slightly, initially, which means Funtoo network documentation needs to be written to help users. Several easy-to-use /etc/init.d/net.* samples need to be available for beginners. That will make things easy for networking newbies.
- Configuration gets stored in /etc/init.d rather than /etc/conf.d (where some might say it "should" be) - This, I do not really agree with, so I don't see it as a significant negative. I don't think that /etc/conf.d should be a mandatory design rule for storing configuration. For networking, putting configuration in /etc/init.d is simpler - users who like /etc/conf.d can still use it, and I can have our templates be usable with /etc/init.d or /etc/conf.d for configuration storage. And designing complex network configuration scripts just for the sake of getting all network configuration stuffed inside variables in /etc/conf.d is not a winning strategy.
- Not desktop-friendly - Some might say that Gentoo and OpenRC network configuration scripts isolate the user from the complexity underneath, and are thus better. In theory, this may be right - in reality, it creates another distro-specific configuration layer you need to learn, and developers need to maintain. And it's not significantly easier, really.
So, I think this is the right way to go. Let me know what you think.
10 comments:
I completely agree. I already have to do part of my config in conf.d/local anyways because openrc always does dumb things to my netmounts when I have to restart the wireless to get it to reconnect to my crappy wireless AP. If you need help with some simple example wireless stuff or testing, let me know.
@Brian- cool :) And having some sample wireless net.* scripts would be a big help as I'm not currently using wireless under Funtoo.
I think it sounds like an excellent idea. Learning more of the guts of a distro sounds good, besides isn't that a part of how Gentoo is supposed to be? :-)
I'm all for putting them in /etc/init.d
The benefit of understanding ifconfig outweighs any learning curve.
Network scripts are something users should definitely get their hands into, as there are so many different setups. Complex stuff that "tries to do it all" just frustrates people who can't read through and understand the scripts. Well-documented examples help teach, yet not frustrate the user, and make the scripts very simple and unique to the setup, and very easy to maintain.
I like most of the ideas that you bring up for OpenRC, and hope that maybe the changes will be merged into Gentoo as well. One thing I don't understand is moving the configuration to /etc/init.d from /etc/conf.d. Why is this important and/or desirable? Sorry to sound dumb, but I thought /etc/conf.d/ was made for configuration files.
Kalos, the main point about /etc/conf.d is that the current systems are designed to be totally driven from /etc/conf.d, and set up your network for you. You are not supposed to modify the scripts in /etc/init.d. I'd like to move away from this approach.
Daniel, thank you for clearing that issue up for me! :)
Do you mean setting actual routes and ip addresses in the init.d script? If so that's a terrible idea but I doubt that's what you mean.
If it is what you mean, think of it this way:
A program shouldn't mix code and data in the same space just like certain exploits take advantage of things like that to execute data. That's not a good analogy but there's a reason why configuration "data" is not in the same place with script "code".
This is an awesome idea. I've never really liked /etc/conf.d . /etc/* belongs to me, not the distro. I use rcs to keep the distro /etc/ files for upgrade comparisons (hey, look a new configuration option), but ultimately the files are likely very different from distro supplied ones for just about everything.
Configuring networks directly without the distro abstractions will ultimately save time on the learning curve, as you have to use these commands occasionally anyway, and allows for interesting use cases with special runlevels and such.
Post a Comment