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.
Adding Spot.
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.
(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.
I do not claim to be an expert here, by any means. Did the normal "start" command work at least?
Yes, the start command works.
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.
(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
Yeah, enable is what I meant to write there. Lemme poke this.
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?
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?
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.
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.
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.
I'm 99% sure the workaround in Comment 11 is correct. systemctl really needs to support this case natively though.
Minor correction - I guess comment 11 should say: systemctl daemon-reload instead of systemctl daemon-restart
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
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
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.
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
(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.
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
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.
According to guidelines services in already released Fedora must not be updated to units. Let's track it for rawhide.
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
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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.
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.