>> Also note that under the puppet paradigm, a "service" is not something >> reachable via network (as in "services provided through xinetd"), but >> can be any process that is maintained by use of an init-script. >> >> Regards, >> Felix > > Hi Felix > Any service must surely have an access point (either listening on a > port on some IP address, even if it's just localhost), or some other > IPC mechanism, otherwise it cannot provide a technical service to any > consumer. > > Surely the abstraction cannot relate to init-scripts, otherwise there > would be no mapping to a Windows machine (or even BSD), and I'd need a > totally parallel set of manifests for wintel. That's not abstraction.
Hi, you're partially right, so let me rear back a bit. Puppet types are really pretty high level abstractions. They can indeed represent different types of services, depending on which "provider" puppet uses to manage your service (think of the type as a frontend and provider as backend). On Linux, the default provider for service is indeed "init" (or "debian"), and controls whatever is launched via init-script. Daemons like at or cron, while not being network-enabled, *are* services, so puppet is right to manage them as such. On BSD, the default provider will surely be "bsd" or "freebsd" etc. You find a list of available providers in your installation $RUBYLIB/puppet/provider/service/ and here: http://docs.puppetlabs.com/references/stable/type.html#service So obviously, there is no xinetd provider. I concur that such a thing would probably be worthwile. If your Ruby is good (or if you like doing new things ;-), you may want to cobble one together yourself as a plugin, it's not rocket science. As for Windows, I am not aware of a service provider, and indeed have no idea wether you can simply write one and have it manage services on Windows. But if it does work and there is an API (or CLI) for Windows services (I'm pretty sure there is), it should be doable. > The problem with there not being a description of how the software > should behave (either documentation or a set of tests), is that if > something changes behaviour between releases, there's a large > migration problem for the user. Which software - puppet? Please see the above link. Note that the references for past releases can be found there as well. I hope this made things more clear. Regards, 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
