Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Wouter Verhelst]

On Fri, Aug 31, 2012 at 09:28:11PM +0300, Serge wrote:
> 2012/8/30 Wouter Verhelst wrote:
> 
> >> How do you suppose it's possible to undo arbitrary network
> >> configuration done by arbitrary set of tools when there's no central
> >> place to hold such information (and can't possibly be)?
> >
> > Actually, the kernel holds that information. Any tool can just query the
> > kernel for information, and decide what to do with what's returned.
> 
> Not sure. Will it work for user-space configuration too? I.e. `ifdown`
> may have have to stop `dhclient` and `wpa_supplicanf`. Is it possible
> to detect such cases automatically?

At the very least it's possible to detect that "a" dhclient or wpa supplicant
is running. As to which interface they're dealing with, that may require
tool-specific code (which would be the case anyway, for other reasons).
I'm not sure, I haven't gotten that far yet :-)

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120902073336.ga29...@grep.be

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Wouter Verhelst]

On Fri, Aug 31, 2012 at 09:56:27AM +0200, Josselin Mouette wrote:
> Le jeudi 30 août 2012 à 22:19 +0200, Wouter Verhelst a écrit : 
> > On Fri, Aug 24, 2012 at 10:44:11AM +0200, Andrew Shadura wrote:
> > > How do you suppose it's possible to undo arbitrary network
> > > configuration done by arbitrary set of tools when there's no central
> > > place to hold such information (and can't possibly be)?
> > 
> > Actually, the kernel holds that information. Any tool can just query the
> > kernel for information, and decide what to do with what's returned.
> 
> Yes it does, but does it hold it in a meaningful, structured way?

Yes.

> In complex setups, for example, there might be no certain way to say
> which interface is related to which route.

wouter@carillon:~$ ip route sh
default via 192.168.64.1 dev wlan0 
169.254.0.0/16 dev tap0  scope link  metric 1000 
172.28.119.2 dev tap0  proto kernel  scope link  src 172.28.119.1 
192.168.10.6 dev tap4  proto kernel  scope link  src 192.168.10.5 
192.168.64.0/24 dev wlan0  proto kernel  scope link  src 192.168.64.184 
wouter@carillon:~$ sudo ip route add 192.168.14.0/24 via 192.168.10.6
wouter@carillon:~$ ip route sh
default via 192.168.64.1 dev wlan0 
169.254.0.0/16 dev tap0  scope link  metric 1000 
172.28.119.2 dev tap0  proto kernel  scope link  src 172.28.119.1 
192.168.10.6 dev tap4  proto kernel  scope link  src 192.168.10.5 
192.168.14.0/24 via 192.168.10.6 dev tap4 
192.168.64.0/24 dev wlan0  proto kernel  scope link  src 192.168.64.184 

As you can see, each and every one of those entries contains a "dev"
line saying which interface the route relates to, even when you add a
route without specifying an interface.

Since you said "complex setup", however, I might miss something. Did you
have something specific in mind?

> Or to tell which low-level interface another interface depends on
> (think tunnels managed by userland tools).

That indeed is slightly more complex. However, provided you know what
the endpoint of the tunnel is, it's not impossible to figure out:

wouter@carillon:~$ ip route get 192.168.14.1
192.168.14.1 via 192.168.10.6 dev tap4  src 192.168.10.5 
cache 

> Actually if there was at least a *standard*, low-level (or in-kernel)
> tool to return structured information about the current network
> configuration,

It's called "netlink", as Ben already pointed out as well.

> maybe high-level network tools (such as ifupdown and NM) could be
> redesigned in a completely different, much more compatible, way.

Really, there's nothing stopping that from happening right now. NM does
use netlink; ifupdown does not. Unfortunately that means ifupdown would
need to be pretty much rewritten; in addition to rewriting the backend
so that it uses netlink, its concepts are way too far away from the
dynamicity that would be required to do the kind of stuff I'm
describing.

Such a rewrite is pretty much what I've started to do with ipcfg, fwiw.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120901101747.gb18...@grep.be

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Bjørn Mork]

Serge  writes:
> 2012/8/30 Wouter Verhelst wrote:
>
>>> How do you suppose it's possible to undo arbitrary network
>>> configuration done by arbitrary set of tools when there's no central
>>> place to hold such information (and can't possibly be)?
>>
>> Actually, the kernel holds that information. Any tool can just query the
>> kernel for information, and decide what to do with what's returned.
>
> Not sure. Will it work for user-space configuration too? I.e. `ifdown`
> may have have to stop `dhclient` and `wpa_supplicanf`. Is it possible
> to detect such cases automatically?

If you start dhclient or wpa_supplicant on ifup, then you naturally need
to query and deconfigure those tools on ifdown too.  There is a perfect
symmetry here:

 "up" use rtnetlink => "down" queries/deconfigures rtnetlink
 "up" use wpa_supplicant => "down" queries/deconfigures wpa_supplicant
 "up" use dhclient => "down" queries/deconfigures dhclient
 "up" use pppd => "down" queries/deconfigures pppd

etc.  Layered combinations of the above is of course common and must be
supported.

But I fail to see the point of this discussion.  Post patches for NM
and/or ifupdown implementing the features you'd like to see.  No need
for all the theoretical mumbo-jumbo, implying that someone else should
do the job.


Bjørn


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vcu3yhi@nemi.mork.no

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Serge]

2012/8/28 Ben Hutchings wrote:

>> It should not be that hard to fit them all.
>>
>> All connections I can think of belong to one of two categories:
>> 1. Permanent connections. Those are "setup-and-forget" connections.
>> Typical for servers and wired desktops. Can be managed with ifupdown.
>> 2. Temporary connections. Those are "use-once-and-forget" connections
>> (e.g. wifi in airport/hotel). Typical for mobile/moveable devices.
>> They're different from #1 because they should not be stored in configs.
> [...]
>
> I don't think there is this hard line between 'permanent' and
> 'temporary' connections.

It depends on what one calls "permanent".

It was just about whether it's possible to write a tool to please
everybody. And I was thinking how to do that. I suggested to split
all connections into two categories: "permanent" (stored in confis,
i.e. "setup-and-forget") and "temporary" (not stored in configs, i.e.
"use-once-and-forget"). Maybe I chose ambiguous names for those
categories, feel free to suggest any better. :)

There're also two interface types: CLI and GUI.
So that would be 4 ways to make a connection:
1.a. Permanent-CLI (ifupdown or a shell-script)
1.b. Permanent-GUI (NetworkManager)
2.a. Temporary-CLI (shell)
2.b. Temporary-GUI (NetworkManager)

None of tools support all 4 points good enough _yet_, that's why none
of them suits everybody. What I was trying to say is that it's still
possible to extend any of them to "fit them all", somebody just need
to extend it to support all 4 kinds.

Such tool, if existed, should please everybody. :)

> Hotel wifi certainly isn't 'use-once-and-forget'. I should be able to
> configure it when I arrive and have it remembered as long as I stay.

It does not matter how often you use it. It's just whether you store
it in configs (that's what I called "permanent") or not ("temporary").

> There are several other categories of dynamic connections, including:
> 3. VPN tunnels (server end)
> 4. Connections to a VM
>
> Most likely these should not be managed by either ifupdown or NM.

Not currently, right. But if someone could extend some of them to
support these, why not? Imagine a GUI/TUI (winetricks-like) front-end
for ifupdown, that allows you to configure VPN with a few simple
dialogs and store basic configs in /etc. :) If only someone wrote it...

-- 
  Serge


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caoveneqbs6wmz0xya0epoammxmvzsgqz7-xaszb_yalekcx...@mail.gmail.com

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Serge]

2012/8/30 Wouter Verhelst wrote:

>> How do you suppose it's possible to undo arbitrary network
>> configuration done by arbitrary set of tools when there's no central
>> place to hold such information (and can't possibly be)?
>
> Actually, the kernel holds that information. Any tool can just query the
> kernel for information, and decide what to do with what's returned.

Not sure. Will it work for user-space configuration too? I.e. `ifdown`
may have have to stop `dhclient` and `wpa_supplicanf`. Is it possible
to detect such cases automatically?

-- 
  Serge


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caoveneqgmo76fz-ccrpnc0rmi5hdcy7tkr6qs+h0ssknxmr...@mail.gmail.com

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Ben Hutchings]

