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

Building Client Config Fails - no useful error reporting #80

Closed
mac-tech opened this Issue Mar 27, 2014 · 5 comments

Comments

Projects
None yet
2 participants
@mac-tech

mac-tech commented Mar 27, 2014

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.

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented Mar 28, 2014

Have you tried doing a server config preview to see any errors?

@mac-tech

This comment has been minimized.

mac-tech commented Mar 28, 2014

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:
a. allowing local hostname resolution using hosts file entries, or
b. forcing resolvable FQDN hostnames at the time of creating client configurations.

best

Florian

On Mar 27, 2014, at 9:29 PM, WillyXJ notifications@github.com wrote:

Have you tried doing a server config preview to see any errors?


Reply to this email directly or view it on GitHub.

//////////////////////

florian feuser

mac-tech

594 broadway # 404
new york, ny 10012
v. 212 689 7911 x 211
f. 646 349 1770

http://mac-tech.net

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented Mar 28, 2014

That sounds like the problem. Although, in my test environment, my fM server has all dns clients in its hosts file and is able to resolve them for keys. I'll keep looking to see how else this can be handled.

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented Apr 3, 2014

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.

@WillyXJ WillyXJ modified the milestones: 1.2 release, 1.1 bugfixes Apr 3, 2014

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented Apr 15, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment