Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eth0 no more?

lists.us.dell.com

Post reply on HN
Print view View original

41–50 of 53 posts

Re: Eth0 no more?

#41

Post by ay »

sciurus wrote: post #15
CrLf wrote: post #7

Earlier quoted context omitted.

Network interfaces should not rename themselves after reboots. On Red Hat derived distributions, the device name is tied to the MAC address of the interface, so it never changes. On other distributions, "udev" accomplishes the same thing. The only point when interface naming is arbitrary is at installation time, then it stays the same forever. Not only this will add confusion by introducing a bunch of new names for n…

No, you can still rename interfaces using udev just like you can now. This is largely about ensuring that devices get predictable name at install time. As is pointed out in the LWN comment thread, for anyone who has to provision large number of servers with multiple NICs that connect to different networks this is a godsend. Ability to rename: http://lists.us.dell.com/pipermail/linux-poweredge/2010-Nove... Why the eth…

Why not give an argument to the kernel to create the new devices as "fooX" (foo being a supplied parameter) - and let udev userland deal with the renaming to "ethY" as it pleases ?

While this novelty certainly may appeal to the folks who are used to alphabet soup in the network adapters list, and I too think that the adapters that distinguish between the T568A and T568B cable layout have a degree of coolness in them by creating an extra value in being able to distinguish between the straight and crossover cables - overall it seems like a step back to me.

I would plug in the interfaces into a switch - and all I care is to find the same MAC address as I see on the switchports - not which bus they attach to.

Re: Eth0 no more?

#42

Post by vacri »

ominous_prime wrote: post #24
nailer wrote: post #18

Earlier quoted context omitted.

1. Linux gives unique names to each NIC. There are no namespace conflicts, because each NIC alias is unique within devices. I personally do not care about the chipset manufacturer and driver when working on a routing issue. 2. You mean (IIRC) 'ip link show'. ifconfig on linux isn't maintained, and breaks in a bunch of situations (Aliases on VLANs on bonds, for one) 3. And you should of course use python-procfs or you…

somewhat OT: > 2. You mean (IIRC) 'ip link show'. ifconfig on linux isn't maintained, and breaks in a bunch of situations (Aliases on VLANs on bonds, for one) This seemingly simple change seems to be taking forever to gain traction; "use `ip` for network config on linux". There is so much googlable stuff instructing one to use ifconfig, route, etc. that it seems to self perpetuate. I often find people telling others…

I used ifconfig until about halfway through last year when someone pointed 'ip' out to me. I kept using ifconfig right up until the point I found that ip didn't require root rights...

Re: Eth0 no more?

#43

Post by wglb »

nl wrote: post #40
_b8r0 wrote: post #32

I can understand why people will resist this, thinking that somehow renaming eth0 to em0 or similar will break stuff, but here's the rub: It'll only break stuff that's badly written. There's a right way to enumerate network interfaces and a wrong way (which is dependent on the language you're using for enumeration - the wrong way is assuming that eth0 is the only network device). Bear in mind that the new convention…

Documentation that references eth0 isn't badly written.

How is that? Would you care to elaborate?

Re: Eth0 no more?

#44

Post by moe »

rdtsc wrote: post #16
adobriyan wrote: post #10

Earlier quoted context omitted.

> Network interfaces should not rename themselves after reboots. But that's because PCI bus walk order doesn't change across reboots.

Well it depends. There is a kernel parameter that forces a consistent walk order: pci=bfsort It forces breadth-first device sorting. But otherwise I understand that devices are detected in parallel and whichever ones return first are designated eth0, eth1 etc. We had this problem on some machine that have 4+ eth0 devices. We use RHEL|CentOS 5.x (see in the post above how we solved the problem).

This!

I once had a server (in the pre-udev era) that would occasionally shuffle its network devices after reboots. I don't remember how I fixed it but I do remember the short phase of amusement, followed by a longer phase of frustration.

Re: Eth0 no more?

#45

Post by _b8r0 »

nl wrote: post #40
_b8r0 wrote: post #32

I can understand why people will resist this, thinking that somehow renaming eth0 to em0 or similar will break stuff, but here's the rub: It'll only break stuff that's badly written. There's a right way to enumerate network interfaces and a wrong way (which is dependent on the language you're using for enumeration - the wrong way is assuming that eth0 is the only network device). Bear in mind that the new convention…

Documentation that references eth0 isn't badly written.

On the surface it would seem like you're correct, but only so in some cases.

If for example you're running Linux on a Macbook Air you have no eth0 by default. Ergo, documentation referencing it is technically incorrect - it would be possible to say badly written at this point but that's even more pedantic than your comment ;)

Re: Eth0 no more?

#46

Post by nailer »

rdtsc wrote: post #34
nailer wrote: post #31

Earlier quoted context omitted.

> No they don't. Thare no files to read. You just wrote above in your commetn [sic] that the first time OS boots ifcfg are generate [sic]. So after a machine is coldstarted there are no ifcfg files! As long as you don't reinstall your OS, or lose your data, your config files are there. Cold starting hardware does not delete data. Are you trolling?

> Cold starting hardware does not delete data. Alright, figured it out. When you talk about coldstaring you really mean restarting the machine, as in pressing the reset button for example. When I talk about coldstarting I mean starting with a bare hardware box and installing an OS on it. > Are you trolling? Actually I thought you were. Sorry for the misunderstanding. [EDIT: I won't edit my previous posts, otherwise y…

No probs. Most places I've worked at use 'provision' or 'bare metal' for an os install plus mop up work, starting cold as a way to differentiate from warm booting, appreciate different places may have different systems though. Thanks for being classy about it :-)

Re: Eth0 no more?

#48

Post by pmcginn »

nl wrote: post #40
_b8r0 wrote: post #32

I can understand why people will resist this, thinking that somehow renaming eth0 to em0 or similar will break stuff, but here's the rub: It'll only break stuff that's badly written. There's a right way to enumerate network interfaces and a wrong way (which is dependent on the language you're using for enumeration - the wrong way is assuming that eth0 is the only network device). Bear in mind that the new convention…

Documentation that references eth0 isn't badly written.

Yes it is. Obviously, this is just my anecdotal experience, but the first time I tried to install Linux the troubleshooting documentation I was working off of only mentioned eth0. I tried to configure everything to eth0, and nothing worked. I gave up and swore off Linux for years. Eventually, I tried Ubuntu, where everything worked, and figured it was a driver issue that Ubuntu had solved.

I got around to trying out Gentoo, which has amazing documentation that really drills down into what you're doing and why. That's when I ran ifconfig and iwconfig for the first time and realized I probably would have been using Linux years earlier if I had known how to find out that my NIC was wlan0.

So I'd say referencing eth0 throughout is fine, as long as at the beginning you take the time to point out that it may not be eth0, and more importantly, how to find out what it is.

Re: Eth0 no more?

#49

Post by kelnos »

ominous_prime wrote: post #37
zdw wrote: post #26

Earlier quoted context omitted.

It's not that it self-perpetuates, it's that nearly every other Unix does it that way, and thus there's an expectation that ifconfig, if it exists, has similar functionality on all platforms. If you're going to deprecate a command, make running the old one either: 1. Not exist, and thus have the shell throw an "command not found" error 2. Print a useful message like "Use instead" 3. Work, but do #2 as well. The curre…

I agree wholeheartedly that the old tools should be hidden away, and I assume that they haven't been, because that will break more things than the actual renaming of devices. I bet even adding deprecation warnings could cause a ruckus, seeing how many times I've come across `ifconfig | something` both in scripts and people shelling out from other languages. I do wish the distros would just make a clean break, and let…

Then you just make the deprecation warning go to stderr instead of stdout. '|' only redirects stdout.

Re: Eth0 no more?

#50

Post by chalst »

nl wrote: post #40
_b8r0 wrote: post #32

I can understand why people will resist this, thinking that somehow renaming eth0 to em0 or similar will break stuff, but here's the rub: It'll only break stuff that's badly written. There's a right way to enumerate network interfaces and a wrong way (which is dependent on the language you're using for enumeration - the wrong way is assuming that eth0 is the only network device). Bear in mind that the new convention…

Documentation that references eth0 isn't badly written.

It's not rare for the WLAN subsystem to be accessed though an ethernet device name.
Post reply on HN