[rudder-dev] Having correct FQDN in (first) inventory

Francois Armand francois.armand at normation.com
Thu Mar 31 12:37:23 CEST 2016


Hello,

So, here goes for a summary of
http://www.rudder-project.org/redmine/issues/8022, "Node's
FQDN-Resolution is sometimes invalid" and related tickets.
The problem cover up several sub-cases, which need to be addressed
systematically to achieve some result.
They are:

  * 1/ the node FQDN is used for identifying a node, and then manage
    authentication and authorization to access its promises. If Rudder
    server, CFEngine promise server, and the node don't agree on it, the
    node can't get its promises. This is a hard problem because:
      o FQDN is fragile. It needs a perfectly up to date and shared DNS
        environment. But "it's always a DNS problem", what gives an idea.
      o FQDN tools are notoriously broken, and don't always agree about
        what is the FQDN of a host
      o even in a perfectly working and up-to-date DNS env, there may
        have voluntary decision not to have the same FQDN from the host
        and the server, as explained in #8022 ticket.
  * 2/ if the node FQDN is not correct in the first sent inventory, the
    node configuration is delayed by one day, because from the node
    point of view, the inventory was correctly sent and so the standard
    frequency for sending inventories is applied.


The long-term solution for 1/ is to use something else that FQDN to
identify the node - we have for example an UUID for that. The problem
here is that it is a hard limitation of the protocol used by cf-serverd.
So to use another identification scheme (and why not our own
authentication/authorization), we need to either patch cf-serverd or use
a different client-server protocol for promises transfer. Both solutions
are open, but are out of scope.

Meanwhile, we can address at best 1/ and 2/

*For 1/, *we need to prevent as much as we can to give bad FQDN and in
all case, give the user a possibility to hook what he knows should be
the correct value.
*- Prevent more bad FQDN:**
*=> update perl version: http://www.rudder-project.org/redmine/issues/8123
I didn't find anything else on that subject, compared to what we are
doing now.

*- Let the user hook the correct value: **
*=> http://www.rudder-project.org/redmine/issues/8022#note-20
Here, we still need to specify the path convention for command and file
to look for the correct FDQN.

*For 2/, *we need to prevent the sending of inventory that will be
rejected by the server for sure. *
*=> http://www.rudder-project.org/redmine/issues/8127

Hope it helps sum up the whole solution.

Cheers,

-- 
------------------------------------------------------------------------
*François ARMAND*
/Co-founder & CTO/
Normation <http://www.normation.com>
------------------------------------------------------------------------
*87 rue de Turbigo, 75003 Paris, France*
Telephone: 	+33 (0)1 83 62 99 23
Mobile: 	+33 (0)6 63 37 60 55
------------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rudder-project.org/pipermail/rudder-dev/attachments/20160331/ae98eea9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo-square.gif
Type: image/gif
Size: 1036 bytes
Desc: not available
URL: <http://www.rudder-project.org/pipermail/rudder-dev/attachments/20160331/ae98eea9/attachment.gif>


More information about the rudder-dev mailing list