Manually set global Git configuration in proc to sync templates with an existing repo

[aneta-petrova]

What changes are you introducing?

Attempting to update the Git global config for the foreman user fails due to insufficient permissions. Adding steps to manually create the config file as well as set the appropriate permissions on the file ensures that it gets updated as expected.

Why are you introducing these changes? (Explanation, links to references, issues, etc.)

https://issues.redhat.com/browse/SAT-27104

Anything else to add? (Considerations, potential downsides, alternative solutions you have explored, etc.)

The proposed solution might be considered hacky by some but it looks like SAT-27349 should make the whole section obsolete in a future version.

Checklists

• I am okay with my commits getting squashed when you merge this PR.
• I am familiar with the contributing guidelines.

Please cherry-pick my commits into:

• Foreman 3.12/Katello 4.14 (Satellite 6.16)
• Foreman 3.11/Katello 4.13
• Foreman 3.10/Katello 4.12
• Foreman 3.9/Katello 4.11 (Satellite 6.15; orcharhino 6.8/6.9/6.10)
• Foreman 3.8/Katello 4.10
• Foreman 3.7/Katello 4.9 (Satellite 6.14)
• Foreman 3.6/Katello 4.8
• Foreman 3.5/Katello 4.7 (Satellite 6.13; orcharhino 6.6/6.7)
• We do not accept PRs for Foreman older than 3.5.

[aneta-petrova]

@adamruzicka Can you please review?

[github-actions]

The PR preview for dfb37a2 is available at theforeman-foreman-documentation-preview-pr-3243.surge.sh

The following output files are affected by this PR:

• Administering_Project/index-foreman-deb.html
• Administering_Project/index-foreman-el.html
• Administering_Project/index-katello.html
• Administering_Project/index-orcharhino.html
• Administering_Project/index-satellite.html

show diff

show diff as HTML

[ekohl]

I wonder if it makes sense to ship an empty config file with the correct permissions by default so I opened theforeman/foreman-packaging#11180. There's some room for discussion of that implementation and we don't have it available everywhere immediately so it doesn't block merging this.

[adamruzicka]

A little bit of context: we're planning some changes to foreman_templates so that the http proxy configured in foreman's settings would be implicitly used, without the user having to go faff around with git config so the whole procedure along with the changes proposed here may become irrelevant.

I wonder if it makes sense to ship an empty config file with the correct permissions by default so I opened

We considered that option but decided against it, considering this is only temporary solution until the changes in f-templates land. But since you already went the extra mile, thank you

[ekohl]

A little bit of context: we're planning some changes to foreman_templates so that the http proxy configured in foreman's settings would be implicitly used, without the user having to go faff around with git config so the whole procedure along with the changes proposed here may become irrelevant.

The HTTP proxy configuration still doesn't set the trusted CA certificates. If you have a self signed certificate for your private gitlab then that doesn't help you, right? Or should we recommend setting up the trusted certificate system wide and avoid the specific git configuration?

[aneta-petrova]

Agreed, fixing the code would be preferable to making users do the legwork of manual configuration, but considering the context (explained in the PR description and by Adam above), my recommendation was to fix this in the docs.

@ekohl Since you opened the foreman-packaging PR (thanks for that, by the way!), can you please help me figure out which branches should the doc fix go to? Should I cherry-pick only to 3.12 and below because for 3.13 and above, the file will be shipped by default?

[adamruzicka]

The HTTP proxy configuration still doesn't set the trusted CA certificates. If you have a self signed certificate for your private gitlab then that doesn't help you, right? Or should we recommend setting up the trusted certificate system wide and avoid the specific git configuration?

I wanted to keep this brief, but since you're asking about it, I'll elaborate. The full plan is to offer an option to pick a proxy from a list of available proxies in the template sync form. The list will be populated with the default proxy as set in settings and all the currently visible proxies configured in infrastructure > http proxies, but will default to the one in settings. For the ones in infrastructure > http proxies, you can paste in a CA cert in case you need it.

[ekohl]

@ekohl Since you opened the foreman-packaging PR (thanks for that, by the way!), can you please help me figure out which branches should the doc fix go to? Should I cherry-pick only to 3.12 and below because for 3.13 and above, the file will be shipped by default?

I'd suggest to merge it first to master, pick it down to all branches you want. Once the packaging change becomes available we'll submit a docs update and then pick it to the same branches where the packaging update was picked to. We should also keep downstream in mind for that, so I probably wouldn't pick it back further than 3.10.

[aneta-petrova]

I'm going to assume there are no technical issues with the current state of this PR so I'm setting tech review done. Style review would be appreciated now.

[aneta-petrova]

[...] Once the packaging change becomes available we'll submit a docs update [...]

Another assumption I'm going to make: "We'll submit a docs update" means that you intend to track this on your side. If that's not the case, let me know and I'll file a Jira for the docs team and/or myself.

[maximiliankolb]

one tiny suggestion, rest LGTM. Feel free to merge with or without.

[aneta-petrova]

Merged to "master" and cherry-picked:

89c1a95..a556446 3.12 -> 3.12
64fe5db..f3230b9 3.11 -> 3.11
3287c30..5e6337a 3.10 -> 3.10
57dc4c0..56f0d67 3.9 -> 3.9
68d15e2..58c89b3 3.8 -> 3.8
2d58662..db84943 3.7 -> 3.7
763d727..cfd432d 3.6 -> 3.6
649bfa2..ad13123 3.5 -> 3.5

[ekohl]

Another assumption I'm going to make: "We'll submit a docs update" means that you intend to track this on your side. If that's not the case, let me know and I'll file a Jira for the docs team and/or myself.

I added a reminder on the packaging PR.