Re: Unexpected NIC naming f23 firewall implications

[Richard W.M. Jones]

On Tue, Nov 10, 2015 at 02:21:13PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Nov 10, 2015 at 07:06:51AM +0100, Tomasz Torcz wrote:
> > On Mon, Nov 09, 2015 at 08:50:55PM +, Richard W.M. Jones wrote:
> > > > em* and p?p? come from biosdevname, which should not be used and is 
> > > > deprecated.
> > > 
> > > I'm merely observing what happened when I updated a bunch of servers
> > > from F22 to F23.  I didn't intentionally install nor uninstall biosdevname
> > > at any point.
> And this is the crux of the problem: for some reason biosdevname
> stopped working for you. This was not intentional and should not
> happen. Is biosdevname it still installed?

Yes: biosdevname-0.6.2-1.fc23.x86_64

> Can you file a bug
> against systemd and attach output of 'sudo udevadm test /sys/class/net/eno1'
> (or whatever the name the device has in the end)?

TBH I've fixed the machines and I don't particularly want to pursue
this bug.  However I have attached the output of:

sudo udevadm test /sys/class/net/enp3s0

to this email, in case anyone else wants to take this up.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
calling: test
version 222
=== trie on-disk ===
tool version:  222
file size: 6829562 bytes
header size 80 bytes
strings1750682 bytes
nodes  5078800 bytes
Load module index
timestamp of '/usr/lib/systemd/network' changed
Parsed configuration file /usr/lib/systemd/network/99-default.link
Created link configuration context.
timestamp of '/etc/udev/rules.d' changed
timestamp of '/usr/lib/udev/rules.d' changed
Reading rules file: /usr/lib/udev/rules.d/10-dm.rules
Reading rules file: /usr/lib/udev/rules.d/11-dm-lvm.rules
Reading rules file: /usr/lib/udev/rules.d/13-dm-disk.rules
Reading rules file: /usr/lib/udev/rules.d/50-rbd.rules
Reading rules file: /usr/lib/udev/rules.d/50-udev-default.rules
Reading rules file: /usr/lib/udev/rules.d/60-block.rules
Reading rules file: /usr/lib/udev/rules.d/60-cdrom_id.rules
Reading rules file: /usr/lib/udev/rules.d/60-ceph-partuuid-workaround.rules
Reading rules file: /usr/lib/udev/rules.d/60-drm.rules
Reading rules file: /usr/lib/udev/rules.d/60-evdev.rules
Reading rules file: /usr/lib/udev/rules.d/60-net.rules
Reading rules file: /usr/lib/udev/rules.d/60-persistent-alsa.rules
Reading rules file: /usr/lib/udev/rules.d/60-persistent-input.rules
Reading rules file: /usr/lib/udev/rules.d/60-persistent-storage-tape.rules
Reading rules file: /usr/lib/udev/rules.d/60-persistent-storage.rules
Reading rules file: /usr/lib/udev/rules.d/60-persistent-v4l.rules
Reading rules file: /usr/lib/udev/rules.d/60-raw.rules
Reading rules file: /usr/lib/udev/rules.d/60-serial.rules
Reading rules file: /usr/lib/udev/rules.d/63-md-raid-arrays.rules
Reading rules file: /usr/lib/udev/rules.d/64-btrfs.rules
Reading rules file: /usr/lib/udev/rules.d/64-md-raid-assembly.rules
Reading rules file: /usr/lib/udev/rules.d/65-md-incremental.rules
Reading rules file: /usr/lib/udev/rules.d/69-bcache.rules
Reading rules file: /usr/lib/udev/rules.d/69-dm-lvm-metad.rules
Reading rules file: /usr/lib/udev/rules.d/70-mouse.rules
Reading rules file: /usr/lib/udev/rules.d/70-power-switch.rules
Reading rules file: /usr/lib/udev/rules.d/70-uaccess.rules
Reading rules file: /usr/lib/udev/rules.d/70-yubikey.rules
Reading rules file: /usr/lib/udev/rules.d/71-biosdevname.rules
Reading rules file: /usr/lib/udev/rules.d/71-seat.rules
Reading rules file: /usr/lib/udev/rules.d/73-seat-late.rules
Reading rules file: /usr/lib/udev/rules.d/75-net-description.rules
Reading rules file: /usr/lib/udev/rules.d/75-probe_mtd.rules
Reading rules file: /usr/lib/udev/rules.d/77-mm-cinterion-port-types.rules
Reading rules file: /usr/lib/udev/rules.d/77-mm-ericsson-mbm.rules
Reading rules file: /usr/lib/udev/rules.d/77-mm-huawei-net-port-types.rules
Reading rules file: /usr/lib/udev/rules.d/77-mm-longcheer-port-types.rules
Reading rules file: /usr/lib/udev/rules.d/77-mm-mtk-port-types.rules
Reading rules file: /usr/lib/udev/rules.d/77-mm-nokia-port-types.rules
Reading rules file: /usr/lib/udev/rules.d/77-mm-pcmcia-device-blacklist.rules
Reading rules file: /usr/lib/udev/rules.d/77-mm-platform-serial-whitelist.rules
Reading rules file: /usr/lib/udev/rules.d/77-mm-simtech-port-types.rules
Reading rules file: /usr/lib/udev/rules.d/77-mm-telit-port-types.rules
Reading rules file: /usr/lib/udev/rules.d/77-mm-usb-device-blacklist.rules
Reading rules file: 
/usr/lib/udev/rules.d/77-mm-usb-serial-adapters-greylist.rules
Reading rules file: /usr/lib/udev/rules.d/77-mm-x22x-port-types.rules
Reading rules file: /usr/lib/udev/rules.d/77-mm-zte-port-types.rules
Reading rules file: /usr/lib/udev/rules.d/78-sound-card.rules
Reading rules file: 

