Re: [RFC] Fast-user-switching plans

[Graham Lyon]

On 28 May 2010 21:41, Martijn Lievaart  wrote:
>
> Very cool! Sounds like there is still much more integration needed -- the
> whole user environment should use such a namespace, and the global
> networkmanager can interact with the user namespaces --, but definately a
> great step in the right direction. I any work done into moving a user
> environment into such a namespace?
>
> M4
>
>
None that I know of. As far as I'm aware this is a very fresh project and is
only used by the linux containers project to create entirely segregated
containers to run as virtual machines. If we were to head down this route,
how would it be achieved? Perhaps there could be a network namespace per
user where all the user's own connections are and then a global one for
global connections (naturally a bridge interface between the two for one the
user just wants to use the globally available connection). This would solve
the highly contrived use case of already having an internet connection and
wanting to connect via 3g in a different session; however it would not solve
the problem of wanting to connect to a different wireless access point if
the wireless card is already in use by another session. Perhaps more thought
is needed on that...?
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Fast-user-switching plans

[Graham Lyon]

Now I'm no expert on this particular area but I recall that there are now
several ways to break a system up into "containers" [1] which is often used
to do things like virtualisation. However, would it be possible
to utilize the network "namespace" component [2] in order to break off a
user's mobile broadband connection into a namespace that only their
processes have access to? I'm just bringing this up because maybe the
technology to do what everyone seems to agree "should" be possible already
is in the kernel.

Like I said, I'm no expert but I think I'll read into it out of curiosity...
just wanted to throw it out there for anyone else who might be curious about
looking down this path...

-Graham

[1] http://lxc.sourceforge.net
[2] http://lxc.sourceforge.net/network.php

On 28 May 2010 17:23, Martijn Lievaart  wrote:

> On 05/28/2010 03:46 PM, Marc Herbert wrote:
>
>> Le 28/05/2010 09:16, Simon Geard a écrit :
>>
>>
>>
>>> Simply because IP is not designed like this at all. NetworkManager's
 scope is make IP networking easy; not to re-invent the Internet.


>>> Actually, couldn't something be done with Netfilter rules? The
>>> connection (a VPN, say) might technically be system-wide, but with rules
>>> enforcing that only applications running as a certain user could send
>>> and receive packets on it? Perhaps imperfect, but a starting point...
>>>
>>>
>> Sockets have owners, but I doubt very much you can extend that to
>> packets. The "end-to-end principle" strikes again. So this rules out
>> Netfilter I am afraid.
>>
>>
>>
>
> Netfilter has an owner match, which does extend the owner to packets, more
> or less. However, you would als have to consider routing. This also looks
> possible with tc rules matching on the same netfilter match. However I
> suspect this will never work satisfactorily, IP was just never designed to
> do things like this.
>
> I do think that we will move in this general direction, but with a more
> light-VM-per-user like aproach, where every user has it's own view of the
> filesystem, it's own networking "view" etc. In other words, I suspect this
> is much bigger than can be handled now.
>
> HTH,
> M4
>
>
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: "/etc/init.d/NetworkManager quit" ?

[Graham Lyon]

The point you're missing here is that network manager solves a very real
problem with links going down after boot time and not automatically coming
back up when they're available again (Read as: laptop users). A daemon was
necessary to fix this and nothing like it had been done before. The design,
therefore, is not perfect and so regressions are inevitable. This does not
mean, however, the the init scripts were better - they just had 15 years or
so to mature ;)

On 27 February 2010 14:47, Dominik George  wrote:

>
> > For use on servers: because it means that you only have to learn one
> tool.
> > Also, why not? ;)
> >
> This, dear fellow user, I will not discuss publicly, as I would probably
> be banned from the list ;).
>
> In short: NetworkManager is all in all a single pain in the a . Both
> on Desktops *and* on servers.
>
> So why not stick to traditional runlevel control when t is known to work
> better?
>
> -nik
>
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: "/etc/init.d/NetworkManager quit" ?

[Graham Lyon]

For use on servers: because it means that you only have to learn one tool.
Also, why not? ;)

On 27 February 2010 08:30, Dominik George  wrote:

>
> > That's correct, at least for some wired devices with a system
> > connection.  It's to ensure that restarting NM as part of a security
> > update or whatever does not interrupt network connectivity server-type
> > boxes.
> >
> I still don't get why people would want to use NetworkManager on servers
> anyway. But that's another topic (however, if someone feels like
> explaining, I'll not stop her ;)).
>
>
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: traditional static ip with nm

[Graham Lyon]

2009/12/5 David Griffith 

> On Fri, 4 Dec 2009, Dan Williams wrote:
>
>  NM natively supports static IP addresses; so you can either configure
>> them via /etc/network/interfaces as you normally would, or you can use
>> nm-connection-editor along with the 'keyfile' plugin to set up a
>> system-wide configuration for your  machines without touching /e/n/i.
>>
>
> My problem with that approach is that the network goes down when the
> console is logged out.


Not anymore - networkmanager supports system-wide connections that stay
active as long as the networkmanager daemon is running.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Online Status Design + Program Input

[Graham Lyon]

I'll pitch in here.

I'd argue that we shouldn't avoid giving this distinction of the "level" of
connectivity we have (local, internet, whatever) just because some apps
might use it in a broken or ill-conceived manner - if an app consumes the
information provided by network manager incorrectly, then the app is broken
and not network manager! For instance, I think firefox should attempt to
connect to a server so long as any sort of network connection is present.
Note that if a "local only" connection is present, then a connection to what
we think of as a public address may still be possible because that public
address may actually be hosted on the LAN and the internet connection for
the entire LAN may be faulty. So, for instance, I should still be able to
connect to my company's internet site if it is hosted on my company's LAN
but my company's internet connection is down. I hope that wasn't too
confusing. But anyway, that's an argument to be had on the firefox
development mailing lists ;)

2009/12/4 Simon Geard 

> On Fri, 2009-12-04 at 07:22 +, Martin Owens wrote:
> > That's a completely different use case. What you want to tell client
> > programs needs to be different to what your telling users when your
> > unsure about what you've got.
>
> True, it's not quite the same, since existing implementations are
> triggered by the presence of any NM-managed network, rather than whether
> that network can see the rest of the world. Even so, if the information
> is there, people will likely use it for such purposes...
>
> Simon.
>
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How to stop wireless autostarting at boot?

[Graham Lyon]

There was a patch submitted to the master branch around a month ago. See
here:
http://www.mail-archive.com/networkmanager-list@gnome.org/msg14215.html

I guess it will be in a distribution near you soon :)

Graham

2009/11/20 Panayiotis Mousouliotis 

> I would like to start with Wireless disabled completely and enable it from
> network manager whenever i need it.
>
> Now, i have blacklisted the wireless module (in
> /etc/modprobe.d/blacklist.conf) and i make a script that executes
>
> modprobe iwlagn
>
> in order to start wireless.
>
> Loading the module makes wireless to start in network manager in my acer
> 5920g latop.
>
> And i would like to know if there is a simpler and more elegant way to do
> this.. maybe using network manager.
>
>
> Panayiotis
>
>
>
> On Fri, Nov 20, 2009 at 1:45 AM, Darren Albers  wrote:
>
>> On Thu, Nov 19, 2009 at 6:15 PM, Panayiotis Mousouliotis
>>  wrote:
>> > I use ubuntu 9.10 and when i boot wireless always starts.
>> >
>> > Is there a way to disable wireless autostarting using some network
>> manager
>> > option or configuration?
>> >
>> >
>> > Thanks in advance,
>> >
>> > Panayiotis
>> >
>>
>> Do you want to start with Wireless disabled completely or just not
>> autoconnect to AP's?
>>
>> If you edit the profile for your wireless networks you can uncheck
>> connect automatically to make all networks manual connections.
>>
>
>
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: bug or "feature" ??

[Graham Lyon]

Why not? Why bother having two different ways of doing something?

2009/11/4 

> Dan Williams wrote:
>
>> On Mon, 2009-11-02 at 16:54 -0400, Gene Czarcinski wrote:
>>
>>
>>> I notice that if I stop the NetworkManager service:
>>>/etc/init.d/NetworkManager stop
>>> that the interfaces started by NetworkManager are not always stopped.
>>>
>>> Note: this is a F12 qemu-kvm guest with multiple (two) NICs defined.
>>>
>>> Bug or "feature"??
>>>
>>>
>>
>> Feature.  It allows you to do 'service NetworkManager restart' and have
>> the connection survive.  This is implemented for wired static and DHCP
>> interfaces only and was requested quite a few times by people who run
>> headless servers where you may need to update NM on-the-fly and not be
>> kicked out when doing so.  It's also necessary for NM to seamlessly take
>> over a connection from the initrd where the rootfs is network mounted.
>>
>> Dan
>>
>>
>> ___
>> NetworkManager-list mailing list
>> NetworkManager-list@gnome.org
>> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>>
>>
> Why would anyone use NM on a server or on a diskless node?
> (Just wondering...)
>
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Problem with changing encryption for established connection

[Graham Lyon]

2009/10/26 Dan Williams 

> I made that work at one point, so that if you did switch from WEP to WPA
> it would just ask and you send the new settings.  But at some point I
> think that became obsolete, because NM won't even try to connect to your
> AP if the connection is WEP, but the AP is WPA; this filtering was
> requested mainly for people with 'linksys' default-ssid APs where say
> their neighbor was running one with WEP + 'linksys', but the one they
> connected to was WPA or something.
>

