Skip to content
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

Closed
wants to merge 11 commits into from

Conversation

Phil-Friderici
Copy link
Contributor

@Phil-Friderici Phil-Friderici commented Aug 18, 2023

PR to collect my little refactors:

  • move OS specific data into module hiera
  • move functionality from subclasses to main class
  • refactor unit tests to be stricter and more complete
  • other minor refactors

@Phil-Friderici Phil-Friderici force-pushed the refactors branch 2 times, most recently from c77c061 to 8f58fc1 Compare August 21, 2023 10:30
@Phil-Friderici Phil-Friderici changed the title Refactors (work in progress) Refactors (ready for review) Aug 23, 2023
Copy link
Member

@kenyon kenyon left a 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!

manifests/init.pp Outdated Show resolved Hide resolved
String[1] $update_cmd = 'update-ca-trust extract',
String[1] $cert_dir_group = 'root',
String[1] $cert_dir_mode = '0755',
Boolean $supported = false,
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do agree with @kenyon on this one. @pcfens doesn't seem to have any opinion?

manifests/init.pp Outdated Show resolved Hide resolved
@ashish1099
Copy link

Wow, would be nice to get this merged. so looking forward for this one

Copy link
Contributor

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 {
Copy link
Contributor

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'
Copy link
Contributor

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'
Copy link
Contributor

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

Copy link
Member

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.

Copy link
Contributor

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'
Copy link
Contributor

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'
Copy link
Contributor

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 ..

@h-haaks
Copy link
Contributor

h-haaks commented May 9, 2024

I guess changing the default for Debian family should be done in a separate PR so that it shows in changelog :)

@h-haaks h-haaks mentioned this pull request May 9, 2024
@h-haaks
Copy link
Contributor

h-haaks commented May 9, 2024

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
Copy link
Contributor Author

Phil-Friderici commented May 10, 2024 via email

@h-haaks
Copy link
Contributor

h-haaks commented May 29, 2024

@Phil-Friderici I think I have covered all the relevant parts of this PR now.
Could you please have a look at the current code in master and close this PR if you agree?

@TheMeier
Copy link
Contributor

TheMeier commented Jun 2, 2024

@h-haaks it needs a rebase though

@h-haaks
Copy link
Contributor

h-haaks commented Jun 3, 2024

@TheMeier I don't see why the PR should be rebased before closing ( no merge ).

@h-haaks h-haaks mentioned this pull request Jun 5, 2024
@h-haaks
Copy link
Contributor

h-haaks commented Jun 5, 2024

I'll move on and close this as I think all the relevant pieces have been solved by other smaller PR's.
Please feel free to reopen or create new PRs if I missed anything.

@h-haaks h-haaks closed this Jun 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants