Project

General

Profile

Bug #7031

Inventory <FQDN> content differs from hostname --fqdn and may lead to unauthorised nodes

Added by François ARMAND over 5 years ago. Updated about 5 years ago.

Status:
Released
Priority:
N/A
Category:
Web - Nodes & inventories
Target version:
Severity:
User visibility:
Effort required:
Priority:

Description

When testing Rudder, at one moment every nodes stopped to being able to get their policies updated. So as always, it was a DNS problem.

The problem was that at that moment, they all decided to send new inventories, and it was after a DHCP new lease - yeah, that would have never happened if not working at 3AM.

In these inventories, the <FQDN> content was <FQDN>myapp.normation.com</FQDN> in place of <FQDN>myapp</FQDN>.

That was because DHCP had modified their resolv.conf, and the new resolv.conf content was:

search normation.com
domain normation.com
nameserver XXXX

But interestingly, on these nodes, "hostname --fqdn" still returned "myapp", and "getent hosts myapp.normation.com" was returning an error. See http://serverfault.com/questions/574301/non-woking-domain-parameter-at-resolv-conf for inputs.

Of course, cf-served.cf was filled with myapp inventory data, so with "myapp.normation.com", and so CFEngine was refusing "myapp" any update.

So, it seems that fusion inventory <FQDN> is filled with a value that IS NOT the DNS resolvable FQDN, so the use of that attribute in 3.1 is really dangerous.


Subtasks

Bug #7570: If RUDDER_HOSTNAME is localhost we should fallback to FQDNReleasedFrançois ARMAND2015-12-08Actions

Related issues

Related to Rudder - Bug #6782: Broken inventory - missing 'FQDN'ReleasedFrançois ARMAND2015-06-23Actions
Related to Rudder - Bug #6711: Hostname in inventory may sometimes be wrongfully in lowercaseReleasedFrançois ARMAND2015-06-11Actions
Related to Rudder - Bug #7001: If domain name is not set in resolv.conf, the inventory generated is invalidReleasedVincent MEMBRÉ2015-07-21Actions
Related to Rudder - Bug #7015: Some inventories have empty FQDN attribute, mandatory in 3.1ReleasedFrançois ARMAND2015-07-21Actions
Related to Rudder - Bug #8022: Node's FQDN-Resolution is sometimes invalidNewActions
Related to Rudder - Bug #7568: Inventory <FQDN> content differs from hostname --fqdn and may lead to unauthorised nodes (impl for system techniques)RejectedActions
#1

Updated by Nicolas CHARLES over 5 years ago

Hum, this is really bad
I had exactly the same issue, and i'm puzzled on why the fqdn is so badly filled
I see two solutions:
  1. don't use the fqdn on 3.1, and revert change made to use it
  2. replace its definition by something that works (like hostname --fqdn on linux, and alike on AIX. keep the value on Windows and Android as it should not depend on resolv.conf)
#2

Updated by Nicolas CHARLES over 5 years ago

  • Related to Bug #6782: Broken inventory - missing 'FQDN' added
#3

Updated by Nicolas CHARLES over 5 years ago

  • Related to Bug #6711: Hostname in inventory may sometimes be wrongfully in lowercase added
#4

Updated by Nicolas CHARLES over 5 years ago

  • Related to Bug #7001: If domain name is not set in resolv.conf, the inventory generated is invalid added
#5

Updated by Nicolas CHARLES over 5 years ago

  • Related to Bug #7015: Some inventories have empty FQDN attribute, mandatory in 3.1 added
#6

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 3.1.1 to 3.1.2
#7

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 3.1.2 to 3.1.3
#8

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 3.1.3 to 3.1.4
#9

Updated by Vincent MEMBRÉ over 5 years ago

  • Target version changed from 3.1.4 to 3.1.5
#10

Updated by Jonathan CLARKE about 5 years ago

  • Assignee set to Benoît PECCATTE

This is potentially disastrous and must be fixed ASAP.

A simple example that shows the problem:

[root@omd ~]# /opt/rudder/bin/run-inventory --local=- | grep -i  -e  hostname -e fqdn -e domain
      <KEY>HOSTNAME</KEY>
      <DNS_DOMAIN>tinker.site</DNS_DOMAIN>
      <FQDN>localhost</FQDN>
      <CMD>grep -i -e hostname -e fqdn -e domain</CMD>
        <POLICY_SERVER_HOSTNAME>192.168.122.198</POLICY_SERVER_HOSTNAME>
      <HOSTNAME>localhost</HOSTNAME>

[root@omd ~]# hostname
omd.tinker.site

Returning "localhost" as a FQDN is simply not useful. This value is used for two reasons in Rudder:

  1. Displaying the node. Folk can't be expected to recognize hundreds of different machines all called "localhost"!
  2. Authorizing nodes to connect to the server. This is done by reverse DNS lookup - which will obviously fail on "localhost"!

Note: Rudder's inventory parsing actually looks at two different fields in the inventory XML: RUDDER/HOSTNAME and OS/FQDN, in that order (the first non empty is taken). We have figured out that RUDDER/HOSTNAME is redundant now - it was introduced in the Fusion Rudder module because Fusion didn't have the hostname in it's inventory. Now that it does, we should fix the Fusion OS/FQDN field, and simply copy it's contents into our RUDDER/HOSTNAME field to avoid code duplication.

So, the problem we're seeing here was introduced by the fix to bug #7001. That bug originally was that - sometimes - the OS/FQDN field was empty. That happens when Perl's hostfqdn() function doesn't figure out the hostname. However, the fix changed the function we used, and now calls out to a different function (hostname --fqdn on Linux).

We didn't really have a problem with the contents of Perl's hostfqdn() - when it wasn't empty. All our tests show it does it's best to a decent, resolvable hostname. So, we're going to revert to using that function, AND check if it returned an empty string, in which case we'll add the hostname ourselves using "hostname" or "hostname -f".

Benoit is going to provide a patch to fix this in 3.1.5. Older versions should also receive the same fix to avoid empty FQDNs.

#11

Updated by Benoît PECCATTE about 5 years ago

  • Assignee deleted (Benoît PECCATTE)
  • Target version changed from 3.1.5 to 2.11.17
#12

Updated by Benoît PECCATTE about 5 years ago

  • Status changed from New to In progress
  • Assignee set to Benoît PECCATTE
#13

Updated by Benoît PECCATTE about 5 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from Benoît PECCATTE to Jonathan CLARKE
  • Pull Request set to https://github.com/Normation/rudder-packages/pull/832
#14

Updated by Benoît PECCATTE about 5 years ago

  • Status changed from Pending technical review to Pending release
  • % Done changed from 0 to 100
#16

Updated by Vincent MEMBRÉ about 5 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 2.11.17, 3.0.12 and 3.1.5 which were released today.

#17

Updated by François ARMAND almost 5 years ago

  • Related to Bug #8022: Node's FQDN-Resolution is sometimes invalid added
#18

Updated by Vincent MEMBRÉ over 4 years ago

  • Related to Bug #7568: Inventory <FQDN> content differs from hostname --fqdn and may lead to unauthorised nodes (impl for system techniques) added

Also available in: Atom PDF