Skip to content
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

Task level user setting looks not working, docs mistake #192

Closed
rahfar opened this issue Apr 22, 2024 · 6 comments · Fixed by #193
Closed

Task level user setting looks not working, docs mistake #192

rahfar opened this issue Apr 22, 2024 · 6 comments · Fixed by #193

Comments

@rahfar
Copy link
Contributor

rahfar commented Apr 22, 2024

Hello,

Noticed that in docs section https://spot.umputun.dev/#playbook-types said that I can specify ssh_key:

The simplified playbook does not support task-level on_error, user, and ssh_key fields, while the full playbook does. See the Task details section for more information.

But link leads to https://spot.umputun.dev/#tasks-and-commands, where it is said that only 3 of 4 fields are available: on_error, user, targets.

Actually I am trying to config my playbook to have 2 tasks, each on different remote. Here is playbook:

ssh_key: ~/.ssh/id_rsa

tasks:
  - name: t1
    user: "user1"
    targets:
      - "host2"
    commands:
      - name: test
        script: echo hello, world!

  - name: t2
    user: "user2"
    targets:
      - "host2"
    commands:
      - name: test
        script: echo hello, world!

But it is not working. If I specify user=user1 on playbook level, then t1 is working and t2 crashes with

failed, can't run task "t2" for target "***": 1 error(s) occurred:
   [0] can't connect to ***: failed to create client connection to ***:22: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

Obviously, because of wrong user selection

Also it is not clear if ssh_key is supported on task level?

Currently my workaround is to have 2 separate playbooks for each host

@rahfar
Copy link
Contributor Author

rahfar commented Apr 22, 2024

Maybe I am wrong, but here looks like the root of the problem:

count, vv, e := p.runTaskOnHost(ctx, tsk, fmt.Sprintf("%s:%d", host.Host, host.Port), host.Name, host.User)

should it be tsk.User, rather than host.User?

@umputun
Copy link
Owner

umputun commented Apr 22, 2024

just to clarify if this is not a typo in your playbook before I go any deeper - you said "... playbook to have 2 tasks, each on different remote" however the playbook you provided runs both tasks on the same host2

@rahfar
Copy link
Contributor Author

rahfar commented Apr 22, 2024

Yup, this is a typo, I meant host1 and host2, of course

@umputun
Copy link
Owner

umputun commented Apr 22, 2024

so, I would assume it fails with a correct host, right? If this is the case, I'll take a look.

in the meantime, you can specify top-level targets and set the user here, i.e.

targets:
  dev:
    hosts:
      - {name: "dev1", host: "dev1.example.com", port: 22, user: user1}
      - {name: "dev2", host: "dev2.example.com", port: 22, user: user2}

tasks:
  - name: t1
    targets:
      - "dev1"
    commands:
      - name: test
        script: echo hello, world!

  - name: t2
    targets:
      - "dev2"
    commands:
      - name: test
        script: echo hello, world!

umputun added a commit that referenced this issue Apr 22, 2024
The change eliminates setting the default task.User on the config level,
and moves this responsibility to the runner. Now the runner explicitly
checks the presence of task.User and passes it in.

In addition, runTaskOnHost sets the passed user into activeTask
(a copy of the task used later on). This was done to be able to know what
the actual user is. Currently, the only use is in setting SPOT_REMOTE_USER,
however, it can also be used in any place that needs to know the active remote user.
umputun added a commit that referenced this issue Apr 22, 2024
* Fix incorrect handling of task-level user #192

The change eliminates setting the default task.User on the config level,
and moves this responsibility to the runner. Now the runner explicitly
checks the presence of task.User and passes it in.

In addition, runTaskOnHost sets the passed user into activeTask
(a copy of the task used later on). This was done to be able to know what
the actual user is. Currently, the only use is in setting SPOT_REMOTE_USER,
however, it can also be used in any place that needs to know the active remote user.

* update man and site

* add a test for user name set on task level
@umputun umputun reopened this Apr 22, 2024
@umputun
Copy link
Owner

umputun commented Apr 22, 2024

the fix on master, please give it a try. It should properly support task-level user now. I have also updated the docs.

@rahfar
Copy link
Contributor Author

rahfar commented Apr 22, 2024

it works, thanks!

@rahfar rahfar closed this as completed Apr 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants