The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #2384

Provider features are validated at instantiation rather than run time

Added by Oliver Hookins over 5 years ago. Updated 10 months ago.

Status:AcceptedStart date:07/02/2009
Priority:HighDue date:
Assignee:eric sorenson% Done:

0%

Category:RAL
Target version:-
Affected Puppet version:0.24.8 Branch:
Keywords:usability

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket is now tracked at: https://tickets.puppetlabs.com/browse/PUP-1161


Description

I’m attempting to do the following: 1. Install ruby-shadow 2. Create a user account (with a password)

Unfortunately puppet tends to screw up the order. Here’s the test manifest:

package { ruby-shadow: ensure => installed; }
user { testdude:
    ensure => present,
    gid => users,
    password => '$1$loo03Rez$MfxLF/9uMeaeOPCtceYGc0',
    require => Package[ruby-shadow],
    comment => "test account";
}

Puppet checks for the account’s presence before anything, and complains about ruby-shadow not being there. IMHO it shouldn’t even care about checking anything to do with the account, since I have specified a prerequisite. Anyway, it installs ruby-shadow, then creates the account without a password despite ruby-shadow now being on the system. It takes a second run of puppet to set the password, which is really not ideal.

Here’s the output with debugging and verbose:

[root@test ~]# puppet -d -v test.pp 
debug: Puppet::Type::Package::ProviderRpm: Executing '/bin/rpm --version'
debug: Puppet::Type::Package::ProviderUrpmi: Executing '/bin/rpm -ql rpm'
debug: Puppet::Type::Package::ProviderAptrpm: Executing '/bin/rpm -ql rpm'
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm --version'
debug: Failed to load library 'shadow' for feature 'libshadow'
debug: Puppet::Type::Package::ProviderAptitude: file /usr/bin/aptitude does not exist
debug: Puppet::Type::Package::ProviderPkgdmg: file /Library/Receipts does not exist
debug: Puppet::Type::Package::ProviderFreebsd: file /usr/sbin/pkg_delete does not exist
debug: Puppet::Type::Package::ProviderSun: file /usr/sbin/pkgrm does not exist
debug: Puppet::Type::Package::ProviderEasy_install: file easy_install does not exist
debug: Puppet::Type::Package::ProviderAppdmg: file /Library/Receipts does not exist
debug: Puppet::Type::Package::ProviderHpux: file /usr/sbin/swinstall does not exist
debug: Puppet::Type::Package::ProviderOpenbsd: file pkg_delete does not exist
debug: Puppet::Type::Package::ProviderPorts: file /usr/local/sbin/pkg_deinstall does not exist
debug: Puppet::Type::Package::ProviderGem: file gem does not exist
debug: Puppet::Type::Package::ProviderSunfreeware: file pkg-get does not exist
debug: Puppet::Type::Package::ProviderDarwinport: file /opt/local/bin/port does not exist
debug: Puppet::Type::Package::ProviderFink: file /sw/bin/fink does not exist
debug: Puppet::Type::Package::ProviderRug: file /usr/bin/rug does not exist
debug: Puppet::Type::Package::ProviderApple: file /Library/Receipts does not exist
debug: Puppet::Type::Package::ProviderAptrpm: file apt-get does not exist
debug: Puppet::Type::Package::ProviderApt: file /usr/bin/apt-get does not exist
debug: Puppet::Type::Package::ProviderUrpmi: file urpmi does not exist
debug: Puppet::Type::Package::ProviderUp2date: file /usr/sbin/up2date-nox does not exist
debug: Puppet::Type::Package::ProviderDpkg: file /usr/bin/dpkg does not exist
debug: Puppet::Type::Package::ProviderPortage: file /usr/bin/emerge does not exist
debug: Puppet::Type::User::ProviderUser_role_add: file roleadd does not exist
debug: Puppet::Type::User::ProviderPw: file pw does not exist
debug: Puppet::Type::User::ProviderLdap: true value when expecting false
debug: Puppet::Type::User::ProviderNetinfo: file nireport does not exist
debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/dscl does not exist
info: /User[testdude]: Provider useradd does not support features manages_passwords; not managing attribute password
debug: Creating default schedules
debug: Prefetching yum resources for package
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm --version'
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm -qa --nosignature --nodigest --qf '%{NAME} %|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH}
''
debug: /User[testdude]/require: requires Package[ruby-shadow]
debug: Failed to load library 'ldap' for feature 'ldap'
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm -q ruby-shadow --nosignature --nodigest --qf %{NAME} %|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH}
'
debug: //Package[ruby-shadow]: Changing ensure
debug: //Package[ruby-shadow]: 1 change(s)
debug: Package[ruby-shadow](provider=yum): Ensuring => present
debug: Puppet::Type::Package::ProviderYum: Executing '/usr/bin/yum -d 0 -e 0 -y install ruby-shadow'
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm -q ruby-shadow --nosignature --nodigest --qf %{NAME} %|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH}
'
notice: //Package[ruby-shadow]/ensure: created
debug: /User[testdude]: Changing ensure
debug: /User[testdude]: 1 change(s)
debug: User[testdude](provider=useradd): Executing '/usr/sbin/useradd -c test account -g users -M testdude'
notice: /User[testdude]/ensure: created
debug: Finishing transaction 23951941785180 with 2 changes

Related issues

Related to Puppet - Bug #6683: Default provider still called even if provider specified Accepted 03/11/2011
Related to Puppet - Bug #14822: Ensure providers can run if features are delivered during... Closed 06/05/2012
Duplicated by Puppet - Bug #2475: cron types fail hard when cron isn't installed Duplicate 07/31/2009

