Project

General

Profile

Feature #1360

strongswan-swanctl.service doesn't have an [install] section

Added by Yves-Alexis Perez over 4 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Category:
charon-systemd
Target version:
Start date:
17.03.2016
Due date:
Estimated time:
Resolution:
Fixed

Description

It seems that the unit file shipped with charon-systemd (which is, really confusingly, called strongswan-swantctl.service and not charon-systemd.service) doesn't have an [Install] section, which means it's not possible to have it started automatically.

I'm unsure if it's on purpose (it should only ever be started manually) or if it's been forgotten, so I'm opening an issue just to be sure.

History

#1 Updated by Tobias Brunner over 4 years ago

  • Tracker changed from Issue to Feature
  • Category set to charon-systemd
  • Status changed from New to Feedback
  • Assignee set to Tobias Brunner
  • Target version set to 5.4.0
  • Resolution set to Fixed

It seems that the unit file shipped with charon-systemd (which is, really confusingly, called strongswan-swantctl.service and not charon-systemd.service)

Yes, it's a bit confusing and you are obviously free to rename it. I think it was originally done to signify that the configuration backend is swanctl as charon-systemd could theoretically be run with the stroke plugin instead of the vici plugin (and thus without swanctl) if we'd move the ipsec.conf parser from starter to the stroke plugin, which would then require a different unit file without the swanctl calls that we could name something like strongswan-stroke.service.

doesn't have an [Install] section, which means it's not possible to have it started automatically.

It didn't in 5.3.5, it does now (source:init/systemd-swanctl/strongswan-swanctl.service.in). Also see this pull request at github.com.

#2 Updated by Yves-Alexis Perez over 4 years ago

Tobias Brunner wrote:

It seems that the unit file shipped with charon-systemd (which is, really confusingly, called strongswan-swantctl.service and not charon-systemd.service)

Yes, it's a bit confusing and you are obviously free to rename it. I think it was originally done to signify that the configuration backend is swanctl as charon-systemd could theoretically be run with the stroke plugin instead of the vici plugin (and thus without swanctl) if we'd move the ipsec.conf parser from starter to the stroke plugin, which would then require a different unit file without the swanctl calls that we could name something like strongswan-stroke.service.

And is that something planed? I had the impression that somehow swanctl and vici was the future, and that stroke wouldn't really move further. So will a charon-systemd + stroke appeared at one point? Also, which charon daemon would be controlled by strongswan-stroke.service? charon-systemd or charon?

doesn't have an [Install] section, which means it's not possible to have it started automatically.

It didn't in 5.3.5, it does now (source:init/systemd-swanctl/strongswan-swanctl.service.in). Also see this pull request at github.com.

Nice, thanks.

#3 Updated by Tobias Brunner over 4 years ago

  • Status changed from Feedback to Closed

I had the impression that somehow swanctl and vici was the future, and that stroke wouldn't really move further.

Yes, but that wasn't clear 1.5 years ago when that file was added (and since it was already getting used quickly afterwards renaming it wasn't really an option).

So will a charon-systemd + stroke appeared at one point?

No, there are currently no plans to do that.

Also available in: Atom PDF