Re: Unexpected NIC naming f23 firewall implications

[Reindl Harald]

Am 11.11.2015 um 16:23 schrieb Björn Persson:

I tend to not listen much to people who tell me to do stuff without
stating any reasons. If you want me to change, and you're not in a
position to give me orders, then you need to explain why the thing I'm
doing is bad.


For MAC based name assignment you can use the ifcfg-*
files with HWADDR="".


Are you saying that HWADDR is a selection? It's described in
/usr/share/doc/initscripts/sysconfig.txt as "ethernet hardware address
for this device". That sounds like an assignment to me, assigning a new
MAC address to the interface. If it would say "of" instead of "for",
then I would understand it as a selection. I'll admit though, that
if HWADDR is a selection, then it's easier to understand why both HWADDR
and MACADDR exist


"HWADDR=" is the phyiscal address
"MACADDR=" is for changing it, known as "clone MAC" on routers

DEVICE=wan
HWADDR=24:be:05:1a:c0:27

[root@srv-rhsoft:~]$ ifconfig wan
wan: flags=67  mtu 1500
ether 24:be:05:1a:c0:27  txqueuelen 100  (Ethernet)
RX packets 3521821  bytes 1182354436 (1.1 GiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 2904184  bytes 3006634333 (2.8 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 20  memory 0xf7c0-f7c2




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Björn Persson]

Harald Hoyer  wrote:
> Am 08.11.2015 um 17:14 schrieb Björn Persson:
> > Christopher  wrote:
> >> I recently updated my desktop to f23, and it went smoothly, for the most
> >> part. However, it broke my mediatomb server because the NIC changed from
> >> em1 to eno1.
> > 
> > On any computer where it matters which network interface is connected
> > to which network, I recommend writing some Udev rules to set permanent
> > interface names based on the MAC address.
> > 
> > Write a file named /etc/udev/rules.d/01-network-interface-naming.rules 
> > with content similar to this:
> > 
> > SUBSYSTEM=="net", ATTR{address}=="00:0c:46:16:dc:b0", NAME:="world"
> > SUBSYSTEM=="net", ATTR{address}=="00:1e:8c:cf:dc:e5", NAME:="gigabit"
> > SUBSYSTEM=="net", ATTR{address}=="fc:f8:ae:ea:08:85", NAME:="wifi"
> > 
> > "01" in the filename causes it to be loaded before other files with
> > higher numbers. Assignment with ":=" prevents later rules from
> > clobbering the names. I found that capital letters don't work in the
> > hexadecimal MAC addresses, so write them with small letters.
> > 
> > We shouldn't have to do this manually, and it definitely shouldn't be
> > as difficult as it was to find out how to do it, but on the upside you
> > get meaningful names so that you won't have any trouble remembering
> > which interface is which.
> > 
> > (I hope no one turns Udev inside out anytime soon.)
> 
> Please don't do this.

I tend to not listen much to people who tell me to do stuff without
stating any reasons. If you want me to change, and you're not in a
position to give me orders, then you need to explain why the thing I'm
doing is bad.

> For MAC based name assignment you can use the ifcfg-*
> files with HWADDR="".

Are you saying that HWADDR is a selection? It's described in
/usr/share/doc/initscripts/sysconfig.txt as "ethernet hardware address
for this device". That sounds like an assignment to me, assigning a new
MAC address to the interface. If it would say "of" instead of "for",
then I would understand it as a selection. I'll admit though, that
if HWADDR is a selection, then it's easier to understand why both HWADDR
and MACADDR exist.

Then I would need a way to use the ifcfg file to assign a name to the
interface. I can find two candidates: DEVICE, and the interface name
that is part of the filename. DEVICE is described as "name of physical
device". Using "of", that sounds like a selection: "Apply the settings
in this file to the interface that has this name." As for the filename,
I've always assumed that that was either a selection or just a name
without any special meaning. Using the filename to assign a name to an
interface would seem really weird. Also, I don't see any explanation of
how DEVICE and the filename interact.

Furthermore, my backups show that the ifcfg files I had when I upgraded
from Fedora 15 to 17 did contain both HWADDR and DEVICE, and that didn't
prevent the interface names from changing unpredictably on every reboot.
Apparently there was a race between two or more components that each
tried to set its own interface names. I pieced together those Udev rules
based on hints I found on various blogs, and my interface names have
been stable ever since.

Considering all of the above, I'm not at all convinced that your method
works.

Björn Persson


pgpFswbEsHgn7.pgp
Description: OpenPGP digital signatur
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Christopher]

On Tue, Nov 10, 2015 at 9:21 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Nov 10, 2015 at 07:06:51AM +0100, Tomasz Torcz wrote:
> > On Mon, Nov 09, 2015 at 08:50:55PM +, Richard W.M. Jones wrote:
> > > > em* and p?p? come from biosdevname, which should not be used and is
> deprecated.
> > >
> > > I'm merely observing what happened when I updated a bunch of servers
> > > from F22 to F23.  I didn't intentionally install nor uninstall
> biosdevname
> > > at any point.
> And this is the crux of the problem: for some reason biosdevname
> stopped working for you. This was not intentional and should not
> happen. Is biosdevname it still installed? Can you file a bug
> against systemd and attach output of 'sudo udevadm test
> /sys/class/net/eno1'
> (or whatever the name the device has in the end)?
>
> > But you should have.  Biosdevname what deprecated 3 years ago (with
> Fedora 19
> > or 20*), you should have migrated your rules to udev's naming scheme and
> > remove biosdevname.
> That's true, but not really relevant. We neither removed biosdevname nor
> announced that is not supported anymore, and if it suddenly stopped working
> we need to figure out why.
>
>
Well, I still have biosdevname-0.6.2-1.fc23.x86_64 installed on the desktop
machine I mentioned was upgraded in the original post, where the NIC was
changed from em1 to eno1 on the upgrade.

https://bugzilla.redhat.com/show_bug.cgi?id=1280037
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Jóhann B . Guðmundsson]

On 11/10/2015 06:06 AM, Tomasz Torcz wrote:

On Mon, Nov 09, 2015 at 08:50:55PM +, Richard W.M. Jones wrote:

em* and p?p? come from biosdevname, which should not be used and is deprecated.

I'm merely observing what happened when I updated a bunch of servers
from F22 to F23.  I didn't intentionally install nor uninstall biosdevname
at any point.

   But you should have.  Biosdevname what deprecated 3 years ago (with Fedora 19
or 20*), you should have migrated your rules to udev's naming scheme and
remove biosdevname.  This was quite long transition period, even longer
than biosdevname usage, which was default between Fedora 15 and 19 (2 years).

   * although I can't find the mention in Release Notes for neither F19 nor F20.
 We may have underdelivered on this :(



Biosdevname has not "officially" been deprecated ( still mentioned in 
the guidelines and still available for download ) and it only got 
removed from comps and Anaconda in F21 ( which is something that should 
have happened in F19 ) and up to that point it was still installed by 
default so machine upgrades from  F21 - F22 -  F23 will still 
have it, clean installs of F21+ should however not ( unverified ).


The WG's or any of the live CD's might still be deliberately shipping it 
( like the serverWG might think it was a good idea to ship it like they 
are still shipping rsyslog etc ) .


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Zbigniew Jędrzejewski-Szmek]

