User story #10237
closed
Make package cache refresh frequency configurable
Description
I have a directive associated with a rule that is supposed to install the telnet package. My test platform has 3 servers, RHEL 6, RHEL 5, and CentOS 6.
The Agent Run Schedule is 5 minutes, and the Maximum Delay is set to 0 (screenshot attached).
On the rule, I have the MOTD directive attached, for debugging purposes.
Within 10 minutes, one of the servers re-installs telnet but the other 2 do not. After about 30 minutes, the second one gets installed, but the third doesn't.
Eventually, the 3rd one will get installed, but I'm not sure about the time. The output on each server follows:
---------------Start of First Server-------------------
[root@rclient1 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.5 (Santiago)
[root@rclient1 ~]# date;yum -y -q remove telnet; echo > /etc/motd
Mon Feb 20 16:43:29 EST 2017
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
[root@rclient1 ~]# date;yum -q list telnet; cat /etc/motd
Mon Feb 20 16:43:52 EST 2017
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Available Packages
telnet.x86_64 1:0.17-48.el6 rhui-rhel-6-server-rhui-rpms
Mon Feb 20 16:49:21 EST 2017
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Available Packages
telnet.x86_64 1:0.17-48.el6 rhui-rhel-6-server-rhui-rpms
- This line was put here by Rudder ***
[root@rclient1 ~]# date;yum -q list telnet; cat /etc/motd
Mon Feb 20 16:55:27 EST 2017
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Available Packages
telnet.x86_64 1:0.17-48.el6 rhui-rhel-6-server-rhui-rpms - This line was put here by Rudder ***
[root@rclient1 ~]# date;yum -q list telnet; cat /etc/motd
Mon Feb 20 16:57:35 EST 2017
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Installed Packages
telnet.x86_64 1:0.17-48.el6 @rhui-rhel-6-server-rhui-rpms - This line was put here by Rudder ***
-------------End of First Server---------------------------
----------Beginning of Second Server-------------------------
[root@rclient5 ~]# cat /etc/redhat-release
CentOS release 6.4 (Final)
[root@rclient5 ~]# date;yum -y -q remove telnet; echo > /etc/motd
Mon Feb 20 16:42:46 EST 2017
[root@rclient5 ~]# date;yum -q list telnet; cat /etc/motd
Mon Feb 20 16:43:55 EST 2017
Available Packages
telnet.x86_64 1:0.17-48.el6 base
Mon Feb 20 16:49:32 EST 2017
Available Packages
telnet.x86_64 1:0.17-48.el6 base
- This line was put here by Rudder ***
[root@rclient5 ~]# date;yum -q list telnet; cat /etc/motd
Mon Feb 20 16:55:33 EST 2017
Available Packages
telnet.x86_64 1:0.17-48.el6 base - This line was put here by Rudder ***
[root@rclient5 ~]# date;yum -q list telnet; cat /etc/motd
Mon Feb 20 16:57:43 EST 2017
Available Packages
telnet.x86_64 1:0.17-48.el6 base - This line was put here by Rudder ***
[root@rclient5 ~]# date;yum -q list telnet; cat /etc/motd
Mon Feb 20 17:03:40 EST 2017
Available Packages
telnet.x86_64 1:0.17-48.el6 base - This line was put here by Rudder ***
[root@rclient5 ~]# date;yum -q list telnet; cat /etc/motd
Mon Feb 20 17:04:57 EST 2017
Available Packages
telnet.x86_64 1:0.17-48.el6 base - This line was put here by Rudder ***
[root@rclient5 ~]# date;yum -q list telnet; cat /etc/motd
Mon Feb 20 17:15:38 EST 2017
Installed Packages
telnet.x86_64 1:0.17-48.el6 @base - This line was put here by Rudder ***
[root@rclient5 ~]#
-------------End of Second Server---------------------------------
-------------Start of Third Server--------------------------------
[root@rclient2 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.11 (Tikanga)
[root@rclient2 ~]# date;yum -y -q remove telnet; echo > /etc/motd
Mon Feb 20 16:42:48 EST 2017
[root@rclient2 ~]# date;yum -q list telnet; cat /etc/motd
Mon Feb 20 16:43:59 EST 2017
Available Packages
telnet.x86_64 1:0.17-41.el5 rhui-rhel-5-server-rhui-rpms
Mon Feb 20 16:49:36 EST 2017
Available Packages
telnet.x86_64 1:0.17-41.el5 rhui-rhel-5-server-rhui-rpms
- This line was put here by Rudder ***
[root@rclient2 ~]# date;yum -q list telnet; cat /etc/motd
Mon Feb 20 16:55:37 EST 2017
Available Packages
telnet.x86_64 1:0.17-41.el5 rhui-rhel-5-server-rhui-rpms - This line was put here by Rudder ***
[root@rclient2 ~]# date;yum -q list telnet; cat /etc/motd
Mon Feb 20 16:57:48 EST 2017
Available Packages
telnet.x86_64 1:0.17-41.el5 rhui-rhel-5-server-rhui-rpms - This line was put here by Rudder ***
[root@rclient2 ~]# date;yum -q list telnet; cat /etc/motd
Mon Feb 20 17:03:48 EST 2017
Available Packages
telnet.x86_64 1:0.17-41.el5 rhui-rhel-5-server-rhui-rpms - This line was put here by Rudder ***
[root@rclient2 ~]# date;yum -q list telnet; cat /etc/motd
Mon Feb 20 17:05:03 EST 2017
Available Packages
telnet.x86_64 1:0.17-41.el5 rhui-rhel-5-server-rhui-rpms - This line was put here by Rudder ***
[root@rclient2 ~]# date;yum -q list telnet; cat /etc/motd
Mon Feb 20 17:15:44 EST 2017
Available Packages
telnet.x86_64 1:0.17-41.el5 rhui-rhel-5-server-rhui-rpms - This line was put here by Rudder ***
[root@rclient2 ~]# date;yum -q list telnet; cat /etc/motd
Mon Feb 20 17:22:00 EST 2017
Available Packages
telnet.x86_64 1:0.17-41.el5 rhui-rhel-5-server-rhui-rpms - This line was put here by Rudder ***
[root@rclient2 ~]#
----------------------End of Third Server---------------------------- (telnet still not installed after about 40 minutes)
Files
| RunSched.JPG (57.1 KB) RunSched.JPG | |||
| telnet-directive.JPG (63.7 KB) telnet-directive.JPG | |||
| rule.JPG (96.5 KB) rule.JPG |
Updated by Nicolas CHARLES about 7 years ago
Hi Hamlyn,
The agent uses a cache of installed packages, so that it doesn't run at each run a yum list installed/dpkg -l/zypper list or equivalent, as it can be quite ressources intensive. Cache is updated every hour (can be more or less depending on the Technique/Generic Method used, and configuration)
When you remove manually the package telnet, the cache is desynchronized with the actual state; so you'll have to wait for the cache to be refreshed for the agent to realize the package needs to be installed.
Cache file is /var/rudder/cfengine-community/state/packages_[installed|updated]_yum.lmdb
Updated by Hamlyn Mootoo about 7 years ago
Is there a way I can refresh the cache by creating a directive to do so? Or can the cache be deleted causing it to rebuild the cache?
Updated by Nicolas CHARLES about 7 years ago
Yes, if you purge the cache, then it will be rebuilt at next run.
Updated by Benoît PECCATTE about 7 years ago
- Found in version(s) old deleted (
4.0.3)
Updated by Hamlyn Mootoo about 7 years ago
I put in a file to delete those file on every run and it worked, thank you. Is this behavior a rudder behavior or a cfengine native behavior?
Updated by Hamlyn Mootoo about 7 years ago
Sorry I meant to write:
I put in a rule to delete those files on every run and it worked, thank you. Is this behavior a rudder behavior or a cfengine native behavior?
Updated by Nicolas CHARLES about 7 years ago
This is a CFEngine native behaviour
However, I'd like to point out that if you purge this file, you'll make your runs much slower, as each time the agent will need to fetch list of installed and available package, putting quite a strain on the system.
Do you have a specific need to list at each run the list of installed packages and available updates, or is it for a test plateform to demonstrate capabilities ?
Also, if you are using Technique " Package management for RHEL / CentOS / SuSE / RPM systems", there is the option "Check package statuses every (minutes)" that you can use to set the frequency at which you check packages
Updated by Hamlyn Mootoo about 7 years ago
The reason I deleted the files was indeed to demonstrate that if I manually deleted a package (in this case the telnet client), it would be reliably re-installed at the next agent run in 5 minutes. During a demonstration it was very difficult to prove that it would actually do it since nobody is going to wait around up to an hour for the "magic" to happen.
I just looked at "Package management for RHEL / CentOS / SuSE / RPM systems" and I see what you are talking about, but I thought that the individual package management techniques were going to be deprecated in favor of the unified one so I never tried to use them.
Updated by Nicolas CHARLES about 7 years ago
Ok, I wasn't sure of the version you used, that's why I mentionned this technique. This Technique is indeed deprecated, so you are correct to use the unified one.
Updated by François ARMAND about 7 years ago
- Severity set to Major - prevents use of part of Rudder | no simple workaround
- User visibility set to Getting started - demo | first install | level 1 Techniques
Updated by 
Updated by Alexis Mousset almost 7 years ago
- Related to User story #9110: Make the package_module bodies configurable added
Updated by Alexis Mousset almost 7 years ago
- Related to deleted (User story #9110: Make the package_module bodies configurable)
Updated by Alexis Mousset almost 7 years ago
- Blocked by User story #9110: Make the package_module bodies configurable added
Updated by Alexis Mousset almost 7 years ago
- Effort required set to Medium
- Priority changed from 53 to 52
Setting to medium as we need to be able to generate a specific ncf.conf for each node from the webapp to implement #9110.
Updated by Alexis Mousset almost 5 years ago
- Subject changed from Package intallation/repair not reliably happening at next agent run (Splay Time=0) to Make package cache refresh frequency configurable
- Target version set to Ideas (not version specific)
- Priority changed from 47 to 0
Updated by Alexis Mousset almost 4 years ago
- Tracker changed from Bug to User story
- Target version changed from Ideas (not version specific) to 6.1.0~beta1
- Severity deleted (
Major - prevents use of part of Rudder | no simple workaround) - Priority deleted (
0)
Will be done in 6.1 with an overridable global property.
Updated by Vincent MEMBRÉ almost 4 years ago
- Target version changed from 6.1.0~beta1 to 6.1.0~beta2
Updated by Alexis Mousset almost 4 years ago
- Status changed from New to Pending release
Updated by Vincent MEMBRÉ almost 4 years ago
- Status changed from Pending release to Released
This bug has been fixed in Rudder 6.1.0~beta2 which was released today.