Unable to bootstrap node on windows node using chef and knife - windows

I've exhausted my options in trying to bootstrap a windows node running in azure. I have the workstation connected to my self-hosted chef server without any issues. I run the bootstrap command and get the following:
Creating new client for vm1
Creating new node for vm1
Connecting to 104.***.***.***
ERROR: Net::SSH::ConnectionTimeout: Net::SSH::ConnectionTimeout
I know the username and password are valid as well as the IP of the target node. What are my options here for debugging such a problem? I believe the necessary ports are open, unless I'm missing something special. I have telnet enabled. Does anyone have any better ideas?

To copy down from the comments, to bootstrap over WinRM you need the knife bootstrap windows winrm command.

you can also bootstrap windows machine with following command. Core Chef now supports bootstrapping Windows systems without a knife plugin
sudo knife bootstrap -o winrm <pubic_IPV4_Address/DNS_of_client_machine> -U Administrator -P '<pwd>' --node-name <node_name> --run-list 'recipe[<cookbook_name>]'
where,
pubic_IPV4_IP/DNS_of_client_machine --> Public IP address/ DNS of the client machine.
node_name --> String representing node name.
cookbook_name --> Cookbook that we want to execute on client machine.
pwd --> password to connect with windows client machine
Note: Make sure to execute above command from ~/chef-repo/.chef/ directory.
If you are unable to execute above command with -o winrm option then install below gem packages
chef gem install winrm
chef gem install knife-windows

Related

Can a Chef Server have multiple workstations?

We have a predefined configuration of the infrastructure where the nodes have a particular runlist of recipes controlled using a central Chef server and workstation.
I want to implement a knife command to force a deploy recipe to be run on all the nodes. Is it possible just to run the knife -o recipe command from a new workstation and let the server sync all the recipes from the central workstation itself?
Yes, you can use multiple workstations, but not quite the way you describe. When you push a cookbook (or policy) it gets uploaded into the Chef Server. All client nodes only talk to your Chef Server, not the workstation. That includes cookbooks and run lists (unless overridden with -o as you noted). So you can run knife ssh somequery sudo chef-client from any workstation any have it function the same.

Opscode Chef Server / Workstation force commands from server

Background : Chef Server Version 12 and a Windows workstation SDK 0.10 targeting windows nodes
I've created recipes and bootstrapped local windows servers into the Chef manager and applied recipes so the very basics are all working.
Question : when running the bootstrap commands for a hosted server (e.g azure / aws) I need the command to come from the Chef Server not the workstation.
I had hoped that the knife.rb with the Chef_server_url would force all commands to come from there.
WireShark shows the WinRM connections trying to come from my workstation.
Is there any setting I can implement that forces this in the knife.rb or elsewhere?
I had tried to add the following from searches but they've not been successful :
chef_zero.enabled false
local_mode false
Is this resolved through Chef Provisioning rather than Chef knife commands?
many thanks in advance for any assistance you can give.
"when running the bootstrap commands for a hosted server (e.g azure / aws) I need the command to come from the Chef Server not the workstation." is not correct. Knife commands that manipulate servers go directly from your workstation, and this is how it is supposed to work. The way the bootstrap functions is it starts the cloud machine using the relevant provider API, then connects to the new VM via SSH or WinRM and installs Chef, and then launches chef-client using a configuration file based on your knife settings (this is where chef_server_url comes in).

Capistrano error : could not connect to ssh-agent