On Fri, 2012-08-31 at 09:56 +0200, Josselin Mouette wrote:
> Le jeudi 30 août 2012 à 22:19 +0200, Wouter Verhelst a écrit : 
> > On Fri, Aug 24, 2012 at 10:44:11AM +0200, Andrew Shadura wrote:
> > > How do you suppose it's possible to undo arbitrary network
> > > configuration done by arbitrary set of tools when there's no central
> > > place to hold such information (and can't possibly be)?
> > 
> > Actually, the kernel holds that information. Any tool can just query the
> > kernel for information, and decide what to do with what's returned.
> 
> Yes it does, but does it hold it in a meaningful, structured way? In
> complex setups, for example, there might be no certain way to say which
> interface is related to which route.

I wish you would give an example.

> Or to tell which low-level
> interface another interface depends on (think tunnels managed by
> userland tools).

You're thinking about packet forwarding in userland?

> Actually if there was at least a *standard*, low-level (or in-kernel)
> tool to return structured information about the current network
> configuration, maybe high-level network tools (such as ifupdown and NM)
> could be redesigned in a completely different, much more compatible,
> way.

The kernel API is called rtnetlink (or NETLINK_ROUTE) and NM already
uses it.  Not all device relationships are properly represented through
it yet, but people are working on it.

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of comp.compilers


signature.asc
Description: This is a digitally signed message part

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Josselin Mouette]

Le jeudi 30 août 2012 à 22:19 +0200, Wouter Verhelst a écrit : 
> On Fri, Aug 24, 2012 at 10:44:11AM +0200, Andrew Shadura wrote:
> > How do you suppose it's possible to undo arbitrary network
> > configuration done by arbitrary set of tools when there's no central
> > place to hold such information (and can't possibly be)?
> 
> Actually, the kernel holds that information. Any tool can just query the
> kernel for information, and decide what to do with what's returned.

Yes it does, but does it hold it in a meaningful, structured way? In
complex setups, for example, there might be no certain way to say which
interface is related to which route. Or to tell which low-level
interface another interface depends on (think tunnels managed by
userland tools).

Actually if there was at least a *standard*, low-level (or in-kernel)
tool to return structured information about the current network
configuration, maybe high-level network tools (such as ifupdown and NM)
could be redesigned in a completely different, much more compatible,
way.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1346399787.3479.451.camel@pi0307572

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Wouter Verhelst]

On Fri, Aug 24, 2012 at 10:44:11AM +0200, Andrew Shadura wrote:
> How do you suppose it's possible to undo arbitrary network
> configuration done by arbitrary set of tools when there's no central
> place to hold such information (and can't possibly be)?

Actually, the kernel holds that information. Any tool can just query the
kernel for information, and decide what to do with what's returned.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120830201911.gc14...@grep.be

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[gregor herrmann]

On Wed, 29 Aug 2012 13:47:00 +0200, Vincent Lefevre wrote:

> > > There's also usbnet, which is used when I connect my Nokia N900 to
> > > my laptop. There must also be a fixed setup, but I haven't found a
> > > solution to recognize my N900 with ifupdown (the MAC address changes
> > > too often).
> > http://wiki.openmoko.org/wiki/Plug-and-Play_USB_Networking
> > https://bugzilla.gnome.org/show_bug.cgi?id=675973
> I don't see how the NM script can recognize which one is connected.
> If this is by comparing the MAC address, then this won't work with
> the N900: as I've said, the MAC address of the N900 changes too
> often.

I'm using a similar setup plus udev to distinguish between the
network devices of my openmoko and my n900:

from /etc/network/interfaces:

# n900
allow-hotplug n900
iface n900 inet static
address ...

# freerunner
allow-hotplug openmoko
iface openmoko inet static
address ...

from a custom udev rule:

# n900
SUBSYSTEM=="net", ACTION=="add", DEVPATH=="*/net/usb[0-9]", 
ATTRS{idVendor}=="0421", ATTRS{idProduct}=="01c8", 
ATTRS{manufacturer}=="Nokia", ATTRS{product}=="N900 (PC-Suite Mode)", 
NAME="n900"

# freerunner
SUBSYSTEM=="net", ACTION=="add", ATTRS{idVendor}=="0525", 
ATTRS{idProduct}=="a4a2", ATTRS{product}=="RNDIS/Ethernet Gadget", 
NAME="openmoko"


Cheers,
gregor
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: U2: If God Would Send His Angels


signature.asc
Description: Digital signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Vincent Lefevre]

On 2012-08-29 19:17:36 +0800, Paul Wise wrote:
> On Wed, Aug 29, 2012 at 5:46 PM, Vincent Lefevre wrote:
> > There's also usbnet, which is used when I connect my Nokia N900 to
> > my laptop. There must also be a fixed setup, but I haven't found a
> > solution to recognize my N900 with ifupdown (the MAC address changes
> > too often).
> 
> I'm using the NM script from here for that:
> 
> http://wiki.openmoko.org/wiki/Plug-and-Play_USB_Networking
> https://bugzilla.gnome.org/show_bug.cgi?id=675973

I don't see how the NM script can recognize which one is connected.
If this is by comparing the MAC address, then this won't work with
the N900: as I've said, the MAC address of the N900 changes too
often.

There's a limitation with ifupdown + guessnet: it is not possible
to AND two tests (e.g. one test on the peer IPv4 address, then
another test to check the device if the first test succeeds).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120829114700.gl19...@xvii.vinc17.org

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Paul Wise]

On Wed, Aug 29, 2012 at 5:46 PM, Vincent Lefevre wrote:

> There's also usbnet, which is used when I connect my Nokia N900 to
> my laptop. There must also be a fixed setup, but I haven't found a
> solution to recognize my N900 with ifupdown (the MAC address changes
> too often).

I'm using the NM script from here for that:

http://wiki.openmoko.org/wiki/Plug-and-Play_USB_Networking
https://bugzilla.gnome.org/show_bug.cgi?id=675973

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6FfN=d+--rg7asvv9jozogmpoua0tnklfycotd4lh_...@mail.gmail.com

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Vincent Lefevre]

On 2012-08-28 22:41:38 +0300, Serge wrote:
> All connections I can think of belong to one of two categories:
> 1. Permanent connections. Those are "setup-and-forget" connections.
> Typical for servers and wired desktops. Can be managed with ifupdown.
> 2. Temporary connections. Those are "use-once-and-forget" connections
> (e.g. wifi in airport/hotel). Typical for mobile/moveable devices.
> They're different from #1 because they should not be stored in configs.

No, there are also semi-permanent connections. For instance, the ADSL
connection for my laptop at home. It isn't permanent because my laptop
is not always at home. So, I need ifupdown + guessnet (to check the
MAC address of the router) + netplug.

There's also usbnet, which is used when I connect my Nokia N900 to
my laptop. There must also be a fixed setup, but I haven't found a
solution to recognize my N900 with ifupdown (the MAC address changes
too often).

Also, how to dynamically set the route (e.g. via eth0 or via usb0
[thanks to 3G connection on the other side] depending on some
conditions) is unclear.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120829094612.gj19...@xvii.vinc17.org

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Ben Hutchings]

On Tue, 2012-08-28 at 22:41 +0300, Serge wrote:
> 2012/8/20 Noel David Torres Taño wrote:
> 
> > Have you all minded that there are several *different* use cases?
> >
> > * Laptop user going here and there, sometimes with Wireless, sometimes
> > with cable, sometimes with USB stick
> > * Desktop user with home ADSL
> > * Server with several connections
> >
> > Each use case has its own needs, and its own best tools.
> >
> > No ifupdown nor NM will fit them all, ever.
> 
> It should not be that hard to fit them all.
> 
> All connections I can think of belong to one of two categories:
> 1. Permanent connections. Those are "setup-and-forget" connections.
> Typical for servers and wired desktops. Can be managed with ifupdown.
> 2. Temporary connections. Those are "use-once-and-forget" connections
> (e.g. wifi in airport/hotel). Typical for mobile/moveable devices.
> They're different from #1 because they should not be stored in configs.
[...]

