On Sat, 2007-07-21 at 17:22 -0400, Mike Frysinger wrote: On Saturday 21 July 2007, Roy Marples wrote: > > On Sat, 2007-07-21 at 21:28 +0100, Roy Marples wrote: > > > On Sat, 2007-07-21 at 22:22 +0200, Tobias Klausmann wrote: > > > > Is there a common bug to report snags to? I've hit one: > > > > /etc/init.d/net.eth0 used to be a symlink to net.lo. After > > > > installing, it was gone (I figure it went with baselayout-1). > > > > Luckily, I have direct console access, otherwise the machine > > > > would have been gone after the reboot. Definitely something to > > > > yell about during merging. > > > > > > We don't ship with net.eth0 because there is no guarantee an interface > > > called eth0 exists. net.lo (net.lo0 in *BSDs) always exists so we just > > > ship that. > > > > One very good idea would be to get udev to create any net links that do > > not exist to net.lo > > > > Then we truly have plug and play :) > > indeed, that'd be sleeky and sexy ... go file a bug ;) > -mike Best make it configurable though :)
by definition, files in /etc/udev/ are configurable since they're CONFIG_PROTECT-ed
This might not be such a good idea for some WLAN drivers (such as rt2500), besides wlanX it would also create a bogus wmasterX symlink to net.lo which should not exist, it's not a real interface.
Which is why I said there should be a configure option to turn it on/off. Or maybe a masking based on name. BTW, the rt2500 driver only makes the ra0 interface. It's the rt2x00 driver that makes these, and you only have upstream to blame for that crappy idea.
Isn't this issue hit only when upgrading baselayout? If so, just preserving any existing symlinks to net.lo* should be sufficient. The current behavior of baselayout-1 is bug on its own (of owning net.eth0). So staying focused on the initial report (changing the subject of this bug) will be easier and quicker, IMHO.
For madwifi (and hopefully the others), `ip a` shows link/ieee802.11 for the controlling interface wifi0. So udev can take this into account and skip the creation of the link.
Perhaps someone can attach either working code (using sysfs) or at least udevinfo -a -p /sys/class/net/DEVICE where DEVICE is one we should not create a link to.
I don't know if it's related, but I have a problem with the inits scripts. I remove from boot and default net.eth0 and net.wlan0 but both are still load and configured. I also remove net.lo but the problem still present. This is a problem because I ran in a laptop and when both interface are up, for some reason, the wired one have sort of "preference", and until I shoot down net.eth0 manually I don't have any connection. This is a VERY big problem if you have users that don't have permission (or you don't want to have) as they can't shoot down net.eth0. I run baselayout-2rc2_r1 in a ~x86 machine.
(In reply to comment #6) > Perhaps someone can attach either working code (using sysfs) or at least > udevinfo -a -p /sys/class/net/DEVICE where DEVICE is one we should not create a > link to. > My madwifi created wifi0 interface has these values, which are different from the real interface ATTR{type}=="801" ATTR{features}=="0x0"
(In reply to comment #8) > > My madwifi created wifi0 interface has these values, which are different from > the real interface > ATTR{type}=="801" > ATTR{features}=="0x0" > First idea: Only auto-create the net.* link if ATTR{type} is "1".
It looks like we never came up with a rule for this.
Udev starts while / is read only, so there is no way for it to create links in /etc/init.d at that point. It seems that This will require a udev rule and a new init.d script added to the boot runlevel on linux systems to trigger that rule.
Creating links in the directory also requires that rc-update -u gets run afterwards, to calculate the init dep tree again.
*** Bug 398203 has been marked as a duplicate of this bug. ***
All, I'm thinking more about this, and I think we can do it without involving udev by adding a script to OpenRC that checks for network devices in /sys/class/net and creates the symlinks based on what it finds there. Or, since the issues are coming more from the isos, we may be able to add this OpenRC script to the livecd-tools package and not install it on systems. Thoughts?
Created attachment 310445 [details] netlinks.in this is a prototype of the initscript I'm considering adding, but I wanted to put it here so we could discuss it. If I add this, should it be added to the boot runlevel automatically? my thought is no, because there are people using OpenRC but not using the network scripts. @releng: If we add this to OpenRC, does it give you a way to bring up network interfaces easily on the ISO's if you add it to the boot runlevel?
(In reply to comment #15) as mentioned on irc, this doesn't solve the hotplug problem. i.e. i plug in a usb network device after the system has booted.
What is the technical goal trying to be achieved *now*? Since I wrote this first post almost 5 years ago I view it (even though I no longer use Gentoo) as defunct. The reason is that no userland tools had a co-herent way of listeting to events and actioning them. baselayout / OpenRC was kind of a glue. It worked but due to the ever changing nature of core packages and user choices it was and endless cycle. I urgue you too look at dhcpcd as a single daemon (or equivalent) controlling many interfaces for a workstation and the OpenRC network script for a server (using simple terms). I strongly belive the net.* approach to be broken in terms of a dynmic host and on a server for dependencies and ease of use.
Hi Roy, (In reply to comment #17) > I urgue you too look at dhcpcd as a single daemon (or equivalent) > controlling many interfaces for a workstation and the OpenRC network script > for a server (using simple terms). I strongly belive the net.* approach to > be broken in terms of a dynmic host and on a server for dependencies and > ease of use. I haven't played with dhcpcd a lot so I'm not sure I can answer this,but the concern I've heard about dhcpcd running as a daemon is that you lose control of your individual interfaces; you can't cycle or reconfigure interfaces, etc. My personal concern about the network script is that it doesn't allow stopping and starting of, or dependencies on, individual interfaces, and this goes against ease of use imo. Suppose that someone has a service that only needs to be active when eth4 comes up or suppose that they for some reason need to re-configure eth4, but don't want to affect their other interfaces. You can't do that with the network script, and if you use the manual commands to reconfigure it, that might work for some situations, but not if you are using a tunnel or something more complex.
You can dynamically remove and reconfigure devices like so dhcpcd -x tap0 dhcpcd -n tap0 In other words, same as normal. dhcpcd also listens to kernel events and starts/stops for each added/removed interface just fine. dhcpcd also doesn't stamp on pre-existing static routes. And so what if you lose a little perceived control? It's meant for workstations, not servers. Since I wrote it as a single use daemon I've not configured a since interface on my of my workstations, which includes a laptop with wired, wireless, bluetooth and a 3G phone tethered all plugged in. I think it's the only RFC6106 (IPv6 RA options for RDNSSL and RDDNS) client in Gentoo which is dual stack with DHCPv4 (and of course IPv4LL). Moving forwards it will gain DHCPv6 as a third stack later this year which AFAIK no other software has (ISC dhclient is either IPv4 or IPv6 but not both at once). How you would handle various concurrent stacks using the net.* approach I really have no idea. Well, actually I do as AFAIK OpenRC supports backgrouding and re-entry but it's hardly ideal and for a user to configure by hand insanely complicated. And yes, you're right about the network script. That basically says "this is how the network should look from zero to up". The only thing it does not do is remove previously assigned addresses. I also have zero problems doing /etc/rc.d/network restart remotely on my NetBSD server where the script was based. For things more compliated or dependent from what the network script sets out to achieve, users generally have their own scripts.
*** Bug 261267 has been marked as a duplicate of this bug. ***
(In reply to comment #17) i'm not expecting the dynamic link creation to bring all interfaces up, just readily make the scripts available. the default is already dhcp which is the only reasonable thing you can expect to work "out of the box" once the user has decided to start it. beyond that, it's just simplifying the process. forcing people to manually symlink things is needlessly backwards.
So what do we need to do, so we can get network interfaces in the install-cd to be started? Nothing?
@vapier: The more I think about this, I am against udev itself trying to create links to net.lo for the interfaces. Here are the issues I am thinking about. - Udev starts while root (and /etc) are still ro, so you can't just make the links at that point. You would have to queue up the links you wanted to make somewhere, then run another init script to create them. - If someone is using newnet, they more than likely do not want dangling symlinks in /etc, so this would have to be disabled. - I'm not sure you would want this running on a live system recreating the symlinks every time it is rebooted. I am thinking that a separate init script to add to livecd-tools which would look for network interfaces and create links to net.lo for them would be better for the install cds. What are your thoughts about this?
And - please don't forget - there is the case sys-fs/udev[-openrc] in which case (using systemd) openrc net links are obsolete.
I will work on reclassifying this bug in a little while, but it isn't something that could be done in the net.* scripts,.
Replaced udev-bugs@ with netifrc@ in CC list because all of this is part of netifrc and openrc, not udev, thesedays. $ qfile -b -v net.lo net-misc/netifrc-0.2.3 (/etc/init.d/net.lo) $ qfile -b -v net.sh net-misc/netifrc-0.2.3 (/lib/udev/net.sh) $ qfile -b -v 90-network.rules net-misc/netifrc-0.2.3 (/lib/udev/rules.d/90-network.rules)
The more I think about this bug, I don't think there is a feasible way to make this completely automatic for the following reasons: First, udev runs so early that / is still read only. Because of this, you can't write the symlinks in /etc/init.d. Second, even if you could write the symlinks, they would either have to be added to a runlevel automatically as well, or you would have to already have rc_hotplug="net.*" for this idea to work. Given these two restrictions, I don't know of a way to do this automatically. If anyone can come up with a way to deal with this, and the feature is still wanted, I am open to suggestions. Thanks, William