Puppet users - Feb 2011 - Fresh node fails puppet run - init script not found before installing package

Hey all,

I was installing puppet on a freshly installed node and the catalog
fails to apply. It immediately bails out with:
err: Could not run Puppet configuration client: Could not find init
script for ''ssh''

This is annoying and odd. ssh service is run by a module in main stage,
there is a stage before that which isn''t being applied. The service
subscribes to a file which in turn requires the package.

Can anyone shed light/guess at why puppet is bailing on an init script
for a service it hasn''t installed yet and shouldn''t be
worrying about at
this stage?

Running puppet 2.6.2 on Debian Squeeze. Master is also 2.6.2 on Squeeze.

Cheers,
Dan


modules/ssh/manifests/init.pp
class ssh {
    require ssh::install, ssh::config
}

modules/ssh/manifests/install.pp
class ssh::install {
    package {
        ''openssh-server'': ;
        ''openssh-clients'':
            name => $operatingsystem ? {
                debian  => ''openssh-client'',
                default => ''openssh-clients'',
            };
    }
}

modules/ssh/manifests/config.pp
class ssh::config {
    File {
        require => Class[''ssh::install''],
    }

    file {
        ''/etc/ssh/sshd_config'':
            source => [
                "puppet:///files/$fqdn/ssh/sshd_config",
               
"puppet:///modules/ssh/sshd_config-${domain}.$operatingsystem",
                "puppet:///modules/ssh/sshd_config.$operatingsystem",
            ];
        ''/etc/ssh/ssh_config'':
            source => ''puppet:///modules/ssh/ssh_config'';
        ''/etc/ssh/ssh_known_hosts'':
            source =>
''puppet:///files/ssh/ssh_known_hosts'';
    }

    service { ''sshd'':
        name => $operatingsystem ? {
            debian  => ''ssh'',
            default => ''sshd'',
        },
        subscribe => File[''/etc/ssh/sshd_config''],
        hasstatus => true,
    }
}

manifests/site.pp (minus other includes and some hierarchy):
node default {
    include ssh
    class { "repositories": stage => repositories; }
}

Defaults:
stage { ''repositories'': before => Stage[main] }
File {
    owner => root,
    group => root,
    mode  => 644,
}
Package {
    ensure  => latest,
}
Service {
    enable     => true,
    ensure     => running,
    hasrestart => true,
}

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi,

On 02/16/2011 05:35 PM, Daniel Piddock wrote:
> Hey all,
> 
> I was installing puppet on a freshly installed node and the catalog
> fails to apply. It immediately bails out with:
> err: Could not run Puppet configuration client: Could not find init
> script for ''ssh''
> 
> This is annoying and odd. ssh service is run by a module in main stage,
> there is a stage before that which isn''t being applied. The
service
> subscribes to a file which in turn requires the package.
> 
> Can anyone shed light/guess at why puppet is bailing on an init script
> for a service it hasn''t installed yet and shouldn''t be
worrying about at
> this stage?
> 
> Running puppet 2.6.2 on Debian Squeeze. Master is also 2.6.2 on Squeeze.
> 
> Cheers,
> Dan
> 
> 
> modules/ssh/manifests/init.pp
> class ssh {
>     require ssh::install, ssh::config
> }
Why do you use the require function? I think it''s dangerous in this
case, because it probably tries to enforce an ordering. I.e.,
ssh::config is to be done before the "class ssh" proper. However,
service "sshd" should require the ssh::install class.

Use include instead of require, and make sure the service requires the
install class as well. That may just solve your problem.

HTH,
Felix

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 17/02/11 08:52, Felix Frank wrote:
> Hi,
>
> On 02/16/2011 05:35 PM, Daniel Piddock wrote:
>> Hey all,
>>
>> I was installing puppet on a freshly installed node and the catalog
>> fails to apply. It immediately bails out with:
>> err: Could not run Puppet configuration client: Could not find init
>> script for ''ssh''
>>
>> This is annoying and odd. ssh service is run by a module in main stage,
>> there is a stage before that which isn''t being applied. The
service
>> subscribes to a file which in turn requires the package.
>>
>> Can anyone shed light/guess at why puppet is bailing on an init script
>> for a service it hasn''t installed yet and shouldn''t
be worrying about at
>> this stage?
>>
>> Running puppet 2.6.2 on Debian Squeeze. Master is also 2.6.2 on
Squeeze.
>>
>> Cheers,
>> Dan
>>
>>
>> modules/ssh/manifests/init.pp
>> class ssh {
>>     require ssh::install, ssh::config
>> }
> Why do you use the require function? I think it''s dangerous in
this
> case, because it probably tries to enforce an ordering. I.e.,
> ssh::config is to be done before the "class ssh" proper. However,
> service "sshd" should require the ssh::install class.
>
> Use include instead of require, and make sure the service requires the
> install class as well. That may just solve your problem.
include doesn''t provide a tight enough binding. It simply says
"this
would be useful, please process it at some point". With your suggested
change, if another package puts a dependency on ssh module there''s no
guarantee that the whole module will be processed in a usable state.

