[rudder-dev] Having correct FQDN in (first) inventory
Nicolas Charles
nicolas.charles at normation.com
Wed Apr 13 09:49:28 CEST 2016
Hello Francois,
Thank you for the nice sum-up. My answers in the text
Le 07/04/2016 15:33, Francois Armand a écrit :
> On 07/04/2016 15:08, Vincent Membré wrote:
>> 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 ?
>
> The idea is to patch fusion inventory plugin for Rudder to use that
> logic.
There are already a way to extend inventories:
http://fusioninventory.org/documentation/agent/additional_content.html
I think it will be much easier and future proof to use the
FusionInventory way rather than reimplementing it ourselves
We could use this principle to create our own task that would read data
or run external script - but maybe that's what you were implying ?
>
>>
>> * In Which entry will they be stored ? RUDDER/HOSTAME? another one
>
> Yes, RUDDER/HOSTNAME
>
>>
>> * 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 ?
>
> It's an other ticket, #4670, linked in #8022. HOSTNAME (FQDN, really)
> is different from the general use case (at least adding information
> into inventory) because of the special importance of FQDN in CFengine
> server/agent identification protocol. So it is kind of ok to see #8022
> as a bug in the existing versions, and #4670 (or an extension of it)
> as a new feature going to next versions.
Yes, let start with HOSTNAME in released version
>
>>
>>
>> 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
>>
>
> No specific feeling on that... Any idea, other ?
I'm not sure it should be in /var - if these are scripts to run to get
data, or data user should put, I feel they would live in other folder.
Plus, if we want user to preseed the system with these scripts/data,
before installing agent, /var/rudder will not exist
>
>> * 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 ...
>
> Let's had that in #4670 :)
>
> Thanks,
>
>>
>>
>>>
>>> *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
>> ------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> rudder-dev mailing list
>> rudder-dev at lists.rudder-project.org
>> http://www.rudder-project.org/mailman/listinfo/rudder-dev
>
>
> --
> ------------------------------------------------------------------------
> *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
--
Nicolas CHARLES
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rudder-project.org/pipermail/rudder-dev/attachments/20160413/4d774098/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/20160413/4d774098/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 23693 bytes
Desc: not available
URL: <http://www.rudder-project.org/pipermail/rudder-dev/attachments/20160413/4d774098/attachment-0001.png>
-------------- 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/20160413/4d774098/attachment-0003.gif>
More information about the rudder-dev
mailing list