I'm curious about this. Are people with that model of router simply unable
to change their SSID then? If not, surely if their neighbor's SSID is the
same as theirs and this is causing them issues then the correct course of
action would be to change their SSID and not cause everyone to lose what I
personally think is an essential piece of functionality. Changing of
encryption methods is actually quite common (no, I'm not saying it's done
every day but it's certainly not unexpected behavior).
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Default Gateway with Manual Setting

[Graham Lyon]

Is there a particular reason that you're manually configuring these two
routes? The 192.168.0.0/255.255.255.0 route is implied by the subnet mask
and so shouldn't be needed, and the 0.0.0.0/0.0.0.0 route is created by
setting the default gateway box on the ipv4 settings page to the address of
your gateway (192.168.0.12, in your case). Or am I missing something?

2009/10/4 Martyn J. Pearce 

> Apogolies if re-asked, I have searched the mailing-list archive to no
> avail.
>
> I am running a new ubuntu install on a netbook (Eeepc surf), with wired &
> wireless networking available, both domestic manually-configured networks
> (no
> dhcp).  I have added Manual profiles to both wired & wireless.  I cannot
> get
> the default gateway (192.168.0.12) to configure, however.
>
> I add two routes in the route config panel; one for
> 192.168.0.0/255.255.255.0
> (no gateway), and one for 0.0.0.0/0.0.0.0 (gateway 192.168.0.12).  Having
> left
> the edit dialogue, and applied, there is no difference to the routing table
> as
> displayed with route -n.  If I re-enter the routes edit panel, I find that
> it's collapsed the routes into one, being 192.168.0.0/255.255.255.0(gateway
> 192.168.0.12); but there's no hint of the gateway in the route config.
>
> I have tried checking and unchecking the "use this connection only for
> resources on its network" (I'm sure it should be unchecked, but I tried
> both);
> it makes no difference.
>
> I'm sure I'm being stupid, could somebody take pity and enlighten me as to
> what I'm doing wrong?
>
> I attach the relevant lines from /var/log/daemon.log (grep NetworkManager),
> I've checked the one bug mentioned therein; that is related to publishing
> of
> offline mode rather than setting of default gateways.
>
> Thanks,
>
> [please cc: me on replies, I am not subscribed to the list]
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network manager always deconfigure the ethernet interface when network link is down

[Graham Lyon]

2009/9/12 Graham Lyon 

> Ah, my bad. I didn't realise that this behaviour was caused by it being the
> first in the list. I second the fact that it would make sense for this
> behaviour to be as standard in network manager.


To clarify what I mean by "this behaviour" I mean sticking to the last used
connection that is set to "connect automatically"
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network manager always deconfigure the ethernet interface when network link is down

[Graham Lyon]

Ah, my bad. I didn't realise that this behaviour was caused by it being the
first in the list. I second the fact that it would make sense for this
behaviour to be as standard in network manager.

2009/9/11 Luc Deschenaux 

> Le vendredi 11 septembre 2009 à 11:58 -0400, John Mahoney a écrit :
> >
> >
> > On Fri, Sep 11, 2009 at 4:03 AM, Graham Lyon 
> > wrote:
> > 2009/9/11 Luc Deschenaux 
> >
> > At least I never need that NM switch to "auto eth0"
> > when the link is up
> > again, I need to continue with the configuration I did
> > choose.
> >
> > I believe that I'm correct in saying that if you select the
> > "connect automatically" checkbox on multiple wired network
> > profiles then it will simply connect to the previously active
> > profile instead of redefaulting to the "auto eth0" profile
> > (which I assume is the only one you have with the "connect
> > automatically" checkbox selected currently. This is the
> > behaviour that I get using a crossover cable so whilst I may
> > get annoying notifications about the interface continually
> > going up and down, it is very quick to reapply a static config
> > (complete with all its routes etc if you have them configured
> > through network manager) and so the other device *shouldn't*
> > notice. Try setting that checkbox for your static
> > configuration and unplugging and replugging the cable to see
> > which profile it then selects and report back with the results
> > - I know I got it to behave in the way that I think you want,
> > I just can't remember precisely how I did it ;)
> >
> >
>
> When the "connect automatically" option is enabled for many
> configurations, the first config in the list having the option checked
> is re-activated instead of the previously used configuration for the
> interface.
>
> If the previously used config for this interface was re-activated (when
> many configs have the "connect automatically" checked), instead of the
> first in the list having the option checked, it should yet solve some of
> the problems.
>
> L:üc:
>
> > The above is true on my system which is Ubuntu 9.04.  Though I
> > unchecked the "Connect Automatically" check box for the Auto eth0(I do
> > not know if this step is necessary, but I do not use dhcp anyways) and
> > checked the "Connect Automatically" box on all my static connections.
> > Worked like a charm for me and I connect and disconnect my Ethernet
> > about 20 times a day.  I still agree with the concept of an option
> > allowing the IP Address and routes to persist between carrier events,
> > except maybe the default route.  Yes, I realize there are often work
> > around for reasons this would be necessary, but it just seems like a
> > nice thing to have.
> >
> > -Graham
> >
> >
> > ___
> > NetworkManager-list mailing list
> > NetworkManager-list@gnome.org
> > http://mail.gnome.org/mailman/listinfo/networkmanager-list
> >
> >
>
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network manager always deconfigure the ethernet interface when network link is down

[Graham Lyon]

2009/9/11 Luc Deschenaux 

> At least I never need that NM switch to "auto eth0" when the link is up
> again, I need to continue with the configuration I did choose.
>

I believe that I'm correct in saying that if you select the "connect
automatically" checkbox on multiple wired network profiles then it will
simply connect to the previously active profile instead of redefaulting to
the "auto eth0" profile (which I assume is the only one you have with the
"connect automatically" checkbox selected currently. This is the behaviour
that I get using a crossover cable so whilst I may get annoying
notifications about the interface continually going up and down, it is very
quick to reapply a static config (complete with all its routes etc if you
have them configured through network manager) and so the other device
*shouldn't* notice. Try setting that checkbox for your static configuration
and unplugging and replugging the cable to see which profile it then selects
and report back with the results - I know I got it to behave in the way that
I think you want, I just can't remember precisely how I did it ;)

-Graham
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: two static configuration for a wired interface

[Graham Lyon]

Assuming that you're using Gnome (KDE isn't very different) you would right
click the network manager icon in the system tray (you need to add this to
your list of programs that gnome starts on session startup if it isn't
already there) and select "Edit Connections...". You should now be faced
with a tabbed configuration manager. Make sure that "Wired" is the active
tab and click the Add button. Give it a sensible name and then go to IPv4
settings and add the IP address and netmask (you can add multiple IP
addresses and netmasks to be active at any one time, as Dan has said) and
fill in any other details as necessary. Do this for both configurations. You
may also want to select "Available to all users" if you wish. Now, when you
plug in at a different location all you need to do is left click on the
network manager icon and select the profile relivent for your current
location. Also, if these are the only two configurations that you wish to
choose then you may want to delete hte "auto eth0" connection which is just
the default created connection which does DHCP, though it does no harm
leaving it there.

If these instructions are a little brief then say so and I'll happily expand
on them :)

