knife cluster kick fails when options -x ubuntu -i knife/credentials/ec2_keys/<cluster>.pem are not specified

[abhijith]

Ironfan gem version:

4.5.1

Ironfan-hombase git-sha:

c1d68b90bfe3bc2e798248a407791b16c806283d

test0 cluster definition:

https://gist.github.com/4379680

$ knife cluster kick test0-foobar-0

/Users/abhi/.rvm/gems/ruby-1.9.3-p286/gems/chef-10.16.2/lib/chef/knife/ssh.rb:101:in block in session': undefined methodeach' for nil:NilClass (NoMethodError)
from /Users/abhi/.rvm/gems/ruby-1.9.3-p286/gems/net-ssh-multi-1.1/lib/net/ssh/multi/session.rb:499:in call' from /Users/abhi/.rvm/gems/ruby-1.9.3-p286/gems/net-ssh-multi-1.1/lib/net/ssh/multi/session.rb:499:inblock in next_session'
from /Users/abhi/.rvm/gems/ruby-1.9.3-p286/gems/net-ssh-multi-1.1/lib/net/ssh/multi/session.rb:499:in catch' from /Users/abhi/.rvm/gems/ruby-1.9.3-p286/gems/net-ssh-multi-1.1/lib/net/ssh/multi/session.rb:499:inrescue in next_session'
from /Users/abhi/.rvm/gems/ruby-1.9.3-p286/gems/net-ssh-multi-1.1/lib/net/ssh/multi/session.rb:482:in next_session' from /Users/abhi/.rvm/gems/ruby-1.9.3-p286/gems/net-ssh-multi-1.1/lib/net/ssh/multi/server.rb:138:insession'
from /Users/abhi/.rvm/gems/ruby-1.9.3-p286/gems/net-ssh-multi-1.1/lib/net/ssh/multi/session_actions.rb:36:in `block (2 levels) in sessions'

Output of $ knife cluster kick test0-foobar-0 -VV

https://gist.github.com/4379663

However, knife cluster kick -x ubuntu -i knife/credentials/ec2_keys/foobar.pem works.

[nickmarden]

At the core of this bug is the idea that "knife cluster kick" assumes that you want to log in to the remote server as $USER (i.e., in my case, "nick") rather than the user associated with the bootstrapping process (ubuntu). I think this is probably wrong, because it implies that every remote server, once bootstrapped, would have a set of Unix users on it that correspond to the sysadmins' $USER names on their management workstations.

[temujin9]

@nickmarden has it exactly. Infochimps burns AMIs that auto-vivify with the necessary users set up already, so we don't personally use the system user very often. I'd like to keep it that way internally, as it affords some extra security and accountability.

The ideal solution, as I see it:

1. There should be a "system user" flag, defaulting to on, configurable at command line (--system-user=false) and in knife-org on a per-command basis (knife[:cluster][:launch][:system_user] = false).
2. If the system user is selected, some minor magic needs to be done to determine the username and key, given the particulars of cloud and target OS (e.g. Ubuntu on AWS means 'ubuntu' using 'knife/credentials/ec2_keys/[cluster].pem').

I'm currently waiting on a gorillib refactor for step 1; once underlays are solidified, then configuration can just be done wholesale with them. If this has become a blocker for you, I can accept pull requests with configuration done the old way.

The minor magic for selecting username and keycombo should probably be built into lib/ironfan/dsl/ec2.rb, and referenced more generally using selected_cloud to reach the ec2 stuff. That makes it future proof against the implementation of other providers.

[abhijith]

@nickmarden has it exactly. Infochimps burns AMIs that auto-vivify with the necessary users set up already, so we don't personally use the system user very often. I'd like to keep it that way internally, as it affords some extra security and accountability.

Agreed. We don't use the system user either for the same reason. Our users are setup as part of the bootstrap process though. So we need to be able to kick as system user (ubuntu) if the boostrap fails without setting up our users for some reason.

The ideal solution, as I see it:

If the system user is selected, some minor magic needs to be done to determine the username and key, given the particulars of cloud and target OS (e.g. Ubuntu on AWS means 'ubuntu' using 'knife/credentials/ec2_keys/[cluster].pem').

I expected setting ssh_user to ubuntu in the cluster definition to have the above behaviour. So ssh_user is used for something else I presume?

If this has become a blocker for you, I can accept pull requests with configuration done the old way.

Nope. Like I mentioned before, we need it only if bootstrap fails before setting up users. So the current configuration is fine.

[temujin9]

Unfortunately, ssh_user only sets the username, not the corresponding SSH key.

[temujin9]

#96 contains similar earlier discussion, which may have some relevance.

[abhijith]

Cool. Can we consider this matter closed then?

[temujin9]

I'm going to leave it open; it's worth fixing (at some point), just not as a super high priority.