Uploaded image for project: 'CFEngine Community'
  1. CFEngine Community
  2. CFE-2243

Bootstrapping an old agent when trigger_upgrade class is defined should not result in a failed bootstrap

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Done
    • Priority: Medium
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.7.3
    • Component/s: None
    • Labels:
      None

      Description

      I have observed that when bootstrapping a 3.7.1 agent to a 3.7.2 hub (I don't think the versions matter much) while trigger_upgrade is defined results in a failed bootstrap and cf-execd is left in a non running state. At this point simply running service cfengine3 start does bring up the services correctly.

      This shows that trigger_upgrade is set

      <pre>
      root@hub:/var/cfengine/masterfiles# grep -A3 trigger_upgrade controls/3.7/update_def.cf
      "trigger_upgrade" or =>

      { "any", }

      ;
      </pre>

      This shows the failed bootstrap

      <pre>
      root@host001:/vagrant/packages/agent_deb_x86_64# cf-agent --bootstrap 192.168.33.2
      notice: Bootstrap mode: implicitly trusting server, use --trust-server=no if server trust is already established
      notice: Trusting new key: SHA=f5428c4237ecfa3613adfb80e590348e4a32c9decec37635af6a8db4c25ddc62
      R: This autonomous node assumes the role of voluntary client
      R: Updated local policy from policy server
      R: Started the scheduler
      error: Bootstrapping failed, cf-execd is not running
      </pre>

      Bootstrap currently executes update.cf and that fails for some reason. I suspect because perhaps sys.policy_hub is yet to be defined. I can't really tell.

      I was however able to work around the situation by defining a class based on the presence or non presence of a cf-agent process using the --bootstrap or -B option. Then use the non presence of that to guard the upgrade policy from being activated.

      At a minimum I think it would be better to at lease define bootstrap_mode on that execution of update.cf, and use that class to guard the upgrade. I think it would be more reliable than scanning the process table, but open to suggestions.

      And even better, I think it makes more sense to just not execute update.cf from failsafe/bootstrap as suggested in #7660.

        Attachments

          Activity

            People

            • Assignee:
              a10042 Nick Anderson
              Reporter:
              a10042 Nick Anderson
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Summary Panel