Marco, try not to think modules and programming but reusable patterns. Ask yourself how you can reduce the total amount if information in the policy. If it can't be reduced then the complexity is real - and there is nothing you can do, except limit the amount of info that is useless to the individual host by dividing up into mutually exclusive files.
Programming is not an answer at least until you can see a pattern/algorithm - once you have that it is best to write it in a convergent language. -- Sent from my Android phone. Marco Marongiu <brontoli...@gmail.com> wrote: Hi all My ntp.cf has grown to nearly 800 lines now. Location-dependent setting are the biggest part of it, while a smaller part (files, processes, reports, and commands promises) is common for all locations. I'd like to reduce its size to something more manageable. I was considering to write a module that, depending on hostname and location, would return a server list, a peer list, and a key list. Another approach could be have the common parts into ntp.cf, and location-specific settings pulled in dynamically. E.g., I'd have them in separate policy files[2]. But I already tried that, and all my attempts to split this policy have been frustrated by various problems (see thread [1] in the forum for a summary). Is the module approach OK? Or maybe there are other obvious approaches I am not able to see at the moment? For those who are wondering why the policy is so huge, you'll find a summary below[3]. Ciao -- bronto [1] https://cfengine.com/forum/read.php?3,23886 [2] ntp.cf is itself pulled into play dynamically (using Neil Watson's technique), and the "ntp" bundle is added to the bundlesequence. [3] For each location, I have: * a list of upstreams for each of the ntp servers in said location; since we usually have four servers per location, this totals to four lists; * a list of peers for each of the ntp servers; again, this totals to four lists; * a list containing the key used by a server to authenticate the packets it sends out; this means we have again four of such lists; * a list of servers to be used by all unicast clients in said location; * a list of authentication keys to be used by all multicast clients in said location; This means that, for each location, I have to define 14 lists. But that's not all. In fact, there is one more list, a big one, which defines the class is_server, which tells cfengine if the machine being configured is an NTP server or not. Think of about four servers per location; think of some ten locations, and now you got the idea of what kind of monster this policy file is. _____________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
_______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
