Philip Hands dixit:
>So, is what you are asking for that rather than simply deleting
>75-persistent-net-generator.rules, that it instead be moved to
>/usr/share/doc/udev/examples/ with a note suggesting that people
>not use it?
That would be sufficient. Ideally add a note on how to
use it (I see
Thorsten Glaser writes:
> Simon McVittie dixit:
>
>>You can still do this via manual configuration; as far as I understand
>
> Yes, but…
>
>>* the current Debian-specific persistent-net-generator scheme
>
> pitti wants to drop this; however, this is where we usually
> do the manual renaming when
Simon McVittie dixit:
>You can still do this via manual configuration; as far as I understand
Yes, but…
>* the current Debian-specific persistent-net-generator scheme
pitti wants to drop this; however, this is where we usually
do the manual renaming when needed.
By all means, do your new thing
On 25/06/15 23:14, Philipp Kern wrote:
> On the other hand I'm more of a fan of actually naming
> interfaces by their purpose or external labeling. Makes for even less
> mental gymnastics. \-:
You can still do this via manual configuration; as far as I understand
it, nobody is proposing to take aw
On Thu, Jun 25, 2015 at 08:16:12AM -0400, Marvin Renich wrote:
> Think about it. Any program can deal with any name or naming
> convention. It doesn't matter whether the name is obfuscated or not. A
> human sysadmin, however, has a much easier time using eth2 than
> enx3c52ca. Binary ids are fo
[ sorry for replying late, I wasn't subscribed, but I read both threads
and I hope I got the In-Reply-To / References right ]
As someone with decent experience deploying RHEL/Centos and Debian on
anything from ARM boards, through x86 desktops/servers (HP/IBM/Dell),
IBM POWER, to IBM System Z (s3
On Jun 25, Marvin Renich wrote:
> If the priority of the goals is realigned to make sense, then we must
> eliminate any solution that satisfies the no-state-file goal if it does
> not also satisfy the human-usable goal. If this brings us back to where
> we currently are, so be it. But please do
On Thu, 25 Jun 2015 13:26:54 +0200, m...@linux.it (Marco d'Itri) wrote:
>On Jun 25, Martin Pitt wrote:
>
>> Unlike /dev nodes, network interfaces can't have aliases as far as I
>> know. Am I missing anything?
>No. As is usual with udev, the people who do not understand how it works
>are always re
* Marco d'Itri [150625 07:27]:
> On Jun 25, Martin Pitt wrote:
>
> > Unlike /dev nodes, network interfaces can't have aliases as far as I
> > know. Am I missing anything?
> No. As is usual with udev, the people who do not understand how it works
> are always ready to propose solutions.
>
> --
On Jun 25, Martin Pitt wrote:
> Unlike /dev nodes, network interfaces can't have aliases as far as I
> know. Am I missing anything?
No. As is usual with udev, the people who do not understand how it works
are always ready to propose solutions.
--
ciao,
Marco
pgp5RW1jnlifi.pgp
Description: PG
Hey Benjamin,
Benjamin Drung [2015-06-25 12:44 +0200]:
> How about adding a easy-to-type symlink for MAC named devices? Would
> that work? Then users could refer to a device by the persistent MAC name
> enx112233445566, but also could use a short name like eth2 (which might
> not be persistent).
>
Am Mittwoch, den 03.06.2015, 12:01 +0200 schrieb Martin Pitt:
> The main objection in the discussion was that path based names aren't
> appropriate for USB based devices. I agree, so I change my proposal to
> use MAC based names for anything USB based. The names will look even
> worse as they inclu
On Jun 05, "Milan P. Stanic" wrote:
> Now, USB Ethernet interface (usb) and bridge (br0) have the same MAC.
This is not relevant, because virtual interfaces like br0 are not
subject to renaming.
--
ciao,
Marco
pgpfCA5WWp_SS.pgp
Description: PGP signature
On Thu, 2015-06-04 at 19:41, Michael Biebl wrote:
> Am 04.06.2015 um 10:10 schrieb Josselin Mouette:
> > How about using only the last 3 bytes of the MAC?
> >
> > The probability of using, on the same system, *two or more* controllers
> > from *different brands* with a collision in the last 3 byte
Am 04.06.2015 um 10:10 schrieb Josselin Mouette:
> How about using only the last 3 bytes of the MAC?
>
> The probability of using, on the same system, *two or more* controllers
> from *different brands* with a collision in the last 3 bytes is
> nonexistent in practice.
>
> The clear benefit would
j...@debian.org wrote:
>
>How about using only the last 3 bytes of the MAC?
>
>The probability of using, on the same system, *two or more* controllers
>from *different brands* with a collision in the last 3 bytes is
>nonexistent in practice.
>
>The clear benefit would be that 3 bytes / 6 hex digits
Vincent Danjean [2015-06-03 12:43 +0200]:
> So, you can show a debconf note, try (or not) to migrate the file
> automatically, remove (or comment-out) the 70-persistent-net.rules,
> or ... but, please, do not write a preinst script that fails
> because the admin did not update its config before upg
At Wed, 3 Jun 2015 17:11:08 +0200,
Stephan Seitz wrote:
>
> On Wed, Jun 03, 2015 at 12:01:34PM +0200, Martin Pitt wrote:
> > However, on a desktop you don't ever care about the device names, and
>
> Of course you do. How will you use tcpdump or tshark without the
> device names? In most desktop s
Hi,
Martin Pitt wrote:
The main objection in the discussion was that path based names aren't
appropriate for USB based devices. I agree, so I change my proposal to
use MAC based names for anything USB based. The names will look even
worse as they include the MAC i
]] Stephan Seitz
> On Wed, Jun 03, 2015 at 12:01:34PM +0200, Martin Pitt wrote:
> >However, on a desktop you don't ever care about the device names, and
>
> Of course you do. How will you use tcpdump or tshark without the
> device names? In most desktop setups a „tcpdump -i eth0” is the right
>
Le 03/06/2015 12:59, Marco d'Itri a écrit :
> On Jun 03, Vincent Danjean wrote:
>
>>> stretch+1 (or maybe +2):
>>> - Check existance/non-emptiness of
>>> /etc/udev/rules.d/70-persistent-net.rules in udev.preinst,
>>> Show critical debconf note, and refuse to upgrade
>> No. It is always
On Wed, Jun 03, 2015 at 12:01:34PM +0200, Martin Pitt wrote:
However, on a desktop you don't ever care about the device names, and
Of course you do. How will you use tcpdump or tshark without the device
names? In most desktop setups a „tcpdump -i eth0” is the right command.
higher-level fir
On Wed, 2015-06-03 at 13:11 +0200, Michael Biebl wrote:
> Am 03.06.2015 um 12:59 schrieb Marco d'Itri:
> > On Jun 03, Vincent Danjean wrote:
> >
> >>> stretch+1 (or maybe +2):
> >>> - Check existance/non-emptiness of
> >>> /etc/udev/rules.d/70-persistent-net.rules in udev.preinst,
> >>>
Am 03.06.2015 um 12:59 schrieb Marco d'Itri:
> On Jun 03, Vincent Danjean wrote:
>
>>> stretch+1 (or maybe +2):
>>> - Check existance/non-emptiness of
>>> /etc/udev/rules.d/70-persistent-net.rules in udev.preinst,
>>> Show critical debconf note, and refuse to upgrade
>> No. It is alway
On Jun 03, Vincent Danjean wrote:
> > stretch+1 (or maybe +2):
> > - Check existance/non-emptiness of
> > /etc/udev/rules.d/70-persistent-net.rules in udev.preinst,
> > Show critical debconf note, and refuse to upgrade
> No. It is always a real pain when a preinst script fails.
This pa
Le 03/06/2015 12:01, Martin Pitt a écrit :
> stretch+1 (or maybe +2):
> - Check existance/non-emptiness of
> /etc/udev/rules.d/70-persistent-net.rules in udev.preinst,
> Show critical debconf note, and refuse to upgrade
No. It is always a real pain when a preinst script fails.
It is (ne
Martin Pitt [2015-06-03 12:01 +0200]:
> | $ cat /lib/systemd/network/01-mac-for-usb.link
> | [Match]
> | Path=*-usb-*
> |
> | [Link]
> | NamePolicy=kernel database mac onboard slot path
> | MACAddressPolicy=persistent
Sorry, that was an old version. We want this:
NamePolicy=kernel databas
27 matches
Mail list logo
