Puppet users - Apr 2011 - is there a definition of the abstract service type

Hullo
I''m a puppet neophyte and I''m a bit confused about the service
type.
I''ve just run up the learning vm and when I try:

puppet resource service

I don''t seem to get any of the services controlled by xinetd, nor even
xinetd itself.  This doesn''t sound right to me as it will cause future
issues if services are implemented in different ways on different o/s
types.

Is there a canonical definition of the service type abstraction, or is
the definition just how the implementation behaves?

cheers

Tim

-- 
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 Tue, Apr 19, 2011 at 04:24:18AM -0700, Tim Coote wrote:
> Is there a canonical definition of the service type abstraction, or is
> the definition just how the implementation behaves?
What happens when you do:

$ puppet resource service xinetd

That should hopefully give you the output for that.

Resource isn''t, say, a system profiling tool. It''s more an
interface to
resources you have. And while some will give you all the information you
may want (''user'' for example), not all of them can.


-- 
Ben Hughes || http://www.puppetlabs.com/

-- 
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 04/20/2011 03:17 AM, Ben Hughes wrote:
> On Tue, Apr 19, 2011 at 04:24:18AM -0700, Tim Coote wrote:
> 
>> Is there a canonical definition of the service type abstraction, or is
>> the definition just how the implementation behaves?
> 
> What happens when you do:
> 
> $ puppet resource service xinetd
> 
> That should hopefully give you the output for that.
> 
> Resource isn''t, say, a system profiling tool. It''s more
an interface to
> resources you have. And while some will give you all the information you
> may want (''user'' for example), not all of them can.
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

-- 
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 Ben
[I''m using the training machine from puppetlabs]
puppet resource service xinetd

returns info about xinetd.

But
puppet resource service
does not include anything about xinetd, which sounds like a bug to me.

I understand the limitations of what can be recovered, but that''s an
implementation constraint. The documentation talks about an
Abstraction Layer. From a design perspective, I''d expect such an
interface to explicitly tell me what it cannot recover, rather than
silently not returning it, as I''ve no way of knowing that
there''s a
constraint on the o/s / distro vs a bug in puppet.

Tim
On Apr 20, 2:17 am, Ben Hughes <b...@puppetlabs.com>
wrote:
> On Tue, Apr 19, 2011 at 04:24:18AM -0700, Tim Coote wrote:
> > Is there a canonical definition of the service type abstraction, or is
> > the definition just how the implementation behaves?
>
> What happens when you do:
>
> $ puppet resource service xinetd
>
> That should hopefully give you the output for that.
>
> Resource isn''t, say, a system profiling tool. It''s more
an interface to
> resources you have. And while some will give you all the information you
> may want (''user'' for example), not all of them can.
>
> --
> Ben Hughes ||http://www.puppetlabs.com/
-- 
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 Apr 20, 8:13 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
wrote:
> On 04/20/2011 03:17 AM, Ben Hughes wrote:
>
> > On Tue, Apr 19, 2011 at 04:24:18AM -0700, Tim Coote wrote:
>
> >> Is there a canonical definition of the service type abstraction,
or is
> >> the definition just how the implementation behaves?
>
> > What happens when you do:
>
> > $ puppet resource service xinetd
>
> > That should hopefully give you the output for that.
>
> > Resource isn''t, say, a system profiling tool. It''s
more an interface to
> > resources you have. And while some will give you all the information
you
> > may want (''user'' for example), not all of them can.
>
> 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.

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.

Tim

-- 
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 20.4.2011 20:30, Tim Coote wrote:
> On Apr 20, 8:13 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
> wrote:
>> 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.
> 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.
Setting sysctls or starting firewalls are coming to me mind.

-- 
Kind Regards, Markus Falb

Intriguingly, on a fedora 13 host, using puppet-0.25.5-1.fc13.noarch,
information about xinetd *is* returned by
puppet resource service.

the version on the learning machine is:
pe-puppet-2.6.4-7.el5

