karnauskas/chef-yum-plugin-versionlock

Manages Yum plugin to lock specified packages from being updated

chef-yum-plugin-versionlock's Issues

fix template variable listfile

Existing:
listfile: node['yum-plugin-versionlock']['listfile'],

Correct:
locklist: node['yum-plugin-versionlock']['locklist'],

add travis, rake, spec ..

Yum cache needs to be reloaded after version is locked

Without this if you add the lock and then install the package without version specified and there is newer version of the package available it fails because it is not aware of the lock.

In our code we ran into this issue...This is our solution.. might not be the best and might be overly convoluted but it works

execute 'yum-cache-clean' do
  command 'yum -q makecache'
  action :nothing
end

Chef.event_handler do
  on :resource_update_applied do |resource, _, update|
    begin
      if resource.class == Chef::Resource::Template && resource.name == resource.run_context.node["yum-plugin-versionlock"]["locklist"] && update.first.start_with?("update content in file")
        resource = resource.run_context.resource_collection.lookup('execute[yum-cache-clean]')
        resource.run_action(:run)
        Chef::Provider::Package::Yum::YumCache.instance.reload
      end
    rescue
      # Ignored
    end
  end
end

In practice only the Chef::Provider::Package::Yum::YumCache.instance.reload is needed, we did have the makecache in our old implementation of the lock.. In that case it would be possible to just call this on add and remove actions to avoid this convolution.

Release 0.2.0

Could you please roll a release for 0.2.0? Would be nice to have the Chef 12.5+ custom resource stuff released.

Thanks!

Update action regex can match / delete unintended lines on CentOS 7

🐛 Problem

TLDR: If a package has dashes in its name, the current regex used by :update can match multiple package names and delete unintended locks on Centos 7 and below.

We are using this cookbook to lock some Docker packages on Centos 7, namely docker-ce and docker-ce-cli. We have two versionlock resources :updateing the lock for each of those packages.

The update regex is /^[0-9]+:$PKGNAME-.+-.+\./, which when filled in for docker-ce becomes ^[0-9]+:docker-ce-.+-.+\. The -.+ directly following the package name matches the -cli of the docker-ce-cli lockfile line instead of the version. This would cause all matching lines--both docker-ce and docker-ce-cli--to be replaced with the docker-ce version string, and as of #25 any duplicate lines are removed. The line for docker-ce-cli is then re-added by its lock resource.

The end result is valid, but as the -cli line is removed and readded each converge, this breaks idempotency.

On Centos 8, the epoch and : following the package name prevents this from happening.

We are in the process of updating our internal cookbooks to be idempotent and as such are just noticing this now. I believe this may have also been present with the old Chef::FileEdit-based resource as well, since that used the same regex.

💡 Possible Solution

Updating the regex to look for a number at the start of the version string may fix this, but I am not sure if that would hold for all packages. Some might still have a number after a dash in their name and still trigger this issue, but this would solve this issue for most packages.

Proposed C6/7 regex:

/^\d+:$PKGNAME-\d.*-.+\./

I can make a pull request to make this change, but I wanted to see if there is a better way of handling this first.

0.2.2 to supermarket please?

If it's ready (it's in the CHANGELOG), could we get 0.2.2 pushed to Supermarket please? We're trying to migrate to Chef Infra Client 16.x now that it's been out for a long time. 0.2.1 does not work with 16.x.

Response: Invalid value '>= 6' for metadata.platforms

Hi,

I'm using Chef Server 12.7.2-1 in Ubuntu and I found that a change broke the cookbook for me.

I'm seeing this error when trying to upload the cookbook v0.1.2:

Uploading yum-plugin-versionlock [0.2.0]
ERROR: The data in your request was invalid
Response: Invalid value '>= 6' for metadata.platforms

It looks like the issue is being caused by the lines:

• https://github.com/karnauskas/chef-yum-plugin-versionlock/blob/master/metadata.rb#L15
  supports 'redhat', '>= 6'
• https://github.com/karnauskas/chef-yum-plugin-versionlock/blob/master/metadata.rb#L16
  supports 'centos', '>= 6'

Please let me know if I can help with something else.

Regards

please add `provides` to fix resource name on chef 16

Thank you for this valuable cookbook! I find that on chef 16.2 I need to add provides :yum_version_lock in addition to resource_name in order for the resource to be recognized.

According to https://docs.chef.io/release_notes/#breaking-change-in-resources having both should be backwards-compatible with previous chef versions.

add lwrp resource yum_version_lock

update action is not removing other package versions from lock file

centos 6:

[root@localhost /]# cat /etc/yum/pluginconf.d/versionlock.list 
0:rpm-4.11.3-21.x86_64
0:sed-4.2.2-5.x86_64
0:grep-2.20-3.x86_64
0:grep-2.20-3.x86_64
0:grep-2.20-3.x86_64
0:grep-2.20-3.x86_64

centos 8:

[root@dokken /]# cat /etc/dnf/plugins/versionlock.list 
rpm-0:4.11.3-21.x86_64
sed-0:4.2.2-5.x86_64
grep-0:2.20-3.x86_64
grep-0:2.20-3.x86_64
grep-0:2.20-3.x86_64

Chef 17 / `unified_mode`-compliant release

The currently-released version of this cookbook on the supermarket (v0.4.0) is currently causing some deprecation warnings for unified_mode. These were fixed in f882e3c but there has not been a release since then.

Could you please cut a release including the unified_mode fix?

Thanks!

disable node['yum-plugin-versionlock']['versions'] in favor of lwrp

Tests are failing for gcc package on CentOS 8

install package yum-plugin-versionlock

Looks like cookbook does not install yum version lock plugin. Will submit a PR.

Running on chef kitchen shows No candidate version available for yum-plugin-versionlock

publish new cookbook version to supermarket