New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to cook node using two user accounts #444

Closed
rmoriz opened this Issue Jul 9, 2015 · 8 comments

Comments

Projects
None yet
3 participants
@rmoriz
Copy link
Contributor

rmoriz commented Jul 9, 2015

Gave the current master (6f7ae02) a try but knife solo cook <node> fails:

...
Vendoring zap (0.8.4) to cookbooks/zap
Uploading the kitchen...
Generating solo config...
Running Chef: sudo chef-solo -c ~/chef-solo/solo.rb -j ~/chef-solo/dna.json
{:config_missing=>true}
[2015-07-09T11:30:01+00:00] WARN: *****************************************
[2015-07-09T11:30:01+00:00] WARN: Did not find config file: /home/rmoriz/chef-solo/solo.rb, using command line options.
[2015-07-09T11:30:01+00:00] WARN: *****************************************
[2015-07-09T11:30:01+00:00] FATAL: Cannot load configuration from /home/rmoriz/chef-solo/dna.json
ERROR: RuntimeError: chef-solo failed. See output above.

Switching back to v0.4.2 fixes it…

@matschaffer

This comment has been minimized.

Copy link
Owner

matschaffer commented Jul 9, 2015

Can you provide the full output with '-VV' ?

Could be an issue with the new ssh/rsync control socket stuff.

On Thursday, July 9, 2015, Roland Moriz notifications@github.com wrote:

Gave the current master (6f7ae02
6f7ae02)
a try but knife solo cook fails:

...
Vendoring zap (0.8.4) to cookbooks/zap
Uploading the kitchen...
Generating solo config...
Running Chef: sudo chef-solo -c ~/chef-solo/solo.rb -j ~/chef-solo/dna.json
{:config_missing=>true}
[2015-07-09T11:30:01+00:00] WARN: *****************************************
[2015-07-09T11:30:01+00:00] WARN: Did not find config file: /home/rmoriz/chef-solo/solo.rb, using command line options.
[2015-07-09T11:30:01+00:00] WARN: *****************************************
[2015-07-09T11:30:01+00:00] FATAL: Cannot load configuration from /home/rmoriz/chef-solo/dna.json
ERROR: RuntimeError: chef-solo failed. See output above.

Switching back to v0.4.2 fixes it…


Reply to this email directly or view it on GitHub
#444.

-Mat

about.me/matschaffer

@rmoriz

This comment has been minimized.

Copy link
Contributor

rmoriz commented Jul 30, 2015

closing this, as I cannot reproduce it right now.

@rmoriz rmoriz closed this Jul 30, 2015

@rmoriz

This comment has been minimized.

Copy link
Contributor

rmoriz commented Sep 18, 2015

Okay, so here is the problem again including steps to reproduce:

  • provision a VM with root access using ssh keys (typical scenario on DigitalOcean)
  • call knife solo bootstrap fqdn.example.com -x root
  • in a sane environment, a chef ruf will remove root login, create admins users with sudo rights
  • then call knife solo cook fqdn.example.com for subsequent converges.

However, instead of syncing and executing to the root's /root/chef-solo the following will be executed:

sudo chef-solo -c ~/chef-solo/solo.rb -j ~/chef-solo/dna.json
this expands to the user home of the admin user and fails.

It looks like cookbook + data bag syncing is still done to /root/chef-solo, just the ~ in the chef call breaks it.

rmoriz@web02:~$ sudo echo ~
/home/rmoriz
rmoriz@web02:~$ sudo whoami
root

I see that with 0.3.0 a breaking change with knife[:provisioning_path] was introduced, however we're using chef-solo for a while and no issues. Did you remove some legacy "auto-detection" code? I just want to know why it failed just recently. :(

On the other hand, the problem might be the other way around: syncing seems not to interpolate "~" to the sudo caller username but to root?

@rmoriz rmoriz reopened this Sep 18, 2015

@rmoriz

This comment has been minimized.

Copy link
Contributor

rmoriz commented Sep 18, 2015

Okay, found the issue.

When I first bootstrapped the machine as ssh user root a local rsync/ssh socket was created in /Users/rmoriz/.chef/knife-solo-sockets on my local OSX machine which later was re-used although the changed other username!

I'll set config[:ssh_control_master] = "no" to fix my issue - may I ask why false was not used here?
=> https://github.com/matschaffer/knife-solo/blob/master/lib/knife-solo/ssh_command.rb#L215

@matschaffer

This comment has been minimized.

Copy link
Owner

matschaffer commented Sep 19, 2015

Yeah, in short term I'm thinking we should include the user & port in the
name and maybe sha it to keep length down.

This also feels like more reason the sockets weren't a great idea, but plan
B (packaging locally then a single rsync) will take some re-work.

On Saturday, September 19, 2015, Roland Moriz notifications@github.com
wrote:

Okay, found the issue.

When I first bootstrapped the machine as ssh user root a local rsync/ssh
socket was created in /Users/rmoriz/.chef/knife-solo-sockets which later
was re-used although the changed other username!

This seems like a bug…


Reply to this email directly or view it on GitHub
#444 (comment)
.

-Mat

matschaffer.com

@adamvduke

This comment has been minimized.

Copy link

adamvduke commented Nov 15, 2015

Thanks @rmoriz for reporting this. I just ran into it as well. Should the issue name change to reflect the actual problem for easier searching?

For others that find this issue, I added a hard dependency on 0.4.1 for the time being and it seems to be working as expected.

@matschaffer

This comment has been minimized.

Copy link
Owner

matschaffer commented Nov 15, 2015

Happy to use whatever issue name you think suits the issue best. You may
have edit access, if not just let me know and I'll update it.

The control socket was a 0.5 feature so pinning to less than that should be
good.

I'm planning to replace it with a local staging step in 0.6 so be sure to
try that when it's available.

On Monday, 16 November 2015, Adam Duke notifications@github.com wrote:

Thanks @rmoriz https://github.com/rmoriz for reporting this. I just ran
into it as well. Should the issue name change to reflect the actual problem
for easier searching?

For others that find this issue, I added a hard dependency on 0.4.1 for
the time being and it seems to be working as expected.


Reply to this email directly or view it on GitHub
#444 (comment)
.

-Mat

matschaffer.com

@matschaffer matschaffer changed the title GitHub master currently broken? Unable to cook node using two user accounts Nov 16, 2015

@matschaffer

This comment has been minimized.

Copy link
Owner

matschaffer commented Nov 16, 2015

Took a stab at a title. @rmoriz to answer your "no" I suspect I was trying to mirror the way ssh_config defines it (ControlMaster no). Though granted, not very idiomatic for chef configs.

mmrwoods added a commit to mmrwoods/knife-solo that referenced this issue Jan 5, 2016

Use remote login user in ssh control path
Only one user can cook a node from a single workstation when ssh
multiplexing is enabled, as it is by default, but the same control
socket is shared by multiple users.

This causes problems when bootstrapping new nodes when the initial
connection is made using the root user, but root logins are disabled
as part of the bootstrap process.

Fixed by using the remote login user name in the ssh control path.

Fixes matschaffer#444

mmrwoods added a commit to mmrwoods/knife-solo that referenced this issue Jan 5, 2016

Include remote user and port in ssh control path
Only one user can cook a node from a single workstation when ssh
multiplexing is enabled, as it is by default, but the same control
socket is shared for ssh sessions with different users and ports.

This causes problems when bootstrapping new nodes if root logins are
disabled and/or the sshd port is changed during the initial chef run.

Fixed by using the remote user and port in the ssh control path.

Fixes matschaffer#444
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment