(In reply to comment #0)
> Know problem: Doesn't work if Selinux is in enforcing mode; that afaics is a
> problem in strongswan; I'll file a bug after filing this review request

Bug 863839

About selinux, I was carefully managing Strongswan so that it doesn't conflict with Openswan at all and could (1) be installed together with Openswan and (2) avoid being affected by Openswan selinux policy.

Strongswan is currently not affected by any policy. But NetworkManager is.

Pabvel, in Bug 863839 Comment #5 you wrote:

> I haven't yet tried to build Thorsten's package at all. I'm only using
> Strongswan and that is currently unconfined except when run from the
> NetworkManager plugin. I don't yet even know how the plugin actually works.
> 
> I will definitely try it but it will take a bit time before I can afford to
> spend time with it.

Can I hope that you sooner or later will review this? If the answer is something like a "yes, likely" I'll save myself the trouble looking for a reviewer.

(In reply to comment #3)
> Pabvel, in Bug 863839 Comment #5 you wrote:
    ^^^

Sorry for the typo; I know it's Pavel.

> Can I hope that you sooner or later will review this? If the answer is
> something like a "yes, likely" I'll save myself the trouble looking for a
> reviewer.

If you're ok with the 'later' option, then yes.

I'm sorry later is sooo later, I'll get better. Currently, I couldn't even find time for fixing my strongswan build for EPEL...

http://koji.fedoraproject.org/koji/packageinfo?packageID=13302

Hi, could you please point me to information about the relation between charon-nm in the strongswan-NetworkManager subpackage and the NetworkManager-strongswan package?

Cheers,

Pavel

I was able to build and install Thorsten's package without problems. Settings showed up in gnome-NM for me.

*** Bug 909098 has been marked as a duplicate of this bug. ***

(In reply to comment #8)
> I was able to build and install Thorsten's package without problems.
> Settings showed up in gnome-NM for me.

Thanks for information.

Thorsten,

sorry for the delay.

Please fix the review request so that the spec file is the same as the one in the SRPM. Please consider notifying upstream about the unversioned .so file and ask them if they would provide properly versioned one.

(See https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#DevelPackages)

Also I would like to ask whether you think it would be a good idea to remove the strongswan-NetworkManager subpackage and deliver the charon-nm inside the strongswan package. I made it separate as I thought that it would provide NM integration but having strongswan-NetworkManager and NetworkManager-strongswan is pretty much confusing. Look at the comments for bugs I marked duplicate to this bug.

Thanks,

Pavel

I hope you're on vacation and didn't lose interest. Looking forward to your answers and finishing the review.

Pavel

(In reply to comment #12)
> I hope you're on vacation

No, this sometimes strange concept of "real life" demanded a bit more attention than usually in the past few weeks ;-) But honestly, looking into this was definitely on my todo list for Easter :-)

> and didn't lose interest.

No -- but I'm wondering if it would be better for everyone if you would maintain this package. But we can change that after the review if we want to.

> Looking forward to your answers and finishing the review.

Here we go:

(In reply to comment #11)
>
> Please fix the review request so that the spec file is the same as the one
> in the SRPM.

Argh, sorry, that was a small last minute change. And I really need to look properly into the selinux issue, that's why I'm not uploading a new package yet.

> Please consider notifying upstream about the unversioned .so
> file and ask them if they would provide properly versioned one.

Hmmmm. I got the impression unversioned .so files are a normal thing for NM after running this:

[thl@thl-t420 tmp]$ repoquery -ql NetworkManager-openconnect NetworkManager-openswan NetworkManager-openswan NetworkManager-openvpn NetworkManager-pptp NetworkManager-vpnc NetworkManager-wimax  | grep /usr/lib64/NetworkManager/
/usr/lib64/NetworkManager/libnm-openconnect-properties.so
/usr/lib64/NetworkManager/libnm-openswan-properties.so
/usr/lib64/NetworkManager/libnm-openvpn-properties.so
/usr/lib64/NetworkManager/libnm-pptp-properties.so
/usr/lib64/NetworkManager/libnm-vpnc-properties.so
/usr/lib64/NetworkManager/libnm-device-plugin-wimax.so
[thl@thl-t420 tmp]$

> Also I would like to ask whether you think it would be a good idea to remove
> the strongswan-NetworkManager subpackage and deliver the charon-nm inside
> the strongswan package.

strongswan-NetworkManager has dependencies on things like libdbus-1, libnm-util, and libnm-glib-vpn, so it might be wise to keep it separate to keep a minimal install with strongswan small (but maybe all these things are installed in a minimal install already anyway -- I didn't check)

> I made it separate as I thought that it would
> provide NM integration but having strongswan-NetworkManager and
> NetworkManager-strongswan is pretty much confusing. 

How about renaming the sub-package to strongswan-charon-nm or something like that?

(In reply to comment #13)
> (In reply to comment #12)
> > I hope you're on vacation
> 
> No, this sometimes strange concept of "real life" demanded a bit more
> attention than usually in the past few weeks ;-) But honestly, looking into
> this was definitely on my todo list for Easter :-)

No problem, I just wanted to make sure my delay wasn't fatal.

> > and didn't lose interest.
> 
> No -- but I'm wondering if it would be better for everyone if you would
> maintain this package. But we can change that after the review if we want to.

First of all, you saw how long it took me to do the review. And it's easier than that. You can share the maintainance burden by granting git push access to other fedora folks and still be the owner of the package. Likewise you can get git push access to some of my related packages if you are interested.

> > Looking forward to your answers and finishing the review.
> 
> Here we go:
> 
> (In reply to comment #11)
> >
> > Please fix the review request so that the spec file is the same as the one
> > in the SRPM.
> 
> Argh, sorry, that was a small last minute change. And I really need to look
> properly into the selinux issue, that's why I'm not uploading a new package
> yet.

So when the selinux issue is over, the dbus policy issue is sorted and the strongswan dependency is changed, the software should work and should be ready for distribution. I think a good idea would be to target rawhide, f19 and optinally f18. It's up to you.

> > Please consider notifying upstream about the unversioned .so
> > file and ask them if they would provide properly versioned one.
> 
> Hmmmm. I got the impression unversioned .so files are a normal thing for NM
> after running this:
> 
> [thl@thl-t420 tmp]$ repoquery -ql NetworkManager-openconnect
> NetworkManager-openswan NetworkManager-openswan NetworkManager-openvpn
> NetworkManager-pptp NetworkManager-vpnc NetworkManager-wimax  | grep
> /usr/lib64/NetworkManager/
> /usr/lib64/NetworkManager/libnm-openconnect-properties.so
> /usr/lib64/NetworkManager/libnm-openswan-properties.so
> /usr/lib64/NetworkManager/libnm-openvpn-properties.so
> /usr/lib64/NetworkManager/libnm-pptp-properties.so
> /usr/lib64/NetworkManager/libnm-vpnc-properties.so
> /usr/lib64/NetworkManager/libnm-device-plugin-wimax.so
> [thl@thl-t420 tmp]$

Agreed. No action is needed then.

> > Also I would like to ask whether you think it would be a good idea to remove
> > the strongswan-NetworkManager subpackage and deliver the charon-nm inside
> > the strongswan package.
> 
> strongswan-NetworkManager has dependencies on things like libdbus-1,
> libnm-util, and libnm-glib-vpn, so it might be wise to keep it separate to
> keep a minimal install with strongswan small (but maybe all these things are
> installed in a minimal install already anyway -- I didn't check)

Question is whether it makes sense to optimize for systems without NetworkManager in Fedora when we're targetting even for initramfs. Will check with other people. For now I'm choosing from two possibilities:

1) rename strongswan-NetworkManager subpackage to -charon-nm to avoid confusion

+ keeps strongswan free of dependency on libnm-util and libnm-glib and indirectly glib, dbus-glib and libuuid.

2) merge strongswan-NetworkManager subpackage into the main package

+ libdbus is already required by systemd and many other packages
+ neither dbus daemon nor NetworkManager is required
+ NetworkManager libs are installed on most fedora systems
+ the total size of pulled in libraries isn't particularly big

Either way, the NetworkManager-strongswan package would depend on the package containing charon-nm.

The correct way to package NM VPN plugins and their daemons is this:

1) the VPN package itself; does not depend on NEtworkManager or consume any NetworkManager libraries like libnm-glib or libnm-util.  eg, the "vpnc", "openconnect", "openvpn", etc packages

2) the NetworkManager VPN plugin itself: eg, the thing that NM talks to via dbus to start/stop the VPN connection, and any associated components.  But *not* any GUI components.  eg, /usr/libexec/nm-vpnc-service and /usr/libexec/nm-vpnc-service-vpnc-helper and /etc/NetworkManager/VPN/nm-vpnc-service.name and any translation files for the core plugin.

3) the GNOME desktop GUI pieces, like the auth dialog and connection editor pane, and associated translations for the GUI parts.

I realize the existing plugins are not separated like 2 & 3, but we want to do that in the future.  So new plugins should follow that separation.

For consistency, #2 should be named "NetworkManager-<vpn service>" (ie, NetworkManager-strongswan) and #3 should be named "NetworkManager-<vpn service>-gnome" (ie, NetworkManager-strongswan-gnome).

(In reply to comment #16)
> The correct way to package NM VPN plugins and their daemons is this:

Thanks for adding information that I didn't know.
 
> 1) the VPN package itself; does not depend on NEtworkManager or consume any
> NetworkManager libraries like libnm-glib or libnm-util.  eg, the "vpnc",
> "openconnect", "openvpn", etc packages

For example, strongswan's charon-nm depends on NetworkManager-glib but I don't know yet what it is and what's the relation between the part that is in strongswan and the part that is in NetworkManager-strongswan.

Do you think that charon-nm binary dependency on NetworkManager-glib is bad enough that I should file a bug report with Strongswan?

> 2) the NetworkManager VPN plugin itself: eg, the thing that NM talks to via
> dbus to start/stop the VPN connection, and any associated components.  But
> *not* any GUI components.  eg, /usr/libexec/nm-vpnc-service and
> /usr/libexec/nm-vpnc-service-vpnc-helper and
> /etc/NetworkManager/VPN/nm-vpnc-service.name and any translation files for
> the core plugin.
> 
> 3) the GNOME desktop GUI pieces, like the auth dialog and connection editor
> pane, and associated translations for the GUI parts.
> 
> I realize the existing plugins are not separated like 2 & 3, but we want to
> do that in the future.  So new plugins should follow that separation.
>
> For consistency, #2 should be named "NetworkManager-<vpn service>" (ie,
> NetworkManager-strongswan) and #3 should be named "NetworkManager-<vpn
> service>-gnome" (ie, NetworkManager-strongswan-gnome).

