public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download: 
* Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
  @ 2013-03-29 11:29 99%           ` Samuli Suominen
  0 siblings, 0 replies; 1+ results
From: Samuli Suominen @ 2013-03-29 11:29 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

On 29/03/13 13:01, Diego Elio Pettenò wrote:
> On 29/03/2013 11:50, Samuli Suominen wrote:
>> Not false, but configurable, and linked from the news item -- nobody
>> stopping you from eg. using MAC addresses instead of PCI slots for
>> defining the names, just like one would have renamed them using MAC with
>> 70-persistent-net.rules
>
> Which I usually do. But
>
> "With the new predictable ... scheme ... the names will be static and
> not randomly rename ..."
>
> is false.
>
> The name will be predictable before rebooting (maybe?) but it could very
> easily change randomly on udev update.
>> Not FUD, but a fact, depends on the driver code (in kernel) if it'll
>> change or not
>> That's random enough as we can't force people to track kernel source
>> tree and drivers code
>
> Hm hm. It's still FUD.
>
> If my desktop only has one Ethernet interface, no matter how many kernel
> changes happen, it'll always be eth0.
>
> Whereas, with the new predictable scheme, if I move that card around, it
> will change name.
>
> Tell me which one is random, again?

I see. You politely wanted to point out these lacks in the news item. 
Sorry, it was hard to see it through from all the sarcasm.

(New item attached, and also covers ulm's concerns from the another reply.)

>
> ---
> I'm not saying you shouldn't enable it (feel free to screw up user as
> much as you want, just don't complain if they don't like you),

I don't remember complaining about users not liking me, nor caring about 
it. If they want to shoot the messenger, that's fine by me.

> but since
> both kernel naming and predictable naming have their chance to change,
> don't spread FUD.

One you can control, the another you can't. So still not FUD.


[-- Attachment #2: 2013-03-29-udev-predictable-network-interface-names.en.txt --]
[-- Type: text/plain, Size: 3101 bytes --]

Title: The new predictable net iface names
Author: Samuli Suominen <ssuominen@gentoo.org>
Content-Type: text/plain
Posted: 2013-03-29
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <sys-fs/udev-201

If you still have network interface renaming rules in /etc/udev/rules.d,
like 70-persistent-net.rules, you will need to modify or remove them.

If you choose to modify them, you will need to pick a free namespace
(like net* or internet*) that is not reserved by the kernel
(like eth* or wlan*) because in-place renaming has been deprecated[1].
You should also rename the file to something else, like
70-my-network.rules to silence the deprecation warning coming from when
you emerge udev.

This is old format:

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="xx:xx:xx:xx:xx:xx",
NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="yy:yy:yy:yy:yy:yy",
NAME="eth1"

This is new format:

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="xx:xx:xx:xx:xx:xx",
NAME="net0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="yy:yy:yy:yy:yy:yy",
NAME="net1"

With the new predictable network interface naming scheme which upstream
enabled by default you don't have to rename anymore because the names
will be static and not randomly rename when you, for example, upgrade
the kernel. The default name is calculated from the slot being used for
the card, but it can be changed to be, for example, MAC based. This is
documented in the upstream wiki[2]. This can be very important aspect,
for example, security in mind.

If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's
a symlink to /dev/null, the new names will be disabled and kernel will
do all the interface naming, which will be random.

The new names can also be disabled using net.ifnames=0 kernel option.

However, if your system has only one network interface card,
for example, eth0, you don't necessarily need this feature at all.
Use the forementioned methods to disable the feature in that case if
you want.

In normal new installation there is no files put in /etc/udev/rules.d
and if you haven't edited any files you have in there, you should most
likely delete (backup) them all out of the way.

You can find out using udevadm command what your interfaces will be
called before booting to make necessary changes, such as changing
net.* symlinks in /etc/init.d.

This is the example command:

# udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null

The output could be (and I'm only picking the most important line for
this example):

ID_NET_NAME_PATH=enp2s0f0

This would mean your eth0 will be called enp2s0f0 if there is no
previously mentioned files blocking the new names taking place in
/etc/udev/rules.d.

This is documented more throughly at upstream wiki[2] which everyone
should read at least once.

This feature can also replace the functionality of sys-apps/biosdevname,
but you can still keep using it if you want.

[1] http://www.kernel.org/doc/htmldocs/device-drivers/
    API-device-rename.html
[2] http://www.freedesktop.org/wiki/Software/systemd/
    PredictableNetworkInterfaceNames

^ permalink raw reply	[relevance 99%]

Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2013-03-29  8:09     [gentoo-dev] Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt Samuli Suominen
2013-03-29 10:24     ` [gentoo-dev] " Duncan
2013-03-29 10:26       ` Samuli Suominen
2013-03-29 10:46         ` Diego Elio Pettenò
2013-03-29 10:50           ` Samuli Suominen
2013-03-29 11:01             ` Diego Elio Pettenò
2013-03-29 11:29 99%           ` Samuli Suominen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox