Re: [PATCH] Allow NetworkManager-SSH plugin

[Dan Williams <dcbw redhat com>]

On Tue, 2013-04-02 at 11:53 +1100, Dan Fruehauf wrote:
> My findings so far about that matter, regarding VPN plugins for
> NetworkManager and their dbus policies.
> 1. Vanilla /etc/dbus-1/system.d (without the SSH rules)
> 2. Things don't work
> 3. Adding the nm-ssh-service.conf file (to allow SSH access)
> 4. Still things won't work
> 5. pgrep dbus-daemon | xargs kill -HUP
> 6. Things still won't work
> 7. Adding the specific rule in org.freedesktop.NetworkManager.conf
> 8. pgrep dbus-daemon | xargs kill -HUP
> 9. Things still don't work
> 10. /bin/systemctl reload  NetworkManager.service
> 11. We're good to go
>
> Looks like it's nice to add this patch, but altogether a restart for
> NetworkManager will be required if you install a new VPN plugin with
> policies that were not included in org.freedesktop.NetworkManager.conf
> originally.

That should not be required.  NM should be watching
the /etc/NetworkManager/VPN directory for new VPN plugins and should
recognize them.  You'll see a log message when it finds a new plugin,
like:

NetworkManager[1348]: <info> VPN: loaded org.freedesktop.NetworkManager.openswan
NetworkManager[1348]: <info> VPN: loaded org.freedesktop.NetworkManager.vpnc
NetworkManager[1348]: <info> VPN: loaded org.freedesktop.NetworkManager.openvpn
NetworkManager[1348]: <info> VPN: loaded org.freedesktop.NetworkManager.pptp
NetworkManager[1348]: <info> VPN: loaded org.freedesktop.NetworkManager.openconnect

Do you see anything in the log after dropping the .name file into the
VPN directory?

> Mmmmm. What can we do about it?
>
> Supposedly new plugins can request a restart for NetworkManager (in their
> %post) section, but that's rather ugly. Any other suggestions?

NM should never need to be restarted to find new VPN plugins.  If that's
the case, there's a bug somewhere.

Dan

> On Mon, Apr 1, 2013 at 6:52 PM, Dan Fruehauf <malkodan gmail com> wrote:
>
> > Hey guys,
> >
> > I'm sorry for the unnecessary patch, but apparently it is unneeded. Just
> > checked it without it (before submitting a bug to fedora to backport that
> > patch) and things work smoothly without it, so I guess it is not needed.
> >
> > That goes I guess for the rest of the VPN modules out there, so I'll test
> > with other VPN modules and let you guys know (so we can remove that clutter
> > at the top of org.freedesktop.NetworkManager.conf)
> >
> > BR
> > Dan.
> >
> >
> >
> >
> > On Fri, Mar 22, 2013 at 4:41 AM, Dan Williams <dcbw redhat com> wrote:
> >
> > > On Thu, 2013-03-21 at 12:05 -0500, Robby Workman wrote:
> > > > On Thu, 21 Mar 2013 10:54:59 -0500
> > > > Dan Williams <dcbw redhat com> wrote:
> > > >
> > > > > On Thu, 2013-03-21 at 11:13 +1100, Dan Fruehauf wrote:
> > > > > > Thanks for that guys.
> > > > > >
> > > > > > Sounds like the best thing to do is to actually allow the installed
> > > > > > VPN plugins to control that configuration. i.e. every VPN plugin
> > > > > > can provide a DBUS file that will allow itself to communicate with
> > > > > > NetworkManager. However with the one file - one policy type of
> > > > > > configuration in dbus it'll be rather difficult.
> > > > > >
> > > > > > On the other hand, try to count all the "famous" VPN protocols you
> > > > > > know today, there aren't that many. I don't expect 500 plugins
> > > > > > popping up tomorrow, so perhaps keeping it the way it is is not too
> > > > > > bad and we can have our efforts invested in more important things.
> > > > > >
> > > > > > But that's just my humble opinion.
> > > > >
> > > > > Yeah, best thing to do is probably to have the plugins themselves
> > > > > provide the configuration.  However, I can't recall the historic
> > > > > reasons we didn't do that, possibly upgrade-related, though the note
> > > > > there says:
> > > > >
> > > > > <!-- Allow NM to talk to known VPN plugins; due to a bug in
> > > > >      the D-Bus daemon, when a plugin is installed and the user
> > > > >      immediately tries to use it, the VPN plugin's rules aren't
> > > > >      always loaded into dbus-daemon.  Those rules allow NM to
> > > > >      talk to the plugin.  Oops.  Work around that by explicitly
> > > > >      allowing NM to talk to VPN plugins here.
> > > > > -->
> > > > >
> > > > > This was a huge bug back in the day, and i'm not 100% confident that
> > > > > it's actually been solved in the bus daemon yet.  If it was, then we
> > > > > could get rid of this block.
> > > >
> > > >
> > > > I'm pretty sure this isn't needed any more.  I may have some details
> > > > wrong, but if my memory serves me correctly, the user would have to
> > > > reload the messagebus config (have it reread its configuration) after
> > > > adding a new file in $sysconfdir/etc/dbus-1/system.d/ -- these days,
> > > > that directory has an inotify watch or some such on it, and the
> > > > daemon automatically reloads its config when a new file appears in
> > > > that directory.
> > >
> > > The directory has had inotifiy watch since the beginning actually, but
> > > as recently as a couple years ago there were a few race conditions that
> > > would cause a new file dropped there not to be recognized.  Which is
> > > what this was working around.  You're probably right though, and it's
> > > likely been fixed for quite a while.  I tried to find the specific bug
> > > just now but failed.
> > >
> > > Dan