On Wed, Jan 15, 2014 at 6:05 AM, Steve Clark sclark@netwolves.com wrote:
On 01/14/2014 08:34 PM, Les Mikesell wrote:
On Tue, Jan 14, 2014 at 7:17 PM, Warren Young warren@etr-usa.com wrote:
I don't know about "less consistent", but I always considered it a feature in Linux vs the BSDs or big iron Unix that I could always count on the first network interface being "eth0".
What does 'first' mean? And the same one isn't consistently first.
I get that network interfaces can move around on you, but I thought that was why they started putting the MAC address in the ifcfg-eth? scripts. What problem did that not solve, that we had to switch to this new system?
The problem is when you clone a disk and ship it to a location with 'hands-on' support that doesn't know linux to install in a new chassis that will arrive there at the same time. Somehow you have to get someone to put the 4 network cables in the right NICs before anything can connect. With things tied to MAC addresses that you don't know ahead of time, nothing will work.
Now I have to remember which *PCI slot* my Ethernet card is in when I run "ifconfig" unless I want to dig through the full listing.
Yes, but that's something you _can_ know.
How can you know it? And if you know which port is which why isn't in the instruction with the drive so the people on site know which port is which?
If you insert the card yourself, you obviously know the slot. And you can tell the position from the back just by looking at it. But Centos6 will detect in random order, so knowing the name on one box doesn't help with another. We have to go through contortions plugging on cable in at a time, doing an 'ifconfig up' and checking which interface shows link up. And the people doing that part wish we used more windows instead of Linux.
How about using ethtool -p which causes the LED of the NIC to blink?
On Wed, Jan 15, 2014 at 4:05 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Wed, Jan 15, 2014 at 6:05 AM, Steve Clark sclark@netwolves.com wrote:
On 01/14/2014 08:34 PM, Les Mikesell wrote:
On Tue, Jan 14, 2014 at 7:17 PM, Warren Young warren@etr-usa.com wrote:
I don't know about "less consistent", but I always considered it a feature in Linux vs the BSDs or big iron Unix that I could always count on the first network interface being "eth0".
What does 'first' mean? And the same one isn't consistently first.
I get that network interfaces can move around on you, but I thought that was why they started putting the MAC address in the ifcfg-eth? scripts. What problem did that not solve, that we had to switch to this new system?
The problem is when you clone a disk and ship it to a location with 'hands-on' support that doesn't know linux to install in a new chassis that will arrive there at the same time. Somehow you have to get someone to put the 4 network cables in the right NICs before anything can connect. With things tied to MAC addresses that you don't know ahead of time, nothing will work.
Now I have to remember which *PCI slot* my Ethernet card is in when I run "ifconfig" unless I want to dig through the full listing.
Yes, but that's something you _can_ know.
How can you know it? And if you know which port is which why isn't in the instruction with the drive so the people on site know which port is which?
If you insert the card yourself, you obviously know the slot. And you can tell the position from the back just by looking at it. But Centos6 will detect in random order, so knowing the name on one box doesn't help with another. We have to go through contortions plugging on cable in at a time, doing an 'ifconfig up' and checking which interface shows link up. And the people doing that part wish we used more windows instead of Linux.
-- Les Mikesell lesmikesell@gmail.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Am Wed, 15 Jan 2014 16:25:04 +0200 schrieb JC Putter jcputter@gmail.com:
How about using ethtool -p which causes the LED of the NIC to blink?
Very useful, unless the datacenter isn't in the basement ;-)
Les Mikesell wrote:
On Wed, Jan 15, 2014 at 6:05 AM, Steve Clark sclark@netwolves.com wrote:
On 01/14/2014 08:34 PM, Les Mikesell wrote:
On Tue, Jan 14, 2014 at 7:17 PM, Warren Young warren@etr-usa.com wrote:
I don't know about "less consistent", but I always considered it a feature in Linux vs the BSDs or big iron Unix that I could always count on the first network interface being "eth0".
What does 'first' mean? And the same one isn't consistently first.
<snip>
The problem is when you clone a disk and ship it to a location with 'hands-on' support that doesn't know linux to install in a new chassis that will arrive there at the same time. Somehow you have to get someone to put the 4 network cables in the right NICs before anything can connect. With things tied to MAC addresses that you don't know ahead of time, nothing will work.
When you clone a disk, you can't get the ifcfg-eth* and 70-persistant-net-rules from the old machine, or you don't have that info under version control, with all those systems? <snip>
If you insert the card yourself, you obviously know the slot. And you can tell the position from the back just by looking at it. But Centos6 will detect in random order, so knowing the name on one box doesn't help with another. We have to go through contortions plugging on cable in at a time, doing an 'ifconfig up' and checking which interface shows link up. And the people doing that part wish we used more windows instead of Linux.
ifconfig up? Not ethtool eth?
mark
On Wed, Jan 15, 2014 at 8:48 AM, m.roth@5-cent.us wrote:
The problem is when you clone a disk and ship it to a location with 'hands-on' support that doesn't know linux to install in a new chassis that will arrive there at the same time. Somehow you have to get someone to put the 4 network cables in the right NICs before anything can connect. With things tied to MAC addresses that you don't know ahead of time, nothing will work.
When you clone a disk, you can't get the ifcfg-eth* and 70-persistant-net-rules from the old machine, or you don't have that info under version control, with all those systems?
I don't have that information on the 1st install. Once it is up and running the ocsinventory-ng client will report the hardware to a central server. I suppose with a huge increase in human effort needed, the MAC addresses of the systems and cards could be databased as they are installed.. But, even knowing them doesn't help when you clone multiple identical disk images. And something would still have to map the MACs to the physical positions.
We have to go through contortions plugging on cable in at a time, doing an 'ifconfig up' and checking which interface shows link up. And the people doing that part wish we used more windows instead of Linux.
ifconfig up? Not ethtool eth?
You have to do both. Link won't come up until you ifconfig up the device - which of course is difficult when you don't know its name...
Les Mikesell wrote:
On Wed, Jan 15, 2014 at 8:48 AM, m.roth@5-cent.us wrote:
The problem is when you clone a disk and ship it to a location with 'hands-on' support that doesn't know linux to install in a new chassis that will arrive there at the same time. Somehow you have to get someone to put the 4 network cables in the right NICs before anything can connect. With things tied to MAC addresses that you don't know ahead of time, nothing will work.
<snip>
We have to go through contortions plugging on cable in at a time, doing an 'ifconfig up' and checking which interface shows link up. And the people doing that part wish we used more windows instead of Linux.
ifconfig up? Not ethtool eth?
You have to do both. Link won't come up until you ifconfig up the device - which of course is difficult when you don't know its name...
I don't think so - pretty sure I was just using ethtool eth? the other week, to try to figure out the name of the port that I'd plugged the patch cord into. I *know* that the ones with nothing in them weren't up (and yes, obviously, I was at the console).
mark
On Wed, Jan 15, 2014 at 12:47 PM, m.roth@5-cent.us wrote:
The problem is when you clone a disk and ship it to a location with 'hands-on' support that doesn't know linux to install in a new chassis that will arrive there at the same time. Somehow you have to get someone to put the 4 network cables in the right NICs before anything can connect. With things tied to MAC addresses that you don't know ahead of time, nothing will work.
<snip> >>> We have to go through contortions >>> plugging on cable in at a time, doing an 'ifconfig up' and checking >>> which interface shows link up. And the people doing that part wish >>> we used more windows instead of Linux. >> >> ifconfig up? Not ethtool eth? > > You have to do both. Link won't come up until you ifconfig up the > device - which of course is difficult when you don't know its name...
I don't think so - pretty sure I was just using ethtool eth? the other week, to try to figure out the name of the port that I'd plugged the patch cord into. I *know* that the ones with nothing in them weren't up (and yes, obviously, I was at the console).
Maybe something else had already probed them. I'm pretty sure that if you bring up a system where all of the udev rules and ifcfg- files have the wrong MAC addresses, none of the links will come up. With CentOS5 you could use mii-tool to enumerate the interfaces and show link. I think the best I've found with 6 is to use 'ip link ls' to show the names, then one at a time 'ifconfig up' each name and then use ethtool to check for link. All very awkward to describe to a windows admin over the phone.
-
JC Putter -
Les Mikesell -
m.roth＠5-cent.us -
Rainer Duffner