2009/9/10 Wurbel Eric 

> Le jeudi 10 septembre 2009 à 13:14 -0700, Dan Williams a écrit :
> > At the same time, or at different times?
> >
> > NM can do two completely different configurations at different times;
> > since you can't really autodetect the network you're connected to easily
> > with a wired interface, you'd have to select at least one manually from
> > the menu or command-line when you wanted to bring it up.
> >
> > NM can also assign multiple IP addresses to a single device at the same
> > time from the same connection.
> >
> > Which one are you looking for?  Let me know and I can describe a bit
> > more how setup would work.
> >
> > Dan
>
> What I want is two different static configurations at different times o
> for one interface (one configuration for my office place and one for my
> home). Switching from one config to another manually is exactly what I
> want.
>
> Thanks
>
> Eric
>
>
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Multiple VPNs and resolvconf

[Graham Lyon]

What about some method of checking which domains the dns on the end of the
VPN is authorative for and only looking up that domain on that dns? Excuse
my ignorance of dns if this is not possible...

2009/8/10 Marc Luethi 

> On Mon, 2009-08-10 at 11:51 +0200, Dominik George wrote:
> > I'm not quite sure whether this is a problem. If nameserver A cannot
> > resolve a hostname, the system will try nameserver B automagically, then
> > nameserver C until it gets a result.
>
>
> Not if the first nameserver returns NXDOMAIN; the local resolver will
> accept this as a valid response and won't query another nameserver.
>
>
> regards
>
> Marc
>
>
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Network Manager does not find system wide connections

[Graham Lyon]

2009/8/9 Hadmut Danisch 

> Graham Lyon wrote:
> >
> >
> > Then documentation should be fixed, not the method itself. DBus is the
> > best approach to do this, it uniffies IPC in unix, which is a *good*
> > thing.
>
> Network configuration is such an essential and basic function, that it
> should not depend
> on IPC.  IPC means that  several processes must exist, and this is error
> prone by default.
>
> IPC may be an addon, but it should work without IPC.
>

I can see what you're saying here and I sympathise. Perhaps the best
solution would be one where there is a single NM daemon on the system level
that manages the interfaces and deal with the system config and then
supplies a (probably the same) DBus API that allows user processes to manage
user-configured connections. A merger of NetworkManager and
nm-system-settings, basicly. This removes the need for IPC in order to get
the core of it working whilst at the same time still supplying the same
funcionality. The more that I think about it the more I agree with you on
this point that NetworkManager shouldn't be useless without DBus and the
nm-settings-daemon running also.

> NM is not interweaved with desktop applications. You're confusing the
> > user settings manager with network manager itself.
>
> A plain user will store his network settings under Gnome or KDE and such
> within the Gnome and KDE
> configuration methods. This depends on desktop applications. Without a
> desktop network manager will
> not find any user specific config.


I'm not entirely sure what you meant here, but I suspect you mean that an
ordinary user will configure their system using the applets in gnome/kde and
so their settings will not be system settings? They only need to tick the
"make available to all users" ticky box. If I completely misread what you're
saying, please do correct me.

And I did not yet see any command line front end.
>

There is cnetworkmanager, apparently (I've never used it) and there was
discussions on this list somewhere about a rewrite of it to make it more
functional.


> > It's actually the best way to get the two levels of configuration that
> > I can think of.
> Storing network configuration in Gnome or KDE in a way that they are not
> available if someone uses the other Desktop is a bad idea. Network
> settings are
> not desktop settings and thus should not be stored in the Gnome or KDE
> configuration.
>

Fair point, but how often do you switch to using the other desktop
environment as the same user login? It's not a particularly common use
case... I will admit that the network settings are not part of your desktop
settings and the problem here is that there is no unified settings daemon
for all user's applications (something like this is really lacking in the
world of linux and would be great as it would stop everyone having to roll
their own config file reading/writing mechanism.


> > It doesn't need a running desktop to be configured, and lots of system
> > relevent applications require DBus (it's not a desktop program).
>
> And that's wrong.
>
> DBus is not started in single user mode. So NetworkManager could not be
> used in single user mode.
>
> A network configuration that does not work in single user mode is a flaw.


See above. I'm not particularly familiar with single user mode (I've never
had the need to use it, rather thankfully) but is it possible that dbus
could be added to the things that are started in single user mode?


> > Networking must be able to work even in single user mode in a simple
>  > terminal
> > with a shell session and must not depend on anything else.
> >
> >
> > Correct me if I'm wrong, but I think it does as long as the daemon is
> > started and the system settings daemon is started.
>
> That's one of the problems. Network configuration must not depend on
> that many daemons.
>
> Network configuration must be able to work on its own, even if
> everything else is absent.


I proposed a possible solution to this a little further up in this mail. I'm
not sure how the devs will feel about it but it actually makes more sense
from a design point of view to me. Though I don't pretend to know about the
network manager internals so it could be impossible...

Graham
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Network Manager does not find system wide connections

[Graham Lyon]

2009/8/8 Hadmut Danisch 

> Dan Williams wrote:
> >> Many packets for debian/ubuntu  are designed for the four phases of
> >> the ifup/down system of debian for pretty good reasons.
> >>
> >
> > It depends; reasons change, and so do implementations.  Nothing is set
> > in stone.
> >
>
> Ah, I see. debian and ubuntu will change their main concepts just
> to please network manager...
>

This wasn't what he said, the statement was that it depends and reasons
change. The DBus interface wasn't available before and therefore everything
had to get information from and happen as a result of the phase scripts. Now
that the DBus interface is there the packages that used the previous methods
should be revised and it should be decided whether that really is the most
appropriate way of doing things. Maybe it is the case that the DBus
interface isn't entirely suitable for whatever reason, but that needs to be
looked at on a case by case basis and if appropriate something else can be
decided upon/added.

> Completely wrong.  NetworkManager is *NOT* a Red Hat tool.  Novell has
> > contributed immensely to it, as have quite a few others from other
> > distributions.  It just happens that I am paid by Red Hat to spend 110%
> > of my time working on NetworkManager.
> >
> > Nobody else has made that commitment.  If some other company or person
> > decided to invest time in NetworkManager, then that person or companies
> > goals would also obviously be reflected in the feature set of the final
> > product.
> >
>
> So network manager is designed to not fit very well into other
> distributions?
>

Again no, network manager wasn't designed to not fit into distribution X, it
simply hasn't been adapted to fit into it yet. The way you're saying this
it's like NM was designed specifically for redhat and they refuse to change
anything to make it fit well with other distributions as well. What was said
is that redhat have invested a lot in NM and so of course it is suited well
to a redhat environment. If some other distro were to invest heavily (by
sending patches for the functionality that was required) then NM would also
fit well into that distribution.

> So lets add some cold hard facts to the discussion.  What things are
> > people doing in pre-down scripts?
> >
>
> * Any kind of logout, e.g. release dynamic dns entries, properly
>  shut down connections that are kept alive during the online state
>* cleanly shutting down VPN connections and tunnels
>* network logoffs, e.g. deregistration from firewalls to prevent
>  that someone else uses the user's permissions still bound the IP
>  address
>* Anything that needs to be done with network interfaces that don't
>  exist anymore after taking them down, e.g. read the counters
>* Doing jobs that need the network connection to be present, e.g.
>  empty the mail queue
>* Porperly shutting down daemons with services bound to that
>  particular network interface or internet address
>
>
>
> >
> >> Beyond the dispute whether two or four phases should be supported,
> >> Network Manager
> >> does not pass the required Information to the up/down scripts.
> >>
> >
> > See below.  What other information do you need?  Is there some reason
> > the tools you're running in these phases cannot use D-Bus for network
> > even notifications if they are already running as a service somewhere?
> > If they are not running as a service, then yes, a one-shot script-based
> > approach may be more appropriate.
> >
>
> Using dbus to fetch information in such a basic application is a
> completely wrong
> way. dbus is not very well documented. When trying to fetch debugging
> data to
> find the problem in my cause I could not find a detailed description
> about how
> to fetch attributes from dbus, and it would be a nightmare to do it in a
> shell script
> (and too slow as well). Documentation is poor and incomplete.


Then documentation should be fixed, not the method itself. DBus is the best
approach to do this, it uniffies IPC in unix, which is a *good* thing.


> requiring each single one of the phase scripts fetch information over
> dbus is
> simply very, very bad design. If five scripts need that informations
> then every
> single one should fetch data over dbus even if the network manager already
> has them but does not pass for 'religious reasons'?
>
> Under debian/ubuntu there is a standard about which data the phase scripts
> expect, and not all of these data can be found on dbus.
>
> Needed:
>
>* The environment variables as set by the ifupdown program
>* The parameters set by users to use extra functionality provided by
>  the phase scripts. Configured in /etc/network/interfaces for every
>  connection type
>* Any parameters passed by the DHCP server
>
>
>
>
>
>
> >
> >> Expecting the scripts to retrieve details with a given UUID over dbus is
> >> error prone and
> >> bad design, and it does not make the script run any faster.
> >>
> >

Re: (missing) pre-up and pre-down

[Graham Lyon]

2009/8/7 Dan Williams 

> On Wed, 2009-08-05 at 11:30 +0100, Marc Herbert wrote:
> > Dan Williams a écrit :
> > >
> > > There are two reasons I've not yet added pre-up and pre-down.  They
> are:
> > >
> > > 2) appropriateness
> >
> > Hmmm, the good old "just do not do this" answer... the best answer to
> > any feature request ever ;-) Especially to people having using this
> > feature for ages and being suddendly deprived of it.
>
> Please note I didn't say *all* uses were inappropriate.  Just that
> because we've done something the same way forever, doesn't *necessarily*
> mean that it should always be done that way until the end of time.
>
> >
> > > b) by the time any pre-down script will run, often the connection
> > > has already gone away (the AP is out of range, the cable has been
> > > unplugged already, etc) so any operation a pre-down script does
> *cannot*
> > > depend on the interface being up; it must gracefully fail.  Common
> > > things people wanted to do here were unmount network shares;
> > > but since the script must always handle unexpected disconnects (which
> > > not all network file systems do well), you might as well just run this
> > > from post-down anyway.
> >
> > I think "pre-down" cleanup scripts could (should?) simply NOT be run on
> > unexpected disconnects (as opposed to explicit disconnection
> > requests). Simply because they are called PRE-down, not AT-down.
>
> I did think about this a lot while composing the mail, and couldn't come
> up with a good reason to not run pre-down scripts on unexpected
> disconnect.  I don't really care either way.


Not running them on unexpected disconnects would breed inconsistency and
would be confusing for tracking issues/users who aren't aware of this quirk.
Running them on unexpected disconnections would be pointless - they are
scripts that, by definition, expect the interface to be up. There's no
winning.

Perhaps when a connection drops unexpectedly the pre-down scripts should be
run with an argument of some kind to inform them that the interface has
already dropped? That way they can clean up the mess that's created but
avoid any action that requires the interface to still be up...

Just two my cents

-Graham
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: The state of firewall management...

[Graham Lyon]

2009/7/1 Dan Williams 

> Firewall UI is a hard problem, and the current Linux stuff just doesn't
> make sense for most users, because they are fundamentally trying to
> provide a UI shell around a simple list of port-based allow/deny rules,
> or worse, a UI shell around every option that iptables provides.  That's
> not how you create a usable interface for 85% of the people out there.


Yes, this has always irked me about firewall management on linux. The most
powerful interface I've ever used was the one in webmin, but I suppose
that's one of the ones that supplies all options iptables offers under the
sun.


> In any case, it's also not a battle I think NM should by trying to
> fight, nor is it entirely within NM's area of responsibility.  Firewalls
> are a level above NM, and the risk of becoming an amoeba gets pretty
> large when talking about adding Firewall, proxy, Captive Portal, etc to
> NM itself.


Agreed.


> What I think *should* happen is fairly intelligent integration between
> NM and some other firewall manager.  NM can provide information that a
> firewall definitely wants; if you connect to a WPA or 802.1x protected
> or 3G network, then you can worry a lot less because you're on a fairly
> secure network.  If you connect in a public coffee shop with no
> encryption at all, then you definitely want higher security policy in
> the firewall.


Finally, someone agrees :D


> Thus, I think that a firewall should interact with NM on a pretty
> fundamental level, and after getting details about the current network
> connection from NM, the firewall manager could make some intelligent
> policy decisions about what security level to enforce.


So all we need to do is export a "security level" property over D-bus and
then a sepparate daemon can manage the firewall. I like this idea.

I think there's a lot of room to improve on Vista's "what location are
> you in" dialog that comes up every time you connect to something new.  I
> think it both over-simplifies the problem *and* mis-characterizes it at
> the same time, but I didn't do any UI research that Microsoft presumably
> did.  Note that Apple doesn't do this at all, they appear to run with
> maximum firewall at all times, and let specific services punch through
> the firewall automatically (like file sharing) with appropriate warnings
> when you start the service up.


A good point - the Vista GUI has some flaws, but at the moment I can't think
of anything better to assertain the level of security of the network short
of outright asking the user. I'd be happy to hear ideas on how we could
infer it but to comment on what you said about 3G networks - they're an
internet connection and should therefore be implicitly untrusted and so
grouped with public wifi...

We could certainly store some sort of "security level" tag on a
> per-connection basis in NetworkManager that would be available to apps
> like a firewall manager, which users could set either in the connection
> editor, or via some other method which we should get user-interaction
> experts to think about.  We can even set that tag to reasonable defaults
> based on the connection type.
>
> Does that sound anything like what you were thinking about?


Yes.

--Graham
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: The state of firewall management...

[Graham Lyon]

2009/6/24 Marc Herbert 

> Graham Lyon a écrit :
> > 2009/6/24 Marc Herbert 
> >
> >> Graham Lyon a écrit :
> >>> I'll agree that if your system doesn't have ports open by default then
> >>> you're fine, but if for instance your package manager pulls in mysql or
> >>> postfix or similar as a dependency for some package that doesn't really
> >> need it to use its network capabilities
>
> > Yes, such a situation would be a misconfiguration. But, going on to say
> that
> > because this is a misconfiguration issue and therefore there is no need
> for
> > a firewall is a little foolish. The firewall would mitigate any threat
> that
> > would exist (at least on public networks)
>
> So I guess the problem is: how do you protect a minority of mysql users
> from an unlikely and easy to fix packaging error, without bothering with
> a firewall the vast majority of desktop users who do not care?


My point wasn't related to mysql directly, that was more of an example. I
was hoping to raise the point of, if a packaging error does occur, then the
firewall mitigates that issue until the bug is found/corrected and so lowers
the potential for an exploit to take place in that time. I do, however,
accept your point that the security vulnerability is, in this case, tied to
the packaging error and that it should be corrected, not left because "the
firewall stops the problem anyway".

> - belt and braces, etc
>
> Belt + braces is nice in theory but in reality people tend to give up
> one once they started to use the others. Windows experience shows that a
> firewall makes most people feel protected and not care any more about
> network security.


I suppose I can see where you're coming from here. I myself have experience
with this kind of person thinking "oh, well I have a firewall so nothing can
get me now!"