I don't think there is this hard line between 'permanent' and
'temporary' connections.  Hotel wifi certainly isn't
'use-once-and-forget'.  I should be able to configure it when I arrive
and have it remembered as long as I stay.  But I could imagine having a
'temporary' checkbox that causes it to expire if unused for a week.

I also have multiple wired Ethernet configurations in Network Manager,
and choose which one I want after inserting the cable.

There are several other categories of dynamic connections, including:
3. VPN tunnels (server end)
4. Connections to a VM

Most likely these should not be managed by either ifupdown or NM.

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education. - Albert Einstein


signature.asc
Description: This is a digitally signed message part

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Serge]

2012/8/20 Noel David Torres Taño wrote:

> Have you all minded that there are several *different* use cases?
>
> * Laptop user going here and there, sometimes with Wireless, sometimes
> with cable, sometimes with USB stick
> * Desktop user with home ADSL
> * Server with several connections
>
> Each use case has its own needs, and its own best tools.
>
> No ifupdown nor NM will fit them all, ever.

It should not be that hard to fit them all.

All connections I can think of belong to one of two categories:
1. Permanent connections. Those are "setup-and-forget" connections.
Typical for servers and wired desktops. Can be managed with ifupdown.
2. Temporary connections. Those are "use-once-and-forget" connections
(e.g. wifi in airport/hotel). Typical for mobile/moveable devices.
They're different from #1 because they should not be stored in configs.

So one tool supporting both of these connections will suit them all. :)
It does not matter what tool it is. It can be some kind of ifupdown GUI
with temporary connections support (just connect without storing configs).
Or it can be NetworkManager, that uses some ifupdown plugin to store
permanent connections.

For advanced users/developers/hackers there's already a tool that fits
them all - console. They can manually configure permanent connections
there. And they can manually run temporary connections there too.
It's easy, usually one command is enough to do that. For example:
DHCP: dhclient eth0
DSL: pppd plugin rp-pppoe.so eth0 user  password 
defaultroute usepeerdns
VPN: pppd defaultroute user  password  pty "pptp
12.34.56.78 --nolaunchpppd"
WIFI: wpa_supplicant -c /tmp/mynetwork.conf
I was able to bring up GPRS USB stick with one (long) pppd command once,
but can't find it right now.

I mean, there's already a "tool" (console) that suit many "smart" users.
To "fit them all" the only thing missing is some GUI with ifupdown support
for "regular" users. But it's not impossible to write one.

PS: I'm dreaming about writing such a tool for a few years already
(something simple, winetricks-like GUI bash script for creating
temporaty connections and then optionally storing them permanently),
just had no time to actually do that, directly running dhclient, pppd
or wpa_supplicant was usually enough for me. Maybe someone else
will eventually write one...

PPS: writing here in case someone else with a lot of free time may
like the idea and implement it. :)

-- 
  Serge


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caovenerq_u4olj+heka3rz0xvsxrtsbbpod-_mc0k33zff+...@mail.gmail.com

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Vincent Lefevre]

On 2012-08-24 15:03:49 +0100, Ben Hutchings wrote:
> On Fri, 2012-08-24 at 10:44 +0200, Andrew Shadura wrote:
> > Hello,
> > 
> > On Mon, 20 Aug 2012 14:51:27 +0100
> > Ben Hutchings  wrote:
> > 
> > > What I mean is that this still happens:
> > 
> > > # ifup eth0
> > > ...
> > > # ifconfig eth0 down
> > > # ifup eth0
> > > ifup: interface eth0 already configured
> > 
> > Why should it happen otherwise? You did *NOT* deconfigure the interface.
> 
> It certainly isn't in the state that 'ifup' put it the first time.  I
> want it back in that state now, why won't it do that?

Anyway even if one just uses ifup/ifdown (not ifconfig), one can
get an inconsistent state (and not fixable by ifupdown).

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685500

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120826194555.gb19...@xvii.vinc17.org

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Vincent Lefevre]

On 2012-08-20 13:08:53 +0200, Bjørn Mork wrote:
> Why do you install gnome-core if you don't want the resulting
> package mess?

If it isn't that important, I think the word "essential" shouldn't
be used.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120826192425.ga19...@xvii.vinc17.org

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Ben Hutchings]

On Fri, Aug 24, 2012 at 04:18:12PM +0200, Andrew Shadura wrote:
> Hello,
> 
> On Fri, 24 Aug 2012 15:03:49 +0100
> Ben Hutchings  wrote:
> 
> > There is, it's called the kernel.
> 
> No, there isn't, and there can't possibly be, as interface's
> configuration isn't only what ifconfig/route/ip reports to you (which
> is what kernel knows about it).

What elements of interface state are you thinking of, then?

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120824161942.gr29...@decadent.org.uk

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Andrew Shadura]

Hello,

On Fri, 24 Aug 2012 15:03:49 +0100
Ben Hutchings  wrote:

> There is, it's called the kernel.

No, there isn't, and there can't possibly be, as interface's
configuration isn't only what ifconfig/route/ip reports to you (which
is what kernel knows about it).

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Ben Hutchings]

On Fri, 2012-08-24 at 10:44 +0200, Andrew Shadura wrote:
> Hello,
> 
> On Mon, 20 Aug 2012 14:51:27 +0100
> Ben Hutchings  wrote:
> 
> > What I mean is that this still happens:
> 
> > # ifup eth0
> > ...
> > # ifconfig eth0 down
> > # ifup eth0
> > ifup: interface eth0 already configured
> 
> Why should it happen otherwise? You did *NOT* deconfigure the interface.

It certainly isn't in the state that 'ifup' put it the first time.  I
want it back in that state now, why won't it do that?

> > People talk about how ifupdown works well with other configuration
> > tools, unlike Network Manager.  But it doesn't, it only knows how to
> > undo the configuration specified in /etc/network/interfaces.
> 
> ...and NM can't do anything at all which it doesn't know about.
> 
> How do you suppose it's possible to undo arbitrary network
> configuration done by arbitrary set of tools when there's no central
> place to hold such information (and can't possibly be)?

There is, it's called the kernel.

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones.


signature.asc
Description: This is a digitally signed message part

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Andrew Shadura]

Hello,

On Mon, 20 Aug 2012 16:21:18 +0200
Mike Hommey  wrote:

> > People talk about how ifupdown works well with other configuration
> > tools, unlike Network Manager.  But it doesn't, it only knows how to
> > undo the configuration specified in /etc/network/interfaces.

> ifupdown should be the only way to configure network interfaces.
> Debian should get rid of NM, ifconfig, ip, and all the other heretic
> programs that break ifupdown.

Haha, how clever and funny. And now please go and write you own
NetConfNG which handles all the possible situations, ever. Or maybe you
know any which does that already? I'm not aware of it.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Andrew Shadura]

Hello,

On Mon, 20 Aug 2012 14:51:27 +0100
Ben Hutchings  wrote:

> What I mean is that this still happens:

> # ifup eth0
> ...
> # ifconfig eth0 down
> # ifup eth0
> ifup: interface eth0 already configured

Why should it happen otherwise? You did *NOT* deconfigure the interface.

> People talk about how ifupdown works well with other configuration
> tools, unlike Network Manager.  But it doesn't, it only knows how to
> undo the configuration specified in /etc/network/interfaces.

...and NM can't do anything at all which it doesn't know about.

How do you suppose it's possible to undo arbitrary network
configuration done by arbitrary set of tools when there's no central
place to hold such information (and can't possibly be)?

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Ben Hutchings]

On Mon, 2012-08-20 at 02:07 +0200, Christoph Anton Mitterer wrote:
> Hey Ben.
> 
> 
> On Sun, 2012-08-19 at 19:32 +0100, Ben Hutchings wrote:
> > To allow users to connect to the NetworkManager daemon they have to be in 
> > the
> > group "netdev".
> Like Vincent already pointed out, CK allows it, too.

Oops, yes, good point.

> In principle nothing speaks generally against either of the two, but I
> guess both of them are just intended towards "who is allowed to connect
> to networks"; either by being member of the group, or by being locally
> logged on (CK).
> But when I e.g. put WPA credentials into /e/n/interfaces and made the
> file specifically readable by root and user foo only, then it still
> exports that connection to all other users (e.g. being logged on
> locally; at least per default).
> 
> 
> > The capability to *use* credentials is separate from the capability to
> > *read* the credentials.
> Well nevertheless, both can be dangerous already, can't it?

Of course.

> Even if it just allows me to use (i.e. connect to) some WLAN but not
> giving me the actual key, I might be able to access some resources
> there, that ought to be secure.

This is also true if you can run a process on the machine while that
WLAN connection is up.  Because the capability to use a network
connection that's already up is another thing again...

> > (Also, the design choice to read credentials from a file that is world-
> > readable by default is incredibly stupid, and you may wish to report
> > bugs on the packages that do that.)
> I don't exactly understand what you mean :)

I'm saying that reading credentials from /etc/network/interfaces is
probably a bug.  In the 'bug' script for Linux kernel packages we have
this filter:

  # Hide passwords/keys
  awk '$1 ~ /key|pass|^wpa-(anonymous|identity|phase|pin|private|psk)/ { 
gsub(".", "*", $2); }
   $1 == "ethtool-wol" { gsub(".", "*", $3); }
   !/^[[:space:]]*\#/ { print; }
  ' &3

I can't remember quite how I came up with this list... I assume the
wpa-* fields were previously used by wpa_supplicant hooks, but that
doesn't seem to be the case any more.  wireless-tools still uses
wireless-key{1,2,3,4}.  For ethtool-wol (wake-on-LAN) there is an
optional 'SecureOn password' for Magic Packet mode.  This is a little
bit different from the others but I probably should still add the option
to read it from a separate file.

[...]
> > ifupdown *was* a good framework, but Linux moved on.  ifupdown doesn't
> > know anything about interface state.
> What exactly do you mean by "state"?

ifupdown records whether an interface has been brought up using a
particular configuration (referenced by name).  If you change the state
using anything other tool, it has no idea.  If the driver reports a
change of state, it doesn't react.  If you change or remove the
configuration, it doesn't even know how to bring the interface down
again!  (That last one should be fixable, by storing the configuration
along with the 'up' state file.)

Pretty much all it does is to run a pre-defined 'up' or 'down' sequence.
Even once it can reliably report failure, I suspect it won't know how to
roll back.

> But anyway,.. it doesn't seem as if it would go away anytime soon,...
> and NM is AFAICS surely not a powerful enough replacement.

Not yet, no.

> > It doesn't know whether hooks
> > succeeded and it can't check for failures because that would be an
> > incompatible change (#547587).
> Sometimes one have to break compatibility ;-)

Yes, and I absolutely support this change.  It's just a shame that it's
taken such a long to be recognised as necessary.

[...]
> > I would really like to see Debian developers working to improve Network
> > Manager so it can replace ifupdown.  For example, improving the command
> > line interface and support for various types of software devices.
> > Unfortunately, I don't have the spare time to make much of a
> > contribution to that myself.  (I do install ifupdown hooks as part of
> > ethtool, so I'll have to think about those.)
> If all that ever happens,... fine (though I like ifupdown and personally
> don't see the need for replacing it),... but it's surely a long road to
> it and has the big disadvantage that we (Debian) are then more or
> less bound to what NM (and other distros) do.
> Sometimes it's good of course, having homogeneous frameworks across
> distros,... but this can also be bad.

By the same token, we should have our own kernel, C library, etc.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow Lindberg


signature.asc
Description: This is a digitally signed message part

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Paul Wise]

On Mon, 2012-08-20 at 09:18 +0200, martin f krafft wrote:

> Or get it working properly with Python, make use of the simplicity
> of interpreted languages until the design is actually proven to
> work, and then rewrite it…

Ah, I thought it was further along than that.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Stephan Seitz]

On Mon, Aug 20, 2012 at 02:19:19PM +0200, Bjørn Mork wrote:

Stephan Seitz  writes:

On Mon, Aug 20, 2012 at 01:08:53PM +0200, Bjørn Mork wrote:

Never mind wireless lan where you've got a well defined kernel API.  Try
to configure a modern 3G/LTE modem using ifupdown, and you will see the

Is this something different from an UMTS usbstick?

[Good explanation snipped]

Thank you very much.


But yes, if „pon umts” is enough for you then you don't need NM (or even
ifupdown - pppd and vim will do).


Right, that is enough for me. I use the UMTS stick only in the holidays 
about three weeks each year. And I’m glad I will get GPRS in the Austrian 
mountains. Different LED colours show me the kind of connection.


It seems I have to be careful if I have to buy a new one.

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Noel David Torres Taño]

Have you all minded that there are several *different* use cases?

* Laptop user going here and there, sometimes with Wireless, sometimes with 
cable, sometimes with USB stick
* Desktop user with home ADSL
* Server with several connections

Each use case has its own needs, and its own best tools.

No ifupdown nor NM will fit them all, ever.

Regards

Noel Torres
er Envite


signature.asc
Description: This is a digitally signed message part.

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Ben Hutchings]

On Mon, Aug 20, 2012 at 04:21:18PM +0200, Mike Hommey wrote:
> On Mon, Aug 20, 2012 at 02:51:27PM +0100, Ben Hutchings wrote:
> > What I mean is that this still happens:
> > 
> > # ifup eth0
> > ...
> > # ifconfig eth0 down
> > # ifup eth0
> > ifup: interface eth0 already configured
> > 
> > People talk about how ifupdown works well with other configuration
> > tools, unlike Network Manager.  But it doesn't, it only knows how to
> > undo the configuration specified in /etc/network/interfaces.
> 
> ifupdown should be the only way to configure network interfaces. Debian
> should get rid of NM, ifconfig, ip, and all the other heretic programs
> that break ifupdown.

Unfortunately they are needed by ifupdown itself.  So instead we need
to have a mechanism in the kernel to refuse network configuration
that's not done by a child process of ifupdown.  Then you will have
to put all network configuration in ifupdown hook scripts.  Routing
daemons will not be supported, but they only cause confusion anyway.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120820155253.gf29...@decadent.org.uk

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Bernd Zeimetz]

On 08/20/2012 01:54 AM, Paul Wise wrote:
> Please take over the netconf project and start implementing that
> design in C, that would be much more productive than any new thread
> about the current and previous deficiencies of NetworkManager.

Or just file bugs against ifupdown, the (new) upstream seems to be
pretty active these days.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/503259b9.1040...@bzed.de

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Mike Hommey]

On Mon, Aug 20, 2012 at 02:51:27PM +0100, Ben Hutchings wrote:
> What I mean is that this still happens:
> 
> # ifup eth0
> ...
> # ifconfig eth0 down
> # ifup eth0
> ifup: interface eth0 already configured
> 
> People talk about how ifupdown works well with other configuration
> tools, unlike Network Manager.  But it doesn't, it only knows how to
> undo the configuration specified in /etc/network/interfaces.

ifupdown should be the only way to configure network interfaces. Debian
should get rid of NM, ifconfig, ip, and all the other heretic programs
that break ifupdown.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120820142118.ga22...@glandium.org

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Ben Hutchings]

On Mon, 2012-08-20 at 00:04 +0200, Andrew Shadura wrote:
> Hello,
> 
> On Sun, 19 Aug 2012 19:32:03 +0100
> Ben Hutchings  wrote:
> 
> > > 3) ifupdown integration is really bad
> > > ifupdown is really a good framework, it offers hooks and and is
> > > properly integrated in many packages.
> 
> > ifupdown *was* a good framework, but Linux moved on.  ifupdown doesn't
> > know anything about interface state.
> 
> Why should it? It's a configuration tool, not a monitoring one. If
> monitoring is needed, a different tool can be developed which would
> perfectly integrate into ifupdown... but nobody has needed that yet?
[...]

