consul
consul copied to clipboard
`consul validate` fails with "Config validation failed: Multiple private IPv4 addresses found."
Description of the Issue (and unexpected/desired result)
When host has two or more interfaces, consul validate fails with:
Config validation failed: Multiple private IPv4 addresses found. Please configure one with 'bind' and/or 'advertise'.
In the same time, consul agent works, because it has bind address configured, so validation passed. The error comes from:
https://github.com/hashicorp/consul/blob/ecee15b4668e33762d36850b74e4d462bb39b917/command/validate/validate.go#L48
In documentation:
The
consul validatecommand performs a thorough sanity test on Consul configuration files. For each file or directory given, the command will attempt to parse the contents just as theconsul agentcommand would, and catch any errors.
But with consul validate I am not able to provide, for example, -bind CLI flag (as I do for consul agent).
consul version for both Client and Server
Client: 1.0.6
Server: 1.0.6
I also see this error. I set the bind_addr in the json config file but it fails to validate for this reason.
I am getting this error as well. Any fixes at the moment?
+1 on this error. Haven't figured a workaround, though the service seems to come up.
+1 on this error. bind_addr in config.json not working.
Consul v1.2.2
But set both bind_addr and advertise_addr is working ..
{
"acl_agent_token": "xxxx",
"acl_datacenter": "aliyun",
"acl_default_policy": "deny",
"acl_master_token": "xxxx",
"bootstrap_expect": 2,
"client_addr": "0.0.0.0",
"bind_addr": "0.0.0.0",
"advertise_addr": "192.168.1.200",
"data_dir": "/opt/consul",
"datacenter": "aliyun",
"dns_config": {
"allow_stale": true,
"enable_truncate": true,
"node_ttl": "60s",
"service_ttl": {
"*": "5s"
}
},
"enable_script_checks": true,
"encrypt": "xxxx",
"log_level": "INFO",
"node_name": "1.200",
"server": true
}
This bug is a real problem as it does not let you consul reload - you have to actually restart the consul client service unless you want to add in extra config information.
My previous file looked like this:
{ "addresses": { "http": "0.0.0.0" }, "data_dir": "/var/consul", "datacenter": "dc1", ...
In order to reload I have to add these fields:
{ "bind_addr": "0.0.0.0", "advertise_addr": "<internal_ip>", "addresses": { "http": "0.0.0.0" }, "data_dir": "/var/consul", "datacenter": "dc1", ...
Well, I'd created a simple PR which can solve the problem. But maybe we should think about support of all the same options as for consul agent?
+1 here. took some time to figure out what I messed up :-/
I got the same error. 2 vms. the same config.js on one the console validate works and on the other this error message returns on start. It would be helpfull to know those "multiple private IPv4 addresses" that are found.
This is the config, some keys are redacted
{
"acl": {
"default_policy": "deny",
"down_policy": "extend-cache",
"enabled": true,
"tokens": {
"default": "<token>"
}
},
"addresses": {
"http": "127.0.0.1 {{ GetInterfaceIP \"docker0\" }}"
},
"bind_addr": "{{ GetInterfaceIP \"ens160\" }}",
"advertise_addr": "{{ GetInterfaceIP \"ens160\" }}",
"data_dir": "/var/data/consul",
"datacenter": "datacenter",
"enable_debug": false,
"enable_script_checks": false,
"encrypt": "<placeholder>",
"encrypt_verify_incoming": true,
"encrypt_verify_outgoing": true,
"node_name": "build1",
"primary_datacenter": "datacenter",
"retry_join": [
"172.16.2.21",
"172.16.2.22",
"172.16.2.23"
],
"server": false,
"tls": {
"defaults": {
"ca_file": "/etc/consul.d/pki/ca-bundle.crt",
"cert_file": "/etc/consul.d/pki/consul.crt",
"key_file": "/etc/consul.d/pki/consul.key"
}
},
"ui_config": {
"enabled": false
}
}
I'm not sure if I can get this done, but I'm going to take a crack at it!
There are a few different approaches for a real fix that I can imagine. Let me know what folks think.
Mix agent flags and validate flags as @jerrdasur suggested
- 👍 easy for users: just copy-paste
- 👎 maybe a bit messy to implement
- 😬 presumes flag names will never overlap
Agent flags after --
E.g.
consul validate <config...> -- -bind=0.0.0.0 -advertise=192.168.0.100
- 👍 relatively easy for users: just copy-paste after
-- - 👍 easy to implement
- 👎 kind of weird-looking
Extra agent config in JSON blob
consul validate -extra-agent-json='{"bind_addr": "0.0.0.0", "advertise_addr": "192.168.0.100"}' <config...>
This would then merge with config as if it were the last file in the directory.
- 👍 not too hard to implement
- 👎 a little fiddly to write and adapt from flags
- 😕 does the extra JSON merge with each of the configs?
Actually it turns out you can work around this with a shell trick involving process substitution and stacking configs:
$ consul validate -config-format=json config.json
Config validation failed: Multiple private IPv4 addresses found. Please configure one with 'bind' and/or 'advertise'.
exit status 1
$ consul validate -config-format=json config.json <(echo '{"bind_addr": "0.0.0.0", "advertise_addr": "192.168.0.100"}')
Configuration is valid!
The -config-format=json is required to inform validate that the extensionless file is JSON. (Unfortunately, the warning that the file is being skipped doesn't get included if there is an error in processing. Arguably a bug on its own.)
Is this workaround sufficient? Honestly it doesn't seem much less ugly than any of the permanent solutions I've offered above.
Hm, it's been more than 4 years since I've created this issue and right now I am not using consul. But it feels a bit wrong that I need to configure bind_addr address in order to validate a config - I think consul validate -config-format=json config.json should only validate the content of the config file and should not require any additional parameters that consul agent might have.
Hmm, I'm not sure. Given that validate validates agent config, I'd say requiring your complete config is not out of the question. Indeed the current CLI help points this out:
This performs all of the validation the agent would, so
this should be given the complete set of configuration files that are going
to be loaded by the agent. This command cannot operate on partial
configuration fragments since those won't pass the full agent validation.
That said, it might be nice if there were another validate mode that just did a static analysis on the config without having to inspect the running system.
Also, if you consider flags to be part of the config, we could perhaps make it easier/possible to pass them :P
In my use-case (I was deploying the config with ansible and wanted to run consul validate before restarting consul) validating only the config was enough. But its true that validating the complete configuration (even with flags) would be even better. Ideally I would like to take consul agent command and replace agent argument to validate and that's it. With this being said, having a possibility to specify agent flags after -- sounds also good to me.
@nfi-hashicorp does this issue still need attention or is consul validate fine as is?
If it does, how could I help?
It looks like you've already laid out some potential solutions.
If specifying agent flags after -- is easier than @edganiukov's ideal solution and would solve this issue, is that the best path forward?
I've been off consul for a while and TBH have 100% unloaded this problem from memory. I don't think I'm going to do anything with it.