Force service start at end of recipe


#1

Besides putting :immediately on the service restart notifies in the template commands, is there a way to force a new service to start at the end of a recipe?

My problem is I have a recipe that correctly installs ldap authentication for the OS, but since it doesn’t immediately start the client daemon, subsequent recipes fail when they reference users defined in the ldap directory. Any pointers are greatly appreciated.

-J

Sent via iPhone

Is your e-mail Premiere?


#2

You can add a simple:

service “YOUR-DAEMON-HERE” do
action :start
end

Or similar to the end of the LDAP client recipe, to ensure it gets started.

On Fri, May 13, 2011 at 9:57 AM, Jason J. W. Williams
jasonjwwilliams@gmail.com wrote:

Besides putting :immediately on the service restart notifies in the template commands, is there a way to force a new service to start at the end of a recipe?

My problem is I have a recipe that correctly installs ldap authentication for the OS, but since it doesn’t immediately start the client daemon, subsequent recipes fail when they reference users defined in the ldap directory. Any pointers are greatly appreciated.

-J

Sent via iPhone

Is your e-mail Premiere?


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#3

Hi Adam,

Hmm…that’s weird then. I’ve already got those services defined with :start…

service “nscd” do
action [:enable, :start]
supports :restart => true, :reload => true
end

service “nslcd” do
action [:enable, :start]
supports :restart => true, :reload => true
en

-J

On Fri, May 13, 2011 at 11:18 AM, Adam Jacob adam@opscode.com wrote:

You can add a simple:

service “YOUR-DAEMON-HERE” do
action :start
end

Or similar to the end of the LDAP client recipe, to ensure it gets started.

On Fri, May 13, 2011 at 9:57 AM, Jason J. W. Williams
jasonjwwilliams@gmail.com wrote:

Besides putting :immediately on the service restart notifies in the template commands, is there a way to force a new service to start at the end of a recipe?

My problem is I have a recipe that correctly installs ldap authentication for the OS, but since it doesn’t immediately start the client daemon, subsequent recipes fail when they reference users defined in the ldap directory. Any pointers are greatly appreciated.

-J

Sent via iPhone

Is your e-mail Premiere?


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#4

Hi Adam,

Well…it looks like the services are starting, however Chef still
bombs out with this error that it can’t find the user:
https://gist.github.com/971425

This only seems to happen during bootstrapping a system. It loads my
ldap_auth recipe and later my redis recipe (which crashes complaining
it can’t find the redis user). If I run "getent passwd | grep redis"
before it hits the redis cookbook (but after it runs the ldap_auth
cookbook) the system shows it is seeing the user:

redis:*:997:997:redis:<redacted_path>:/bin/false

However, I still get the error:

/usr/lib/ruby/1.8/chef/provider/file.rb:82:in `getpwnam’: can’t find
user for redis

Now if I run chef-client again manually after the failed bootstrap,
the redis recipe completes successfully (it’s almost as if Chef is
caching the user/group list at the start of the run). Any help is
greatly appreciated.

-J

On Fri, May 13, 2011 at 11:18 AM, Adam Jacob adam@opscode.com wrote:

You can add a simple:

service “YOUR-DAEMON-HERE” do
action :start
end

Or similar to the end of the LDAP client recipe, to ensure it gets started.

On Fri, May 13, 2011 at 9:57 AM, Jason J. W. Williams
jasonjwwilliams@gmail.com wrote:

Besides putting :immediately on the service restart notifies in the template commands, is there a way to force a new service to start at the end of a recipe?

My problem is I have a recipe that correctly installs ldap authentication for the OS, but since it doesn’t immediately start the client daemon, subsequent recipes fail when they reference users defined in the ldap directory. Any pointers are greatly appreciated.

-J

Sent via iPhone

Is your e-mail Premiere?


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#5

Chef isn’t caching it, but RedHat/CentOS is:

http://tickets.opscode.com/browse/CHEF-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16783#comment-16783

Best,
Adam

On Fri, May 13, 2011 at 3:38 PM, Jason J. W. Williams
jasonjwwilliams@gmail.com wrote:

Hi Adam,

Well…it looks like the services are starting, however Chef still
bombs out with this error that it can’t find the user:
https://gist.github.com/971425

This only seems to happen during bootstrapping a system. It loads my
ldap_auth recipe and later my redis recipe (which crashes complaining
it can’t find the redis user). If I run "getent passwd | grep redis"
before it hits the redis cookbook (but after it runs the ldap_auth
cookbook) the system shows it is seeing the user:

redis:*:997:997:redis:<redacted_path>:/bin/false

However, I still get the error:

/usr/lib/ruby/1.8/chef/provider/file.rb:82:in `getpwnam’: can’t find
user for redis

Now if I run chef-client again manually after the failed bootstrap,
the redis recipe completes successfully (it’s almost as if Chef is
caching the user/group list at the start of the run). Any help is
greatly appreciated.

-J

On Fri, May 13, 2011 at 11:18 AM, Adam Jacob adam@opscode.com wrote:

You can add a simple:

service “YOUR-DAEMON-HERE” do
action :start
end

Or similar to the end of the LDAP client recipe, to ensure it gets started.

On Fri, May 13, 2011 at 9:57 AM, Jason J. W. Williams
jasonjwwilliams@gmail.com wrote:

Besides putting :immediately on the service restart notifies in the template commands, is there a way to force a new service to start at the end of a recipe?

My problem is I have a recipe that correctly installs ldap authentication for the OS, but since it doesn’t immediately start the client daemon, subsequent recipes fail when they reference users defined in the ldap directory. Any pointers are greatly appreciated.

-J

Sent via iPhone

Is your e-mail Premiere?


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#6

Hi Adam,

Was actually just getting ready to write back. I’d discovered the same thing in the linux man page for nsswitch.conf(5):

“Within each process that uses nsswitch.conf, the entire file is read only once; if the file is later changed, the process will continue using the old configuration.
With Solaris, it isn’t possible to link programs using the NSS Service statically. With Linux, this is no problem.”

Thinking about writing a knife plugin that wraps bootstrap to call once with the first cookbook in the run list and then connect a second time to run chef-client after adding the rest of the cookbooks to the run list.

Thank you very much for your help.

-J

Sent via iPhone

Is your e-mail Premiere?

On May 13, 2011, at 21:54, Adam Jacob adam@opscode.com wrote:

Chef isn’t caching it, but RedHat/CentOS is:

http://tickets.opscode.com/browse/CHEF-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16783#comment-16783

Best,
Adam

On Fri, May 13, 2011 at 3:38 PM, Jason J. W. Williams
jasonjwwilliams@gmail.com wrote:

Hi Adam,

Well…it looks like the services are starting, however Chef still
bombs out with this error that it can’t find the user:
https://gist.github.com/971425

This only seems to happen during bootstrapping a system. It loads my
ldap_auth recipe and later my redis recipe (which crashes complaining
it can’t find the redis user). If I run "getent passwd | grep redis"
before it hits the redis cookbook (but after it runs the ldap_auth
cookbook) the system shows it is seeing the user:

redis:*:997:997:redis:<redacted_path>:/bin/false

However, I still get the error:

/usr/lib/ruby/1.8/chef/provider/file.rb:82:in `getpwnam’: can’t find
user for redis

Now if I run chef-client again manually after the failed bootstrap,
the redis recipe completes successfully (it’s almost as if Chef is
caching the user/group list at the start of the run). Any help is
greatly appreciated.

-J

On Fri, May 13, 2011 at 11:18 AM, Adam Jacob adam@opscode.com wrote:

You can add a simple:

service “YOUR-DAEMON-HERE” do
action :start
end

Or similar to the end of the LDAP client recipe, to ensure it gets started.

On Fri, May 13, 2011 at 9:57 AM, Jason J. W. Williams
jasonjwwilliams@gmail.com wrote:

Besides putting :immediately on the service restart notifies in the template commands, is there a way to force a new service to start at the end of a recipe?

My problem is I have a recipe that correctly installs ldap authentication for the OS, but since it doesn’t immediately start the client daemon, subsequent recipes fail when they reference users defined in the ldap directory. Any pointers are greatly appreciated.

-J

Sent via iPhone

Is your e-mail Premiere?


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#7

You can work around this by doing the installation during the compile phase,
or by creating the user account yourself rather than waiting for the RPM to
do it.

On Fri, May 13, 2011 at 5:38 PM, Jason J. W. Williams <
jasonjwwilliams@gmail.com> wrote:

Hi Adam,

Well…it looks like the services are starting, however Chef still
bombs out with this error that it can’t find the user:
https://gist.github.com/971425

This only seems to happen during bootstrapping a system. It loads my
ldap_auth recipe and later my redis recipe (which crashes complaining
it can’t find the redis user). If I run "getent passwd | grep redis"
before it hits the redis cookbook (but after it runs the ldap_auth
cookbook) the system shows it is seeing the user:

redis:*:997:997:redis:<redacted_path>:/bin/false

However, I still get the error:

/usr/lib/ruby/1.8/chef/provider/file.rb:82:in `getpwnam’: can’t find
user for redis

Now if I run chef-client again manually after the failed bootstrap,
the redis recipe completes successfully (it’s almost as if Chef is
caching the user/group list at the start of the run). Any help is
greatly appreciated.

-J

On Fri, May 13, 2011 at 11:18 AM, Adam Jacob adam@opscode.com wrote:

You can add a simple:

service “YOUR-DAEMON-HERE” do
action :start
end

Or similar to the end of the LDAP client recipe, to ensure it gets
started.

On Fri, May 13, 2011 at 9:57 AM, Jason J. W. Williams
jasonjwwilliams@gmail.com wrote:

Besides putting :immediately on the service restart notifies in the
template commands, is there a way to force a new service to start at the end
of a recipe?

My problem is I have a recipe that correctly installs ldap
authentication for the OS, but since it doesn’t immediately start the client
daemon, subsequent recipes fail when they reference users defined in the
ldap directory. Any pointers are greatly appreciated.

-J

Sent via iPhone

Is your e-mail Premiere?


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#8

An easier way would be to just call the code that’s in the ticket I
linked earlier, so that the new data is available instantly.

Adam

On Fri, May 13, 2011 at 9:35 PM, Jason J. W. Williams
jasonjwwilliams@gmail.com wrote:

Hi Adam,

Was actually just getting ready to write back. I’d discovered the same thing in the linux man page for nsswitch.conf(5):

“Within each process that uses nsswitch.conf, the entire file is read only once; if the file is later changed, the process will continue using the old configuration.
With Solaris, it isn’t possible to link programs using the NSS Service statically. With Linux, this is no problem.”

Thinking about writing a knife plugin that wraps bootstrap to call once with the first cookbook in the run list and then connect a second time to run chef-client after adding the rest of the cookbooks to the run list.

Thank you very much for your help.

-J

Sent via iPhone

Is your e-mail Premiere?

On May 13, 2011, at 21:54, Adam Jacob adam@opscode.com wrote:

Chef isn’t caching it, but RedHat/CentOS is:

http://tickets.opscode.com/browse/CHEF-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16783#comment-16783

Best,
Adam

On Fri, May 13, 2011 at 3:38 PM, Jason J. W. Williams
jasonjwwilliams@gmail.com wrote:

Hi Adam,

Well…it looks like the services are starting, however Chef still
bombs out with this error that it can’t find the user:
https://gist.github.com/971425

This only seems to happen during bootstrapping a system. It loads my
ldap_auth recipe and later my redis recipe (which crashes complaining
it can’t find the redis user). If I run "getent passwd | grep redis"
before it hits the redis cookbook (but after it runs the ldap_auth
cookbook) the system shows it is seeing the user:

redis:*:997:997:redis:<redacted_path>:/bin/false

However, I still get the error:

/usr/lib/ruby/1.8/chef/provider/file.rb:82:in `getpwnam’: can’t find
user for redis

Now if I run chef-client again manually after the failed bootstrap,
the redis recipe completes successfully (it’s almost as if Chef is
caching the user/group list at the start of the run). Any help is
greatly appreciated.

-J

On Fri, May 13, 2011 at 11:18 AM, Adam Jacob adam@opscode.com wrote:

You can add a simple:

service “YOUR-DAEMON-HERE” do
action :start
end

Or similar to the end of the LDAP client recipe, to ensure it gets started.

On Fri, May 13, 2011 at 9:57 AM, Jason J. W. Williams
jasonjwwilliams@gmail.com wrote:

Besides putting :immediately on the service restart notifies in the template commands, is there a way to force a new service to start at the end of a recipe?

My problem is I have a recipe that correctly installs ldap authentication for the OS, but since it doesn’t immediately start the client daemon, subsequent recipes fail when they reference users defined in the ldap directory. Any pointers are greatly appreciated.

-J

Sent via iPhone

Is your e-mail Premiere?


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#9

The problem is not waiting for the the rpm. This is a tarball install and the account is already in ldap. The issue is chef-client can’t get refreshed look at nsswitch.conf to know to check LDAP.

-J

Sent via iPhone

Is your e-mail Premiere?

On May 13, 2011, at 22:39, Charles Duffy charles@dyfis.net wrote:

You can work around this by doing the installation during the compile phase, or by creating the user account yourself rather than waiting for the RPM to do it.

On Fri, May 13, 2011 at 5:38 PM, Jason J. W. Williams jasonjwwilliams@gmail.com wrote:
Hi Adam,

Well…it looks like the services are starting, however Chef still
bombs out with this error that it can’t find the user:
https://gist.github.com/971425

This only seems to happen during bootstrapping a system. It loads my
ldap_auth recipe and later my redis recipe (which crashes complaining
it can’t find the redis user). If I run "getent passwd | grep redis"
before it hits the redis cookbook (but after it runs the ldap_auth
cookbook) the system shows it is seeing the user:

redis:*:997:997:redis:<redacted_path>:/bin/false

However, I still get the error:

/usr/lib/ruby/1.8/chef/provider/file.rb:82:in `getpwnam’: can’t find
user for redis

Now if I run chef-client again manually after the failed bootstrap,
the redis recipe completes successfully (it’s almost as if Chef is
caching the user/group list at the start of the run). Any help is
greatly appreciated.

-J

On Fri, May 13, 2011 at 11:18 AM, Adam Jacob adam@opscode.com wrote:

You can add a simple:

service “YOUR-DAEMON-HERE” do
action :start
end

Or similar to the end of the LDAP client recipe, to ensure it gets started.

On Fri, May 13, 2011 at 9:57 AM, Jason J. W. Williams
jasonjwwilliams@gmail.com wrote:

Besides putting :immediately on the service restart notifies in the template commands, is there a way to force a new service to start at the end of a recipe?

My problem is I have a recipe that correctly installs ldap authentication for the OS, but since it doesn’t immediately start the client daemon, subsequent recipes fail when they reference users defined in the ldap directory. Any pointers are greatly appreciated.

-J

Sent via iPhone

Is your e-mail Premiere?


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#10

Hi Adam,

On Fri, May 13, 2011 at 10:47 PM, Adam Jacob adam@opscode.com wrote:

An easier way would be to just call the code that’s in the ticket I
linked earlier, so that the new data is available instantly.

That doesn’t appear to be a solution for changing nsswitch.conf. I’ve
added the following to my ldap_auth recipe (along with a notifies
trigger on the nsswitch.conf template definition):

ruby_block “reset nss lists” do
action :nothing
block do
Etc.endgrent
Etc.endpwent
end
end

While those calls close /etc/group and /etc/passwd forcing a reload of
their contents, they don’t force a reload of nsswitch.conf…which is
what is needed for the NSS libraries to pickup that they need to start
looking in LDAP.

-J


#11

On Tue, May 17, 2011 at 9:42 AM, Jason J. W. Williams
jasonjwwilliams@gmail.com wrote:

While those calls close /etc/group and /etc/passwd forcing a reload of
their contents, they don’t force a reload of nsswitch.conf…which is
what is needed for the NSS libraries to pickup that they need to start
looking in LDAP.

Ahh, you’re totally right. I have a sneaking suspicion you’ll need to
fork/exec to get the new data…

Adam


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#12

Ahh, you’re totally right. I have a sneaking suspicion you’ll need to
fork/exec to get the new data…

Yeah…so I think I’m stuck with a double bootstrap arrangement of some sort.

-J


#13

On Tue, May 17, 2011 at 11:00 AM, Jason J. W. Williams
jasonjwwilliams@gmail.com wrote:

Ahh, you’re totally right. I have a sneaking suspicion you’ll need to
fork/exec to get the new data…

Yeah…so I think I’m stuck with a double bootstrap arrangement of some sort.

Well, let’s try this.

ruby_block “crazy” do
block do
if fork
exit 0
end
end
end

Things will get weird from there - but let’s see if a simple fork will
force the new nsswitch read.

Adam


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#14

Things will get weird from there - but let’s see if a simple fork will
force the new nsswitch read.

Yeah things get a little wierd:

192.168.241.138 [Tue, 17 May 2011 21:32:39 +0000] INFO: Processing
ruby_block[crazy] action create (ldap_auth::default line 14)
192.168.241.138 [Tue, 17 May 2011 21:32:39 +0000] ERROR: Running
exception handlers
192.168.241.138 [Tue, 17 May 2011 21:32:39 +0000] INFO: ruby_block[crazy] called
192.168.241.138 [Tue, 17 May 2011 21:32:39 +0000] INFO: Processing
remote_file[/var/cache/chef/nslcd_0.7.13_amd64.deb] action create
(ldap_auth::default line 42)
192.168.241.138 [Tue, 17 May 2011 21:32:39 +0000] FATAL: Saving node
information to /var/cache/chef/failed-run-data.json
192.168.241.138 [Tue, 17 May 2011 21:32:39 +0000] ERROR: Exception
handlers complete
192.168.241.138 [Tue, 17 May 2011 21:32:39 +0000] INFO: SIGHUP
received, reconfiguring

I’ve got a private gist for failed-run-data.json, I’ll send you separately.

-J