What I mean is that this still happens:

# ifup eth0
...
# ifconfig eth0 down
# ifup eth0
ifup: interface eth0 already configured

People talk about how ifupdown works well with other configuration
tools, unlike Network Manager.  But it doesn't, it only knows how to
undo the configuration specified in /etc/network/interfaces.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow Lindberg


signature.asc
Description: This is a digitally signed message part

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[martin f krafft]

also sprach Paul Wise  [2012.08.20.0154 +0200]:
> Please take over the netconf project and start implementing that
> design in C,

Or get it working properly with Python, make use of the simplicity
of interpreted languages until the design is actually proven to
work, and then rewrite it…

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
quantum mechanics: the dreams stuff is made of.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Bjørn Mork]

Stephan Seitz  writes:
> On Mon, Aug 20, 2012 at 01:08:53PM +0200, Bjørn Mork wrote:
>>Never mind wireless lan where you've got a well defined kernel API.  Try
>>to configure a modern 3G/LTE modem using ifupdown, and you will see the
>
> Is this something different from an UMTS usbstick?

No.

> I plug it in, get a
> /dev/ttypUSB0 and do a „pon umts”. No need for NM and Co.

Sure. But you didn't actually configure the device here, did you?  And
you didn't notice that the device fell back from LTE to UTMS.  Or that
it suddenly started roaming to the network on the other side of the
border. Etc.

You didn't even notice that the connection failed because the PIN code
was wrong.  Or did you?  OK, then your chat script has started looking
like a small ModemManager application...

Oh, yeah, and of course /dev/ttyUSB0 wasn't the AT port.  It was the
QCDM port so the chat script just timed out.

The connections provided by these devices are dynamic by nature, and
they typically have management protocols supporting notifications from
device to host.  You may of course ignore this and state that the device
"works" in a static configuration, but most users will want some
monitoring daemon allowing them to make intelligent decisions based on
current available devices and networks.  A little like what
wpa_supplicant does for wireless LANs. That's what ModemManager
provides.

But yes, if „pon umts” is enough for you then you don't need NM (or even
ifupdown - pppd and vim will do).

By modern 3G/LTE modem I mean a device supporting CDC MBIM or a vendor
specific management protocol like QMI.  The firmware of most of these
devices will export a basic AT command set and support PPP on one or
more serial ports, but that only supports a very limited usage pattern
IMHO.  And when it comes to LTE, also limited speed.  Some vendors
implement AT commands for initiating "NDIS" connections, but these are
exceptions and are likely to go away over time as more and more devices
get a "intented for Windows 8" label or somthing like that.  And it
didn't work with your "pon" in any case.


Bjørn


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pq6liwmw@nemi.mork.no

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Marco d'Itri]

On Aug 20, Stephan Seitz  wrote:

> On Mon, Aug 20, 2012 at 01:08:53PM +0200, Bjørn Mork wrote:
> >Never mind wireless lan where you've got a well defined kernel API.  Try
> >to configure a modern 3G/LTE modem using ifupdown, and you will see the
> Is this something different from an UMTS usbstick? I plug it in, get
Often they are, you can learn way more than you ever wanted to know 
about this by quickly looking at the modemmanager sources. Next?  
-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Stephan Seitz]

On Mon, Aug 20, 2012 at 01:08:53PM +0200, Bjørn Mork wrote:

Never mind wireless lan where you've got a well defined kernel API.  Try
to configure a modern 3G/LTE modem using ifupdown, and you will see the


Is this something different from an UMTS usbstick? I plug it in, get 
a /dev/ttypUSB0 and do a „pon umts”. No need for NM and Co.


Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Bjørn Mork]

Christoph Anton Mitterer  writes:
> On Sun, 2012-08-19 at 19:41 +0200, Marco d'Itri wrote:
>> NM, as a design goal, is not supposed to be able to manage every 
>> possible configuration.
> Well but then it shouldn't be kind of a default package.

No it shouldn't.  And it isn't either.  gnome-core is not default.

> And yes, I
> know, strictly speaking it's neither required nor essential.
> But as I mentioned before, more and more uses it... and one usually
> get's it already with gnome-core.

Except for GNOME, what other unrelated packages depends on NM?

The GNOME dependencies are deliberately broken to bring in as much cruft
as possible, but GNOME is neither required nor default so what's the
problem?  Why do you install gnome-core if you don't want the resulting
package mess?

> And to be honest, I don't think that it's impossible that NM would
> integrate well with ifupdown (and the others).

I believe it already does.  Any problems with this integration should be
reported as bugs.

Neither NM nor ifupdown is currently capable of dealing with every
possible networking setup (NM fails on complex static configurations,
ifupdown fails on dynamic stateful configurations).  And I expect this
is how it will be for the foreseeable future.  At least that's how I
understand the current scopes of those packages.

Debian need *both*, and any efforts in this area should be put into
making them interoperate.

Never mind wireless lan where you've got a well defined kernel API.  Try
to configure a modern 3G/LTE modem using ifupdown, and you will see the
usefulness of a framework like NM and it's companion ModemManager. Yes,
there are of course bugs and missing features. But let's fix them then.
NM upstream is very active and easy to co-operate with.

And before someone asks: There won't be any "standard wireless
extensions" for wan connections. That sort of thing is just not
considered appropriate for the kernel anymore. Drivers export the device
native control channel(s), and leave the rest of the job for userspace
libraries.  This means that you will need something like ModemManager,
oFono or similar to provide a common device independent application
interface.


Bjørn


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871uj1kegq@nemi.mork.no

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Chris Knadle]

On Monday, August 20, 2012 03:29:05, Stephan Seitz wrote:
> On Sun, Aug 19, 2012 at 07:59:00PM -0400, Chris Knadle wrote:
> >Related note: I likewise repeatedly have confusion over how to deal with
> >testing Network Status from within shell scripts for doing operations that
> >require network access.  As a "for instance" a common suggestion for
> >keeping GPG keys up to date is to set a 'gpg --referesh-keys' operation
> >as a cron job, which doesn't make sense to do if the device the script is
> >run on is offline,
> 
> And how do you want to do this check? Even if ethtool says, the interface
> is up, this doesn’t mean, your DSL router has a WAN connection running.
> And if it has, it doesn’t mean you can reach the keyserver.
> 
> So you can use something like „fping -q ”, if the keyserver is
> pingeable. Any other check is not really usefull.

Basically you've got the idea of what I'm doing.

~/bin/gpg-refresher
---
# (this setting pulled in from a config file)
PING_LOCATION=www.yahoo.com  #(actual location should = keyserver location)
#
ping -c 3 $PING_LOCATION > /dev/null
if [ "$?" -ne "0" ]; then
  exit
fi
gpg --refresh-keys -o - 2>&1 | fgrep -v -e "requesting key" \
  -e " not changed" -e "Total number processed: " -e " unchanged: " \
  -e " keys processed so far" -e " next trustdb check due at" \
  | egrep -v -e "refreshing .* keys from " \
  -e "key .* not found on keyserver" \
  -e "^gpg: depth: .*" -e " trust model$"


  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


signature.asc
Description: This is a digitally signed message part.

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Stephan Seitz]

On Sun, Aug 19, 2012 at 07:59:00PM -0400, Chris Knadle wrote:

Related note: I likewise repeatedly have confusion over how to deal with
testing Network Status from within shell scripts for doing operations that
require network access.  As a "for instance" a common suggestion for keeping
GPG keys up to date is to set a 'gpg --referesh-keys' operation as a cron job,
which doesn't make sense to do if the device the script is run on is offline,


And how do you want to do this check? Even if ethtool says, the interface 
is up, this doesn’t mean, your DSL router has a WAN connection running.  
And if it has, it doesn’t mean you can reach the keyserver.


So you can use something like „fping -q ”, if the keyserver is 
pingeable. Any other check is not really usefull.


Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


signature.asc
Description: Digital signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Wouter Verhelst]