On Tue, Nov 10, 2015 at 07:06:51AM +0100, Tomasz Torcz wrote:
> On Mon, Nov 09, 2015 at 08:50:55PM +, Richard W.M. Jones wrote:
> > > em* and p?p? come from biosdevname, which should not be used and is 
> > > deprecated.
> > 
> > I'm merely observing what happened when I updated a bunch of servers
> > from F22 to F23.  I didn't intentionally install nor uninstall biosdevname
> > at any point.
And this is the crux of the problem: for some reason biosdevname
stopped working for you. This was not intentional and should not
happen. Is biosdevname it still installed? Can you file a bug
against systemd and attach output of 'sudo udevadm test /sys/class/net/eno1'
(or whatever the name the device has in the end)?

> But you should have.  Biosdevname what deprecated 3 years ago (with Fedora 19
> or 20*), you should have migrated your rules to udev's naming scheme and
> remove biosdevname. 
That's true, but not really relevant. We neither removed biosdevname nor
announced that is not supported anymore, and if it suddenly stopped working
we need to figure out why.

Zbyszek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Kevin Kofler]

Richard W.M. Jones wrote:
> Their NICs changed from p6p1 -> enp3s0.  It was annoying because I had
> to boot each one with a display and keyboard and change the network
> configuration by hand.
> 
> "predictable, stable network interface names"
> https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/

Oh the irony!

Unpredictable, unstable network interface names. (I presume they previously
changed from eth0 to p6p1, so that's already the SECOND breakage.) Hooray
for this "feature"!

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Tomasz Torcz]

On Mon, Nov 09, 2015 at 08:50:55PM +, Richard W.M. Jones wrote:
> > em* and p?p? come from biosdevname, which should not be used and is 
> > deprecated.
> 
> I'm merely observing what happened when I updated a bunch of servers
> from F22 to F23.  I didn't intentionally install nor uninstall biosdevname
> at any point.

  But you should have.  Biosdevname what deprecated 3 years ago (with Fedora 19
or 20*), you should have migrated your rules to udev's naming scheme and
remove biosdevname.  This was quite long transition period, even longer 
than biosdevname usage, which was default between Fedora 15 and 19 (2 years).

  * although I can't find the mention in Release Notes for neither F19 nor F20.
We may have underdelivered on this :(

-- 
Tomasz TorczThere exists no separation between gods and men:
xmpp: zdzich...@chrome.pl   one blends softly casual into the other.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Harald Hoyer]

Am 08.11.2015 um 20:29 schrieb Richard W.M. Jones:
> On Sat, Nov 07, 2015 at 05:28:54PM +, Christopher wrote:
>> I recently updated my desktop to f23, and it went smoothly, for the most
>> part. However, it broke my mediatomb server because the NIC changed from
>> em1 to eno1.
>>
>> Is this something that was expected? It certainly surprised me.
> 
> It happened to a bunch of servers when I updated them from F22 to F23.
> Their NICs changed from p6p1 -> enp3s0.  It was annoying because I had
> to boot each one with a display and keyboard and change the network
> configuration by hand.
> 
> "predictable, stable network interface names"
> https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/
> 
> Rich.
> 

em* and p?p? come from biosdevname, which should not be used and is deprecated.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Dan Williams]

On Sun, 2015-11-08 at 20:36 +0100, Reindl Harald wrote:
> 
> Am 08.11.2015 um 20:29 schrieb Richard W.M. Jones:
> > On Sat, Nov 07, 2015 at 05:28:54PM +, Christopher wrote:
> >> I recently updated my desktop to f23, and it went smoothly, for the most
> >> part. However, it broke my mediatomb server because the NIC changed from
> >> em1 to eno1.
> >>
> >> Is this something that was expected? It certainly surprised me.
> >
> > It happened to a bunch of servers when I updated them from F22 to F23.
> > Their NICs changed from p6p1 -> enp3s0.  It was annoying because I had
> > to boot each one with a display and keyboard and change the network
> > configuration by hand.
> >
> > "predictable, stable network interface names"
> > https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/
> 
> that is simple to solve forever
> 
> * add "net.ifnames=0 biosdevname=0" to your kernel params
> * get rid of NetworkManager

