[gentoo-dev] Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[gentoo-dev] Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Samuli Suominen]

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

This is required for stabilizing new udev (bug #463614)
And required otherwise too as people are still confused from what I have 
seen in forums
I hope this isn't too much of an hand holding

Will push it tomorrow'ish if noone complains (and fix grammar later too 
if required)

Thanks for looking into it!



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

Title: The new default predictable network interface naming with udev
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. 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.

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 will also replace the functionality of sys-apps/biosdevname which
you should uninstall. However, you can still keep using sys-apps/biosdevname
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

[gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Duncan]

Samuli Suominen posted on Fri, 29 Mar 2013 10:09:27 +0200 as excerpted:

> This feature will also replace the functionality of sys-apps/biosdevname
> which you should uninstall. However, you can still keep using
> sys-apps/biosdevname if you want.

I'd suggest...

This feature can optionally replace... can uninstall.

IOW...

s/will also/can optionally/

s/should/can/


It sounds less menacing than your suggested wording, making it clearer 
that it's an optional replacement and lessening the apparent conflict and 
possible confusion with the next sentence saying it can still be used if 
desired.

I'd say that's a particularly good idea given the sensitivity around the 
"all engulfing gray goo" that systemd has seemed to many to have become.
Given that upstream specifically designed this feature to cooperate with 
existing biosdevname installations, let's not unnecessarily poke that 
hornet's nest by implying otherwise, even if the next sentence /does/ 
basically say it's an optional change anyway.  =:^/

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Samuli Suominen]

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

On 29/03/13 12:24, Duncan wrote:
> Samuli Suominen posted on Fri, 29 Mar 2013 10:09:27 +0200 as excerpted:
>
>> This feature will also replace the functionality of sys-apps/biosdevname
>> which you should uninstall. However, you can still keep using
>> sys-apps/biosdevname if you want.
>
> I'd suggest...
>
> This feature can optionally replace... can uninstall.
>
> IOW...
>
> s/will also/can optionally/
>
> s/should/can/
>
>
> It sounds less menacing than your suggested wording, making it clearer
> that it's an optional replacement and lessening the apparent conflict and
> possible confusion with the next sentence saying it can still be used if
> desired.
>
> I'd say that's a particularly good idea given the sensitivity around the
> "all engulfing gray goo" that systemd has seemed to many to have become.
> Given that upstream specifically designed this feature to cooperate with
> existing biosdevname installations, let's not unnecessarily poke that
> hornet's nest by implying otherwise, even if the next sentence /does/
> basically say it's an optional change anyway.  =:^/
>

OK, new one attached, should be better

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

Title: The new default predictable network interface naming with udev
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. 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.

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

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Diego Elio Pettenò]

On 29/03/2013 11:26, Samuli Suominen wrote:
> 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. This can be
> very important aspect, for example, security in mind.

You do know this is false, right? The names are supposed to be
predictable, not persistent. If you do happen to MOVE your network card
because the new videocard you add to your system does not fit otherwise,
the name _will_ change.

> 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.

Avoid spreading FUD about naming being random. Thanks.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Samuli Suominen]

On 29/03/13 12:46, Diego Elio Pettenò wrote:
> On 29/03/2013 11:26, Samuli Suominen wrote:
>> 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. This can be
>> very important aspect, for example, security in mind.
>
> You do know this is false, right? The names are supposed to be
> predictable, not persistent. If you do happen to MOVE your network card
> because the new videocard you add to your system does not fit otherwise,
> the name _will_ change.

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

>> 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.
>
> Avoid spreading FUD about naming being random. Thanks.

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

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Diego Elio Pettenò]

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'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), but since
both kernel naming and predictable naming have their chance to change,
don't spread FUD.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Ulrich Mueller]

>>>>> On Fri, 29 Mar 2013, Samuli Suominen wrote:

> Title: The new default predictable network interface naming with udev

This is too long. GLEP 42 says:

| Title: A short (maximum 44 characters) descriptive title.

Also:

| The text body should be wrapped at 72 characters.

Ulrich

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Samuli Suominen]

[-- 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

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Chí-Thanh Christopher Nguyễn]

Diego Elio Pettenò schrieb:
> If my desktop only has one Ethernet interface, no matter how many kernel
> changes happen, it'll always be eth0.

That was not true with the old persistent naming. One example which we
encountered in #gentoo IRC was the split between e1000 and e1000e drivers
which caused interfaces to change names.

> Whereas, with the new predictable scheme, if I move that card around, it
> will change name.

It's even worse, if you mess with kernel parameters (esp. pci=assign-busses
for PCMCIA) then the device numbering might change without hardware moving
around.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Diego Elio Pettenò]

On 29/03/2013 12:29, Samuli Suominen wrote:
> One you can control, the another you can't. So still not FUD.

You do not really control it any more than the kernel. The fact that me
and you can edit an udev ruleset to "control" it, does not mean that
most users see it as a black box.

The news item reads better. I would still either avoid showing the
NET_PATH example or describe that that is not the final result because
on a laptop, NET_PATH almost certainly will *not* match the final
interface name:

flame@saladin~ % udevadm test-builtin net_id /sys/class/net/eno1 2>/dev/null
ID_NET_NAME_MAC=enx0026b9d7bf1f
ID_OUI_FROM_DATABASE=Dell Inc
ID_NET_NAME_ONBOARD=eno1
ID_NET_LABEL_ONBOARD=en Onboard LAN
ID_NET_NAME_PATH=enp0s25

And I would not expect users to all go read the wiki and try to figure
out why you said it would be named enp0s25 when it gets the name eno1.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Diego Elio Pettenò]

On 29/03/2013 12:34, Chí-Thanh Christopher Nguyễn wrote:
> Diego Elio Pettenò schrieb:
>> > If my desktop only has one Ethernet interface, no matter how many kernel
>> > changes happen, it'll always be eth0.
> That was not true with the old persistent naming. One example which we
> encountered in #gentoo IRC was the split between e1000 and e1000e drivers
> which caused interfaces to change names.

Okay let me re-qualify the statement:

"If my desktop only has one Ethernet interface, and I don't mess up with
it in userspace at all, no matter how many kernel changes happen, it'll
always be eth0".

Yes, the previous persistent rules for udev would have messed that one
up when e1000e got split, or if you switched between the
Broadcom-provided driver to the kernel one or vice-versa. The deathforce
drivers come in mind as well.

> 
>> > Whereas, with the new predictable scheme, if I move that card around, it
>> > will change name.
> It's even worse, if you mess with kernel parameters (esp. pci=assign-busses
> for PCMCIA) then the device numbering might change without hardware moving
> around.

Sweet I didn't think about that. Yai for predictably variable names.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Samuli Suominen]

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

On 29/03/13 13:38, Diego Elio Pettenò wrote:
> On 29/03/2013 12:29, Samuli Suominen wrote:
>> One you can control, the another you can't. So still not FUD.
>
> You do not really control it any more than the kernel. The fact that me
> and you can edit an udev ruleset to "control" it, does not mean that
> most users see it as a black box.

I don't agree with that, /etc/udev/rules.d and overriding udev rules is 
very basic administration, very basic...
I'll put a bit more trust on our users.

> The news item reads better. I would still either avoid showing the
> NET_PATH example or describe that that is not the final result because
> on a laptop, NET_PATH almost certainly will *not* match the final
> interface name:
>
> flame@saladin~ % udevadm test-builtin net_id /sys/class/net/eno1 2>/dev/null
> ID_NET_NAME_MAC=enx0026b9d7bf1f
> ID_OUI_FROM_DATABASE=Dell Inc
> ID_NET_NAME_ONBOARD=eno1
> ID_NET_LABEL_ONBOARD=en Onboard LAN
> ID_NET_NAME_PATH=enp0s25
>
> And I would not expect users to all go read the wiki and try to figure
> out why you said it would be named enp0s25 when it gets the name eno1.
>

Nod.
Attached new version again, more generic than before.
Hope it'll do what it's meant to do... push users into right direction...
It's not meant to be a complete documentation or rewrite of the upstream 
wiki page :-p
Just a push...

[-- Attachment #2: 2013-03-29-udev-predictable-network-interface-names.en.txt --]
[-- Type: text/plain, Size: 3099 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 names can be calculated from the slots being
used for the cards, but it can be changed to use, for example, MAC
addresses. This is documented in the upstream wiki[2].

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 for getting attributes of the current eth0
network device:

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

Assuming there are no leftover rules in /etc/udev/rules.d that would
prevent the new names from being enabled, it's most likely either
ID_NET_NAME_ONBOARD or ID_NET_NAME_PATH lines you should be looking
at for the new name in default configuration. This ordering 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

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Diego Elio Pettenò]

On 29/03/2013 13:20, Samuli Suominen wrote:
> I don't agree with that, /etc/udev/rules.d and overriding udev rules is
> very basic administration, very basic...
> I'll put a bit more trust on our users.

Let's agree to disagree then. To me, it's much more consistent the
kernel's behaviour than these "predictable" names. Is my WWAN interface
wwan0, wwp0s29u1u2i1, wws1u1i1 or wwp0s29u1u3i1 today?

> Attached new version again, more generic than before.
> Hope it'll do what it's meant to do... push users into right direction...
> It's not meant to be a complete documentation or rewrite of the upstream
> wiki page :-p

Better, not perfect IMHO, but definitely better.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Michael Mol]

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

On 03/29/2013 08:20 AM, Samuli Suominen wrote:
> On 29/03/13 13:38, Diego Elio Pettenò wrote:
>> On 29/03/2013 12:29, Samuli Suominen wrote:
>>> One you can control, the another you can't. So still not FUD.
>>
>> You do not really control it any more than the kernel. The fact that me
>> and you can edit an udev ruleset to "control" it, does not mean that
>> most users see it as a black box.
> 
> I don't agree with that, /etc/udev/rules.d and overriding udev rules is
> very basic administration, very basic...

I'd love to believe that, but do you have any idea how many people
aren't familiar with it? It took a long time before the default response
to "help, I've replaced my NIC or motherboard, and eth0 is gone!" became
"find and remove this line from
/etc/udev/rules.d/70-persistent-net.rules" instead of "remove
/etc/udev/rules.d/70-persistent-net.rules"

Something else...I've not encountered *one* other person to use anything
other than the system-default names for NICs...except myself. And when
I've done it, and despite giving them descriptive names, other people
are completely flummoxed when they see my configurations. "What's this
'wan', 'lan' and 'wifilan'? Where are eth0, eth1 and eth2?"

And of those I've found who knew of the feature and knew how to use it,
none have ever felt motivated to use it except when hardware was replaced.

(Personally, I find the feature underused; I could easily see networks
benefiting from rules like "any interface prefixed with 'p' is public
facing without the benefit of a firewall", "any interface prefixed with
's' points to a SAN" or "any interface prefixed with a 'c' is touches a
network region where PCI-compliance rules are in effect.")

> I'll put a bit more trust on our users.
> 
>> The news item reads better. I would still either avoid showing the
>> NET_PATH example or describe that that is not the final result because
>> on a laptop, NET_PATH almost certainly will *not* match the final
>> interface name:
>>
>> flame@saladin~ % udevadm test-builtin net_id /sys/class/net/eno1
>> 2>/dev/null
>> ID_NET_NAME_MAC=enx0026b9d7bf1f
>> ID_OUI_FROM_DATABASE=Dell Inc
>> ID_NET_NAME_ONBOARD=eno1
>> ID_NET_LABEL_ONBOARD=en Onboard LAN
>> ID_NET_NAME_PATH=enp0s25
>>
>> And I would not expect users to all go read the wiki and try to figure
>> out why you said it would be named enp0s25 when it gets the name eno1.
>>
> 
> Nod.
> Attached new version again, more generic than before.
> Hope it'll do what it's meant to do... push users into right direction...
> It's not meant to be a complete documentation or rewrite of the upstream
> wiki page :-p
> Just a push...

I would probably replace this:

"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."

With something like this:

"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, and the resulting names will vary by kernel
and hardware configuration, and may vary by kernel version."



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Andreas K. Huettel]

