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.

Sign up for GitHub

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

Fixes #37947 - install katello-host-tools by default #10358

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from
Open

Fixes #37947 - install katello-host-tools by default #10358

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion app/views/unattended/provisioning_templates/host_init_config/host_init_config_default.erb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -73,7 +73,7 @@ if command -v subscription-manager &>/dev/null; then
subscription-manager refresh
fi

<% if host_param_true?('redhat_install_host_tools') -%>
<% if host_param_true?('redhat_install_host_tools', true) -%>
Copy link
Contributor

Choose a reason for hiding this comment

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

Since only debian, suse, and ubuntu need this by default, what do you think about adding specific checks here for those OSs to install katello host tools by default?
It might also be worth adding a check for plugin_present?('katello') since katello-host-tools isn't useful without Katello.

This template seems to make different assumptions compared to redhat_register.erb about the Foreman configuration.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, is it safe to assume that katello-host-tools will be available in the host's repository?
I'm not sure exactly where this template comes into play, so I'm not sure if that's a safe assumption.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The check about is plugin Katello used, is already there some lines above.

I changed the default to the same as on redhat_register. Katello host tools should be delivered as this is done after the sub man registration.

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't fully understand when this template gets used vs redhat_register. I see, in redhat_register, the katello host tools installation is guarded behind if host_param('kt_activation_keys'). Is the use of kt_activation_keys not some special workflow where a user is more likely to have the katello host tools package distributed?

I just want to make sure users aren't going to suddenly see the script start failing if they're not distributing katello host tools.

Copy link
Member

Choose a reason for hiding this comment

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

I think this is global registration where redhat_register is provisioning.

Copy link
Contributor Author

@sbernhard sbernhard Oct 30, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

be on by default, users will need to know to set redhat_install_host_tools to false

=> same for the redhat_register snippet :-)

@maximiliankolb any thoughts regarding documentation? Can we add both parameter to the documentation (redhat_install_host_tools and redhat_install_host_tracer_tools)

Copy link
Contributor

Choose a reason for hiding this comment

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

From a user perspective, I expect that provisioning a host or registering a host to Foreman+Katello means that I have access to package lists in Foreman UI and to hints if services/the Kernel has to be restarted. With this in mind, I'd recommend, if at all, documenting how to disable this by changing a default parameter.

Regardless of the OS, if you provision a host and register a host to Foreman+Katello, the templates should install whatever is necessary to have the best user experience. I cannot speak much for Foreman on EL/Deb.

Current docs: Installing Tracer + Enabling Tracer

If we change the default from "is not installed" to "is installed automatically because of a new default host param", I can make the appropriate changes in foreman-documentation.

Copy link
Contributor

Choose a reason for hiding this comment

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

Current docs: Installing Tracer + Enabling Tracer

the important part being the Prerequisite, which you have to do yourself :)

image

Copy link
Contributor

Choose a reason for hiding this comment

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

But there's a difference in doing this after your host is registered to F+K and you can provide content etc. vs registering a host using global host registration where you have to provide just the right repos. Any more packages other than subscription-manager have again more dependencies that users have to cater for.

Strictly speaking, the Client repo is not sufficient for any OS (I did not test RHEL):

$ podman run --rm -it almalinux:9.4

# rm -fr /etc/yum.repos.d/almalinux-*
# vi /etc/yum.repos.d/client.repo
# dnf makecache
...
# cat /etc/yum.repos.d/client.repo
[client]
baseurl=https://yum.theforeman.org/client/latest/el9/x86_64/
enabled=1
gpgcheck=0
name=client
sslverify=0

# dnf install katello-host-tools-tracer
Last metadata expiration check: 0:00:26 ago on Thu Oct 31 09:00:21 2024.
Error: 
 Problem: conflicting requests
  - nothing provides crontabs needed by katello-host-tools-tracer-4.4.0-1.el9.noarch from client
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

I assume that most packages in Client repos have the same issue, e.g. OpenSCAP client requires Ruby ...

My conclusion: Limit pkg installation to a minimum when provisioning/registering a host. After the host is registered to F+K with an AK, have the user provide the "default" OS repos (e.g. BaseOS + AppStream on EL8+) and then install whatever from the combination of default OS repos + Client repo.

Disclaimer: tested with a container. I do not have access to VMs that are not provisioned in an automated way and therefore have automated pkg installations ... One could argue that crontab is installed by default in a EL9 VM compared to a container.

Copy link
Member

Choose a reason for hiding this comment

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

  • nothing provides crontabs needed by katello-host-tools-tracer-4.4.0-1.el9.noarch from client

This is in baseos

My conclusion: Limit pkg installation to a minimum when provisioning/registering a host. After the host is registered to F+K with an AK, have the user provide the "default" OS repos (e.g. BaseOS + AppStream on EL8+) and then install whatever from the combination of default OS repos + Client repo.

IMHO you always want the "default" OS repos and I can't think of a use case where you don't provide those. When you're subscribed to a content view, you always want to include those. The way I always interpreted the note as that you want base + Foreman Client, not "just Foreman Client". The AK should provide access to both.

<%= install_packages('katello-host-tools') -%>
<% end -%>

Expand Down
Loading