FYI, NetworkManager has nothing to do with device naming at all.  So
disabling NM will do nothing to solve your problems with device names.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Jóhann B . Guðmundsson]

On 11/08/2015 07:29 PM, Richard W.M. Jones wrote:

On Sat, Nov 07, 2015 at 05:28:54PM +, Christopher wrote:

I recently updated my desktop to f23, and it went smoothly, for the most
part. However, it broke my mediatomb server because the NIC changed from
em1 to eno1.

Is this something that was expected? It certainly surprised me.

It happened to a bunch of servers when I updated them from F22 to F23.
Their NICs changed from p6p1 -> enp3s0.  It was annoying because I had
to boot each one with a display and keyboard and change the network
configuration by hand.

"predictable, stable network interface names"
https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/


The p6p1 and em1 interface names come from ( Dells ) biosdevname not 
systemd and most likely the biosdevname component got removed on upgrade 
or superseded by other udev rules.


Arguably biosdevname component should have been obsoleted in F19 as a 
component and in Anaconda and Dracut when predictable network interface 
names got introduced with systemd in the distribution, to prevent these 
kind of surprises but here we are so "surprise" ...


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Harald Hoyer]

Am 08.11.2015 um 17:14 schrieb Björn Persson:
> Christopher  wrote:
>> I recently updated my desktop to f23, and it went smoothly, for the most
>> part. However, it broke my mediatomb server because the NIC changed from
>> em1 to eno1.
> 
> On any computer where it matters which network interface is connected
> to which network, I recommend writing some Udev rules to set permanent
> interface names based on the MAC address.
> 
> Write a file named /etc/udev/rules.d/01-network-interface-naming.rules 
> with content similar to this:
> 
> SUBSYSTEM=="net", ATTR{address}=="00:0c:46:16:dc:b0", NAME:="world"
> SUBSYSTEM=="net", ATTR{address}=="00:1e:8c:cf:dc:e5", NAME:="gigabit"
> SUBSYSTEM=="net", ATTR{address}=="fc:f8:ae:ea:08:85", NAME:="wifi"
> 
> "01" in the filename causes it to be loaded before other files with
> higher numbers. Assignment with ":=" prevents later rules from
> clobbering the names. I found that capital letters don't work in the
> hexadecimal MAC addresses, so write them with small letters.
> 
> We shouldn't have to do this manually, and it definitely shouldn't be
> as difficult as it was to find out how to do it, but on the upside you
> get meaningful names so that you won't have any trouble remembering
> which interface is which.
> 
> (I hope no one turns Udev inside out anytime soon.)
> 
> Björn Persson
> 
> 
> 

Please don't do this. For MAC based name assignment you can use the ifcfg-*
files with HWADDR="".


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Richard W.M. Jones]

On Mon, Nov 09, 2015 at 04:55:40PM +0100, Harald Hoyer wrote:
> Am 08.11.2015 um 20:29 schrieb Richard W.M. Jones:
> > On Sat, Nov 07, 2015 at 05:28:54PM +, Christopher wrote:
> >> I recently updated my desktop to f23, and it went smoothly, for the most
> >> part. However, it broke my mediatomb server because the NIC changed from
> >> em1 to eno1.
> >>
> >> Is this something that was expected? It certainly surprised me.
> > 
> > It happened to a bunch of servers when I updated them from F22 to F23.
> > Their NICs changed from p6p1 -> enp3s0.  It was annoying because I had
> > to boot each one with a display and keyboard and change the network
> > configuration by hand.
> > 
> > "predictable, stable network interface names"
> > https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/
> > 
> > Rich.
> > 
> 
> em* and p?p? come from biosdevname, which should not be used and is 
> deprecated.

I'm merely observing what happened when I updated a bunch of servers
from F22 to F23.  I didn't intentionally install nor uninstall biosdevname
at any point.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Björn Persson]

Christopher  wrote:
> I recently updated my desktop to f23, and it went smoothly, for the most
> part. However, it broke my mediatomb server because the NIC changed from
> em1 to eno1.

On any computer where it matters which network interface is connected
to which network, I recommend writing some Udev rules to set permanent
interface names based on the MAC address.

Write a file named /etc/udev/rules.d/01-network-interface-naming.rules 
with content similar to this:

SUBSYSTEM=="net", ATTR{address}=="00:0c:46:16:dc:b0", NAME:="world"
SUBSYSTEM=="net", ATTR{address}=="00:1e:8c:cf:dc:e5", NAME:="gigabit"
SUBSYSTEM=="net", ATTR{address}=="fc:f8:ae:ea:08:85", NAME:="wifi"

"01" in the filename causes it to be loaded before other files with
higher numbers. Assignment with ":=" prevents later rules from
clobbering the names. I found that capital letters don't work in the
hexadecimal MAC addresses, so write them with small letters.

We shouldn't have to do this manually, and it definitely shouldn't be
as difficult as it was to find out how to do it, but on the upside you
get meaningful names so that you won't have any trouble remembering
which interface is which.

(I hope no one turns Udev inside out anytime soon.)

Björn Persson


pgpgMhd_r3Uqq.pgp
Description: OpenPGP digital signatur
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Richard W.M. Jones]

On Sat, Nov 07, 2015 at 05:28:54PM +, Christopher wrote:
> I recently updated my desktop to f23, and it went smoothly, for the most
> part. However, it broke my mediatomb server because the NIC changed from
> em1 to eno1.
> 
> Is this something that was expected? It certainly surprised me.

It happened to a bunch of servers when I updated them from F22 to F23.
Their NICs changed from p6p1 -> enp3s0.  It was annoying because I had
to boot each one with a display and keyboard and change the network
configuration by hand.

"predictable, stable network interface names"
https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Reindl Harald]

Am 08.11.2015 um 21:25 schrieb Christopher:

On Sun, Nov 8, 2015, 14:29 Richard W.M. Jones  enp3s0.  It was annoying because I had
to boot each one with a display and keyboard and change the network
configuration by hand.

"predictable, stable network interface names"
https

://

wiki.freedesktop.org

/www/Software/

systemd

/

PredictableNetworkInterfaceNames

/



Rich.

It's a good policy and a good idea, but I thought it had already
been done with the em1 naming. I guess i misunderstood when it'd be
implemented.


there is nothing good in changing network interface naming every few 
years and there where even reports that after updates even the 
systemd-implementation changed it again (not only the switch form 
biosdevname to systemd)


doing that on systems with just one ethernet interface (the majority) 
every few years is nothing else than asking for troubles


a skilled sysadmin can solve all that problems at his own, a non-skilled 
has repeatly problems to solve which did not exist in the past where 
eth0 was normal




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Reindl Harald]

Am 08.11.2015 um 20:42 schrieb Richard W.M. Jones:

On Sun, Nov 08, 2015 at 08:36:57PM +0100, Reindl Harald wrote:



Am 08.11.2015 um 20:29 schrieb Richard W.M. Jones:

On Sat, Nov 07, 2015 at 05:28:54PM +, Christopher wrote:

I recently updated my desktop to f23, and it went smoothly, for the most
part. However, it broke my mediatomb server because the NIC changed from
em1 to eno1.

Is this something that was expected? It certainly surprised me.


It happened to a bunch of servers when I updated them from F22 to F23.
Their NICs changed from p6p1 -> enp3s0.  It was annoying because I had
to boot each one with a display and keyboard and change the network
configuration by hand.

"predictable, stable network interface names"
https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/


that is simple to solve forever

* add "net.ifnames=0 biosdevname=0" to your kernel params
* get rid of NetworkManager
* rename your ethernet-devices in the ifcfg-files based on the MAC
* survives yum-upgardes from Fedora 9 to Fedora 23
* nobody needs NM and that other stuff on static configured servers
* frankly even with a DHCP wan-interface it works perfectly


I agree, except it's not "simple" :-)


define simple

it's in any way simpler then find out after a update that you can no 
longer reaach your machine because all that "predictable" crap changed 
multiple times in the past with no gain for 99% of all setups (most have 
only one NIC and for them eth0 was as predictable as something can be)



Maybe giving permanent names to network interfaces (of our own choice
or from a standard set) is something we should be able to choose at
installation time?


yes that would make things way easier because when you have 5 
network-interfaces and a plan what they are supposed to do you could 
start naming them and later just try out "who is who" by plugin a cable 
(they easy way with physical access while and after setup)


the same way when you see the MAC-address you giving the name you can 
plugin your cables before setup, depending on the hardware there may be 
some label which port has which MAC, however - the only "persistent" 
thing of a network-interface it's his MAC address


IMPORTANT: it *must* be clear where this paring is configured in case 
you need to replace a NIC and adtop the configuration





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Björn Persson]

Reindl Harald  wrote:
> a skilled sysadmin can solve all that problems at his own, a non-skilled 
> has repeatly problems to solve which did not exist in the past where 
> eth0 was normal

I guess you were lucky in the past. My experience was that interface
names were unstable in the "eth0" days. After an upgrade eth0 and eth1
could suddenly swap names with each other, and adding or removing a
network card could trigger a renaming of other network cards that had
not been touched. Network interface names have always been unreliable,
and apparently they're still unreliable, unless you have configured
your own names and ensured that your configuration overrides anything
else that tries to rename interfaces.

Björn Persson


pgp8A3EEsZJ74.pgp
Description: OpenPGP digital signatur
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Richard W.M. Jones]

On Sun, Nov 08, 2015 at 08:36:57PM +0100, Reindl Harald wrote:
> 
> 
> Am 08.11.2015 um 20:29 schrieb Richard W.M. Jones:
> >On Sat, Nov 07, 2015 at 05:28:54PM +, Christopher wrote:
> >>I recently updated my desktop to f23, and it went smoothly, for the most
> >>part. However, it broke my mediatomb server because the NIC changed from
> >>em1 to eno1.
> >>
> >>Is this something that was expected? It certainly surprised me.
> >
> >It happened to a bunch of servers when I updated them from F22 to F23.
> >Their NICs changed from p6p1 -> enp3s0.  It was annoying because I had
> >to boot each one with a display and keyboard and change the network
> >configuration by hand.
> >
> >"predictable, stable network interface names"
> >https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/
> 
> that is simple to solve forever
> 
> * add "net.ifnames=0 biosdevname=0" to your kernel params
> * get rid of NetworkManager
> * rename your ethernet-devices in the ifcfg-files based on the MAC
> * survives yum-upgardes from Fedora 9 to Fedora 23
> * nobody needs NM and that other stuff on static configured servers
> * frankly even with a DHCP wan-interface it works perfectly

I agree, except it's not "simple" :-)

Maybe giving permanent names to network interfaces (of our own choice
or from a standard set) is something we should be able to choose at
installation time?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Christopher]

On Sun, Nov 8, 2015, 14:29 Richard W.M. Jones  wrote:

On Sat, Nov 07, 2015 at 05:28:54PM +, Christopher wrote:
> I recently updated my desktop to f23, and it went smoothly, for the most
> part. However, it broke my mediatomb server because the NIC changed from
> em1 to eno1.
>
> Is this something that was expected? It certainly surprised me.

It happened to a bunch of servers when I updated them from F22 to F23.
Their NICs changed from p6p1 -> enp3s0.  It was annoying because I had
to boot each one with a display and keyboard and change the network
configuration by hand.

"predictable, stable network interface names"
https

://

wiki.freedesktop.org

/www/Software/

systemd

/

PredictableNetworkInterfaceNames

/


Rich.

It's a good policy and a good idea, but I thought it had already been done
with the em1 naming. I guess i misunderstood when it'd be implemented.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[nicolas . mailhot]

> Maybe giving permanent names to network interfaces (of our own choice
> or from a standard set) is something we should be able to choose at
> installation time?

Actually, what people want is to forbid any renaming during updates, because 
that breaks all kinds of stuff. The system should keep the install-time naming 
or whatever the admin (not the system) changed it to later

(Guess I know now why I have a headless system to rescue)

-- 
Nicolas Mailhot
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Reindl Harald]

Am 08.11.2015 um 22:59 schrieb Björn Persson:

Reindl Harald  wrote:

a skilled sysadmin can solve all that problems at his own, a non-skilled
has repeatly problems to solve which did not exist in the past where
eth0 was normal


I guess you were lucky in the past. My experience was that interface
names were unstable in the "eth0" days. After an upgrade eth0 and eth1
could suddenly swap names with each other, and adding or removing a
network card could trigger a renaming of other network cards that had
not been touched. Network interface names have always been unreliable,
and apparently they're still unreliable, unless you have configured
your own names and ensured that your configuration overrides anything
else that tries to rename interfaces


what about read and quote correctly?

