Mac OS X open ssh server refresh from puppet...

252 views
Skip to first unread message

grandpa

unread,
Aug 30, 2009, 9:06:49 AM8/30/09
to Puppet Users
Anyone out there who've tried updating sshd_config on macs and
restarting / ensure running the ssh server?

I've found that this ALMOST works:

service {
"com.openssh.sshd":
enable => true,
ensure => running;
}

and then notifying that when changing the config... At least,
com.openssh.sshd is what launchd calls the
service.

The problem is this though:

err: //macssh/Service[com.openssh.sshd]: Failed to call refresh on
Service[com.openssh.sshd]: Unable to start service: com.openssh.sshd
at path: /System/Library/LaunchDaemons/ssh.plist...

Anyone good with OS X / Puppet who could enlighten me?

grandpa

unread,
Aug 30, 2009, 9:30:22 AM8/30/09
to Puppet Users
Forgot to add that I'm running Snow Leopard...

I've noticed that to start the ssh server from terminal I must do:
launchctl load -w /System/Library/LaunchDaemons/ssh.plist

Notice the -w switch. Without it I just get "nothing found to load"...

I wonder if this is new to Snow Leopard?

/John

grandpa

unread,
Aug 30, 2009, 9:33:42 AM8/30/09
to Puppet Users
Talking to myself here ;-)... I've noticed in the man pages for
launchctl in Snow Leopard this:

-w Overrides the Disabled key and sets it to false. In previous
versions, this option would modify the configuration file. Now the
state of the Disabled key is stored elsewhere on-disk.

So I guess the behavior DID change... whatever "previous versions"
mean.

Should I file a bug report?

/John

grandpa

unread,
Aug 30, 2009, 9:46:36 AM8/30/09
to Puppet Users
And looking through the ruby code for provider launchd I see this:

# start the service. To get to a state of running/enabled, we need to
# conditionally enable at load, then disable by modifying the
plist file
# directly.
def start
job_path, job_plist = plist_from_label(resource[:name])
did_enable_job = false
cmds = []
cmds << :launchctl << :load
if self.enabled? == :false # launchctl won't load disabled
jobs
cmds << "-w"
did_enable_job = true
end
cmds << job_path
begin
execute(cmds)
rescue Puppet::ExecutionFailure
raise Puppet::Error.new("Unable to start service: %s at
path: %s" % [resource[:name], job_path])
end
# As load -w clears the Disabled flag, we need to add it in
after
if did_enable_job and resource[:enable] == :false
self.disable
end
end

So I guess the -w switch is actually used... not sure where to go from
here.

Anyone?

/John

grandpa

unread,
Aug 30, 2009, 9:51:52 AM8/30/09
to Puppet Users
The actual problem still seems to be with the provider. Doing a proper
trace/debug/verbose I get this output:

debug: Service[com.openssh.sshd](provider=launchd): Executing
'launchctl load /System/Library/LaunchDaemons/ssh.plist'
/Library/Ruby/Site/1.8/puppet/provider/service/launchd.rb:141:in
`start'
/Library/Ruby/Site/1.8/puppet/type/service.rb:61:in `set_running'
/Library/Ruby/Site/1.8/puppet/property.rb:109:in `send'
/Library/Ruby/Site/1.8/puppet/property.rb:109:in `call_valuemethod'
/Library/Ruby/Site/1.8/puppet/property.rb:297:in `set'
/Library/Ruby/Site/1.8/puppet/property.rb:367:in `sync'
/Library/Ruby/Site/1.8/puppet/type/service.rb:72:in `sync'
/Library/Ruby/Site/1.8/puppet/transaction/change.rb:54:in `go'
/Library/Ruby/Site/1.8/puppet/transaction/change.rb:72:in `forward'
/Library/Ruby/Site/1.8/puppet/transaction.rb:118:in `apply_changes'
/Library/Ruby/Site/1.8/puppet/transaction.rb:111:in `collect'
/Library/Ruby/Site/1.8/puppet/transaction.rb:111:in `apply_changes'
/Library/Ruby/Site/1.8/puppet/transaction.rb:83:in `apply'
/Library/Ruby/Site/1.8/puppet/transaction.rb:249:in
`eval_children_and_apply_resource'
/Library/Ruby/Site/1.8/puppet/util.rb:425:in `thinmark'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/
gems/1.8/gems/activesupport-2.2.2/lib/active_support/core_ext/
benchmark.rb:8:in `realtime'
/Library/Ruby/Site/1.8/puppet/util.rb:424:in `thinmark'
/Library/Ruby/Site/1.8/puppet/transaction.rb:248:in
`eval_children_and_apply_resource'
/Library/Ruby/Site/1.8/puppet/transaction.rb:205:in `eval_resource'
/Library/Ruby/Site/1.8/puppet/transaction.rb:294:in `evaluate'
/Library/Ruby/Site/1.8/puppet/util.rb:425:in `thinmark'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/
gems/1.8/gems/activesupport-2.2.2/lib/active_support/core_ext/
benchmark.rb:8:in `realtime'
/Library/Ruby/Site/1.8/puppet/util.rb:424:in `thinmark'
/Library/Ruby/Site/1.8/puppet/transaction.rb:293:in `evaluate'
/Library/Ruby/Site/1.8/puppet/transaction.rb:287:in `collect'
/Library/Ruby/Site/1.8/puppet/transaction.rb:287:in `evaluate'
/Library/Ruby/Site/1.8/puppet/resource/catalog.rb:139:in `apply'
/Library/Ruby/Site/1.8/puppet/configurer.rb:142:in `run'
/Library/Ruby/Site/1.8/puppet/util.rb:180:in `benchmark'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/
gems/1.8/gems/activesupport-2.2.2/lib/active_support/core_ext/
benchmark.rb:8:in `realtime'
/Library/Ruby/Site/1.8/puppet/util.rb:179:in `benchmark'
/Library/Ruby/Site/1.8/puppet/configurer.rb:141:in `run'
/Library/Ruby/Site/1.8/puppet/agent.rb:53:in `run'
/Library/Ruby/Site/1.8/puppet/agent/locker.rb:21:in `lock'
/Library/Ruby/Site/1.8/puppet/agent.rb:53:in `run'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/
1.8/sync.rb:229:in `synchronize'
/Library/Ruby/Site/1.8/puppet/agent.rb:53:in `run'
/Library/Ruby/Site/1.8/puppet/agent.rb:130:in `with_client'
/Library/Ruby/Site/1.8/puppet/agent.rb:51:in `run'
/Library/Ruby/Site/1.8/puppet/application/puppetd.rb:103:in `onetime'
/Library/Ruby/Site/1.8/puppet/application.rb:226:in `send'
/Library/Ruby/Site/1.8/puppet/application.rb:226:in `run_command'
/Library/Ruby/Site/1.8/puppet/application.rb:217:in `run'
/Library/Ruby/Site/1.8/puppet/application.rb:306:in `exit_on_fail'
/Library/Ruby/Site/1.8/puppet/application.rb:217:in `run'
/usr/sbin/puppetd:159
err: //macssh/Service[com.openssh.sshd]/ensure: change from stopped to
running failed: Unable to start service: com.openssh.sshd at path: /
System/Library/LaunchDaemons/ssh.plist

grandpa

unread,
Aug 30, 2009, 10:39:46 AM8/30/09
to Puppet Users
Doing another run reveals a bit more... perhaps I missed pasting that
part previously.
Here we can see what puppet executes. If I do the same from a terminal
I get "nothing found to load".

launchctl unload -w /System/Library/LaunchDaemons/ssh.plist
then
launchctl load /System/Library/LaunchDaemons/ssh.plist

to get this to actually load from a terminal the second command needs
to include the -w switch just like unload does, like so:
launchctl load -w /System/Library/LaunchDaemons/ssh.plist

Dont understand why puppet doesn't... below is the debug/trace/verbose
output showing these commands.


debug: Puppet::Type::Service::ProviderLaunchd: Executing '/bin/
launchctl list'
debug: Service[com.openssh.sshd](provider=launchd): Executing
'launchctl unload -w /System/Library/LaunchDaemons/ssh.plist'
debug: Service[com.openssh.sshd](provider=launchd): Executing
'launchctl load /System/Library/LaunchDaemons/ssh.plist'
err: //macssh/Service[com.openssh.sshd]: Failed to call refresh on
Service[com.openssh.sshd]: Unable to start service: com.openssh.sshd
at path: /System/Library/LaunchDaemons/ssh.plist
/Library/Ruby/Site/1.8/puppet/provider/service/launchd.rb:141:in
`start'
/Library/Ruby/Site/1.8/puppet/provider/service/base.rb:50:in `restart'
/Library/Ruby/Site/1.8/puppet/type/service.rb:192:in `refresh'
/Library/Ruby/Site/1.8/puppet/transaction.rb:672:in `send'
/Library/Ruby/Site/1.8/puppet/transaction.rb:672:in `trigger'
/Library/Ruby/Site/1.8/puppet/transaction.rb:645:in `each'
/Library/Ruby/Site/1.8/puppet/transaction.rb:645:in `trigger'
/Library/Ruby/Site/1.8/puppet/transaction.rb:209:in `eval_resource'

grandpa

unread,
Aug 30, 2009, 10:57:50 AM8/30/09
to Puppet Users
I'm no ruby expert... rather I'm a complete newbie, but I found that
commenting out the places
in the launchd provider (in stop and start) where it decides whether
to use the -w switch (so it always
includes that switch) makes the problem (well, MY problem) go away.

I haven't tested this on Leopard (10.5) so I'm not sure if this is
something new to Snow Leopard. I'll try
testing this on 10.5 later. I guess I should file a bug report after
that.

Here's the diff:

--- launchd.rb
+++ (clipboard)
@@ -130,10 +130,10 @@
did_enable_job = false
cmds = []
cmds << :launchctl << :load
- if self.enabled? == :false # launchctl won't load disabled
jobs
- cmds << "-w"
- did_enable_job = true
- end
+ #if self.enabled? == :false # launchctl won't load disabled
jobs
+ cmds << "-w"
+ did_enable_job = true
+ #end
cmds << job_path
begin
execute(cmds)
@@ -152,10 +152,10 @@
did_disable_job = false
cmds = []
cmds << :launchctl << :unload
- if self.enabled? == :true # keepalive jobs can't be stopped
without disabling
- cmds << "-w"
- did_disable_job = true
- end
+ #if self.enabled? == :true # keepalive jobs can't be stopped
without disabling
+ cmds << "-w"
+ did_disable_job = true
+ #end
cmds << job_path
begin
execute(cmds)
> ...
>
> läs mer »

Nigel Kersten

unread,
Aug 30, 2009, 12:15:55 PM8/30/09
to puppet...@googlegroups.com
We need to re-do some of the way the service provider works. Your
solution isn't going to work for all cases.

Apple decided to stop using the plist to store state in, and it's all
in /var now.

Can you bug report this and assign it to me John?
--
Nigel Kersten
nig...@google.com
System Administrator
Google, Inc.

Nigel Kersten

unread,
Aug 30, 2009, 12:27:17 PM8/30/09
to puppet...@googlegroups.com
I should also add that you really want to be running 0.25.0rc1 for Snow Leopard.

The package installer is broken in 0.24.8 for SnoLo as Apple started
dereferencing mount points, and we got it fixed in 0.25.x

I can get the service issue fixed pretty quickly for 0.25.x

grandpa

unread,
Aug 30, 2009, 1:30:27 PM8/30/09
to Puppet Users
I am running 0.25rc1 from your package. Also running facter built from
a clone of your git repo(think it was on github),
since there seem to be a bug with versioning concerning 10.6 not fixed
in your package.

Thanks for providing those packages.

Puppetmaster server is running on Debian 5. Also have a few web/db etc
servers running Debian 5 - configured by puppet...

Gotta say, puppet is the greatest thing I've come across in a long
time. Thanks for all the hard work on 0.25!

I'll put in a bug report.

/John

On 30 Aug, 18:27, Nigel Kersten <nig...@google.com> wrote:
> I should also add that you really want to be running 0.25.0rc1 for Snow Leopard.
>
> The package installer is broken in 0.24.8 for SnoLo as Apple started
> dereferencing mount points, and we got it fixed in 0.25.x
>
> I can get the service issue fixed pretty quickly for 0.25.x
>
>
>
> On Sun, Aug 30, 2009 at 9:15 AM, Nigel Kersten<nig...@google.com> wrote:
> > We need to re-do some of the way the service provider works. Your
> > solution isn't going to work for all cases.
>
> > Apple decided to stop using the plist to store state in, and it's all
> > in /var now.
>
> > Can you bug report this and assign it to me John?
>
> ...
>
> läs mer »

Nigel Kersten

unread,
Aug 30, 2009, 1:34:43 PM8/30/09
to puppet...@googlegroups.com
On Sun, Aug 30, 2009 at 10:30 AM, grandpa<john.axel...@gmail.com> wrote:
>
> I am running 0.25rc1 from your package. Also running facter built from
> a clone of your git repo(think it was on github),
> since there seem to be a bug with versioning concerning 10.6 not fixed
> in your package.

Yeah. There's no released version of facter that 10.x.0 releases work for.

Either stick with an old version like 1.5.4 or get it from the
upstream repo, as the changes have actually been accepted to fix that.

James or anyone have any ideas when the next 1.5.x release of Facter is due?


>
> Thanks for providing those packages.
>
> Puppetmaster server is running on Debian 5. Also have a few web/db etc
> servers running Debian 5 - configured by puppet...
>
> Gotta say, puppet is the greatest thing I've come across in a long
> time. Thanks for all the hard work on 0.25!

woot! :)

Paul Nasrat

unread,
Aug 30, 2009, 1:41:29 PM8/30/09
to puppet...@googlegroups.com
2009/8/30 Nigel Kersten <nig...@google.com>:

>
> On Sun, Aug 30, 2009 at 10:30 AM, grandpa<john.axel...@gmail.com> wrote:
>>
>> I am running 0.25rc1 from your package. Also running facter built from
>> a clone of your git repo(think it was on github),
>> since there seem to be a bug with versioning concerning 10.6 not fixed
>> in your package.
>
> Yeah. There's no released version of facter that 10.x.0 releases work for.
>
> Either stick with an old version like 1.5.4 or get it from the
> upstream repo, as the changes have actually been accepted to fix that.
>
> James or anyone have any ideas when the next 1.5.x release of Facter is due?

If this is going to be a must have for platform support I'm not
opposed to doing one soon.

Just got back from travelling, so let me look through the 1.6.0 bug
list and see what makes sense to try and get in for 1.5.7

Paul

Nigel Kersten

unread,
Aug 31, 2009, 7:55:41 PM8/31/09
to puppet...@googlegroups.com
On Sun, Aug 30, 2009 at 6:30 AM, grandpa<john.axel...@gmail.com> wrote:
>
> Forgot to add that I'm running Snow Leopard...

I've just had a metric crapload of work get dumped on me today, so if
anyone else feels like having a look at this issue for Snow Leopard,
that would be awesome.

Essentially we have two main choices:

a) provide a completely different provider by using the new
ServiceManagement framework that is accessible from Ruby in Snow
Leopard. I've yet to look at this seriously in Ruby, but it is a far
better option than shelling out to launchctl all the time.

b) provide a slightly different code path by examining the new
locations for launchd job state in Snow Leopard (somewhere in /var)

Basically the methods that will need to be fixed are:

status
enabled?
enable
disable

I think.


Option a) is where we eventually want to be.

Allan Marcus

unread,
Sep 1, 2009, 2:49:33 PM9/1/09
to puppet...@googlegroups.com
I believe the disabled state is stored in /var/db/launchd.db/
com.apple.launchd/overrides.plist

so to bound ntp, for example:

launchctl unload "/System/Library/LaunchDaemons/org.ntp.ntpd.plist"
2> /dev/null
/usr/libexec/PlistBuddy -c "set :org.ntp.ntpd:Disabled false" /var/db/
launchd.db/com.apple.launchd/overrides.plist
launchctl load "/System/Library/LaunchDaemons/org.ntp.ntpd.plist" 2> /
dev/null

---
Thanks,

Allan Marcus
505-667-5666

Nigel Kersten

unread,
Sep 1, 2009, 5:29:13 PM9/1/09
to puppet...@googlegroups.com
yep, see:

http://groups.google.com/group/puppet-dev/browse_thread/thread/1ff894c6af240244

for a pending patch.

If you could test this, that would be awesome.

It's currently at my git repo:

http://github.com/nigelkersten/puppet/tree/tickets/0.25.x/2581

Nigel Kersten

unread,
Sep 1, 2009, 5:30:44 PM9/1/09
to puppet...@googlegroups.com
so this turned out to not be as much work as I thought it could be, as
the interaction between the disabled flag in a launchd job plist and
the overrides plist is much simpler than I thought it was, and I
decided to only support system level launchd jobs.

At some point in the future I'd like to support user launchds (ie not
root), but that's going to take a fair bit of design work first.

Allan Marcus

unread,
Sep 1, 2009, 6:14:41 PM9/1/09
to puppet...@googlegroups.com
I'm going to take my puppet-dev server (running Mac OS X server 10.5.7
and puppet 0.24.8 and upgrade it to 10.6. I will then install your
puppet and give it a try with some 24.8 clients. Then I'll try it with
some clients using your package.

---
Thanks,

Allan Marcus
505-667-5666



Nigel Kersten

unread,
Sep 1, 2009, 6:28:55 PM9/1/09
to puppet...@googlegroups.com
On Tue, Sep 1, 2009 at 3:14 PM, Allan Marcus<al...@lanl.gov> wrote:
>
> I'm going to take my puppet-dev server (running Mac OS X server 10.5.7
> and puppet 0.24.8 and upgrade it to 10.6. I will then install your
> puppet and give it a try with some 24.8 clients. Then I'll try it with
> some clients using your package.

Brilliant Allan. Much appreciated.
Reply all
Reply to author
Forward
0 new messages