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

Mon May 2 22:13:34 CEST 2016

Hi


*Answers Inline.*
Regards,
Matya

Jonathan Clarke <jonathan.clarke at normation.com> ezt írta (időpont: 2016.
máj. 2., H, 18:29):

> 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:
>       - 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.
>       - FQDN tools are notoriously broken, and don't always agree about
>       what is the FQDN of a host
>       - 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?
>
>
*This is the most welcome!*

*The only thing one should not forget about is that apache is still having
its allowed IP Subnets, which are also not making one's life too easy if
you have a ton of subnets your clients connect from.*

*Please also do not forget
about https://www.rudder-project.org/redmine/issues/7893
<https://www.rudder-project.org/redmine/issues/7893>, which is about
extending the Rudder API with the possibility to edit the allowed subnets
for the policy servers, which one currently has to do either in the WebGUI
or over some direct-brain-surgery out-of-band LDAP editing...*


> 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.
>
>
*#4670 is really something very useful, as this would allow to merge other
inventory-collecting systems into the one rudder collects with
fusioninventory, which is currently not providing any interface to get any
user-defined data, which could be collected on the server (like Firmware
version of different cards, SAP SID etc.)*


> * 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):
>       - /var/rudder/inventories/hostname-command: Command to execute the
>       get the correct hostname
>       - /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)
>
>
>
*Well, you already have stuff in /opt/rudder/etc, so adding more stuff
there would actually make more sense then opening a third location (well,
there is actually /etc/sysconfig/rudder-apache, which is already a config
below /etc, so you have already stuff laying in there...*


> 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
> _______________________________________________
> rudder-dev mailing list
> rudder-dev at lists.rudder-project.org
> http://www.rudder-project.org/mailman/listinfo/rudder-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rudder-project.org/pipermail/rudder-dev/attachments/20160502/fba67c9d/attachment-0001.html>