Bug 243535 - NM cannot open vpnc properties page (fix known)
Summary: NM cannot open vpnc properties page (fix known)
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager-vpnc   
(Show other bugs)
Version: 7
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Denis Leroy
QA Contact: Fedora Extras Quality Assurance
Keywords: Reopened
: 248105 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-09 15:12 UTC by Tim Niemueller
Modified: 2018-04-11 06:54 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-17 06:44:40 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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

Description Tim Niemueller 2007-06-09 15:12:26 UTC
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

It turn's out that in /etc/NetworkManager/VPN/nm-vpnc-service.name it reads:
while on the x86_64 system it should be

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

How reproducible:

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 15:25:00 UTC
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 15:28:49 UTC
Hows does the openvpn package solve this then so that the correct file has been

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 15:37:05 UTC
Again, not really sure.  It goes against all I know about rpm packages.

Comment 4 Christopher Aillon 2007-06-09 15:38:07 UTC
Anyway, this really belongs to be filed against NetworkManager-vpnc

Comment 5 Denis Leroy 2007-06-13 19:45:15 UTC
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 19:51:58 UTC
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 08:53:57 UTC
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 10:24:12 UTC
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 15:42:58 UTC
Actually, it _is_ a bug.  Multilib packages *must* be parallel installable.

Comment 10 Christopher Aillon 2007-06-14 15:48:06 UTC
I just filed http://bugzilla.gnome.org/show_bug.cgi?id=447577 to track this.

Comment 11 Denis Leroy 2007-06-17 12:00:26 UTC
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-22 00:14:09 UTC
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

Comment 13 Need Real Name 2007-08-03 16:09:30 UTC
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 19:30:55 UTC
except it didnt work when i tried that.

Comment 15 Denis Leroy 2007-08-17 06:44:40 UTC
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 11:24:12 UTC
*** 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.