Starting a chef client from a workstation

Question

I already installed the chef server on one of my Ubuntu 12.04 OS. The second ubuntu machine runs a client chef, which I use as a workstation to manage other nodes.

So, let's define the nomenclature as follows: Chef: S Workstation: W Chefs N1, N2 ...

I downloaded the node N1 chef from the W workstation using the chef boot box as indicated here http://wiki.opscode.com/display/chef/Client+Bootstrap+Fast+Start+Guide

After that, I try to run the chef-client command on N1 from my workstation W. I use the following command:

knife ssh name:chefNode -x ubuntu -P password "sudo chef-client" 

This results in an error: ERROR: Server error for http://ec2-XX-XX-XX-XXX.compute-1.amazonaws.com:4000/search/node?=name:chefNode&sort=X_CHEF_id_CHEF_X%20asc&start=0 & rows = 1000, retry 5/5 in 58s ERROR: internal server error

Any help or hint appreciated. Please reply

Answer 1

Check your rabbitmq server. See if it is configured correctly or not.

To configure the launch of these

rabbitmqctl add_vhost / chef

check chef rabbitmqctl add_user

rabbitmqctl set_permissions -p / chef chef "." "" * "

Departure

http://wiki.opscode.com/display/chef/Chef+Indexer

Use sudo if you are not a root user.

Add this line to the sever.rb file, which should be located in the / etc / chef folder

amqp_pass "testing"

Restart the rabbitmq-server service and everything should work

Answer 2

The "knife ssh" command uses the chef search function. The link to the Chef Indexer , which was suggested by @Manak Wadhwa, says:

The chef's indexer consists of the RabbitMQ message queue, chef-expander, which extracts messages from the queue and formats them, and chef-solr is a thin shell around Solr.

So, you can also check if chef-solr and chef-expander work and work. Ensure that all configuration files have the correct server IP addresses for each component:

- Chef Server


- Chef configuration settings (check solr.rb and server.rb)

Try a simple search from your workstation, for example: knife search node "*:*" or even knife status (the status of the knife uses search) to get a list of all the nodes. I would prefer the status of a knife, as it will return a list of all nodes, while a knife search will return all nodes as objects, and this will not help if you have many nodes. In any case, if the result is a list of all the nodes you have, then the search works as it should. If so, then the next thing I will try is to rebuild the index with:
knife index rebuild -y from the workstation or modify maxFieldLength in the solrconfig.xml file, as described in more detail below (2).

Two other links for checking with troubleshooting: 1. nodes [of the chef] that do not appear in the status of "knife" , where people in the list of options try to execute the command knife index rebuild -y to rebuild the search index and check related with cache-solr directories permissions.

2. CHEF-2346 , where they talk about maxFieldLength in solr for systems that produce large amounts of index data. Indexing data, as you probably already know, is data obtained from ohai and all attributes, nodes, databases, etc. The case I had was with all my window systems, as with most other people. (The reason I also provide this link is because I cannot estimate the amount of your indexing data.) LDAP, for example, can generate a large amount of data. Of course, if you have large amounts of data in your case, you can disable several ohai plugins if you do not need them. (Disable Ohai plugins.)

Answer 3

Good practice when debugging problems with Chef Server and Co, I found by looking at server logs. For Chef Server 11, you just do it with

 $ sudo chef-server-ctl tail 

or

 $ sudo chef-server-ctl [<service name>] tail 

For this specific task I would do

 $ sudo chef-server-ctl erchef tail 

You can see answers to requests and a short message about what is happening with the error in msg = [...]

In addition, to debug problems encountered when working with a knife, I would set

 log_level :debug 

in knife.rb.