Bug 744244

Summary: systemd-sysv-convert doesn't work for openvpn
Product: [Fedora] Fedora Reporter: Jonathan Kamens <jik>
Component: openvpnAssignee: Gwyn Ciesla <gwync>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: amcnabb, amessina, djuran, dylan.semler, emcnabb, emisca, gilboad, gwync, huzaifas, jason.donald.burgess, kevin, lpoetter, maxmirror, mjc, mschmidt, pahan, psabata, samuel-rhbugs, steve, tcallawa, thomas.moschny
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-17 13:55:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jonathan Kamens 2011-10-07 15:13:18 UTC
Before the upgrade to F16, openvpn automatically started my tunnel at boot time.

After the upgrade, it doesn't.

There seems to have been some effort to preserve the behavior -- there is a "systemd-sysv-convert --save openvpn" command in the triggerun for openvpn -- but it doesn't appear to work:

jik2:~!1047$ sudo systemd-sysv-convert --apply openvpn
[sudo] password for jik: 
systemd service openvpn.service does not exist.

Furthermore, there's no documentation or tools anywhere that I could find of how to configure a new tunnel to be started automatically. Looking at the getty files in /lib/systemd and /etc/systemd and comparing them to the openvpn files, I am suspecting that perhaps the openvpn systemd implementation is incomplete, although I don't understand all the systemd stuff to be able to figure out exactly what's missing.

Comment 1 Gwyn Ciesla 2011-10-07 15:22:07 UTC
Adding Spot.

Comment 2 Tom "spot" Callaway 2011-10-07 15:33:34 UTC
No, I think the script just doesn't understand that openvpn is setup to permit instances, see here: http://0pointer.de/blog/projects/instances.html

The old model would iterate through any .conf configuration files in /etc/openvpn, and if found, would start up a separate OpenVPN daemon for each file.

The systemd method is a bit more granular, you need to tell it which instances you want it to start. So, lets say you have:

/etc/openvpn/foo.conf

If you want to initialize the "foo" tunnel, then you would do this:

systemctl start openvpn

If you want it to start on boot, you would do this:

systemctl enable openvpn

Please let me know if that does not work.

Comment 3 Jonathan Kamens 2011-10-07 19:04:06 UTC
(In reply to comment #2)
> If you want it to start on boot, you would do this:
> 
> systemctl enable openvpn

jik2:~/tmp!1061$ sudo systemctl enable openvpn
[sudo] password for jik: 
Failed to issue method call: No such file or directory

Judging from the blog entry you referenced, systemctl enable is not expected to work in this context; you need to create a symlink by hand. But the example it gives for getty is, "ln -s /lib/systemd/system/serial-getty@.service /etc/systemd/system/getty.target.wants/serial-getty", and there's no corresponding openvpn.target file or openvpn.target.wants directory, which is why I think the openvpn implementation is missing something.

Not to mention that all of this stuff is ridiculously underdocumented. A blog entry floating around somewhere in the ether and referenced in a bugzilla comment is not document. The thing should be shipped with documentation, at minimum something useful in /usr/share/doc, explaining how to configure it.

Comment 4 Tom "spot" Callaway 2011-10-07 19:11:11 UTC
I do not claim to be an expert here, by any means. 

Did the normal "start" command work at least?

Comment 5 Jonathan Kamens 2011-10-07 19:15:10 UTC
Yes, the start command works.

Comment 6 Tom "spot" Callaway 2011-10-07 19:22:53 UTC
Okay, a bit more digging, here is how I think it works:

Again, this assumes that /etc/openvpn/foo.conf is present and correct.

If you just want to turn it on, you don't need to do anything besides:

   systemctl start openvpn

However, if you want to enable it on boot, you need to make a symlink.

   ln -s /lib/systemd/system/openvpn\@.service \
   /etc/systemd/system/openvpn\@foo.service

And for another instance bar (again, depends on /etc/openvpn/bar.conf)

   ln -s /lib/systemd/system/openvpn\@.service \
   /etc/systemd/system/openvpn\@bar.service

Then to make it stick:

   systemctl daemon-reload 

At this point, you should still be able to start the service like this:

   systemctl start openvpn

And enable it on boot like this:

   systemctl start openvpn

****

Please confirm the accuracy of the above statements. I'll make a README.systemd for inclusion in the package once I know they're correct.

Comment 7 Jonathan Kamens 2011-10-07 19:31:08 UTC
(In reply to comment #6)
> At this point, you should still be able to start the service like this:
> 
>    systemctl start openvpn
> 
> And enable it on boot like this:
> 
>    systemctl start openvpn

Should that last line be "systemctl enable" rather than "systemctl start"? Because otherwise it's just the same as the line before.

Even after following the above steps, enable still doesn't work:


jik2:/var/lib/dhcpd!1096$ ls -l /etc/systemd/system/openvpn 
lrwxrwxrwx 1 root root 36 Oct  7 15:28 /etc/systemd/system/openvpn -> /lib/systemd/system/openvpn@.service
jik2:/var/lib/dhcpd!1097$ sudo systemctl enable openvpn\@openhosting.service
Failed to issue method call: No such file or directory

Comment 8 Tom "spot" Callaway 2011-10-07 19:43:12 UTC
Yeah, enable is what I meant to write there. Lemme poke this.

Comment 9 Tom "spot" Callaway 2011-10-07 20:09:58 UTC
Debugging this is proving to be difficult, as the main openvpn that I have access to is configured to only support auth-user-pass, which isn't something that systemd (or sysvinit) supports.

Any errors in syslog that might shed light here?

Comment 10 Tom "spot" Callaway 2011-10-07 20:26:57 UTC
FWIW, even though it is throwing that error, it looks like the service may actually be enabled. Can you reboot and see if it comes up?

Comment 11 Tom "spot" Callaway 2011-10-07 20:40:45 UTC
Nm. I think I have a sort of workaround, but I think this is a systemd bug.

Workaround:

ln -s /lib/systemd/system/openvpn@.service /etc/systemd/system/multi-user.target.wants/openvpn

systemctl daemon-restart

Then:

systemctl status openvpn

(it should show as enabled, and should start on a reboot)

I'm looking at the systemd code now.

Comment 12 Tom "spot" Callaway 2011-10-07 21:00:55 UTC
Looking at the code, I don't think systemctl has _any_ code to handle enable/disable of instance units, and we're falling through the bottom.

Paging lennart here to confirm or deny that.

Comment 13 Nickolay Bunev 2011-11-10 19:02:27 UTC
What is the status of this bug? Do we have anything new, or we have to stick with the workaround above? If there is need for additional tests, I will be happy to help.

Comment 14 Tom "spot" Callaway 2011-11-10 19:18:32 UTC
I'm 99% sure the workaround in Comment 11 is correct. systemctl really needs to support this case natively though.

Comment 15 Michael J. Chudobiak 2011-11-10 21:52:11 UTC
Minor correction - I guess comment 11 should say:

systemctl daemon-reload

instead of

systemctl daemon-restart

Comment 16 Emilio Scalise 2011-11-14 10:23:05 UTC
I've also upgraded my fedora installation to version 16 and I found lost as:
service openvpn start
didn't work.
I have searched for any README in /usr/share/doc/openvpn-2.2.1 and I found nothing. I had to start googling for this issue.

Reading this bug comments I knew that I have to use:
systemctl start openvpn

and that works correctly for me.

You should definitely document this on the release notes and in a README file as you said in this bug report.

This new behaviour is very nice, previously I hacked my openvpn init.d file to get a second parameter to choose the config file to start. Now that's handled natively and that's really great!

Thanks
Emilio

Comment 17 Max 2011-11-14 10:32:40 UTC
I make

systemctl enable openvpn@.service

it is output:
ln -s '/lib/systemd/system/openvpn@.service' '/etc/systemd/system/multi-user.target.wants/openvpn@.service'

And get (where kama_server_vpn is /etc/openvpn/kama_server_vpn.conf)

systemctl status openvpn

openvpn - OpenVPN Robust And Highly Flexible Tunneling Application On kama_server_vpn
	  Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled)
	  Active: inactive (dead)
	  CGroup: name=systemd:/system/openvpn@.service/kama_server_vpn

systemctl start openvpn

systemctl status openvpn

openvpn - OpenVPN Robust And Highly Flexible Tunneling Application On kama_server_vpn
	  Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled)
	  Active: active (running) since Mon, 14 Nov 2011 14:22:31 +0400; 1s ago
	 Process: 4342 ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf (code=exited, status=0/SUCCESS)
	Main PID: 4354 (openvpn)
	  CGroup: name=systemd:/system/openvpn@.service/kama_server_vpn
		  └ 4354 /usr/sbin/openvpn --daemon --writepid /var/run/openvpn/kama_server_vpn.pid --cd /etc/openvpn/ --config kama_server_vpn.conf

I can't reboot server today to check it to start on boot. But i think what it is will work

Comment 18 Thomas Moschny 2011-11-14 18:59:30 UTC
The (fixed) workaround from comment 11 works for me.

Running "systemctl enable openvpn@.service" does something silly it seems, because at boot time it then tries to start an instance named "openvpn" which is nonsense.

Comment 19 Max 2011-11-15 10:55:14 UTC
Ok. I tested this solution (comment 11) for vsftpd. For vsftpd problem is similar, it works on reboot. I'll check it later for openvpn.

ln -s /lib/systemd/system/vsftpd@.service /etc/systemd/system/multi-user.target.wants/vsftpd

Comment 20 Michal Schmidt 2012-01-02 14:51:09 UTC
(In reply to comment #12)
> Looking at the code, I don't think systemctl has _any_ code to handle
> enable/disable of instance units, and we're falling through the bottom.
> 
> Paging lennart here to confirm or deny that.

I'm not Lennart, but I can confirm that. See bug 752774.

Comment 21 Fedora End Of Life 2013-01-16 17:35:48 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 22 Jonathan Kamens 2013-01-16 20:34:12 UTC
As far as I know, this is still broken. Whether we need to care about any more about upgrades from pre-F16 working properly, I don't know.

Comment 23 Marcela Mašláňová 2013-01-21 09:32:20 UTC
According to guidelines services in already released Fedora must not be updated to units. 
Let's track it for rawhide.

Comment 24 Fedora End Of Life 2013-04-03 17:41:44 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 25 Fedora Admin XMLRPC Client 2014-11-10 15:37:09 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 26 Fedora Admin XMLRPC Client 2014-11-10 15:51:23 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 27 Fedora End Of Life 2015-01-09 16:48:53 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 28 Fedora End Of Life 2015-02-17 13:55:01 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.