Forum: CFEngine Help Subject: 3.1.4 => 3.3.4: has something changed regarding classes in bundles? Author: davidlee Link to topic: https://cfengine.com/forum/read.php?3,26274,26274#msg-26274
(RHEL 5.x; cfengine community 3.1.4, just started migrating to 3.3.4) In RHEL the files that control network interfaces are "/etc/sysconfig/network-scripts/ifcfg-eth*" and look like: ========== DEVICE=eth0 HWADDR=aa:bb:cc:dd:ee:ff ONBOOT=yes BOOTPROTO=static IPADDR=10.156.164.33 NETMASK=255.255.252.0 ========== The natural cfengine way to maintain these is with "set_variable_values". We have been doing this reasonably happily for 15 months or more with version 3.1.4 (modulo a niggle described in bug 679). Today I have just been trying the latest 3.3.4, and something has changed. It sometimes isn't inserting lines because (according to a "-v" run of cf-agent) it reckons, incorrectly, that a pattern-matching line is already present. --- For the reader not familiar with COPBL's "set_variable_values": If a pattern-matched line is absent, "set_variable_values" inserts it; if it already present, "set_variable_values" edits it. This is internally controlled by setting a class within the "set_variable_values" bundle, e.g. "ONBOOT_in_file". --- We have several such files. So "set_variable_values" is being called several times, once per interface-file. My suspicion is that, under 3.3.4 but not 3.1.4, the class-setting is leaking from one invocation to the next. So that if a call for one interface-file sets a class (e.g. "ONBOOT_in_file"), I suspect that the behaviour of the next call will be affected by this class's existence from earlier call. (So if an early-checked file includes an "ONBOOT" line, this sets the class; a later-checked file, lacking such a line, will fail to get the line inserted because the earlier class setting seems to leak through.) My understanding is that such a class should be local to the invocation, and should evaporate immediately afterwards. But I suspect that it may be persistent (global?). As I say, this is a well-established, well-used piece of our config; the change is that I'm running it under 3.3.4 rather than 3.1.4. Before I put too much effort into trying to debug this further, is anyone able to say whether this is a known issue? (Is my understanding of the intended class (non-)persistence correct?) _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
