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

[Dan Williams <dcbw redhat com>]

On Thu, 2009-04-23 at 10:20 +0100, Marc Herbert wrote:
> 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.

NM already uses two stages here; you change the files, they get re-read
into the system-settings service, but they *don't* get applied to
network interface until you do something like:

1) restart NM or the machine
2) re-activate the connection
3) activate a different connection you just changed
4) trip over the switch's power cable
5) unplug & replug the network cable

That's your commit phase.  These are all manual operations.  Hostname
and unmanaged devices are the only things here that don't act like this,
because hostname is system-wide and not specific to a connection.

Dan

> 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
> 
> 
> 
> 
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list