FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 04-29-2011, 08:10 PM
Kenneth Porter
 
Default RHEL 6.1 beta

Some interesting developments coming:

<http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/96/html/6.1_Release_Notes/index.html>

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-02-2011, 10:48 AM
Christopher Chan
 
Default RHEL 6.1 beta

On Saturday, April 30, 2011 04:10 AM, Kenneth Porter wrote:
> Some interesting developments coming:
>
> <http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/96/html/6.1_Release_Notes/index.html>
>

biosdevname for nics...bye bye eth0!

FUSE!

control groups!

a linux 2.2 feature!

ipchains anyone?
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-02-2011, 10:53 AM
Christopher Chan
 
Default RHEL 6.1 beta

On Monday, May 02, 2011 06:48 PM, Christopher Chan wrote:
> On Saturday, April 30, 2011 04:10 AM, Kenneth Porter wrote:
>> Some interesting developments coming:
>>
>> <http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/96/html/6.1_Release_Notes/index.html>
>>
>
> biosdevname for nics...bye bye eth0!
>
> FUSE!
>
> control groups!
>
> a linux 2.2 feature!
>
> ipchains anyone?

We're getting finger print authentication on our screen savers. Soon, we
are going to have to show our ugly faces instead grubby silicon fingers.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-02-2011, 01:38 PM
Lamar Owen
 
Default RHEL 6.1 beta

On Monday, May 02, 2011 06:48:37 AM Christopher Chan wrote:
> biosdevname for nics...bye bye eth0!

Not by default, and according to the release notes only for certain Dell servers ATM.

But, yes, a different way of looking at NICs is coming down the pipe. It's about time.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-02-2011, 01:57 PM
Steve Clark
 
Default RHEL 6.1 beta

On 05/02/2011 09:38 AM, Lamar Owen wrote:

On Monday, May 02, 2011 06:48:37 AM Christopher Chan wrote:


biosdevname for nics...bye bye eth0!



Not by default, and according to the release notes only for certain Dell servers ATM.

But, yes, a different way of looking at NICs is coming down the pipe. It's about time.


EGADS Why?* After working with FreeBSD for ten years it so nice not
to have to worry is this rl0, vr0, em0, fxp0, bge0, ed0,

etc in networking scripts. Why would you want to go back to that?





--

Stephen*Clark

NetWolves

Sr.*Software*Engineer*III

Phone:*813-579-3200

Fax:*813-882-0209

Email:*steve.clark@netwolves.com

http://www.netwolves.com




_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-02-2011, 02:41 PM
Peter A
 
Default RHEL 6.1 beta

On Monday, May 02, 2011 09:57:19 AM Steve Clark wrote:
> On 05/02/2011 09:38 AM, Lamar Owen wrote:
> > On Monday, May 02, 2011 06:48:37 AM Christopher Chan wrote:
> >> biosdevname for nics...bye bye eth0!
> >
> > Not by default, and according to the release notes only for certain Dell
> > servers ATM.
> >
> > But, yes, a different way of looking at NICs is coming down the pipe.
> > It's about time.
>
> EGADS Why? After working with FreeBSD for ten years it so nice not to have
> to worry is this rl0, vr0, em0, fxp0, bge0, ed0, etc in networking
> scripts. Why would you want to go back to that?

I couldn't agree more... One of the things in Solaris that was always a pain.
Just write a monitoring script that enumerates all devices... On linux you
simply write a loop, start with eth0 and go up. On Solaris, you parse
path_to_inst, then go from there iterating over the devices and instances...
Not real hard to do but makes a script go from 80 lines on Linux to about 250
lines on Solaris.
Oh and then of course there is the lovely implementation in Oracle RAC (and
many other clustered pieces of software) that wants the same interface name on
all hosts. Good luck finding two identical systems for the demo tomorrow
afternoon

Essentially, having names per driver sounds good - until you actually lived
it. Then you realize you gain virtually nothing (how often have you really
looked at the cabeling of a server after its initial install) and made it
significanly more complex to script and maintain.

Peter.


--
Censorship: noun, circa 1591. a: Relief of the burden of independent thinking.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-02-2011, 02:47 PM
Les Mikesell
 
Default RHEL 6.1 beta

On 5/2/2011 8:57 AM, Steve Clark wrote:
> On 05/02/2011 09:38 AM, Lamar Owen wrote:
>> On Monday, May 02, 2011 06:48:37 AM Christopher Chan wrote:
>>> biosdevname for nics...bye bye eth0!
>> Not by default, and according to the release notes only for certain Dell servers ATM.
>>
>> But, yes, a different way of looking at NICs is coming down the pipe. It's about time.
> EGADS Why? After working with FreeBSD for ten years it so nice not to
> have to worry is this rl0, vr0, em0, fxp0, bge0, ed0,
> etc in networking scripts. Why would you want to go back to that?

The numbers chosen in the eth? scheme are more or less randomized even
on identical hardware, so it is pretty much impossible to prepare a disk
to ship to a remote site and have it come up working unattended or clone
disk images for a large rollout. If this gives predictable names in
bios-detection order it will be very useful. Remote-site support is
expensive and typically not great at the quirks of Linux distributions
that you need to know to do IP assignments.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-02-2011, 02:58 PM
 
Default RHEL 6.1 beta

