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

With private probe, cannot set http target with only hostname (no TLD) #934

Open
peterschretlen opened this issue Sep 13, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@peterschretlen
Copy link
Contributor

What happened:

On an HTTP check, we assert that target must be a valid hostname with a top level domain. Hostnames without at TLD don't work

Image

What you expected to happen:

If we're using a private probe, we should be able to specify a hostname without at TLD to access resources on an internal network. For example the hostname to IP mapping might be configured on the hosts file on the machine running the private probe.

Anything else we need to know?:

I suspect we have it this way because at the time the target is specified, there's no way to know if private or public probes are going to be used. Without the TLD the check won't work on a public probe, so we consider it invalid.

Possible workarounds are

  • Creating the check directly via the API, to skip the frontend validation
  • Using a k6 scripted check, which will not have the validation
@peterschretlen peterschretlen added the bug Something isn't working label Sep 13, 2024
@mem
Copy link
Contributor

mem commented Sep 13, 2024

I'm so tempted to say "not going to fix".

The check is valid if the only probes specified by the configuration are private probes. Adding a public probe invalidates the check. We do validate checks on every change, not just during creation, so yes, we could support something like that, but that does require some changes to the validation logic. At the point where this validation occurs, the information about whether a probe is private or public is not available.

All that said, this is making broad assumptions regarding the configuration of the resolver in the system, and how the agent uses that configuration. It's further assuming that all systems are configured like that.

From resolv.conf(5):

By default, the search list contains one entry, the local domain name. It is determined from the local hostname returned by gethostname(2); the local domain name is taken to be everything after the first '.'. Finally, if the hostname does not contain a '.', the root domain is assumed as the local domain name. This may be changed by listing the desired domain search path following the search keyword with spaces or tabs separating the names.

So this request assumes (on certain Linux systems) that the hostname of the system where the agent is running is fully qualified, that the search option is used, or that the user actually wants to use the root domain. In the first two cases it should be possible to specify a fully-qualified hostname (if that's not the case, please clarify why), so I have to assume this is about the later case.

@mem mem added enhancement New feature or request and removed bug Something isn't working labels Sep 13, 2024
@mem
Copy link
Contributor

mem commented Sep 13, 2024

Also, I'm open to discussing this particular point, but this is not a bug, it's a request for a change.

@mem
Copy link
Contributor

mem commented Sep 13, 2024

Creating the check directly via the API, to skip the frontend validation

The validation happens in the backend, too.

Using a k6 scripted check, which will not have the validation

If k6 is actually accepting this, that is a bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants