Puppet users - Nov 2008 - How should a launchd service work in Puppet?

(sending to users and -dev to try and catch the Mac users)

So I''ve been playing around with a launchd service type, and
conceptually it doesn''t map cleanly to Puppet in all cases.

launchd differs from a lot of service frameworks in that it can also
keep jobs alive when the process exits, which leads to some of the
problems below.

Jobs can be set to have various flags that are reasonably
self-explanatoryg that can cause problems here.

KeepAlive - whether it keeps the job alive.
RunAtLoad - whether the job runs when loaded
Disabled - whether the job is loaded at boot.


In puppet we have the concepts of a job being "enabled" and
"ensure"
as being "running" or "stopped"

If you have a KeepAlive job, if you stop it, then launchd relaunches
it. To truly disable it you need to set it to be "stopped" *and* set
"enabled" to false in Puppet terminology.

If you have a RunAtLoad job, if you set it to be "enabled", then
launchd effectively sets it to be "running", so it is impossible to
have service { "foo": enabled => true, ensure => stopped }

I can implement the refreshable feature by interrogating the job, but
I''m unsure how to deal with the above mappings.

Do I just throw my hands up and say, your plists, you deal with the
consequences of jobs set with KeepAlive and RunAtLoad and the service
settings just work as puppet sets them to be?






-- 
Nigel Kersten
Systems Administrator
Tech Lead - MacOps

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

and now with the new correct puppet-dev address...

On Mon, Nov 17, 2008 at 7:42 AM, Nigel Kersten <nigelk@google.com>
wrote:
> (sending to users and -dev to try and catch the Mac users)
>
> So I''ve been playing around with a launchd service type, and
> conceptually it doesn''t map cleanly to Puppet in all cases.
>
> launchd differs from a lot of service frameworks in that it can also
> keep jobs alive when the process exits, which leads to some of the
> problems below.
>
> Jobs can be set to have various flags that are reasonably
> self-explanatoryg that can cause problems here.
>
> KeepAlive - whether it keeps the job alive.
> RunAtLoad - whether the job runs when loaded
> Disabled - whether the job is loaded at boot.
>
>
> In puppet we have the concepts of a job being "enabled" and
"ensure"
> as being "running" or "stopped"
>
> If you have a KeepAlive job, if you stop it, then launchd relaunches
> it. To truly disable it you need to set it to be "stopped" *and*
set
> "enabled" to false in Puppet terminology.
>
> If you have a RunAtLoad job, if you set it to be "enabled", then
> launchd effectively sets it to be "running", so it is impossible
to
> have service { "foo": enabled => true, ensure => stopped }
>
> I can implement the refreshable feature by interrogating the job, but
> I''m unsure how to deal with the above mappings.
>
> Do I just throw my hands up and say, your plists, you deal with the
> consequences of jobs set with KeepAlive and RunAtLoad and the service
> settings just work as puppet sets them to be?
>
>
>
>
>
>
> --
> Nigel Kersten
> Systems Administrator
> Tech Lead - MacOps
>


-- 
Nigel Kersten
Systems Administrator
Tech Lead - MacOps

--~--~---------~--~----~------------~-------~--~----~
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 Nov 17, 2008, at 9:42 AM, Nigel Kersten wrote:
>
> (sending to users and -dev to try and catch the Mac users)
>
> So I''ve been playing around with a launchd service type, and
> conceptually it doesn''t map cleanly to Puppet in all cases.
>
> launchd differs from a lot of service frameworks in that it can also
> keep jobs alive when the process exits, which leads to some of the
> problems below.
>
> Jobs can be set to have various flags that are reasonably
> self-explanatoryg that can cause problems here.
>
> KeepAlive - whether it keeps the job alive.
> RunAtLoad - whether the job runs when loaded
> Disabled - whether the job is loaded at boot.
>
>
> In puppet we have the concepts of a job being "enabled" and
"ensure"
> as being "running" or "stopped"
>
> If you have a KeepAlive job, if you stop it, then launchd relaunches
> it. To truly disable it you need to set it to be "stopped" *and*
set
> "enabled" to false in Puppet terminology.
>
> If you have a RunAtLoad job, if you set it to be "enabled", then
> launchd effectively sets it to be "running", so it is impossible
to
> have service { "foo": enabled => true, ensure => stopped }
>
> I can implement the refreshable feature by interrogating the job, but
> I''m unsure how to deal with the above mappings.
>
> Do I just throw my hands up and say, your plists, you deal with the
> consequences of jobs set with KeepAlive and RunAtLoad and the service
> settings just work as puppet sets them to be?
We had the same problem with SMF on Solaris, and we basically just  
considered ''stopped'' and ''disabled'' to be
equivalent, which I think
would work as well for launchd.

-- 
A person''s maturity consists in having found again the seriousness one
had as a child, at play. --Friedrich Nietzsche
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.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 Mon, Nov 17, 2008 at 3:26 PM, Luke Kanies <luke@madstop.com>
wrote:
>
> On Nov 17, 2008, at 9:42 AM, Nigel Kersten wrote:
>
>>
>> (sending to users and -dev to try and catch the Mac users)
>>
>> So I''ve been playing around with a launchd service type, and
>> conceptually it doesn''t map cleanly to Puppet in all cases.
>>
>> launchd differs from a lot of service frameworks in that it can also
>> keep jobs alive when the process exits, which leads to some of the
>> problems below.
>>
>> Jobs can be set to have various flags that are reasonably
>> self-explanatoryg that can cause problems here.
>>
>> KeepAlive - whether it keeps the job alive.
>> RunAtLoad - whether the job runs when loaded
>> Disabled - whether the job is loaded at boot.
>>
>>
>> In puppet we have the concepts of a job being "enabled" and
"ensure"
>> as being "running" or "stopped"
>>
>> If you have a KeepAlive job, if you stop it, then launchd relaunches
>> it. To truly disable it you need to set it to be "stopped"
*and* set
>> "enabled" to false in Puppet terminology.
>>
>> If you have a RunAtLoad job, if you set it to be "enabled",
then
>> launchd effectively sets it to be "running", so it is
impossible to
>> have service { "foo": enabled => true, ensure =>
stopped }
>>
>> I can implement the refreshable feature by interrogating the job, but
>> I''m unsure how to deal with the above mappings.
>>
>> Do I just throw my hands up and say, your plists, you deal with the
>> consequences of jobs set with KeepAlive and RunAtLoad and the service
>> settings just work as puppet sets them to be?
>
> We had the same problem with SMF on Solaris, and we basically just
> considered ''stopped'' and ''disabled'' to
be equivalent, which I think
> would work as well for launchd.
ok. So ignore "enabled" and just set started to be
"enabled/loaded"
and stopped to be "disabled/unloaded" ?  I guess that is simpler and
should be easy enough to finish off tonight.



-- 
Nigel Kersten
Systems Administrator
Tech Lead - MacOps

--~--~---------~--~----~------------~-------~--~----~
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 Nov 17, 2008, at 5:32 PM, Nigel Kersten wrote:
>>
>> We had the same problem with SMF on Solaris, and we basically just
>> considered ''stopped'' and ''disabled''
to be equivalent, which I think
>> would work as well for launchd.
>
> ok. So ignore "enabled" and just set started to be
"enabled/loaded"
> and stopped to be "disabled/unloaded" ?  I guess that is simpler
and
> should be easy enough to finish off tonight.
Something like that, yeah.

Do you have the ''instances'' method working?  And if so, is it
working
if I run, say, ''ralsh service'' as a normal user?

Just curious. :)

-- 
Susskind''s Rule of Thumb:
     Don''t ask what they think. Ask what they do.
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.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 Mon, Nov 17, 2008 at 3:36 PM, Luke Kanies <luke@madstop.com>
wrote:
>
> On Nov 17, 2008, at 5:32 PM, Nigel Kersten wrote:
>>>
>>> We had the same problem with SMF on Solaris, and we basically just
>>> considered ''stopped'' and
''disabled'' to be equivalent, which I think
>>> would work as well for launchd.
>>
>> ok. So ignore "enabled" and just set started to be
"enabled/loaded"
>> and stopped to be "disabled/unloaded" ?  I guess that is
simpler and
>> should be easy enough to finish off tonight.
>
> Something like that, yeah.
>
> Do you have the ''instances'' method working?  And if so,
is it working
> if I run, say, ''ralsh service'' as a normal user?
>
> Just curious. :)
Unfortunately launchd in the current incarnation doesn''t allow you to
interrogate launchd instances that were launched by another user
account, and pretty much all the services people are interested in are
owned by root.

The inverse could work if the type supported a "user" attribute of
some kind, where root could query other launchd instances it didn''t
launch, but there is quite strong separation there still, as for
example root can''t actually load a launchagent on behalf of a logged
in user and have it be part of the current session.

I was wondering how autorequire worked though... does it matter if I
autorequire potentially non-existent resources?

ie, say I have a job "com.spam.eggsd" that lives at
/Library/LaunchDaemons/com.spam.eggsd.plist

I''d like the type to be sane enough to allow people to manage that
file, but to require it so that any potential changes to the file
(such as writing to the Disabled attribute in the plist) are committed
first.

This is what autorequire does right? Does it matter if there is no
such resource as File["/Library/LaunchDaemons/com.spam.eggsd.plist"]
defined by the user? I assume not, but thought I should check....



-- 
Nigel Kersten
Systems Administrator
Tech Lead - MacOps

--~--~---------~--~----~------------~-------~--~----~
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 Nov 17, 2008, at 6:30 PM, Nigel Kersten wrote:
>
> Unfortunately launchd in the current incarnation doesn''t allow you
to
> interrogate launchd instances that were launched by another user
> account, and pretty much all the services people are interested in are
> owned by root.
>
> The inverse could work if the type supported a "user" attribute
of
> some kind, where root could query other launchd instances it
didn''t
> launch, but there is quite strong separation there still, as for
> example root can''t actually load a launchagent on behalf of a
logged
> in user and have it be part of the current session.
Suckage.  Please make sure you include that in the docs.
>
> I was wondering how autorequire worked though... does it matter if I
> autorequire potentially non-existent resources?
>
> ie, say I have a job "com.spam.eggsd" that lives at
> /Library/LaunchDaemons/com.spam.eggsd.plist
>
> I''d like the type to be sane enough to allow people to manage that
> file, but to require it so that any potential changes to the file
> (such as writing to the Disabled attribute in the plist) are committed
> first.
>
> This is what autorequire does right? Does it matter if there is no
> such resource as
File["/Library/LaunchDaemons/com.spam.eggsd.plist"]
> defined by the user? I assume not, but thought I should check....

Autorequire will just ignore resources that aren''t in the catalog, so  
return as many as you want.

-- 
When one admits that nothing is certain one must, I think, also admit
that some things are much more nearly certain than others.
     -- Bertrand Russell
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.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
-~----------~----~----~----~------~----~------~--~---