Facing 401 unauthorized errors intermittently on Windows


#1

Hi,

I am trying to get the Windows VMs to run jobs similar to bootstrap. The
knife vsphere plugin wasn’t quite working. So I have a powershell script
that spawns off a VM and uses Customization spec. As part of the
customization spec, I run the following command :
“C:\opscode\chef\bin\chef-client -j C:\etc\chef\first-boot.json” . As part
of my template, I already have chef installed along with the c:\etc\chef
containing “client.rb”, " validation.pem" and “first-boot.json” .

Problem is that this seems to be working alternatively. Every 2nd time it
fails with the 401 Authorized error ( Searched for this error and I can
safely say that the various files are right). I have opened the Vmware
console a couple of times to see what happens and every time I do that I
can see that the chef run succeeds . Any suggestions around what I can do
to make this more stable?

thanks
Ranjan


#2

On Thu, Mar 29, 2012 at 10:46 AM, Madhurranjan Mohaan
maadhuuranjan.m@gmail.com wrote:

I am trying to get the Windows VMs to run jobs similar to bootstrap. The
knife vsphere plugin wasn’t quite working. So I have a powershell script
that spawns off a VM and uses Customization spec. As part of the
customization spec, I run the following command :
“C:\opscode\chef\bin\chef-client -j C:\etc\chef\first-boot.json” . As part
of my template, I already have chef installed along with the c:\etc\chef
containing “client.rb”, " validation.pem" and “first-boot.json” .

Problem is that this seems to be working alternatively. Every 2nd time it
fails with the 401 Authorized error ( Searched for this error and I can
safely say that the various files are right). I have opened the Vmware
console a couple of times to see what happens and every time I do that I can
see that the chef run succeeds . Any suggestions around what I can do to
make this more stable?

Are you sure the node_name (based on the hostname) of the VMs are all
different? The new client could be trying to register with the same
name of an existing client.

Bryan


#3

Yes they are all different. The Customization spec in Vmware doesn’t even
run if the name is present in the Domain Controller. So we are sure the
names are different.

On Fri, Mar 30, 2012 at 2:52 AM, Bryan McLellan btm@loftninjas.org wrote:

On Thu, Mar 29, 2012 at 10:46 AM, Madhurranjan Mohaan
maadhuuranjan.m@gmail.com wrote:

I am trying to get the Windows VMs to run jobs similar to bootstrap. The
knife vsphere plugin wasn’t quite working. So I have a powershell script
that spawns off a VM and uses Customization spec. As part of the
customization spec, I run the following command :
“C:\opscode\chef\bin\chef-client -j C:\etc\chef\first-boot.json” . As
part
of my template, I already have chef installed along with the c:\etc\chef
containing “client.rb”, " validation.pem" and “first-boot.json” .

Problem is that this seems to be working alternatively. Every 2nd time it
fails with the 401 Authorized error ( Searched for this error and I can
safely say that the various files are right). I have opened the Vmware
console a couple of times to see what happens and every time I do that I
can
see that the chef run succeeds . Any suggestions around what I can do
to
make this more stable?

Are you sure the node_name (based on the hostname) of the VMs are all
different? The new client could be trying to register with the same
name of an existing client.

Bryan


#4

Folks,
Had a problem with chef-server starting up on ubuntu 11.10, having followed the bootstrap process from the opscode wiki. This was tracked down to couchdb starting after the chef-server. To fix this behaviour, I did the following…

remove the existing links to start couchdb

update-rc.d -f couchdb remove

#check that no refrences to couchdb exist
ls -al /etc/rc2.d/

#check your couchd script is still there
ls -al /etc/init.d/couchdb

#setup couchdb to restart on boot (previous start/stop levels were 20, moved to 19, as chef-server starts on 20 on current ubuntu 11.10)
update-rc.d couchdb start 19 2 3 4 5 . stop 21 0 1 6 .

note the “.” dots are required

restart your box to check.

reboot

verify that chef-server is listening on port 4000

netstat -A inet -l

                                                                             regards

                                                                                          Sc0tt...

#5

On Fri, Mar 30, 2012 at 12:45 AM, Madhurranjan Mohaan
maadhuuranjan.m@gmail.com wrote:

Yes they are all different. The Customization spec in Vmware doesn’t even
run if the name is present in the Domain Controller. So we are sure the
names are different.

Perhaps the system time isn’t updated before the Chef run and is
really far off? There’s a bit of an allowed time window to help
protect against replay attacks.


#6

Folks,
Just a further follow up on the install, I had to chown the following directory, not sure if this was a problem specific to my install or something more generic. But posting it here just in case…

On the chef server (ubuntu 11.10)
chown -R chef:chef /var/lib/chef

    This was owned by root, which smaks of me doing something I should not have as "root".   

         regards

              Sc0tt....

From: RUSSELL Scott
Sent: 30 March 2012 14:49
To: chef@lists.opscode.com
Subject: chef-server fails on startup on ubuntu server 11.10…

Folks,
Had a problem with chef-server starting up on ubuntu 11.10, having followed the bootstrap process from the opscode wiki. This was tracked down to couchdb starting after the chef-server. To fix this behaviour, I did the following…

remove the existing links to start couchdb

update-rc.d -f couchdb remove

#check that no refrences to couchdb exist
ls -al /etc/rc2.d/

#check your couchd script is still there
ls -al /etc/init.d/couchdb

#setup couchdb to restart on boot (previous start/stop levels were 20, moved to 19, as chef-server starts on 20 on current ubuntu 11.10)
update-rc.d couchdb start 19 2 3 4 5 . stop 21 0 1 6 .

note the “.” dots are required

restart your box to check.

reboot

verify that chef-server is listening on port 4000

netstat -A inet -l

                                                                             regards

                                                                                          Sc0tt...