Fix rex_pub_key retrieval for containerized Satellite

[sjha4]

Problem Statement

Update REX public key retrieval to handle foremanctl foreman-proxy container

Solution

Use podman exec foreman-proxy cat /var/lib/foreman-proxy/ssh/id_rsa_foreman_proxy.pub to retrieve public key contents.

Related Issues

Summary by Sourcery

Handle REX public key retrieval correctly for containerized Satellite installations and validate that the retrieved key is not empty.

Bug Fixes:

• Fix REX public key retrieval when Satellite is installed via foremanctl using the foreman-proxy container.

Enhancements:

• Add validation to raise an error if the REX public key retrieval returns an empty key.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Adjusts rex public key retrieval to support foremanctl/foreman-proxy running in a container and adds validation that the retrieved key is non-empty.

Flow diagram for updated rex_pub_key retrieval logic

flowchart TD
    A[Call rex_pub_key] --> B{install_method == InstallMethod.FOREMANCTL}
    B -->|yes| C[execute podman exec foreman-proxy cat /var/lib/foreman-proxy/ssh/id_rsa_foreman_proxy.pub]
    B -->|no| D[execute cat rex_key_path]
    C --> E[Strip result.stdout to key]
    D --> E
    E --> F{key is empty?}
    F -->|yes| G[raise ValueError with status and stderr]
    F -->|no| H[return key]

Loading

File-Level Changes

Change	Details	Files
Update rex_pub_key property to handle containerized foreman-proxy and validate the retrieved key.	Import InstallMethod enum within the rex_pub_key property. Branch on install_method to use podman exec against the foreman-proxy container when running via foremanctl, otherwise read the existing rex key path. Strip stdout from the execution result and raise a ValueError if the key is empty, including command status and stderr in the error message.	robottelo/hosts.py

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've left some high level feedback:

• The hard-coded path and container name in the FOREMANCTL branch (foreman-proxy and /var/lib/foreman-proxy/ssh/id_rsa_foreman_proxy.pub) might benefit from being configurable or derived from existing settings to avoid breakage if these values change.
• Consider moving the InstallMethod import to the module level to avoid repeated imports and potential circular import issues when rex_pub_key is accessed frequently.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The hard-coded path and container name in the FOREMANCTL branch (`foreman-proxy` and `/var/lib/foreman-proxy/ssh/id_rsa_foreman_proxy.pub`) might benefit from being configurable or derived from existing settings to avoid breakage if these values change.
- Consider moving the `InstallMethod` import to the module level to avoid repeated imports and potential circular import issues when `rex_pub_key` is accessed frequently.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sjha4]

Do I need another ack on this @vijaysawant or is this ok to merge? Not sure about the whole review process here..

[vsedmik]

Left one proposal

[sjha4]

@Gauravtalreja1 I think fetching this from podman secret makes most sense in case of foremanctl rather than relying on the cat.. We can get around reading files from mounted paths entirely with this.

[Gauravtalreja1]

Good suggestion! I don't have a strong opinion either way, but I'd lean toward sticking with podman exec cat .. here, it mirrors the existing installer pattern and keeps the code readable and consistent across both install methods.
Additionally, I believe the podman secret name is an implementation detail that could change in future, while key path would be consistent.

CC @evgeni curious to hear your opinion as well on this.

[evgeni]

Is there a reason not to use the APIs we have (Foreman's /api/smart_proxies which contains the key in remote_execution_pubkey or the Smart Proxy API at /ssh/pubkey) to retrieve the key?

[Gauravtalreja1]

@sjha4 I'm not entirely familiar with this API endpoint and don't have a strong opinion against it, but if it works, it would be a much cleaner solution than checking for the public key with two different install-methods

[evgeni]

rex is always enabled on sat: theforeman/foremanctl#628

[Gauravtalreja1]

Its not enabled today how we deploy without flavor, but I believe its good to have that check in place as its quick one

[sjha4]

Are there plans for something similar with REX enabled on capsule/smart proxies with deploy-proxy. The current default flavor https://github.com/theforeman/foremanctl/blob/master/src/vars/flavors/foreman-proxy-content.yml doesn't have it.

[Gauravtalreja1]

yes, maybe in future we'll have dedicate capsule flavor which will have this enabled by default, but I think we do need a quick check today to see if its enabled then fetch pubkey

[sjha4]

@Gauravtalreja1 With the last push, I have taken your suggestion and tested the existing path ~foreman-proxy/.ssh/id_rsa_foreman_proxy.pub in both installs..For @Evegeni's question I don't know why we don't use the APIs, not sure if it was written this way for readability or cause the endpoints differ for sat and capsule and the method to get key fits both?

[evgeni]

You can get the key of every capsule from the sat.
It's just there is also an API on the capsule.

[sjha4]

@evgeni Ack..The /ssh/pubkey is promising.

@Gauravtalreja1 , @vsedmik , @vijaysawant Thoughts on this? We could refactor the logic for rex_pub_key to grab the rex public key from API at url:8443/ssh/pubkey for smart proxies which does the File read on the server directly (https://github.com/theforeman/smart_proxy_remote_execution_ssh/blob/master/lib/smart_proxy_remote_execution_ssh/api.rb#L12) or use the existing rex_key_path approach? Can't really talk about why the rex_key_path approach was taken so I'll lean into your opinions on this.

[vsedmik]

@evgeni Ack..The /ssh/pubkey is promising.

@Gauravtalreja1 , @vsedmik , @vijaysawant Thoughts on this? We could refactor the logic for rex_pub_key to grab the rex public key from API at url:8443/ssh/pubkey for smart proxies which does the File read on the server directly (https://github.com/theforeman/smart_proxy_remote_execution_ssh/blob/master/lib/smart_proxy_remote_execution_ssh/api.rb#L12) or use the existing rex_key_path approach? Can't really talk about why the rex_key_path approach was taken so I'll lean into your opinions on this.

I'm not sure about the why either, I haven't been working with REX too often, guessing it just seemed more straightforward. @pondrejk might know more.

[Gauravtalreja1]

@sjha4 I'm not entirely familiar with this API endpoint and don't have a strong opinion against it, but if it works, I think it would be a much cleaner solution than checking for the public key with two different install-methods. That said, it's up to you whether you'd like to include this refactor in the same PR or handle it separately.

[sjha4]

@Gauravtalreja1 I prefer merging this with the old rex_key_path approach which has acks and I will open a fresh PR for the refactoring unless there are strong objections.

[Gauravtalreja1]

@sjha4 ACK, I'll merge even without PRT results this time since there are no REX tests to run as the feature is disabled by default in the current containerized deployments