Am Freitag, 29. März 2013, 13:20:20 schrieb Samuli Suominen:
> On 29/03/13 13:38, Diego Elio Pettenò wrote:
> > On 29/03/2013 12:29, Samuli Suominen wrote:
> >> One you can control, the another you can't. So still not FUD.
> > 
> > You do not really control it any more than the kernel. The fact that me
> > and you can edit an udev ruleset to "control" it, does not mean that
> > most users see it as a black box.
> 
> I don't agree with that, /etc/udev/rules.d and overriding udev rules is
> very basic administration, very basic...
> I'll put a bit more trust on our users.

Not really. Every time I modified anything in there, it just took a few udev 
versions and suddenly I was flooded with deprecation warnings a la "things 
work different now, find out on your own how to fix it..."

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Rich Freeman]

On Fri, Mar 29, 2013 at 9:24 AM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
> Not really. Every time I modified anything in there, it just took a few udev
> versions and suddenly I was flooded with deprecation warnings a la "things
> work different now, find out on your own how to fix it..."

Not to mention at least in the past it has tended to accumulate
orphans.  I was getting tons of warnings on boot-up and discovered
that config protection left a ton of files in there from
who-knows-when.  Granted, this is on a system that has been running
Gentoo for about a decade now (every part in it has changed several
times, but the OS has steadily migrated along).

Now I'm down to 5 files in there, and only one of them is my
local.rules file.  If udev is going to stick stuff in /etc then it
really needs to have better communication when this stuff needs to be
modified/cleaned/etc, and what users are and aren't supposed to touch.

Rich

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Samuli Suominen]

On 29/03/13 15:30, Rich Freeman wrote:
> On Fri, Mar 29, 2013 at 9:24 AM, Andreas K. Huettel
> <dilfridge@gentoo.org> wrote:
>> Not really. Every time I modified anything in there, it just took a few udev
>> versions and suddenly I was flooded with deprecation warnings a la "things
>> work different now, find out on your own how to fix it..."
>
> Not to mention at least in the past it has tended to accumulate
> orphans.  I was getting tons of warnings on boot-up and discovered
> that config protection left a ton of files in there from
> who-knows-when.  Granted, this is on a system that has been running
> Gentoo for about a decade now (every part in it has changed several
> times, but the OS has steadily migrated along).
>
> Now I'm down to 5 files in there, and only one of them is my
> local.rules file.  If udev is going to stick stuff in /etc then it
> really needs to have better communication when this stuff needs to be
> modified/cleaned/etc, and what users are and aren't supposed to touch.
>
> Rich
>

What do you have there? We cover bunch of those in pkg_postinst of udev 
already.

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Rich Freeman]

On Fri, Mar 29, 2013 at 9:44 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> What do you have there? We cover bunch of those in pkg_postinst of udev
> already.

After a bunch of cleanup (after which I have yet to detect any
problems), I have:
70-persistent-cd.rules  70-persistent-net.rules
80-net-name-slot.rules  kino.rules  local.rules

Only media-video/kino actually claims one of those files.  If I missed
an elog message somewhere, I'm ready for my flogging.  :)

Rich

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Samuli Suominen]

On 29/03/13 16:35, Rich Freeman wrote:
> On Fri, Mar 29, 2013 at 9:44 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>> What do you have there? We cover bunch of those in pkg_postinst of udev
>> already.
>
> After a bunch of cleanup (after which I have yet to detect any
> problems), I have:
> 70-persistent-cd.rules  70-persistent-net.rules
> 80-net-name-slot.rules  kino.rules  local.rules
>
> Only media-video/kino actually claims one of those files.  If I missed
> an elog message somewhere, I'm ready for my flogging.  :)
>
> Rich
>

I fixed kino but I didn't revision bump for it. Waiting for something
bigger to revbump it. If you re-emerge kino, the rule will move to 
/lib/udev/rules.d.

Those 70-*  and 80-* are in udev pkg_postinst, this news item, 
everywhere... can all 3 be deleted if you haven't modified them yourself.

So that leaves one... local.rules... dunno about that. I'm curious.

- Samuli

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Rich Freeman]

On Fri, Mar 29, 2013 at 10:45 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> Those 70-*  and 80-* are in udev pkg_postinst, this news item, everywhere...
> can all 3 be deleted if you haven't modified them yourself.
>
> So that leaves one... local.rules... dunno about that. I'm curious.

Excellent, sounds good then.

The local rules are exactly what it sounds like - my own stuff.

Some of what it does is obsolete now.  It maps persistent symlinks to
two pl2303 rs232 usb interfaces (which I believe is a solved problem
now).  It maps persistent symlinks to a few video capture devices (not
a solved problem afaik).  It assigns firewire ports to the video group
(no idea if that is now in the standard rules).

Rich

[gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Nuno J. Silva (aka njsg)]

On 2013-03-29, Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:
> On 29/03/2013 12:34, Chí-Thanh Christopher Nguyễn wrote:
>> Diego Elio Pettenò schrieb:
>>> > If my desktop only has one Ethernet interface, no matter how many kernel
>>> > changes happen, it'll always be eth0.
>> That was not true with the old persistent naming. One example which we
>> encountered in #gentoo IRC was the split between e1000 and e1000e drivers
>> which caused interfaces to change names.
>
> Okay let me re-qualify the statement:
>
> "If my desktop only has one Ethernet interface, and I don't mess up with
> it in userspace at all, no matter how many kernel changes happen, it'll
> always be eth0".
>
> Yes, the previous persistent rules for udev would have messed that one
> up when e1000e got split, or if you switched between the
> Broadcom-provided driver to the kernel one or vice-versa. The deathforce
> drivers come in mind as well.

IMHO this is really relevant. It is annoying seeing how many people go
"oh you *must not* use the old scheme, because it won't work".

The new naming scheme does *not* prevent you from using eth0, users
should really just be told they can *disable* udev rules (and told how
to do it) if they are happy with the kernel name of their sole network
card, instead of being told that they *must* upgrade to the new rules.

The messages so far seem to imply that you can't have eth0. You *can*,
but udev won't be able to do anything if the device appears as
something else and there's already another eth0. If you don't already
have eth0, the udev rules *will* work, even if your card is named in
the eth namespace.

The *only* thing that breaks is renaming network devices to names that
are already in use inside the kernel namespaces.


-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Markos Chandras]

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

On 29 March 2013 16:21, Nuno J. Silva (aka njsg) <nunojsilva@ist.utl.pt>wrote:

> On 2013-03-29, Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:
> > On 29/03/2013 12:34, Chí-Thanh Christopher Nguyễn wrote:
> >> Diego Elio Pettenò schrieb:
> >>> > If my desktop only has one Ethernet interface, no matter how many
> kernel
> >>> > changes happen, it'll always be eth0.
> >> That was not true with the old persistent naming. One example which we
> >> encountered in #gentoo IRC was the split between e1000 and e1000e
> drivers
> >> which caused interfaces to change names.
> >
> > Okay let me re-qualify the statement:
> >
> > "If my desktop only has one Ethernet interface, and I don't mess up with
> > it in userspace at all, no matter how many kernel changes happen, it'll
> > always be eth0".
> >
> > Yes, the previous persistent rules for udev would have messed that one
> > up when e1000e got split, or if you switched between the
> > Broadcom-provided driver to the kernel one or vice-versa. The deathforce
> > drivers come in mind as well.
>
> IMHO this is really relevant. It is annoying seeing how many people go
> "oh you *must not* use the old scheme, because it won't work".
>
> The new naming scheme does *not* prevent you from using eth0, users
> should really just be told they can *disable* udev rules (and told how
> to do it) if they are happy with the kernel name of their sole network
> card, instead of being told that they *must* upgrade to the new rules.
>
> The messages so far seem to imply that you can't have eth0. You *can*,
> but udev won't be able to do anything if the device appears as
> something else and there's already another eth0. If you don't already
> have eth0, the udev rules *will* work, even if your card is named in
> the eth namespace.
>
> The *only* thing that breaks is renaming network devices to names that
> are already in use inside the kernel namespaces.
>
>
> --
> Nuno Silva (aka njsg)
> http://njsg.sdf-eu.org/
>
>
>
I sort of agree here. The news item is rather scary for people maintaining
remote boxes. Couldn't we just
preserve the old behavior with an opt-in for people who want to use this
new feature? Or am I reading the message wrong?
In my mind, the message says "either remove 70-* and setup 80-*" or your
system will end up broken.

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

[-- Attachment #2: Type: text/html, Size: 3308 bytes --]

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Rich Freeman]

On Fri, Mar 29, 2013 at 12:40 PM, Markos Chandras <hwoarang@gentoo.org> wrote:
> In my mind, the message says "either remove 70-* and setup 80-*" or your
> system will end up broken.

The other bit is that modifying symlinks in /etc/init.d is only
mentioned in passing.  That is a VERY important step unless your new
name happens to be the same as your old one, otherwise on the next
boot the system will not have a working network interface, which will
hamper efforts to fix for casual/new users, and cause real trouble for
those doing remote administration (though anybody doing anything
serious on a remotely-administered box should have some kind of
console-level access outside of the OS - like serial console or
iLO/etc support).

Rich

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Samuli Suominen]

On 29/03/13 18:21, Nuno J. Silva (aka njsg) wrote:
> On 2013-03-29, Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:
>> On 29/03/2013 12:34, Chí-Thanh Christopher Nguyễn wrote:
>>> Diego Elio Pettenò schrieb:
>>>>> If my desktop only has one Ethernet interface, no matter how many kernel
>>>>> changes happen, it'll always be eth0.
>>> That was not true with the old persistent naming. One example which we
>>> encountered in #gentoo IRC was the split between e1000 and e1000e drivers
>>> which caused interfaces to change names.
>>
>> Okay let me re-qualify the statement:
>>
>> "If my desktop only has one Ethernet interface, and I don't mess up with
>> it in userspace at all, no matter how many kernel changes happen, it'll
>> always be eth0".
>>
>> Yes, the previous persistent rules for udev would have messed that one
>> up when e1000e got split, or if you switched between the
>> Broadcom-provided driver to the kernel one or vice-versa. The deathforce
>> drivers come in mind as well.
>
> IMHO this is really relevant. It is annoying seeing how many people go
> "oh you *must not* use the old scheme, because it won't work".
>
> The new naming scheme does *not* prevent you from using eth0, users
> should really just be told they can *disable* udev rules (and told how
> to do it) if they are happy with the kernel name of their sole network
> card, instead of being told that they *must* upgrade to the new rules.
>
> The messages so far seem to imply that you can't have eth0. You *can*,
> but udev won't be able to do anything if the device appears as
> something else and there's already another eth0. If you don't already
> have eth0, the udev rules *will* work, even if your card is named in
> the eth namespace.
>
> The *only* thing that breaks is renaming network devices to names that
> are already in use inside the kernel namespaces.

I think you may have not seen the latest version, it says for eg.

"If you only have one interface card, you don't necessarily have much
use for this feature as the name almost always stays at eth0, you can
easily disable it using forementioned methods."

After first listing 3 different ways of disabling the new names earlier.

http://sources.gentoo.org/gitweb/?p=proj/gentoo-news.git;a=blob_plain;f=2013/2013-03-29-udev-upgrade/2013-03-29-udev-upgrade.en.txt;hb=HEAD

But I'd prefer not to lead people to the path of renaming into namespace 
already taken... that can lead to issues. It sounds almost as hackish as 
the script that frees the whole namespace by using temporary names:
https://bugs.gentoo.org/attachment.cgi?id=336774

Still trying to decipher people if there is more to adjust in the news 
though, it doesn't have to be frozen as is, if you have better wording, 
please provide a patch against the current. Thanks :)

- Samuli

[gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Nuno J. Silva (aka njsg)]

On 2013-03-29, Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 29/03/13 18:21, Nuno J. Silva (aka njsg) wrote:
>> On 2013-03-29, Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:
>>> On 29/03/2013 12:34, Chí-Thanh Christopher Nguyễn wrote:
>>>> Diego Elio Pettenò schrieb:
>>>>>> If my desktop only has one Ethernet interface, no matter how many kernel
>>>>>> changes happen, it'll always be eth0.
>>>> That was not true with the old persistent naming. One example which we
>>>> encountered in #gentoo IRC was the split between e1000 and e1000e drivers
>>>> which caused interfaces to change names.
>>>
>>> Okay let me re-qualify the statement:
>>>
>>> "If my desktop only has one Ethernet interface, and I don't mess up with
>>> it in userspace at all, no matter how many kernel changes happen, it'll
>>> always be eth0".
>>>
>>> Yes, the previous persistent rules for udev would have messed that one
>>> up when e1000e got split, or if you switched between the
>>> Broadcom-provided driver to the kernel one or vice-versa. The deathforce
>>> drivers come in mind as well.
>>
>> IMHO this is really relevant. It is annoying seeing how many people go
>> "oh you *must not* use the old scheme, because it won't work".
>>
>> The new naming scheme does *not* prevent you from using eth0, users
>> should really just be told they can *disable* udev rules (and told how
>> to do it) if they are happy with the kernel name of their sole network
>> card, instead of being told that they *must* upgrade to the new rules.
>>
>> The messages so far seem to imply that you can't have eth0. You *can*,
>> but udev won't be able to do anything if the device appears as
>> something else and there's already another eth0. If you don't already
>> have eth0, the udev rules *will* work, even if your card is named in
>> the eth namespace.
>>
>> The *only* thing that breaks is renaming network devices to names that
>> are already in use inside the kernel namespaces.
>
> I think you may have not seen the latest version, it says for eg.
>
> "If you only have one interface card, you don't necessarily have much
> use for this feature as the name almost always stays at eth0, you can
> easily disable it using forementioned methods."

Yeah, I didn't. Checking the new version, it is definitely much better!
Just two notes/questions:

> 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, and the resulting names will vary by kernel
> and hardware configuration, and may vary by kernel version.

IIRC, it can also vary from boot to boot, with the same kernel and
hardware, if there is some kind of race condition.

> Also, the forementioned old 70-persistent-net.rules might interfere with
> the new enabling of the new predictable interface names!

"might"? I never checked, but I thought that, in order to enable the new
naming rules, one had to remove the 70-persistent-net.rules file from
/etc. How does this work, exactly?

> After first listing 3 different ways of disabling the new names earlier.
>
> http://sources.gentoo.org/gitweb/?p=proj/gentoo-news.git;a=blob_plain;f=2013/2013-03-29-udev-upgrade/2013-03-29-udev-upgrade.en.txt;hb=HEAD
>
> But I'd prefer not to lead people to the path of renaming into namespace 
> already taken... that can lead to issues. It sounds almost as hackish as 
> the script that frees the whole namespace by using temporary names:
> https://bugs.gentoo.org/attachment.cgi?id=336774

Can, but only if there is more than one device using that namespace for
their final names. I'm probably biased, because of having had udev
configuration issues and having to hear half of the time "you *can't*
use ethX", just because of the FUD.

I'd say the key is more avoiding leading people to a different system of
rules when they may be fine with the kernel namespace. Perhaps the
approach should be more like:

   If you need persistent naming for some reason (such as two network
   devices in the same kernel namespace), you will need to change your
   rules and use namespaces that are not used by your kernel. This will
   also imply changing all relevant configurations (firewalling, init
   scripts) to refer to the new device names.

   If you do not need to avoid clashes (only one network device or more
   devices on separate namespaces (e.g. eth0 and wlan0)), you can just
   keep the current configuration.

> Still trying to decipher people if there is more to adjust in the news 
> though, it doesn't have to be frozen as is, if you have better wording, 
> please provide a patch against the current. Thanks :)

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I don't have enough time to go through the rest of this thread, but if
the first sentence hasn't been adjusted yet:

On 29/03/13 08:20 AM, Samuli Suominen wrote:
> 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.


Might I recommend at least a little bit of context before going right
into "you have to remove these rules"?  IE - if a user wants to keep
the old mac-based rules they already have, can't they?  80-*.rules
doesn't override that now, does it?

I'd recommend:

"As of version 197, udev now provides predictable interface renaming
based directly on [hardware addresses and whatever other info].  The
old MAC-based relabelling in prior udev versions has been removed, and
it is highly recommended to migrate to the new version."

...as the first paragraph.  Then follow with the rest.  Friendly?



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlFV6WMACgkQ2ugaI38ACPAMAAD/aJC64ISmRlspep2FU3vuBHuB
o+tEueMLIrNnHgNtC7sA/0JIl9H5gbX6talhmPkxKLbMdcaAAWvB4osN1pgWC45H
=XH7f
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Diego Elio Pettenò]

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

On 29/03/2013 20:20, Ian Stakenvicius wrote:
> Might I recommend at least a little bit of context before going right
> into "you have to remove these rules"?  IE - if a user wants to keep
> the old mac-based rules they already have, can't they?  80-*.rules
> doesn't override that now, does it?

It doesn't override it _but_ if you were using the old eth* names, it
will drop support for the in-place renaming (i.e. the ability to swap
eth0 and eth1).

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Walter Dnes]

On Fri, Mar 29, 2013 at 01:38:03PM -0400, Rich Freeman wrote
> On Fri, Mar 29, 2013 at 12:40 PM, Markos Chandras <hwoarang@gentoo.org> wrote:
> > In my mind, the message says "either remove 70-* and setup 80-*" or your
> > system will end up broken.
> 
> The other bit is that modifying symlinks in /etc/init.d is only
> mentioned in passing.  That is a VERY important step unless your new
> name happens to be the same as your old one, otherwise on the next
> boot the system will not have a working network interface, which will
> hamper efforts to fix for casual/new users, and cause real trouble for
> those doing remote administration (though anybody doing anything
> serious on a remotely-administered box should have some kind of
> console-level access outside of the OS - like serial console or
> iLO/etc support).

  That's only the beginning for the necessary changes.  I'm running mdev
on this machine, so it won't affect me, but here goes...

[d531][root][~] grep -rl eth[0-9] /etc/*
/etc/conf.d/net
/etc/conf.d/network
/etc/conf.d/netmount
/etc/dosemu/dosemu.conf
/etc/hibernate/common.conf
/etc/rc.conf

  I've eliminated some specific stuff that only I do.

* /etc/conf.d/net  Is going to have to be modified by users.

* I believe /etc/conf.d/network is a doc file for /etc/conf.d/net.

* /etc/conf.d/netmount  Who changes that?

* /etc/dosemu/dosemu.conf  It's an app, but may require changes.

* /etc/hibernate/common.conf  It's an app, but may require changes.

* /etc/rc.conf  Is going to have to be modified by users.

  "Fun" for users, and app upstreams.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Philip Webb]

130329 Samuli Suominen wrote:
> Attached new version again, more generic than before.

I find this difficult to decipher.  Who is it aimed at ?

I've just updated to Udev 200 .  Following the news item,
I renamed  /etc/udev/rules.d/70-persistent-net.rules :
my script to start my I/net connection with DHCP failed.
I restored the file to its old name & all works as usual :
it has 'NAME="eth0"'.

I am always aware of & grateful for the unpaid efforts of Gentoo devs,
but I'm not pleased with confused or confusing news items.

The first thing any news item should make clear is its audience :
"If you are using ABC or belong to the group describable as DEF,
then you need to do GHI".  Clearly, I don't fall into the group
at whom the Udev news item is aimed, perhaps those with  > 1  net card.
What proportion of Gentoo users fall into that group ?

HTH improve news items.

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Samuli Suominen]

On 31/03/13 04:06, Philip Webb wrote:
> 130329 Samuli Suominen wrote:
>> Attached new version again, more generic than before.
>
> I find this difficult to decipher.  Who is it aimed at ?
>
> I've just updated to Udev 200 .  Following the news item,
> I renamed  /etc/udev/rules.d/70-persistent-net.rules :
> my script to start my I/net connection with DHCP failed.
> I restored the file to its old name & all works as usual :
> it has 'NAME="eth0"'.

Aimed to everyone and it already answers your questions. I can answer 
them differently here again, but if you read the news item, this all is 
there:

If kernel assigns eth0 to first network interface (driver/module) then 
you can't rename to eth0, thus the rule you have is likely superflous
and it doesn't matter if you delete it or not -- you are currently
using "random" kernel names
What it might do is interfere with enabling of the new networking, so 
you should propably symlink /etc/udev/rules.d/80-net-name-slot.rules to 
/dev/null and delete the 70-persistent-net.rules and the behavior of 
your system stays exactly as it's when you are writing this now,
using random kernel names, but if it's an system with only 1 network 
card, it propably doesn't matter much as eth0 gets always used (almost 
always)
Nothing is stopping you from leaving out the symlink either and 
migrating to the new name despite using only 1 network card either,
it's still more reliable than the kernel names

The logic really isn't that hard... It's documented everywhere... :-(

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Diego Elio Pettenò]

On 31/03/2013 03:17, Samuli Suominen wrote:
> it's still more reliable than the kernel names

I still call that bullshit.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Walter Dnes]

On Fri, Mar 29, 2013 at 04:45:50PM +0200, Samuli Suominen wrote

> Those 70-*  and 80-* are in udev pkg_postinst, this news item, 
> everywhere... can all 3 be deleted if you haven't modified them yourself.
> 
> So that leaves one... local.rules... dunno about that. I'm curious.

  One paragraph you should add to the news item is...

=======================================================================

  Users who change interface names will need to search, as root, for
references to eth[0-9] in their config files.  Then they will have to
change the config files to reflect the new names.  At least the
following search is suggested...

grep -rl eth[0-9] /etc /var/lib

Also any custom firewall/routing/network scripts in other locations
should be searched for references to eth[0-9].

=======================================================================

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

[gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Nuno J. Silva (aka njsg)]

On 2013-03-31, Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 31/03/13 04:06, Philip Webb wrote:
>> 130329 Samuli Suominen wrote:
>>> Attached new version again, more generic than before.
>>
>> I find this difficult to decipher.  Who is it aimed at ?
>>
>> I've just updated to Udev 200 .  Following the news item,
>> I renamed  /etc/udev/rules.d/70-persistent-net.rules :
>> my script to start my I/net connection with DHCP failed.
>> I restored the file to its old name & all works as usual :
>> it has 'NAME="eth0"'.
>
> Aimed to everyone and it already answers your questions. I can answer 
> them differently here again, but if you read the news item, this all is 
> there:
>
> If kernel assigns eth0 to first network interface (driver/module) then 
> you can't rename to eth0, thus the rule you have is likely superflous
> and it doesn't matter if you delete it or not -- you are currently
> using "random" kernel names
> What it might do is interfere with enabling of the new networking, so 
> you should propably symlink /etc/udev/rules.d/80-net-name-slot.rules to 
> /dev/null and delete the 70-persistent-net.rules and the behavior of 
> your system stays exactly as it's when you are writing this now,
> using random kernel names, but if it's an system with only 1 network 
> card, it propably doesn't matter much as eth0 gets always used (almost 
> always)

*almost* always?

> Nothing is stopping you from leaving out the symlink either and 
> migrating to the new name despite using only 1 network card either,
> it's still more reliable than the kernel names

I wonder if the OP did change the network devices configuration and init
scripts to handle the network device under the new name, it'd not be
surprising to see everything failing if you *just* change the udev
rules.

> The logic really isn't that hard... It's documented everywhere... :-(

Badly documented. We already had lots of misdocumentation with "you need
an initrd for a separate /usr *starting with* udev-191".


-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

[gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Nuno J. Silva (aka njsg)]

On 2013-03-31, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Fri, Mar 29, 2013 at 04:45:50PM +0200, Samuli Suominen wrote
>
>> Those 70-*  and 80-* are in udev pkg_postinst, this news item, 
>> everywhere... can all 3 be deleted if you haven't modified them yourself.
>> 
>> So that leaves one... local.rules... dunno about that. I'm curious.
>
>   One paragraph you should add to the news item is...
>
>=======================================================================
>
>   Users who change interface names will need to search, as root, for
> references to eth[0-9] in their config files.  Then they will have to

"references to *their network devices* in their config files. [...]"

And maybe provide something like

"If you want a quick way to generate a list of network devices affected
by udev persistency rules, run:

   grep -o 'NAME="[^"]*"' /etc/udev/rules.d/70-persistent-net.rules"

although I don't know for sure how reliable is this in other
systems/shells.


> change the config files to reflect the new names.  At least the
> following search is suggested...
>
> grep -rl eth[0-9] /etc /var/lib
>
> Also any custom firewall/routing/network scripts in other locations
> should be searched for references to eth[0-9].
>
>=======================================================================
>


-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 895 bytes --]

Am Sonntag, 31. März 2013, 03:17:52 schrieb Samuli Suominen:
> Nothing is stopping you from leaving out the symlink either and
> migrating to the new name despite using only 1 network card either,
> it's still more reliable than the kernel names

Why should I?

Kernel behaviour is traditionally way more stable than udev behaviour. If my 
driver for my only one network card has always produced eth0 as device name, 
chances are good it will do so still in a few years, after re-shuffling the 
cards in my casing, and even after exchanging the whole motherboard.

Whereas with udev I can probably expect random things at random times for each 
of these events.

Also, should I have problems with a new kernel, I can always just boot back 
into an old one without much ado.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Philip Webb]

130331 Samuli Suominen offered prompt + polite help re Udev 200 :

Thanks.  In fact, it's a bit more complex than I thought yesterday.
After moving the '70 80' files into a subdirectory & restarting, I get :

  root:501 ~> dhcpcd
    dhcpcd[830]: version 5.6.4 starting
    ... [nothing happens for  10 s ]
    ^C
    ... [long delay till machine responds]
    dhcpcd[830]: no interfaces have a carrier
    dhcpcd[830]: forked to background, child pid 857
  root:502 ~> dhcpcd
    dhcpcd[864]: version 5.6.4 starting
    dhcpcd[864]: enp5s0: sending IPv6 Router Solicitation
    dhcpcd[864]: enp5s0: rebinding lease of 192.168.1.2
    dhcpcd[864]: enp5s0: NAK: from 192.168.1.1
    dhcpcd[864]: enp5s0: sending IPv6 Router Solicitation
    dhcpcd[864]: enp5s0: broadcasting for a lease
    dhcpcd[864]: enp5s0: offered 192.168.1.2 from 192.168.1.1
    dhcpcd[864]: enp5s0: acknowledged 192.168.1.2 from 192.168.1.1
    dhcpcd[864]: enp5s0: checking for 192.168.1.2
    dhcpcd[864]: enp5s0: sending IPv6 Router Solicitation
    dhcpcd[864]: enp5s0: leased 192.168.1.2 for 86400 seconds
    dhcpcd[864]: forked to background, child pid 888
 
The same happens if I try 'dhcpcd enp5s0',
except that the 1st reply is "enp5s0 : removing interface".
The name 'enp5s0' has shown up after  > 1  restart,
so that seems to be what my kernel (gentoo-sources 3.5.3) calls it.

So I've done what I understand to be recommended,
but have to go thro' a stutter before I can get the I/net working.

I really don't want to have to spend an hour or more
reading docs which are largely irrelevant to my very simple case,
ie  1  network card accessing an ordinary ISP.

Further advice is very welcome & I hope I'm helping clarify things
for others trying who try to follow the news item
& also helping the developer improve his docs.

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt : SOLVED

[Philip Webb]

I have sent a msg to gentoo-user describing how to solve this problem.
Perhaps it needs to be mentioned in the news item or wiki entry.

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt : SOLVED

[Markos Chandras]

On 1 April 2013 02:56, Philip Webb <purslow@ca.inter.net> wrote:
> I have sent a msg to gentoo-user describing how to solve this problem.
> Perhaps it needs to be mentioned in the news item or wiki entry.
>
> --
> ========================,,============================================
> SUPPORT     ___________//___,   Philip Webb
> ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
> TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca
>
>

So you broke the threading on the original email, you deleted all the
previous content,
you did not write an appropriate title for your e-mail and then you
claim you solved a problem without
mentioning what the problem was.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt : SOLVED

[Philip Webb]

130401 Markos Chandras wrote:
> On 1 April 2013 02:56, Philip Webb <purslow@ca.inter.net> wrote:
>> I have sent a msg to gentoo-user describing how to solve this problem.
>> Perhaps it needs to be mentioned in the news item or wiki entry.
> So you broke the threading on the original email,
> you deleted all the previous content,
> you did not write an appropriate title for your e-mail
> and then you claim you solved a problem
> without mentioning what the problem was.

Your response is completely out of place & very impolite.
I am trying to help improve Gentoo documentation
& help other users who may face the same problem,
but without taking unnecessary space on the dev-list.
I am not happy with the way the Udev-200 update has been documented,
but I haven't criticised the developer responsible.

Please take the trouble to read what I sent to the user-list :

  Date: Sun, 31 Mar 2013 21:54:08 -0400
  From: Philip Webb <purslow@ca.inter.net>
  To: Gentoo User <gentoo-user@lists.gentoo.org>
  Subject: [gentoo-user] Udev 200 : dhcpcd problem + solution
  Message-ID: <20130401015408.GA912@ca.inter.net>

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt : SOLVED

[Markos Chandras]

On 1 April 2013 16:32, Philip Webb <purslow@ca.inter.net> wrote:
> 130401 Markos Chandras wrote:
>> On 1 April 2013 02:56, Philip Webb <purslow@ca.inter.net> wrote:
>>> I have sent a msg to gentoo-user describing how to solve this problem.
>>> Perhaps it needs to be mentioned in the news item or wiki entry.
>> So you broke the threading on the original email,
>> you deleted all the previous content,
>> you did not write an appropriate title for your e-mail
>> and then you claim you solved a problem
>> without mentioning what the problem was.
>
> Your response is completely out of place & very impolite.
> I am trying to help improve Gentoo documentation
> & help other users who may face the same problem,
> but without taking unnecessary space on the dev-list.
> I am not happy with the way the Udev-200 update has been documented,
> but I haven't criticised the developer responsible.
>
> Please take the trouble to read what I sent to the user-list :
>

Oh but of course. This was more than obvious. Posting something to
gentoo-dev just to
inform us that you posted something to gentoo-user without even
mentioning the title.
And then you claim that my reply is out of place. Ok

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt : SOLVED

[Michael Mol]

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

On 04/01/2013 01:06 PM, Markos Chandras wrote:
> On 1 April 2013 16:32, Philip Webb <purslow@ca.inter.net> wrote:
>> 130401 Markos Chandras wrote:
>>> On 1 April 2013 02:56, Philip Webb <purslow@ca.inter.net> wrote:
>>>> I have sent a msg to gentoo-user describing how to solve this problem.
>>>> Perhaps it needs to be mentioned in the news item or wiki entry.
>>> So you broke the threading on the original email,
>>> you deleted all the previous content,
>>> you did not write an appropriate title for your e-mail
>>> and then you claim you solved a problem
>>> without mentioning what the problem was.
>>
>> Your response is completely out of place & very impolite.
>> I am trying to help improve Gentoo documentation
>> & help other users who may face the same problem,
>> but without taking unnecessary space on the dev-list.
>> I am not happy with the way the Udev-200 update has been documented,
>> but I haven't criticised the developer responsible.
>>
>> Please take the trouble to read what I sent to the user-list :
>>
> 
> Oh but of course. This was more than obvious. Posting something to
> gentoo-dev just to
> inform us that you posted something to gentoo-user without even
> mentioning the title.
> And then you claim that my reply is out of place. Ok

Is this a good time to point out that list archival is still broken? And
has been for almost a year?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt : SOLVED

[Markos Chandras]

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

On Apr 1, 2013 8:53 PM, "Michael Mol" <mikemol@gmail.com> wrote:
>
> On 04/01/2013 01:06 PM, Markos Chandras wrote:
> > On 1 April 2013 16:32, Philip Webb <purslow@ca.inter.net> wrote:
> >> 130401 Markos Chandras wrote:
> >>> On 1 April 2013 02:56, Philip Webb <purslow@ca.inter.net> wrote:
> >>>> I have sent a msg to gentoo-user describing how to solve this
problem.
> >>>> Perhaps it needs to be mentioned in the news item or wiki entry.
> >>> So you broke the threading on the original email,
> >>> you deleted all the previous content,
> >>> you did not write an appropriate title for your e-mail
> >>> and then you claim you solved a problem
> >>> without mentioning what the problem was.
> >>
> >> Your response is completely out of place & very impolite.
> >> I am trying to help improve Gentoo documentation
> >> & help other users who may face the same problem,
> >> but without taking unnecessary space on the dev-list.
> >> I am not happy with the way the Udev-200 update has been documented,
> >> but I haven't criticised the developer responsible.
> >>
> >> Please take the trouble to read what I sent to the user-list :
> >>
> >
> > Oh but of course. This was more than obvious. Posting something to
> > gentoo-dev just to
> > inform us that you posted something to gentoo-user without even
> > mentioning the title.
> > And then you claim that my reply is out of place. Ok
>
> Is this a good time to point out that list archival is still broken? And
> has been for almost a year?
>
I don't see how this is relevant to this discussion. We are aware of that.
The bug is still open

[-- Attachment #2: Type: text/html, Size: 2167 bytes --]