It turns out that the 'environments' that the D-Bus Register*() APIs
accept are the IDs of the environments, and not the user-facing names of
the environments (which is what the module has been accepting so far).
Since there is no easy way to do the mapping manually, for now use again
the subscription-manager CLI for registering when environments are
specified.
Factorize the current logic to determine whether use 'environments' as
D-Bus registration option (rather than 'environment') in an own
function, so it is easier to read it and maintain it.
With the small helper function in place, extend the logic to support
CentOS: it is in practice the same as the RHEL one, with an additional
check to support CentOS Stream 8 (which is a rolling release, and not
versioned).
When registering using D-Bus and using a version of subscription-manager
with an unimplemented 'force' option, then unregister manually the
system only if it is registered. 'subscription-manager unregister'
errors out when trying to unregister an already unregistered system.
The module currently has a static 'required_if' statement for its
parameters that forces any of 'username' or 'activationkey' or 'token'
in case state=present; while this is generally a good idea, it can be
an extra requirements in some cases. In particular, if the system is
already registered, there is no need for credentials -- some of the
operations of the module, such as manipulating pools, can be done
perfectly without credentials.
Hence:
- change the static 'required_if' to require credentials only when
forcing the registration
- check for credentials manually when a registration is needed, i.e.
on an unregistered system; the fail message is the same as the one
shown by 'required_if'
Adapt the tests to this new situation:
- test_without_required_parameters now needs to mock an unregistered
system
- add a new version of test_without_required_parameters to test an
already registered system
- add a simple test case for only state=present usable on an already
registered system
- remove the credentials from a test case for pool attachment that
mocks an already registered system
subscription-manager on RHEL installs a symlink in /usr/bin to
console-helper (part of usermode), which triggers an interactive prompt
for root credentials when run as user. It seems that console-helper
does not handle well non-interactive contexts (e.g. without a TTY for
input), and thus it will hang waiting for input when run as user in an
Ansible task.
Since subscription-manager requires root already anyway (and it will
fail when explicitly run as user), then apply the same logic locally on
all the modules that interact with it: redhat_subscription,
rhsm_release, and rhsm_repository.
subscription-manager currently does not have a way to get credentials
(username, password, activation keys, organization ID) in a secure way:
the existing command line parameters can be easily spotted when running
a process listing while 'subscription-manager register' runs.
There is a D-Bus service, which is used by e.g. cockpit and Anaconda to
interface with RHSM (at least for registration and common queries).
Try to perform the registration using D-Bus, in a way very similar to
the work done in convert2rhel [1] (with my help):
- try to do a simple signal test to check whether the system bus works;
inspired by the login in the dconf module
- pass most of the options as registration options; for the few that are
not part of the registration, execute 'subscription-manager' manually
- add quirks for differently working (or not) registration options for
the D-Bus Register*() methods depending on the version of RHEL
- 'subscription-manager register' is used only in case the signal test
is not working; silent fallback in case of D-Bus errors during the
registration is not done on purpose to avoid silent fallback to a less
secure registration
[1] https://github.com/oamg/convert2rhel/pull/540/
Add the `server_proxy_scheme` parameter to configure the scheme used for
the proxy server. This completes the configuration parameters for the
proxy server.
Fixes#3486. From the man-pages of subscription-manager, none of the
parameters used are tied to the activationkey except the two that remain
in its else-clause.
Note that type is not mentioned in the man-pages on 7.6 (at least), but
is still present and available.
Co-authored-by: Thor K. H <thor@roht.no>
Stop passing all the "rhsm_", and "server_" module arguments to
"Rhsm.register()", and thus as arguments for
"subscription-manager register":
- right before calling "Rhsm.register()", "Rhsm.configure()" is called
to configure subscription-manager with all the "rhsm_", and "server_"
arguments; hence, they are already configured
- the passed argument to "--serverurl" is partially wrong:
"Rhsm.register()" passes only the hostname, whereas the other bits
(port and prefix) are supported too; this "works" because port and
prefix were already configured previously, and the lax parsing that
subscription-manager does allows for missing bits
- the parsing done by subscription-manager for "--baseurl" strips out
the URL scheme and always uses https: this means that specifying
"rhsm_baseurl: http://server" as module parameter will be taken as
"https://server" by subscription-manager; since "rhsm_baseurl" is
already configured by "Rhsm.configure()", this issue is gone
Do not mention an explicit version of Satellite for an environment to
use; future versions of Satellite will support that, and older versions
are long EOL.
Also mention Katello next to Red Hat Satellite.