* Marco d'Itri m...@linux.it [2015-05-11 05:55]:
On May 08, Martin Pitt mp...@debian.org wrote:
I propose to retire [mac], i. e. drop
/lib/udev/rules.d/75-persistent-net-generator.rules and enable
[ifnames] by default.
I see a large enough consensus about switching by default to
On 06/30/2015 12:14 AM, Vincent Bernat wrote:
❦ 29 juin 2015 22:29 +0200, Thomas Goirand z...@debian.org :
So your proposal is: if the default is unusable (like above), then the
poor user has to find a way to fix that... I'm not convince that this is
what we want. I'd very much prefer a
❦ 29 juin 2015 22:29 +0200, Thomas Goirand z...@debian.org :
So your proposal is: if the default is unusable (like above), then the
poor user has to find a way to fix that... I'm not convince that this is
what we want. I'd very much prefer a usable default.
Me too, but there is none that we
On 06/26/2015 11:14 AM, Marco d'Itri wrote:
I believe that firmware-based device names work well enough in practice
since RHEL 7 uses them by default: I tend to trust a market-based
approach to maintenability more than anecdote from a very selected
population like the debian-devel@
On Jun 26, Thomas Goirand z...@debian.org wrote:
Actually it requires us to keep maintaining the
Revert-udev-network-device-renaming patch as long as there will be
systems with a 70-persistent-net.rules file renaming eth* to eth*.
The other solution would be to upstream that patch (maybe
On 05/11/2015 05:53 AM, Marco d'Itri wrote:
On May 08, Martin Pitt mp...@debian.org wrote:
I propose to retire [mac], i. e. drop
/lib/udev/rules.d/75-persistent-net-generator.rules and enable
[ifnames] by default.
I see a large enough consensus about switching by default to ifnames,
FWIW:
On 05/17/2015 09:28 PM, Josh Triplett wrote:
If that's a standard property of VMWare VMs, you could submit a udev
rule that improves the default naming on such systems. I believe there
are already some rules defining policies in that area, including
VM-specific information.
the only thing I
On 05/08/2015 09:28 AM, Josh Triplett wrote:
Marc Haber wrote:
I have tried this just last week and have found it kind of
unsatisfactory that it doesn't work in virtualized environments. For
example, in a KVM VM with virtio ethernet, the network devices still
end up in the system as eth0,
On Sun, May 17, 2015 at 08:03:54PM +0200, Bernd Zeimetz wrote:
On 05/08/2015 09:28 AM, Josh Triplett wrote:
Marc Haber wrote:
I have tried this just last week and have found it kind of
unsatisfactory that it doesn't work in virtualized environments. For
example, in a KVM VM with virtio
On Thu, 14 May 2015 09:07:16 +1000, Russell Stuart
russell-deb...@stuart.id.au wrote:
On Wed, 2015-05-13 at 17:16 +0200, Vincent Lefevre wrote:
Well, having some of the network traffic (more precisely, connections
to machines that have an IPv6 address) re-routed to some unknown
machine on the
On May 13, D. Jared Dominguez jared_doming...@dell.com wrote:
- it does not seem to me to provide any benefit over the firmware-based
names since in practice both would use by default an interface index
in the common case
Firmware based in what sense? From the biosdevname readme,
On 2015-05-12 22:31:43 +0200, Marc Haber wrote:
On Tue, 12 May 2015 17:08:33 +0200, Vincent Lefevre
vinc...@vinc17.net wrote:
On 2015-05-11 18:04:14 +0200, Marc Haber wrote:
In IPv6, routers advertise prefixes. If a new prefix comes, end
systems configured for SLAAC will allocate an IP
On Sat, May 09, 2015 at 02:49:35AM -0500, peter green wrote:
The main downside is that by nature the device names are not familiar
to current admins yet. For BIOS provided names you get e. g. ens0, for
PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a
necessary price to pay
Maybe biosdevname would be nice to have, but:
- somebody needs to actually maintain it in Debian
I actually had it ready to upload, but then given the approach RHEL 7
took and the general trend towards systemd-based approaches, I held off.
If there is interest, though, I'm happy to maintain
On Wed, 2015-05-13 at 17:16 +0200, Vincent Lefevre wrote:
Well, having some of the network traffic (more precisely, connections
to machines that have an IPv6 address) re-routed to some unknown
machine on the local network is not a nice feature.
IMHO, such a feature should be enabled only by
On Wed, 13 May 2015 17:16:07 +0200, Vincent Lefevre
vinc...@vinc17.net wrote:
On 2015-05-12 22:31:43 +0200, Marc Haber wrote:
On Tue, 12 May 2015 17:08:33 +0200, Vincent Lefevre
vinc...@vinc17.net wrote:
On 2015-05-11 18:04:14 +0200, Marc Haber wrote:
In IPv6, routers advertise prefixes. If a
Marvin Renich wrote:
Yes, I use ifupdown and wpasupplicant. Based on some of the threads on
this list there are many people who love Network Manager and many who
dislike it. I am one of the ones who dislike it. Given the fact that
it is (or at least was recently) clearly controversial,
On Mon, May 11, 2015 at 07:40:38PM +0200, Karsten Merker wrote:
On Mon, May 11, 2015 at 09:29:21AM +0100, Jonathan Dowland wrote:
On Fri, May 08, 2015 at 11:03:55PM +0200, Marc Haber wrote:
On Fri, 8 May 2015 13:33:06 -0700, j...@joshtriplett.org wrote:
There are much better alternatives
On Tue, 12 May 2015 17:08:33 +0200, Vincent Lefevre
vinc...@vinc17.net wrote:
On 2015-05-11 18:04:14 +0200, Marc Haber wrote:
In IPv6, routers advertise prefixes. If a new prefix comes, end
systems configured for SLAAC will allocate an IP address in this
prefix and begin to use it.
On this
On 2015-05-11 18:04:14 +0200, Marc Haber wrote:
In IPv6, routers advertise prefixes. If a new prefix comes, end
systems configured for SLAAC will allocate an IP address in this
prefix and begin to use it.
On this subject, end systems under Debian are configured for SLAAC
by default. :-(
--
On Mon, 11 May 2015 10:18:18 +1000, Russell Stuart
russell-deb...@stuart.id.au wrote:
I get the distinct feeling some people posting here consider ifup/down
old fashioned. Granted it doesn't have a nice GUI, but from the point
of view of someone who deploys lots of similar machines a GUI of any
On Sun, May 10, 2015 at 09:04:23PM +0200, Stephan Seitz wrote:
On Sun, May 10, 2015 at 07:09:41PM +0200, Marc Haber wrote:
Just for the record, an unexpected interface name change hasn't
happened in my professional career in more than ten years.
Same here. I have never seen unexpected
On Fri, May 08, 2015 at 11:03:55PM +0200, Marc Haber wrote:
On Fri, 8 May 2015 13:33:06 -0700, j...@joshtriplett.org wrote:
There are much better alternatives for most common cases.
For example being?
ufw is quite nice.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
On Mon, 11 May 2015 09:29:43 +0200, Marc Haber
mh+debian-de...@zugschlus.de wrote:
On Mon, 11 May 2015 10:18:18 +1000, Russell Stuart
russell-deb...@stuart.id.au wrote:
I get the distinct feeling some people posting here consider ifup/down
old fashioned. Granted it doesn't have a nice GUI, but
Just a quick observation: a lot of the problems people have experienced with
network interface naming is a combination of two things: both whatever
persistence scheme is in place (or not), but also the fact they *need to know a
network interface name at all*.
Many times I've wanted to express
Ben Hutchings b...@decadent.org.uk wrote:
The NM configuration is based on MAC addresses and doesn’t care about
the interface name at all. This is the exact opposite of “handling
dynamic names ungracefully”.
Well, that's assuming hardware that has a
On Mon, 2015-05-11 at 12:16 +0200, Josselin Mouette wrote:
Ben Hutchings b...@decadent.org.uk wrote:
The NM configuration is based on MAC addresses and doesn’t care
about
the interface name at all. This is the exact opposite of “handling
dynamic names
* Marco d'Itri m...@linux.it [150510 23:55]:
I see a large enough consensus about switching by default to ifnames,
and I believe that the few people who want MAC-based names for USB
interfaces can easily set NamePolicy=mac or write a custom rule.
Huh? This thread seems to have lots of
On Mon, 2015-05-11 at 05:53 +0200, Marco d'Itri wrote:
[...]
It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on
my Allwinner-based ARM computer), which means that interfaces will get
a mac-based name like enx028909xx.
[...]
For ARM (and any other architecture using
On Mon, 2015-05-11 at 09:29 +0200, Marc Haber wrote:
For example, it doesn't know dependencies between Interfaces, which is
rather common for a server jockey (consider a VLAN on a bridge which
is connected to the network via a bonding device)
I haven't had to solve that example, but I have had
On May 11, Marvin Renich m...@renich.org wrote:
I see a large enough consensus about switching by default to ifnames,
and I believe that the few people who want MAC-based names for USB
interfaces can easily set NamePolicy=mac or write a custom rule.
Huh? This thread seems to have lots
Hello,
Karsten Merker [2015-05-11 20:22 +0200]:
From what Ben Hutchings has described in
1431294933.2233.66.ca...@decadent.org.uk, the race condition
could easily be avoided with the current codebase by simply not
using eth as the prefix, but e.g. en.
Right, that would solve one problem, but
On May 11, Ben Hutchings b...@decadent.org.uk wrote:
For ARM (and any other architecture using Device Tree) the on-board
indices should be specified as aliases 'ethernet0', 'ethernet1', etc.
Is this something that I can experiment on by patching just the device
tree definition or does it
On Mon, 11 May 2015 22:37:40 +1000, Russell Stuart
russell-deb...@stuart.id.au wrote:
On Mon, 2015-05-11 at 09:29 +0200, Marc Haber wrote:
For example, it doesn't know dependencies between Interfaces, which is
rather common for a server jockey (consider a VLAN on a bridge which
is connected to
Le 10/05/2015 16:24, Vincent Bernat a écrit :
Actually, when rebooting your (mission-critical) server, you can have a
race condition where eth1 is not the interface that was eth1 on the
previous boot and rename5 is the interface that should be
eth1. That's what needs to be fixed. Doing nothing
On Sun, 2015-05-10 at 22:23 +0200, Vincent Danjean wrote:
Le 10/05/2015 16:24, Vincent Bernat a écrit :
Actually, when rebooting your (mission-critical) server, you can have a
race condition where eth1 is not the interface that was eth1 on the
previous boot and rename5 is the interface that
On May 08, Martin Pitt mp...@debian.org wrote:
I propose to retire [mac], i. e. drop
/lib/udev/rules.d/75-persistent-net-generator.rules and enable
[ifnames] by default.
I see a large enough consensus about switching by default to ifnames,
and I believe that the few people who want MAC-based
On May 08, Marc Haber mh+debian-de...@zugschlus.de wrote:
That would mean changing local code to _both_ handle en* and eth*,
which is (a) a surprise and (b) unsatisfying in _my_ personal opinion.
I'd rather have it fully and consistently or not at all.
Not at all is going to be harder and
Hey Marco,
Marco d'Itri [2015-05-11 5:53 +0200]:
I am not sure that we really need to retire 75-persistent-net-generator
right now: the annoying part to maintain is the kernel patch which we
will need anyway for at least a couple of releases
Which kernel patch? I think all of this ought to
Le vendredi 08 mai 2015 à 20:14 +0200, Marc Haber a écrit :
Do we have other network software other than ifupdown,
systemd-networkd and network-manager, the latter handling dynamic
names rather ungracefully.
The NM configuration is based on MAC addresses and doesn’t care about
the interface
On Sun, 2015-05-10 at 17:11 +0200, Vincent Bernat wrote:
The disease is that actual servers running actual free software can
break at each boot because we cannot have both a persistent naming
scheme and use the eth* prefix is worse that the cure because old
versions of Novell ZENworks may stop
On Sun, 2015-05-10 at 23:57 +0200, Josselin Mouette wrote:
Le vendredi 08 mai 2015 à 20:14 +0200, Marc Haber a écrit :
Do we have other network software other than ifupdown,
systemd-networkd and network-manager, the latter handling dynamic
names rather ungracefully.
The NM configuration
On Sat, May 09, 2015 at 02:36:30PM -0700, Josh Triplett wrote:
Why? What does a stable name matter in the case you mentioned?
Because I don’t want to look up the interface name of the day when I use
wireshark/tshark? Because I don’t want to change my iptables scripts
which is working very
On 05/10/2015 at 07:36 AM, Stephan Seitz wrote:
On Sat, May 09, 2015 at 02:36:30PM -0700, Josh Triplett wrote:
Why? What does a stable name matter in the case you mentioned?
Because I don’t want to look up the interface name of the day when I
use wireshark/tshark? Because I don’t want to
On Sat, May 09, 2015 at 05:55:36PM -0700, Cameron Norman wrote:
On Sat, May 9, 2015 at 2:36 PM, Josh Triplett j...@joshtriplett.org wrote:
Marvin Renich wrote:
* Martin Pitt mp...@debian.org [150509 05:27]:
TBH, hotpluggable USB network adapters which change all the time sound
like a
On Sun, 10 May 2015 17:11:03 +0200, Vincent Bernat ber...@debian.org
wrote:
The disease is that actual servers running actual free software can
break at each boot because we cannot have both a persistent naming
scheme and use the eth* prefix is worse
Just for the record, an unexpected interface
On 05/10/2015 at 10:24 AM, Vincent Bernat wrote:
❦ 10 mai 2015 08:20 -0400, The Wanderer wande...@fastmail.fm :
Were you actually using ifupdown to manage the varied set of
wireless networks? Because if not, then the name shouldn't
matter.
Yes, I’m using ifupdown. Besides USB NICs
❦ 10 mai 2015 10:45 -0400, The Wanderer wande...@fastmail.fm :
Do you speak about ifupdown? It's Debian only. eth* interfaces is
not *nix at all since all BSD are using per-driver naming
convention.
Upon consideration, I suspect that I've been making - at least - the
following three
❦ 10 mai 2015 08:20 -0400, The Wanderer wande...@fastmail.fm :
Were you actually using ifupdown to manage the varied set of
wireless networks? Because if not, then the name shouldn't
matter.
Yes, I’m using ifupdown. Besides USB NICs don’t have to be WiFi.
Lots of people are, and it's
On Sun, May 10, 2015 at 07:09:41PM +0200, Marc Haber wrote:
On Sun, 10 May 2015 17:11:03 +0200, Vincent Bernat ber...@debian.org
wrote:
The disease is that actual servers running actual free software can
break at each boot because we cannot have both a persistent naming
scheme and use the eth*
Marvin Renich wrote:
* Martin Pitt mp...@debian.org [150509 05:27]:
TBH, hotpluggable USB network adapters which change all the time sound
like a corner case in a server world where you have hand-written
config files referring to interface names. They are of course common
on the client
* Martin Pitt mp...@debian.org [150509 05:27]:
TBH, hotpluggable USB network adapters which change all the time sound
like a corner case in a server world where you have hand-written
config files referring to interface names. They are of course common
on the client side, but there stable
* Josh Triplett j...@joshtriplett.org [150509 17:37]:
Marvin Renich wrote:
I disagree that stable interface names do not matter for USB adaptors
for consumer laptops. I have owned two laptops where the on-board WiFi
adaptor was too new to have reliable Linux drivers until 6-12 months
On Sat, May 9, 2015 at 2:36 PM, Josh Triplett j...@joshtriplett.org wrote:
Marvin Renich wrote:
* Martin Pitt mp...@debian.org [150509 05:27]:
TBH, hotpluggable USB network adapters which change all the time sound
like a corner case in a server world where you have hand-written
config
Is there a tool to list interfaces based on their characteristics?
Right now at $work our initial setup code does glob eth* in
/sys/class/net in order to setup a bond interface using all NICs, so
network works no matter which NIC one plugs a cable into. It sounds
like this proposal would break
Hey Paul,
Paul Wise [2015-05-09 16:15 +0800]:
Is there a tool to list interfaces based on their characteristics?
Right now at $work our initial setup code does glob eth* in
/sys/class/net in order to setup a bond interface using all NICs, so
network works no matter which NIC one plugs a cable
The main downside is that by nature the device names are not familiar
to current admins yet. For BIOS provided names you get e. g. ens0, for
PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a
necessary price to pay (biosdevname names look similar).
The stability of these names
Bjørn Mork [2015-05-08 16:13 +0200]:
PCI buses can be and are hotplugged, similar to network devices.
Yes, that's certainly a valid point. It's not unanimously clear how
you define the identity of an interface, whether it's more like by
location or by MAC address. There are pros and cons for
On Fri, 08 May 2015 21:54:11 +0300, Timo Juhani Lindfors
timo.lindf...@iki.fi wrote:
Marc Haber mh+debian-de...@zugschlus.de writes:
Btw, why the expletive is the only way to configure this the kernel
command line and no configuration inside /etc where one would expect
it?
Maybe because udev
On Fri, 8 May 2015 07:59:31 +0200, Martin Pitt mp...@debian.org
wrote:
Details about [ifnames]
---
This is a generic solution which extends the [biosdevname] idea and
thus applies to all practical cases and all architectures. It doesn't
need any persistant state (i. e. dynamic
Martin Pitt [2015-05-08 7:59 +0200]:
Details about [mac]
---
[...]
* It requires a writable /etc/udev/rules.d/ for persistantly storing
the assignment. We don't want/have that with system-image
(touch/snappy).
Sorry, these are Ubuntu specific terms, forgot to
Hello Debianists,
Quick intro to the problem: The kernel generally detects network
interfaces (eth0, wlan1, etc.) in an unpredictable and often
unstable order. But in order to refer to a particular one in
/etc/network/interfaces, firewall configs etc. you need to use a
stable name.
The general
Marc Haber wrote:
On Fri, 8 May 2015 07:59:31 +0200, Martin Pitt mp...@debian.org
wrote:
Details about [ifnames]
---
This is a generic solution which extends the [biosdevname] idea and
thus applies to all practical cases and all architectures. It doesn't
need any persistant
Martin Pitt wrote:
Proposal
I propose to retire [mac], i. e. drop
/lib/udev/rules.d/75-persistent-net-generator.rules and enable
[ifnames] by default.
This will provide the new stable interface names for all new
installations, stop the different handling of server/client, work
On Fri, 8 May 2015 00:28:44 -0700, Josh Triplett
j...@joshtriplett.org wrote:
Marc Haber wrote:
I have tried this just last week and have found it kind of
unsatisfactory that it doesn't work in virtualized environments. For
example, in a KVM VM with virtio ethernet, the network devices still
end
Hello Konstantin,
Konstantin Khomoutov [2015-05-08 13:08 +0300]:
Is it possible to provide a tool (a shell script?) that would print out
the new would-be name of the interface provided by the user so that it
would be possible to migrate remote systems only accessible via SSH?
The closest
On Fri, 8 May 2015 00:33:58 -0700, Josh Triplett
j...@joshtriplett.org wrote:
To help migrate existing systems, I'd suggest including a NEWS.Debian
file that explains the change, and recommends deleting
/etc/udev/rules.d/70-persistent-net.rules on systems that don't depend
on the exact names (for
On Fri, 8 May 2015 00:33:58 -0700
Josh Triplett j...@joshtriplett.org wrote:
I propose to retire [mac], i. e. drop
/lib/udev/rules.d/75-persistent-net-generator.rules and enable
[ifnames] by default.
[...]
Having spent a non-trivial amount of time fighting
persistent-net.rules on various
Tollef Fog Heen wrote:
]] Marc Haber
That would mean changing local code to _both_ handle en* and eth*,
which is (a) a surprise and (b) unsatisfying in _my_ personal opinion.
By en*, you mean emN, enN, pXpY all, right?
Or more generally anything that enumerates as a network device.
On Fri, 08 May 2015 15:11:06 +0200, Tollef Fog Heen tfh...@err.no
wrote:
]] Marc Haber
That would mean changing local code to _both_ handle en* and eth*,
which is (a) a surprise and (b) unsatisfying in _my_ personal opinion.
By en*, you mean emN, enN, pXpY all, right?
yes.
Greetings
Marc
--
Karsten Merker wrote:
while this probably works resonably well for (semi-)fixed devices
like onboard-NICs and PCI/PCIe cards, it results in a completely
unsuitable behaviour with pluggable devices such as USB network
adapters. When using ifnames, the interface name depends on the
USB port
Hi,
Karsten Merker:
while this probably works resonably well for (semi-)fixed devices
like onboard-NICs and PCI/PCIe cards, it results in a completely
unsuitable behaviour with pluggable devices such as USB network
adapters.
Why?
I can envision two likely scenarios for using a USB adapter.
On Fri, 8 May 2015 10:50:30 -0700, Josh Triplett
j...@joshtriplett.org wrote:
Karsten Merker wrote:
while this probably works resonably well for (semi-)fixed devices
like onboard-NICs and PCI/PCIe cards, it results in a completely
unsuitable behaviour with pluggable devices such as USB network
Marc Haber wrote:
On Fri, 8 May 2015 10:50:30 -0700, Josh Triplett
j...@joshtriplett.org wrote:
Karsten Merker wrote:
while this probably works resonably well for (semi-)fixed devices
like onboard-NICs and PCI/PCIe cards, it results in a completely
unsuitable behaviour with pluggable
On Fri, May 08, 2015 at 09:06:25PM +0200, Karsten Merker wrote:
On Fri, May 08, 2015 at 10:50:30AM -0700, Josh Triplett wrote:
Karsten Merker wrote:
while this probably works resonably well for (semi-)fixed devices
like onboard-NICs and PCI/PCIe cards, it results in a completely
On Fri, 8 May 2015 11:36:44 -0700, Josh Triplett
j...@joshtriplett.org wrote:
Also, what do you mean by NetworkManager handling dynamic names ungracefully?
I just remember having horrible trouble. Otherwise I would have filed
a bug report.
Greetings
Marc
--
Am 08.05.2015 um 18:31 schrieb Karsten Merker:
while this probably works resonably well for (semi-)fixed devices
like onboard-NICs and PCI/PCIe cards, it results in a completely
unsuitable behaviour with pluggable devices such as USB network
adapters. When using ifnames, the interface name
Just my 0.02$ against using the BIOS method.
I have and Do see inconsistent bios vendor naming used from release to
release of their Firmware updates. I have had to fix HP Propliants servers
numerous time due to a firmware update changing the number and/or order of
SATA ports, PCI and other
Marc Haber mh+debian-de...@zugschlus.de writes:
Btw, why the expletive is the only way to configure this the kernel
command line and no configuration inside /etc where one would expect
it?
Maybe because udev is started from initramfs before the root filesystem
has been mounted?
--
To
On Fri, 8 May 2015 13:33:06 -0700, j...@joshtriplett.org wrote:
There are much better alternatives for most common cases.
For example being?
Greetings
Ma iptables --table INPUT --interface eth+ --jump REJECT rc
--
-- !! No courtesy copies, please !! -
❦ 8 mai 2015 23:03 +0200, Marc Haber mh+debian-de...@zugschlus.de :
There are much better alternatives for most common cases.
For example being?
firewalld works nicely nowadays. You assign different level of security
to different networks. When I dock my laptop, network manager configures
]] Marc Haber
That would mean changing local code to _both_ handle en* and eth*,
which is (a) a surprise and (b) unsatisfying in _my_ personal opinion.
By en*, you mean emN, enN, pXpY all, right?
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To
On Fri, 2015-05-08 at 12:41 +0200, Marc Haber wrote:
On Fri, 8 May 2015 00:33:58 -0700, Josh Triplett
j...@joshtriplett.org wrote:
To help migrate existing systems, I'd suggest including a NEWS.Debian
file that explains the change, and recommends deleting
On Fri, 8 May 2015 12:40:39 +0200, Martin Pitt mp...@debian.org
wrote:
I don't
know whether it's possible to change the name while the interface is
up and in use.
It isn't.
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Haber |
On Fri, May 08, 2015 at 10:04:36PM +0200, Karsten Merker wrote:
On Fri, May 08, 2015 at 12:29:03PM -0700, j...@joshtriplett.org wrote:
On Fri, May 08, 2015 at 09:06:25PM +0200, Karsten Merker wrote:
On Fri, May 08, 2015 at 10:50:30AM -0700, Josh Triplett wrote:
Karsten Merker wrote:
85 matches
Mail list logo