Les Mikesell wrote:
> On 5/2/2011 8:57 AM, Steve Clark wrote:
>> On 05/02/2011 09:38 AM, Lamar Owen wrote:
>>> On Monday, May 02, 2011 06:48:37 AM Christopher Chan wrote:
>>>> biosdevname for nics...bye bye eth0!
>>> Not by default, and according to the release notes only for certain Dell
>>> servers ATM.
>>>
>>> But, yes, a different way of looking at NICs is coming down the pipe.
It's about
>>>time.
>> EGADS Why? After working with FreeBSD for ten years it so nice not to
have to worry
>> is this rl0, vr0, em0, fxp0, bge0, ed0, etc in networking scripts. Why
would you
>> want to go back to that?
>
> The numbers chosen in the eth? scheme are more or less randomized even
on identical hardware, so it is pretty much impossible to prepare a disk
<snip>
Anybody know *why*? Is it based on the order of response of the NIC
firmware? Certainly, were I writing the code, I'd have based it on the bus
address.

mark


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-02-2011, 03:07 PM
Les Mikesell
 
Default RHEL 6.1 beta

On 5/2/2011 9:58 AM, m.roth@5-cent.us wrote:
>
>>>> But, yes, a different way of looking at NICs is coming down the pipe.
> It's about
>>>> time.
>>> EGADS Why? After working with FreeBSD for ten years it so nice not to
> have to worry
>>> is this rl0, vr0, em0, fxp0, bge0, ed0, etc in networking scripts. Why
> would you
>>> want to go back to that?
>>
>> The numbers chosen in the eth? scheme are more or less randomized even
> on identical hardware, so it is pretty much impossible to prepare a disk
> <snip>
> Anybody know *why*? Is it based on the order of response of the NIC
> firmware? Certainly, were I writing the code, I'd have based it on the bus
> address.

I think the 2.4 kernel did it that way, and was single-threaded during
detection. At least I seldom had problems omitting the HWADDR= setting
from ifcfg-eth? files and moving disks to a different chassis. My
impression was that 2.6 tries to do device detection in parallel to
speed up booting and thus makes the order unpredictable. As I recall,
there was a bug in early RHEL/Centos 5.x versions where the HWADDR=
setting was ignored if it was wrong, fixed in an update that made the
interface not come up at all. That made for fun times after the
update/reboot on remote machines...

--
Les Mikesell
lesmikesell@gmail.com


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-02-2011, 03:14 PM
Lamar Owen
 
Default RHEL 6.1 beta

On Monday, May 02, 2011 09:57:19 AM Steve Clark wrote:
> On 05/02/2011 09:38 AM, Lamar Owen wrote:
> > But, yes, a different way of looking at NICs is coming down the pipe. It's about time.
> EGADS Why? After working with FreeBSD for ten years it so nice not to have to worry is this rl0, vr0, em0, fxp0, bge0, ed0,
> etc in networking scripts. Why would you want to go back to that?

I knew I'd get a reaction..... :-) And it's good to see Peter A around again.....

Major networking gear does this; cisco, for instance, gives you things like FastEthernet4/47, or GigabitEthernet2/2, or TenGigabitEthernet1/0, or POS3/0, etc for networking interfaces. Having seen the PCI eth device flips before between update releases of EL4, to give one example, it's really nice to be able to really know what device you've plugged a particular cable into, and know it in an unequivocal, and unchanging way.

I might, for instance, put the server's primary 'serving' port(s) on server-grade gig or tengig ethernet adapters, but do out-of-band ethernet management on the motherboard's built-in Realtek 8139. Ok, I have eth0, eth1, eth2, and eth3. I have a dual-port Intel e1000 on a 64-bit PCI-X slot (and the card is PCI-X 133 capable, and I have two motherboard ethernet ports.

Care to guess which eth's go to which ports with a recent kernel (F14's kernel)? You might cringe: eth0 is the first e1000 port; eth1 and eth2 are the first and second motherboard ports (and the linux enumeration order is opposite of the labeling on the botherboard!); eth3 is the second e1000 port. This is better than previous; I've used the same hardware for quite a while now for one of my development servers, and between CentOS 5, and Fedoras 11, 12, 13, and 14, I've not had consistent ethernet enumeration.

Likewise, I'm working on a packetfence box (based on C5); the capture devices are server grade gig-e devices, and the managment port is a run-of-the-mill RTL8139. I really want to be able, without having eyes on the box, to know for a fact what device I'm working with. I know about grepping dmesg, but even then it's not nearly as easy as with a cisco box (like our two 7609's or our 12008) where I just:
configure terminal
interface gigabitethernet1/2
......

and I *know* exactly, with no magic, what port I'm working with.

I also know that my requirements aren't typical 'home' users' requirements; but this *is* the CentOS list, not the Fedora list, right?

I know the convenience of kickstarting to possibly heterogeneous hardware; but device aliases are available and reasonable setup of those aliases can eliminate most of the problems.

Now, I'm not sure I particularly care for the current biosdevname setup; but I also know that upstream is going to be rather careful about this particular change, especially given the flak that has happened in the past with devnames flipping between kernel releases.

But then I can pull out all the stops on my most beastly networking config on a Linux box: our Sun E6500 (for which I hope to do a from-source C6 rebuild): every I/O card in the box has an ethernet port; I have eight I/O cards in this box, two of which are SunGEM gigabit cards. I'd love to be able to get the devname in a slot-subslot format, like cisco..... but that's not currently the way it is. And it gets worse if I pull an I/O card, particularly given the E6500's slot numbered 'fun.'

When you get to the level of a box having half a dozen or more ethernet devices of various capabilities and speeds, you begin to really despise the single namespace that currently exists, especially when the devnames change between kernel releases.

HWADDR in the configs has helped fix some of that, but that's worse than the biosdevname setup when it comes to imaging/cloing between multiple boxes....
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 10:51 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org