Metadata Valid
No translation
easy-rsa2 was removed from FreeBSD ports tree, see:
https://svnweb.freebsd.org/ports?view=revision&revision=r504939
switch to easy-rsa 3, tested on FreeBSD 12.0-RELEASE, FreeBSD 13-CURENT
Fixes #211
Should manage the service for openvpn client service correctly. Service restart on configuration changes does not work due to dependency cycles I wasn't able to solve.
Only tested on Amazon linux (like RedHat 7).
Fix of deprecation warning:
Warning: The source_permissions parameter is deprecated. Explicitly set owner, group, and mode.
(file: .../manifests/ca.pp, line: 127)
Replaced:
source_permissions => 'use',
With:
owner => 'root',
mode => '0755',
This is tested on puppet-agent 5.5.7-1 on Ubuntu Xenial, puppetserver 5.3.6-1 Ubuntu Xenial.
Adding support for Ubuntu 20.04 (Focal)
See documentation for proto:
–proto p
Use protocol p for communicating with remote host. p can be udp, tcp-client, or tcp-server.The default protocol is udp when –proto is not specified.
This might be wron implemented as there is also a proto field for the
remote argument:
–remote host [port] [proto]
Remote host name or IP address. On the client, multiple –remote options may be specified for redundancy, each referring to a different OpenVPN server. Specifying multiple –remote options for this purpose is a special case of the more general connection-profile feature. See the documentation below.The OpenVPN client will try to connect to a server at host:port in the order specified by the list of –remote options.
proto indicates the protocol to use when connecting with the remote, and may be “tcp” or “udp”.
For forcing IPv4 or IPv6 connection suffix tcp or udp with 4/6 like udp4/udp6/tcp4/tcp6.
<!--
Thank you for contributing to this project!
-->
<!--
Replace this comment with a description of your pull request.
-->
<!--
Replace this comment with the list of issues or n/a.
Use format:
Fixes #123
Fixes #124
-->
In easyrsa 3.0 (used in CentOS) the command has changed. Now there is
only a single binary to run the scripts. Further the generation of CRL
also has changed; now a new crl.pem file is created in keys/crl.pem
which overrides the symlink there. So the revocation check did not work
anymore, because the crl.pem in the base directory was not checked when
a client connected.
Resolves: VSHNOPS-1537
<!--
Thank you for contributing to this project!
-->
<!--
Replace this comment with a description of your pull request.
-->
<!--
Replace this comment with the list of issues or n/a.
Use format:
Fixes #123
Fixes #124
-->
If using crlautorenew and the crl is recreated, the service has to be reloaded,
otherwise clients can't connect if crl is getting verified. (seen on centos7)
no issue created, but i can if it helps