On Feb 17, 8:05 am, Daniel Piddock <[email protected]> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
