When subscribing a system with an activationkey, it seems (sometimes?)
required to pass the "--org <number>" parameter to subscription-manager.
Activation Keys can be created through the Red Hat Customer Portal, and
a subscription can be attached to those. This makes is easy to register
systems without passing username/passwords around.
The organisation ID can be retrieved by executing the following command
on a registered system (*not* the account number):
# subscription-manager identity
URL: https://access.redhat.com/management/activation_keys
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Reviewed-by: Ken Dreyer <kdreyer@redhat.com>
Prior to this commit, Ansible would pass '--activationkeys <value>' as a
literal string, which the remote server would interpret as a single
argument to subscription-manager.
This led to the following failure message when using an activation key:
subscription-manager: error: no such option: --activationkey "mykey"
Update the arguments so that the remote server will properly interpret
them as two separate values.
In cases when the python-apt package is not installed, ansible will
attempt to install it. After this attempt, it tries to import the
needed apt modules, but forgets to import the apt.debfile module.
The result is that playbooks that use the dpkg argument on a machine
that does not initially have the python-apt package available will
fail with the following error
AttributeError: 'module' object has no attribute 'debfile'
This patch adds the appropriate import to the apt module to ensure
that necessary libraries are available in cases when the dpkg argument
is being used on a system that does not initially have the python-apt
package installed
There is no call to yum_base using 'cachedir' argument, so
while it work fine from a cursory look, that's useless code,
and so should be removed to clarify the code.
Using the rpm module prevent a uneeded fork, and permit
to skip the signature checking which slow down a bit the
operation, and which would be done by yum on installation
anyway.
Yum does not always update to latest package version unless metadata cache has expired. By runing yum makecache, we ensure the metadata cache has been updated.
Signed-off-by: René Moser <mail@renemoser.net>
