Project

General

Profile

Bug #8022

Node's FQDN-Resolution is sometimes invalid

Added by Janos Mattyasovszky over 2 years ago. Updated about 1 month ago.

Status:
New
Priority:
3
Assignee:
-
Category:
Agent
Target version:
Target version (plugin):
Severity:
Critical - prevents main use of Rudder | no workaround | data loss | security
User visibility:
Operational - other Techniques | Technique editor | Rudder settings
Effort required:
Large
Pull Request:
Priority:
38

Description

Determining how the node is called from "outside" is not always that easy, as it depends on many things:
  • Do we use the same DNS Server as the policy server?
  • Do we use the same IP to reach the policy server as the default gateway's IP's FQDN? (issue present on multi-homed servers)
  • Does the external DNS also know me by the name I think I have? (SUSE's openstack assigns some bogus hostnames like external.server.fqdn)

I would suggest to enable a "hook"-binary, that if it exists, it is executed to resolve the FQDN of the node being run on, since the sysadmin might have a better knowledge on how the nodes are named. Or it should at least be customizable via a local variable, but the binary-approach would actually allow you to use a custom logic to reilable resolve how the node is called, even if it is renamed.


Related issues

Related to Rudder - User story #4670: Allows inventories to be augmented by the user with custom propertiesReleased
Related to Rudder - Bug #7001: If domain name is not set in resolv.conf, the inventory generated is invalidReleased2015-07-21
Related to Rudder - Bug #7031: Inventory <FQDN> content differs from hostname --fqdn and may lead to unauthorised nodesReleased2015-12-08
Related to Rudder - User story #7571: Change hostname source to prefer FQDN over RUDDER_HOSTNAMERejected2015-12-08
Related to Rudder - Bug #8123: Update perl version to get correct fqdnRejected2016-03-30
Related to Rudder - User story #8127: On agent, check inventory before sending it to Rudder serverReleased2016-10-17
Related to Rudder - Bug #8283: Backport patch for better FQDN detection in perlRejected2016-05-13
Related to Rudder - User story #8300: Download inventories hooks as part of the initial promise bootstrapNew
Related to Rudder - User story #3112: Allow to get informations from the node inventory to use them in DirectivesNew

History

#1 Updated by Janos Mattyasovszky over 2 years ago

  • Description updated (diff)

#2 Updated by Janos Mattyasovszky over 2 years ago

Slightly connected to #7031

#3 Updated by François ARMAND over 2 years ago

This is actually the best idea we had on the subject, thanks Janos !

And it could be rather easy, because it "just" need a hook in FusionInventory/Agent/Task/Inventory/Generic.pm to call script (path defined by convention) if present, and use its result if success. It would also helps to support special hardware: call the script that only handle the cases it knows how to handle.

There is a question remaining about the distribution of that script. Of course, it could be defined by Rudder once the node is accepted, but the use case is mostly to make a valid inventory, so to make things correct on the first inventory.

#4 Updated by Janos Mattyasovszky over 2 years ago

It's a chicken-egg problem, this will be something that the sysadmin has to install during the rudder agents install. This issue way is have also suggested a separate variable (maybe content of a rudder specific new config file, which will then be overruled by a hook binary if it exists).

So as of the suggestion I had was:
- if a hook binary exists, execute it, if it succeeded, take the output as the fqdn for the inventory.
- if a rudder specific configuration file exists, take the first line as the fqdn
- last: fall back to the method used up until now.

This would provide a nice way to influence the behavior by either setting it hard to a specific value (like for initial rollout/installation), then later remove the file, and place an executable there by a rudder rule.

#5 Updated by François ARMAND over 2 years ago

  • Related to User story #4670: Allows inventories to be augmented by the user with custom properties added

#6 Updated by François ARMAND over 2 years ago

We were reaching the same conclusion. In fact, this is somehow linked with the bigger picture of letting the user add / change arbitrary information on inventory if he wants so, see #4670. But the hostname is perhaps a bit peculiar, since it is also used (for now) for node identification and authentication for promise distribution.

So, your 3 steps process seems good.
One question, thought. Is it more or less convenient, or just an an other (fourth) option, to look for an environment variable (for. ex RUDDER_FQDN)?

Thanks

#7 Updated by Janos Mattyasovszky over 2 years ago

Hi.

Yes, RUDDER_FQDN is also a good point, it would be very good for a dockerized use :-D

thx
Janos

#8 Updated by Florian Heigl over 2 years ago

imo most of these cases are going back to
http://forge.fusioninventory.org/issues/3000

they try to have it fixed in libnet

  • libnet has a lot of open bugs to that end and is not fully maintained
  • libnet is doing the right thing in it's own sense - the dns lookup doesn't work and that's what it's return is based on
  • fusion does use that mangled non-return and PROCESSES it, ending up with the empty hostname
  • fusion should not(!) use external dns to strip-check the OS hostname
  • if can do that in addition but the primary source for a system's hostname is the system's hostname!
so what would work is building it upwards:
  • round one: look at hostname
  • round two: then look at hostname --fqdn
  • round two: then look at the remote-looked up fqdn minus domain (the more fragile bit)

accept the longest result that has any overlap with one from round two.
If there is no overlap, fall back to only using the hostname.

That would also be the right place for the trigger, to subvert THIS behaviour.
But there has to be a defined default behavior to come up with a filled entry for <HOSTNAME>

#9 Updated by François ARMAND over 2 years ago

Some more information from discussion on #irc channel:

- in all cases, we must have a post-check validation on the agent before sending the inventory to at least ensure that a valid hosname/fqdn entry is filled. Without that check, the inventory will be correctly sent, so the node will NOT issue a new inventory before 24h, BUT we are sur that the inventory WON'T be accepted by the server. On the other hand, if the node see an error with regards to the sending of the inventory, it will retry in the next run, and on the next, until the post-check is valid. That allows to wait for a DNS config to propagate, for example.

- there is nonetheless other bug in fusion, which could be better addressed than they are now (see previous comment).

#10 Updated by Florian Heigl over 2 years ago

+1 for giving a strongly worded error message if inventory is not going to be enough for the server to accept the node.

#11 Updated by Nicolas CHARLES over 2 years ago

More also on this subject: We use a super old version of Perl (5.12.4) which contains also bugs in name resolution
Upgrading to a recent version of Perl would solve a vast majority of headaches regarding hostname/dns

#12 Updated by Nicolas CHARLES over 2 years ago

oh, and also upgrade fusioninventory as well ...

#13 Updated by François ARMAND about 2 years ago

#14 Updated by François ARMAND about 2 years ago

#15 Updated by François ARMAND about 2 years ago

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

#16 Updated by François ARMAND about 2 years ago

  • Related to Bug #7031: Inventory <FQDN> content differs from hostname --fqdn and may lead to unauthorised nodes added

#17 Updated by François ARMAND about 2 years ago

  • Related to User story #7571: Change hostname source to prefer FQDN over RUDDER_HOSTNAME added

#18 Updated by François ARMAND about 2 years ago

  • Related to Bug #8123: Update perl version to get correct fqdn added

#19 Updated by François ARMAND about 2 years ago

  • Related to User story #8127: On agent, check inventory before sending it to Rudder server added

#20 Updated by François ARMAND about 2 years ago

So, to recap:

We want to let the user specify a value for RUDDER/HOSTNAME (which is actually a FQDN...). The value to put is looked in order, stoping at the first success:

- in RUDDER_FQDN environment variable if exists, and is not empty
- if the command TODO_SPECIFY_PATH_CONVENTION_FOR_FQDN_COMMAND exists, is executable, return correctly (no error code), and return a non-empty string
- if the file TODO_SPECIFY_PATH_CONVENTION_FOR_FQDN_CONFIG_FILE exists, is readable, is non empty, take the first valid line (question: do we want to allow command ? Key/value ? or just a file with only the FQDN on first line ?)
- else, fall back to current method.

#21 Updated by François ARMAND about 2 years ago

  • Tags set to Next minor release

This must go in next minor.

#22 Updated by Janos Mattyasovszky about 2 years ago

Hi

Regarding the questions:

I think the config file should be somewhere in /etc, like /etc/rudder.conf, and it would be make sense to make it extendable, so using key=value where key could be the same as the environment variable, like:
RUDDER_FQDN="some.other.fqdn"

#23 Updated by Benoît PECCATTE about 2 years ago

  • Target version set to 4.0.0~rc2

#24 Updated by François ARMAND about 2 years ago

  • Related to Bug #8283: Backport patch for better FQDN detection in perl added

#25 Updated by François ARMAND about 2 years ago

  • Target version changed from 4.0.0~rc2 to 3.1.10

We decided to do that bug correction in 3.1.

#26 Updated by François ARMAND about 2 years ago

  • Related to User story #8300: Download inventories hooks as part of the initial promise bootstrap added

#27 Updated by Jonathan CLARKE about 2 years ago

  • Tags deleted (Next minor release)

#28 Updated by Vincent MEMBRÉ about 2 years ago

  • Target version changed from 3.1.10 to 3.1.11

#29 Updated by Vincent MEMBRÉ about 2 years ago

  • Target version changed from 3.1.11 to 3.1.12

#30 Updated by Vincent MEMBRÉ almost 2 years ago

  • Target version changed from 3.1.12 to 3.1.13

#31 Updated by Vincent MEMBRÉ almost 2 years ago

  • Target version changed from 3.1.13 to 3.1.14

#32 Updated by Vincent MEMBRÉ over 1 year ago

  • Target version changed from 3.1.14 to 3.1.15

#33 Updated by Vincent MEMBRÉ over 1 year ago

  • Target version changed from 3.1.15 to 3.1.16

#34 Updated by Vincent MEMBRÉ over 1 year ago

  • Target version changed from 3.1.16 to 3.1.17

#35 Updated by François ARMAND over 1 year ago

  • Related to User story #3112: Allow to get informations from the node inventory to use them in Directives added

#36 Updated by Vincent MEMBRÉ over 1 year ago

  • Target version changed from 3.1.17 to 3.1.18

#37 Updated by Vincent MEMBRÉ over 1 year ago

  • Target version changed from 3.1.18 to 3.1.19

#38 Updated by Jonathan CLARKE over 1 year ago

  • Severity set to Major - prevents use of part of Rudder | no simple workaround
  • User visibility set to Getting started - demo | first install | level 1 Techniques

#39 Updated by François ARMAND about 1 year ago

  • Severity changed from Major - prevents use of part of Rudder | no simple workaround to Critical - prevents main use of Rudder | no workaround | data loss | security
  • User visibility changed from Getting started - demo | first install | level 1 Techniques to Operational - other Techniques | Technique editor | Rudder settings
  • Effort required set to Large
  • Priority set to 38

In 4.1, we are using agent key to identify the nodes, so the problem does not occur anymore.

We still don't have a good solution for 3.1.

#40 Updated by Alexis MOUSSET about 1 year ago

Hosts fqdn are still need for remote run to work properly.

#41 Updated by Vincent MEMBRÉ about 1 year ago

  • Target version changed from 3.1.19 to 3.1.20

#42 Updated by Vincent MEMBRÉ about 1 year ago

  • Target version changed from 3.1.20 to 3.1.21

#43 Updated by Vincent MEMBRÉ about 1 year ago

  • Target version changed from 3.1.21 to 3.1.22

#44 Updated by Vincent MEMBRÉ 11 months ago

  • Target version changed from 3.1.22 to 3.1.23

#45 Updated by Vincent MEMBRÉ 10 months ago

  • Target version changed from 3.1.23 to 3.1.24

#46 Updated by Vincent MEMBRÉ 8 months ago

  • Target version changed from 3.1.24 to 3.1.25

#47 Updated by Vincent MEMBRÉ 7 months ago

  • Target version changed from 3.1.25 to 387

#48 Updated by Vincent MEMBRÉ 6 months ago

  • Target version changed from 387 to 4.1.10

#49 Updated by Vincent MEMBRÉ 4 months ago

  • Target version changed from 4.1.10 to 4.1.11

#50 Updated by Vincent MEMBRÉ 2 months ago

  • Target version changed from 4.1.11 to 4.1.12

#51 Updated by Vincent MEMBRÉ about 1 month ago

  • Target version changed from 4.1.12 to 4.1.13

Also available in: Atom PDF