[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /etc/init.d/networking does not start everything in /etc/network/interfaces



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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:

[...]

> 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".

> 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.

> 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.

Peace
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlc8LM8ACgkQBcgs9XrR2kZ4MgCfQSnjPs4BM8VCz7dw9EG6tHr5
en8AnAhXGwrhlzNS2JeHWdhVjdx8gM3+
=1vsC
-----END PGP SIGNATURE-----


Reply to: