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

[Vincent Membré]

Le 31/03/2016 12:37, Francois Armand a écrit :
> 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.
I have some remarks/questions here:

* If I understand correctly the process will be: Inventory is ran on the 
Node, then inventory is modified to add data from commands / file ? or 
will this be used when runnig fusionInventory ?

* In Which entry will they be stored ? RUDDER/HOSTAME? another one?

* Do we want to define Hostname only ? Would it not be better if the 
solution was much more adaptable and can modify any entry from the 
inventory ?


About the path, I suggest we should put them under /var/rudder/inventories :

  * If we modify only hostname (RUDDER/HOSTNAME):
      o /var/rudder/inventories/hostname-command: Command to execute the
        get the correct hostname
      o /var/rudder/inventories/hostname-file: File containing the path
        the file containing the correct hostname

  * If we want something more general:
      o /var/rudder/inventories/commands or
        /var/rudder/inventories/hooks.d : to put all commands/hooks
      o /var/rudder/inventories/mapping: a file mapping a Key in
        inventory to an action to do, ie:
          + RUDDER/HOSTNAME => get_fqdn.sh # Will run get_fqdn.sh (from
            hooks directory!) and put output into the correct tag
          + OPERATINGSYSTEM/OSVERSION => /some/path/to/file # Will read
            that file to fill the tag

I hope I'm not going too far from the original idea ...


>
> *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
> ------------------------------------------------------------------------
>
>
>
> _______________________________________________
> rudder-dev mailing list
> rudder-dev at lists.rudder-project.org
> http://www.rudder-project.org/mailman/listinfo/rudder-dev


-- 
------------------------------------------------------------------------
*Logo Normation Vincent Membré*
/Developer / Release manager/
Normation <http://www.normation.com>
------------------------------------------------------------------------
*87, Rue de Turbigo, 75003 Paris, France*
Phone: 	+33 (0)1 84 16 06 00
Mobile: 	+33 (0)6 10 14 76 78
------------------------------------------------------------------------

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