> > What's complicated about it?! Sorry - but that's really an incorrect
>  > statement. As for which user understands the configuration of their
> > firewall, that's the whole point of this daemon - *it* understands and
> *it*
> > can do the configuration, all the user has to do is say that it's a
> > public/private network and the rest is taken care of.
> >
> > 1) You've just connected to a wireless network
> > 2) Do you know whether this is a public or private network already? If
> not,
> > ask.
> > 3) If it's public, block all incoming traffic on that interface.
>
> Please let me quote your message from yesterday:
>
> > A firewall isn't only about prevention access to network listening
> > daemons, it's about granularity in that restriction :)
>
> And indeed, the first thing people will do is allowing skype and other
> similar P2P software to escape their firewall (or worse: disabling their
> whole firewall). Your configuration simplicity (or worse: your entire
> firewall) is just gone. So now you have to manage an extra firewall
> configuration, where managing just your network services gets you the
> same result. Complexity is security's worst enemy.


Point taken. I was thinking that down the line we could have a D-bus or
similar call that software could perform to request an interface be opened
to them, then we can do the whole PolicyKit authentication with ticky boxes
saying "always allow them to do this on this network". I realise this is
extra dialog boxes etc, but I think that it would be worth it.


> > Imagine you're a user who's decided
> > you'd like to start learning php for the first time:
>
> So for a start: I am definitely NOT the average desktop user.


Actually, the number of average desktop users I see trying this (or similar)
things is large enough to take note of


> > you install apache,
> > mysql and php. What's the first thing you do? Carefully comb the
> > documentation and the default configuration files, looking for security
> > holes and ways to tighten up the security of the setup or do you get
> > straight in there with the programming and learning and only worry about
> the
> > security aspects a few months down the line when you're about to put in
> your
> > first production ready server? If your answer is the second one then
> you're
> > a liar :)
>
> My answer is that I use a Linux system which is not insecure by default,
> meaning apache and mysql are bound to the loopback address by
> default. Based on this, this system does not need and has no firewalling
> by default. Moreover the package manager refuses to start MySQL until I
> have input a non-default password, giving me some extra security. I can
>

Re: The state of firewall management...

[Graham Lyon]

2009/6/24 Marc Herbert 

> Graham Lyon a écrit :
> > I'll agree that if your system doesn't have ports open by default then
> > you're fine, but if for instance your package manager pulls in mysql or
> > postfix or similar as a dependency for some package that doesn't really
> need
> > it to use its network capabilities
>
> Such a situation would be a default misconfiguration problem, and a
> very bad one since it directly affects security. I assume no package
> manager installs and starts MySQL behind the user's back, at least
> not listening to the outside world with the default password!
>

Yes, such a situation would be a misconfiguration. But, going on to say that
because this is a misconfiguration issue and therefore there is no need for
a firewall is a little foolish. The firewall would mitigate any threat that
would exist (at least on public networks) - belt and braces, etc

> then having the ability to turn on a firewall in public wifi
> > networks for instance that blocks all traffic to those services
> > would be a bonus, in my opinion.
>
> IMHO firewalling is a complicated and error-prone workaround, not the
> real fix to the misconfiguration problem above. Which Windows end user
> understands anything to its firewall configuration?


What's complicated about it?! Sorry - but that's really an incorrect
statement. As for which user understands the configuration of their
firewall, that's the whole point of this daemon - *it* understands and *it*
can do the configuration, all the user has to do is say that it's a
public/private network and the rest is taken care of.

As a matter of fact, I don't see what's so difficult and complicated about
this:
1) You've just connected to a wireless network
2) Do you know whether this is a public or private network already? If not,
ask.
3) If it's public, block all incoming traffic on that interface.

One rule, that's all. I don't see this as error prone or complicated in the
slightest.

 > Why should I have to edit the httpd config?
>
> Just because it is simpler and less error-prone than configuring a
> firewall. It is simpler and safer to close the security hole
> you created in the first place rather than from somewhere else.


Yes, however the firewall provides you with mitigation until you realise
that you've created a security hole. Imagine you're a user who's decided
you'd like to start learning php for the first time: you install apache,
mysql and php. What's the first thing you do? Carefully comb the
documentation and the default configuration files, looking for security
holes and ways to tighten up the security of the setup or do you get
straight in there with the programming and learning and only worry about the
security aspects a few months down the line when you're about to put in your
first production ready server? If your answer is the second one then you're
a liar :)

The point is that in a perfect world where we all carefully configure our
systems to be secure, the daemons are all written with perfect code with no
security weaknesses and that any code that we ourselves write (eg a
php-based site running on the apache server, or similar) is also written
perfectly and so will not have any weaknesses THEN we can not bother with a
firewall. If you think we live in this world, you're a tad naive...

You also missed my point about how, with a location aware firewall, I could
offer a service on my home network that I don't offer to my public wifi,
although I suppose that this would be achieved by turning off all network
listening daemons. For that to happen, however, we'd need all those daemons
to advertise to the init daemon what port that they are running on. This
would be difficult for daemons which can be configured to run on different
ports, although I suppose that once you've configured it to run on a
different port you're now a power user and so we no longer care about you
and shouldn't assist you with anything - infact, you should stop using
network manager and do all your network settings using ifconfig et al.
That's taking it a bit far, but it's affectively what you're saying.


