Re: [ovirt-users] Engine setup: insistent DNS demand

On Mon, Nov 9, 2015 at 8:27 PM, Jamie Lawrence <jlawrence(a)squaretrade.com&gt; wrote: (-offline affects only package management, e.g. to prevent an upgrade) Sorry, that was wrong. Let me sketch the flow: We query for the fqdn. let's mark the answer FQDN. We then check what FQDN resolves to using getaddrinfo, let's mark the result resolvedAddresses. We also lookup FQDN in the dns (using 'dig'). If it does not resolve, we warn. If it does resolve in the dns, *and* a special variable is set, we reverse lookup each of resolvedAddresses (dig -x), and if none of the results matches FQDN, we fail with the error you see. This special variable is set, by default, only if you configured all-in-one. This is the place where it failed for you. If it didn't, we then: If another special variable is set (which is also set by default only in all-in-one), we check if resolvedAddresses is a subset of the addresses of non-loopback local interfaces, and fail if not. This is the only place where we actually check local addresses. getaddrinfo means we effectively use the local resolver as configured by you in /etc/nsswitch.conf, by default looking first in /etc/hosts and then dns. Well, you can use other means for that, such as various pastbins/file sharing sites/whatever. So here you were asked about FQDN, and accepted the default, which was box-3.squaretrade.com That's resolvedAddresses, which contains exactly one address, 172.16.1.13. That's the result of a dns lookup for FQDN, 10.180.202.13 . As you can see, we already might have a problem here, as this is different. I admit I did not fully understand what you are trying to do, but this seems like a contradiction between what you wrote in the dns and what you wrote in /etc/hosts. As explained above, this would have caused a failure eventually, if we didn't fail earlier. Here we try to reverse-lookup 172.16.1.13 in the dns, and timeout. Not sure why. Perhaps your dns server is configured to not reply to queries about private addresses, or something like that - I'd expect here a reply NXDOMAIN (or some actual answer). And this is the error message you received, which I think makes sense even without understanding how engine-setup works. No, it only tries the result of a lookup for FQDN. As I wrote above, I do not fully understand what you try to do. May I suggest that you simply use, everywhere, both in the dns and in /etc/hosts, different names for the different addresses. E.g. if your storage interface is 172.16.1.13, give it a different name, say box-3-storage.squaretrade.com or whatever. Do this either in the dns, or in /etc/hosts, or both, but if both - same at both. And same for the other address. And when asked about FQDN, input the one you want to access the engine with. Thanks for the report. If you feel, reading the above analysis, that engine-setup should behave differently, by all means go ahead and open a bug. But if you do, please describe exactly what you want. And, if what you want is "Please add a flag or whatever that will allow me to override all this name lookup mess and just make engine-setup do what I say", please consider that the current behavior actually did find something which I personally think is unintended, so it helped you catch it now instead of perhaps spending much more time, during a much less comfortable situation, when something actually breaks due to this. Best, -- Didi