Created attachment 392952 [details, diff] ipsec-tools-0.8.2.ebuild.patch A small patch to add systemd support to net-firewall/ipsec-tools (service files shamelessly stolen from Arch Linux and slightly adapted to Gentoo).
Created attachment 392954 [details] ipsec.service
Created attachment 392956 [details] racoon.service
@systemd folks, can you review the unit files and I'll add them.
*ugh* Judging from the contents of /etc/conf.d/racoon, it is unnecessary to source it at all. The reasoning behind this is that if a user wants to override this, he can already selectively do so in /etc/systemd/system/racoon.service.d with a drop-in - there is no need for a configuration under /etc/conf.d at all. Further, why not refactoring the contents of ipsec.service into racoon.service as well? Or is the call to setkey already something that sould be available independently of racoon? If not, what about just a single racoon.service file: [Unit] Description=Racoon IKEv1 key management daemon for IPSEC After=syslog.target network.target [Service] Type=forking ExecStartPre=/usr/sbin/setkey -f /etc/racoon/racoon.conf ExecStart=/usr/sbin/racoon -f /etc/racoon/racoon.conf ExecStopPost=/usr/sbin/setkey -F ExecStopPost=/usr/sbin/setkey -F -P [Install] WantedBy=multi-user.target Unfortunately, I currently lack the time to test it.
(In reply to Matthias Maier from comment #4) > *ugh* > > Judging from the contents of /etc/conf.d/racoon, it is unnecessary to source > it at all. > > The reasoning behind this is that if a user wants to override this, he can > already selectively do so in /etc/systemd/system/racoon.service.d with a > drop-in - there is no need for a configuration under /etc/conf.d at all. Fine for me. These service files where written several months ago, when I understood even less about systemd than I do now. > > Further, why not refactoring the contents of ipsec.service into > racoon.service as well? Or is the call to setkey already something that > sould be available independently of racoon? As far as I understand it, you can create simple IPsec tunnels with just setkey (thus ipsec.service), while you need racoon for more complex setups (IKE, NAT traversal, the like). I did it this way because Arch (where I "stole" the service files from) does it like this and I guess they know better than me. > If not, what about just a single > racoon.service file: > > > [Unit] > Description=Racoon IKEv1 key management daemon for IPSEC > After=syslog.target network.target > > [Service] > Type=forking > ExecStartPre=/usr/sbin/setkey -f /etc/racoon/racoon.conf > ExecStart=/usr/sbin/racoon -f /etc/racoon/racoon.conf > ExecStopPost=/usr/sbin/setkey -F > ExecStopPost=/usr/sbin/setkey -F -P > > [Install] > WantedBy=multi-user.target Whatever. I still think there's value in keeping them separate, though.
(In reply to Paolo Pedroni from comment #5) > > As far as I understand it, you can create simple IPsec tunnels with just > setkey (thus ipsec.service), while you need racoon for more complex setups > (IKE, NAT traversal, the like). I did it this way because Arch (where I > "stole" the service files from) does it like this and I guess they know > better than me. > racoon and ipsec can be run independantly of one another. racoon is just a session key negotiation program based on some shared secret. but you can just hard code your keys in /etc/ipsec-tools.conf and run ipsec independantly. many people do for dedicated tunnels between servers. So we should keep those two services independant. Whether that means you need one or two unit files, I'll leave up to the systemd ninjas.
Closing this for now since we didn't reach any consensus on what we want for systemd unit files. Reopen when/if we have somethign more.
