User story #8022
closedAllow users to specify node hostname (FQDN)
Description
- 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.
Updated by François ARMAND over 8 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.
Updated by Janos Mattyasovszky over 8 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.
Updated by François ARMAND over 8 years ago
- Related to User story #4670: Allows inventories to be augmented by the user with custom properties added
Updated by François ARMAND over 8 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
Updated by Janos Mattyasovszky over 8 years ago
Hi.
Yes, RUDDER_FQDN is also a good point, it would be very good for a dockerized use :-D
thx
Janos
Updated by Florian Heigl over 8 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!
- 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>
Updated by François ARMAND over 8 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).
Updated by Florian Heigl over 8 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.
Updated by Nicolas CHARLES over 8 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
Updated by Nicolas CHARLES over 8 years ago
oh, and also upgrade fusioninventory as well ...
Updated by François ARMAND over 8 years ago
- Related to User story #3448: Improve perfs for manageFileAndFolder added
Updated by François ARMAND over 8 years ago
- Related to deleted (User story #3448: Improve perfs for manageFileAndFolder)
Updated by François ARMAND over 8 years ago
- Related to Bug #7001: If domain name is not set in resolv.conf, the inventory generated is invalid added
Updated by François ARMAND over 8 years ago
- Related to Bug #7031: Inventory <FQDN> content differs from hostname --fqdn and may lead to unauthorised nodes added
Updated by François ARMAND over 8 years ago
- Related to User story #7571: Change hostname source to prefer FQDN over RUDDER_HOSTNAME added
Updated by François ARMAND over 8 years ago
- Related to Bug #8123: Update perl version to get correct fqdn added
Updated by François ARMAND over 8 years ago
- Related to User story #8127: On agent, check inventory before sending it to Rudder server added
Updated by François ARMAND over 8 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.
Updated by François ARMAND over 8 years ago
- Translation missing: en.field_tag_list set to Next minor release
This must go in next minor.
Updated by Janos Mattyasovszky over 8 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"
Updated by François ARMAND over 8 years ago
- Related to Bug #8283: Backport patch for better FQDN detection in perl added
Updated by François ARMAND over 8 years ago
- Target version changed from 4.0.0~rc2 to 3.1.10
We decided to do that bug correction in 3.1.
Updated by François ARMAND over 8 years ago
- Related to User story #8300: Download inventories hooks as part of the initial promise bootstrap added
Updated by Jonathan CLARKE over 8 years ago
- Translation missing: en.field_tag_list deleted (
Next minor release)
Updated by Vincent MEMBRÉ over 8 years ago
- Target version changed from 3.1.10 to 3.1.11
Updated by Vincent MEMBRÉ over 8 years ago
- Target version changed from 3.1.11 to 3.1.12
Updated by Vincent MEMBRÉ over 8 years ago
- Target version changed from 3.1.12 to 3.1.13
Updated by Vincent MEMBRÉ over 8 years ago
- Target version changed from 3.1.13 to 3.1.14
Updated by Vincent MEMBRÉ about 8 years ago
- Target version changed from 3.1.14 to 3.1.15
Updated by Vincent MEMBRÉ about 8 years ago
- Target version changed from 3.1.15 to 3.1.16
Updated by Vincent MEMBRÉ about 8 years ago
- Target version changed from 3.1.16 to 3.1.17
Updated by François ARMAND about 8 years ago
- Related to User story #3112: Allow to get informations from the node inventory to use them in Directives and ncf techniques added
Updated by Vincent MEMBRÉ about 8 years ago
- Target version changed from 3.1.17 to 3.1.18
Updated by Vincent MEMBRÉ almost 8 years ago
- Target version changed from 3.1.18 to 3.1.19
Updated by Jonathan CLARKE over 7 years 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
Updated by François ARMAND over 7 years 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.
Updated by Alexis Mousset over 7 years ago
Hosts fqdn are still need for remote run to work properly.
Updated by Vincent MEMBRÉ over 7 years ago
- Target version changed from 3.1.19 to 3.1.20
Updated by Vincent MEMBRÉ over 7 years ago
- Target version changed from 3.1.20 to 3.1.21
Updated by Vincent MEMBRÉ over 7 years ago
- Target version changed from 3.1.21 to 3.1.22
Updated by Vincent MEMBRÉ over 7 years ago
- Target version changed from 3.1.22 to 3.1.23
Updated by Vincent MEMBRÉ over 7 years ago
- Target version changed from 3.1.23 to 3.1.24
Updated by Vincent MEMBRÉ about 7 years ago
- Target version changed from 3.1.24 to 3.1.25
Updated by Vincent MEMBRÉ almost 7 years ago
- Target version changed from 3.1.25 to 387
Updated by Vincent MEMBRÉ almost 7 years ago
- Target version changed from 387 to 4.1.10
Updated by Vincent MEMBRÉ almost 7 years ago
- Target version changed from 4.1.10 to 4.1.11
Updated by Vincent MEMBRÉ over 6 years ago
- Target version changed from 4.1.11 to 4.1.12
Updated by Vincent MEMBRÉ over 6 years ago
- Target version changed from 4.1.12 to 4.1.13
Updated by Vincent MEMBRÉ over 6 years ago
- Target version changed from 4.1.13 to 4.1.14
Updated by Benoît PECCATTE over 6 years ago
- Target version changed from 4.1.14 to 4.1.15
Updated by Vincent MEMBRÉ about 6 years ago
- Target version changed from 4.1.15 to 4.1.16
Updated by Vincent MEMBRÉ about 6 years ago
- Target version changed from 4.1.16 to 4.1.17
Updated by Vincent MEMBRÉ about 6 years ago
- Target version changed from 4.1.17 to 4.1.18
- Priority changed from 38 to 0
Updated by Vincent MEMBRÉ almost 6 years ago
- Target version changed from 4.1.18 to 4.1.19
Updated by Alexis Mousset almost 6 years ago
- Target version changed from 4.1.19 to 4.1.20
Updated by François ARMAND almost 6 years ago
- Target version changed from 4.1.20 to 4.1.21
Updated by Vincent MEMBRÉ over 5 years ago
- Target version changed from 4.1.21 to 4.1.22
Updated by Vincent MEMBRÉ over 5 years ago
- Target version changed from 4.1.22 to 4.1.23
Updated by Vincent MEMBRÉ over 5 years ago
- Target version changed from 4.1.23 to 4.1.24
Updated by Vincent MEMBRÉ over 5 years ago
- Target version changed from 4.1.24 to 588
Updated by Alexis Mousset over 5 years ago
- Target version changed from 588 to 5.0.13
Updated by Vincent MEMBRÉ over 5 years ago
- Target version changed from 5.0.13 to 5.0.14
Updated by Vincent MEMBRÉ about 5 years ago
- Target version changed from 5.0.14 to 5.0.15
Updated by Vincent MEMBRÉ about 5 years ago
- Target version changed from 5.0.15 to 5.0.16
Updated by Alexis Mousset almost 5 years ago
- Target version changed from 5.0.16 to 5.0.17
Updated by Vincent MEMBRÉ over 4 years ago
- Target version changed from 5.0.17 to 5.0.18
Updated by Vincent MEMBRÉ over 4 years ago
- Target version changed from 5.0.18 to 5.0.19
Updated by Vincent MEMBRÉ over 4 years ago
- Target version changed from 5.0.19 to 5.0.20
Updated by Vincent MEMBRÉ about 4 years ago
- Target version changed from 5.0.20 to 797
Updated by Benoît PECCATTE over 3 years ago
- Target version changed from 797 to 6.1.14
Updated by Vincent MEMBRÉ over 3 years ago
- Target version changed from 6.1.14 to 6.1.15
Updated by Vincent MEMBRÉ over 3 years ago
- Target version changed from 6.1.15 to 6.1.16
Updated by Vincent MEMBRÉ over 3 years ago
- Target version changed from 6.1.16 to 6.1.17
Updated by Vincent MEMBRÉ about 3 years ago
- Target version changed from 6.1.17 to 6.1.18
Updated by Vincent MEMBRÉ almost 3 years ago
- Target version changed from 6.1.18 to 6.1.19
Updated by François ARMAND almost 3 years ago
- Tracker changed from Bug to User story
- Subject changed from Node's FQDN-Resolution is sometimes invalid to Allow users to specify node hostname (FQDN)
- Severity deleted (
Critical - prevents main use of Rudder | no workaround | data loss | security) - Effort required changed from Large to Medium
- Priority deleted (
0)
So, to clean up a bit things, that bug was an important bug in the old days, because we used hostname for node identification and authorization. That proved to be a terrible mistake, and a long time ago, we switched to other mean of authentication (now, node ID + certificate with TOFU based trust model by default, with possiblity to pre-fill cert to override it).
So, we still want to allow an user to set it's own hostname, because he may knows better than the system, and hostname is still needed for push-based action (ie remote run).
But now, the system is MUCH simpler, since it's just having an overriding logic in inventory for hostame ("use FQDN unless user filled an inventory hook key").
=> swithching to user story (actually even just an enhancement likely).
Updated by Vincent MEMBRÉ over 2 years ago
- Target version changed from 6.1.19 to 6.1.20
Updated by Vincent MEMBRÉ over 2 years ago
- Target version changed from 6.1.20 to 6.1.21
Updated by Vincent MEMBRÉ over 2 years ago
- Target version changed from 6.1.21 to old 6.1 issues to relocate
Updated by François ARMAND about 2 years ago
- Target version changed from old 6.1 issues to relocate to 7.1.7
- Regression set to No
Updated by François ARMAND about 2 years ago
- Status changed from New to In progress
- Assignee set to François ARMAND
Updated by François ARMAND about 2 years ago
- Status changed from In progress to Pending technical review
- Assignee changed from François ARMAND to Alexis Mousset
- Pull Request set to https://github.com/Normation/rudder/pull/4472
Updated by François ARMAND about 2 years ago
- Related to Enhancement #21782: Allow to override FQDN used for remote run added
Updated by Anonymous about 2 years ago
- Status changed from Pending technical review to Pending release
Applied in changeset rudder|f8361138990b14aa03870fdfaa70ea98625cf469.
Updated by Vincent MEMBRÉ about 2 years ago
- Status changed from Pending release to Released
This bug has been fixed in Rudder 7.1.7 and 7.2.1 which were released today.
Updated by François ARMAND about 2 years ago
- Related to Bug #21356: Inventory hostname differ between Windows and Linux added
Updated by François ARMAND about 2 years ago
- Related to Enhancement #21952: Documentation for FQDN overriding added
Updated by Nicolas CHARLES almost 2 years ago
- Related to Bug #22326: some nodes are called "localhost" since #8022 added