On Sun, Aug 19, 2012 at 07:59:00PM -0400, Chris Knadle wrote:
> The first suggestion I have is to look at Wouter Verhelst's 'ipcfg' project
> [1],

Thanks :-)

> which he gave a talk about on the last day of DebConf12 [2], and which is
> currently a work-in-progress, thus making it a good time for this kind of
> input. His plan for the project addresses many of the typical complaints about
> NM, as well as other network managers, and I think he's got some very
> interesting ideas and thoughts about the problems you've described.

It's nowhere near ready yet, however. Last week was the first time I
managed to do anything on ipcfg since debconf (hey, I have a life, too).

_Maybe_ I'll get this to a somewhat working state for Jessie, but that's
by no means certain.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120820065624.ga4...@grep.be

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Vincent Bernat]

 ❦ 20 août 2012 04:07 CEST, Guillem Jover  :

>> But also:
>> 
>>   Alternatively you can install the "consolekit" package which will
>>   grant access for all locally logged in users.
>
> ConsoleKit has already been dropped and deprecated by upstream:
>
>   

But we will keep it a looonnng time in Debian otherwise, we won't be
able to propose a working desktop environment.
-- 
printk("ufs_read_super: fucking Sun blows me\n");
2.0.38 /usr/src/linux/fs/ufs/ufs_super.c


pgpC6U9h9zPJ4.pgp
Description: PGP signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Chris Knadle]

On Sunday, August 19, 2012 20:41:47, Michael Biebl wrote:
[…]
> I won't bother following up as I'm really tired of all this BS on
> debian-devel regarding NM lately. Sorry.
> My guess is, that this will be another of those pointless NM bashing
> threads, where nothing useful comes out of it. Actually I'm not sure
> what the point of this thread is, but it definitely managed to piss me
> off, the maintainer of network-manager, and I'm not going to further
> participate.

I'm sorry you're feeling hurt from the NM criticism.  I'm confident that 
nobody had any intent of hurting your feelings.

Whatever opinions I or others my have about NM are about the software is 
mostly about the software that comes from upstream -- which has nothing to do 
with you directly, so /please/ try not to take this personally.  Also this 
thread started mainly about *other* packages that pull in network-manager as a 
dependency, which doesn't even have to do with the network-manager package 
itself.  NM is just one part of a larger "meta issue" going on concerning 
coordination /between/ various packages.

There's a natural tendency to have an emotional attachment and pride one's 
work.  In the case of Debian packaging the maintainer gets to have a lot of 
input on how the package gets installed and might have /some/ control over the 
software's default behavior, but to a large extent it seems to me the 
maintainer only has minimal control over how the software actually works, 
because that comes from upstream and it's specifically /not/ the packager's 
task to implement major design changes to it.

I therefore think taking criticism about the /software itself/ that a 
maintainer packaged /personally/ is a harsh self-judgment, especially if 
there's not much a maintainer can actually /do/ about the perceived design 
failings that the software might have.  This reminds me of the the "Serenity 
Prayer" [1] mantra used during meetings of Alcoholics Anonymous (AA).

The part of this that I think is non-obvious is that one's emotions and 
reaction are actually a choice.  For instance, my experience is that if 
someone outright criticizes me directly with the obvious intent of /trying/ to 
hurt my feelings, /that/ is often far easier to dismiss than if someone 
criticizes the output of my efforts /without/ any obvious intent to make it 
hurt.  This is a good thing as otherwise I would be allowing someone else to 
/control/ my emotions and my reaction.  But the extension of this is even more 
interesting -- that I am /responsible/ for my emotions as as well as my 
reaction, because they are both my choice.  (There's an interesting 10-minute 
video [2] discussing some of these issues which I think is worth watching.)

Finally, I want to make it clear that none of the above is meant as criticism 
of any kind -- it's meant purely as an attempt to help.


[1] https://en.wikipedia.org/wiki/Serenity_Prayer

[2] https://www.youtube.com/watch?v=AhgtGFPTeMY

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


signature.asc
Description: This is a digitally signed message part.

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Guillem Jover]

On Sun, 2012-08-19 at 22:02:47 +0200, Vincent Bernat wrote:
> But also:
> 
>   Alternatively you can install the "consolekit" package which will
>   grant access for all locally logged in users.

ConsoleKit has already been dropped and deprecated by upstream:

  

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120820020757.ga2...@gaara.hadrons.org

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Christoph Anton Mitterer]

On Mon, 2012-08-20 at 02:41 +0200, Michael Biebl wrote:
> Apparently it is still not clear to you: NM by *default* does not export
> any wireless connections from /e/n/i to *any* user by the simple fact
> that managed=false by *default*.
Well ok... but that's what one needs to set when one at least somehow
want's to use both NM and ifupdown. Or did I understand wrong that NM
ignores any interfaces mentioned in /e/n/i, if managed=false?


> What follows is a lot of misconceptions and biased views and you
> conclude with "Will we continue to live with the current disease?".
Well I guess by reporting tickets against the package and upstream, with
things that IMHO should work differently and ideas for enhancement I
made clear enough that I don't simply hate it or so, but want to improve
it..
If you, as maintainer, feel/felt offended, than I'm really sorry and
apologize,... that wasn't my intention; if it were I would have disabled
NM at my system, saved some hours of writing ideas for improvements, and
started lobbying around at all different packages, to drop NM support.

And the "disease" is not NM iself (at least not in my opinion) it's
rather the improper integration of NM with the "native"
tools/configuration.


After all, if NM's integration with ifupdown and the other native tools
(ppp, vpnc, strongswan, etc.) and their configuration would be as good
as I'd like to see it, then most if not all reasons for NM bashing would
fall away.
Because even if NM continues it's philosophy of begin a replacement for
these "native tools",... no could largely complain anymore when both are
well integrated and can just happily co-exist.


>> So no,... don't want to spread FUD ;)
> So my inital point still stands.
Well,... forgive me if I don't always know all lines of the code and the
details behind them.
I just think I have a valid use case (want to use both, ifupdown and NM
well integrated),... and this leads to all kinds of problems.
Assuming that I'm not totally stupid, I came to the conclusion that
there might be issues.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Michael Biebl]

On 20.08.2012 02:18, Christoph Anton Mitterer wrote:
> On Mon, 2012-08-20 at 02:13 +0200, Michael Biebl wrote:
>> That is simply not true.
>> NM doesn't by default export any WPA secrets in /e/n/i to any user.
>> I'm not sure if you don't know any better or if you just want to spread FUD.
> I specifcally wrote "export _connection_" and not "credentials"...
> meaning that it allows to open a connection, that might be intednded to
> be usable by only some users ...and I also gave some ideas that even
> that could be an issue

Apparently it is still not clear to you: NM by *default* does not export
any wireless connections from /e/n/i to *any* user by the simple fact
that managed=false by *default*.

> So no,... don't want to spread FUD ;)

So my inital point still stands.

In your first paragraph you write "I hope this won't become too much of
a rant"
What follows is a lot of misconceptions and biased views and you
conclude with "Will we continue to live with the current disease?".

I won't bother following up as I'm really tired of all this BS on
debian-devel regarding NM lately. Sorry.
My guess is, that this will be another of those pointless NM bashing
threads, where nothing useful comes out of it. Actually I'm not sure
what the point of this thread is, but it definitely managed to piss me
off, the maintainer of network-manager, and I'm not going to further
participate.

Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Christoph Anton Mitterer]

Dear Michael.

On Mon, 2012-08-20 at 02:13 +0200, Michael Biebl wrote:

> That is simply not true.
> NM doesn't by default export any WPA secrets in /e/n/i to any user.
> I'm not sure if you don't know any better or if you just want to spread FUD.
I specifcally wrote "export _connection_" and not "credentials"...
meaning that it allows to open a connection, that might be intednded to
be usable by only some users ...and I also gave some ideas that even
that could be an issue

So no,... don't want to spread FUD ;)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Michael Biebl]

On 20.08.2012 02:07, Christoph Anton Mitterer wrote:

> But when I e.g. put WPA credentials into /e/n/interfaces and made the
> file specifically readable by root and user foo only, then it still
> exports that connection to all other users (e.g. being logged on
> locally; at least per default).

That is simply not true.
NM doesn't by default export any WPA secrets in /e/n/i to any user.
I'm not sure if you don't know any better or if you just want to spread FUD.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Christoph Anton Mitterer]

Hey Ben.


On Sun, 2012-08-19 at 19:32 +0100, Ben Hutchings wrote:
> To allow users to connect to the NetworkManager daemon they have to be in the
> group "netdev".
Like Vincent already pointed out, CK allows it, too.

In principle nothing speaks generally against either of the two, but I
guess both of them are just intended towards "who is allowed to connect
to networks"; either by being member of the group, or by being locally
logged on (CK).
But when I e.g. put WPA credentials into /e/n/interfaces and made the
file specifically readable by root and user foo only, then it still
exports that connection to all other users (e.g. being logged on
locally; at least per default).


> The capability to *use* credentials is separate from the capability to
> *read* the credentials.
Well nevertheless, both can be dangerous already, can't it?
Even if it just allows me to use (i.e. connect to) some WLAN but not
giving me the actual key, I might be able to access some resources
there, that ought to be secure.


> (Also, the design choice to read credentials from a file that is world-
> readable by default is incredibly stupid, and you may wish to report
> bugs on the packages that do that.)
I don't exactly understand what you mean :)


