Skip to content

Non-atomic default plugins update can cause havoc. #1090

Open
@kyrian666

Description

@kyrian666

Affected Puppet, Ruby, OS and module versions/distributions

  • Puppet: 7.28.0
  • Ruby: 2.7.0p0
  • Distribution: Ubuntu
  • Module version: 2.0.0

How to reproduce (e.g Puppet code you use)

Have a broken download repo/url when this module runs.

What are you seeing

The combined effects of these two bits of code:

https://github.com/voxpupuli/puppet-jenkins/blob/v4.0.0/manifests/plugin.pp#L185-L190
https://github.com/voxpupuli/puppet-jenkins/blob/v4.0.0/manifests/params.pp#L8-L16

Will completely trash a jenkins instance if the plugin download URL is unresponsive at the time it runs. Because the code is not atomic and is prone to dangerous failure if the plugin file download fails. Because it removes critical plugins without replacing them with anything at all, thus placing you in dependency hell for your jenkins instance. Because structs and credentials underpin just about everything useful Jenkins ever does.

What behaviour did you expect instead

To degrade gracefully in the even of a failure to download. Not to delete a plugin until it has already been downloaded to a temporary directory and then move the intermediate version into place live with for example a more atomic 'mv' call, or equivalent puppet resource. Perhaps a defined type might be better here than a chain of exec and archive.

Output log

/Stage[main]/Jenkins::Config/Jenkins::Plugin[credentials]/Archive[credentials.hpi]/ensure)
/Stage[main]/Jenkins::Config/Jenkins::Plugin[structs]/Archive[structs.hpi]/ensure)

Then the rest is in STDOUT etc. My client is pretty sensitive so I can't share much more. Don't think there's a need as this problem is pretty clear.

Any additional information you'd like to impart

You can work around this with hiera:

jenkins::default_plugins: []

And you can, if you have one, just restore a backup of your plugins directory to before the problem happened in order to get functional jenkins back again.

This is particularly bad because it's not at all obvious that this has happened until you really go digging, so not only does it fail to degrade gracefully it can leave you in a mess that is very badly broken and hard to track down. Even if the problem itself can't be fixed, at least some easier to figure out debug information would be good. Although I imagine the problem itself is simple enough to fix in the puppet code.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions