retitle 786902 ITA: ifupdown -- high level tools to configure network
owner 786902 !
thanks
On Tue, May 26, 2015 at 05:45:22PM +0200, Andrew Shadura wrote:
> This is that time of the year when I finally need to orphan ifupdown
> package. It's been quite some time already since I first thought abo
On Sat, 30 May 2015 16:24:35 Marco d'Itri wrote:
> On May 30, Dmitry Smirnov wrote:
> > I'm not yet sure what can replace "ifupdown" in bonded NIC configurations
> > with "ifenslave"...
>
> I am not sure about the obsolete bonding driver,
I wouldn't rush to label our "ifenslave" as obsolete: in
On 5/30/15, 7:24 AM, Marco d'Itri wrote:
On May 30, Dmitry Smirnov wrote:
I'm not yet sure what can replace "ifupdown" in bonded NIC configurations with
"ifenslave"...
I am not sure about the obsolete bonding driver, but NM supports the new
teaming driver. [1]
systemd-networkd support is plan
On May 30, Dmitry Smirnov wrote:
> I'm not yet sure what can replace "ifupdown" in bonded NIC configurations
> with
> "ifenslave"...
I am not sure about the obsolete bonding driver, but NM supports the new
teaming driver. [1]
systemd-networkd support is planned but not being actively worked on
On Fri, 29 May 2015 14:02:04 Simon McVittie wrote:
> In other words, ifupdown is one choice among many - on wheezy/jessie
> servers I currently choose ifupdown (although I should try out
> systemd-networkd at some point), but on laptops where I've chosen to use
> NM, the only reason ifupdown is sti
On Fri, 2015-05-29 at 16:17 +0200, Marco d'Itri wrote:
> > And I guess it's rather uncommon on Debian to use NM e.g. on server
> > systems (probably also because most people wonder why they need a
> > bloated daemon/etc. running just for a network that is brought up/down
> > once every nnn days)
>
On 5/29/15, 1:44 AM, Michael Biebl wrote:
Am 29.05.2015 um 06:59 schrieb roopa:
ifupdown did pose a few challenges to manage interfaces at the scale we
deploy (sometimes more than 2000 interfaces
bridges/bonds etc). But we loved the extensibility and modularity it
provided.
And the only difficul
On May 27, Christoph Anton Mitterer wrote:
> And I guess it's rather uncommon on Debian to use NM e.g. on server
> systems (probably also because most people wonder why they need a
> bloated daemon/etc. running just for a network that is brought up/down
> once every nnn days)
Maybe, but it is the
On 27/05/15 21:12, Christoph Anton Mitterer wrote:
> On Wed, 2015-05-27 at 20:50 +0100, Simon McVittie wrote:
>> I don't think ifupdown has been "Debian's native tool" for several years
>> now. It is one among several available tools, and happens to be the only
>> one with Debian as its upstream;
Am 29.05.2015 um 06:59 schrieb roopa:
> ifupdown did pose a few challenges to manage interfaces at the scale we
> deploy (sometimes more than 2000 interfaces
> bridges/bonds etc). But we loved the extensibility and modularity it
> provided.
> And the only difficulty continuing with ifupdown was ext
On 5/28/15, 10:05 PM, Paul Wise wrote:
On Thu, 2015-05-28 at 21:59 -0700, roopa wrote:
We plan to post it for inclusion as an alternative to ifupdown (using
the debian alternatives infrastructure), hoping to make it easier
for people who may be interested in trying it out.
Please see this page
On Thu, 2015-05-28 at 21:59 -0700, roopa wrote:
> We plan to post it for inclusion as an alternative to ifupdown (using
> the debian alternatives infrastructure), hoping to make it easier
> for people who may be interested in trying it out.
Please see this page for how to get ifupdown2 into Debi
On 5/27/15, 8:18 PM, Paul Wise wrote:
On Thu, May 28, 2015 at 1:41 AM, Christoph Anton Mitterer wrote:
Haven't tried systemd-networkd yet, but at least NM fails in even very
simple cases (like resolving is broken, when I disconnect the wire and
go back to wifi, etc. pp.) ... plus the whole desi
On Thu, 2015-05-28 at 11:18 +0800, Paul Wise wrote:
> > Haven't tried systemd-networkd yet, but at least NM fails in even very
> > simple cases (like resolving is broken, when I disconnect the wire and
> > go back to wifi, etc. pp.) ... plus the whole design, that it tries to
> > be the canonical
On Thu, May 28, 2015 at 1:41 AM, Christoph Anton Mitterer wrote:
> Haven't tried systemd-networkd yet, but at least NM fails in even very
> simple cases (like resolving is broken, when I disconnect the wire and
> go back to wifi, etc. pp.) ... plus the whole design, that it tries to
> be the canon
On Wed, May 27, 2015 at 5:29 PM, Josh Triplett wrote:
> On Wed, May 27, 2015 at 05:06:38PM -0700, Cameron Norman wrote:
>> On Wed, May 27, 2015 at 4:36 PM, Josh Triplett wrote:
>> > Simon McVittie wrote:
>> >> One thing that an adopter could very usefully do with ifupdown would be
>> >> to coordi
On Wed, May 27, 2015 at 05:06:38PM -0700, Cameron Norman wrote:
> On Wed, May 27, 2015 at 4:36 PM, Josh Triplett wrote:
> > Simon McVittie wrote:
> >> One thing that an adopter could very usefully do with ifupdown would be
> >> to coordinate with the systemd maintainers on moving net.agent
> >> (D
On Wed, May 27, 2015 at 4:36 PM, Josh Triplett wrote:
> Simon McVittie wrote:
>> One thing that an adopter could very usefully do with ifupdown would be
>> to coordinate with the systemd maintainers on moving net.agent
>> (Debian-specific udev glue to invoke ifupdown) from udev into ifupdown,
>> s
Simon McVittie wrote:
> I don't think ifupdown has been "Debian's native tool" for several years
> now. It is one among several available tools, and happens to be the only
> one with Debian as its upstream; on a wheezy-era sysvinit system that
> uses NetworkManager, the only thing ifupdown does for
On Wed, 2015-05-27 at 22:12 +0200, Christoph Anton Mitterer wrote:
> On Wed, 2015-05-27 at 20:50 +0100, Simon McVittie wrote:
> > I don't think ifupdown has been "Debian's native tool" for several years
> > now. It is one among several available tools, and happens to be the only
> > one with Debia
On Wed, 2015-05-27 at 22:12 +0200, Christoph Anton Mitterer wrote:
> On Wed, 2015-05-27 at 20:50 +0100, Simon McVittie wrote:
> > I don't think ifupdown has been "Debian's native tool" for several years
> > now. It is one among several available tools, and happens to be the only
> > one with Debia
On Wed, 2015-05-27 at 20:50 +0100, Simon McVittie wrote:
> I don't think ifupdown has been "Debian's native tool" for several years
> now. It is one among several available tools, and happens to be the only
> one with Debian as its upstream; on a wheezy-era sysvinit system that
> uses NetworkManag
On 27/05/15 18:41, Christoph Anton Mitterer wrote:
> However, I hope ifupdown is going to live on. Or are there any plans to
> replace Debian's native tool?
I don't think ifupdown has been "Debian's native tool" for several years
now. It is one among several available tools, and happens to be the
On Wed, 2015-05-27 at 12:33 +0200, Marco d'Itri wrote:
> (I am shocked, shocked that there is no flood of people here rushing to
> save ifupdown... :-) )
Perhaps people are just tired of flame wars... (for now...) ;)
However, I hope ifupdown is going to live on. Or are there any plans to
replace
On Wed, May 27, 2015 at 4:18 AM, Russell Stuart
wrote:
> On Wed, 2015-05-27 at 12:33 +0200, Marco d'Itri wrote:
>> (I am shocked, shocked that there is no flood of people here rushing to
>> save ifupdown... :-) )
>
> Until systemd-networkd can run scripts on events no defence is required.
Martin
Marco d'Itri wrote:
I do not expect systemd-networkd taking over NM when an interaction
with
a GUI is needed, but OTOH I see no reason to use NM on servers when
(recent) systemd-networkd is available, since it is much leaner.
In the current state of affairs, that’s pro
On Wed, 2015-05-27 at 19:27 +0800, Paul Wise wrote:
> Your mail is missing some things:
>
> To: 786...@bugs.debian.org
> Control: retitle -1 ITA: ifupdown -- high level tools to configure
> network interfaces
> Control: owner -1 !
If you mean it has been orphaned, it will work for while yet even
On Wed, May 27, 2015 at 7:18 PM, Russell Stuart wrote:
> On Wed, 2015-05-27 at 12:33 +0200, Marco d'Itri wrote:
>> (I am shocked, shocked that there is no flood of people here rushing to
>> save ifupdown... :-) )
>
> Until systemd-networkd can run scripts on events no defence is required.
Your mai
On Wed, 2015-05-27 at 12:33 +0200, Marco d'Itri wrote:
> (I am shocked, shocked that there is no flood of people here rushing to
> save ifupdown... :-) )
Until systemd-networkd can run scripts on events no defence is required.
It would be like comparing a calculator to a computer. Sure, the
calc
On May 27, Paul Wise wrote:
> > a featureful systemd-networkd.
> Will that make NetworkManager obsolete or will there be cases where it
> will still be needed?
I am not sure that there is a clear plan about this: when this question
was asked at FOSDEM the answer was a bit vague. :-)
I do not ex
On Wed, May 27, 2015 at 12:54 AM, Marco d'Itri wrote:
> a featureful systemd-networkd.
Will that make NetworkManager obsolete or will there be cases where it
will still be needed?
--
bye,
pabs
https://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
On Tue, 2015-05-26 at 18:54 +0200, Marco d'Itri wrote:
> On May 26, Andrew Shadura wrote:
>
> > In current state ifupdown is probably good enough for what it is used
> > for, except a few bugs. For advanced uses, it seems, Python-based
> > ifupdown2 may become a good alternative in the future, an
Hello,
On Tue, 26 May 2015 18:54:53 +0200
m...@linux.it (Marco d'Itri) wrote:
> Maybe this is the right time to think hard about what we should do
> about network configuration: Red Hat proposes NM for both desktop and
> servers (even if they still support their legacy shell scripts), and
> in st
On May 26, Andrew Shadura wrote:
> In current state ifupdown is probably good enough for what it is used
> for, except a few bugs. For advanced uses, it seems, Python-based
> ifupdown2 may become a good alternative in the future, and some simpler
> things wicd, NM and systemd-network probably do
X-Debbugs-CC: debian-devel@lists.debian.org
Package: wnpp
Severity: normal
Hello,
This is that time of the year when I finally need to orphan ifupdown
package. It's been quite some time already since I first thought about
this, and I have finally understood I have no intent to maintain this
packa
35 matches
Mail list logo
