Bug 1375706

Description of problem:

When registering a Content host with Katello, we are able to successfully register a host using the short hostname. WHen trying to register the same host with puppet, using this command:

puppet agent -t --server xxxxxxxx.xxx.xxxx.xxx --certname `hostname -s`

Puppet correctly identifies this host as a short hostname when generating the SSL certificate, however the web UI, creates a new host, one for the content host (short) and one for the puppet (FQDN). Below is the output of our registration command:

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

Satellite 6.2


Actual results:

web UI shows host for content host with shortname, and one for puppet with fqdn.


Expected results:

Consistently shows hostname used for registration (in this case, short)


Additional info:

  Based on our investigation, the Ruby template file  is displaying the column name from the PostgreSQL database named foreman/hosts. 
  
    =============
    /usr/share/foreman/app/views/hosts/_list.html.erb
 
            <% hosts.each do |host| %>
      <tr>
        <td class="ca">
          <%= check_box_tag "host_ids[]", nil, false, :id => "host_ids_#{host.id}", :class => 'host_select_boxes', :onclick => 'hostChecked(this)' %>
        </td>
        <td class="ellipsis"><%= name_column(host) %>    <---- here
        </td>
        <td class="hidden-xs ellipsis"><%= (icon(host.operatingsystem, :size => "16x16") + " #{host.operatingsystem.to_label}").html_safe if host.operatingsystem %></td>
        <td class="hidden-xs ellipsis"><%= host.environment %></td>
        <td class="hidden-tablet hidden-xs ellipsis"><%= model_name host %></td>
        <td class="hidden-tablet hidden-xs"><%= label_with_link host.hostgroup, 23, @hostgroup_authorizer %></td>
        <td class="hidden-tablet hidden-xs ellipsis"><%= last_report_column(host) %></td>
    =============

  Satellite is creating the certname correct as we can see on the SQL output you provided this afternoon, however it is not the column being displayed by the webUI which may be creating the confusing. During our tests, if we rename the value on the field "name" to match with the certname the short name is displayed, however, this was just a troubleshooting step and should not be used for now. 
  
    ==============
      
      foreman=# select id, name, certname from hosts;
         id |           name           |       certname        
        ----+--------------------------+-----------------------
          9 | xxxx13.xxx.xxxx.xxx    | 
         32 | xxxx6505.xxx.xxxx.xxx | 
         53 | xxx01.xxxx.xxxx.xxx    | 
         39 | xxlab10                  | 
         16 | xxxlab65                | 
         38 | xxxlab6507              | 
         33 | xxxlab6505              | 
         42 | xxxlab6508              | 
          5 | xxxxxx12                 | 
         37 | xxxxlab67                | 
         18 | xxxxlab6502              | 
         52 | xxxx01                  | xxxx01
         19 | xxxxlab6503              | 
         12 | xxxxx12.xxx.xxxx.xxx    | xxxxxx.xxx.xxxx.xxx
         60 | xxxxlabsat5.xxx.xxxx.xxx | xxxxlabsat5
         58 | xxxxlab01                | 
         59 | xxxxlab01.xxx.xxxx.xxx   | xxxxlab01
        (17 rows)

      foreman# update hosts set name = 'xxxxab01' where id = 59;
      foreman# commit;
      
        --- the troubleshooting step above changed the display to shortname
    ==============

    Since for a provisioning on Satellite is requires a domain it seems that is the reason of why the FQDN is being used instead the short name. Satellite (using the Foreman capabilities) requires a domain and subnet so then it assumes the FQDN. 
    
    Since you want to use short names, as defined by the Puppet certificate (CN=shortname), we will follow-up with engineering if is the situation to an RFE to use short names instead. 
    
    As you already mentioned in the case, if you override the FQDN Puppet fact via /etc/facter/facts.d you can workaround it. 

After some additional review of this, overriding the facter fact "fqdn" will _not_ be a viable workaround.  If we do this, we will lose access to that "fact" (fqdn) should we need to use it in future puppet modules.