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.

Sign up for GitHub

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

Jump to bottom

cli client doesn't respect env vars with nomad alloc signal command. #8894

Closed
hongkongkiwi opened this issue Sep 16, 2020 · 2 comments · Fixed by #8897
Closed

cli client doesn't respect env vars with nomad alloc signal command. #8894

hongkongkiwi opened this issue Sep 16, 2020 · 2 comments · Fixed by #8897
Labels
stage/waiting-reply theme/allocation API type/bug

Comments

@hongkongkiwi
Copy link

Nomad version

Nomad v0.12.4

Operating system and Environment details

Linux edge0 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Issue

When using the command nomad alloc signal -s SIGHUP <alloc_id> nomad does not respect the NOMAD_ADDR environment variable. Any other command works fine e.g. nomad alloc status <alloc_id>.

In my .bash_aliases file I have the following:

export NOMAD_ADDR=https://127.0.0.1:4646
export NOMAD_CACERT=/etc/nomad/certs/nomad-ca.pem
export NOMAD_CLIENT_CERT=/etc/nomad/certs/cli.pem
export NOMAD_CLIENT_KEY=/etc/nomad/certs/cli-key.pem

However, when connecting with the signal comment, it gives an error such as:

Error signalling allocation: Put "https://192.168.1.18:4646/v1/client/allocation/b16c3dfb-cfc3-e2ba-9c4c-241e889b7719/signal?region=global": x509: certificate is valid for 127.0.0.1, 172.17.0.1, not 192.168.1.18

So obviously (and strangely) for this one command it does not respect the environment variable for NOMAD_ADDR and somehow tries to connect to a lan ip instead of 127.0.0.1.
@tgross
Copy link
Member

tgross commented Sep 16, 2020

Hi @hongkongkiwi! Sorry to hear you're having trouble.

Just to help us narrow this down, are you experiencing the same issue with nomad alloc exec, nomad alloc fs, or nomad alloc logs? Those commands use the same API to forward commands to the client nodes, whereas nomad alloc status just communicates with the server, so if those are also broken that would help identify where the problem is.

@notnoop notnoop mentioned this issue Sep 16, 2020
Merged
@tgross tgross mentioned this issue Sep 16, 2020
Closed
notnoop pushed a commit that referenced this issue Sep 16, 2020
api: target servers for allocation requests (#8897)
679fee9 
Allocation requests should target servers, which then can forward the
request to the appropriate clients.

Contacting clients directly is fragile and prune to failures: e.g.
clients maybe firewalled and not accessible from the API client, or have
some internal certificates not trusted by the API client.

FWIW, in contexts where we anticipate lots of traffic (e.g. logs, or
exec), the api package attempts contacting the client directly but then
fallsback to using the server. This approach seems excessive in these
simple GET/PUT requests.

Fixes #8894
notnoop pushed a commit that referenced this issue Sep 16, 2020
api: target servers for allocation requests (#8897)
0392a15 
Allocation requests should target servers, which then can forward the
request to the appropriate clients.

Contacting clients directly is fragile and prune to failures: e.g.
clients maybe firewalled and not accessible from the API client, or have
some internal certificates not trusted by the API client.

FWIW, in contexts where we anticipate lots of traffic (e.g. logs, or
exec), the api package attempts contacting the client directly but then
fallsback to using the server. This approach seems excessive in these
simple GET/PUT requests.

Fixes #8894
fredrikhgrelland pushed a commit to fredrikhgrelland/nomad that referenced this issue Sep 28, 2020
@fredrikhgrelland
api: target servers for allocation requests (hashicorp#8897)
44ecc11 
Allocation requests should target servers, which then can forward the
request to the appropriate clients.

Contacting clients directly is fragile and prune to failures: e.g.
clients maybe firewalled and not accessible from the API client, or have
some internal certificates not trusted by the API client.

FWIW, in contexts where we anticipate lots of traffic (e.g. logs, or
exec), the api package attempts contacting the client directly but then
fallsback to using the server. This approach seems excessive in these
simple GET/PUT requests.

Fixes hashicorp#8894
@github-actions
Copy link

github-actions bot commented Nov 2, 2022

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 2, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
stage/waiting-reply theme/allocation API type/bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

api: target servers for allocation requests hashicorp/nomad
2 participants
@tgross @hongkongkiwi