I should have mentioned that this is my first package for Fedora Extras and I'm
seeking a "sponsor".

I built the RPM in mock on a system running -devel and tried to connect to a
server running on FC4.  It would seem that the 2.1 version of OpenVPN that is in
-devel extras is turning on "--redirect-gateway" by default, which is DEFINITELY
not what I want.  I have verified that the server is not configured to send
redirect-gateway and the --redirect-gateway is not defined on the OpenVPN
command line invoked by NetworkManager.  Is there some way to disable this behavior?

I have read the new man page and it states what you say. It does not seem that
there is a way to disable this feature at the moment. I can't see any postings
to the OpenVPN devel list that mention this problem. Since what this flag does
is exactly what NM already does there should be a way to disable this option. I
will send an email to their mailinglist stating this problem. Thanks for
pointing this out.

I have initiated a discussion about this. You can follow the thread and post
your findings to  the OpenVPN-devel list. See the thread at
http://thread.gmane.org/gmane.network.openvpn.devel/1390

I'm not sure what caused you problems, Jeffrey, but it was stated now on the
OpenVPN mailinglist (see link in earlier posting) that this will not become the
default. So this problem should be cleared.

Is there someone willing to sponsor this package?

Is it NetworkManager itself then that is changing my default route then? 

Yes. If you don't want that set the list of networks that should be routed via
the VPN in the optional information expander. This will cause NM to only route
these networks over the VPN and not the default route.

Aha... I'll have to try that when I get home.  I haven't tried any other VPN
plugins so I was thinking that that field controlled when the VPN service got
activated.  While whether to replace the default gateway by default could be
debated either way, the wording of the option leaves something to be desired. 
That's a matter for the NetworkManager list though.

Is there a way that you could package v0.3.1 for testing?

Done. Download from
http://www.niemueller.de/software/patches/NetworkManager-openvpn-0.3.1-1.src.rpm

Is there someone willing to sponsor this to get it into Extras finally?

NetworkManager-openvpn no longer builds against the NetworkManager that is in
development:

nm-openvpn-service.c:48:46: error: NetworkManager/NetworkManagerVPN.h: No such
file or directory

Couple of things:

change /usr/bin/ to %{_bindir}
Put a period at the end of your %description

I built the rpm from the srpm noted in Comment #9 and installed.

When I tried to start the vpn, the vpn was initiated and worked, but I got these
messages in my /var/log/messages file:

Feb 14 11:40:18 localhost nm-openvpn[2658]: TUN/TAP device tun0 opened
Feb 14 11:40:18 localhost nm-openvpn[2658]: /sbin/ip link set dev tun0 up mtu 1500
Feb 14 11:40:18 localhost nm-openvpn[2658]: /sbin/ip addr add dev tun0 local
10.1.1.6 peer 10.1.1.5
Feb 14 11:40:18 localhost nm-openvpn[2658]:
/usr/bin/nm-openvpn-service-openvpn-helper tun0 1500 1542 10.1.1.6 10.1.1.5 init
Feb 14 11:40:18 localhost NetworkManager: <WARNING>      get_dbus_guint32_helper
(): Error: couldn't get IP4 VPN Local Netmask from VPN IP Config message.
Feb 14 11:40:18 localhost NetworkManager: <WARNING>     
nm_vpn_service_stage4_ip_config_get ():
nm_vpn_service_stage4_ip_config_get(org.freedesktop.NetworkManager.openvpn): did
not receive valid IP config information.

Even though you can see that the tun was assigned an address (and the remote
network was reachable), NetworkManager thinks that it didn't receive valid IP4
information.

Because of this, there is no status in NetworkManager that indicates I've
connected to a vpn and the disconnect option is not available.

I'm not sure if this is a problem with NetworkManager or NetworkManager-openvpn.

dbus-0.60-7.2
NetworkManager-0.5.1-12.cvs20060213

I, for one, appreciate this package and would like to see it sponsored and moved
forward.

Any updates on this package?  I'm sure that I'm not the only one that would like
to see this get into extras.

Tim, can you roll a new(er) srpm?

I'd like to see this in extras too.

I'm currently investigating some problems in the code, when that is done I will
post a new version of the srpm. Expect this for next week.

Ping ? Any news ?

Tim,

I can understand that you may've got a bit frustated because of the lack of
someone willing to sponsor you in the beginning of this Review where you were
very responsive. However currently your responsiveness is lacking.

If you can become once again as responsive as in the beginning and post a new
version, then I'll review it and sponsor you under the condition that someone in
the CC-list does some funtionality testing as I currently have no need for this
myself.

(In reply to comment #19)
>
> If you can become once again as responsive as in the beginning and post a new
> version, then I'll review it and sponsor you under the condition that someone in
> the CC-list does some funtionality testing as I currently have no need for this
> myself.

I'm certainly willing to do the testing, esp when my replacement laptop arrives.

Just some feedback: I will put a new version online ASAP. The problem is right
now that we are preparing for the RoboCup 2006 robot soccer tournament that we
are heading for next week (http://www.robocup2006.org) and I probably won't make
it before that event (just a side note: robots work just fine with FC3 :-) ).
Will be back around June 20th and will push a new version by then at the latest.

Ok, waiting until 20-6 (or so) is no problem, no need to hurry.

It's now a couple of weeks past June 20th; anything happening here?

I have put a new version of the package (0.3.2) together based on the NM 0.6
branch in CVS. I tested it with the current version of NetworkManager from
FC5-updates. You can find my source RPM here:
http://www.niemueller.de/software/patches/NetworkManager-openvpn-0.3.2-1.src.rpm
There is also a new spec at the location mentioned in the first post.

Observations:

1) When a new VPN is added, it does not appear until after NetworkManager is
restarted.  Ideally, it would show up immediately.

2) There is still some interaction with selinux that needs to be dealt with
(this output was run in permissive mode to capture full set of messages):

Jul 10 18:25:24 localhost kernel: audit(1152577524.671:21): avc:  denied  {
node_bind } for  pid=2781 comm="openvpn" saddr=127.0.0.1 src=1194
scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:lo_node_t:s0 tclass=tcp_socket
Jul 10 18:25:24 localhost kernel: audit(1152577524.671:22): avc:  denied  {
search } for  pid=2781 comm="openvpn" name="etc" dev=dm-1 ino=818771
scontext=system_u:system_r:NetworkManager_t:s0
tcontext=user_u:object_r:user_home_t:s0 tclass=dir
Jul 10 18:25:24 localhost kernel: audit(1152577524.671:23): avc:  denied  { read
} for  pid=2781 comm="openvpn" name="bjohnson.crt" dev=dm-1 ino=818840
scontext=system_u:system_r:NetworkManager_t:s0
tcontext=user_u:object_r:user_home_t:s0 tclass=file
Jul 10 18:25:24 localhost kernel: audit(1152577524.671:24): avc:  denied  {
getattr } for  pid=2781 comm="openvpn" name="bjohnson.crt" dev=dm-1 ino=818840
scontext=system_u:system_r:NetworkManager_t:s0
tcontext=user_u:object_r:user_home_t:s0 tclass=file
Jul 10 18:25:30 localhost kernel: audit(1152577530.332:25): avc:  denied  { read
write } for  pid=2781 comm="openvpn" name="tun" dev=tmpfs ino=1315
scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:tun_tap_device_t:s0 tclass=chr_file
Jul 10 18:25:30 localhost kernel: audit(1152577530.332:26): avc:  denied  {
ioctl } for  pid=2781 comm="openvpn" name="tun" dev=tmpfs ino=1315
scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:tun_tap_device_t:s0 tclass=chr_file

3) On the "Create VPN Connection 2 of 2" screen, if you click the "Optional
Information" area, the window expands well outside of the borders of my display
(1440x900).  I would guess that you want to try to stay near the lowest common
denominator, maybe 600 pixels tall.

Other than that, it looks good, and useful (bug from comment #9 is gone).

(In reply to comment #25)
> Observations:
> 
> 1) When a new VPN is added, it does not appear until after NetworkManager is
> restarted.  Ideally, it would show up immediately.

This is a bug in Network Manager's VPN support from what I recall, and is not
specific to the Network Manager OpenVPN plugin.

> 2) There is still some interaction with selinux that needs to be dealt with
> (this output was run in permissive mode to capture full set of messages):

This isn't specific to the Network Manager OpenVPN plugin.  I've had the same
problem with starting OpenVPN manually and recent SELinux policies.   This command:

setsebool -P openvpn_disable_trans 1

should disable SELinux for OpenVPN (and you shouldn't even need to reboot).

(In reply to comment #25)

1) NM-problem
2) Needs fixes for the OpenVPN-package/SELinux policy for OpenVPN
3) This is true. It seems that after the last patch we finally reached the size
where we need either more tabs or a popup with these settings.

> Other than that, it looks good, and useful (bug from comment #9 is gone).

Maybe you meant comment 11?

Hans, are you going to sponsor this now?

Regarding comment #27

When I get a spare moment, I'll file bugs for #1 and #2.  In regards to #3, I
was actually referring to commment #13, which is no longer a problem for me.

For those trying to keep track,

#1 from comment #25 is already filed as bug #185992.

I have fixed the SELinux issues with using openvpn manually by using a local
policy module:

http://www.redhat.com/archives/fedora-selinux-list/2006-July/msg00036.html

I expect this will get fixed in the next policy update.

(In reply to comment #27)
> Hans, are you going to sponsor this now?

Tim,

I'm not sponsering it (the package) but you. Packages get approved and any FE
contributer can approve, sponsering is about giving a person access to the the
CVS-server, buildsys etc.

And I'm not sure about this yet. You seem to come and go you said you would be
away untill the 20st of june and I said that wouldn't be a problem, it however
got somewhat longer. Even though we are all volunteers we expect a certain
amount of involvement from contributers, this starts with responding to
communications in a timeley matter.

Besides this there also is the issue that in order to get CVS and buildsys
access you must first show a thorough understanding of the Fedora Extras
guidelines and procedures. Usually just having one package in approvable state
(it cannot be approved until you are sponsored) is not enough to show this
understanding, possible ways of showing this understanding are:
1) reviewing other peoples packages (note add a note to the review that you 
  aren't sponsored / a contributer yet and thus cannot do official reviews /
  approve. When you do this put me in the CC of the bug so I know that you're
  doing this
2) create a couple of more packages and let me know then I'll review this and
  the others and usually after 2 or 3 packages I'm satisfied that you know what
  you're doing

Is there any way this can be expedited (its been in the queue for over 6
months), so someone should sponsor his upload, even if we don't give him Extras
CVS access.

There's no way to sponsor an upload.  Either he maintains the package and has
the access necessary to do so or not.

We're trying to work out a better solution to this problem, but the issue is
difficult as long as commit access to one package gives access to all of the others.

I had some RPMs before Fedora Extras came up
(http://www.niemueller.de/projects/extrpms/) which I got space for on SunSITE
Europe. To get this going I would suggest to package Asuka (IRC daemon) and
Palantir (webcam streaming) for Fedora Extras. I'll give it a go and CC you
(Hans) on the review request.

I have filed requests for the mentioned packages as #199919 and #199920.

(In reply to comment #34)
> I had some RPMs before Fedora Extras came up
> (http://www.niemueller.de/projects/extrpms/) which I got space for on SunSITE
> Europe. To get this going I would suggest to package Asuka (IRC daemon) and
> Palantir (webcam streaming) for Fedora Extras. I'll give it a go and CC you
> (Hans) on the review request.

Sounds good, I'll review this + the other 2 then and assuming you show a
reasonable response time (if you need a number say within a week) during the
review process and show some packaging skills I'll sponsor you.

Okay, here is a full review for this one, I'll do the other 2 you mentioned as
time permits.

MUST:
=====
O rpmlint output is:
E: NetworkManager-openvpn explicit-lib-dependency libglade2
E: NetworkManager-openvpn explicit-lib-dependency libgnomeui
W: NetworkManager-openvpn no-url-tag
W: NetworkManager-openvpn devel-file-in-non-devel-package
/usr/lib64/libnm-openvpn-properties.so
W: NetworkManager-openvpn non-conffile-in-etc
/etc/dbus-1/system.d/nm-openvpn-service.conf
E: NetworkManager-openvpn zero-length
/usr/share/doc/NetworkManager-openvpn-0.3.2/NEWS
W: NetworkManager-openvpn non-conffile-in-etc
/etc/NetworkManager/VPN/nm-openvpn-service.name
W: NetworkManager-openvpn-debuginfo no-url-tag
W: NetworkManager-openvpn no-url-tag
W: NetworkManager-openvpn prereq-use %{_bindir}/update-desktop-database
W: NetworkManager-openvpn prereq-use %{_bindir}/gtk-update-icon-cache
See Must FIX list.
* Package and spec file named appropriately
* Packaged according to packaging guidelines
O License (GPL) ok, but license file not included
* spec file is legible and in Am. English.
O Source matches upstream ?? (couldn't verify, but you are upstream right?)
* Compiles and builds on devel-x86_64
* BR: ok (see below)
* No locales
* No shared libraries
* Not relocatable
* Package owns / or requires all dirs (with some strangeness see Must fix below)
* No duplicate files & Permissions ok
* %clean & macro usage OK
* Contains code only
* %doc does not affect runtime, and isn't large enough to warrent a sub package
* no -devel package needed, no libs / .la files.
* no gui -> no .desktop file required


MUST fix:
=========
* The followjng rpmlint output:
E: NetworkManager-openvpn explicit-lib-dependency libglade2
E: NetworkManager-openvpn explicit-lib-dependency libgnomeui
Why explicitly require these, explicit requires are ok if you want to force a
certain version, but since these requires are versionless, the autodep rpm does
on dso's should suffice or?

W: NetworkManager-openvpn devel-file-in-non-devel-package
/usr/lib64/libnm-openvpn-properties.so
Is this needed for dl-opening by NetWorkManager, if not, is this needed at all?

W: NetworkManager-openvpn non-conffile-in-etc
/etc/dbus-1/system.d/nm-openvpn-service.conf
You must mark this %config (just put %config in front of the line) normally we
always use %config(noreplace) in FE, bubt I don't know if thats appropiate here.

E: NetworkManager-openvpn zero-length 
/usr/share/doc/NetworkManager-openvpn-0.3.2/NEWS
Please don't package this empty file

W: NetworkManager-openvpn non-conffile-in-etc 
/etc/NetworkManager/VPN/nm-openvpn-service.name
You must mark this %config (just put %config in front of the line) normally we
always use %config(noreplace) in FE, bubt I don't know if thats appropiate here.

W: NetworkManager-openvpn prereq-use %{_bindir}/update-desktop-database
W: NetworkManager-openvpn prereq-use %{_bindir}/gtk-update-icon-cache
Do not use PreReq, it has issues. Instead use Requires(post): xxx and
Requires(postun): xxx

* Add a Requires(post) (and postun): /sbin/ldconfig
* Why no %{?_smp_mflags} after make? either add a comment why tis admitted or
  add it.
* %install must start with: "rm -fr %{buildroot}"
* %makeinstall has issues (see f-e-l archives) instead use
  "make install DESTDIR=%{buildroot}"


Should fix:
===========
* Do I understand correctly that you are upstream for this package? If so
  I'll assume that the included tarbal matches upstream. Still it would be nice
  to provide the tarbal for download from your site and use a full URL as
  Source0. (rpmlint: W: NetworkManager-openvpn no-url-tag)
* You should include a COPYING in the tarbal and in %doc
* "rm -f %{buildroot}%{_libdir}/lib*.a" why not just add --disable-static to
  %configure that reduces build time quite a bit. while you're add it also add
  --disable-dependency-tracking


Questions:
==========
* Why is this there? "## %find_lang %{name}" (similar for %files)

A new package is available at
http://www.niemueller.de/projects/extrpms/packages/fedora-extras-5/NetworkManager-openvpn-0.3.2-2.src.rpm
(the spec is available at
http://www.niemueller.de/projects/extrpms/packages/fedora-extras-5/NetworkManager-openvpn.spec
now). Cleaned up and incorporated most suggestions.

Upstream: It's from the 0.6 branch (0.6.4 tag) from CVS. The more recent
versions are incompatible because the VPN DBUS API has changed.
There are no tarballs, source is only available in CVS, thus no URL tag for now.

Four warnings remain:
W: NetworkManager-openvpn no-url-tag
explained above

W: NetworkManager-openvpn conffile-without-noreplace-flag
/etc/NetworkManager/VPN/nm-openvpn-service.name
W: NetworkManager-openvpn conffile-without-noreplace-flag
/etc/dbus-1/system.d/nm-openvpn-service.conf

These are directly relevant to a functioning service and should not be modified,
thus I did not add noreplace (for if the files have to change during an
upgrade). If it is policy to add noreplace anyway I can easily do this but from
my understanding this is just error prone.

W: NetworkManager-openvpn devel-file-in-non-devel-package
/usr/lib/libnm-openvpn-properties.so

This is needed, it contains the GUI for configuring the VPN and is called from
inside NM (to be more precise: nm-vpn-properties).

The find_lang has been removed for now. It should be used for i18n support but
only threw errors so I commented it out.

The URL tag is required... It should probably point to
<http://www.gnome.org/projects/NetworkManager/>.  It's not a link to the source.

Since you are using a CVS snapshot, you should include comments on how to
recreate the snapshot.  Also, since this is a CVS snapshot "autogen.sh" has
never been run before.  This script requires gnome-common, automake, autoconf,
libtool, and intltool none of which are available by default in the FE build
system.  So you'd either need to BuildRequire them, or run autogen.sh manually
in the directory before you create the tarball.  I'd go with the 2nd option...
it'll keep things cleaner.

Other than that it seems to build fine.

Creating a VPN connection seemed worked fine (the mouse on this laptop is
getting flaky so I'm sure any difficulty I had was due to that), other than the
known problem with VPN connections not showing up until you restart the
NetworkManager applet.

However, when I actually tried to connect to the new VPN connection I made,
SELinux threw a fit:

kernel: audit(1155005417.964:12): avc:  denied  { execute } for  pid=2924
comm="nm-openvpn-serv" name="openvpn" dev=dm-0 ino=758428
scontext=user_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:openvpn_exec_t:s0 tclass=file

This would sometimes cause the NetworkManager daemon to crash:

NetworkManager: file nm-vpn-service.c: line 459
(nm_vpn_service_stage3_connect_cb): assertion failed: (service != NULL)

(BTW, I'm testing with NetworkManager 0.6.4 from FC5).

For purposes of testing, I disabled SELinux for NetworkManager by changing the
NetworkManager_disable_trans SELinux boolean variable.  Before this package gets
accepted a more permanent solution needs to be found.

Once the SELinux problems were bypassed the VPN connection seemed to work fine.
 I couldn't check for sure because I was connecting to my home VPN server from
inside my home network.  Once I'm back at work tomorrow I check that out for sure.

Created attachment 133778 [details]
SELinux policy modules for NetworkManager-openvpn

Please try the attached SELinux policy modules (myNetworkManager and
myopenvpn), which should allow NetworkManager to run openvpn under SELinux.

For details of how to build modules:
http://www.city-fan.org/tips/BuildSeLinuxPolicyModules

To install the modules once built:
# semodule -i myNetworkManager.pp -i myopenvpn.pp

It seems as if this is a problem with the openvpn package and should be solved
there, correct? If so please propose this patch to either the selinux policy or
the openvpn package (and provide a link to the bugzilla id here). If not please
explain to me why this is NetworkManager-openvpn specific.

If the fixes work, I'll get them included in the upstream selinux-policy
package. What I'm asking here is for someone actually using this package with
SELinux enabled to try them out and see if they fix the issues.

(In reply to comment #38)
> A new package is available at
>
http://www.niemueller.de/projects/extrpms/packages/fedora-extras-5/NetworkManager-openvpn-0.3.2-2.src.rpm
> (the spec is available at
>
http://www.niemueller.de/projects/extrpms/packages/fedora-extras-5/NetworkManager-openvpn.spec
> now). Cleaned up and incorporated most suggestions.
> 
> Upstream: It's from the 0.6 branch (0.6.4 tag) from CVS. The more recent
> versions are incompatible because the VPN DBUS API has changed.
> There are no tarballs, source is only available in CVS, thus no URL tag for now.
> 
> Four warnings remain:
> W: NetworkManager-openvpn no-url-tag
> explained above
> 

Okay, please add a comment above source0 with the bash commands which can be
used to recreate the tarbal (I know the tarbal might not be the same because
CVS has chanced, but thats ok).
> W: NetworkManager-openvpn conffile-without-noreplace-flag
> /etc/NetworkManager/VPN/nm-openvpn-service.name
> W: NetworkManager-openvpn conffile-without-noreplace-flag
> /etc/dbus-1/system.d/nm-openvpn-service.conf
> 
> These are directly relevant to a functioning service and should not be modified,
> thus I did not add noreplace (for if the files have to change during an
> upgrade). If it is policy to add noreplace anyway I can easily do this but from
> my understanding this is just error prone.
> 

OK

> W: NetworkManager-openvpn devel-file-in-non-devel-package
> /usr/lib/libnm-openvpn-properties.so
> 
> This is needed, it contains the GUI for configuring the VPN and is called from
> inside NM (to be more precise: nm-vpn-properties).
>

OK
 
> The find_lang has been removed for now. It should be used for i18n support but
> only threw errors so I commented it out.
> 

OK


TODO:
-Add an URL tag (see previous comments by others)
-Add comments to Source0 to explain how the tarbal was created
-Remove this as its probably no longer needed:
 "rm -f %{buildroot}%{_libdir}/lib*.a", if it is still needed then the
 --disable-static %configure argument isn't working and should be removed
-Remove these 2 lines:
 Requires(post): %{_bindir}/gtk-update-icon-cache
 Requires(postun): %{_bindir}/gtk-update-icon-cache
 These are not needed / unwanted, the scrip checks for existence of this
 file before using it and if its not there there is no reason to call it.

Once these are done (assuming you agree with the proposed changes) I'll approve
this and sponsor you. Feel free to create an account in the account system /
request FE membership if you alreadty have one, then I can approve and sponsor
in one go.



"

(In reply to comment #43)

I have uploaded a new version of the package with the suggested changes. The
SRPM is available at
http://www.niemueller.de/projects/extrpms/packages/fedora-extras-5/NetworkManager-openvpn-0.3.2-4.src.rpm

Created attachment 134200 [details]
Log of connection with SELinux openvpn policy module

It seems that it does not work. I'm using the targeted policy in permissive
mode (it just does not work with enforcing, so many simple little details fail,
coding is a hassle with selinux enabled etc.).

See the dmesg log for the problems. It seems that the management connection
(local TCP socket) is not allowed and access to the user's certificate files is
denied (it's in the user home directory somewhere probably), also there seems
to be a problem with the dbus communication.

(In reply to comment #44)
> (In reply to comment #43)
> 
> I have uploaded a new version of the package with the suggested changes. The
> SRPM is available at
>
http://www.niemueller.de/projects/extrpms/packages/fedora-extras-5/NetworkManager-openvpn-0.3.2-4.src.rpm
> 

Looks good, approved! I've sponsored you now as promised so you should be able
to import this.


(In reply to comment #45)
> Created an attachment (id=134200) [edit]
> Log of connection with SELinux openvpn policy module
> 
> It seems that it does not work. I'm using the targeted policy in permissive
> mode (it just does not work with enforcing, so many simple little details fail,
> coding is a hassle with selinux enabled etc.).
> 
> See the dmesg log for the problems. It seems that the management connection
> (local TCP socket) is not allowed and access to the user's certificate files is
> denied (it's in the user home directory somewhere probably), also there seems
> to be a problem with the dbus communication.

Thats unfortunate, still this review has been going on long enough as is, please
add a big FAT warning to %description, and maybe somewhere in the docs that
selinux needs to be in permissive mode for this to work :|

After adding this to owners.list, please open a seperate bug with
NetworkManager-openvpn as component to track the SELinux issues, and post a link
to that bug here for reference.

Do the certificate files *have* to be the user's home directory (this is a
biggie for SELinux, which likes to keep "user" and "system" space as far apart
as possible), or could they go in the usual /etc/openvpn place?

In general this will not be possible. Since connections are user-specific
settings certificates are user-specific, too. We authenticate users, not
machines. And users do not have write permission in /etc/openvpn anyway. And
since NM is the gateway from the user to the system space for networking stuff
this makes sense. There may be the need then to communicate certificates through
in NM in the worst case. For now I think the policy should allow openvpn to read
the certificates from the user's home until we found a better solution.

I have checked in the package to Extras and have built the current version
successfully for devel. Now I'm waiting for the module to appear in bugzilla to
add the SELinux bug. Paul, did you make any progress on that end? An FC-5 branch
has been requested but no one has dropped by yet, probably due to the weekend or
so. So we're close to get this bug closed.

I've not had time to do anything with the SELinux policy yet. Can you please CC
me on the SELinux bug when you raise it?

I'm thinking of creating an SELinux boolean to allow openvpn to read files from
users' home directories (off by default), much like the one for spamassassin.

Can this bug be closed now? There is a NetworkManager-openvpn bugzilla 
component now... 

This package has been imported and build, so I see no reason for leaving this
ticket open, closing.

I know there are still SELinux issues but those _really_ belong in a seperate bug.

Package Change Request
======================
Package Name: NetworkManager-openvpn
New Branches: EL-5
New branch owner: lkundrak

Christoph Höger: "I do not use a RHEL Desktop and do not have any
experience with EPEL I would propably do a bad job maintaining it.
So I think it's better if you take the maintainership for EPEL."

cvs done.

Type the following command in terminal:

$ sudo apt-get install network-manager-OpenVPN

If that fails please also install below:

$ sudo apt-get install network-manager-OpenVPN-gnome

any help related to router get help from this www.belkinroutersupportnumber.com/

Type the following command in terminal:

$ sudo apt-get install network-manager-OpenVPN

If that fails please also install below:

$ sudo apt-get install network-manager-OpenVPN-gnome

any help related to router get help from this  <ahref="www.belkinroutersupportnumber.com/">Belkin Support</a>