Re: localhost woes -- help requested

2019-06-19 Thread Ronald F. Guilmette
In message <74b7ccf0-967f-40b1-9818-3417cd8d1...@punkt.de>, 
"Patrick M. Hausen"  wrote:

>https://tools.ietf.org/html/rfc6761

Wow.  Thanks for that.  Quite certainly, 6.3 (part 1) is confirming
that this is the way things are now, and have been, apparently since
2013.

I really didn't know.  Now I do.  I'm not happy about it, but you
can't fight City Hall.


Regards,
rfg
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: localhost woes -- help requested

2019-06-19 Thread Rodney W. Grimes
> > In message <201906190617.x5j6hqma016...@gndrsh.dnsmgr.net>, 
> > Rodney W. Grimes"  wrote:
> > 
> > >> In message <201906181719.x5ihj8g0014...@gndrsh.dnsmgr.net>, 
> > >> "Rodney W. Grimes"  wrote:
> > >> 
> > >> >What is in /etc/host.conf, /etc/resolv.conf, do you have DNS running?
> > >> 
> > >> 
> > >> 1)  https://pastebin.com/raw/wXTTgd9R
> > >This is /etc/hosts, not /etc/host.conf
> > ># cat /etc/host.conf
> > ># Auto-generated from nsswitch.conf
> > >hosts
> > >dns
> > >
> > >> 2)  https://pastebin.com/raw/PiGpN0LU
> > >> 
> > >> 3)  Yes, local-unbound
> > >
> > >Ok, if you comment out ::1 from /etc/hosts then the lookup is
> > >going to fall through to DNS with the default /etc/host.conf file
> > >and you'll get what ever your dns is configured to return, which
> > >is usually the exact some thing as /etc/hosts has.
> > 
> > So basically you're telling me that local-unbound has taken it upon
> > itself to decide for me, regardless of what is or isn't in my /etc/hosts
> > file, what addresses "localhost" should resolve to??
> 
> Yes, dns resolvers shipping for the last 5 decades have all shipped

Ooppps.. off by one calculation "near 4 decades"

> with default "localhost" values.  Both "localhost" and 127.in-addr.arpa
> zones existed iirc in the very first version of bind.
> 
> > 
> > If so, that really is rather presumptive on its part.
> 
> No, well defined by RFC.
> I would suggest a starting read at https://en.wikipedia.org/wiki/Localhost
> 
> Specifically this detail:
>   In the Domain Name System, the name localhost is reserved as a
>   top-level domain name, originally set aside to avoid confusion
>   with the hostname used for loopback purposes.[3] IETF standards
>   prohibit domain name registrars from assigning the name localhost. 
> 
> 
> And finally:
> https://tools.ietf.org/html/rfc2606#section-2
> at 
>   The ".localhost" TLD has traditionally been statically defined in
>   host DNS implementations as having an A record pointing to the
>   loop back IP address and is reserved for such use.  Any other use
>   would conflict with widely deployed code which assumes this use.
> 
> Regards,
> -- 
> Rod Grimes rgri...@freebsd.org
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: localhost woes -- help requested

2019-06-19 Thread Rodney W. Grimes
> In message <201906190617.x5j6hqma016...@gndrsh.dnsmgr.net>, 
> Rodney W. Grimes"  wrote:
> 
> >> In message <201906181719.x5ihj8g0014...@gndrsh.dnsmgr.net>, 
> >> "Rodney W. Grimes"  wrote:
> >> 
> >> >What is in /etc/host.conf, /etc/resolv.conf, do you have DNS running?
> >> 
> >> 
> >> 1)  https://pastebin.com/raw/wXTTgd9R
> >This is /etc/hosts, not /etc/host.conf
> ># cat /etc/host.conf
> ># Auto-generated from nsswitch.conf
> >hosts
> >dns
> >
> >> 2)  https://pastebin.com/raw/PiGpN0LU
> >> 
> >> 3)  Yes, local-unbound
> >
> >Ok, if you comment out ::1 from /etc/hosts then the lookup is
> >going to fall through to DNS with the default /etc/host.conf file
> >and you'll get what ever your dns is configured to return, which
> >is usually the exact some thing as /etc/hosts has.
> 
> So basically you're telling me that local-unbound has taken it upon
> itself to decide for me, regardless of what is or isn't in my /etc/hosts
> file, what addresses "localhost" should resolve to??

