-
Notifications
You must be signed in to change notification settings - Fork 0
Update to latest master version #1
base: master
Are you sure you want to change the base?
Conversation
Marked fullchain as a deprecated_property_alias
bump acme-client gem to 2.0.3
Pebble v2.x has breaking changes that need some futher overhaul here, but for now use the v1.0.1 version so tests can pass once more. Also ensure that available packages are updated in Debian-based testing platforms.
Test fixes
Need lazy evaluation when using attributes in resources
Upgrades acme-client version to 2.0.6 which supports faraday 1.0.0 which is required by chef
Update default.rb (Closes #120)
Why do you need this? If I recall correctly we needed this for ACME v2 support which is part of the stable 4.1.0 release. Currently upstream master is the latest stable version (4.1.2) so there is no longer a need for this custom fork. You can get rid of it and just upload 4.1.2 to your Chef server or reference it in the cookbooks that depend on it. |
Chef testing fails because it can't install the acme-client gem. Didn't we pin all the mirrored cookbooks so we can't have any problems when somebody updates them and we don't support it? |
There's a difference in pinning and forking cookbooks. We had to fork this one because the changes we needed weren't released in a stable release yet. The cookbook should still be pinned. E.g. in |
# Problem Currently, if a certificate has a large number of alt-names in it, and one (or more) of them fail, the entire certificate is rejected. Unfortunately, there is no diagnostics returned to point out what has failed, only that something has. This makes it difficult to debug the problem from the server admin point of view. # Fix Adjust the block that triggers the fail so that it includes some additional information about what the failure is, and include it in the output
Adds a bit more information to authz failure
Fix 'satus' typo in cert creation ruby_block
fixes #51 As the ability to install DNS challenges into the infrastructure depends on the site, I implemented this in a way that allows cfookbook authores to specify how to supply this to the infrastructure using custom ruby blocks. There must be two blocks given to the resource if you want to use DNS validation: `install_authz_block` and `remove_authz_block` There is an example in the README explaining how to use this.
implement an interface to support DNS challenges
Signed-off-by: Robert Detjens <[email protected]>
Signed-off-by: Robert Detjens <[email protected]>
Signed-off-by: Robert Detjens <[email protected]>
Signed-off-by: Robert Detjens <[email protected]>
Fixes #126 Signed-off-by: Robert Detjens <[email protected]>
Signed-off-by: Robert Detjens <[email protected]>
Chef 17 compatibility and test modernization
location can be configured via chef attributes
Make private key file location configurable
v4.1.5 added this field, and it's important to note that if `private_key_file` exists, the contents will take precedence over `private_key`.
Document behavior of private_key_file
The upstream file resource supports using both String and Integer for owner/group properties. There are some use cases where setting the UID/GID is needed instead of the name (i.e. Docker volumes). Signed-off-by: Lance Albertson <[email protected]>
Allow Integer for owner and group properties
…_authz.status add processing as a valid authz status
upgrade acme-client gem to 2.0.15
Updates our branch to the latest version. @jeroenj how do i update the live branch? Just create a PR with the metadatata.rb version update?