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

cfengine was not evaluating a condition correctly

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open
    • Priority: Medium
    • Resolution: Unresolved
    • Affects Version/s: 3.10.1
    • Fix Version/s: None
    • Component/s: cf-agent
    • Labels:
      None
    • Platform:
      RHEL or CentOS
    • Found in version (details):
      CFEngine Core 3.10.1

      Description

      We install tripwire via cfengine. That includes generating the local keys, but only when they don't exist (which means usually only during the first run).

      After having distributed tripwire to all server (about 8000) it was running for about a month without problems. But when I changed the wrapper script (masterconfig.sh), cfengine was invoking it with the key generation option, even if the key was already present.

      The task file:

      bundle agent ec_tasks_software_tripwire {
        meta:
          "tags" slist => { "ec_task" };
      
        classes:
          (redhat_s_6|redhat_s_7|rhel_8_0)::
            # Set class MasterConfig for Linux RC 6/7/8
            "MasterConfig" expression => "any";
      
        vars:
          MasterConfig::
            "required_packages" slist => { "tripwire" };
            "masterconfig_wrapper" string => "/usr/local/sbin/masterconfig.sh";
            "tripwire_etc" string => "/etc/tripwire";
            "tripwire_var_lib" string => "/var/lib/tripwire";
      
        classes:
            "HasWrapper" expression => fileexists("$(masterconfig_wrapper)");
            "HasTripwireInstalled" expression => fileexists("/usr/sbin/tripwire");
            "HasConfigFile" expression => fileexists("$(tripwire_etc)/tw.cfg");
            "HasPolicyFile" expression => fileexists("$(tripwire_etc)/tw.pol");
            "HasLocalKey" expression => fileexists("$(tripwire_etc)/local.key");
      
        packages:
          MasterConfig.!(HasTripwireInstalled)::
            "$(required_packages)"
              classes => ec_if_repaired_scope("InstalledTripwire", "namespace"),
              package_policy => "add",
              package_method => yum;
      
        files:
          MasterConfig::
            # Remove anacron job created by the package installation
            "/etc/cron.daily/tripwire-check"
              delete => tidy;
      
            # Make sure the config directory exists
            "$(tripwire_etc)/."
              create => "true",
              perms => mog("700", "root", "root");
      
            # Make sure the log directory exists
            "$(tripwire_var_lib)/."
              create => "true",
              perms => mog("700", "root", "root");
      
            # Install wrapper script for MasterConfig
            "$(masterconfig_wrapper)"
              classes => ec_if_repaired_scope("HasWrapper", "namespace"),
              copy_from => ec_remote_cp("$(def.master_cfdata)/software/tripwire/masterconfig.sh", "digest"),
              perms => mog("500", "root", "root");
      
            # Copy site key
            "/etc/tripwire/site.key"
              classes => ec_if_repaired_scope("InstalledSiteKey", "namespace"),
              copy_from => ec_remote_cp("$(def.master_cfdata)/software/tripwire/site.key", "digest"),
              perms => mog("400", "root", "root");
      
            # Copy tripwire config file
            "/etc/tripwire/twcfg.txt"
              classes => ec_if_repaired_scope("UpdateTripwireConfig", "namespace"),
              copy_from => ec_remote_cp("$(def.master_cfdata)/software/tripwire/twcfg.txt", "digest"),
              perms => mog("400", "root", "root");
      
            # Copy tripwire policy file
            "/etc/tripwire/twpol.txt"
              classes => ec_if_repaired_scope("UpdateTripwirePolicy", "namespace"),
              copy_from => ec_remote_cp("$(def.master_cfdata)/software/tripwire/twpol.txt", "digest"),
              perms => mog("400", "root", "root");
      
        commands:
          # Generate local key if it is not present
          MasterConfig.HasWrapper.HasTripwireInstalled.!HasLocalKey::
            "$(masterconfig_wrapper) gen_keys"
              contain => ec_setuidgid_dir("root", "root", "/");
      
          # Regenerate config file if it is not present or source has changed
          MasterConfig.HasWrapper.HasTripwireInstalled.(!HasConfigFile|UpdateTripwireConfig)::
            "$(masterconfig_wrapper) upd_cfg"
              contain => ec_setuidgid_dir("root", "root", "/");
      
          # Regenerate policy file if it is not present or source has changed
          MasterConfig.HasWrapper.HasTripwireInstalled.(!HasPolicyFile|UpdateTripwirePolicy)::
            "$(masterconfig_wrapper) upd_pol"
              contain => ec_setuidgid_dir("root", "root", "/");
      }
      

      So the expression MasterConfig.HasWrapper.HasTripwireInstalled.!HasLocalKey should not be true anymore on server that have already the tripwire keys generated.

      When I changed the script masterconfig.sh it should have been distributed, but not be launched (especially not with the option gen_keys).
      But that's what happened on all ~8000 server.

      I still have one server running the wrong task part. Here you can see, the keys exist since 2nd of August:

      root@rhel8-test-4:->ls -l /etc/tripwire/
      total 32
      -rw------- 1 root root   931 Aug  2 08:28 local.key
      -r-------- 1 root root   931 Aug  2 08:28 site.key
      -rw------- 1 root root   335 Aug  2 08:28 tw.cfg
      -r-------- 1 root root   561 Aug  2 08:28 twcfg.txt
      -rw------- 1 root root  2903 Aug  2 08:28 tw.pol
      -r-------- 1 root root 10287 Aug  2 08:28 twpol.txt
      

      cfengine nevertheless started the wrapper with the option gen_keys:

      root@rhel8-test-4:->pstree -apA 32517
      cf-agent,32517 -Dcf_execd_initiated
        `-masterconfig.sh,32673 /usr/local/sbin/masterconfig.sh gen_keys
            `-twadmin,32674                                                                            
      

      And that happened on the 4th of September:

      root@rhel8-test-4:->ps -fp 32517
      UID        PID  PPID  C STIME TTY          TIME CMD
      root     32517     1  0 Sep04 ?        00:00:05 /var/cfengine/bin/cf-agent -Dcf_execd_initiated
      

       The task file has not been changed since 2nd of August.
      And it was running fine until 4th of September. Then the wrapper script was changed, which should have triggered a copy of the new version (which was done), but it should have not been launched.

       

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                andy Andreas K
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Summary Panel