Yes, dns resolvers shipping for the last 5 decades have all shipped
with default "localhost" values.  Both "localhost" and 127.in-addr.arpa
zones existed iirc in the very first version of bind.

> 
> If so, that really is rather presumptive on its part.

No, well defined by RFC.
I would suggest a starting read at https://en.wikipedia.org/wiki/Localhost

Specifically this detail:
In the Domain Name System, the name localhost is reserved as a
top-level domain name, originally set aside to avoid confusion
with the hostname used for loopback purposes.[3] IETF standards
prohibit domain name registrars from assigning the name localhost. 


And finally:
https://tools.ietf.org/html/rfc2606#section-2
at 
  The ".localhost" TLD has traditionally been statically defined in
  host DNS implementations as having an A record pointing to the
  loop back IP address and is reserved for such use.  Any other use
  would conflict with widely deployed code which assumes this use.

Regards,
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: localhost woes -- help requested

2019-06-19 Thread Patrick M. Hausen
Hi!

> Am 19.06.2019 um 08:23 schrieb Ronald F. Guilmette :
> So basically you're telling me that local-unbound has taken it upon
> itself to decide for me, regardless of what is or isn't in my /etc/hosts
> file, what addresses "localhost" should resolve to??
> 
> If so, that really is rather presumptive on its part.

https://tools.ietf.org/html/rfc6761

Patrick
-- 
punkt.de GmbH   Internet - Dienstleistungen - Beratung
Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100
76133 Karlsruhe i...@punkt.de   http://punkt.de
AG Mannheim 108285  Gf: Juergen Egeling

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: localhost woes -- help requested

2019-06-19 Thread Ronald F. Guilmette
In message <201906190617.x5j6hqma016...@gndrsh.dnsmgr.net>, 
Rodney W. Grimes"  wrote:

>> In message <201906181719.x5ihj8g0014...@gndrsh.dnsmgr.net>, 
>> "Rodney W. Grimes"  wrote:
>> 
>> >What is in /etc/host.conf, /etc/resolv.conf, do you have DNS running?
>> 
>> 
>> 1)  https://pastebin.com/raw/wXTTgd9R
>This is /etc/hosts, not /etc/host.conf
># cat /etc/host.conf
># Auto-generated from nsswitch.conf
>hosts
>dns
>
>> 2)  https://pastebin.com/raw/PiGpN0LU
>> 
>> 3)  Yes, local-unbound
>
>Ok, if you comment out ::1 from /etc/hosts then the lookup is
>going to fall through to DNS with the default /etc/host.conf file
>and you'll get what ever your dns is configured to return, which
>is usually the exact some thing as /etc/hosts has.

So basically you're telling me that local-unbound has taken it upon
itself to decide for me, regardless of what is or isn't in my /etc/hosts
file, what addresses "localhost" should resolve to??

If so, that really is rather presumptive on its part.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: localhost woes -- help requested

2019-06-19 Thread Rodney W. Grimes
> In message <201906181719.x5ihj8g0014...@gndrsh.dnsmgr.net>, 
> "Rodney W. Grimes"  wrote:
> 
> >What is in /etc/host.conf, /etc/resolv.conf, do you have DNS running?
> 
> 
> 1)  https://pastebin.com/raw/wXTTgd9R
This is /etc/hosts, not /etc/host.conf
# cat /etc/host.conf
# Auto-generated from nsswitch.conf
hosts
dns

> 2)  https://pastebin.com/raw/PiGpN0LU
> 
> 3)  Yes, local-unbound

Ok, if you comment out ::1 from /etc/hosts then the lookup is
going to fall through to DNS with the default /etc/host.conf file
and you'll get what ever your dns is configured to return, which
is usually the exact some thing as /etc/hosts has.

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: localhost woes -- help requested