History

#1 Updated by Luke Kanies over 5 years ago

  • Subject changed from Odd interaction between user and package types when requiring ruby-shadow to Provider features are validated at instantiation rather than run time
  • Category set to RAL
  • Status changed from Unreviewed to Accepted

This is basically the problem of when validation happens, and we’re apparently doing the validation too early here.

#2 Updated by Luke Kanies about 5 years ago

  • Target version set to 2.6.0

This is coming up more often, so I’m bumping up its priority.

#3 Updated by James Turnbull over 4 years ago

  • Target version changed from 2.6.0 to 2.7.x

#4 Updated by seph seph over 4 years ago

  • Affected Puppet version changed from 0.24.8 to 0.25.4

I got here by way of #2475 I routinely hit this with cron, and now with augeas. Though easy to work around, it’s frustrating.

#5 Updated by Dan Carley almost 4 years ago

A temporary solution to this issue, rather than modifying your Kickstarts, is to send a dummy provider for the Cron type over with pluginsync. This allows the first run to proceed and install a Cron package, albeit possibly failing to install any Cron resources. A second run will then use the correct provider and mop up any outstanding resources.

# modules/cron/lib/puppet/provider/cron/dummy_issue2384.rb 
Puppet::Type.type(:cron).provide :dummy_issue2384 do
    desc "Dummy provider for Cron.

    Fake nil resources when there is no crontab binary available. Allows
    puppetd to run on a bootstrapped machine before a Cron package has been
    installed. Workaround for: http://projects.puppetlabs.com/issues/2384
    "

    def self.instances
        []
    end
end

#6 Updated by Peter Meier almost 4 years ago

this is quite annoying if you want to distribute a provider and imho it breaks a fundamental feature of puppet… Can we get some priority for this problem?

#7 Updated by Nigel Kersten almost 4 years ago

  • Priority changed from Normal to High
  • Affected Puppet version changed from 0.25.4 to 0.24.8
  • Keywords set to usability

Yes. This is immensely frustrating.

#8 Updated by Simon Josi almost 4 years ago

Peter Meier wrote:

this is quite annoying if you want to distribute a provider and imho it breaks a fundamental feature of puppet… Can we get some priority for this problem?

+1

#9 Updated by Jordan Raub over 3 years ago

Simon Josi wrote:

Peter Meier wrote:

this is quite annoying if you want to distribute a provider and imho it breaks a fundamental feature of puppet… Can we get some priority for this problem?

+1

+1 anything done with this issue?

#10 Updated by Gary Richards over 2 years ago

+1 Just ran into this myself with a custom provider.

#11 Updated by Gabriel Filion over 2 years ago

humm.. a high priority, 3 years-old issue :(

does this still affect recent puppet versions? Gary, which version of puppet were you using when you ran into this issue?

#12 Updated by jared jennings over 2 years ago

I’ve still got the problem with 2.7.6, although I’m not sure if that’s “recent”

#13 Updated by Nigel Kersten over 2 years ago

  • Assignee set to eric sorenson

#14 Updated by Dominic Cleal over 2 years ago

I recently filed #14822 with a fix that disables negative caching of features, so we pick up on when features are installed during a run. I think it’s a duplicate of this issue. If so, pull request 833 has the fix.

#15 Updated by Dominic Cleal over 2 years ago

Dominic Cleal wrote:

I recently filed #14822 with a fix that disables negative caching of features, so we pick up on when features are installed during a run. I think it’s a duplicate of this issue. If so, pull request 833 has the fix.

I’ve tested the original example and see now this is slightly different: I fixed Puppet.features to prevent caching, but this is different to a provider’s features. This means that #14822 is probably a pre-requisite to fix this as libshadow is checked via Puppet.features, but it didn’t solve the re-evaluation of the provider features.

It looks like an equivalent of “confine :feature” is needed for provider features?

#16 Updated by jared jennings about 2 years ago

Dan Carley wrote:

A temporary solution to this issue … is … a dummy provider

I have a gconf resource type that depends on the existence of /usr/bin/gconftool-2. Up until now I’ve used dummy providers to “allow… my run to proceed,” referencing this ticket in their documentation. Now because of the fix to #6907 (the fix went into 2.7.8), Puppet no longer barfs at startup if there are instances of resource types that have no suitable providers. So I’ve been able to remove the dummy providers.

I’m not sure whether the #6907 fix also fixes the original stated problem of this ticket.

#17 Updated by Dominic Cleal about 2 years ago

jared jennings wrote:

Dan Carley wrote:

A temporary solution to this issue … is … a dummy provider

I have a gconf resource type that depends on the existence of /usr/bin/gconftool-2. Up until now I’ve used dummy providers to “allow… my run to proceed,” referencing this ticket in their documentation. Now because of the fix to #6907 (the fix went into 2.7.8), Puppet no longer barfs at startup if there are instances of resource types that have no suitable providers. So I’ve been able to remove the dummy providers.

I’m not sure whether the #6907 fix also fixes the original stated problem of this ticket.

I believe this ticket is subtly different and that #6907 is the one for your problem. This ticket covers the case where a provider is valid, but not all of its features are available initially – for example the “useradd” provider is functional, but since libshadow’s missing the “manages_passwords” feature isn’t.

#18 Updated by Andrew Parker almost 2 years ago

  • Target version deleted (2.7.x)

#19 Updated by Dominic Cleal 10 months ago

Redmine Issue #2384 has been migrated to JIRA:

https://tickets.puppetlabs.com/browse/PUP-1161

Also available in: Atom PDF