Bug 978828 - Installer does not detect changed hostname
Installer does not detect changed hostname
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Installer (Show other bugs)
6.0.0
x86_64 Linux
medium Severity low (vote)
: Unspecified
: --
Assigned To: Ivan Necas
Katello QA List
https://github.com/Katello/katello-in...
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-27 03:52 EDT by Wade Mealing
Modified: 2015-08-13 14:20 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-13 14:20:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Wade Mealing 2013-06-27 03:52:58 EDT
Description of problem:

After setting a hostname that works with forward lookups, having the system configured with a dns server that uses a reverse lookup, the installer will create a situation in which when visiting the web interface to katello, it will redirect the system to a webpage (https://) of the original reverse lookup name.

Version-Release number of selected component (if applicable):

katello-all-1.4.2-18.el6sat.noarch

How reproducible:

One out of One times.

Steps to Reproduce:
1. Modify system hostname to a resolvable fqdn.
2. Have a different reverse name for the host.
3. Continue the install, visit the http://yourserver/katello

Actual results:

Get redirected to the original reverse resolved name.  This is bad.  Because it ends up looping around in redirections and firefox/chrome will not ever finish looping.

Expected results:

Use the systems configured fqdn, instead of the reversed resolved name.


Additional info:

Talked to lzap about this, said to lodge the bug.  Good experience, would talk to again.
Comment 2 Lukas Zapletal 2013-06-27 04:02:42 EDT
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!)
Comment 4 Marek Hulan 2013-07-08 02:17:51 EDT
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.
Comment 5 Wade Mealing 2013-07-08 02:27:35 EDT
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.
Comment 6 Wade Mealing 2013-07-08 02:29:32 EDT
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 ?
Comment 7 Marek Hulan 2013-07-08 02:45:29 EDT
> 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.
Comment 8 RHEL Product and Program Management 2013-09-17 00:24:54 EDT
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.
Comment 11 Lukas Zapletal 2013-10-30 07:19:43 EDT
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
Comment 12 Lukas Zapletal 2013-10-30 07:24:54 EDT
Patch upstream: https://github.com/Katello/katello-installer/pull/62
Comment 13 Mike McCune 2013-11-01 16:30:11 EDT
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
Comment 14 Lukas Zapletal 2013-11-04 05:40:10 EST
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.
Comment 15 Lukas Zapletal 2013-11-05 16:43:28 EST
Ivan, when implementing this check for katello plugin installer, note there is one another fix: https://github.com/Katello/katello-installer/pull/64 ;)
Comment 18 Brad Buckingham 2014-07-30 13:13:47 EDT
Hi Wade, can you re-test this one using the Satellite 6 beta?
Comment 19 Wade Mealing 2014-07-30 23:54:57 EDT
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 ?
Comment 20 Brad Buckingham 2015-08-13 14:20:02 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.