"doing that on systems with just one ethernet interface (the majority) 
every few years is nothing else than asking for troubles"


the problems you are talking about *did not* affect single-nic machines, 
the new ones does




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Reindl Harald]

Am 08.11.2015 um 20:29 schrieb Richard W.M. Jones:

On Sat, Nov 07, 2015 at 05:28:54PM +, Christopher wrote:

I recently updated my desktop to f23, and it went smoothly, for the most
part. However, it broke my mediatomb server because the NIC changed from
em1 to eno1.

Is this something that was expected? It certainly surprised me.


It happened to a bunch of servers when I updated them from F22 to F23.
Their NICs changed from p6p1 -> enp3s0.  It was annoying because I had
to boot each one with a display and keyboard and change the network
configuration by hand.

"predictable, stable network interface names"
https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/


that is simple to solve forever

* add "net.ifnames=0 biosdevname=0" to your kernel params
* get rid of NetworkManager
* rename your ethernet-devices in the ifcfg-files based on the MAC
* survives yum-upgardes from Fedora 9 to Fedora 23
* nobody needs NM and that other stuff on static configured servers
* frankly even with a DHCP wan-interface it works perfectly

the machine below has 16 network-interfaces and the IP is configured via 
DHCP and after get rid of all the "improvements" no loger troubles

__

[root@srv-rhsoft:~]$ cat /etc/sysconfig/network-scripts/ifcfg-wan
###
#  WAN (Chello)   #
###

DEVICE=wan
HWADDR=24:be:05:1a:c0:27

TYPE=Ethernet
BOOTPROTO=static
ONBOOT=yes
ARPCHECK=no
NM_CONTROLLED=no
USERCTL=no
IPV6INIT=no
MTU=1500
ETHTOOL_OPTS="wol d; -K ${DEVICE} tso on rx on tx on gro on; -G 
${DEVICE} rx 2048 tx 2048; -C ${DEVICE} rx-usecs 75"

__

[root@srv-rhsoft:~]$ cat /etc/systemd/system/network-wan-bridge.service
[Unit]
Description=Network Internet Bridge
After=network.service systemd-networkd.service network-online.target

[Service]
Type=forking
ExecStartPre=-/usr/sbin/brctl addbr br-wan
ExecStartPre=-/usr/sbin/brctl stp br-wan off
ExecStartPre=-/usr/sbin/brctl setageing br-wan 600
ExecStartPre=-/usr/sbin/brctl setfd br-wan 5
ExecStartPre=-/usr/sbin/brctl addif br-wan wan
ExecStartPre=-/usr/sbin/brctl addif br-wan vmnet1
ExecStartPre=-/usr/sbin/ifconfig br-wan hw ether 00:50:8D:B5:CC:DE up
ExecStart=/usr/sbin/dhclient -4 -H srv-rhsoft -q -R 
subnet-mask,broadcast-address,routers,interface-mtu br-wan

ExecStartPost=-/usr/sbin/ifconfig br-wan -multicast -allmulti
ExecStartPost=-/usr/sbin/ifconfig vmnet1 0.0.0.0 -multicast -allmulti up
ExecStopPost=-/usr/sbin/ifconfig br-wan down
ExecStopPost=-/usr/sbin/brctl delbr br-wan

Restart=always
RestartSec=1

PrivateTmp=yes
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
CAP_NET_BROADCAST CAP_NET_RAW


ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr

InaccessibleDirectories=-/mnt
InaccessibleDirectories=-/mnt/data



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Christopher]

On Sat, Nov 7, 2015, 12:28 Christopher  wrote:

I recently updated my desktop to f23, and it went smoothly, for the most
part. However, it broke my mediatomb server because the NIC changed from
em1 to eno1.

Is this something that was expected? It certainly surprised me.

In addition to the mediatomb configuration needing to be changed, I also
noticed a more serious issue here: the firewalld zone associated with em1
did not get ported to eno1 during the upgrade. That could have serious
unexpected implications for security.

In my case, it wasn't that serious, because my default zone was more locked
down than the one I had for that NIC, but I can imagine scenarios where it
could be a problem.

For the most part, the upgrade experience was great, but I thought I'd
mention this particular issue for consideration/discussion, because I
wasn't aware of the naming change in advance, and it could have serious
consequences for function and security.


This is also a good reason why the default firewalld zone should be very
restrictive.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct