On Tue, Apr 01, 2025 at 01:36:21PM +0100, mick.crane wrote:
On 2025-04-01 13:21, tomas@tuxteam.de wrote:Yes, you can put as many space-separated names in a line as you
On Tue, Apr 01, 2025 at 12:42:46PM +0100, mick.crane wrote:Ah, thanks. I didn't know you could do that.
[...]
the spaces look wrong to meIf you mean those:
192.168.71.122 bpi51e5p.coyote.den bpi51 e5p #3dprinter^^^
...^^^
192.168.71.121 mkspi.coyote.den mkspi xmax3 # 3dprinter
... they are OK. They separate alternative host names. They mean
that 192.168.71.122 responds to "bpi51e5p.coyote.den", but also
"bpi51" and finally "e5p". Likewise for the other.
Cheers
like (well: one or more).
But in a way you are right: the formatting is a bit funny and we
don't know whether OP means that. My guess is he does.
Cheers
On 4/1/25 08:59, tomas@tuxteam.de wrote:
On Tue, Apr 01, 2025 at 01:36:21PM +0100, mick.crane wrote:
On 2025-04-01 13:21, tomas@tuxteam.de wrote:
On Tue, Apr 01, 2025 at 12:42:46PM +0100, mick.crane wrote:
[...]
the spaces look wrong to meIf you mean those:
192.168.71.122 bpi51e5p.coyote.den bpi51 e5p #3dprinter^^^
...^^^
192.168.71.121 mkspi.coyote.den mkspi xmax3 # 3dprinter
... they are OK. They separate alternative host names. They mean
that 192.168.71.122 responds to "bpi51e5p.coyote.den", but also
"bpi51" and finally "e5p". Likewise for the other.
Yes, you can put as many space-separated names in a line as youCheersAh, thanks. I didn't know you could do that.
like (well: one or more).
But in a way you are right: the formatting is a bit funny and we
don't know whether OP means that. My guess is he does.
=yes. Some of that is spaces and some are tabs, the file does not care. Just to make it more interesting, t-bird doesn't paste tabs accurately.
But I'm far more interested in a critique of the nsswitch.conf also attached previously.
On Tue 01 Apr 2025 at 04:58:27 (-0400), gene heskett wrote:
On 3/31/25 23:02, David Wright wrote:So here you are, poking your system in one location, without taking
On Mon 31 Mar 2025 at 16:35:58 (-0400), gene heskett wrote:neither do I David, it doesn't make sense, but I've just found that
On 3/31/25 13:55, David Wright wrote:I don't know why you're using libnss-myhostname,
I don't know why you have problems with using /etc/hosts for lookups >>>>> on your LAN. I use it here without any problems, and it has to workbecause files doesn't work in bookworm, I had to:
because there's no DNS server in my router (too cheap).
$ grep hosts: /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns
grep hosts: /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
to make the hosts file work
file, except for that added word, is far different overall than the
man page example. So I've commented that word back out, and here is
what I have now, which bears no resemblance to the man page example;
account of how it's configured elsewhere. Perhaps that's how you find yourself in difficulties in the first place?
"I don't know why you're using libnss-myhostname" was an assumption
on the basis of your saying that you had to add "myhostname" to
make your system work. If you poke your system as randomly as you have
just done, then how would we have confidence in that being the one
change that originally made it work, and not anything else. We don't
even have solid evidence of (or the reason for) the libnss-myhostname
package being installed at all.
Also, changing configurations on a running system may well solve some
current problem, but it can affect how the system will boot up the
next time, and the effects may be deleterious. In any case, you said
your system is currently working, and took you a great deal of trouble
to make it do so, yet you're happy to moan about it, and then poke
around at random, and potentially remove some of the sticking plasters
that hold it all together.
you also called my hosts file unconventional, its been updated, is aWhat Brian pointed out in the thread: the lack of 127.0.1.1, the
totally private network, so not planet visible as its all my side of
the router. Whats unconventional.
conventional way in which Debian ensures a host can find its own
name when the network is not up.
You seem to have taken umbrageEasy for you to say, you don't have the aggravation of a machine that
against it for no good reason. (ISTR there was a long discussion
on the subject some years ago on the list.) Substituting it back
is not a panacea. And no one on this list is likely prepared to
spend a week, or however long, in unravelling your system.
Just live with it.
31.184.194.81 Sci-Hub.se scihub.seBTW, whatever they are, I don't think they're the same host.
Cheers,
David.
127.0.1.1 coyote.coyote.den coyote
[...]
I don't see the point in leaving it there. If you want to send
something to coyote.coyote.den, why do you want the LAN address
when 127.0.1.1 is just as good. If the line is correct, it does
nothing; if it's incorrect, it can cause harm.
On Wed 02 Apr 2025 at 09:12:24 (-0400), gene heskett wrote:
[...]
Experimenting I find the duplication does not seem to generate an
error, other than I now had to ping itself by address, since the name
is now found at 127.0.1.1 by pings lookup?
That's what you want: as the address is in the 127.0.0.0 network,
pinging it will ping itself, and it gets a reply. It doesn't
require your LAN to be set up, and AIUI it's like localhost
(127.0.0.1) in that it doesn't touch the network hardware.
I don't see the point in leaving it there. If you want to send
something to coyote.coyote.den, why do you want the LAN address
when 127.0.1.1 is just as good. If the line is correct, it does
nothing; if it's incorrect, it can cause harm.
I think the idea is, software can always use 127.0.1.1 to find the
host's fully qualified domain name,
I think the idea is, software can always use 127.0.1.1 to find the
host's fully qualified domain name, without the need to know real IP
address. (And what to do with multihomed hosts?)
Yeah, I'm going to lookup what Stevens has to say about the hosts file
in TCP/IP Illustrated. I need to figure out where the confusion lies.
On 2025-04-03, Dan Purgert <dan@djph.net> wrote:
That's what you want: as the address is in the 127.0.0.0 network,
pinging it will ping itself, and it gets a reply. It doesn't
require your LAN to be set up, and AIUI it's like localhost
(127.0.0.1) in that it doesn't touch the network hardware.
Indeed, the entirety of 127.0.0.0/8 is the virtual loopback adapter
(i.e. "localhost").
Doubtless yet another fallacious notion, but I thought IPV6 opened up
the flood gates of assigning "real" ip addresses to whatever the heck
Gene's talking about.
Greg Wooledge <greg@wooledge.org> wrote:
I'm just going to assume that it worked similarly to traditional X
sessions (e.g. the ones on HP-UX), where it looked up the system's hostname, and used whatever IP address that returned for connections between the X client and server.
I'm confused. Traditional X sessions in my experience use a Unix socket rather than a TCP connection when they are on the same host and don't
require the use of the hostname at all.
$ xeyes -display :0.0
I'm just going to assume that it worked similarly to traditional X
sessions (e.g. the ones on HP-UX), where it looked up the system's
hostname, and used whatever IP address that returned for connections
between the X client and server.
In any case, having the system's hostname map to a nonfunctional IP
address, or no IP address at all, causes enough problems that the
127.0.1.1 workaround for systems with no permanent address is a good
and useful solution.
Sent: Friday, April 04, 2025 at 6:10 AM
From: "Dan Purgert" <dan@djph.net>
To: debian-user@lists.debian.org
Subject: Re: DHCP and static addresses, nothing to do with Re: Who:Bookwormv.Trixie
On Apr 03, 2025, Greg wrote:
On 2025-04-03, Dan Purgert <dan@djph.net> wrote:
That's what you want: as the address is in the 127.0.0.0 network,
pinging it will ping itself, and it gets a reply. It doesn't
require your LAN to be set up, and AIUI it's like localhost
(127.0.0.1) in that it doesn't touch the network hardware.
Indeed, the entirety of 127.0.0.0/8 is the virtual loopback adapter (i.e. "localhost").
Doubtless yet another fallacious notion, but I thought IPV6 opened up
the flood gates of assigning "real" ip addresses to whatever the heck Gene's talking about.
Maybe? I honestly lost the plot to what he's trying to accomplish.
Everything will still have a "localhost" entry (albeit "::1" instead of
16 million valid options under 127.0.0.0/8), but yes, everything can
also have publicly routable addresses as well.
?
cat /etc/hosts
# Static table lookup for hostnames.
# See hosts(5) for details.
I have no need for a hosts file
On Thu 03 Apr 2025 at 06:55:10 (-0400), Greg Wooledge wrote:
I disagree with you here. The 127.0.1.1 address is a placeholder put
there by the installer for the more common case where a machine doesn't
have a fixed LAN IP address. Most home or workplace computers these
days will get their addresses from DHCP without a reservation, so their
internal addresses may vary.
And that means that two machines can't find each other unless the DHCP
server is also a DNS server. Or you set up and run your own.
But one disadvantage of your preferred approach is that the hostname
and domain won't resolve unless the network is up.
I don't know
whether that's why Gene installs/ed libnss-myhostname: I find the >documentation rather heavy going, and would have to experiment with
it a bit to make sense of it. I also don't know whether it would be
at all relevant to explaining Gene's following statement:
✄✄
$ grep hosts: /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns
because files doesn't work in bookworm, I had to:
grep hosts: /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
to make the hosts file work
✄✄
On Thu 03 Apr 2025 at 06:55:10 (-0400), Greg Wooledge wrote:Or you use mdns, which is the standard way of dealing with dynamic resources on an unmanaged network.
The resources stay fixed during their lifetime, and any changes that
occur are at a glacial pace. The network is managed, by me.
I also don't like the names that mDNS comes up with.
(That doesn't mean you have to use
mdns, it just means that if you instead decide to do something like
copy hosts files around the network you're choosing to make up your
own solution to the inherent problems that led to dns in the first
place.)
I can hardly take credit for inventing /etc/hosts. It's simple to set
up, and it causes no problems here. I don't think DNS was invented for resolving two dozen non-hierachical names on one site.
For various reasons I'd much rather configure a static IP in this
situation than set up a reservation on the dhcp server. Among other
things, in a small network the bespoke dhcp configuration is likely
going to cause pain that can't possibly outweigh the need to
reconfigure a static IP if for some strange reason it needs to change.
I don't know how to configure static IPs without a DHCP server when
there are devices that can only configure themselves by DHCP (or
maybe mDNS, I haven't tried). But what are the pain and the strange
reason?
Mostly,
to me, this falls into a weird place in wanting to use a complex
solution (static dhcp reservations) without taking the relatively
small additional step of just providing dns. Either go all the way
and provide all the normal facilities (which these days are often
baked into the router) instead of a mash-up, or go the easy route
and use dynamic dhcp and mdns.
Apart from configuring DNS, I don't want to have to run a dedicated
server 24/7. And none of the 24/7 routers has had DNS capability.
OTOH they've all had very simple interfaces for setting up static
DHCP reservations.
On Fri 11 Apr 2025 at 05:45:47 (-0400), Dan Purgert wrote:
(That doesn't mean you have to use
mdns, it just means that if you instead decide to do something like copy hosts files around the network you're choosing to make up your
own solution to the inherent problems that led to dns in the first place.)
I can hardly take credit for inventing /etc/hosts. It's simple to set
up, and it causes no problems here. I don't think DNS was invented for resolving two dozen non-hierachical names on one site.
That's exactly what DNS was invented for. Manually managing host files
is a pain after only a few hosts. Add one machine, and you have to
update 5,10,20,[...] host files.
So the last change I made was mid-November, for adding a new laptop.
I only change the DHCP when all my hosts are running. I login to
the router, add the reservation, and remove anything that has died
since the previous change, which was, as it happens, when I installed
my latest router in December 2023. I update the master file with the
same changes. I then run a script that transfers the master file
to the half-dozen hosts, edits the hosts own line to 127.0.1.1, and
prints a diff of the old and new versions. Finally a second script
does the same thing, except it overwrites all the old hosts files.
Yes, "Domain Names" do include hierarchy (e.g. "company.tld"); but
that's more an artifact that when RFC 1035 was written, we were already seeing convergence of names for common services (mail, telnet, ftp,
etc.).
Sure, but not at this site", unless you count my adding a .corp TLD
to all my hostnames in 2018. (I think at the time that was to quieten
exim, but smarthosts may also appreciate it.)
For various reasons I'd much rather configure a static IP in this situation than set up a reservation on the dhcp server. Among other things, in a small network the bespoke dhcp configuration is likely going to cause pain that can't possibly outweigh the need to reconfigure a static IP if for some strange reason it needs to change.
I don't know how to configure static IPs without a DHCP server when
there are devices that can only configure themselves by DHCP (or
maybe mDNS, I haven't tried). But what are the pain and the strange reason?
Correct -- if a device is stupidly-configured from the factory to
REQUIRE DHCP, then you need to use DHCP.
Welcome to the world of consumer electronics. Their /functionality/
is certainly not stupid.
mDNS is just a simplified name resolution tool. It doesn't do host configuration for network/netmask/gateway.
No, I think it's designed just for a single network. As I said above,
I've found it useful for driverless printing, but nothing else.
Sounds like getting a better router would be a good idea (I mean, when
the current one starts acting wonky). There are (or were) a handful of options that could manage to update the DNS resolver when new DHCP Hosts were added to the network (and, likewise, static entries for non-DHCP hosts).
Granted, these days, they may need *wrt or tomato firmwares, because the good features always seem to be the ones that go away. :(
My first router bought over here is now about 12 years old, cost $86
at Radio Shack (R.I.P), has lost its WAN port and one LAN port over
the years, but is still working. It's replacement cost $38 at Walmart
and is also still at work. The third one, which hosts the DHCP server,
cost all of $14 at Staples (clearance). So I've got great coverage
with 3 APs, and one device could die with limited degradation, so
I can't say I'm in the market for yet another, and I've see no need
for a DNS server here.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 149:29:32 |
| Calls: | 10,383 |
| Calls today: | 8 |
| Files: | 14,054 |
| D/L today: |
2 files (1,861K bytes) |
| Messages: | 6,417,769 |