Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 186156 - sys-apps/openrc: allow net-misc/netifrc to create links to net.lo in /etc/init.d
Summary: sys-apps/openrc: allow net-misc/netifrc to create links to net.lo in /etc/init.d
Status: RESOLVED CANTFIX
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: OpenRC (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: OpenRC Team
URL:
Whiteboard:
Keywords:
: 261267 (view as bug list)
Depends on:
Blocks: 398203
  Show dependency tree
 
Reported: 2007-07-21 22:02 UTC by Roy Marples (RETIRED)
Modified: 2015-03-22 22:50 UTC (History)
22 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
netlinks.in (netlinks.in,474 bytes, text/plain)
2012-04-29 20:19 UTC, William Hubbs
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roy Marples (RETIRED) gentoo-dev 2007-07-21 22:02:06 UTC
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 :)
Comment 1 SpanKY gentoo-dev 2007-07-21 22:16:57 UTC
by definition, files in /etc/udev/ are configurable since they're CONFIG_PROTECT-ed
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2007-07-22 06:10:39 UTC
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.
Comment 3 Roy Marples (RETIRED) gentoo-dev 2007-07-22 10:26:25 UTC
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.
Comment 4 Kalin KOZHUHAROV 2007-07-22 17:16:59 UTC
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.
Comment 5 Roy Marples (RETIRED) gentoo-dev 2007-07-23 06:46:11 UTC
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.
Comment 6 Matthias Schwarzott gentoo-dev 2007-08-03 13:25:48 UTC
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.
Comment 7 cruzki 2007-08-16 23:47:53 UTC
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.
Comment 8 Roy Marples (RETIRED) gentoo-dev 2007-08-21 12:49:07 UTC
(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"
Comment 9 Matthias Schwarzott gentoo-dev 2007-09-25 18:13:48 UTC
(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".
Comment 10 William Hubbs gentoo-dev 2012-01-13 19:59:34 UTC
It looks like we never came up with a rule for this.
Comment 11 William Hubbs gentoo-dev 2012-01-14 18:45:12 UTC
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.
Comment 12 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-01-14 19:02:28 UTC
Creating links in the directory also requires that rc-update -u gets run afterwards, to calculate the init dep tree again.
Comment 13 William Hubbs gentoo-dev 2012-04-29 18:14:28 UTC
*** Bug 398203 has been marked as a duplicate of this bug. ***
Comment 14 William Hubbs gentoo-dev 2012-04-29 18:17:43 UTC
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?
Comment 15 William Hubbs gentoo-dev 2012-04-29 20:19:58 UTC
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?
Comment 16 SpanKY gentoo-dev 2012-05-17 04:46:17 UTC
(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.
Comment 17 Roy Marples 2012-05-25 01:47:42 UTC
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.
Comment 18 William Hubbs gentoo-dev 2012-05-25 03:07:49 UTC
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.
Comment 19 Roy Marples 2012-05-25 07:15:05 UTC
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.
Comment 20 William Hubbs gentoo-dev 2012-06-30 15:15:51 UTC
*** Bug 261267 has been marked as a duplicate of this bug. ***
Comment 21 SpanKY gentoo-dev 2012-08-27 03:23:26 UTC
(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.
Comment 22 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2012-12-24 05:31:28 UTC
So what do we need to do, so we can get network interfaces in the install-cd to be started? Nothing?
Comment 23 William Hubbs gentoo-dev 2012-12-27 15:57:38 UTC
@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?
Comment 24 Ulenrich 2013-02-15 00:14:54 UTC
And - please don't forget - there is the case sys-fs/udev[-openrc] 
in which case (using systemd) openrc net links are obsolete.
Comment 25 William Hubbs gentoo-dev 2013-04-26 16:31:56 UTC
I will work on reclassifying this bug in a little while, but it isn't
something that could be done in the net.* scripts,.
Comment 26 Samuli Suominen gentoo-dev 2014-05-12 15:41:25 UTC
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)
Comment 27 William Hubbs gentoo-dev 2015-03-22 22:50:55 UTC
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