Bug #1896
CFEngine package method seems to confuse class names
| Status: | Discussion | Start date: | 2011-10-04 | ||
|---|---|---|---|---|---|
| Priority: | 2 | Due date: | |||
| Assignee: | % Done: | 20% |
|||
| Category: | - | ||||
| Target version: | Rudder - 2.3.13 | ||||
| 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!)
History
#1
Updated by Jonathan CLARKE over 1 year 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 over 1 year ago
Isn't it because of a bulk package install, preventing CFEngine to effectively separate each packages installation ?
#3
Updated by Jonathan CLARKE over 1 year ago
- Target version changed from 23 to 2.3.0 (final)
#4
Updated by Jonathan CLARKE over 1 year ago
- Assignee set to Matthieu CERDA
#5
Updated by Matthieu CERDA over 1 year 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 over 1 year 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 over 1 year ago
Note : The commit 3007 in CFengine's SVN was a failure.
#8
Updated by François ARMAND over 1 year ago
- Target version changed from 2.3.0 (final) to 2.3.1
#9
Updated by Jonathan CLARKE over 1 year ago
- Target version changed from 2.3.1 to 2.3.2
#10
Updated by Jonathan CLARKE over 1 year ago
- Target version changed from 2.3.2 to 2.3.3
#11
Updated by Jonathan CLARKE over 1 year ago
- Target version changed from 2.3.3 to 2.3.4
#12
Updated by Jonathan CLARKE over 1 year ago
- Target version changed from 2.3.4 to 2.3.7
#13
Updated by Nicolas PERRON about 1 year 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 12 months 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 12 months 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 11 months ago
- Target version changed from 2.3.8 to 2.3.9
#17
Updated by Jonathan CLARKE 9 months ago
- Assignee deleted (
Matthieu CERDA)
#18
Updated by Nicolas PERRON 6 months 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 6 months ago
- Target version changed from 2.3.9 to 2.3.10
#20
Updated by Nicolas CHARLES 6 months 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 5 months 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 5 months 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 4 months 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 4 months ago
- Target version changed from 2.3.10 to 2.3.11
#25
Updated by Nicolas PERRON 3 months ago
- Project changed from Rudder to packages
- Category deleted (
11)
#26
Updated by Matthieu CERDA about 1 month ago
- Target version changed from 2.3.11 to 2.3.12
#27
Updated by Matthieu CERDA 21 days ago
- Target version changed from 2.3.12 to 2.3.13