Warren Young wrote:
On 1/13/2014 07:33, m.roth@5-cent.us wrote:
<snip>
Reason for this: at one of my local sf clubs, I've been trying to
install Evergreen, F/OSS library software, on a system, and it's a nightmare.
They seem to have been building it for Ubuntu
whateverthelatestanimalis. The
biggest problem is, IIRC, eventhandler and memchached; oh, and it uses
postgresql 9, and nothing else. PGSQL 9 was not a big deal to install, but the other stuff.... Even trying to build it in /usr/local is a royal mess:though I've got the dbi installed, ./configure can't find it.
Post an actual error message, and someone may be able to help.
That's not a problem, well, the issue, as I said, is that configure can't find the interface, even when I've given it the correct paths. Can't really just give it to you, since a) I'm at work, in the DC 'burbs, and b) the clubhouse is up in Baltimore. Not building it at home - I've got other things to build (like xtrackcad)....
Thanks for the offer, though. I'm sure there's either some environment variable it isn't happy with, or is missing, or an option isn't right to tell it what path to use.
mark
On 1/14/2014 14:32, m.roth@5-cent.us wrote:
configure can't find the interface,
Were you aware that RHEL 7 now uses "Consistent Network Device Naming" (http://goo.gl/Z0ydDF) in more situations? It was optional in RHEL 6 (http://goo.gl/TiuTP9) but is all but enforced in RHEL 7.
Everyone, drop a tear for the dead "eth0". <sniff> We will miss you, eth0!
On Tue, Jan 14, 2014 at 02:57:20PM -0700, Warren Young wrote:
On 1/14/2014 14:32, m.roth@5-cent.us wrote:
configure can't find the interface,
Were you aware that RHEL 7 now uses "Consistent Network Device Naming" (http://goo.gl/Z0ydDF) in more situations? It was optional in RHEL 6 (http://goo.gl/TiuTP9) but is all but enforced in RHEL 7.
Everyone, drop a tear for the dead "eth0". <sniff> We will miss you, eth0!
Haven't played much with it in CentOS. In Fedora, at present, it is a bit of pain as both biosdevname and systemd have something to do with it, making it less consistent than ever.
So, to remove it, one has to both run rpm -e biosdevname and add to /etc/deafaults/grub kernel line net.ifnames=0.
On 01/15/2014 12:37 AM, Scott Robbins wrote:
On Tue, Jan 14, 2014 at 02:57:20PM -0700, Warren Young wrote:
On 1/14/2014 14:32, m.roth@5-cent.us wrote:
configure can't find the interface,
Were you aware that RHEL 7 now uses "Consistent Network Device Naming" (http://goo.gl/Z0ydDF) in more situations? It was optional in RHEL 6 (http://goo.gl/TiuTP9) but is all but enforced in RHEL 7.
Everyone, drop a tear for the dead "eth0". <sniff> We will miss you, eth0!
Haven't played much with it in CentOS. In Fedora, at present, it is a bit of pain as both biosdevname and systemd have something to do with it, making it less consistent than ever.
So, to remove it, one has to both run rpm -e biosdevname and add to /etc/deafaults/grub kernel line net.ifnames=0.
Fpr 7: " If the system's BIOS does not have SMBIOS version 2.6 or higher and this data, the new naming convention will not be used. Most older hardware does not support this feature because of a lack of BIOSes with the correct SMBIOS version and field information. For BIOS or SMBIOS version information, contact your hardware vendor."
On 1/14/2014 17:33, Ljubomir Ljubojevic wrote:
" If the system's BIOS does not have SMBIOS version 2.6 or higher and this data, the new naming convention will not be used.
Apparently VirtualBox emulates SMBIOS, since my RHEL 7 VM uses this new scheme.
On 1/14/2014 16:37, Scott Robbins wrote:
On Tue, Jan 14, 2014 at 02:57:20PM -0700, Warren Young wrote:
Everyone, drop a tear for the dead "eth0". <sniff> We will miss you, eth0!
Haven't played much with it in CentOS. In Fedora, at present, it is a bit of pain as both biosdevname and systemd have something to do with it, making it less consistent than ever.
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". BSD and big iron Unix named the interface after the Ethernet driver, as if that was what was important.
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?
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.
Evil shades of PR#1, begone!
(Apple DOS 3.3 reference, there.)
On 1/14/2014 5:17 PM, Warren Young 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". BSD and big iron Unix named the interface after the Ethernet driver, as if that was what was important.
conversely, it wasn't always consistent WHICH NIC would be eth0. Had several x86 servers with dual integral nic's where eth0/eth1 were swapped relative to what RHEL/CentOS thought they were. while you COULD force it via mucking about in some kernel file or another, it was rarely worth the hassle.
On 1/14/2014 18:23, John R Pierce wrote:
On 1/14/2014 5:17 PM, Warren Young 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". BSD and big iron Unix named the interface after the Ethernet driver, as if that was what was important.
conversely, it wasn't always consistent WHICH NIC would be eth0. Had several x86 servers with dual integral nic's where eth0/eth1 were swapped relative to what RHEL/CentOS thought they were.
I know the problem you mean, but doesn't the HWADDR setting in the ifcfg-ethX file fix the problem? Doesn't that force "ifup eth0" to bind that file's settings to the right physical interface?
In the old days, ifcfg-ethX didn't have HWADDR, so "first" was somewhat unpredictable, as you say.
On 1/14/2014 5:55 PM, Warren Young wrote:
I know the problem you mean, but doesn't the HWADDR setting in the ifcfg-ethX file fix the problem? Doesn't that force "ifup eth0" to bind that file's settings to the right physical interface?
In the old days, ifcfg-ethX didn't have HWADDR, so "first" was somewhat unpredictable, as you say.
that forces it to bind to the same interface. but when you're doing a virgin install, its fairly unlikely you'll know what the MAC's are or which port it will pick to be eth0 and the setup will pick them fairly arbitrarily (bus enumeration order, typically)
On 1/14/2014 19:10, John R Pierce wrote:
On 1/14/2014 5:55 PM, Warren Young wrote:
I know the problem you mean, but doesn't the HWADDR setting in the ifcfg-ethX file fix the problem? Doesn't that force "ifup eth0" to bind that file's settings to the right physical interface?
In the old days, ifcfg-ethX didn't have HWADDR, so "first" was somewhat unpredictable, as you say.
that forces it to bind to the same interface. but when you're doing a virgin install, its fairly unlikely you'll know what the MAC's are or which port it will pick to be eth0 and the setup will pick them fairly arbitrarily (bus enumeration order, typically)
Yes, we've had that problem, too. Motherboard model A from Most Favored Manufacturer will put eth0 on the left, then model B replaces it, and eth0 is now on the right. We figure this out during setup, then label the ports.
If we decide we really want eth0 and eth1 swapped, we swap the HWADDR lines between the ifcfg files.
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.
On 2014-01-14 8:34 PM, Les Mikesell wrote:
On Tue, Jan 14, 2014 at 7:17 PM, Warren Young warren@etr-usa.com wrote: 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.
So... which PCI/PCI-e slots are associated with the dual gigabit NICs integrated in/on every ASUS board I've bought over the last 8 years?
On Tue, Jan 14, 2014 at 7:56 PM, Darr247 darr247@gmail.com wrote:
On 2014-01-14 8:34 PM, Les Mikesell wrote:
On Tue, Jan 14, 2014 at 7:17 PM, Warren Young warren@etr-usa.com wrote: 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.
So... which PCI/PCI-e slots are associated with the dual gigabit NICs integrated in/on every ASUS board I've bought over the last 8 years?
I wouldn't know on the first one, but the important thing is that if you have 50 identical servers they would all be the same for the same physical location. The way 6.x works, the motherboard set and the pair on the card will randomly flip in the initial detection. With 5.x having the MAC address in the ifcfg-ethx file was enough. With 6.x you also need a udev rule to nail the name down. These get tied to MAC addresses in the initial install, but that makes it painful to clone systems or restore backups into a different box.
On 01/14/2014 09:25 PM, Les Mikesell wrote:
On Tue, Jan 14, 2014 at 7:56 PM, Darr247 darr247@gmail.com wrote:
On 2014-01-14 8:34 PM, Les Mikesell wrote:
On Tue, Jan 14, 2014 at 7:17 PM, Warren Young warren@etr-usa.com wrote: 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.
So... which PCI/PCI-e slots are associated with the dual gigabit NICs integrated in/on every ASUS board I've bought over the last 8 years?
I wouldn't know on the first one, but the important thing is that if you have 50 identical servers they would all be the same for the same physical location. The way 6.x works, the motherboard set and the pair on the card will randomly flip in the initial detection. With 5.x having the MAC address in the ifcfg-ethx file was enough. With 6.x you also need a udev rule to nail the name down. These get tied to MAC addresses in the initial install, but that makes it painful to clone systems or restore backups into a different box.
Hmm... we have over a 1000 units in the field and CentOS always enumerates the 6 ethx interfaces the same - as they are labeled by the manufacturer of the hardware. This has continued to be consistent even when the manufacturer upgraded the MB.
On 1/14/2014 18:34, Les Mikesell wrote:
On Tue, Jan 14, 2014 at 7:17 PM, Warren Young warren@etr-usa.com wrote:
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 much time and resources do you need to learn the answer?
Puzzle for ya: What "PCI slot" is the Intel e1000e MAC chip in on a Supermicro X9SCA-F motherboard? It isn't called out in the mobo manual. I just looked. (For that matter, the actual PCI slots don't have their numbers documented in the manual, either.)
If you can't get lucky with Google, you're just going to have to install EL7 on it and find out. And if you can do that, why not just build it and ship it?
Somehow you have to get someone to put the 4 network cables in the right NICs before anything can connect.
Yes, I know that problem.
We solved it here years ago by building the full system, testing it, then labeling the ports with a Sharpie. Then, later, we got really fancy and switched to a Brother label maker.
Sure, it means we have to have the barebones chassis shipped here first, but as you're doubtless aware, that shipping charge is cheap next to the confusion that can happen in the field when Joe Wirepuller is asked to plug it all in, if nothing is labeled.
On 1/14/2014 18:34, Les Mikesell wrote:
Puzzle for ya: What "PCI slot" is the Intel e1000e MAC chip in on a Supermicro X9SCA-F motherboard? It isn't called out in the mobo manual. I just looked. (For that matter, the actual PCI slots don't have their numbers documented in the manual, either.)
If you can't get lucky with Google, you're just going to have to install EL7 on it and find out. And if you can do that, why not just build it and ship it?
On top of that, it seems to be only populated slots.
I added a USB3 PCIe card to my Gigabyte MB and the previous 'enp2s0' became 'enp3s0'!
On Tue, Jan 14, 2014 at 8:27 PM, Thomas Eriksson thomas.eriksson@slac.stanford.edu wrote:
Puzzle for ya: What "PCI slot" is the Intel e1000e MAC chip in on a Supermicro X9SCA-F motherboard? It isn't called out in the mobo manual. I just looked. (For that matter, the actual PCI slots don't have their numbers documented in the manual, either.)
If you can't get lucky with Google, you're just going to have to install EL7 on it and find out. And if you can do that, why not just build it and ship it?
On top of that, it seems to be only populated slots.
I added a USB3 PCIe card to my Gigabyte MB and the previous 'enp2s0' became 'enp3s0'!
Oh great, another naming scheme invented by people that don't actually deal with hardware.
On Tue, Jan 14, 2014 at 8:21 PM, Warren Young warren@etr-usa.com wrote:
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 much time and resources do you need to learn the answer?
You need a box in a lab setting where you do the build you want to clone.
Puzzle for ya: What "PCI slot" is the Intel e1000e MAC chip in on a Supermicro X9SCA-F motherboard? It isn't called out in the mobo manual. I just looked. (For that matter, the actual PCI slots don't have their numbers documented in the manual, either.)
Let anaconda figure it out. I don't care what it is, just that it is repeatable.
If you can't get lucky with Google, you're just going to have to install EL7 on it and find out. And if you can do that, why not just build it and ship it?
Don't want to ship the chassis twice - and especially not for the 2nd/3rd installs on a remote box. I want to send a disk and have someone on-site plug it in and have the box come up working. For the 2nd/3rd installs, I can get the MAC addresses, but usually don't know them on the first round.
Somehow you have to get someone to put the 4 network cables in the right NICs before anything can connect.
Yes, I know that problem.
We solved it here years ago by building the full system, testing it, then labeling the ports with a Sharpie. Then, later, we got really fancy and switched to a Brother label maker.
Sure, it means we have to have the barebones chassis shipped here first, but as you're doubtless aware, that shipping charge is cheap next to the confusion that can happen in the field when Joe Wirepuller is asked to plug it all in, if nothing is labeled.
It gets old when you are doing several a day. Oh, and we've been waiting over a month for a resolution on a server that disappeared in transit, too...
On Tue, Jan 14, 2014 at 08:35:06PM -0600, Les Mikesell wrote:
Let anaconda figure it out. I don't care what it is, just that it is repeatable.
Awooga! Awoooga! Awooga!
Here's the fun part; devices discovered by Anaconda may not match the devices disovered during the production boot. Device driver order and bus discovery order wasn't necessarily consistent with the production kernel. This is why the HWADDR stuff was added; to work around (poorly) this issue. I say poorly becuase I've seen many cases of _net##### devices where the ifcfg files conflict in same way with the actual device.
Ultimately what we have is a situation similar to hard disks. We've got used to sd devices changing depending on the order disks are discovered in, which is why we use LABEL or UUID. HWADDR doesn't work consistently.
The existing process is demonstrably broken.
The new process is new and therefor bad, wrong, disgusting, an abomination.
But maybe... just maybe... it'll work.
On Tue, Jan 14, 2014 at 8:43 PM, Stephen Harris lists@spuddy.org wrote:
Ultimately what we have is a situation similar to hard disks. We've got used to sd devices changing depending on the order disks are discovered in, which is why we use LABEL or UUID.
But those don't work until something has already identified the device. If you are old enough, you might remember unix versions that named disks by controller, bus, target numbers. Which worked, but wasn't very human-friendly either.
The new process is new and therefor bad, wrong, disgusting, an abomination.
But maybe... just maybe... it'll work.
Maybe. If the names are relative to populated slots, maybe not.
On Tue, Jan 14, 2014 at 08:54:33PM -0600, Les Mikesell wrote:
On Tue, Jan 14, 2014 at 8:43 PM, Stephen Harris lists@spuddy.org wrote:
Ultimately what we have is a situation similar to hard disks. We've got used to sd devices changing depending on the order disks are discovered in, which is why we use LABEL or UUID.
But those don't work until something has already identified the device. If you are old enough, you might remember unix versions that
At install time "we have a disk; we designate it 'datadisk' we give it label DATA". That's what Anaconda does. The production kernel might find it as another disk, but because it has the label then all works. There's still a "boot" dependency, but there's not a lot we can do to work around the BIOS.
named disks by controller, bus, target numbers. Which worked, but wasn't very human-friendly either.
You mean the "modern" c0t0d0s0 type structures (eg Solaris SPARC) and similar (truncated) SVR4 Intel paths? Heh, I'm much older than that.
That was actually not a bad scheme... but it required the bus to be detected in a consistent format. The problem with the Intel architecture is that this detection is _not_ consistent. It depends on module loading order, hotplug device issues etc etc. "c0" isn't necessarily "c0" on an Intel platform. That's where it all fell down.
Back in the day (if you can remember back that far), Dell servers were a fun issue with RedHat; the install kernel would detect devices on the PCI bus in one order but the production install kernel would detect them in the _reverse_ order. So if you had two ethernet cards eth0 and eth1 would be reversed between install and boot kernels. Some HP servers also did this. Fun times!
On 1/14/2014 19:54, Les Mikesell wrote:
On Tue, Jan 14, 2014 at 8:43 PM, Stephen Harris lists@spuddy.org wrote:
If you are old enough, you might remember unix versions that named disks by controller, bus, target numbers.
/dev/rdsk/c0t0n0q0w0e0p1k5n8.... :)
It's another reason I took to Linux quickly, right along with eth0.
The new process is new and therefor bad, wrong, disgusting, an abomination.
But maybe... just maybe... it'll work.
Maybe. If the names are relative to populated slots, maybe not.
Ve shall see.
On 01/15/2014 06:17 AM, Warren Young wrote:
On 1/14/2014 19:54, Les Mikesell wrote:
On Tue, Jan 14, 2014 at 8:43 PM, Stephen Harris lists@spuddy.org wrote:
If you are old enough, you might remember unix versions that named disks by controller, bus, target numbers.
/dev/rdsk/c0t0n0q0w0e0p1k5n8.... :)
It's another reason I took to Linux quickly, right along with eth0.
I'm old enough to remember another distribution where the trick was to symlink to /dev/cdrom. DO you? :-P
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?
On 01/15/2014 02:17 PM, Warren Young 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". BSD and big iron Unix named the interface after the Ethernet driver, as if that was what was important.
Admittedly I like the ethX naming scheme as well, but it did have issues.
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?
There are situations where the nic needs to be used or at least initialized before networking is brought up, pxe boot comes to mind as just one example. With the new naming convention the nic will have a consistent name everywhere barring any hardware changes (like moving it to a different slot).
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.
Evil shades of PR#1, begone!
You can still use the old naming convention. There's a setting somewhere for it and it's easy to change, I can't recall off the top of my head where it is, though.
Peter
On 01/14/2014 08:17 PM, Warren Young wrote:
On 1/14/2014 16:37, Scott Robbins wrote:
On Tue, Jan 14, 2014 at 02:57:20PM -0700, Warren Young wrote:
Everyone, drop a tear for the dead "eth0". <sniff> We will miss you, eth0!
Haven't played much with it in CentOS. In Fedora, at present, it is a bit of pain as both biosdevname and systemd have something to do with it, making it less consistent than ever.
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". BSD and big iron Unix named the interface after the Ethernet driver, as if that was what was important.
I agree - it was so much easier when we switched to CentOS from FreeBSD all the interfaces were ethx instead of vrx, rlx, edx, fxpx, emx, bge, etc - it made it so much easier when the hardware platform changed to move our software configs.
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?
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.
Evil shades of PR#1, begone!
(Apple DOS 3.3 reference, there.) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 01/14/14 20:17, Warren Young wrote:
On 1/14/2014 16:37, Scott Robbins wrote:
On Tue, Jan 14, 2014 at 02:57:20PM -0700, Warren Young wrote:
Everyone, drop a tear for the dead "eth0". <sniff> We will miss you, eth0!
Haven't played much with it in CentOS. In Fedora, at present, it is a bit of pain as both biosdevname and systemd have something to do with it, making it less consistent than ever.
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". BSD and big iron Unix named the interface after the Ethernet driver, as if that was what was important.
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?
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.
Evil shades of PR#1, begone!
(Apple DOS 3.3 reference, there.)
What do you mean, "slot"? All of my servers, and our systems at home, the NIC's on the m/b. What "slot" is that? Is it labeled *anywhere*? No, of course not.
mark
On Wed, 15 Jan 2014, mark wrote:
What do you mean, "slot"? All of my servers, and our systems at home, the NIC's on the m/b. What "slot" is that? Is it labeled *anywhere*? No, of course not.
Many servers have PCI cards for NICs in addition to those on the motherboard (if any). For example, most of my file servers have eight ethernet interfaces (six 1GBE, two 10GbE). On my Dell servers, the built-in interfaces are labeled on the back panel.
However, at least in CentOS 6, you can call the interfaces anything you want by suitably changing /etc/udev/rules.d/70-persistent-net.rules. The names used have to be consistent with /etc/sysconfig/network-scripts/ifcfg-* of course.
BTW, I have some workstations that have only a single interface, and that comes up as p2p1. I actually like the new scheme better, but don't get me started on the use of UUID in /etc/fstab...
Steve
Steve Thompson wrote:
On Wed, 15 Jan 2014, mark wrote:
What do you mean, "slot"? All of my servers, and our systems at home, the NIC's on the m/b. What "slot" is that? Is it labeled *anywhere*?
No, of
course not.
Many servers have PCI cards for NICs in addition to those on the motherboard (if any). For example, most of my file servers have eight ethernet interfaces (six 1GBE, two 10GbE). On my Dell servers, the built-in interfaces are labeled on the back panel.
I can think of one server we've got, a Dell PER815, that's got a NIC (that we don't use, dunno why it was in there), and four onboard.
However, at least in CentOS 6, you can call the interfaces anything you want by suitably changing /etc/udev/rules.d/70-persistent-net.rules. The names used have to be consistent with /etc/sysconfig/network-scripts/ifcfg-* of course.
BTW, I have some workstations that have only a single interface, and that comes up as p2p1. I actually like the new scheme better, but don't get me started on the use of UUID in /etc/fstab...
I disliked it when the first time I started doing sysadmin, on a Sparcserver 20, back in the mid-nineties, and I don't like it any better now. Among other things, too easy to mistype one of the letters or numbers.
About UUIDs, though, I think we can start on that in harmony. UUID is *so* much easier to remember, and shorter than, say, the serial number on the disk label... oh, right, it's twice as long....
mark
On 1/15/2014 05:41, mark wrote:
On 01/14/14 20:17, Warren Young wrote:
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.
What do you mean, "slot"? All of my servers, and our systems at home, the NIC's on the m/b.
I know what you mean, but on those systems, the Ethernet MAC chip is still on the PCI[e] bus, so it still gets a slot number. If you say lspci, it's generally the second number, between the colon and dot.
Fun fact: the MAC chip isn't always on a PCI[e] bus. On the Raspberry Pi, it's on the USB bus, despite the fact that it's soldered to the PCB!
On 01/15/2014 10:57 AM, Warren Young wrote:
On 1/14/2014 14:32, m.roth@5-cent.us wrote:
Everyone, drop a tear for the dead "eth0". <sniff> We will miss you, eth0!
Not as dead as you may think, there are still situations where eth0 will be used, even by default:
[root@el7-test ~]# ip a ... 2: eth0: ...
Peter
-
Darr247 -
John R Pierce -
Les Mikesell -
Ljubomir Ljubojevic -
m.roth＠5-cent.us -
mark
-
Mihamina Rakotomandimby -
Peter -
Scott Robbins -
Stephen Harris -
Steve Clark -
Steve Thompson -
Thomas Eriksson -
Warren Young