2019-06-18 Thread Ronald F. Guilmette
In message <201906181719.x5ihj8g0014...@gndrsh.dnsmgr.net>, 
"Rodney W. Grimes"  wrote:

>What is in /etc/host.conf, /etc/resolv.conf, do you have DNS running?


1)  https://pastebin.com/raw/wXTTgd9R

2)  https://pastebin.com/raw/PiGpN0LU

3)  Yes, local-unbound
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: localhost woes -- help requested

2019-06-18 Thread Rodney W. Grimes
> In message 
> , 
> Adam  wrote:
> 
> >On Sat, Jun 15, 2019 at 12:54 AM Ronald F. Guilmette 
> >wrote:
> >> ... except for the browsers, and also one other thing (nmh outbound
> >> email handling).  Now, both Firefox and Opera crash and burn, right
> >> out of the gate, when started from the command line.  In both cases
> >> thet do so both with entirely cryptic failure messages.
> >>
> >> But here's the kicker... I futzed around with this awhile and found
> >> out that if I just change the default value of the DISPLAY environment
> >> variable from "localhost:0.0" to ":0.0" then both browsers *do* then
> >> start up successfully from the command line.
> >>
> >> So, um, what the bleep did I do wrong?
> >>
> >> Here's the output of the command "getent hosts localhost":
> >>
> >> ::1   localhost
> >> 127.0.0.1 localhost  localhost.tristatelogic.com
> >>
> >>
> >> Any hints for how I can debug this mess would be appreciated.
> >>
> >
> >Do you have local_unbound running?  It's probably caching the result.
> >
> >/etc/rc.d/local_unbound stop
> >
> >Then try your changes to /etc/hosts
> 
> I have now rebooted the system multiple times, from a cold start, and
> this has had *no* effect on the output generated by "getent hosts localhost".
> 
> That is *still* showing me that there exists a mapping from "localhost"
> to an IPv6 address, even though I commented that out in my /etc/hosts
> file.
> 
> I really would like to understand why manual edits to /etc/hosts seem
> to have no effect whatosoever.  And more importantly, I'd really still
> like to know whey X applications cannot seem to connect to the X server
> when and if DISPLAY is set to localhost:0.0 while they have no problem
> doing so when DISPLAY is instead set to :0.0

What is in /etc/host.conf, /etc/resolv.conf, do you have DNS running?

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: localhost woes -- help requested

2019-06-17 Thread Ronald F. Guilmette
In message <20190618003925.a49a1156e...@mail.bitblocks.com>, 
Bakul Shah  wrote:

>> I really would like to understand why manual edits to /etc/hosts seem
>> to have no effect whatosoever.

That's issue/question #1.

>>  And more importantly, I'd really still
>> like to know whey X applications cannot seem to connect to the X server
>> when and if DISPLAY is set to localhost:0.0 while they have no problem
>> doing so when DISPLAY is instead set to :0.0

This is issue/questuon #2.

>I ran into this as well. I tried tracing getent() through
>networking code in libc but this is quite a mess. And gdb
>doesn't work reliably either. No doubt there are some new
>switches I haven't explored. And threading.

Ok, I have an answer now on question #2.  I asked some people who know
way more about X than I do (which is actually almost eerybody), and
as a result I found out the whole story.

It seems that at some point it time, somebody decided that it would be
Good if the default configuation(s) of the X server would no longer talk
to clients, by default, using TCP.  (I can only assume that this was most
probably a very wise security improvement for the X server at the time.)

So anyway, the other thing I learned is that if one has a hostname... i.e.
*any* kind of a hostname... in one's DISPLAY environment variable value,
then X clients will all try to connect to the server using TCP.  And that
will fail, as it should nowadays.

Apparenttly this even includes "localhost", which is sort of a special kind
of a hostname.

My problem was that... unbeknownst to me...  I had the following line,
left over from ancient times, in one of my tcsh shell startup files:

setenv DISPLAY localhost:0.0

I simply removed that, quit X, logged out, and logged back in again,
and then started X again, and everything was perfect after that, most
probably because all of my processes (after starting X) were now inheriting
a proper and modern sort of value for DISPLAY, which is to say ":0".

That's all there was to it.

I'm still totally in the dark about Question #1 (above) however, but that
is just a matter of idle curiosity now, now that I have all of my X clients
working properly.


Regards,
rfg
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: localhost woes -- help requested

2019-06-17 Thread Bakul Shah
On Mon, 17 Jun 2019 13:15:22 -0700 "Ronald F. Guilmette" 
 wrote:
Ronald F. Guilmette writes:
> Adam  wrote:
>
> >On Sat, Jun 15, 2019 at 12:54 AM Ronald F. Guilmette 
> >wrote:
> >> ... except for the browsers, and also one other thing (nmh outbound
> >> email handling).  Now, both Firefox and Opera crash and burn, right
> >> out of the gate, when started from the command line.  In both cases
> >> thet do so both with entirely cryptic failure messages.
> >>
> >> But here's the kicker... I futzed around with this awhile and found
> >> out that if I just change the default value of the DISPLAY environment
> >> variable from "localhost:0.0" to ":0.0" then both browsers *do* then
> >> start up successfully from the command line.
> >>
> >> So, um, what the bleep did I do wrong?
> >>
> >> Here's the output of the command "getent hosts localhost":
> >>
> >> ::1   localhost
> >> 127.0.0.1 localhost  localhost.tristatelogic.com
> >>
> >>
> >> Any hints for how I can debug this mess would be appreciated.
> >>
> >
> >Do you have local_unbound running?  It's probably caching the result.
> >
> >/etc/rc.d/local_unbound stop
> >
> >Then try your changes to /etc/hosts
>
> I have now rebooted the system multiple times, from a cold start, and
> this has had *no* effect on the output generated by "getent hosts localhost".
>
> That is *still* showing me that there exists a mapping from "localhost"
> to an IPv6 address, even though I commented that out in my /etc/hosts
> file.
>
> I really would like to understand why manual edits to /etc/hosts seem
> to have no effect whatosoever.  And more importantly, I'd really still
> like to know whey X applications cannot seem to connect to the X server
> when and if DISPLAY is set to localhost:0.0 while they have no problem
> doing so when DISPLAY is instead set to :0.0

I ran into this as well. I tried tracing getent() through
networking code in libc but this is quite a mess. And gdb
doesn't work reliably either. No doubt there are some new
switches I haven't explored. And threading.

(gdb) where
#0  0x080b127b in __vdso_clock_gettime (clock_id=12, ts=0xbfbfe100)
at /usr/src/lib/libc/sys/__vdso_gettimeofday.c:149
#1  0x080a1a2e in __clock_gettime (clock_id=12, ts=0xbfbfe100)
at /usr/src/lib/libc/sys/clock_gettime.c:46
#2  0x080dd47a in __res_state () at /usr/src/lib/libc/resolv/res_state.c:82
#3  0x08097fdf in _ht_gethostbyname (rval=0xbfbfe698, cb_data=0x0,
ap=0xbfbfe240 "T??\034") at /usr/src/lib/libc/net/gethostbyht.c:244
#4  0x08096f7f in _nsdispatch (retval=0xbfbfe698, disp_tab=0x80f6b30,
database=, method_name=0x80f6b7c "gethostbyname2_r",
defaults=0x80f6af4) at /usr/src/lib/libc/net/nsdispatch.c:704
#5  0x08095dba in gethostbyname_internal (name=0xbfbfe954 "localhost", af=28,
hp=0x8107a00, buf=0x8107a14 "", buflen=8504, result=0xbfbfe698,
h_errnop=0xbfbfe694, statp=0x81128d4)
at /usr/src/lib/libc/net/gethostnamadr.c:572
#6  0x08096539 in gethostbyname2 (name=0xbfbfe954 "localhost", af=28)
at /usr/src/lib/libc/net/gethostnamadr.c:519
#7  0x08048b39 in hosts (argc=3, argv=0xbfbfe790) at getent.c:309
#8  0x08048402 in main (argc=3, argv=0xbfbfe790) at getent.c:112

Just manually s/localhost/127.0.0.1/g.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: localhost woes -- help requested

2019-06-17 Thread Ronald F. Guilmette
In message 
, 
Adam  wrote:

>On Sat, Jun 15, 2019 at 12:54 AM Ronald F. Guilmette 
>wrote:
>> ... except for the browsers, and also one other thing (nmh outbound
>> email handling).  Now, both Firefox and Opera crash and burn, right
>> out of the gate, when started from the command line.  In both cases
>> thet do so both with entirely cryptic failure messages.
>>
>> But here's the kicker... I futzed around with this awhile and found
>> out that if I just change the default value of the DISPLAY environment
>> variable from "localhost:0.0" to ":0.0" then both browsers *do* then
>> start up successfully from the command line.
>>
>> So, um, what the bleep did I do wrong?
>>
>> Here's the output of the command "getent hosts localhost":
>>
>> ::1   localhost
>> 127.0.0.1 localhost  localhost.tristatelogic.com
>>
>>
>> Any hints for how I can debug this mess would be appreciated.
>>
>
>Do you have local_unbound running?  It's probably caching the result.
>
>/etc/rc.d/local_unbound stop
>
>Then try your changes to /etc/hosts

I have now rebooted the system multiple times, from a cold start, and
this has had *no* effect on the output generated by "getent hosts localhost".

That is *still* showing me that there exists a mapping from "localhost"
to an IPv6 address, even though I commented that out in my /etc/hosts
file.

I really would like to understand why manual edits to /etc/hosts seem
to have no effect whatosoever.  And more importantly, I'd really still
like to know whey X applications cannot seem to connect to the X server
when and if DISPLAY is set to localhost:0.0 while they have no problem
doing so when DISPLAY is instead set to :0.0


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: localhost woes -- help requested

2019-06-15 Thread Adam
On Sat, Jun 15, 2019 at 12:54 AM Ronald F. Guilmette 
wrote:

> I've recently completed a long overdue upgrade from FreeBSD 9.1 to
> 12.0.  And when I say "completed" that isn't 100% accurate, as there
> are still a couple of remaining things I can't quite seem to make
> work properly.
>
> Both of these, perhaps coincidentally, have to do with the magic
> name "localhost".
>
> I can't for the life of me figure out what I've done wrong so I am
> asking for help.
>
> First I should probably explain where I have been already, as that
> may help to shed light on the problem.
>
> I installed and configured my new 12.0 system on a different (Intel-
> based) machine at first.  Got almost everything I need installed and
> working on that hardware before, as a last step, pulling the hard
> drive out of that system and sticking in into the AMD-based system
> which will be its final home.  Two things that definitely worked
> before I swapped the hard drive to its new home were the Firefox and
> Opera browsers.  (I know.  I checked.)
>
> Once I had the drive installed on the AMD system, I had to make a
> small diddle to /etc/rc.conf to enable the AMD Kernel Mode Switching
> graphics driver.  But other than that, everything remained pretty
> much as it was.  The only other thing I did was to tun on ipfw.
> It took me awhile to get my ipfw rules all the way I want them,
> but now everything is running peachey again...
>
> ... except for the browsers, and also one other thing (nmh outbound
> email handling).  Now, both Firefox and Opera crash and burn, right
> out of the gate, when started from the command line.  In both cases
> thet do so both with entirely cryptic failure messages.
>
> But here's the kicker... I futzed around with this awhile and found
> out that if I just change the default value of the DISPLAY environment
> variable from "localhost:0.0" to ":0.0" then both browsers *do* then
> start up successfully from the command line.
>
> So, um, what the bleep did I do wrong?
>
> Here's the output of the command "getent hosts localhost":
>
> ::1   localhost
> 127.0.0.1 localhost  localhost.tristatelogic.com
>
>
> Any hints for how I can debug this mess would be appreciated.
>

Do you have local_unbound running?  It's probably caching the result.

/etc/rc.d/local_unbound stop

Then try your changes to /etc/hosts

fwiw, the default ipv6 line matches the ipv4 short then fqdn.

-- 
Adam
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


localhost woes -- help requested

2019-06-14 Thread Ronald F. Guilmette
I've recently completed a long overdue upgrade from FreeBSD 9.1 to
12.0.  And when I say "completed" that isn't 100% accurate, as there
are still a couple of remaining things I can't quite seem to make
work properly.

Both of these, perhaps coincidentally, have to do with the magic
name "localhost".

I can't for the life of me figure out what I've done wrong so I am
asking for help.

First I should probably explain where I have been already, as that
may help to shed light on the problem.

I installed and configured my new 12.0 system on a different (Intel-
based) machine at first.  Got almost everything I need installed and
working on that hardware before, as a last step, pulling the hard
drive out of that system and sticking in into the AMD-based system
which will be its final home.  Two things that definitely worked
before I swapped the hard drive to its new home were the Firefox and
Opera browsers.  (I know.  I checked.)

Once I had the drive installed on the AMD system, I had to make a
small diddle to /etc/rc.conf to enable the AMD Kernel Mode Switching
graphics driver.  But other than that, everything remained pretty
much as it was.  The only other thing I did was to tun on ipfw.
It took me awhile to get my ipfw rules all the way I want them,
but now everything is running peachey again...

... except for the browsers, and also one other thing (nmh outbound
email handling).  Now, both Firefox and Opera crash and burn, right
out of the gate, when started from the command line.  In both cases
thet do so both with entirely cryptic failure messages.

But here's the kicker... I futzed around with this awhile and found
out that if I just change the default value of the DISPLAY environment
variable from "localhost:0.0" to ":0.0" then both browsers *do* then
start up successfully from the command line.

So, um, what the bleep did I do wrong?

Here's the output of the command "getent hosts localhost":

::1   localhost
127.0.0.1 localhost  localhost.tristatelogic.com

This output also seems pretty entirely bizzare to me, because at some
point, while trying to debug this problem, I came to the theory that
perhaps it was all of this darned IPv6 stuff that was causing all of
the problems.  So I edited my local /etc/hosts file and I actually
COMMENTED OUT the line that defined an IPv6 address for localhost.
And yet, ever after I commented out the /etc/hosts line that defines
an IPv6 address for "localhost" *and* then rebooting, I am *still*
getting the above output from getent which is still showing an IPv6
address for localhost !?!?  So, I mean, what the hay??? I have zero
comptrehension of whay this might be the case, and if someone could
explain it to me, I would be eternally greatful.

Oh! And by the way, the relevant line from my /etc/nsswitch.conf
file is as follows:

hosts: files dns mdns

I had assumed that "files" meant /etc/hosts.  No?  It now appears,
maybe not, since my manual edits to that file appear to have no effect
whatsoever.

One last thing... I also have run into -another- problem that also
seems related to the resolution... or lack thereof... of the name
"localhost".  That name is also used in the default NMH configuration
file called /usr/local/etc/nmh/mts.conf wherein it is supposed to
designate what mail server the NMH mail client should try to connect
to when it needs to send outbound mail.

Well, believe me, the Postfix mail server is up and running on this
(AMD) machine, and its doing its job flawlessly.  And it is answering
to "telnet 127.0.0.1 25" just like it should.  HOWEVER, regardless of
that, when I go to send some outbound mail using the NMH mail client,
I am getting an error saying that NMH can't connect to "localhost".

I am totally unable to understand or explain that also/either.

I don't know if this NMH problem is even related to the problem with
the browsers.  They apparently are having trouble connecting to the X
server on "localhost"... but it seems like the two problems might be
related in some way, and might all have to do with some resolution
problem relating to this blasted name "localhost".

Any hints for how I can debug this mess would be appreciated.


Regards,
rfg


P.S.  I actually do know my way around DNS fairly well, but none of this
is DNS related, per se.  "localhost" is not an FQDN, and it isn't in any
DNS zone file that I am aware of.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"