Bug 243535 - NM cannot open vpnc properties page (fix known)
NM cannot open vpnc properties page (fix known)
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager-vpnc (Show other bugs)
7
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Denis Leroy
Fedora Extras Quality Assurance
: Reopened
: 248105 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-09 11:12 EDT by Tim Niemueller
Modified: 2007-11-30 17:12 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-17 02:44:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 447577 None None None Never

  None (edit)
Description Tim Niemueller 2007-06-09 11:12:26 EDT
Description of problem:
Creating a vpnc connection is not possible with NM on x86_64, while creating an
OpenVPN connection is. The problem became obvious when running nm-vpn-properties
on the console:
** (nm-vpn-properties:7905): WARNING **: Cannot open module
'/usr/lib/libnm-vpnc-properties'

It turn's out that in /etc/NetworkManager/VPN/nm-vpnc-service.name it reads:
properties=/usr/lib/libnm-openvpn-properties
while on the x86_64 system it should be
properties=/usr/lib64/libnm-openvpn-properties

As said for the OpenVPN module this is correct in the config file. Is that a
problem with both the i386 and x86_64 packages being installed (automatically)
and the i386 version coming first?

Changing the mentioned line made the configuration working.

Version-Release number of selected component (if applicable):
# rpm -qa --queryformat "%{name}-%{version}.%{arch}\n" | grep NetworkManager
NetworkManager-glib-0.6.5.i386
NetworkManager-glib-0.6.5.x86_64
NetworkManager-vpnc-0.6.4.x86_64
NetworkManager-vpnc-0.6.4.i386
NetworkManager-openvpn-0.3.2.i386
NetworkManager-openvpn-0.3.2.x86_64
NetworkManager-0.6.5.x86_64
NetworkManager-0.6.5.i386
NetworkManager-gnome-0.6.5.x86_64


How reproducible:
Always

Steps to Reproduce:
1. nm-vpn-properties (see error message on console)
2. try to create VPN connection, vpnc is not offered
Comment 1 Christopher Aillon 2007-06-09 11:25:00 EDT
This is tricky because doing that would lead to conflicts when installing
multilib... Both 32 and 64 bit versions need to contain identical text-based
files.  I'm not really sure how the openvpn packages avoided conflicts.
Comment 2 Tim Niemueller 2007-06-09 11:28:49 EDT
Hows does the openvpn package solve this then so that the correct file has been
installed?

Is the i386 version needed anyway? Since I'm using only the 64-Bit version I
guess I don't know. Although the packages contain a shared object, it's not a
generally used library but just a plugin for the properties application. Is
there a way to command that only the x86_64 is installed and not the i386 version?
Comment 3 Christopher Aillon 2007-06-09 11:37:05 EDT
Again, not really sure.  It goes against all I know about rpm packages.
Comment 4 Christopher Aillon 2007-06-09 11:38:07 EDT
Anyway, this really belongs to be filed against NetworkManager-vpnc
Comment 5 Denis Leroy 2007-06-13 15:45:15 EDT
There's no difference between openvpn and vpnc in this case. In your setup, you
must have installed the RPMs in a different order, with the i386 version of the
vpnc package installed last. If you do

  sudo yum -y remove NetworkManager-openvpn NetworkManager-vpnc
  sudo yum -y install NetworkManager-openvpn NetworkManager-vpnc


you should have the correct lib64 path in both files. Could you verify that ?

This bug i think highlight the major issues we have with our wide-scale support
for multilib. Note that if you try to install the RPMs manually, rpm will fail
with a conflict (both for openvpn and vpnc). Yum just ignore those errors and
install stuff it shouldn't...

Is there any reason NetworkManager has multilib support ?

Comment 6 Christopher Aillon 2007-06-13 15:51:58 EDT
The reason is that it has a -devel subpackage and all packages with -devel are
defined to be multilib, currently.
Comment 7 Tim Niemueller 2007-06-14 04:53:57 EDT
Joup, after re-installing the correct version of the config file is installed.
But also last time I installed it via yum, this machine was originally installed
with the last F7 Test version and is now running F7.
Comment 8 Denis Leroy 2007-06-14 06:24:12 EDT
Closing as not a bug then. This is more of an unfortunate side-effect of
multilib, some of which are not yet fully understoood.
Comment 9 Christopher Aillon 2007-06-14 11:42:58 EDT
Actually, it _is_ a bug.  Multilib packages *must* be parallel installable.
Comment 10 Christopher Aillon 2007-06-14 11:48:06 EDT
I just filed http://bugzilla.gnome.org/show_bug.cgi?id=447577 to track this.
Comment 11 Denis Leroy 2007-06-17 08:00:26 EDT
I can confirm that simply removing the absolute path from the service file
properties entry fixes the problem, with no modifications necessary to the
NetworkManager package. So all we need is an update to NetworkManager-vpnc and
NetworkManager-openvpn. I'll push the NetworkManager-vpnc update shortly.
Comment 12 Christopher Aillon 2007-06-21 20:14:09 EDT
I just committed a slightly better fix upstream.  We can rely on ${LIB} being
properly expanded so we're now using that to guarantee we get the correct shared
object.
Comment 13 Need Real Name 2007-08-03 12:09:30 EDT
Comment from the peanut gallery:

The developer in me thinks that not specifying the absolute path at all is
probably the most reliable approach.

Part of the point of dynamic libraries is to let ld figure out The Right Thing
to do ... the thin savings of avoiding searching through several ld library
paths doesn't seem to me to be enough incentive to decide in favor of providing
the absolute path to a dynamic library in a config file.

Just my two cents ... after all, YOU guys are the professionals ...     :^]

Comment 14 Christopher Aillon 2007-08-10 15:30:55 EDT
except it didnt work when i tried that.
Comment 15 Denis Leroy 2007-08-17 02:44:40 EDT
Hmm, it did work for me when I tried it. Anyways, it's not terribly important.
Built for F-8.
Comment 16 Matěj Cepl 2007-08-17 07:24:12 EDT
*** Bug 248105 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.