Bug #1896

CFEngine package method seems to confuse class names

Added by Jonathan CLARKE almost 3 years ago. Updated 23 days ago.

Status:New Start date:2011-10-04
Priority:3 Due date:
Assignee:- % Done:

20%

Category:-
Target version:Rudder - 2.6.18
Pull Request:

Description

Trying to install 2 packages, defining a result class for each based on the package name:

rudder>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
rudder>    Offering these package-promise suggestions to the managers
rudder>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
rudder>  -> Deletion schedule...
rudder>  -> Addition schedule...
rudder> Execute scheduled package addition
rudder> Command prefix: /usr/bin/yum -y install
rudder> Executing /usr/bin/yum -y install git-core.*...
rudder> Q:yum -y install git-c ...:Loaded plugins: fastestmirror
rudder> Q:yum -y install git-c ...:Loading mirror speeds from cached hostfile
rudder> Q:yum -y install git-c ...: * base: mirror.ovh.net
rudder> Q:yum -y install git-c ...: * epel: mirror01.th.ifl.net
rudder> Q:yum -y install git-c ...: * extras: mirror.ovh.net
rudder> Q:yum -y install git-c ...: * updates: mirror.ovh.net
rudder> Q:yum -y install git-c ...:Setting up Install Process
rudder> Q:yum -y install git-c ...:No package git-core.* available.
rudder> Q:yum -y install git-c ...:Nothing to do
rudder> Q:yum -y install git-c ...:
rudder> -> Command related to promiser "git-core" returned code defined as promise kept (0)
rudder>  ?> defining promise result class rpm_package_install_kept_git_core
rudder> Package schedule execution ok for git-core.* (outcome cannot be promised by cf-agent)
rudder> Executing /usr/bin/yum -y install vim.*...
rudder> Q:yum -y install vim.* ...:Loaded plugins: fastestmirror
rudder> Q:yum -y install vim.* ...:Loading mirror speeds from cached hostfile
rudder> Q:yum -y install vim.* ...: * base: mirror.ovh.net
rudder> Q:yum -y install vim.* ...: * epel: mirror01.th.ifl.net
rudder> Q:yum -y install vim.* ...: * extras: mirror.ovh.net
rudder> Q:yum -y install vim.* ...: * updates: mirror.ovh.net
rudder> Q:yum -y install vim.* ...:Setting up Install Process
rudder> Q:yum -y install vim.* ...:No package vim.* available.
rudder> Q:yum -y install vim.* ...:Nothing to do
rudder> Q:yum -y install vim.* ...:
rudder> -> Command related to promiser "git-core" returned code defined as promise kept (0)
rudder>  ?> defining promise result class rpm_package_install_kept_git_core

Note that after trying to install package vim, CFEngine defines the class rpm_package_install_kept_*git_core* (which is wrong!)

patch Magnifier (651 Bytes) Jonathan CLARKE, 2013-08-04 15:26

History

#1 Updated by Jonathan CLARKE almost 3 years ago

I think a solution that might work for this is calling a separate bundle to install a package. I'm not sure, but it's worth a try.

#2 Updated by Nicolas CHARLES almost 3 years ago

Isn't it because of a bulk package install, preventing CFEngine to effectively separate each packages installation ?

#3 Updated by Jonathan CLARKE almost 3 years ago

  • Target version changed from 23 to 2.3.0 (final)

#4 Updated by Jonathan CLARKE almost 3 years ago

  • Assignee set to Matthieu CERDA

#5 Updated by Matthieu CERDA almost 3 years ago

  • Status changed from 2 to In progress

After a short diving session in the CFengine SVN, we found a commit that might match this bug : r3007

Patch :

--- src/verify_packages.c    (révision 3006)
+++ src/verify_packages.c    (révision 3007)
@@ -1688,7 +1688,7 @@
           }
        else
           {
-          cfPS(cf_error,CF_FAIL,"",pp,a,"!! Package \"%s\" cannot be verified -- no match\n",pp->promiser);
+          cfPS(cf_inform,CF_FAIL,"",pp,a,"!! Package \"%s\" cannot be verified -- no match\n",pp->promiser);
           }

        break;
@@ -1960,7 +1960,7 @@
     ReplaceStr(line,lineSafe,sizeof(lineSafe),"%","%%");
     CfOut(cf_inform,"","Q:%20.20s ...:%s",cmd,lineSafe);

-    if (line[0] != '\0' && verify)
+    if (verify && line[0] != '\0')
        {
        if (a.packages.package_noverify_regex)
           {
@@ -1976,21 +1976,25 @@

  packmanRetval = cf_pclose(pfp);

- if(verify)  // return code check for verify policy
+ if(verify && a.packages.package_noverify_returncode != CF_NOINT)
     {
-    if(a.packages.package_noverify_returncode != CF_NOINT)
+    if(a.packages.package_noverify_returncode == packmanRetval)
        {
-       if(a.packages.package_noverify_returncode == packmanRetval)
-      {
-          cfPS(cf_inform,CF_FAIL,"",pp,a,"!! Package verification error (returned %d)",packmanRetval);
-          retval = false;
-      }
-       else
-      {
-          CfOut(cf_verbose, "", " Package successfully verified from return code");
-      }
+       cfPS(cf_inform,CF_FAIL,"",pp,a,"!! Package verification error (returned %d)",packmanRetval);
+       retval = false;
        }
+    else
+       {
+       cfPS(cf_inform,CF_NOP,"",pp,a,"-> Package verification succeeded (returned %d)",packmanRetval);
+       }
     }
+ else if(verify && a.packages.package_noverify_regex)
+    {
+    if(retval)  // set status if we succeeded above
+       {
+       cfPS(cf_inform,CF_NOP,"",pp,a,"-> Package verification succeeded (no match with package_noverify_regex)");
+       }
+    }
  else if(setCmdClasses)  // generic return code check
     {
     retval = VerifyCommandRetcode(packmanRetval,true,a,pp);

I will confirm the bug on our version, and try to recompile it with this patch for testing purpose.

#6 Updated by Matthieu CERDA almost 3 years ago

  • Status changed from In progress to Discussion
  • % Done changed from 0 to 20

This is a bug. It has been reported to CFengine => https://cfengine.com/bugtracker/view.php?id=831 , now we have to wait for a solution.

#7 Updated by Matthieu CERDA almost 3 years ago

Note : The commit 3007 in CFengine's SVN was a failure.

#8 Updated by François ARMAND almost 3 years ago

  • Target version changed from 2.3.0 (final) to 2.3.1

#9 Updated by Jonathan CLARKE almost 3 years ago

  • Target version changed from 2.3.1 to 2.3.2

#10 Updated by Jonathan CLARKE almost 3 years ago

  • Target version changed from 2.3.2 to 2.3.3

#11 Updated by Jonathan CLARKE almost 3 years ago

  • Target version changed from 2.3.3 to 2.3.4

#12 Updated by Jonathan CLARKE over 2 years ago

  • Target version changed from 2.3.4 to 2.3.7

#13 Updated by Nicolas PERRON over 2 years ago

  • Target version changed from 2.3.7 to 2.3.8
  • Needs translating set to No

It seems that this bug has not been fixed yet.

#14 Updated by Jonathan CLARKE about 2 years ago

According to https://cfengine.com/bugtracker/view.php?id=829, this will be fixed in CFEngine 3.3.4.

#15 Updated by Jonathan CLARKE about 2 years ago

The patch is here: https://github.com/cfengine/core/commit/201f3abc9c94254b1d87233f1a8cd5483f20320e

We should test this and apply it for 2.3.8 and 2.4.0 if possible.

#16 Updated by Jonathan CLARKE about 2 years ago

  • Target version changed from 2.3.8 to 2.3.9

#17 Updated by Jonathan CLARKE almost 2 years ago

  • Assignee deleted (Matthieu CERDA)

#18 Updated by Nicolas PERRON almost 2 years ago

  • Category changed from Webapp - CFEngine integration to 11
  • Status changed from Discussion to In progress
  • 2 set to 0

This should not be in a Discussion state since a patch must be applied during packaging.

#19 Updated by Nicolas PERRON almost 2 years ago

  • Target version changed from 2.3.9 to 2.3.10

#20 Updated by Nicolas CHARLES over 1 year ago

  • Assignee set to Nicolas PERRON

Nicolas, you set this ticket in Progress without any assignee. A ticket in progress must have an assigne, so I assign it to you.

#21 Updated by Matthieu CERDA over 1 year ago

  • Assignee changed from Nicolas PERRON to Matthieu CERDA

I'll catch this, since NPE is unavailable at the moment.

#22 Updated by Matthieu CERDA over 1 year ago

  • Status changed from In progress to Discussion
  • Assignee changed from Matthieu CERDA to Jonathan CLARKE

I took a look at the CFEngine 3.2.0 and 3.2.4 code base (= Rudder 2.3 and 2.4), and the patch is totally inapplicable.

As discussed with NCH, the patch is originally made for the CFEngine 3.3.X code base, that has been drastically simplified and modified by Mikhail Gusarov, and the impacted function is completely different, see the example below:

static int ExecuteSchedule(struct CfPackageManager *schedule,enum package_actions action)

{ struct CfPackageItem *pi;
  struct CfPackageManager *pm;
  int size,estimated_size,retval = true,verify = false;
  char *command_string = NULL;
  struct Attributes a = {{0}};
  struct Promise *pp;
  int ok;       

for (pm = schedule; pm != NULL; pm = pm->next)
   {
   if (pm->action != action)
      {
      continue;
      }

   if (pm->pack_list == NULL)
      {
      continue;
      }

   estimated_size = 0;

   for (pi = pm->pack_list; pi != NULL; pi=pi->next)
      {   
      size = strlen(pi->name) + strlen("  ");

      switch (pm->policy)
         {
         case cfa_individual:             

             if (size > estimated_size)
                {
                estimated_size = size + CF_MAXVARSIZE;
                }             
             break;

         case cfa_bulk:

             estimated_size += size + CF_MAXVARSIZE;
             break;

         default:
             break;
         }
      }

   pp = pm->pack_list->pp;
   a = GetPackageAttributes(pp);

And the patch:

@@ -856,6 +856,9 @@ static int ExecuteSchedule(PackageManager *schedule, enum package_actions action

                 for (pi = pm->pack_list; pi != NULL; pi = pi->next)
                 {
+                    pp = pi->pp;
+                    a = GetPackageAttributes(pp);
+
                     char *sp, *offset = command_string + strlen(command_string);

                     if (a.packages.package_file_repositories && (action == cfa_addpack || action == cfa_update))

I can not reasonably apply this patch blindly, without beeing able to balance the consequences, I'm sorry.

Jon, what should we do here ?

#23 Updated by François ARMAND over 1 year ago

For now, we use the following the workaround (and we don't see any other way to proceed until switching to a newer version of Rudder, see #2519 )

#24 Updated by Matthieu CERDA over 1 year ago

  • Target version changed from 2.3.10 to 2.3.11

#25 Updated by Nicolas PERRON over 1 year ago

  • Project changed from Rudder to packages
  • Category deleted (11)

#26 Updated by Matthieu CERDA over 1 year ago

  • Target version changed from 2.3.11 to 2.3.12

#27 Updated by Matthieu CERDA over 1 year ago

  • Target version changed from 2.3.12 to 2.3.13

#28 Updated by Nicolas PERRON about 1 year ago

  • Target version changed from 2.3.13 to 84

#29 Updated by Nicolas PERRON about 1 year ago

  • Target version changed from 84 to 2.4.7

#30 Updated by Nicolas PERRON about 1 year ago

  • Target version changed from 2.4.7 to 2.4.8

#31 Updated by Jonathan CLARKE about 1 year ago

  • Assignee deleted (Jonathan CLARKE)
  • Priority changed from 2 to 3

I have just checked and I confirm that this issue is no longer present in CFEngine 3.4 (and therefore in Rudder 2.6+).

It does however still affect CFEngine 3.2 and therefore Rudder 2.4 (and 2.3 and 2.5 but they are no longer supported). Fixing this in CFEngine 3.2 is non trivial, and upstream has been clear they do not intend to provide patches or new versions on older releases.

As a result, I can't see us putting a high priority on this bug, for now.

#32 Updated by Jonathan CLARKE about 1 year ago

Actually, I take that back, it's not that hard. I attach a patch that should fix this. I haven't tested it, but it is issued from https://cfengine.com/bugtracker/view.php?id=829 and seems logical to me.

#33 Updated by Nicolas PERRON about 1 year ago

  • Target version changed from 2.4.8 to 2.4.9

#34 Updated by Nicolas PERRON about 1 year ago

  • Status changed from Discussion to New

#35 Updated by Nicolas PERRON 11 months ago

  • Target version changed from 2.4.9 to 2.4.10

#36 Updated by Nicolas PERRON 11 months ago

  • Target version changed from 2.4.10 to 2.4.11

#37 Updated by Nicolas PERRON 11 months ago

  • Target version changed from 2.4.11 to 2.4.12

#38 Updated by Nicolas PERRON 10 months ago

  • Target version changed from 2.4.12 to 2.4.13

#39 Updated by Vincent MEMBRÉ 7 months ago

  • Target version changed from 2.4.13 to 2.6.11

Since version 2.4 is not maintained anymore, retageting this issue to 2.6

#40 Updated by Vincent MEMBRÉ 6 months ago

  • Target version changed from 2.6.11 to 2.6.12

#41 Updated by Vincent MEMBRÉ 6 months ago

  • Target version changed from 2.6.12 to 2.6.13

#42 Updated by Vincent MEMBRÉ 3 months ago

  • Target version changed from 2.6.13 to 2.6.14

#43 Updated by Jonathan CLARKE 3 months ago

  • Target version changed from 2.6.14 to 2.6.16

#44 Updated by Jonathan CLARKE 2 months ago

  • Target version changed from 2.6.16 to 2.6.17

#45 Updated by Nicolas PERRON 23 days ago

  • Target version changed from 2.6.17 to 2.6.18

Also available in: Atom PDF