Bug #7031
closed
Inventory <FQDN> content differs from hostname --fqdn and may lead to unauthorised nodes
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 XXXXBut 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.
Updated by Nicolas CHARLES over 9 years ago
I had exactly the same issue, and i'm puzzled on why the fqdn is so badly filled
I see two solutions:
- don't use the fqdn on 3.1, and revert change made to use it
- 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)
Updated by Nicolas CHARLES over 9 years ago
- Related to Bug #6782: Broken inventory - missing 'FQDN' added
Updated by Nicolas CHARLES over 9 years ago
- Related to Bug #6711: Hostname in inventory may sometimes be wrongfully in lowercase added
Updated by Nicolas CHARLES over 9 years ago
- Related to Bug #7001: If domain name is not set in resolv.conf, the inventory generated is invalid added
Updated by Nicolas CHARLES over 9 years ago
- Related to Bug #7015: Some inventories have empty FQDN attribute, mandatory in 3.1 added
Updated by Vincent MEMBRÉ over 9 years ago
- Target version changed from 3.1.1 to 3.1.2
Updated by Vincent MEMBRÉ about 9 years ago
- Target version changed from 3.1.2 to 3.1.3
Updated by Vincent MEMBRÉ about 9 years ago
- Target version changed from 3.1.3 to 3.1.4
Updated by Vincent MEMBRÉ about 9 years ago
- Target version changed from 3.1.4 to 3.1.5
Updated by Jonathan CLARKE almost 9 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:
- Displaying the node. Folk can't be expected to recognize hundreds of different machines all called "localhost"!
- 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.
Updated by Benoît PECCATTE almost 9 years ago
- Assignee deleted (
Benoît PECCATTE) - Target version changed from 3.1.5 to 2.11.17
Updated by Benoît PECCATTE almost 9 years ago
- Status changed from New to In progress
- Assignee set to Benoît PECCATTE
Updated by Benoît PECCATTE almost 9 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
Updated by Benoît PECCATTE almost 9 years ago
- Status changed from Pending technical review to Pending release
- % Done changed from 0 to 100
Applied in changeset rudder-packages|856b699ef702d35aa57ce03acfedcc12e920ecf5.
Updated by Jonathan CLARKE almost 9 years ago
Applied in changeset rudder-packages|8ad0e2b84637ab7a5fe34066d81379163c59b7a1.
Updated by Vincent MEMBRÉ almost 9 years ago
- Status changed from Pending release to Released
Updated by François ARMAND over 8 years ago
- Related to User story #8022: Allow users to specify node hostname (FQDN) added
Updated by Vincent MEMBRÉ over 8 years ago
- Related to Bug #7568: Inventory <FQDN> content differs from hostname --fqdn and may lead to unauthorised nodes (impl for system techniques) added