For instance without a firewall you can list all your security holes with
> just a simple "netstat -l"; no added confusion.


This could just be me, but I didn't actually know about that command before
you mentioned it. Now what about your poor little idiot user who couldn't
possibly comprehend a firewall - does he know about that command?

If you need run an insecure apache instance on a regular basis,
> then I think you should always watch it very closely, not from the
> distance of a firewall.


A firewall is hardly distant, and it's hardly a bad way of doing this. I'll
admit tha

Re: The state of firewall management...

[Graham Lyon]

Why should I have to edit the httpd config? What if I want it to be
available on my LAN at home so that I can test it in IE or Safari from other
machines (or from a VM)? Also, that was a single use case - I can think of
many more.

2009/6/23 Patryk Zawadzki 

> On Tue, Jun 23, 2009 at 7:23 PM, Graham Lyon wrote:
> > Ah, but what if I wanted to sit in my local coffee shop doing some
> > development work on my website (apache running on my local machine) but
> > wanted to use their public wifi to access docs etc online. I want myself
> to
> > have access to my apache server but I want to prevent others in the
> coffee
> > shop from also having access.
>
> Just make your http server only bind to lo interface :)
>
> --
> Patryk Zawadzki
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: The state of firewall management...

[Graham Lyon]

Ah, but what if I wanted to sit in my local coffee shop doing some
development work on my website (apache running on my local machine) but
wanted to use their public wifi to access docs etc online. I want myself to
have access to my apache server but I want to prevent others in the coffee
shop from also having access. A firewall isn't only about prevention access
to network listening daemons, it's about granularity in that restriction :)

2009/6/23 Marc Herbert 

> Marc Herbert a écrit :
>
> > Sorry for ranting but I am a bit tired of the "everyone needs a
> > firewall" bullshit.
>
> Now trying to be more constructive: I would much prefer NetworkManager
> to have some kind of integration with "system-config-services" rather
> than with "system-config-firewall" (pardon my Fedora-speak, I think
> non-Fedora users will get the point anyway).
>
> Something along those lines: "You are about to connect to an untrusted
> network. Do you want to switch off network listening daemons?".
>
> Or even better, something like this:
> http://homepage.mac.com/locationmanager/screenshots.html
>
>
> It's not because Windows is lousy and not able to track listening ports
> that Linux has to copy its uselessly complex, firewall-based model. It
> can surely do simpler.
>
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: The state of firewall management...

[Graham Lyon]

I'll agree that if your system doesn't have ports open by default then
you're fine, but if for instance your package manager pulls in mysql or
postfix or similar as a dependency for some package that doesn't really need
it to use its network capabilities then having the ability to turn on a
firewall in public wifi networks for instance that blocks all traffic to
those services would be a bonus, in my opinion. Also, you're right, firewall
vendors try to push everyone to have a firewall and so, as a result, a lot
of users aren't happy with the idea that there is no firewall on their
system because they have been indocterinated into the idea that they must
have one ;)

2009/6/22 Marc Herbert 

> Hi Graham,
>
> Graham Lyon a écrit :
> > Firewalls, for the average end user, should "just work". A great many
> linux
> > distros don't come with a firewall configured by default and there is no
> > default mechanism for interfacing with a firewall and opening ports etc
> for
> > any software to use.
>
> The reason for this by the way, is that most Linux distros do not need
> a firewall at all. That is because unlike other systems, they are not
> insecure by default. I mean that most desktop distros do not have a
> number of useless and insecure daemons listening to the network by
> default. When ports are already closed by default then you obviously
> do not need the complexity of a firewall to "double-close" them!
>
> Sorry for ranting but I am a bit tired of the "everyone needs a
> firewall" bullshit. That is simply wrong (and probably pushed very
> hard by firewall vendors). Closer to the truth is: "everyone running a
> system insecure by default needs a firewall patch on top of it".
>
> So, while the average desktop Linux user simply does not need a
> firewall and is more than happy with the best firewall interface ever
> invented (= no firewall at all) *some* other users might need a
> firewall and would certainly find useful what you are suggesting. Good
> luck.
>
> Cheers,
>
> Marc
>
>
> PS: I have left for years a Windows 2000 system on-line without any
> firewall and without any problem. BUT I had explicitly disabled most
> network services beforehand. It was shamelessly far from easy to
> achieve, see for instance this:
> http://www.hsc.fr/ressources/breves/min_srv_res_win.en.html
>
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

The state of firewall management...

[Graham Lyon]

Hi,

I'm wondering what the plan of action is towards management of firewalls on
the desktop. Is this something that NetworkManager should do? I think so.
Firewalls, for the average end user, should "just work". A great many linux
distros don't come with a firewall configured by default and there is no
default mechanism for interfacing with a firewall and opening ports etc for
any software to use. I'm interested in developing a system to allow NM to
identify a network, ask the user to classify this network if it has never
been visited before, and then act accordingly (users of Windows Vista will
recognise this process). I think it's needed as the average enduser will not
give themselves a proper firewall configuration. Ever.

I have some thoughts about how this might be implemented (several
possibilities, infact) and I'd be happy to share/discuss them here before I
actually start working towards an implementation. So, before I go ahead and
write a long email detailing all my thoughts I'm just curious as to what the
overall state of firewall management is as far as NM is concerned (is
someone working on it, is it considered not the duty of NM, etc)?

-Graham
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list