No error is returned to user if system settings plugin fails connection update

[Andrey Borzenkov]

Using NM 0.8 + nm-applet 0.8 I hit the following situation - if ->update 
plugin method fails (for whatever reason - e.g. plugin is not able to 
create necessary file) - no error is returned to user. Error is 
correctly returned if creation of new system connection fails.

I start nm-connection-editor and select system connection to modify. I 
correctly get authentication request and am able to modify connection 
(and save changes if no errors happened). But if there are errors inside 
of plugin during updating of connection settings, very funny situation 
results - logical state of NM is updated (i.e. if I start n-c-e again, I 
see my changes) but state in files on permanent storage is not updated, 
meaning restarting NM show again previous configuration.

I verified that plugin really returns error, error is correctly set and 
plugin should be calling callback (in this case con_update_cb). This 
unfortunately pretty much ends my ability to debug it further - I am not 
good at D-Bus internals.

Background - I am working on system settings plugin for Mandriva (which 
diverged significantly from RH). Plugin is based on ifcfg-rh, at least 
w.r.t. interface to the rest of NM. Because Mandriva does not fully 
implement everything that is offered by NM (e.g. - no IPv6, no LEAP etc) 
- I expected being able to return error from plugin during update to 
inform user that settings are not supported. It does not work :( If it 
is possible to indicate "parameter not supported" in advance, it would 
be just fine (although bug still remains :)

Thank you!

-andrey


signature.asc
Description: This is a digitally signed message part.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

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

[Larry Finger]

On 02/27/2010 11:05 AM, Graham Lyon wrote:
> 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?

If you move around and connect to multiple AP's, traditional runlevel control is
a PITA. With NM, you can create the new connection with the GUI. If it already
exists, a single click brings it up. For systems with only wired connections, I
don't use it, but if it has wireless, it is very useful.

Larry

___
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: "/etc/init.d/NetworkManager quit" ?

[Dominik George]

> 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 ;)).



signature.asc
Description: OpenPGP digital signature
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list