Is the change in behaviour a bug? how can I tell?

On Apr 20, 6:42 pm, Tim Coote <tim.coo...@googlemail.com>
wrote:
> Hi Ben
> [I''m using the training machine from puppetlabs]
> puppet resource service xinetd
>
> returns info about xinetd.
>
> But
> puppet resource service
> does not include anything about xinetd, which sounds like a bug to me.
>
> I understand the limitations of what can be recovered, but that''s
an
> implementation constraint. The documentation talks about an
> Abstraction Layer. From a design perspective, I''d expect such an
> interface to explicitly tell me what it cannot recover, rather than
> silently not returning it, as I''ve no way of knowing that
there''s a
> constraint on the o/s / distro vs a bug in puppet.
>
> Tim
> On Apr 20, 2:17 am, Ben Hughes <b...@puppetlabs.com> wrote:
>
>
>
>
>
>
>
> > On Tue, Apr 19, 2011 at 04:24:18AM -0700, Tim Coote wrote:
> > > Is there a canonical definition of the service type abstraction,
or is
> > > the definition just how the implementation behaves?
>
> > What happens when you do:
>
> > $ puppet resource service xinetd
>
> > That should hopefully give you the output for that.
>
> > Resource isn''t, say, a system profiling tool. It''s
more an interface to
> > resources you have. And while some will give you all the information
you
> > may want (''user'' for example), not all of them can.
>
> > --
> > Ben Hughes ||http://www.puppetlabs.com/
-- 
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 Wed, Apr 20, 2011 at 10:42:21AM -0700, Tim Coote wrote:
> [I''m using the training machine from puppetlabs]
> puppet resource service xinetd
Which one? Not all of them use xinetd. Certainly the CentOS 5 machine I
have doesn''t have xinetd. So it won''t report it as a service.
Querying it
directly will say not to run it as it doesn''t exist.

[ben@centos56:~]% puppet resource package xinetd
package { ''xinetd'':
  ensure => ''absent'',
  }
[ben@centos56:~]% puppet resource service xinetd
service { ''xinetd'':
	ensure => ''running'',
	enable => ''false'',
}

I don''t know if Fedora uses xinetd by default as I don''t have
a Fedora
machine here to test with I''m afraid.
> From a design perspective, I''d expect such an
> interface to explicitly tell me what it cannot recover, rather than
> silently not returning it, as I''ve no way of knowing that
there''s a
> constraint on the o/s / distro vs a bug in puppet.
I think this may, to a degree, be a case of not being able to know the
unknown. Certainly resource can improve in some areas though.

If it is a bug then I''d like to get it fixed too.

-- 
Ben Hughes || http://www.puppetlabs.com/

-- 
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.

>> 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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 2011-04-21 09:18, Felix Frank wrote:
> 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.
Well, on RedHat:ish systems, the chkconfig(8) command can manage xinetd
services, and since Puppet has a "redhat" provider which uses
chkconfig,
it is already possible to manage xinetd services using the Puppet, at
least on RedHat systems.

However, puppet resource/ralsh doesn''t seem to understand the xinetd
portion of the output from ''chkconfig --list'', so it
doesn''t show
those services.  At least, I *guess* ralsh uses ''chkconfig
--list'' to
find out which services exist on the system, but I haven''t checked.
This should probably be reported as a bug by someone who cares about
ralsh (i.e., not me).


	/Bellman

-- 
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 04/21/2011 09:35 AM, Thomas Bellman wrote:
> On 2011-04-21 09:18, Felix Frank wrote:
> 
>> 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.
> 
> Well, on RedHat:ish systems, the chkconfig(8) command can manage xinetd
> services, and since Puppet has a "redhat" provider which uses
chkconfig,
> it is already possible to manage xinetd services using the Puppet, at
> least on RedHat systems.
> 
> However, puppet resource/ralsh doesn''t seem to understand the
xinetd
> portion of the output from ''chkconfig --list'', so it
doesn''t show
> those services.  At least, I *guess* ralsh uses ''chkconfig
--list'' to
> find out which services exist on the system, but I haven''t
checked.
> This should probably be reported as a bug by someone who cares about
> ralsh (i.e., not me).
Hi,

I don''t think ralsh packs much intelligence in that regard, but relies
on the redhat provider instead.

Peaking at the provider, it doesn''t appear to do anything special. It
relies on the default (=init) method to find available services, which
is browsing /etc/init.d.

I concur that this can possibly be improved. If you do care for good
chkconfig integration (ralsh has nothing to do with it), you may want to
consider opening that bug after all ;-)

Also, thanks for the useful hint about xinetd+chkconfig, I wasn''t aware
of that.

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 2011-04-21 10:19, Felix Frank wrote:
> I don''t think ralsh packs much intelligence in that regard, but
relies
> on the redhat provider instead.
Yes, I was thinking "ralsh" as in "ralsh and all the subroutines
from
the rest of Puppet that it uses".
> Peaking at the provider, it doesn''t appear to do anything special.
It
> relies on the default (=init) method to find available services, which
> is browsing /etc/init.d.
> 
> I concur that this can possibly be improved. If you do care for good
> chkconfig integration (ralsh has nothing to do with it), you may want to
> consider opening that bug after all ;-)
Right, the ''resources'' type of course also uses that
functionality.  I
didn''t think of that.  As I said, it already works to do e.g.

    service { "rsync": enable => true; }

to enable the xinetd-based rsync service, or

    ralsh service rsync

to find out if it is enabled or not.  At least in 0.25.5 and 2.6.6.  The
''ensure'' parameter that ralsh reports isn''t in
accordance with reality,
though (it seems to be always returning "running")...


	/Bellman

-- 
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.

This all sounds to me like there isn''t much of an abstraction, since
there''s no definition of what ought to happen (as opposed to what does
happen).

Surely, I want to be able to manage the xyz service in the same way no
matter what the operating system. If I take Felix'' suggestion and
start hacking code, how do I know that it''s consistent with behaviour
across all platforms?

My experience is that such questions are major barriers to enterprise
uptake of products as it''s not clear whose responsibility it is to get
things working consistently across platforms or between product
releases.

To extend the cron example, it could be extended to ''a
scheduler'' with
a mapping to cron and, say, anacron, Windows'' at system and autosys
(which is widely used in enterprises).

A dependency could be on a specific package, or on a generic
scheduler, which should reduce the replication in manifests.

In the particular instance of xinetd service on the learning vm, the
package is not installed (doh) and the directory /etc/xinetd.d is
actually owned by filesystem, rather than the xinetd package.  There''s
a whole ontology around these different entities that (imo) needs
clarification/definition if the use of puppet is to be consistent.

Tim



On Apr 21, 10:32 am, Thomas Bellman <bell...@nsc.liu.se>
wrote:
> On 2011-04-21 10:19, Felix Frank wrote:
>
> > I don''t think ralsh packs much intelligence in that regard,
but relies
> > on the redhat provider instead.
>
> Yes, I was thinking "ralsh" as in "ralsh and all the
subroutines from
> the rest of Puppet that it uses".
>
> > Peaking at the provider, it doesn''t appear to do anything
special. It
> > relies on the default (=init) method to find available services, which
> > is browsing /etc/init.d.
>
> > I concur that this can possibly be improved. If you do care for good
> > chkconfig integration (ralsh has nothing to do with it), you may want
to
> > consider opening that bug after all ;-)
>
> Right, the ''resources'' type of course also uses that
functionality.  I
> didn''t think of that.  As I said, it already works to do e.g.
>
>     service { "rsync": enable => true; }
>
> to enable the xinetd-based rsync service, or
>
>     ralsh service rsync
>
> to find out if it is enabled or not.  At least in 0.25.5 and 2.6.6.  The
> ''ensure'' parameter that ralsh reports isn''t in
accordance with reality,
> though (it seems to be always returning "running")...
>
>         /Bellman
-- 
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.