-
-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactors (ready for review) #81
Conversation
- be more complete and strict - utilize rspec-puppet-facts
c77c061
to
8f58fc1
Compare
8f58fc1
to
7a2ab4a
Compare
3c3288a
to
b7e15fc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lots of nice work here!
String[1] $update_cmd = 'update-ca-trust extract', | ||
String[1] $cert_dir_group = 'root', | ||
String[1] $cert_dir_mode = '0755', | ||
Boolean $supported = false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I like this supported
parameter pattern. I don't think we do this in any of the Vox Pupuli modules. It seems redundant to just listing supported OSes in metadata.json
. I suppose you are retaining existing behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes this is only here to maintain the existing behaviour. Would be more than happy to remove it :)
Let @pcfens decide which route to go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, would be nice to get this merged. so looking forward for this one |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kali was added to params.pp while this PR was up for review.
Should that be added to metadata as well?
create_resources('ca_cert::ca', $ca_certs) | ||
create_resources('ca_cert::ca', $ca_certs) | ||
|
||
if $facts['os']['family'] == 'RedHat' and versioncmp($facts['os']['release']['full'], '7') < 0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need for this as EL6 is long gone.
ca_cert::trusted_cert_dir: '/usr/local/share/ca-certificates' | ||
ca_cert::update_cmd: 'update-ca-certificates' | ||
ca_cert::cert_dir_group: 'staff' | ||
ca_cert::cert_dir_mode: '2665' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where does this default come from?
On a fresh install of ca-certificates in amd/debian:10
,amd/debian:11
and amd/debian:12
containers the default is
root@60422e36a680:/# ls -l /usr/local/share/
total 0
drwxr-xr-x. 2 root root 6 May 9 14:06 ca-certificates
ca_cert::cert_dir_mode: '2665' | ||
ca_cert::package_name: 'ca-certificates' | ||
ca_cert::ca::ca_file_group: 'root' | ||
ca_cert::ca::ca_file_mode: '0444' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not 0644 as default? Fresh debian container once more:
No files at all in /usr/local/share/ca-certificates
and certificates in /usr/share/ca-certificates
have 0644
root@b3059a7e2497:/# ls -l /usr/share/ca-certificates/mozilla/
total 560
-rw-r--r--. 1 root root 2772 Mar 11 2023 ACCVRAIZ1.crt
-rw-r--r--. 1 root root 1972 Mar 11 2023 AC_RAIZ_FNMT-RCM.crt
-rw-r--r--. 1 root root 904 Mar 11 2023 AC_RAIZ_FNMT-RCM_SERVIDORES_SEGUROS.crt
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/usr/local/share/ca-certificates
is the right place for certs installed by this module. See the FILES section of man update-ca-certificates
.
I'd be fine with 0644 or 0444, but I think we often use 0444 as a way to show that the files are puppet-managed and shouldn't be manually edited.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was just referring to /usr/share/ca-certificates
because that's provided by the ca-certificates package with mode 0644
as an argument for using the same when adding files to /usr/local/share/ca-certificates
:)
ca_cert::supported: true | ||
ca_cert::trusted_cert_dir: '/usr/local/share/ca-certificates' | ||
ca_cert::update_cmd: 'update-ca-certificates' | ||
ca_cert::cert_dir_group: 'staff' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why staff
as default? The ca-certificates package creates this directory with group root ...
root@cbe1f3cd0871:/# ls -l /usr/local/share/
total 0
drwxr-xr-x. 2 root root 6 May 9 17:31 ca-certificates
ca_cert::cert_dir_mode: '0755' | ||
ca_cert::package_name: 'ca-certificates' | ||
ca_cert::ca::ca_file_group: 'root' | ||
ca_cert::ca::ca_file_mode: '0444' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same reasoning as for Debian. See no reason why this should default to 0444 ..
I guess changing the default for Debian family should be done in a separate PR so that it shows in changelog :) |
This PR has a few conflicts and is changing things that should to be split into separate PRs. |
Yes sure modify as needed. As I’m not able to contribute anymore myself, I’m happy to see any action here :)This PR has a few conflicts and is changing things that should to be split into separate PRs.
I'll try to do this the best I can.
Hope that's all right with you @Phil-Friderici
|
@Phil-Friderici I think I have covered all the relevant parts of this PR now. |
@h-haaks it needs a rebase though |
@TheMeier I don't see why the PR should be rebased before closing ( no merge ). |
I'll move on and close this as I think all the relevant pieces have been solved by other smaller PR's. |
PR to collect my little refactors: