On Fri, 08 May 2015 21:54:11 +0300, Timo Juhani Lindfors
wrote:
>Marc Haber writes:
>> Btw, why the 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 filesyst
On Fri, 2015-05-08 at 12:41 +0200, Marc Haber wrote:
> On Fri, 8 May 2015 00:33:58 -0700, Josh Triplett
> 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 system
❦ 8 mai 2015 23:03 +0200, Marc Haber :
>>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
the network interface and f
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 !! -
M
On Fri, 8 May 2015 11:36:44 -0700, Josh Triplett
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
--
-- !! No courtesy co
Marc Haber writes:
> Btw, why the 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 UNSUBSCRIBE, email to debian-devel-requ..
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 wr
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
>
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 things
Marc Haber wrote:
> On Fri, 8 May 2015 10:50:30 -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
> >> unsuitable behaviour with pluggable devices such
On Fri, 8 May 2015 10:50:30 -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
>> unsuitable behaviour with pluggable devices such as USB network
>> adapters. W
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
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 por
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 adapte
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 devic
On Fri, 08 May 2015 15:11:06 +0200, 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?
yes.
Greetings
Marc
--
]] 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 U
On Fri, 8 May 2015 12:40:39 +0200, Martin Pitt
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 | " Questions are t
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 th
On Fri, 8 May 2015 00:33:58 -0700, Josh Triplett
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 instance, systems
On Fri, 8 May 2015 00:28:44 -0700, 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 syst
On Fri, 8 May 2015 00:33:58 -0700
Josh Triplett 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 systems, I'd v
Package: wnpp
Severity: wishlist
Owner: Tim Potter
* Package name: golang-gocapability
Version : 0.0~git20150507
Upstream Author : Suryandaru Triandana
* URL : https://github.com/syndtr/gocapability
* License : BSD
Programming Lang: Go
Description : Uti
Package: wnpp
Severity: wishlist
Owner: Tim Potter
* Package name: golang-raven-go
Version : 0.0~git20150427
Upstream Author : Jonathan Rudenberg
* URL : https://github.com/getsentry/raven-go
* License : BSD
Programming Lang: Go
Description : Go client
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,
Marc Haber wrote:
>On Fri, 8 May 2015 07:59:31 +0200, Martin Pitt
>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
26 matches
Mail list logo
