On 12/17/2011 05:33 AM, Les Mikesell wrote: > On Fri, Dec 16, 2011 at 11:23 AM, Marko Vojinovic<vvmarko at gmail.com> wrote: >> On Thursday 15 December 2011 16:04:35 Les Mikesell wrote: >>> On Thu, Dec 15, 2011 at 3:39 PM,<m.roth at 5-cent.us> wrote: >>>>>>> In earlier versions 'mii-tool' would iterate over interfaces and >>>>>>> show >>>>>>> which have link up. In 6.x it wants an interface as a parameter. >>>>>>> What is the appropriate way to find which of some number of of >>>>>>> interfaces are connected? Better yet, what is the least typing >>>>>>> to >>>>>>> get the mac addresses of those interfaces? >>>> Dumb question: in /etc/sysconfig/network-scripts, do the ifcfg-* have >>>> HWADDRs? >>> They do, but the case I want to cover is where an existing server is >>> cloned, or the disk has been moved from a failed chassis to a spare. >>> And in this case the existing files will be wrong, and the nics will >>> be named more or less randomly. Assume the hands-on operators don't >>> know much about linux and you can't actively help until they get at >>> least one of the right IP's on the right NIC. >>> >>> With 5.x I'd use mii-tool to find the connected interface (connecting >>> one wire at a time if necessary), then ifconfig on that interface to >>> get the hwaddr, then edit that into the ifcfg-* file for the names I >>> want the active NICs to have, and reboot. That's awkward enough to >>> ask someone to do who already prefers windows, and it looks like it >>> just got harder by having to explicitly run mii-tool for each possible >>> interface (and we always have 4 to 6 per box). There has to be a >>> better way. I thought 6.1 was going to have a new NIC name >>> convention but I haven't had time to look into it and have to make >>> something work now. >> Your situation is the "textbook usecase" example for biosdevname >> (http://linux.dell.com/biosdevname). It is a way to consistently name the >> network devices according to their physical location in a computer. For >> example, a typical NIC would not have a name "eth1", but "p2p3" (which means >> "port 3 of the NIC in PCI slot 2") or "em2" (which is "2nd ethernet port on >> the motherboard"). So once the hands-on operator plugs a cable into a >> particular port, you immediately know the corresponding interface name that >> the system will use for that connection. And in addition, this is MAC-address >> independent, so moving the hard drive from one box to the other requires >> basically no reconfiguration (as long as the operator plugs the same cables >> into the same sockets). >> >> The biosdevname was first introduced in Fedora 15 >> (http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming), ie. >> only after RHEL 6 was already rolled out. Apparently, it has to cooperate >> intimately with the kernel, udev, initscripts, dracut, anaconda, kickstart, >> etc., --- so it is not just a userland app which one could yum install in a >> trivial way. >> >> Therefore, somehow I doubt that CentOS 6 will ever see biosdevname implemented >> (maybe in the CentOSplus kernel and a "use at your own risk" label?), since it >> involves too many system changes and breaks backward compatibility. But RHEL 7 >> is almost certainly going to have it, since this is actually the proper (and >> permanent) solution to the problem you have. > I thought I saw it mentioned in release notes for RHEL 6.1 but it said > something about support being limited to certain Dell models. I'm not > sure it is going to be perfect anyway, since most of the machines in > question have Broadcom NICs on the motherboards and the ones we > actually use are on Intel cards that may not exactly match types or > slot positions. But I'd settle for something that had something to > do with the slot position... > http://www.pkje.net/meander/?p=115 - this may help on the device ordering for 6.x if you know the mac addresses then you can fix the names of the interfaces