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

[Jonathan Clarke]

Hi,

On 04/13/2016 11:48 AM, Francois wrote:
> On 13/04/2016 09:49, Nicolas Charles wrote:
>> Hello Francois,
>>
>> Thank you for the nice sum-up. My answers in the text

+1

>> 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.

Actually, it is already possible to do authorizations in cf-serverd 
based on the key hash of connecting agents: 
https://docs.cfengine.com/docs/3.7/reference-promise-types-access.html#admit_keys. 
This has been possible since CFEngine 3.6 (so works on Rudder 2.11+ agents).

We could pretty easily implement this, since we already have an 
inventory with nodes CFEngine keys in. It could be opt-in as a start, 
while we ensure it's reliable (as in "more reliable that hostnames"). WDYT?

>>>>> 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 ?
>
> No, I meant that we should evolve the logic to fill 
> <RUDDER><HOSTNAME>, contribute the evolution to rudder plugin, and 
> patch our own until then.
> I'm not about using the what you linked to for that, it's really not 
> an extension, but the actual "business" logic we want to implement for 
> Rudder <HOSTNAME>.
>
> On the other hand, what you propose seems really nice for 4670, I 
> updated the ticket accordingly.
>
>>>> * 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.

It is pretty unusual to configure anything in /var. The right place for 
configs is /etc. (yes, policy_server.dat is a nasty exception to this 
rule). How about /opt/rudder/etc/hooks/inventory.d/ ? This would be a 
good start to having extensible inventory.

(and yes, it would be desirable to have configs in /etc, without the 
/opt/rudder prefix, but we're talking about a bug fix in existing 
versions here, so that it clearly out of scope)

>> Plus, if we want user to preseed the system with these scripts/data, 
>> before installing agent, /var/rudder will not exist

This is irrelevant, I think. If you need to install a file in a 
directory, it's pretty easy to create - in fact, just good practice.

>>>>> *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

FYI, Benoît is working on this this week. We will implement simple 
checks on the most important fields using a Perl script (since the 
inventory is already run in Perl, we know it's available).

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rudder-project.org/pipermail/rudder-dev/attachments/20160502/00229807/attachment.html>