agriffis: this is as per our discussion via IRC. I've made the change for to get VLAN ids via vlan_IFACE (and support the old name for backwards compatibility). I think the (pre|post)(up|down)_* functions I've added to the conf.d/net have a definate home inside the net.eth0 instead, and just have their invocation inside the conf.d/net functions. bug #52653 adds functionality using the functions for wireless :-), so having an easy plug-in infrastructure for the functions would make sense.
Created attachment 34322 [details, diff] patch for features
Woah! I see that loads of stuff went into conf.d/net in baselayout-1.10.1 I'm thinking that it's going to confuse users something cronic! IMO, a better way would be to have an init.d/net.script.d directory and place small scripts in there for use in the preup() style functions - including my wireless script. Then, net.eth0 can load each script in the init.d/net.script.d directory as it finds it. This would give flexibility to add more stuff easy and make maintaince much easier. Thoughts?
agreed, a net script directory would be best. for which files from there are used i say have a variable net_modules="bonding wireless" and that then sources the bonding and wireless scripts :-). each script provides SCRIPTNAME_(pre|post)(up|down) etc. as required. and then the conf.d/net functions just use them.
i don't know if agriffis is on base-system
ssh gentoo cat /var/mail/alias/misc/base-system ;-)
I've mentioned this on #gentoo to seemant, who forwarded me to this bug. I've got a few points: - that patch frightens me, particularly where it supports randomization of mac addresses. Could someone please explain to me why this should ever be in a distribution? -It seems like we're headed toward so many many different scripts that all of the simplicity previously attractive about /etc/conf.d/net will be lost. -A few months ago, I extended my networking scripts to support tuntap devices and bridging in a generic fashion for use with user mode linux. I've got a few notes and my scripts up at http://jjoseph.org/linux-work/uml_gentoo and would like suggestions for integration into these proposed net changes. Thanks, Jacob
as for supporting randomization of mac addresses, I have two cases where I use mac-changer. firstly at home, to avoid my ip changing when i change network cards (cable modem), i present the same mac address always (originally belonging to an isa network card i was using 4 1/2 years ago). secondly, i know this case is not supposed to happen, but certain consumer network ethernet card manufacters have been re-using their old mac address blocks in their new cards recently. this really surprised me, but it does seem to have happened. i only found it as i had a really old card on a network with a new card present as well. as uberlord proposed and I agree with, i think having a netscripts dir is one of the only ways to avoid execssive complexity being present in the net config file. i'll look at your scripts later tonight, and probably hack up a bridging script for use with this baselayout (mainly because i need one tommorow).
I've taken a closer look at your patch. * I'm still a pretty ardent believer in distributions not encouraging such network-unfriendly things as changing mac addresses. This has great potential to wreck great network havoc and in my mind falls in the category of bad things to do. Of course, there are exceptions where it might be nice, but this is one function that should not be provided. Of course, with pre and post scripts, it's no problem to accomplish on an individual level. * One of my goals with my own modifications was to avoid creating too many special keywords. At a quick glance, I see "vlans_xxx", "mac_xxx", "slaves_xxx", "ipaddr_xxx"(which is different from ifconfig?), "dhcpcd_xxx", "iproute_xxx", and "ipaddr_fallback_xxx". Of course, most of these would be optional, but it's just as bad to have to go find documentation to figure out what's allowed. It's probably worse to have it documented inline. * With creating a network scripts directory, what would be the logical organization? I'm assuming the bare minimum would be "pre_eth0", "cfg_net0", "post_eth0" or some such. Going with this, however, seems to loose all of the great benefits of a single, simple configuration file in /etc/conf.d. I a single source to be particularly attractive in contrast to a million config files in /etc/sysconfig/network-scripts, as is the case with redhat/fedora. * If we do move toward a configuration directory, what benefits will we have over redhat's scripts. If they are few, why write our own? -Jacob
I'm starting to wonder if Gentoo ought to have dead-simple network initscripts. Just a bash script with all the real commands in it. "Advanced" users can add fancy commands, while simple users can make themselves happy with one of two templates shown in comments (one for static, one for dhcp). Consider that we can bring a network up in just a few steps: modprobe tulip ifconfig eth0 192.168.15.15 netmask 255.255.255.0 up route add default gw 192.168.15.1 eth0 Also notice that our config files, and the code to check the vars, etc, are getting much longer than that. I've neglected the start/stop/restart stuff, but that won't add much. Error checking is always good, but you'll notice in my suggested script that I'm not sending errors to /dev/null. I am playing devil's advocate here -- I'm not certain this is a good idea. However, if we can't demonstrate a better solution (easier to read, easier to customize, transparent debugging, etc), then maybe we should give up and take the most straightforward route. I also wonder why one would *randomize* a MAC. I can understand that one might want to set a MAC to some value (though maybe this shouldn't be made *too* easy). But randomize? -Paul Komarek
as for a network scripts directory, my thoughts on it are that it should only contain scripts, eg /etc/netscript.d/{bonding,macchanger,wireless} and each one can provide functions: SCRIPTNAME_FUNCTION where SCRIPTNAME in bonding,macchanger,wireless and FUNCTION in preup,predown,postup,postdown the /etc/conf.d/ would be JUST configuration variables, and your custom functions (that would call the bonding/macchanger/wireless stuff as needed). i'd keep the custom functions in conf.d/net very small, and instead put documentation about using extra modules elsewhere. the idea is to have the functionality available. lots of packages can be used for very subversive purposes, much worse than macchanger, but there are many more good uses of the packages. don't take away the package/configuration options just because they can be used for evil. there will not be seperate functions for the interfaces in baselayout, this has been discussed many times and there are strong things against it (just do a case statement inside your preup if you want it). i'll see about coding up an initial implementation of the netscripts tonight if i get a chance. i've used redhat's scripts many times before, and i definetly don't like them due to their lack of flexibility.
I have some issues with the link detect function. It turns out that the aliases are made after preup so ethtool just says "No such device" for everything. You might also want to do a "> /dev/null" after the grep command. Also, for some reason, ethtool keeps on saying "No information available". I suggest that you try mii-diag (get it with emerge "mii-diag"). There originally was a tutorial in the forum about this at http://forums.gentoo.org/viewtopic.php?t=38964
Of course in stable versions it would save some seconds during startup if preup_linkdetect = nolink would abort at least dhcp, maybe also ifconfig_fallback. But anyway it seems like youre making a good effort.
Thomas: this was done at one point when this work was still very experimental, but it was found that a good number of cards don't support link status checking, and doing it by default broke networking for a lot of folk, so it's best that we allow people the ability to do it, but not have it on by default.
Created attachment 41131 [details, diff] Patch to net init script to allow configuration of tun/tap and bridge devices
I've gotten a chance to rewrite my changes to the net scripts to add tun/tap and bridging support. This does require a few changes to the default init script to support a few new options. See the patch for details. You'll need the usermode-utilities package for tunctl. brctl is provided by bridge-utils. Of course, kernel support for both is a must. Since I am creating a separate /etc/init.d/net.IFACE script for each interface, I do not believe the vlan stuff is an appropriate model for what I need to do. I also toyed with creating a type of interface (ifconfig_IFACE = "none") that would cause only a postup script of my choosing to be run, but this sure seems like a hack. I much prefer a solution integrated into the core networking scripts. Previously, I'd used iface_IFACE to denote the 'type' of interface, whether it be dhcp, tuntap, or bridge. I had added ifconfig_IFACE to then pass the appropriate interface perameters. Since the first has now replaced the latter, I've been forced to add another option type_IFACE. This code is run only if not using dhcp. I tend to think the two should not be mutually exclusive, but this suits my needs well. Incidentally, I'm not sure I agree with hijacking ifconfig_IFACE=dhcp to mean something special. Perhaps another keyword along the lines of 'type' should be used for dhcp as well. The old iface method was good in this respect. Note that I am not aware of a way to query whether an interface is a tuntap or bridge device before stopping it. As such, I've changed iface_stop() to not try a "simple down" and always try to kill the interface using tunctl and brctl. Overall, I'd like some feedback as to what more is required to get functionality my patch provides into baselayout. Thanks. -Jacob
Jacob: nice work. Agriffis: perhaps now it really is time for an extensible system so each of these extra sets of functionality don't need to live in net.eth0, but could rather be with the relevant packages. Between the patches on bugzilla, we have: vlans bonding mac-changing bridging tunnelling wireless auto-config
baselayout-1.11.x has the fully modularized extensible network configuration system. It has been pmasked for quite a while but went ~arch tonight vlans, bonding, mac-changing, and wireless are all in baselayout-1.11.x Myself or Uberlord can write a module to include the concepts in this bug's patch, unless one of you wants to write it first. The modules in /lib/rcscripts/net.modules.d should provide enough examples, I hope. Regarding putting modules in packages instead of baselayout, I think we'll keep them in baselayout for the 1.11.x stream. That way if we change the API it's easy to change all the modules. Perhaps we'll group modules with packages at the end of the 1.11.x stream once we feel like the API is holding under pressure. Sorry it has taken so long to integrate these features. Designing the modular net-scripts was not an easy job; we have Uberlord to thank for stepping up to the plate.
It doesn't look too hard to write a module to incorporate the patches features :) It's probably easier for either me or Aron to make the module as we know the current API for net-scripts - although it should be easy to pickup as it's quite well documented
I've created tuntap and bridge modules which are now in CVS They will be in baselayout-1.11.6
Fixed in baselayout-1.11.6
*** Bug 72392 has been marked as a duplicate of this bug. ***
When will the new baselayout be put into use? There seems to be a lot of features in limbo over this release.
Whats in limbo? And do you mean released into stable? Gentoo policy is as follows "When a package version has proved stable for sufficient time and the Gentoo maintainer of the package is confident that the upgrade will not break a regular Gentoo user's machine, then it can be moved from ~ARCH to ARCH. An indication of the package's stability would be no verified or unresolved bug report for a month after the version's introduction. It is up to the maintainer of the package to deem which versions are stable or if development versions should be in package.mask or left in ~arch." The main issue here is that we've introduced a lot of new features - especially for networking. That being said, we're still relying on bash and readline becoming "stable" as we use some of their new functionality.