> > In my opinion, NM should:
> > - export any connections from the real canonical places
> > (e.g. /etc/network/interfaces, /etc/vpnc/*, /etc/ppp/peers/*
> > and /etc/chatscripts/*, /etc/ipsec.conf and /etc/ipsec.d/*, etc. pp.)
> > - only if a user doesn't find something there, a per user connection
> > configuration should be set up.
> > - I know, NM supports system wide configuration, too, but IMHO that
> > should be dropped altogether and NM should also not try to edit the real
> > canonical configuration.
> > If someone want's a system wide IPsec connection, that should e.g. go to
> > strongswan's /etc/ipsec.conf.
> 
> You seem to be asking for an awful lot of integration work within NM
> itself, which means divergence from upstream.

Well... yes ^^ ... but actually I don't want to have this in Debian
only.
As said, I've opened bugs for most of the above, e.g. proper integration
of /etc/vpnc/* config into NM's vpnc plugin.

It may however be reasonable, if the ifupdown plugins was really managed
by Debian (developers) and not by some upstream developers who may or
may not have the in depth knowledge to the Debian way of life.


> ifupdown *was* a good framework, but Linux moved on.  ifupdown doesn't
> know anything about interface state.
What exactly do you mean by "state"?

But anyway,.. it doesn't seem as if it would go away anytime soon,...
and NM is AFAICS surely not a powerful enough replacement.


> It doesn't know whether hooks
> succeeded and it can't check for failures because that would be an
> incompatible change (#547587).
Sometimes one have to break compatibility ;-)


> > d) when I disable wireless in NM it really blocks it, so I can't use it
> > with ifupdown. Now one can rfkill unblock then... but why? and even if
> > one does...NM seems to get confused again.
> If you say 'disable wireless', why are you surprised that it does what
> you say? I think it uses rfkill because that may save more power.
Ah is that the case? Didn't know.
Nevertheless, it seems to not handle it correctly when I manually change
things or stop/start NM and things like that.


> I don't think this is the direction upstream is going in.  Instead, it's
> adding more support for advanced setups.
Well even if they do,... to me it seems that every distro keeps it's own
native way of controlling networking and canonical configuration for it.
Trying to duplicate this in NM is IMHO a bad way.


> I would really like to see Debian developers working to improve Network
> Manager so it can replace ifupdown.  For example, improving the command
> line interface and support for various types of software devices.
> Unfortunately, I don't have the spare time to make much of a
> contribution to that myself.  (I do install ifupdown hooks as part of
> ethtool, so I'll have to think about those.)
If all that ever happens,... fine (though I like ifupdown and personally
don't see the need for replacing it),... but it's surely a long road to
it and has the big disadvantage that we (Debian) are then more or
less bound to what NM (and other distros) do.
Sometimes it's good of course, having homogeneous frameworks across
distros,... but this can also be bad.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Paul Wise]

On Mon, Aug 20, 2012 at 7:59 AM, Chris Knadle wrote:

> require network access. As a "for instance" a common suggestion for keeping
> GPG keys up to date is to set a 'gpg --referesh-keys' operation as a cron

I prefer this option for keeping my GPG keyring up to date:

http://packages.debian.org/sid/parcimonie

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6hve3j_noprugitdd-_sbvxzg4eqzwar324dydz4tb...@mail.gmail.com

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Chris Knadle]

On Sunday, August 19, 2012 13:26:46, Christoph Anton Mitterer wrote:
> Hey.
> 
> I hope this won't become too much of a rant, but IMHO we long ago
> crossed the point where something (well actually many things) would have
> needed to be seriously done.
> My grandparents always warned me about UNIX programs written in capital
> letters ;-).
> 
> 
> Seriously... I have nothing against a high level daemon that manages
> underlying network control systems (ifupdown, vpnc, ppp, strongswan,
> openswan, openvpn) but not the way NM does it, especially as it doesn't
> work correctly at all edges and ends.
> 
> Until "recently" all that wasn't a big problem, because one was easily
> able to simply not install NM, but nowadays more and more packages start
> to depend on it (of those I know, most notably gnome-core) or at least
> use it's functionality to determine whether one is online or not.
[…]

The first suggestion I have is to look at Wouter Verhelst's 'ipcfg' project 
[1], which he gave a talk about on the last day of DebConf12 [2], and which is 
currently a work-in-progress, thus making it a good time for this kind of 
input.  His plan for the project addresses many of the typical complaints 
about NM, as well as other network managers, and I think he's got some very 
interesting ideas and thoughts about the problems you've described.

Related note: I likewise repeatedly have confusion over how to deal with 
testing Network Status from within shell scripts for doing operations that 
require network access.  As a "for instance" a common suggestion for keeping 
GPG keys up to date is to set a 'gpg --referesh-keys' operation as a cron job, 
which doesn't make sense to do if the device the script is run on is offline, 
especially if you want to log the output from the command.  The conclusion 
I've come to is that there needs to be a standard way for programs in Debian 
to know whether the local environment has network access, but that right now 
this is something that doesn't currently exist and is also not covered in 
Debian Policy.  :-(

I've likewise repeatedly been frustrated by packages that try to pull in NM as 
a dependency, and there has been repeated discussion here in [debian-devel] on 
this topic as well.  I've used NM, learned to hate it, and today absolutely 
refuse to allow it to be installed.  Reason: I too tried the "solution" of 
"just disable it in the startup script" just to have THAT bite me in the ass 
every time NM gets upgraded.  I'd personally like to see the NM package in 
Debian come with an /etc/default/network-manager file [like wicd has] so that 
a user has a way of disabling NM in a way that won't get "fixed" upon 
upgrades.  Until then, when it comes to my own systems, it and any package 
that depends on it looses.  [Come to think of it, the right thing for me to do 
is to open up a Wishlist bug for this -- so I'll be doing that today.]


[1]  http://anonscm.debian.org/gitweb/?p=users/wouter/ipcfg.git

[2]  http://penta.debconf.org/dc12_schedule/events/953.en.html

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


signature.asc
Description: This is a digitally signed message part.

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Paul Wise]

Please take over the netconf project and start implementing that
design in C, that would be much more productive than any new thread
about the current and previous deficiencies of NetworkManager.

http://web.archive.org/web/20100109113017/http://netconf.alioth.debian.org/

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6HqspWEZqrh64FN0BoEU-X2yKABLW-eHG=x14fms7q...@mail.gmail.com

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Christoph Anton Mitterer]

Hi Marco.

On Sun, 2012-08-19 at 19:41 +0200, Marco d'Itri wrote:
> NM, as a design goal, is not supposed to be able to manage every 
> possible configuration.
Well but then it shouldn't be kind of a default package. And yes, I
know, strictly speaking it's neither required nor essential.
But as I mentioned before, more and more uses it... and one usually
get's it already with gnome-core.


After all, isn't Debian the "Universal Operating System" ... or is it
the "works with only one scenario OS" ;-) 


And to be honest, I don't think that it's impossible that NM would
integrate well with ifupdown (and the others).
Don't take it personal (and I guess neither should even the NM
developers)... but saying "it's not intended to such complex stuff"
sounds sometimes like an excuse.


> > Or will we just mothball ifupdown silently and slowly (as it's replaced
> > by NM).
> As explained, NM is not a general ifupdown replacement.
Ok,... but e.g. on a laptop it's very useful (easily selecting any
wireless networks and such)... but as I outlaid above it more or less
breaks ifupdown and doesn't work quite well with some others... so if I
not only want to go online with my laptop, but do a little more,... I'm
already screwed.


Cheers,
Chris.



smime.p7s
Description: S/MIME cryptographic signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Christoph Anton Mitterer]

Hi Stephan.

On Sun, 2012-08-19 at 19:35 +0200, Stephan Seitz wrote:
> I don’t use NM, but I have it installed (you mentioned the dependencies).  
> I have a „exit 0” in the init script, so NM won’t be started.
Yeah,... or just disable it but then what's the point on it?! I mean
the basic idea of NM or what it should be (high level interface for
users and software to control networking and determine the status) is a
good one..


And to some extent I hate to be required to install dead code, just to
fulfil some deps.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Andrew Shadura]

Hello,

On Sun, 19 Aug 2012 19:32:03 +0100
Ben Hutchings  wrote:

> > 3) ifupdown integration is really bad
> > ifupdown is really a good framework, it offers hooks and and is
> > properly integrated in many packages.

> ifupdown *was* a good framework, but Linux moved on.  ifupdown doesn't
> know anything about interface state.

Why should it? It's a configuration tool, not a monitoring one. If
monitoring is needed, a different tool can be developed which would
perfectly integrate into ifupdown... but nobody has needed that yet?

> It doesn't know whether hooks succeeded and it can't check for
> failures because that would be an incompatible change (#547587).

It can, and compatibility isn't a matter here, it's just a question of
bringing other packages to a state they should have been in already.

Also, as you don't know the stuff behind ifupdown development, please
don't make such statements, okay? We're in the freeze now, so the work
on ifupdown is limited to fixing RC bugs for a while, but this doesn't
mean new stuff won't be developed to make ifupdown better.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Vincent Bernat]

 ❦ 19 août 2012 20:32 CEST, Ben Hutchings  :

>> 1) In parts it has some security issues.
>> - At least the default setting seems to be that any user can connect to
>> any network.
> [...]
>
> According to README.Debian:
>
> To allow users to connect to the NetworkManager daemon they have to be in the
> group "netdev".

But also:

  Alternatively you can install the "consolekit" package which will
  grant access for all locally logged in users.

But all this can be changed by altering the appropriate file in
/etc/dbus-1/system.d.
-- 
Follow each decision as closely as possible with its associated action.
- The Elements of Programming Style (Kernighan & Plauger)


pgpge7rFD4ITs.pgp
Description: PGP signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Ben Hutchings]

On Sun, 2012-08-19 at 19:26 +0200, Christoph Anton Mitterer wrote:
[...]
> 1) In parts it has some security issues.
> - At least the default setting seems to be that any user can connect to
> any network.
[...]

According to README.Debian:

To allow users to connect to the NetworkManager daemon they have to be in the
group "netdev".

> - At least the network connections from /etc/network/interfaces are
> exported to the normal user, even if that user cannot read that file.
> A typical example is that I put in network connections that the normal
> user should not be able to enable, or even connections that require
> credentials in /etc/network/interfaces.
> So NM should only export a connection, if the user would be able to read
> the necessary config files.

The capability to *use* credentials is separate from the capability to
*read* the credentials.

(Also, the design choice to read credentials from a file that is world-
readable by default is incredibly stupid, and you may wish to report
bugs on the packages that do that.)

> 2) NM's design seems to be wrong.
> AFAIU (I didn't look into too much depth, though), NM is based on the
> design idea, that it replaces all network management and configuration
> from the respective distros.

I don't think that was the original intent at all.  However it is
gradually being extended to manage more types of device.

[...]
> In my opinion, NM should:
> - export any connections from the real canonical places
> (e.g. /etc/network/interfaces, /etc/vpnc/*, /etc/ppp/peers/*
> and /etc/chatscripts/*, /etc/ipsec.conf and /etc/ipsec.d/*, etc. pp.)
> - only if a user doesn't find something there, a per user connection
> configuration should be set up.
> - I know, NM supports system wide configuration, too, but IMHO that
> should be dropped altogether and NM should also not try to edit the real
> canonical configuration.
> If someone want's a system wide IPsec connection, that should e.g. go to
> strongswan's /etc/ipsec.conf.

You seem to be asking for an awful lot of integration work within NM
itself, which means divergence from upstream.

> 3) ifupdown integration is really bad
> ifupdown is really a good framework, it offers hooks and and is properly
> integrated in many packages.

ifupdown *was* a good framework, but Linux moved on.  ifupdown doesn't
know anything about interface state.  It doesn't know whether hooks
succeeded and it can't check for failures because that would be an
incompatible change (#547587).

Yes, we have a large investment in ifupdown.  But the result is still
not good, and we don't get much help with this from other distributions.

[...]
> d) when I disable wireless in NM it really blocks it, so I can't use it
> with ifupdown. Now one can rfkill unblock then... but why? and even if
> one does...NM seems to get confused again.

If you say 'disable wireless', why are you surprised that it does what
you say?  I think it uses rfkill because that may save more power.

> 4) upstream more or less doesn't want to support these scenarios...
> Already many months ago, I've opened a Debian bug, that some /e/n/i
> connections are simply not shown by NM.
> Given that this is actually an upstream issue, I've reported this (and
> most other problems I've mentioned before, especially the poor ifupdown
> integration but also the ideas about adding support for all the
> canonical configurations) upstream.
> I guess the conclusion is: "this won't be implemented".
> 
> It seems the "desired" scenario for NM is that /e/n/i is empty and

I suspect so.

> everything is handled Apple™ like: hide-everything, don't support
> advanced setups.

I don't think this is the direction upstream is going in.  Instead, it's
adding more support for advanced setups.

[...]
> So what are the opinions of the others? Will we continue to live with
> the current disease? Are the alternatives better integrated? Could we
> get discourage NMs use if necessary?
> Or will we just mothball ifupdown silently and slowly (as it's replaced
> by NM).

I would really like to see Debian developers working to improve Network
Manager so it can replace ifupdown.  For example, improving the command
line interface and support for various types of software devices.
Unfortunately, I don't have the spare time to make much of a
contribution to that myself.  (I do install ifupdown hooks as part of
ethtool, so I'll have to think about those.)

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.


signature.asc
Description: This is a digitally signed message part

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Stephan Seitz]

On Sun, Aug 19, 2012 at 07:26:46PM +0200, Christoph Anton Mitterer wrote:

Until "recently" all that wasn't a big problem, because one was easily
able to simply not install NM, but nowadays more and more packages start
to depend on it (of those I know, most notably gnome-core) or at least
use it's functionality to determine whether one is online or not.


I don’t use NM, but I have it installed (you mentioned the dependencies).  
I have a „exit 0” in the init script, so NM won’t be started. I don’t see 
any problems with other applications (e.g. Pidgin).


So try it, and if it works for you, you can ignore NM.

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Marco d'Itri]

On Aug 19, Christoph Anton Mitterer  wrote:

> Where do I see the main problems of NM?
NM, as a design goal, is not supposed to be able to manage every 
possible configuration.
I see no reason do /discourage/ it use: it has important use cases where 
it works well, the problem is just the people who are making hard to not 
install it when it is not appropriate for the job.

> Or will we just mothball ifupdown silently and slowly (as it's replaced
> by NM).
As explained, NM is not a general ifupdown replacement.

-- 
ciao,
Marco


signature.asc
Description: Digital signature