I'm using Bedrock with Capistrano deploys.
When I use command bundle exec cap staging deploy:check I get an authentication error :
...
D, [2015-05-09T15:39:53.878464 #15636] DEBUG -- net.ssh.authentication.session[1e34a58]: trying publickey
D, [2015-05-09T15:39:53.878464 #15636] DEBUG -- net.ssh.authentication.agent[1e30d2c]: connecting to ssh-agent
E, [2015-05-09T15:39:53.879447 #15636] ERROR -- net.ssh.authentication.agent[1e30d2c]: could not connect to ssh-agent
E, [2015-05-09T15:39:53.879447 #15636] ERROR -- net.ssh.authentication.session[1e34a58]: all authorization methods failed (tried publickey)
cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing as deploy#SERVER_IP: Authentication failed for user deploy#SERVER_IP
Tasks: TOP => git:check => git:wrapper
Capistrano could not connect to ssh-agent on my server.
But I can log in on my server via SSH like this ssh deploy#SERVER_IP without password. I dit all the instructions in Capistrano Authentication & Authorisation Docs page, so I can use command like me#localhost $ ssh deploy#one-of-my-servers.com 'hostname; uptime'.
If I enter command ssh -A deploy#SERVER_IP 'env | grep SSH_AUTH_SOCK' I get result
SSH_AUTH_SOCK=/tmp/ssh-UweQkw7578/agent.7578
Here is my deploy.rb file :
set :application, 'APP'
set :repo_url, 'URL'
set :branch, :master
set :tmp_dir, '~/tmp'
set :log_level, :info
set :linked_files, fetch(:linked_files, []).push('.env')
set :linked_dirs, fetch(:linked_dirs, []).push('web/app/uploads')
Here is my staging.rb file :
set :stage, :staging
set :deploy_to, -> { "/var/www/vhosts/project/dev" }
server 'SERVER_IP', user: 'deploy', roles: %w{web app}
set :ssh_options, {
user: 'deploy',
keys: %w('/c/Users/alexander/.ssh/id_rsa'),
forward_agent: true,
auth_methods: %w(publickey),
verbose: :debug
}
fetch(:default_env).merge!(wp_env: :staging)
Apache's agent forwarding agent instruction is enabled in sshd_config file : AllowAgentForwarding yes
What should do with my config files to make my deploy work?
Windows 8.1
Ruby 2.2.0
Capistrano 3.2.1
Git Bash
OK so I had the same issue, and I spent way too long working out exactly what is happening here, and the upshot is -
for ruby on windows, you must run pagent, not ssh-agent, for Capistrano and agent forwarding to work - in fact pretty much any tool that uses the Ruby net-ssh library on Windows.
And I dont think that will change, at least not for a while.
Agent Forwarding
See An Illustrated Guide to SSH Agent Forwarding for more about agent forwarding, and how the key challenge ends back up on our workstation.
Terminology
workstation - the machine (Windowa server/desktop/laptop) our SSH
client software is running from, and, most importantly, our PKI
private key is stored on (with or without a passphrase)
deployment node - the target of our Capistrano deployment task, most
like defined in the 'server' key in our config/deploy.rb, or
config/deploy/.rb file
git repo - where we will pull the code from, first queried via "git
ls-remote" - we will access this git repo via SSH, and the deployment
node will use agent forwarding to pass the key challenge back to the
workstation
SSH client software - how we reach out to sshd on remote servers, and
which has access to our private key. Might be putty, an OpenSSH ssh
client or the net-ssh library in Ruby.
Setup
I have a Windows 7 workstation box, with Git-Bash, and its OpenSSH ssh client, plus the script from Joe Reagle that sets up some environmental variables that say which port and pid the ssh-agent is operating on.
I also have Putty and Pageant, but I focussed, initially, on just the OpenSSH/Git-Bash tools.
I have set up passwordless ssh from the workstation to the deployment node, I have the ssh-agent running, I have my key added through ssh-add, and I have my public key registered as a read-only access key to the git repo.
Basics
So we are trying to use SSH agent forwarding to have Capistrano pull from our Git repo onto our deployment node.
Now we can test this all ourselves by setting up our public SSH key on the deployment node and using, say, the OpenSSH ssh client, to confirm we have passwordless ssh working. Then we can setup ssh-agent by
starting ssh-agent and setting the SSH_AUTH_SOCK and SSH_AGENT_PID as required.
adding our private key to the ssh-agent via ssh-add
add our public key as an authorised key to the git repo
ssh to the deployment node, and from there do a "git ls-remote git#" (or a ssh -T git#)
If everything is setup correctly, this will all work, and so we will think "ok I can do a 'cap deploy:check'" - and it will fail.
What Went Wrong
We will get an error
"Error reading response length from authentication socket"
Who is telling us this ? It isnt immediately clear, but it
isn't the git repo
it isnt the git client on the deployment node
it isnt the sshd daemon on the deployment node, that wants to pass the key challenge back to the workstation.
Its the Ruby ssh client library on the workstation.
How do we know this
In the ssh_options hash in the deploy.rb file, we add the following :
verbose: :debug
When we do this we see this message
Pageant not running.
Why is Capistrano trying to use Pageant instead of ssh-agent
When running via Capistrano, the ssh client is different to the one you used when verifying things by hand.
When verifying by hand, it was an OpenSSH ssh client. Now it is the net-ssh library in Ruby.
And on Windows, net-ssh has these lines
if Net::SSH::Authentication::PLATFORM == :win32
require 'net/ssh/authentication/pageant'
end
or
case Net::SSH::Authentication::PLATFORM
when :java_win32
require 'net/ssh/authentication/agent/java_pageant'
else
require 'net/ssh/authentication/agent/socket'
So loading pageant is hard-coded into net-ssh. It doesnt even try to see if you are running under a unix-like shell (like git-bash or cygwin), and to then use the unix-domain ssh-agent SSH_AUTH_SOCK
At present net-ssh doesnt try to open a unix-domain named socket. In theory I think it could, through the UNIXSocket class in the stdlib. But I haven't experimented with that on a Windows machine yet.

Configure TCP endpoint when vagrant up or reload

I'm using Vagrant to run an Ubuntu VM with Microsoft Azure provider, but I need to create an endpoint on this VM.
I've done it installing azure command-line tools with
npm install azure-cli -g
and after that
azure vm endpoint create {VM-Name} 80 8080
VM is running fine without problems. But I don't want to configure the endpoint manually anymore. I would like to create it when I run vagrant up. I don't want to use vagrant provision, because this shell instruction should not be executed in my VM, but in my physical machine.
There is no options such as verbose in vagrant, which would have permitted me to see what it really does with the Vagrantfile, and what I should do to implement a shell command like this one in it.
Ansver to initial question, do the following:
in vagrantfile add following string in azure provider section:
azure.tcp_endpoints = '80:8080'
hope this help.
answer to your question about verbose output:
you may run vagrant up --provider=azure --debug
for additional debug information.
if you need to run local scripts you may try to use vagrant-triggers plugin

How to install an OpenLDAP service running on non default port?

I have a production LDAP server running on 389 and I want to install another OpenLDAP for test purpose on port 10389.
I am wondering how to install the OpenLDAP daemon as a windows service that will run on another port than 389.
Note: I cannot use the slapd install as I already have this service installed...
Well, I installed NSSM that can run any kind of executable as a service.
I have created a batch file with the appropriate options and now I have Open LDAP running as a service on a non default port.

Resources