e.g.: file { ''something'': require =>
Class[''ssh''] }
class ssh gets processed but ssh::install and ssh::config might not be,
unless I put a depend on something deeper within it. Which defeats the
idea of organising into classes a bit.

I should probably just rewrite all my modules to be single classes
unless there''s a clear use for a proper subclass. Puppet''s
classing
seems broken and my design with requires isn''t helping.

I also think this is a tangent to the issue of failing a catalog due to
an init script not being present on a service that has dependencies to
process.

Dan

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> e.g.: file { ''something'': require =>
Class[''ssh''] }
> class ssh gets processed but ssh::install and ssh::config might not be,
> unless I put a depend on something deeper within it. Which defeats the
> idea of organising into classes a bit.
Where have you gotten that idea from? Is this documented?

AFAIK, requiring Class[ssh] will require all resources declared by class
ssh, and it doesn''t matter whether those resources are declared through
include or directly in the class.

Correct me if I''m wrong, please.

If I *am* wrong on this one, here''s what should be safer:
class ssh {
  include ssh::install
  require ssh::config
}

and have all resources in ssh::config require Class[ssh::install], but
that would be ugly and a bit evil (although not as evil as requiring two
interrelated classes).

All this aside, I looked at your error again and begin to doubt that
this is the root cause of your problems. Your catalog should either
apply or be rejected because of cyclic dependencies. Something else must
be fishy. Does the catalog work if your node doesn''t include ssh at
all?

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 17/02/11 11:45, Felix Frank wrote:
>> e.g.: file { ''something'': require =>
Class[''ssh''] }
>> class ssh gets processed but ssh::install and ssh::config might not be,
>> unless I put a depend on something deeper within it. Which defeats the
>> idea of organising into classes a bit.
> Where have you gotten that idea from? Is this documented?
>
> AFAIK, requiring Class[ssh] will require all resources declared by class
> ssh, and it doesn''t matter whether those resources are declared
through
> include or directly in the class.
>
> Correct me if I''m wrong, please.
My first mail to the group was about this very issue with the conclusion
of using require instead of include:
http://groups.google.com/group/puppet-users/browse_thread/thread/64e4dde981c79ffb/bbb8bdc4ab78c328?lnk=gst

A require does require everything defined within the class but it does
not put a dependency on other classes pulled in by an include.
> If I *am* wrong on this one, here''s what should be safer:
> class ssh {
>   include ssh::install
>   require ssh::config
> }
>
> and have all resources in ssh::config require Class[ssh::install], but
> that would be ugly and a bit evil (although not as evil as requiring two
> interrelated classes).
>
> All this aside, I looked at your error again and begin to doubt that
> this is the root cause of your problems. Your catalog should either
> apply or be rejected because of cyclic dependencies. Something else must
> be fishy. Does the catalog work if your node doesn''t include ssh
at all?
I managed to solve the problem by installing the openssh-server package
manually so the init script was present. I have other modules with a
very similar structure and they weren''t throwing up these errors. Odd
glitch. Frustrating.

Cheers,
Dan

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 17/02/11 12:09, Daniel Piddock wrote:
> I managed to solve the problem by installing the openssh-server package
> manually so the init script was present. I have other modules with a
> very similar structure and they weren''t throwing up these errors.
Odd
> glitch. Frustrating.
I tried a few more things and it''s still failing:
* Upgrading the server and client to 2.6.4.
* Flattened the ssh module to remove the class level requires.
* Added a node definition so that only the ssh class was included.
* Put a direct require from Service[ssh] to Package[openssh-server]
* Syntax errors in init.pp to ensure it''s actually reading the right
file ;)

Attaching init.pp from ssh module and the client''s cached yaml if
anyone
fancies looking.

Dan

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Feb 17, 2011 at 4:09 AM, Daniel Piddock
<dgp-goog@corefiling.co.uk> wrote:
> On 17/02/11 11:45, Felix Frank wrote:
>>> e.g.: file { ''something'': require =>
Class[''ssh''] }
>>> class ssh gets processed but ssh::install and ssh::config might not
be,
>>> unless I put a depend on something deeper within it. Which defeats
the
>>> idea of organising into classes a bit.
>> Where have you gotten that idea from? Is this documented?
>>
>> AFAIK, requiring Class[ssh] will require all resources declared by
class
>> ssh, and it doesn''t matter whether those resources are
declared through
>> include or directly in the class.
>>
>> Correct me if I''m wrong, please.
>
> My first mail to the group was about this very issue with the conclusion
> of using require instead of include:
>
http://groups.google.com/group/puppet-users/browse_thread/thread/64e4dde981c79ffb/bbb8bdc4ab78c328?lnk=gst
>
> A require does require everything defined within the class but it does
> not put a dependency on other classes pulled in by an include.
Yep. If you need to achieve this, you''ll need Class[ssh] to require
Clas[ssh::install, ssh::config] rather than simply including.



>
>> If I *am* wrong on this one, here''s what should be safer:
>> class ssh {
>>   include ssh::install
>>   require ssh::config
>> }
>>
>> and have all resources in ssh::config require Class[ssh::install], but
>> that would be ugly and a bit evil (although not as evil as requiring
two
>> interrelated classes).
>>
>> All this aside, I looked at your error again and begin to doubt that
>> this is the root cause of your problems. Your catalog should either
>> apply or be rejected because of cyclic dependencies. Something else
must
>> be fishy. Does the catalog work if your node doesn''t include
ssh at all?
>
> I managed to solve the problem by installing the openssh-server package
> manually so the init script was present. I have other modules with a
> very similar structure and they weren''t throwing up these errors.
Odd
> glitch. Frustrating.
>
> Cheers,
> Dan
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 17/02/11 14:05, Daniel Piddock wrote:
> On 17/02/11 12:09, Daniel Piddock wrote:
>> I managed to solve the problem by installing the openssh-server package
>> manually so the init script was present. I have other modules with a
>> very similar structure and they weren''t throwing up these
errors. Odd
>> glitch. Frustrating.
> I tried a few more things and it''s still failing:
> * Upgrading the server and client to 2.6.4.
> * Flattened the ssh module to remove the class level requires.
> * Added a node definition so that only the ssh class was included.
> * Put a direct require from Service[ssh] to Package[openssh-server]
> * Syntax errors in init.pp to ensure it''s actually reading the
right file ;)
>
> Attaching init.pp from ssh module and the client''s cached yaml if
anyone
> fancies looking.
>
> Dan
Puppet bug.

It''s setting the name parameter to not match the title that causes this
example to explode and why the other services weren''t.

Issue 5610. Still hasn''t been fixed in 2.6.5rc4. Ah well, something
else
to work around.

Cheers,
Dan

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Feb 17, 8:05 am, Daniel Piddock <dgp-g...@corefiling.co.uk> wrote:

I was going to suggest some of the things you report already trying:
> * Flattened the ssh module to remove the class level requires.
I find that better form in this case because I can''t imagine a reason
to include/require just ssh::install, and ssh::config will (should)
pull in ssh::install every time via the default dependency it
declares.  As such, there is no functional difference between class
ssh and class ssh::config.  Furthermore, ssh::config and ssh::install
are not so large that there is any code organization advantage to the
split, and putting their contents together better encapsulates their
dependencies.

Nevertheless, even though I prefer a flat module structure in this
case, I don''t see why there should have been dependency problems with
the original structure.
> * Put a direct require from Service[ssh] to Package[openssh-server]
I think it''s always a good idea for a service to depend directly on
the package that provides it.  I realize that you previously had a
transitive dependency on the package via the config file, but for me
it''s not just a matter of getting all the dependencies ordered, but of
modelling the system correctly.  Services should directly depend on
their packages because the packages provide their binaries.  They
should depend on any configuration file and/or init script that you
manage because those influence the service execution.  Whether the
config file / init script also depends on the package is irrelevant as
far as I''m concerned.

Still, I don''t see why your original manifest should have suffered
from resource ordering problems.
> Attaching init.pp from ssh module and the client''s cached yaml if
anyone
> fancies looking.
I am a novice at analyzing Puppet yaml, but I don''t see any
relationship edges that correspond to your explicit ''requires''
and
''subscribe'' dependencies.  That seems suspect to me, but maybe
it''s
normal.  I do see all the resources, and the ''requires'' and
''subscribe'' parameters themselves.  If the yaml in fact should
contain
relationship edges for the explicit dependencies, then I have no idea
why yours doesn''t.

Are you sure that the yaml corresponds to the manifest you posted?  It
looks like it does, but is there any chance that a stale server-cached
catalog was provided by the master?  Could a stale client-cached
catalog have been applied by the client?  There are Puppet
configuration options that can prevent those things: ignorecache,
use_cached_catalog, usecacheonfailure.

Also, do you confirm that the puppet agent fails on that catalog with
exactly the same error you originally posted?  And do you see any
relevant errors in the master''s log?

You said you had other, similarly-structured modules that work.  Do
any of them also include Services?  Can you recheck that they in fact
work for the affected node?  Do you see any significant differences
between the manifests?


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.