Bug 1775548

Summary:	Strongswan services missing synchronisation
Product:	[Fedora] Fedora EPEL	Reporter:	Frank MICHEL <franck.michel>
Component:	strongswan	Assignee:	Mikhail Zabaluev <mikhail.zabaluev>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	epel7	CC:	avagarwa, code, mikhail.zabaluev, sspreitz
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-12-02 09:12:01 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Frank MICHEL 2019-11-22 09:14:11 UTC

Description of problem:
Strongswan 5.7.2 el7 rpm uses 2 services : strongswan.service (daemon start) and strongswan-swanctl.service (configuration load).
According to our tests, the strongswan-swanctl.service must start first then the strongswan.service.
However, the two services are not synchronized with "Before=" or "After=" clauses. 
It happen that sometimes, at platform boot, the start order is not respected and the IPSEC tunnel is started before the configuration is properly loaded. Therefore, it randomly fails.
Please add a "After=strongswan-swanctl.service" in strongswan.service

Version-Release number of selected component (if applicable):
5.7.2-1

How reproducible:
See description

Steps to Reproduce:
1. Setup an automatic IPSEC tunnel at boot between two plateforms.
2. Reboot both platforms
3. "ipsec status" shows failed start randomly

Actual results:
Randomly failed tunnel initialization.

Expected results:
Deterministic tunnel initialization.

Additional info:
None

Comment 1 Mikhail Zabaluev 2019-11-24 09:09:14 UTC

(In reply to Frank MICHEL from comment #0)
> Description of problem:
> Strongswan 5.7.2 el7 rpm uses 2 services : strongswan.service (daemon start)
> and strongswan-swanctl.service (configuration load).
> According to our tests, the strongswan-swanctl.service must start first then
> the strongswan.service.

The documentation on the wiki suggests that the two .service files are alternative ways to start strongswan:

https://wiki.strongswan.org/projects/strongswan/wiki/Charon-systemd#Behavior

In strongswan-swanctl.service, there is a directive to load the configuration with swanctl after the daemon start:

ExecStart=@SBINDIR@/charon-systemd

In version 5.8, now in Rawhide, the service files have been renamed: strongswan-swanctl.service is now strongswan.service, and the old strongswan.service, using the legacy starter script, is named strongswan-starter.service.

Please provide additional information explaining the need to start both services in the order suggested.

Comment 2 Mikhail Zabaluev 2019-11-24 09:12:52 UTC

(In reply to Mikhail Zabaluev from comment #1)
> In strongswan-swanctl.service, there is a directive to load the
> configuration with swanctl after the daemon start:
> 
> ExecStart=@SBINDIR@/charon-systemd

Sorry, wrong line was quoted, it is:

ExecStartPost=/usr/sbin/swanctl --load-all --noprompt

Comment 3 Frank MICHEL 2019-11-25 09:17:07 UTC

Hello,
From the page you cited, it is not obvious that services should not be started together.
If so, they should be made incompatible using a systemd configuration and thus the problem requires an update anyway.
We'll redo the testing this week activating only the "strongswan.service".
Thanks for your help

Comment 4 Mikhail Zabaluev 2019-11-25 18:01:58 UTC

See bug #1773381 for a SELinux issue that prevents strongswan-swanctl.service from being used as the intended standalone unit.

Comment 5 Frank MICHEL 2019-12-02 08:46:14 UTC

We successfully tested the ipsec tunnel using only the "strongswan-starter.service".
Consider the case closed. Sorry for distrubing