Re: [PATCH] Allow NetworkManager-SSH plugin



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.

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?




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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]