Building Client Config Fails - no useful error reporting #80
Building a client config and pushing out the config fails for me but the error points to non-existing lines in the config file. Unfortunately, the error message truncates the useful info:
/etc/bind/named.conf.options:21: expected IP address or IPv4 prefix near '[cannot'
I have seen similar errors due to incorrect DNS resolution of the client address, but both the internal DNS and hosts files of the server and clients are resolving okay.
A deployment logging option, a logging of the DNS syntax check, or a path to the temporary config files would be helpful.
The text was updated successfully, but these errors were encountered:
I think here’s the issue:
As soon as you have one HOST type key in play, the app tries to parse the server address for the associated server from the server’s local host name. If that host name (with its automatically appended default search domain) isn’t resolvable in DNS, the key directive will break (“cannot resolve…”).
It will not use /etc/hosts entries and relies purely on DNS - a bit of a catch-22.
In my example, I have two slaves that will be authoritative for a number of domains in the public space. Any changes will be made on the DNS master that does not resolve any queries from the public net itself and only exposes zone management and administration to my clients.
On the private subnet where these machines live (10.0.5.0/24) I am using an .internal zone for peer address resolution. All local host names have to be resolvable under the .internal domain in order to allow proper translation.
Definitely not an issue with your great software, but it could be made more robust by either:
On Mar 27, 2014, at 9:29 PM, WillyXJ email@example.com wrote:
594 broadway # 404
Since client installation can add servers to the table, your option b would not work. Option a is already supported (at least it's been working in my test environment). So, would it make more sense to have another field in the server definition to input an IP address? It could auto populate if the IP has a PTR record.
I was able to reproduce this in my test environment. I found server/fm-modules/fmDNS/classes/class_buildconf.php#L221 uses get_dns_record() which does not use /etc/hosts so I've swapped that for gethostbyname() which will use /etc/hosts and DNS.
This will be added in v1.2.