Handle "broken" or systems already registered to another server?

[davealden]

Hi, Is this module supposed to handle "broken" or systems that are already registered to another server (it isn't working for me)? ...dave

[davealden]

@waveclaw thoughts on this? I have a bunch of systems that are registered to our old satellite server and I am hoping to find a module that I can use to migrate them over to our new satellite server. When I tried this module, it:

updates /etc/rhnsm/rhsm.conf with the new info removes the old katello-ca-consume- rpm installs the new katello-ca-consumer- rpm

However, subscription-manager status returns "Overall Status: Unknown" and the /etc/yum.repos.d/redhat.repo file still points at the old satellite server.

...dave

[waveclaw]

My thoughts are "Needs more information" and "I cannot even tell if this is a valid complaint there is so little information." See ESR's famous How to Ask Questions .

However, there are pertinent details beneficial to you and I for examining your situation.

/etc/yum.repos.d/redhat.repo files are managed by the RedHat subscription-manager tool. This module does not diddle that file directly. If you run registration commands yourself and redhat.repo is not changing then you need to contact RedHat Support, not me.

Answering these questions will help you understand what has happened.

1. What version of puppet-subscription_manager was used?
2. What version of Puppet was used?
   • Puppet 2 from Satellite?
   • Puppet Enterprise?
   • Something else?
3. How was the module used: native types in the raw, hiera data fed into the Puppet DSL code, PE groups in a console or even some mix of roles and profiles?
4. How does your site do registration?
   • Registration keys?
   • Passwords and usernames? (do NOT provide the passwords or usernames)
   • Do you mix RedHat subscriptions with Katello pools?
5. What are the details of the source and destination servers?
   • What were they?
   • What versions?
   • Katello? Satellite?
   • There are a lot of bugs in RedHat Satellite related to subscription management prior to 6.2 that cannot be fixed by this module.
6. Is there any debug output from puppet --debug to confirm what the actual actions were?
7. Where is the log of subscription-manager commands?
8. Was the registration command run on existing the servers or were these deployed from the Satellite server?
9. If the registration command ran, what was in the logs?
10. Does the server(s) in question have valid subscriptions in the Satellite or Katello dashboard?

Satellite 6.2.4 and older still uses older Puppet 3 language. The puppet-subscription_manager module version 3 is for the Puppet 4 language. The last version of this module to support Puppet language version 2 and 3 was 2.2.2. That version is EOL. If you are doing this I will have to close the ticket with #wontfix.

And finally: are you sure your /etc/yum.repos.d/redhat.repo file is not immutable? Check that with

lsattr /etc/yum.repos.d/redhat.repo

And see if the 'i' flag appears in the output.

[waveclaw]

To answer your original question:

Yes, the waveclaw/puppet-subscription_manager module handles both broken and moving subscriptions.

It is tested on many combinations of server types for both renaming the Satellite or Katello server and invalidating client subscriptions.

[davealden]

@waveclaw

Hi, I'm sorry, I didn't mean for you to solve my problem with the very limited amount of information I gave, I just meant for you to let me know if you expected it to work or not. Then I was going to dive into it more deeply. Thanks for taking the time to ask the questions (I really do appreciate all the time and effort you put into your modules, being an open source author myself, I know that too many folks assume that we are here to fix there problems :).

What version of puppet-subscription_manager was used?

3.2.2

What version of Puppet was used?

We are using the latest open source versions:

server: 2.7.2 agent: 4.10.4

How was the module used: native types in the raw, hiera data fed into the Puppet DSL code, PE groups in a console or even some mix of roles and profiles?

native type:

class { 'subscription_manager':
  server_hostname => $server,
  org             => $org,
  activationkey   => $key,
  autosubscribe   => true,
  servicelevel    => 'STANDARD',
  config_hash     => {
    server_prefix     => '/rhsm',
    rhsm_baseurl      => "https://${server}/pulp/repos",
    rhsm_repo_ca_cert => '%(ca_cert_dir)skatello-server-ca.pem',
  },
  service_name    =>'rhsmcertd',
  force           => $force,
}

Note that I also tried the rhsm_repo_ca_cert parameter as you suggested ('%(ca_cert_dir)s/katello-server-ca.pem'), but this changes the rhsm_repo_ca_cert from what was setup originally (both produce the same end result, a "subscription-manager status" returns unknown).

How does your site do registration?

registration keys

Do you mix RedHat subscriptions with Katello pools?

no

What are the details of the source and destination servers?

The old server is a Red Hat Satellite Server 6.2.8, the new one is 6.2.9.

Is there any debug output from puppet --debug to confirm what the actual actions were?

puppet-debug.txt

Where is the log of subscription-manager commands?

rhsm.log.txt

Was the registration command run on existing the servers or were these deployed from the Satellite server?

Both, they were deployed from the server, but I've also run subscription-manager commands manually when switching back and forth between the old server and new server. I can easily switch back and forth using the following (after setting $satelliteserver and $key):

rpm -e rpm -qa | grep katello-ca-consumer rpm -Uhv http://${satelliteserver}/pub/katello-ca-consumer-latest.noarch.rp subscription-manager unregister subscription-manager register --org=ASC --activationkey=${key} --force

If the registration command ran, what was in the logs?

I've included the rhsm.log - is there another logfile that would be helpful?

Does the server(s) in question have valid subscriptions in the Satellite or Katello dashboard?

no. It doesn't show up on the dashboard. If run the commands mentioned earlier (to manually subscribe), it does show up with a valid subscription.

Satellite 6 uses older Puppet 3, but puppet-subscription_manager version 3 is for Puppet 4 and not compatible. If you are doing this I will have to close the ticket with #wontfix. The last version of this module to support Puppet 3 was 2.2.2 and is EOL.

I am specifically NOT using the puppet 3 that comes with satellite 6, I have installed 4.10.4 on all of my systems.

And finally: are you sure your /etc/yum.repos.d/redhat.repo file is not immutable? Check that with: lsattr /etc/yum.repos.d/redhat.repo - And see if the 'i' flag appears in the output.

It is not immutable.

...dave

[waveclaw]

I'm just a week-ender for supporting this so thank you for your understanding. I do use this module at work so it gets more tender love than a true weekend-only project.

I also thank you for eluding most of the logfiles.

It does look like the module fails to create the rhsm_register resource for your situation. Your situation describes case III in the minfests/config.pp file. This is the case registered to different server.

You are using the module as a whole (class { 'subscription_manager': ...). This means you depend on this bit of logic in manifests/config.pp to trigger registration or re-registration:

  if ($::facts['rhsm_identity'] == '' or $::facts['rhsm_identity'] == undef or
      $::facts['rhsm_ca_name'] != $::subscription_manager::server_hostname or
      $::subscription_manager::force == true ) {
      rhsm_register { $::subscription_manager::server_hostname:
        ensure  => present,
        require => Rhsm_config['/etc/rhsm/rhsm.conf'],
        *       =>  $_settings
      }

Are you getting anything from the facter rhsm_identity fact on a broken server?

If the ca_name and new server's hostname match[1] and you are not forcing then that fact may be broken.

While I don't encourage people to use the force option, it will garuntee the creation of the rhsm_register resource and make it run subscription-manager with the --force flag.

I'm also curious as to why there is no debug output from the rhsm_register resource in puppet-debug.txt. There is a catalog dependency notice for rhsm_register:

Debug: /Stage[main]/Subscription_manager::Config/Rhsm_register[satellite-01.asc.ohio-state.edu]/require: subscribes to Rhsm_config[/etc/rhsm/rhsm.conf]

I would not expect this entry to exist if the resource didn't actually end up in the catalog. It should cause a dangling entry on the graph and fail the compile:

---

1. It looks like in puppet-debug.txt your old name was sat-01.asc.ohio-state.edu and the new name was satellite-01.asc.ohio-state.edu. That should have tripped the test $::facts['rhsm_ca_name'] != $::subscription_manager::server_hostname.
   • The way Puppet runs facts means there should be no possibility of a race condition between facts values and things than change them.
   • If $server was set to satellite-01.asc.ohio-state.edu in the class { 'subscription_manager': ... code and you were using a proxy so that the rhsm_ca_name would match that value then this test would fail.

[davealden]

Are you getting anything from the facter rhsm_identity fact on a broken server?

No. If I run 'subscription-manager identity', I get back:

Unable to verify server's identity: tlsv1 alert unknown ca

While I don't encourage people to use the force option, it will guarantee the creation of the rhsm_register resource and make it run subscription-manager with the --force flag.

I've changed the instantiation to:

class { 'subscription_manager':
  server_hostname => 'satellite-01.asc.ohio-state.edu', # $server,                                                                                                                                 
  org             => 'ASC', # $org,                                                                                                                                                                
  activationkey   => 'rhel-7workstation-production-asc', # $key,                                                                                                                                   
  autosubscribe   => true,
  servicelevel    => 'STANDARD',
  config_hash     => {
    server_prefix     => '/rhsm',
    rhsm_baseurl      => 'https://satellite-01.asc.ohio-state.edu/pulp/repos', # "https://${server}/pulp/repos",                                                                                   
    rhsm_repo_ca_cert => '%(ca_cert_dir)skatello-server-ca.pem',
  },
  service_name    => 'rhsmcertd',
  force           => false, # $force,                                                                                                                                                              
}

If I run this with force=>false, I can run it over and over and it never registers correctly. If I reset the system so it's pointing at the old server, change force to be true, and run it multiple times - on the second run it comes away properly registered.

...dave

[waveclaw]

Unable to verify server's identity: tlsv1 alert unknown ca

You have broken SSL certificates for the Satellite server installed at some point. This can happen when moving from one Satellite server to another. It is also a risk when registering to a proxy / capsule instead of the primary Satellite server.

See this access.redhat.com article for example solutions.

In general this module cannot fix these SSL issues. The module "sort of" fixes it through the brute force certificate reinstalled with '--force'. But this is fixing a flat tire by crushing the car into a cube in a compactor.

One of the solutions from RedHat is to change ssl_verify_depth in /etc/rhsm/rhsm.conf. That is available as an option in the config_hash. This setting tells the SSL libraries how far up a certificate chain to check for valid signatures.

In the 'tlsv1 alert unknown ca' situation the signature authority for the SSL certificate from Satellite is unavailable to check. Reducing that setting is possible to reduce the depth checked. Increasing the depth is sometimes needed when the Satellite CA itself is signed by another PKI solution such as FreeIPA or an in-house PKI service. To disable SSL verification requires other options in rhsm.conf to also be set.

Without examining your specific SSL environment and packages on your system I cannot provide further assistance.

[davealden]

Hmm. The odd thing is that if I "manually" register the system back and forth between the two satellite servers (directly, we have no proxy/capsule servers), it all "just works". I can run:

rpm -e rpm -qa | grep katello-ca-consumer rpm -Uhv http://${satelliteserver}/pub/katello-ca-consumer-latest.noarch.rp subscription-manager unregister subscription-manager register --org=ASC --activationkey=${key} --force

changing the $satelliteserver between runs and after each run I can run 'subscription-manager identity' and it shows the correct output (not the unknown ca error).

[waveclaw]

As I mentioned

subscription-manager register --org=ASC --activationkey=${key} --force

"sort of" fixes it through the brute force certificate reinstalled with '--force'.

You have a workaround and it is the only solution I can support in this situation.