Re: dispatcher conditions

[Dan Williams <dcbw redhat com>]

On Mon, 2010-03-15 at 13:04 -0400, Yclept Nemo wrote:
> Resending this message, forgot to cc the networkmanager mailing-list.
> Stupid gmail (or me). In any case, is this thread worth filing an RFE
> on bugzilla ?

Yes please do so; the RFE should say something like adding "global-up"
and "global-down" events that trigger when the global NM 'connected'
state changes.

Dan

> On Tue, Mar 2, 2010 at 2:25 AM, Dan Williams <dcbw redhat com> wrote:
> > On Sun, 2010-02-28 at 16:45 -0500, Yclept Nemo wrote:
> >> Quick question, can the dispatcher scripts in
> >> "/etc/NetworkManager/dispatcher.d/*" be run when:
> >>  down) only when no more public interfaces remain
> >>  up) only when the first public interface is brought up
> >
> > Not entirely; 'man NetworkManager' has more details, but you will get
> > up/down events when *any* NM managed interface is taken up or down, not
> > just when there's a connection or not.  If you get a "down" event, there
> > may well be another interface that still has a connection.
> >
> > We could explore the possibility of adding two more events indicating
> > when there is any connection, and when there is no longer any
> > connection.
> 
> I think it would be fruitful to explore adding such events. Example scenario:
> Networked daemons such as ntpd need only be brought up with the first
> accessible "user" or "system" network connection (see below) and
> should only be terminated along with the last accessible connection.
> Currently bringing down any extraneous connections also stops such
> daemons. For example, a tenuous wireless connection on a laptop also
> possessing a wired network would have ntpd unnecessarily flickering on
> and off in tandem with the wireless connection.
> 
> >> I say "public" because iirc via consolekit some network connections
> >> can be exclusive to starting user? ...doesn't really matter though.
> >> I'm only dealing with the root user.
> >
> > There are "system" connections and "user" connections.  Since you're
> > only dealing with root, all your connections should probably be "system"
> > connections.  System connections are stored either by distro-specific
> > plugins, or by the distro-agnostic 'keyfile' plugin to
> > NetworkManager/nm-system-settings.
> > See /etc/NetworkManager/nm-system-settings.conf for more information, or
> > take a look at:
> >
> > http://live.gnome.org/NetworkManager/SystemSettings
> >
> 
> Thanks for the documentation and terminology. All my connections are
> "user" initiated by nm-applet - one wired and one wireless, and though
> I could convert the wired connection to a "system" connection there is
> no need. It seems that processes running as root (for example, ntpd)
> have no problem accessing "user" connections. According to
> [http://live.gnome.org/NetworkManagerConfiguration] "User connections
> are *only* available to the specified user" ... and root ?
> 
> --
> 
> On the other hand not all daemons run as root and might only be able
> to access "system" connections. Then different daemons would need to
> be stopped or started at different times.
> All these events might be a bit silly:
> [all connections down]
> [first connection up]
> [all system connections down]
> [first system connection up]
> For example the apache2 worker processes run under the "webserver"
> user and I think manage/access the network connections while the root
> apache2 process only handles user switching and startup/shutdown.
> 
> It's a bad example but this is out of my league. Unlike apache, ntpd
> needs to be started with access to a time server in order to
> immediately set the clock. Honestly this dispatcher script would work,
> but it seems crude:
> up) /etc/rc.d/openntpd restart # long (unnecessary) time changes after
> boot-up can adversely affect other daemons
> down) "explicit_do_nothing_function" # possibly let ntpd timeout
> *) echo "not cool"
> 
> so...
> 
> thanks,