Forum: CFEngine Help Subject: Re: cf_promises_validated : bug 1258 Author: nickanderson Link to topic: https://cfengine.com/forum/read.php?3,27307,27593#msg-27593
> (1) Within any machine, is the copy in "inputs" > (i.e. "inputs/cf_promises_validated") used at all? > I suspect not. its my understanding that any node that does not have the am_policy_hub class defined validates /inputs/cf_promises_validated against the policyhub masterfiles/cf_promises_validated, it copies the file if its changed, and thats what triggers a full policy update > (2) On the central hub, is the copy in > "masterfiles" (i.e. > "masterfiles/cf_promises_validated") magically > maintained within cfengine itself (some black > magic deep within the source code, rather than a > user-visible ".cf" file)? Minor supplementary > question: how might this extend to slave hubs? yes I believe generation of cf_promises_validated is black magic Without actually looking myself, I suspect it stores file change information in the tokyo cabinate db and when it sees files have changed and validated successfully it writes out a new masterfiles/cf_promises_validated. Important to note here, I think it does this on any node, not just the hub. But since the hub is the only one remote clients look at masterfiles on its the only one you really notice. But go look on your clients, you should find a masterfiles/cf_promises_validated file there as well. And to my knowledge thats regenerated when new or changed policy found in inputs has been validated. > (3) On any non-hub (simple client) machine, is the > copy that ends up in "masterfiles" (i.e. > "masterfiles/cf_promises_validated") ultimately > copied in from a hub? I believe that masterfiles/cf_promises_validated is never placed from a copy_from, but is always generated by a policy run/validation It might even be cf-promises that updates that file. So masterfiles/cf_promises_validated is self generated, inputs/cf_promises_validated is copied from masterfiles on the hub. > This "am_policy_hub" seems to be some sort of > pre-defined class, used by "failsafe.cf". > Envisage a simple cluster of two machines, one > where policy is maintained, the other a pure > client. I presume the former should be routinely > running with "am_policy_hub" set and the latter > with it unset. But how is this set/unset nature > actually defined? I think that am_policy_hub is _supposed_ to be defined when the address listed in workdir/policy_server.dat is found on the executing agent. So if the ip in that file matches one of the ips bound to my interfaces then I am_policy_hub. > I suspect that my policy hub is, for some reason, > is running with "am_policy_hub" unset instead of > set. (I have just done a quick check by putting > a temporary "reports:" section into one of our > ".cf" files to tell me; both a client and a > (supposed-to-be) hub reports they are not hubs.) > > What is the cleanest way to fix this (presumably > so that "am_policy_hub" is appropriately > set/unset on hub/client)? I would check the policy_server.dat file and maybe just re-bootstrap it again to itself. But there have been reported bugs with am_policy_hub not always being defined as Neil mentioned. > (1) The contents (a single line datestamp) lack a > (2) It lacks a timezone. Won't this be File a bug, both sound like reasonable additions to me. I don't think the timezone is necessary. It used to just be a check based on mtime, but that was problematic when machines had wild clock skews (common when standing up new infrastructure) so they chose datestamp, not because the datestamp represented a time, but it was unique enough to account for difference. All clients care about is that its different. If you jumped back an hour and clients checked in it would still be different, they aren't doing a time comparison. _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
