Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #244291 > unrolled thread
| Started by | gene heskett <gheskett@shentel.net> |
|---|---|
| First post | 2022-01-22 00:50 +0100 |
| Last post | 2022-01-22 10:20 +0100 |
| Articles | 20 on this page of 78 — 16 participants |
Back to article view | Back to linux.debian.user
hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-22 00:50 +0100
Re: hostname is being reset, killing net on reboot "Andrew M.A. Cater" <amacater@einval.com> - 2022-01-22 00:50 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-22 01:30 +0100
Re: hostname is being reset, killing net on reboot Greg Wooledge <greg@wooledge.org> - 2022-01-22 01:50 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-22 03:40 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-22 04:10 +0100
Re: hostname is being reset, killing net on reboot Greg Wooledge <greg@wooledge.org> - 2022-01-22 04:50 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-22 06:00 +0100
Re: hostname is being reset, killing net on reboot <tomas@tuxteam.de> - 2022-01-22 08:10 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-22 10:40 +0100
Re: hostname is being reset, killing net on reboot <tomas@tuxteam.de> - 2022-01-22 11:20 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-22 13:20 +0100
Re: hostname is being reset, killing net on reboot Andrei POPESCU <andreimpopescu@gmail.com> - 2022-01-23 09:10 +0100
Re: hostname is being reset, killing net on reboot David Wright <deblis@lionunicorn.co.uk> - 2022-01-22 18:20 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-22 20:00 +0100
Re: hostname is being reset, killing net on reboot Greg Wooledge <greg@wooledge.org> - 2022-01-22 22:30 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-23 00:40 +0100
Re: hostname is being reset, killing net on reboot The Wanderer <wanderer@fastmail.fm> - 2022-01-23 01:10 +0100
Re: hostname is being reset, killing net on reboot David Wright <deblis@lionunicorn.co.uk> - 2022-01-23 03:10 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-23 03:30 +0100
Re: hostname is being reset, killing net on reboot The Wanderer <wanderer@fastmail.fm> - 2022-01-23 03:40 +0100
Re: hostname is being reset, killing net on reboot David Wright <deblis@lionunicorn.co.uk> - 2022-01-23 03:10 +0100
Re: hostname is being reset, killing net on reboot Andrei POPESCU <andreimpopescu@gmail.com> - 2022-01-23 09:00 +0100
Re: hostname is being reset, killing net on reboot Greg Wooledge <greg@wooledge.org> - 2022-01-23 14:50 +0100
Re: hostname is being reset, killing net on reboot Felix Miata <mrmazda@earthlink.net> - 2022-01-23 19:30 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-23 20:00 +0100
Re: hostname is being reset, killing net on reboot Brian <ad44@cityscape.co.uk> - 2022-01-23 20:10 +0100
Re: hostname is being reset, killing net on reboot Charles Curley <charlescurley@charlescurley.com> - 2022-01-23 21:00 +0100
Re: hostname is being reset, killing net on reboot Brian <ad44@cityscape.co.uk> - 2022-01-24 00:50 +0100
Re: hostname is being reset, killing net on reboot Charles Curley <charlescurley@charlescurley.com> - 2022-01-24 01:20 +0100
Re: hostname is being reset, killing net on reboot Greg Wooledge <greg@wooledge.org> - 2022-01-23 21:10 +0100
Re: hostname is being reset, killing net on reboot Felix Miata <mrmazda@earthlink.net> - 2022-01-23 21:20 +0100
Re: hostname is being reset, killing net on reboot Brian <ad44@cityscape.co.uk> - 2022-01-24 01:00 +0100
Re: hostname is being reset, killing net on reboot David Wright <deblis@lionunicorn.co.uk> - 2022-01-24 17:40 +0100
Re: hostname is being reset, killing net on reboot Brian <ad44@cityscape.co.uk> - 2022-01-25 01:00 +0100
Re: hostname is being reset, killing net on reboot Andrei POPESCU <andreimpopescu@gmail.com> - 2022-01-25 09:40 +0100
Re: hostname is being reset, killing net on reboot Brian <ad44@cityscape.co.uk> - 2022-01-25 12:20 +0100
Re: hostname is being reset, killing net on reboot Andrei POPESCU <andreimpopescu@gmail.com> - 2022-01-25 13:10 +0100
Re: hostname is being reset, killing net on reboot Brian <ad44@cityscape.co.uk> - 2022-01-25 17:30 +0100
Re: hostname is being reset, killing net on reboot Brian <ad44@cityscape.co.uk> - 2022-01-25 18:00 +0100
Re: hostname is being reset, killing net on reboot David Wright <deblis@lionunicorn.co.uk> - 2022-01-26 01:40 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-26 03:30 +0100
Re: hostname is being reset, killing net on reboot Greg Wooledge <greg@wooledge.org> - 2022-01-26 05:20 +0100
Re: hostname is being reset, killing net on reboot David Wright <deblis@lionunicorn.co.uk> - 2022-01-26 05:40 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-26 11:20 +0100
Re: hostname is being reset, killing net on reboot David Wright <deblis@lionunicorn.co.uk> - 2022-01-26 17:50 +0100
Re: hostname is being reset, killing net on reboot Greg Wooledge <greg@wooledge.org> - 2022-01-26 18:00 +0100
Re: hostname is being reset, killing net on reboot Andrei POPESCU <andreimpopescu@gmail.com> - 2022-01-26 19:00 +0100
Re: hostname is being reset, killing net on reboot David Wright <deblis@lionunicorn.co.uk> - 2022-01-27 06:10 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-26 23:40 +0100
Re: hostname is being reset, killing net on reboot Andrei POPESCU <andreimpopescu@gmail.com> - 2022-01-26 19:20 +0100
Re: hostname is being reset, killing net on reboot Reco <recoverym4n@enotuniq.net> - 2022-01-26 20:00 +0100
Re: hostname is being reset, killing net on reboot Brian <ad44@cityscape.co.uk> - 2022-01-26 16:40 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-26 16:50 +0100
Re: hostname is being reset, killing net on reboot Brian <ad44@cityscape.co.uk> - 2022-01-26 16:50 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-26 23:40 +0100
Re: hostname is being reset, killing net on reboot Brian <ad44@cityscape.co.uk> - 2022-01-26 17:10 +0100
Re: hostname is being reset, killing net on reboot David Wright <deblis@lionunicorn.co.uk> - 2022-01-26 17:50 +0100
Re: hostname is being reset, killing net on reboot Brian <ad44@cityscape.co.uk> - 2022-01-26 20:30 +0100
Re: hostname is being reset, killing net on reboot Greg Wooledge <greg@wooledge.org> - 2022-01-26 20:50 +0100
Re: hostname is being reset, killing net on reboot Tixy <tixy@yxit.co.uk> - 2022-01-27 09:30 +0100
Re: hostname is being reset, killing net on reboot Dan Ritter <dsr@randomstring.org> - 2022-01-27 12:40 +0100
Re: hostname is being reset, killing net on reboot Brian <ad44@cityscape.co.uk> - 2022-01-27 15:10 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-23 22:50 +0100
Re: hostname is being reset, killing net on reboot David Wright <deblis@lionunicorn.co.uk> - 2022-01-23 17:00 +0100
Re: hostname is being reset, killing net on reboot Andrei POPESCU <andreimpopescu@gmail.com> - 2022-01-22 09:20 +0100
Re: hostname is being reset, killing net on reboot Lee <ler762@gmail.com> - 2022-01-23 03:00 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-23 03:20 +0100
Re: hostname is being reset, killing net on reboot <tomas@tuxteam.de> - 2022-01-22 08:00 +0100
Re: hostname is being reset, killing net on reboot David Wright <deblis@lionunicorn.co.uk> - 2022-01-22 18:20 +0100
Re: hostname is being reset, killing net on reboot <tomas@tuxteam.de> - 2022-01-22 07:50 +0100
Re: hostname is being reset, killing net on reboot Charles Curley <charlescurley@charlescurley.com> - 2022-01-22 15:40 +0100
Re: hostname is being reset, killing net on reboot <tomas@tuxteam.de> - 2022-01-22 17:10 +0100
Re: hostname is being reset, killing net on reboot gene heskett <gheskett@shentel.net> - 2022-01-22 23:30 +0100
Re: hostname is being reset, killing net on reboot "Andrew M.A. Cater" <amacater@einval.com> - 2022-01-23 00:00 +0100
Re: hostname is being reset, killing net on reboot deloptes <emanoil.kotsev@deloptes.org> - 2022-01-23 09:00 +0100
Re: hostname is being reset, killing net on reboot Curt <curty@free.fr> - 2022-01-22 10:10 +0100
Re: hostname is being reset, killing net on reboot <tomas@tuxteam.de> - 2022-01-22 10:20 +0100
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2022-01-23 03:40 +0100 |
| Message-ID | <DIAXo-2Ew-3@gated-at.bofh.it> |
| In reply to | #244386 |
[Multipart message — attachments visible in raw view] — view raw
On 2022-01-22 at 21:23, gene heskett wrote: > On Saturday, January 22, 2022 9:08:02 PM EST David Wright wrote: > >> On Sat 22 Jan 2022 at 19:07:35 (-0500), The Wanderer wrote: >> > This is the line which contains the directives involved. >> > >> > The 'files' directive tells your system to check local files first; >> > the list of files involved is in the FILES section near the end of >> > 'man nsswitch.conf', and /etc/hosts is in that list. >> > >> > The 'mdns4_minimal' directive tells your system to check "multicast >> > DNS" first; I'm not familiar with the details of this, but Google >> > should be helpful. The [NOTFOUND=return] tag says - I think - that >> > if this check returns a report that the lookup was successful but >> > that no match was found, the system should return that result and >> > stop checking. >> > >> > The 'dns' directive tells your system to check the DNS system proper. >> > Given that this is after the [NOTFOUND=return] tag, as far as I can >> > see this should never be reached, but I presume it's there for a >> > reason; my best guess is that mDNS will usually not be available, so >> > the check will return UNAVAIL, which (per the man page) will by >> > default tell the system to continue to the next check (which is this >> > one). >> >> Rather than its not being available, it shouldn't even try with mDNS >> unless the name ends in .local, so it will skip to dns. Hmm. Looking at nsswitch.conf(5), it seems clear that the mdns4_minimal module must return *something* in that case, so I wonder what it might be. The obvious thing to return is NOTFOUND, but this tag turns the result of that from "continue to try the next thing" to "stop processing, and report back that no match was found", so that isn't plausible. >> This is what catches people out when they think that .local is a good >> choice for some random LAN, rather than one from the recommended list: >> .corp, .home or .mail. >> > You're changing the subject again. It doesn't look that way to me; he's explaining something I misunderstood, which provides more context. This might be branching out a bit from what your original discussion was about, but that's neither unexpected (thread drift is a thing, as are subthreads) nor - so long as your original subject is still being addressed, which it seems to be - a real problem. > AFAIK, the only .local is in the users directory, as a subdir. Exactly > NONE of my hostnames contain a .local postfix. That's exactly as expected. For the hostnames which are in /etc/hosts, the lookup process won't ever get this far, so the question of a '.local' suffix won't even become relevant. For the hostnames which aren't in that file, since none of them have that suffix, the mdns4_minimal entry in nsswitch.conf won't ever trigger, so any names that get that far will just proceed on for lookup via standard DNS. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2022-01-23 03:10 +0100 |
| Message-ID | <DIAum-2vr-7@gated-at.bofh.it> |
| In reply to | #244348 |
On Sat 22 Jan 2022 at 13:57:38 (-0500), gene heskett wrote:
> On Saturday, January 22, 2022 12:14:20 PM EST David Wright wrote:
> > On Sat 22 Jan 2022 at 11:13:59 (+0100), tomas@tuxteam.de wrote:
> > > On Sat, Jan 22, 2022 at 04:38:04AM -0500, gene heskett wrote:
> > > > On Saturday, January 22, 2022 2:04:32 AM EST tomas@tuxteam.de
> wrote:
> > > [...]
> > >
> > > > > Once that part is flying, tackle names :)
> > >
> > > I stay still by this :)
> > >
> > > > But, I found, quite by serendipity, in the raspios version of
> > > > bullseye, a fix. Look at the bottom of /etc/dhcpdcp.conf,
> > > >
> > > ^^^^^^^
> > >
> > > ...that one looks like a typo to me. On my (not quite standard,
> > > because I avoid systemd) Debian buster, there is a /etc/dhcp
> > > hierarchy, with a dhclient.conf, which gets into action whenever my
> > > machine requests an IP address (typically when I do "ifup foo", for
> > > foo in eth0 or wlan0.
> > >
> > > The host name does figure there: it goes out with the request, in
> > > case
> > > the DHCP server wants to take decisions based on that. No DHCP server
> > > I interact with takes notice, but they might.
> > >
> > > This is the only connection I see.
> > >
> > > That filename directly at top-level looks to me pretty
> > > raspi-specific.
> > > Is it configuring some DHCP server, or your client?
> >
> > It looks like Gene might be talking about /etc/dhcpcd.conf from
> > dhcpcd5_7.1.0-2+b1_amd64.deb (or the appropriate hardware).
> > In any case, it looks like an instance of "make some change in
> > some file until it works", which is fine until any of a reboot,
> > an upgrade, a change somewhere else in the system, etc which
> > causes it to stop working.
> >
> > And when posts starts appearing here again, Gene's system is
> > even more unlike anybody else's than it is today.
> >
> > Cheers,
> > David.
>
> Ok David, perhaps you can explain to me why my use of an identical hosts
> file on every machine in my tiny home network to describe my local
> network is bad, to be denigrated at every turn of the screw you can
> manage.
Because the basic /etc/hosts file looks something like:
127.0.0.1 localhost
192.168.1.1 router.corp router
192.168.1.2 cascade.corp cascade
127.0.1.1 acer.corp acer # 192.168.1.10
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
and the hostname, acer, will be different on each host.
> So my resolv.conf says to search coyote.den, and failing that, use my
> isp's nameserver by relaying the request for lookup to my router, which
> in turn querys my isp after NATing the request, to look up the name.
So you're using some local DNS server to resolve hostnames on your
LAN. Where's it getting that information from? Is it up to date?
> That way the only 2 limitations on local host and domain names is that
> they cannot start with a number, but must be alpha. And they must NOT be
> volatile. Which explains why one of my machines, a 6040 4 axis milliing
> machine, is called sixty40.coyote.den.
I don't know why you tried that corner case. Back then, you wrote:
"Is that a bug? Or is there a specific reason for the silent failure?
In which case, it really ought to be a little mouthier about the failure."
The whole point is that there is no "it". Somewhere—anywhere—there
will be some code that makes a false assumption. Just avoid it by
scanning RFC1178.
> Linux goes out of its way to kill networking by ignoring what I put in a
> file in /etc/network/interfaces.d/anyoldname. And when some coder dinking
> around in dhcp code thinks the whole world is volatile, and changes a
> hostname just because they can boggles my mind. But its the only way to
> have a sane local network with STABLE names and addresses.
No idea what you're talking about here.
> So convince me how I can build a stable local network using dhcp that
> still allows me to "ssh -Y rpi4" and know for 100% certainty that dhcp
> hasn't rerouted my ssh session to tlm.coyote.den.
I can't. You have this wonderful router that contains DHCP and DNS,
where you flashed in the software, and I know nothing about it.
> To me its unnecessary complexity to even run a nameserver of any kind on
> my local network. Makes zero sense to me, I've been doing it this for 25
> years now, how long have you?
I don't run a nameserver, and I don't attempt to. My $35 router has a
list of MACs for every device in the house, and a corresponding IPaddr
for each. It gets sent names by devices but, on the whole, they aren't
useful and best ignored.
All the devices get their addresses by DHCP from the router, except
that my laptops override the wired address with a static IPaddr that
matches their DHCP wireless one. That just means that the laptop will
have the same IPaddr whether wired or wireless.
For resolving these hosts, I use the /etc/hosts file. The master list
resides in /root on my admin/day-to-day machine, and a script edits
the appropriate line as shown above for acer, appends ~13000 fake
127.0.0.1 addresses, and dispatches it to acer in this case. That's
all because my $35 router "unbelievably" doesn't have a DNS server.
BTW,
$ grep hosts /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.1.1
$
I don't specify any domain information in the resolver: names are
either on the LAN or they're passed to 192.168.1.1 and thereby to
the addresses set in the router, currently 8.8.8.8 and 8.8.4.4.
I'm not sure why you have to use coyote.den. My .corp exists solely
to make exim a little happier.
> Unless you can tell me how to get a STABLE, Just Works local network
> using dhcpd, I'll keep on doing it my way. That is a question I've asked
> one way or another on various lists, without ever getting a step by step
> instruction on how to make a far more complex method Just Work. To me
> there has to be a STABLE place to start, and that hostname files contents
> is it IMNSHO.
↑↑↑↑↑↑↑↑↑↑↑↑↑↑
The hostname file is for the machine itself, not for getting to it.
The host has one name, but each interface could have a different name
and address for reaching it.
> Can you understand my anger when I edit /etc/hostname to call a machine
> an "rpi4", reboot it, no network, something has taken upon itself the
> authority to make a cat /etc/hostname return "raspberry" after a reboot.
Not really. I don't have a clue how your machines boot up. It /would/
worry me if it changed on my machines without my knowing why, but
that's a different problem.
> That is bs, usually found on the ground, warm and smelly, behind the male
> of the bovine specie. Its gotten a bit less smelly in recent years, but I
> used to have to chattr +i both the /etc/hostname and /etc/resolv.conf
> files to make it work reliably at every reboot. I think jessie was the
> last time I had to do that.
>
> I was about to revert to doing it again when I found the last 2
> paragraphs in the bottom of the /etc/dhcpdcp.conf file on the rpi4, which
> has the effect of the last word if a dhcpd server can't be found.
Sorry, I don't know why you're having to mess about with a dhcp
configuration file when you're not using DHCP (it that's actually so).
> Since the list seems determined to keep this thread alive, I'll wait for
> an explanation I can print, take around to all my machines and follow to
> implement it YOUR way. But I'm not going on a hunger strike until that
> happens.
I'm not worried about whether you use /my/ way, but it is odd that you
seem to take pride in the fact that you (claim to) set it up the way
you did on an Amiga in the 1980s.
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2022-01-23 09:00 +0100 |
| Message-ID | <DIFX4-5F9-5@gated-at.bofh.it> |
| In reply to | #244382 |
[Multipart message — attachments visible in raw view] — view raw
On Sb, 22 ian 22, 20:07:45, David Wright wrote: > > Because the basic /etc/hosts file looks something like: > > 127.0.0.1 localhost > 192.168.1.1 router.corp router > 192.168.1.2 cascade.corp cascade > 127.0.1.1 acer.corp acer # 192.168.1.10 > # The following lines are desirable for IPv6 capable hosts > ::1 localhost ip6-localhost ip6-loopback > ff02::1 ip6-allnodes > ff02::2 ip6-allrouters > > and the hostname, acer, will be different on each host. Instead of listing the machine's name with 127.0.1.1 I'm using it's actual IP (like the one you have in the comment). Any potential issues I should be aware of? As far as I can tell (with my limited understanding of DNS) it only makes it easier to share /etc/hosts with no obvious downside. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2022-01-23 14:50 +0100 |
| Message-ID | <DILpM-Am-7@gated-at.bofh.it> |
| In reply to | #244392 |
On Sun, Jan 23, 2022 at 08:50:56AM +0100, Andrei POPESCU wrote: > On Sb, 22 ian 22, 20:07:45, David Wright wrote: > > > > Because the basic /etc/hosts file looks something like: > > > > 127.0.0.1 localhost > > 192.168.1.1 router.corp router > > 192.168.1.2 cascade.corp cascade > > 127.0.1.1 acer.corp acer # 192.168.1.10 > > # The following lines are desirable for IPv6 capable hosts > > ::1 localhost ip6-localhost ip6-loopback > > ff02::1 ip6-allnodes > > ff02::2 ip6-allrouters > > > > and the hostname, acer, will be different on each host. > > Instead of listing the machine's name with 127.0.1.1 I'm using it's > actual IP (like the one you have in the comment). > > Any potential issues I should be aware of? > > As far as I can tell (with my limited understanding of DNS) it only > makes it easier to share /etc/hosts with no obvious downside. If that actually works, that's great news for Gene. It means he can duplicate a single /etc/hosts file across all systems without needing to bolt on a unique per-system header afterward. In terms of operation, the main difference as far as I understand it is that a connection to "acer" (or whatever your system's own name is) will be directed to the ethernet interface instead of the loopback interface. So, if you've got a daemon that's only bound to loopback, you would need to contact it via the name "localhost" rather than the system's name. Whereas in the regular Debian setup that has 127.0.1.1 bound to the system's name, either one works.
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2022-01-23 19:30 +0100 |
| Message-ID | <DIPMK-3hn-9@gated-at.bofh.it> |
| In reply to | #244417 |
Greg Wooledge composed on 2022-01-23 08:42 (UTC-0500): > On Sun, Jan 23, 2022 at 08:50:56AM +0100, Andrei POPESCU wrote: >> As far as I can tell (with my limited understanding of DNS) it only >> makes it easier to share /etc/hosts with no obvious downside. > If that actually works, that's great news for Gene. It means he can > duplicate a single /etc/hosts file across all systems without needing > to bolt on a unique per-system header afterward. I've been sharing the very same hosts file among all my PCs for well over a decade, probably closer to two. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2022-01-23 20:00 +0100 |
| Message-ID | <DIQfM-3rf-5@gated-at.bofh.it> |
| In reply to | #244431 |
On Sunday, January 23, 2022 1:26:56 PM EST Felix Miata wrote: > Greg Wooledge composed on 2022-01-23 08:42 (UTC-0500): > > On Sun, Jan 23, 2022 at 08:50:56AM +0100, Andrei POPESCU wrote: > >> As far as I can tell (with my limited understanding of DNS) it only > >> makes it easier to share /etc/hosts with no obvious downside. > > > > If that actually works, that's great news for Gene. It means he can > > duplicate a single /etc/hosts file across all systems without needing > > to bolt on a unique per-system header afterward. > > I've been sharing the very same hosts file among all my PCs for well > over a decade, probably closer to two. And I have been for 2 decades and change as it once had an amiga as one of its clients. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2022-01-23 20:10 +0100 |
| Message-ID | <DIQps-3JJ-1@gated-at.bofh.it> |
| In reply to | #244435 |
On Sun 23 Jan 2022 at 13:53:01 -0500, gene heskett wrote: > On Sunday, January 23, 2022 1:26:56 PM EST Felix Miata wrote: > > Greg Wooledge composed on 2022-01-23 08:42 (UTC-0500): > > > On Sun, Jan 23, 2022 at 08:50:56AM +0100, Andrei POPESCU wrote: > > >> As far as I can tell (with my limited understanding of DNS) it only > > >> makes it easier to share /etc/hosts with no obvious downside. > > > > > > If that actually works, that's great news for Gene. It means he can > > > duplicate a single /etc/hosts file across all systems without needing > > > to bolt on a unique per-system header afterward. > > > > I've been sharing the very same hosts file among all my PCs for well > > over a decade, probably closer to two. > > And I have been for 2 decades and change as it once had an amiga as one > of its clients. What advice would you give to a user regarding the benefits of a hosts file as opposed to more modern techniques? -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Charles Curley <charlescurley@charlescurley.com> |
|---|---|
| Date | 2022-01-23 21:00 +0100 |
| Message-ID | <DIRbP-3Zt-7@gated-at.bofh.it> |
| In reply to | #244437 |
On Sun, 23 Jan 2022 19:09:27 +0000 Brian <ad44@cityscape.co.uk> wrote: > What advice would you give to a user regarding the benefits of a hosts > file as opposed to more modern techniques? By "more modern techniques" I will assume you mean DHCP and DNS. Hosts files are simple, easy to do. They have to be propagated and maintained, so they are obnoxious from time to time. With no DHCP, you have to had configure each host's network interface, usually at installation time, or when you introduce a computer to your network. This isn't always possible. Also, you will still need a DNS client on each machine so they can resolve external host names. DNS and DHCP require a lot more configuration up front. But once they are done, that can be all you have to do, and you shouldn't have to do anything at installation or introduction time. You can use DHCP to assign fixed IP addresses to some (or all) hosts, but that means some one-time configuration. A side benefit of running your own DNS server is that your hosts look to it, rather than to your ISP's server, which usually means faster turn-around time for lookups. Which is easier depends in part on how many hosts you have at any one time, what they are, and how often new ones arrived. These days, new arrivals may also mean guests' mobile phones and laptops. It may also mean "smart" gadgets. I have a pressure cooker on my network, and I doubt the creators of DNS had those in mind way back when. I don't think my pressure cooker has any way to manually configure its IP address, so it pretty well requires DHCP. If I were running an internet cafe or a computer repair shop, I would insist on DHCP and DNS. At the other end of the scale, if you only have a few machines and don't care about your guests' machines or "smart" gadgets, a hosts file may be simpler. I hope that provides some guidance. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2022-01-24 00:50 +0100 |
| Message-ID | <DIUMp-6bs-3@gated-at.bofh.it> |
| In reply to | #244441 |
On Sun 23 Jan 2022 at 12:52:27 -0700, Charles Curley wrote: > On Sun, 23 Jan 2022 19:09:27 +0000 > Brian <ad44@cityscape.co.uk> wrote: > > > What advice would you give to a user regarding the benefits of a hosts > > file as opposed to more modern techniques? > > By "more modern techniques" I will assume you mean DHCP and DNS. > > Hosts files are simple, easy to do. They have to be propagated and > maintained, so they are obnoxious from time to time. I was rather hoping for some mention of the role of Avahi and libnss-mdns on the local network amd its minimal maintenamce. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Charles Curley <charlescurley@charlescurley.com> |
|---|---|
| Date | 2022-01-24 01:20 +0100 |
| Message-ID | <DIVfr-6Ao-1@gated-at.bofh.it> |
| In reply to | #244468 |
On Sun, 23 Jan 2022 23:42:33 +0000 Brian <ad44@cityscape.co.uk> wrote: > I was rather hoping for some mention of the role of Avahi and > libnss-mdns on the local network amd its minimal maintenamce. I seem to have it installed, mostly to support an apple Macbook. But I did not configure it in any way. Apparently, it Just Works™, at least for the small use I make of it. Someone else will have to help you there. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2022-01-23 21:10 +0100 |
| Message-ID | <DIRlv-4i7-5@gated-at.bofh.it> |
| In reply to | #244437 |
On Sun, Jan 23, 2022 at 07:09:27PM +0000, Brian wrote: > On Sun 23 Jan 2022 at 13:53:01 -0500, gene heskett wrote: > > > On Sunday, January 23, 2022 1:26:56 PM EST Felix Miata wrote: > > > Greg Wooledge composed on 2022-01-23 08:42 (UTC-0500): > > > > On Sun, Jan 23, 2022 at 08:50:56AM +0100, Andrei POPESCU wrote: > > > >> As far as I can tell (with my limited understanding of DNS) it only > > > >> makes it easier to share /etc/hosts with no obvious downside. > > > > > > > > If that actually works, that's great news for Gene. It means he can > > > > duplicate a single /etc/hosts file across all systems without needing > > > > to bolt on a unique per-system header afterward. > > > > > > I've been sharing the very same hosts file among all my PCs for well > > > over a decade, probably closer to two. > > > > And I have been for 2 decades and change as it once had an amiga as one > > of its clients. > > What advice would you give to a user regarding the benefits of a hosts > file as opposed to more modern techniques? I'll treat this question as "static interface configuration and hosts files". The advantage is that it's conceptually simpler. The disadvantages are numerous. * Adding a new host, or changing a host's IP address, requires platform-specific knowledge on the host in question. On a heterogeneous network, that means you need knowledge of how to do this on all the different platforms. This may include devices like printers, where it's quite difficult, maybe even impossible, to configure an address without DHCP. * After a change is made, it has to be replicated across your entire network. Manually. * Any "visitor" machines that are temporarily added to your network will need to be configured manually, and they will have zero knowledge of the other hosts on the network. Even if you know their names, there won't be any DNS in which you can look up their addresses. For anyone setting up a new home network, I'd recommend using DHCP. It will be a lot simpler in the long run, especially if you start adding wireless devices (cell phones, tablets, TV streaming devices, etc.). Your router probably already acts as a DHCP server, so all you need to do is learn how to configure fixed addresses for specific computers (and printers) that want to act like servers. The other devices can just get random addresses. Guest machines can just be connected and start working without issues.
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2022-01-23 21:20 +0100 |
| Message-ID | <DIRvb-4l8-3@gated-at.bofh.it> |
| In reply to | #244443 |
Greg Wooledge composed on 2022-01-23 15:01 (UTC-0500): > * After a change is made, it has to be replicated across your entire > network. Manually. But trivial. > * Any "visitor" machines that are temporarily added to your network will > need to be configured manually, and they will have zero knowledge of > the other hosts on the network. Even if you know their names, there > won't be any DNS in which you can look up their addresses. This can be an advantage. I don't need or want visitors' cell phones accessing my machines willy nilly. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2022-01-24 01:00 +0100 |
| Message-ID | <DIUW5-6eO-5@gated-at.bofh.it> |
| In reply to | #244447 |
On Sun 23 Jan 2022 at 15:14:54 -0500, Felix Miata wrote: > > > Greg Wooledge composed on 2022-01-23 15:01 (UTC-0500): > > > * After a change is made, it has to be replicated across your entire > > network. Manually. > > But trivial. Manual intervention as opposed to no intervention. What price libnss-mdns? > > > * Any "visitor" machines that are temporarily added to your network will > > need to be configured manually, and they will have zero knowledge of > > the other hosts on the network. Even if you know their names, there > > won't be any DNS in which you can look up their addresses. > > This can be an advantage. I don't need or want visitors' cell phones accessing my > machines willy nilly. You obviously do not trust your network setup sufficiently to allow access to it from other devices. Something to be attemded to. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2022-01-24 17:40 +0100 |
| Message-ID | <DJaxQ-7ya-5@gated-at.bofh.it> |
| In reply to | #244443 |
On Sun 23 Jan 2022 at 15:01:09 (-0500), Greg Wooledge wrote:
> On Sun, Jan 23, 2022 at 07:09:27PM +0000, Brian wrote:
> > On Sun 23 Jan 2022 at 13:53:01 -0500, gene heskett wrote:
> > > On Sunday, January 23, 2022 1:26:56 PM EST Felix Miata wrote:
> > > > Greg Wooledge composed on 2022-01-23 08:42 (UTC-0500):
> > > > > On Sun, Jan 23, 2022 at 08:50:56AM +0100, Andrei POPESCU wrote:
> > > > >> As far as I can tell (with my limited understanding of DNS) it only
> > > > >> makes it easier to share /etc/hosts with no obvious downside.
> > > > >
> > > > > If that actually works, that's great news for Gene. It means he can
> > > > > duplicate a single /etc/hosts file across all systems without needing
> > > > > to bolt on a unique per-system header afterward.
> > > >
> > > > I've been sharing the very same hosts file among all my PCs for well
> > > > over a decade, probably closer to two.
> > >
> > > And I have been for 2 decades and change as it once had an amiga as one
> > > of its clients.
> >
> > What advice would you give to a user regarding the benefits of a hosts
> > file as opposed to more modern techniques?
>
> I'll treat this question as "static interface configuration and hosts
> files".
>
> The advantage is that it's conceptually simpler.
>
> The disadvantages are numerous.
>
> * Adding a new host, or changing a host's IP address, requires
> platform-specific knowledge on the host in question. On a
> heterogeneous network, that means you need knowledge of how to do
> this on all the different platforms. This may include devices like
> printers, where it's quite difficult, maybe even impossible, to
> configure an address without DHCP.
>
> * After a change is made, it has to be replicated across your entire
> network. Manually.
>
> * Any "visitor" machines that are temporarily added to your network will
> need to be configured manually, and they will have zero knowledge of
> the other hosts on the network. Even if you know their names, there
> won't be any DNS in which you can look up their addresses.
>
> For anyone setting up a new home network, I'd recommend using DHCP. It
> will be a lot simpler in the long run, especially if you start adding
> wireless devices (cell phones, tablets, TV streaming devices, etc.).
> Your router probably already acts as a DHCP server, so all you need to
> do is learn how to configure fixed addresses for specific computers (and
> printers) that want to act like servers. The other devices can just get
> random addresses. Guest machines can just be connected and start working
> without issues.
Yes, I'd agree with all those arguments for DHCP, which is why I use
it, hence its inclusion in my post at the top of this subthread, and
why I can't understand Gene's aversion to it. But that's all about
configuration, and the quoted comment at the top of this post is AIUI
about /resolving/ hostnames through /etc/hosts.
Some of us (not including Gene) don't have DNS resolvers built into
our routers, and don't want to have to run 24/7 yet another piece of
hardware (other than the already necessary modem and router
(routers in my case).
So from the list of IP addresses, hostnames and MAC addresses,
configured into and printed out from my master router, I compiled
a master list of the first and second items, which is transformed
into /etc/hosts as already shown. From the length of my list,
I'd estimate an addition or deletion occurs about twice a year—
less frequently really, as often they're paired +-.
(And I did answer Andrei's comment, albeit after you'd posted.
It's no harder to distribute transformed files than identical ones.)
But to get back to Gene's network, and his lack of certainty that,
when "ssh -Y rpi4" is typed, "dhcp hasn't rerouted my ssh session
to tlm.coyote.den." Well, from what we've been told (or it might be
from what's been gleaned over the years), we have a dozen machines
with, we hope, identical lists of hostname≡IPaddress in /etc/hosts,
but instead of a single location for their IPaddress configuration,
we have a dozen /e/n/i files. Just to make it more difficult to check
them, none of the latter will contain a hostname, of course, but only
a static IP address.
That seems a lot less robust than having two lists that can be
compared side by side, as I described in my own setup. If I had
a setup like that, I'd make sure that my /etc/hosts-distribution
script provoked a script on the target to check that the address
in /e/n/i matched the target's entry in /etc/hosts.
A couple of posts further up this subthread:
> > > > >> On Sb, 22 ian 22, 20:07:45, David Wright wrote:
> > > > >> > On Sat 22 Jan 2022 at 13:57:38 (-0500), gene heskett wrote:
> > > > >> > > Linux goes out of its way to kill networking by ignoring what I put in a
> > > > >> > > file in /etc/network/interfaces.d/anyoldname. And when some coder dinking
> > > > >> > > around in dhcp code thinks the whole world is volatile, and changes a
> > > > >> > > hostname just because they can boggles my mind. But its the only way to
> > > > >> > > have a sane local network with STABLE names and addresses.
> > > > >> > No idea what you're talking about here.
It later struck me that there's a clue in Gene writing: "Linux [ignores]
what I put in a file in /etc/network/interfaces.d/anyoldname."
I can only assume that that means Gene has observed a disagreement between:
/etc/hosts on any host containing
IPADDR HOSTNAME
and:
/etc/network/interfaces.d/anyoldname on the host HOSTNAME containing
address IPADDR/24
Unless, of course, Gene has "nuked" /e/n/i (strictly, the file
/etc/network/interfaces itself).
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2022-01-25 01:00 +0100 |
| Message-ID | <DJhpD-394-3@gated-at.bofh.it> |
| In reply to | #244522 |
On Mon 24 Jan 2022 at 10:39:01 -0600, David Wright wrote: > On Sun 23 Jan 2022 at 15:01:09 (-0500), Greg Wooledge wrote: > > On Sun, Jan 23, 2022 at 07:09:27PM +0000, Brian wrote: > > > On Sun 23 Jan 2022 at 13:53:01 -0500, gene heskett wrote: > > > > On Sunday, January 23, 2022 1:26:56 PM EST Felix Miata wrote: > > > > > Greg Wooledge composed on 2022-01-23 08:42 (UTC-0500): > > > > > > On Sun, Jan 23, 2022 at 08:50:56AM +0100, Andrei POPESCU wrote: > > > > > >> As far as I can tell (with my limited understanding of DNS) it only > > > > > >> makes it easier to share /etc/hosts with no obvious downside. > > > > > > > > > > > > If that actually works, that's great news for Gene. It means he can > > > > > > duplicate a single /etc/hosts file across all systems without needing > > > > > > to bolt on a unique per-system header afterward. > > > > > > > > > > I've been sharing the very same hosts file among all my PCs for well > > > > > over a decade, probably closer to two. > > > > > > > > And I have been for 2 decades and change as it once had an amiga as one > > > > of its clients. > > > > > > What advice would you give to a user regarding the benefits of a hosts > > > file as opposed to more modern techniques? > > > > I'll treat this question as "static interface configuration and hosts > > files". > > > > The advantage is that it's conceptually simpler. > > > > The disadvantages are numerous. > > > > * Adding a new host, or changing a host's IP address, requires > > platform-specific knowledge on the host in question. On a > > heterogeneous network, that means you need knowledge of how to do > > this on all the different platforms. This may include devices like > > printers, where it's quite difficult, maybe even impossible, to > > configure an address without DHCP. > > > > * After a change is made, it has to be replicated across your entire > > network. Manually. > > > > * Any "visitor" machines that are temporarily added to your network will > > need to be configured manually, and they will have zero knowledge of > > the other hosts on the network. Even if you know their names, there > > won't be any DNS in which you can look up their addresses. > > > > For anyone setting up a new home network, I'd recommend using DHCP. It > > will be a lot simpler in the long run, especially if you start adding > > wireless devices (cell phones, tablets, TV streaming devices, etc.). > > Your router probably already acts as a DHCP server, so all you need to > > do is learn how to configure fixed addresses for specific computers (and > > printers) that want to act like servers. The other devices can just get > > random addresses. Guest machines can just be connected and start working > > without issues. > > Yes, I'd agree with all those arguments for DHCP, which is why I use > it, hence its inclusion in my post at the top of this subthread, and > why I can't understand Gene's aversion to it. But that's all about > configuration, and the quoted comment at the top of this post is AIUI > about /resolving/ hostnames through /etc/hosts. Resolving hostnames on the local network is simple and reliable when avahi-daemon and linnss-mdns are available. brian@desktop:~$ getent hosts envy4500.local 192.168.7.235 envy4500.local Continually and nanually maintain /etc/hosts? Not in 2022! -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2022-01-25 09:40 +0100 |
| Message-ID | <DJpwR-8cZ-1@gated-at.bofh.it> |
| In reply to | #244547 |
[Multipart message — attachments visible in raw view] — view raw
On Lu, 24 ian 22, 23:54:41, Brian wrote: > > Resolving hostnames on the local network is simple and reliable when > avahi-daemon and linnss-mdns are available. > > brian@desktop:~$ getent hosts envy4500.local > 192.168.7.235 envy4500.local > > Continually and nanually maintain /etc/hosts? Not in 2022! Ok, I'll bite :) Could you point to any (reasonably up-to-date) documentation or is it sufficient to just install avahi-daemon and libnss-mdns? Can mDNS resolve only hostnames or is it necessary to always mention the '.local' domain? Thanks, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2022-01-25 12:20 +0100 |
| Message-ID | <DJs1H-1m3-1@gated-at.bofh.it> |
| In reply to | #244571 |
On Tue 25 Jan 2022 at 09:31:57 +0100, Andrei POPESCU wrote: > On Lu, 24 ian 22, 23:54:41, Brian wrote: > > > > Resolving hostnames on the local network is simple and reliable when > > avahi-daemon and linnss-mdns are available. > > > > brian@desktop:~$ getent hosts envy4500.local > > 192.168.7.235 envy4500.local > > > > Continually and nanually maintain /etc/hosts? Not in 2022! > > Ok, I'll bite :) > > Could you point to any (reasonably up-to-date) documentation or is it > sufficient to just install avahi-daemon and libnss-mdns? 'apt install avahi-daemon' is sufficient. libnnss-mdns is a recommended package of avahi-daemon. Machines with cups installed will already have both packages. Documentation is at https://www.avahi.org/ https://github.com/lathiat/nss-mdns and in /usr/share/doc. > Can mDNS resolve only hostnames or is it necessary to always mention the > '.local' domain? .local is required. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2022-01-25 13:10 +0100 |
| Message-ID | <DJsO5-1W6-3@gated-at.bofh.it> |
| In reply to | #244580 |
[Multipart message — attachments visible in raw view] — view raw
On Ma, 25 ian 22, 11:18:21, Brian wrote: > On Tue 25 Jan 2022 at 09:31:57 +0100, Andrei POPESCU wrote: > > > > Could you point to any (reasonably up-to-date) documentation or is it > > sufficient to just install avahi-daemon and libnss-mdns? > > 'apt install avahi-daemon' is sufficient. libnnss-mdns is a recommended > package of avahi-daemon. Machines with cups installed will already have > both packages. Documentation is at > > https://www.avahi.org/ > https://github.com/lathiat/nss-mdns > > and in /usr/share/doc. > > > Can mDNS resolve only hostnames or is it necessary to always mention the > > '.local' domain? > > .local is required. Less than optimal (yes, I'm lazy), but I might be able to live with it ;) Is there a way to have "generic" names, e.g. something like "mpd.local", independent of the system's hostname? I like to name systems based on their hardware, not based on the service(s) they provide. If for some reason I want to move the mpd service from one system to another, how can I do that without having to reconfigure all clients? My current solution is to point something like mpd.(mylocaldomain) to the correct IP address in the router (OpenWrt) and use that in all clients[1]. If I need to move the service to another system I only need to adjust the configuration in one place. (I'm aware mpd might not be the best example here, since as far as I know it has native zeroconf support, but let's just assume clients are either buggy or lack zeroconf support completely. Besides, this would apply also to services without zeroconf support.) [1] shared /etc/hosts doesn't work for this, because some clients are running on systems where deploying a custom /etc/hosts would be too complicated (assuming /etc/hosts or something like it is even supported). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2022-01-25 17:30 +0100 |
| Message-ID | <DJwRH-4Jq-3@gated-at.bofh.it> |
| In reply to | #244582 |
On Tue 25 Jan 2022 at 13:06:49 +0100, Andrei POPESCU wrote: > On Ma, 25 ian 22, 11:18:21, Brian wrote: > > On Tue 25 Jan 2022 at 09:31:57 +0100, Andrei POPESCU wrote: > > > > > > Could you point to any (reasonably up-to-date) documentation or is it > > > sufficient to just install avahi-daemon and libnss-mdns? > > > > 'apt install avahi-daemon' is sufficient. libnnss-mdns is a recommended > > package of avahi-daemon. Machines with cups installed will already have > > both packages. Documentation is at > > > > https://www.avahi.org/ > > https://github.com/lathiat/nss-mdns > > > > and in /usr/share/doc. > > > > > Can mDNS resolve only hostnames or is it necessary to always mention the > > > '.local' domain? > > > > .local is required. > > Less than optimal (yes, I'm lazy), but I might be able to live with it ;) It grows on you :). > Is there a way to have "generic" names, e.g. something like "mpd.local", > independent of the system's hostname? Let's see if this addresses your question: Install avahi-utils. For a complete view of the network, do avahi-browse -art | less For a spcific service, do avahi-browse -rt _mpd._tcp on the same or another machine. _mpd._tcp is a service name and is "something like "mpd.local"". (BTW, I had to disable and mask mpd.socket for the commands to give outputs for mpd). > I like to name systems based on their hardware, not based on the > service(s) they provide. > > If for some reason I want to move the mpd service from one system to > another, how can I do that without having to reconfigure all clients? Relocation on the same network should not need client reconfiguration. > My current solution is to point something like mpd.(mylocaldomain) to > the correct IP address in the router (OpenWrt) and use that in all > clients[1]. If I need to move the service to another system I only need > to adjust the configuration in one place. > > > (I'm aware mpd might not be the best example here, since as far as I > know it has native zeroconf support, but let's just assume clients are > either buggy or lack zeroconf support completely. Besides, this would > apply also to services without zeroconf support.) I'm a little lost here. If services or clients lack Avahi integration, they cannot avail themselves of its services. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2022-01-25 18:00 +0100 |
| Message-ID | <DJxkL-4X5-13@gated-at.bofh.it> |
| In reply to | #244597 |
On Tue 25 Jan 2022 at 16:20:49 +0000, Brian wrote: > on the same or another machine. _mpd._tcp is a service name and is Correction. _mpd._tcp is a service type. -- Brian.
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | linux.debian.user
csiph-web