Fresh node fails puppet run - init script not found before installing package

[Daniel Piddock]

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,
}

[Felix Frank]

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

[Daniel Piddock]

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

[Felix Frank]

> 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

[Daniel Piddock]

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

[Daniel Piddock]

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

[Nigel Kersten]

On Thu, Feb 17, 2011 at 4:09 AM, Daniel Piddock
<dgp-...@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...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>
>

[Daniel Piddock]

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

[jcbollinger]

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