Re: /etc/init.d/networking does not start everything in /etc/network/interfaces
On Wed 18 May 2016 at 10:50:23 (+0200), tomas@tuxteam.de wrote:
> On Tue, May 17, 2016 at 11:22:29AM -0500, David Wright wrote:
> > On Tue 17 May 2016 at 11:26:28 (-0400), Gene Heskett wrote:
>
> [...]
What was snipped is "I do not see that as a disadvantage, udev can do
that much unwanted damage all by itself."
> > You don't see any disadvantage to removing the "hotplug stuff".
> > Hooray, let's go back to PCs as static boxes. Shut it down to add
> > a USB device. Who needs udev anyway?
>
> This is the typical red herring which helps heating up those
> discussions. *You* see an advantage. *You* use it. Gene doesn't
> Everyone is happy. Once you introduce this idiotic "we" as in
> "let's go back...", things get messed up. The optimum set up
> may vary from person to person (and *will* vary: if you have
> a laptop with two USB hubs hanging off it, with three Ethernet
> dongles randomly distributed in there, your requirements
> envelope will differ from Gene's, who has a pretty stable
> hardware setup once it's shaken out).
>
> So there's an answer to your rhetorical question anyway:
> "some need it, some need it not".
What that snipped line conveys to me is:
"Yes, [udev's stable naming of interfaces] its a certified PITA and
needs fixed by debian or the maintainer."
"So when udev screws me, I an not able to access anything or anybody
to ask what hapoened."
"I guess the udev way is the way it will be, but in that event, the
bug, a huge one, needs a fixit script included with udev"
"And its far simpler to maintain than all the moving targets udev and
dhcp can be and are giving us, IMO just to harrass the long time
users, which it does a fine job of."
If that's happy...
> > A previous time this reference was pointed out to you, you realised
> > that it has no relevance to wheezy. Even if you upgrade to jessie,
> > it's of little relevance as Debian preserves the existing behaviour
> > if you don't try to wreck it/second-guess it/believe every posting on
> > the internet.
>
> Tries. That's the word.
>
> > If you remember that far back, the linux kernel, faced with two NICs,
> > would toss a coin before naming one eth0 and the other eth1. This had
> > the splendid side-effect that you could think your LAN was the WAN and
> > vice versa, and there was nothing you could do about it.
>
> Been there, done that (many moons ago, I was part of a small group of
> people doing the software for a Debian based PC based router box, and
> had to "solve" exactly this problem. There was no udev back then.
>
> So I pretty well *know* what udev is trying to solve in this case, and
> *know* there's no "simple" policy which will always do what the user
> wants/expects.
Wants, no. Expects, yes. udev's stable naming of interfaces was
documented in the squeeze Release Notes (4.6.2) for people who were
used to the previous behaviour. It's then newish behaviour was not a
bug, and was not designed to cause grief for anyone.
> > udev meant that each NIC always got the same name even if you took it
> > out of the box one week and put it back the next. It is easy to
> > override that behaviour if it's undesired.
>
> Yeah, right. Based on the NIC's MAC address. Enter virtual machines,
> which basically throw dice to come up with a MAC: every boot, a new
> interface. Remember that? We laughed a lot ;-D
>
> Or... the case of a disk clone you stuff into new hardware (because
> the old one went down in flames, and you back up by mirroring the
> disk). Absolutely the same hardware... just a different MAC address.
> If you haven't had that fun of a customer calling in panic because
> of that, you haven't been for long enough in business. And I can't
> really blame the customer for fucking up here.
>
> > You appear to think that the old behaviour (the first NIC discovered
> > gets named eth0) is the only sensible behaviour because everyone is
> > always tinkering with the hardware, swapping boards out etc. as you do.
> > If that is really important, why not just write a script to clean
> > /etc/udev/rules.d/70-persistent-net.rules at every reboot.
> > That solves your problem, but allows other people to have a default
> > system that can sensibly give a stable configuration on machines
> > that have more than instance of each type of hardware (multiple
> > NICs, burners, USB devices.
>
> Note that I'm not pro or against "the new way" of doing things, but
> very much miffed by the arrogant stance "My Way Is The Only Right
> Way". I always recommend: "study, understand, decide". And for
> $DEITY's sake, show some respect for those deciding otherwise. If
> they seem like idiots to you, it just might be more your problem
> than theirs.
Please point out where I've taken an arrogant stance on "My Way" of
doing things (and not just in this thread, if you wish).
There *is* a Debian Way. There has to be a defined, preferably
documented, default behaviour. But when I don't agree with the choices
Debian made, I don't claim that things are now broken, and that they
were broken to give me grief. Is it wrong to defend against such
accusations?
Cheers,
David.
Reply to: