Chef-client and HTTPServerException: 401 "Unauthorized"


#1

Hi,

I need to booststap an node and I do not want to use knife.

I have a script that installed chef and then I run chef client as follows.

chef-client -E development -K /etc/chef/ips1-validator.pem -N
Tracker_east_development_1_2_1339695020 -j /etc/chef/first-boot.json

  1. the ips1-validator.pem is correct. It is placed in /etc/chef
  2. Here is my client.rb that is in /etc/chef

log_level :info
log_location STDOUT
chef_server_url "https://api.opscode.com/organizations/ips1"
validation_client_name "ips1-validator"
validation_key “/etc/chef/ips1-validator.pem”

  1. Here is the first-boot.json
    {“run_list”:[“role[nginx_server]”]}

Given that it appears that I did everything correct, why do I get the
below error? This randomly works or fails. The node name is based on
a time stamp.

root@ip-10-29-173-111:/home/ubuntu# chef-client -E development -K
/etc/chef/ips1-validator.pem -N
Tracker_east_development_1_2_1339695020 -j /etc/chef/first-boot.json
[Thu, 14 Jun 2012 17:41:28 +0000] INFO: *** Chef 0.10.10 ***
[Thu, 14 Jun 2012 17:41:30 +0000] FATAL: Stacktrace dumped to
/var/chef/cache/chef-stacktrace.out
[Thu, 14 Jun 2012 17:41:30 +0000] FATAL: Net::HTTPServerException: 401
"Unauthorized"

My bash script for installing chef is the below

mkdir /etc/chef
cp /tmp/ips1-validator.pem /etc/chef
cp /tmp/client.rb /etc/chef
cp /tmp/first-boot.json /etc/chef
echo "deb http://apt.opscode.com/ `lsb_release -cs`-0.10 main" |

sudo tee /etc/apt/sources.list.d/opscode.list
mkdir -p /etc/apt/trusted.gpg.d
gpg --keyserver keys.gnupg.net --recv-keys 83EF826A
gpg --export packages@opscode.com | sudo tee
/etc/apt/trusted.gpg.d/opscode-keyring.gpg > /dev/null
sudo apt-get -y update
sudo apt-get -y install opscode-keyring
sudo apt-get -y upgrade
echo “chef chef/chef_server_url string
https://api.opscode.com/organizations/ips1” | sudo
debconf-set-selections && sudo apt-get install chef -y


#2

One problem is the key server randomly fails. I spent a few days on this one and ended up just putting the key in my script and doing a local import directly.

Joshua

gpg --keyserver keys.gnupg.net --recv-keys 83EF826A
gpg --export packages@opscode.com | sudo tee

On Jun 16, 2012, at 8:08 AM, David Montgomery davidmontgomery@gmail.com wrote:

gpg --keyserver keys.gnupg.net --recv-keys 83EF826A
gpg --export packages@opscode.com | sudo tee


#3

Wow…why does the key randomly fail? Does anybody have a clue? It
should never fail.

What do you mean doing a local import directly?

On Sun, Jun 17, 2012 at 12:52 AM, Joshua Miller jassinpain@gmail.com wrote:

One problem is the key server randomly fails. I spent a few days on this
one and ended up just putting the key in my script and doing a local import
directly.

Joshua

gpg --keyserver keys.gnupg.net --recv-keys 83EF826A
gpg --export packages@opscode.com | sudo tee

On Jun 16, 2012, at 8:08 AM, David Montgomery davidmontgomery@gmail.com
wrote:

gpg --keyserver keys.gnupg.net --recv-keys 83EF826A
gpg --export packages@opscode.com | sudo tee


#4

On Sat, Jun 16, 2012 at 6:56 PM, David Montgomery
davidmontgomery@gmail.com wrote:

Wow…why does the key randomly fail? Does anybody have a clue? It
should never fail.

Possibly internet connection glitches, keyserver issues… Everything
can be expected when you are dealing with network.

In general,

set -e

is a very good practice for those kind of scripts. And make sure that
when the setup script fails at any point, you know.

What do you mean doing a local import directly?

He probably means copying the key together with the shell script.
i.e. do gpg --export packages@opscode.com >
/etc/apt/trusted.gpg.d/opscode-keyring.gpg once, and put the file to
the node before setting the node up.


Motiejus Jakštys


#5

Thanks,

I dont know know set -e …what is it and how I use it?

What I do have is a time out, for the script, if taking longer the
usual the kill the boot and start again.

On Sun, Jun 17, 2012 at 1:44 AM, Motiejus Jakštys desired.mta@gmail.com wrote:

On Sat, Jun 16, 2012 at 6:56 PM, David Montgomery
davidmontgomery@gmail.com wrote:

Wow…why does the key randomly fail? Does anybody have a clue? It
should never fail.

Possibly internet connection glitches, keyserver issues… Everything
can be expected when you are dealing with network.

In general,

set -e

is a very good practice for those kind of scripts. And make sure that
when the setup script fails at any point, you know.

What do you mean doing a local import directly?

He probably means copying the key together with the shell script.
i.e. do gpg --export packages@opscode.com >
/etc/apt/trusted.gpg.d/opscode-keyring.gpg once, and put the file to
the node before setting the node up.


Motiejus Jakštys


#6

On Sat, Jun 16, 2012 at 7:59 PM, David Montgomery
davidmontgomery@gmail.com wrote:

Thanks,

I dont know know set -e …what is it and how I use it?

What I do have is a time out, for the script, if taking longer the
usual the kill the boot and start again.

From BASH(1)

         -e      Exit  immediately if a pipeline (which may
                  consist of a single  simple  command),   a
                  subshell  command enclosed in parentheses,
                  or one of the commands executed as part of
                  a  command  list  enclosed  by braces (see
                  SHELL GRAMMAR above) exits with a non-zero
                  status.   The  shell  does not exit if the
                  command that fails is part of the  command
                  list  immediately  following  a  while  or
                  until keyword, part of the test  following
                  the if or elif reserved words, part of any
                  command executed in a && or ⎪⎪ list except
                  the  command following the final && or ⎪⎪,
                  any command in a pipeline but the last, or
                  if  the  command's  return  value is being
                  inverted with !.  A trap on ERR,  if  set,
                  is  executed before the shell exits.  This
                  option applies to  the  shell  environment
                  and  each  subshell environment separately
                  (see COMMAND EXECUTION ENVIRONMENT above),
                  and  may  cause  subshells  to exit before
                  executing all the  commands  in  the  sub‐
                  shell.

In other words, exit if some command fails in the script. Safer than
timeout, because some commands might finish exeting with error instead
of timing out.


Motiejus Jakštys