Thank you. We're talking about the following packages then.

* strongswan (and optionally strongswan-charon-nm)
* NetworkManager-strongswan
* NetworkManager-strongswan-gnome

This is quick attempt at improving the package based on the above comments. Not sure if it's really working though. Installing it provides a strongswan option in NetworkManager GUI, but I couldn't find a way to select SSL certs or define password etc. (NB: to build, it requires manually downloading latest strongswan RPMS from koji as the rename to strongswan-charon-nm hasn't hit updates-testing yet.)

Spec URL: http://jamielinux.fedorapeople.org/NetworkManager-strongswan/NetworkManager-strongswan.spec
SRPM URL: http://jamielinux.fedorapeople.org/NetworkManager-strongswan/SRPMS/NetworkManager-strongswan-1.3.0-2.fc19.src.rpm

* Thu Jul 25 2013 Jamie Nguyen <jamielinux> - 1.3.0-2
- depend on strongswan-charon-nm instead of strongswan-NetworkManager
- add Group tag
- remove rm -rf {buildroot}
- add NetworkManager-strongswan-gnome subpackage

https://koji.fedoraproject.org/koji/taskinfo?taskID=5878470

Seems to work just fine on f19 against strongswan 5.1.0 on my raspi...

Sorry, seems I don't find enough time to drive this package forward properly :-/ 

@jamie, @pavel, @andreas: Wanna take over?

Anyway, here is my latest WIP:
Spec URL: http://www.leemhuis.info/files/fedora/NetworkManager-strongswan.spec
SRPM URL: http://www.leemhuis.info/files/fedora/NetworkManager-strongswan-1.3.0-3.fc19.src.rpm

(Sorry jamie, I had some of the changes lying around here already before you posted your 1.3.0-2 here :-/ And btw, why did you add a group tag?)

Remaining problems:

 * rpmlint: NetworkManager-strongswan.x86_64: E: no-binary 
   Could be fixed with making this a noarch subpackage of NetworkManager-strongswan-gnome -- but that's ugly and probably not worth the trouble
 
 * the NetworkManager configuration dialog in F19 (gnome) doesn't show the options to specify the key files anymore (jamie: same with your package); not sure when and why that broke :-/

 * still seeing AVC denied msgs from Selinux; partly due to the location of the keyfiles, hence that might be my configuration up to a point

Closing this to avoid discouraging anyone else to take this over. I use this package, but I obviously do not drive the review forward properly. I also fear this package might need more attention and knowledge(¹) than I have, so I guess it's better to abstain from it.

(¹) the "NetworkManager configuration dialog not working in F19" issue that I mention in my last comment is not present in f20 and it might work again in f19 by now, but it makes me suspicious...

This bug shouldn't be closed, it should be unassigned. Can someone please re-open?

Please reopen this ticket!

as Thorsten mentioned, this ticket is closed. It shouldn't discourage anyone to submit an own package for review.

https://fedoraproject.org/wiki/Category:Package_Maintainers?rd=PackageMaintainers

Yes, Mattias, it is pretty clear that it is closed given that the last two people to comment on it asked for it to be re-opened.

It should be open, as it is a legitimate and unresolved issue.

Someone with the right permissions please re-open it, and unassign it if necessary. A bug shouldn't be closed because the last person to own it was not able to resolve it (vs. someone deciding it isn't a legitimate issue, a.k.a. WONTFIX).

Sorry, Matthias.

Stephen, I see your pain, as you want this to be packaged in Fedora.
I did not say, it's not a legitimate issue. 

You (and Florian) simply misunderstood the way it works:


The reporter wants to maintain the package and opens a request for review. The request is: dear assignee, please review the following package for me.
(Not: dear assignee, please package ... for Fedora !)


In this case, Thorsten doesn't want to continue with this request. 

Of course, I could re-open the ticket, but what would this help in this case?

Stephen, if you are willing to maintain the package, please go ahead and submit the package as own review request. (In a different request).

(In reply to Stephen from comment #25)
> It should be open, as it is a legitimate and unresolved issue.

Tracking of things to package is not done in bugzilla, it's done on the wishlist in the wiki iirc. Fedora is a community project, and if nobody wants to package this software, then that's how it is. A stale bug report won't help getting it in the repos.

FWIW, if somebody want to step up and submit this package, here is my latest spec. Might help as a starting point and is compile tested on F22: http://www.leemhuis.info/files/fedora/NetworkManager-strongswan.spec

Hello Thorsten,

thanks for the info and your spec file!

I managed to build and install it but in the end its not working for me.
If I try to add a connection through the Network Manager, I get this form:
https://ge1.me/e1e870dd99ba43ee99b1
(Network Manager > '+' sign bottom left > "IPsec/IKEv2 (strongswan)")
Any ideas?

rpm files: https://ge1.me/2423da1b5e304ff181be

Greetings,
Florian

(In reply to Florian Kaiser from comment #29)
> I managed to build and install it but in the end its not working for me.

Fun fact: I've seen that problem about a year or two ago; it first came and suddenly vanished again on my system. I have no idea why – but it is one of the reasons why I decided to not maintain this in Fedora.

I guess its a missing library. Can you send me a list of packages you have installed or a diff or so? Here are mine: https://ge1.me/4297f919ba7f4608b4aa/raw (dnf list installed)

(In reply to Florian Kaiser from comment #29)
> ... but in the end its not working for me.
> If I try to add a connection through the Network Manager, I get this form:
> https://ge1.me/e1e870dd99ba43ee99b1

Hi Florian,
in order to get that fixed please have a look on my bugreport for opensuse with provided patches: https://bugzilla.suse.com/show_bug.cgi?id=944769

FWIW, here is a SRPM with the patches from openSUSE:
http://www.leemhuis.info/files/fedora/NetworkManager-strongswan-1.3.1-2.fc23.src.rpm

Know issues: 
* SELinux still needs to be disabled
* the plugin doesn't set the route properly for me

BTW, This new SRPM doesn't mean I plan to pick this up again. Which reminds me: Lubomir, are you interested in this orwould be willing to help maintaining this package? I noticed you cleaned a lot of things up in NetworkManager and NM-vpn-plugins land. So I wonder if you might be willing to help getting this package into Fedora for those poor souls like me, whose company admins suggest to use NM-strongswan-plugin.

TWIMC: NetworkManager-strongswan recently made it into Fedora via this package review: https://bugzilla.redhat.com/show_bug.cgi?id=1273477 That package afaics is currently not containing the openSUSE packages mentioned in comment 32, but we'll get them there if it makes sense to add them there.