On 01/05/2019 15.34, Anton Aylward wrote:
On 2019-05-01 8:44 a.m., Carlos E. R. wrote:
Before that point (before reading from /etc/hosts) is the nscd intercept. You mean that -- somehow, some unspecified manner -- that happens before the decision as to whether to use files or DNS or something else as determined by the nsswitch.conf file is accessed?
No, after the decision.
So you are saying that nsswitch.conf is accessed then ..
If the decision is files, it is nscd who answers what the files say.
HOW? you are doing the 'by magic' (aka unspecified) again.
Where is the magic? I don't see it. It is you who first used the word "decision". If "/etc/host.conf" says: order files, bind then the "decision" is first to ask the local files, ie, /etc/hosts.
"if the decision is 'files' ..." well its not about 'decision. if the refile reads:
hosts: files dns
that means 'try files first". That means READING a file. presumably /etc/hosts.
NOT invoking a routine or calling a network connection.
Who said different?
If the decision is bind, it is nscd who answers what the bind says.
More magic.
No magic.
Its not about a 'decision', it is IF AND ONLY IF the 'files' returns STATUS = notfound
And where does 'bind' come into this? I'm running dnsmasq, not Bind9.
Because the wording in "/etc/host.conf" is bind, not dns. See "man host.conf": order This keyword specifies how host lookups are to be performed. It should be followed by one or more lookup methods, separated by commas. Valid methods are bind, hosts, and nis.
I think you mean, reading the MAN(nsswitch.conf) where it says "The order of the services on the line determines the order in which those services will be queried, in turn, until a result is found."
So if the answer isn't find in "files" then it uses "dns". But how does that get to invoke Bind9, nscd or dnsmasq? In a deterministic, procedural manner? As determined by some configuration!
Again, it does not decide what daemon to ask. It ask 127.0.0.1 or 192.168.0.1. The address is written in hosts. Who ever answers. Not its business to know what daemon actually answers. If nscd is running, then the library is hijacked, intercepted or however you want to call it, to ask nscd first.
Or, maybe it intercepts,
No, it's the beady-eyed raptor that intercepts ...
find out he doesn't know the answer,
You mean "its not in the cache".
Yes, of course. Did you think it is a person, a magician? Of course I mean "its not in the cache". But I did not use that wording.
I can see how that logic applies to both nscd and dnsmasq, but it still doesn't say how it got to them in the first place.
nscd: intercept the library call. dnsmasq: make an internet call, that happens in your case to be on the same computer.
lets the call to the library continue, and when there is an answer it stores the answer in the cache for the next time.
I think that "library continues" needs a LOT more clarification.
But not from me.
And yes, Bind9 and dnsmasq can be configured to do their own caching. At which point the relevance of nscd becomes apropos.
nscd is not at the same level as the rest. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org