Bug 978828

Well my impression about your workflow is:

1. Install the product
2. Change your hostname
3. Re-run the installer with the same params
4. Try to logon, it does redirect to a wrong (old) hostname.

We should provide at least one of the following

a) Warning to customers not to do that;
b) Howto document about how to change hostname;
c) Fix the installer to detect that (challenging!)

The problem with login in here is that you don't run Signo and Katello on same domain. The cookie is not preserved across multiple domains. New version of Signo will support cross domain authentication.

The question is whether installer should modify files that could be customized by user. In this case, it would modify at least katello.yml. Also it would have to regenerate certificates.

To fix current setup you can change signo url in katello.yml configuration file. It's under key sso.provider_url. However when you change hostname after initial configuration there may be some other issues related to certificates.

My biggest concern was that customers would do exactly as I have done and this creates a support burden for GSS.

When you say "you don't run Signo and Katello on same domain", do you mean that due to the change in configuration it doesn't work ?


> The question is whether installer should modify files that could be 
> customized by user. In this case, it would modify at least katello.yml.
> Also it would have to regenerate certificates.

My biggest concern was that customers would do exactly as I have done and this creates a support burden for GSS.

When you say "you don't run Signo and Katello on same domain", do you mean that due to the change in configuration it doesn't work ?

> The question is whether installer should modify files that could be 
> customized by user. In this case, it would modify at least katello.yml.
> Also it would have to regenerate certificates.

Is this feature/fix planned that will be easily done by customers at time of final release ?

> When you say "you don't run Signo and Katello on same domain", do you mean that > due to the change in configuration it doesn't work ?

Yes, new configuration left old hostname settings intact which means that katello thinks Signo is running on different domain.

> Is this feature/fix planned that will be easily done by customers at time of final release ?

Future Signo will be able to handle this however cleaner solution would be to change configurations as well.

Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

Wade, can you please test this script against your instance that is wrong? I am not able to reproduce, but I created checker function that will force users to either fix reverse DNS first or to provide environment variable if they are sure it is set up correctly (in case the check does not work properly).

Please run this script with ruby:

#!/usr/bin/env ruby
require 'socket'
require 'resolv'
def check_hostname
  hostname = Socket.gethostname
  Socket.gethostbyname hostname
  Socket.gethostbyname 'localhost'
  $stderr.puts "WARNING: FQDN is not set!" unless hostname.index '.'
  # Check reverse DNS against hostname IP address
  unless ENV['REVERSE_DNS_CORRECT']
    hostname_ip = Socket::getaddrinfo(hostname, nil)[0][3]
    resolved_name = Resolv.getname(hostname_ip)
    raise Resolv::ResolvError unless hostname != resolved_name
  end
  puts "ALL OK"
rescue SocketError => e
  puts "Unable to resolve '#{hostname}' or 'localhost'. Check your DNS and /etc/hosts settings."
rescue Resolv::ResolvError => e
  puts "Reverse DNS entry for '#{hostname_ip}' ('#{hostname}') is not correct. Cannot continue."
end
check_hostname

It should print "ALL OK" when no misconfiguration is found, it should print an error if:

 - hostname is not set
 - hostname or localhost does not resolve
 - IP address of hostname entry does not exist
 - the IP address has not valid reverse entry

Patch upstream: https://github.com/Katello/katello-installer/pull/62

I'm hesitant to put this into MDP2 but am willing to get it into MDP3 after we test it out a bit.

punting to MDP3 unless someone says otherwise

Mike, I think you can safely put this into MDP2 because I was aware this could be blocker and there is clear information to the user that he can override this behavior using env. variable REVERSE_DNS_CORRECT. So in case there is a bug, this test can be completely skipped. But if you don't like it, I understand.

Ok handing over to Ivan: Please incorporate this change into the new foreman-katello installer as a kafo checker. We do not want this change in foreman upstream as we don't need reverse DNS to be set properly for Foreman.

Ivan, when implementing this check for katello plugin installer, note there is one another fix: https://github.com/Katello/katello-installer/pull/64 ;)

Hi Wade, can you re-test this one using the Satellite 6 beta?

As I dont know which particular iso to test (i'm only on the fringe of sat 6 knowledge) which ISO should I be downloading/using ?

The Satellite 6 architecture no longer supports the 3 separate applications (aka, foreman, katello and signo).  It is now a single application, with a single interface to log in to.  Given this fundamental change to the architecture, I am going to close this bug.  If a similar issue is encountered for Satellite 6.1.1 (GA), let's open a separate bugzilla and in the process attach the foreman-debug output for the scenario.