Re: Stop nm-system-settings when NM is stopped

[Marc Herbert <Marc Herbert gmail com>]

Dan Williams wrote:

> > On Tue, 2009-04-21 at 13:39 +0200, Alexander Sack wrote:
> > > Monitoring and applying modified config files straight away is
> > > considered impolite by admins and i think its really bad practice that
> > > keyfile,rh do that. Usually admins want to decide about the "when"
> > > after they edited a config file. Think about your webserver and
> > > mailserver monitoring config files and and just reloading config when
> > > the admin saves the file - in whatever state it might be at that point
> > > ;).

> > The solution here is to not write out half-baked config files, really.

> > You don't make live edits to web pages, do you?  Same sort of thing.
>
> This little rant aside,...

Indeed...

I think your comparison with live web pages is interesting but
superficial.

In any situation you will find there is a first "working" phase
followed by a second and last "commit" phase. For various reasons
(including training and legacy = very valid reasons) different
situations implement the "commit" phase in different ways. Maybe
committing is writing the file for some people, but in the vast
majority of system administration situations committing is NOT writing
the file but "/etc/init.d/foo restart".

By the way the very fundamental reason for the "commit" concept to
exist (in any situation) is because you want several changes to be
applied atomically. Think for instance changing multiple files at
once.

I think most system administrators consider the filesystem to be their
_private_ workspace. For instance I maintain all my configuration
files using RCS and the very last thing I want is someone looking over
my shoulder when I fiddle with different file versions.

Unlike a "live" web page that is actually read again and again by the
server, I think most people consider config files NOT to be "live" but
read only on demand.


> > Or write out a temp config file, and move that to the acutal production
> > config file *when it's ready*.

Not convenient and very error-prone since against current practices.

I am afraid trying to teach sysadmins new ways to work is not going to
make you a lot of new friends.


> Also, remember that sysadmins from a text console/SSH aren't the only
> things updating these files.  And you don't want to have to code
> "restart NM" into *everything* that modifies network config either,
> whether it's an administrator, a script, a package, or another network
> config utility.

I am not sure I get this but to me this looks again like low-level
implementation details irrelevant to what should be the CLI. Could
please you elaborate?

Even if there is one big massive "restart ALL" manual CLI for the
hurried sysadmin who does not care at all about subtle engineering
optimizations, then that does not prevent these optimizations to be
provided to more clever automated scripts and config utilities. Does
it?


> Next, consider the connection editor GUI case.  It edits system
> connections too; since that's *always* immediate, there would be a huge
> behavioral discrepancy between the connection editor for system
> connections, and editing them via text file.  Not helpful.

To be honest I have seldom seen measures of discrepancy between a CLI
and a GUI... such two interfaces seem worlds apart anyway. And they
tend to be used by different users.



Because of all the above and other reasons I am actually starting to
wonder if a "naive desktop user" oriented solution like NetworkManager
can really be made to suit more server-oriented needs at the same
time.

Cheers,

Marc