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 1 of 4 [1] 2 3 4 Next page →
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2022-01-22 00:50 +0100 |
| Subject | hostname is being reset, killing net on reboot |
| Message-ID | <DIbPj-4gd-1@gated-at.bofh.it> |
Hi all; System is an rpi4b/bullseye, uptodate. I had to fix this a year or more ago with buster, but this system has crashed and burned thanks to a 2T shingled drive. Notes if any were ever made are gone. So how do I officially set the hostname so its reboot proof? Thanks all. 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] | [next] | [standalone]
| From | "Andrew M.A. Cater" <amacater@einval.com> |
|---|---|
| Date | 2022-01-22 00:50 +0100 |
| Message-ID | <DIbPj-4gd-3@gated-at.bofh.it> |
| In reply to | #244291 |
On Fri, Jan 21, 2022 at 06:42:38PM -0500, gene heskett wrote: > Hi all; > > System is an rpi4b/bullseye, uptodate. > I had to fix this a year or more ago with buster, but this system has > crashed and burned thanks to a 2T shingled drive. Notes if any were ever > made are gone. > > So how do I officially set the hostname so its reboot proof? > hostnamectl set hostname [foobar] Hope that helps - all best, as ever, Andy Cater > Thanks all. > > 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 | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2022-01-22 01:30 +0100 |
| Message-ID | <DIcs1-4ID-3@gated-at.bofh.it> |
| In reply to | #244292 |
On Friday, January 21, 2022 6:45:52 PM EST Andrew M.A. Cater wrote: > On Fri, Jan 21, 2022 at 06:42:38PM -0500, gene heskett wrote: > > Hi all; > > > > System is an rpi4b/bullseye, uptodate. > > I had to fix this a year or more ago with buster, but this system has > > crashed and burned thanks to a 2T shingled drive. Notes if any were > > ever made are gone. > > > > So how do I officially set the hostname so its reboot proof? > > hostnamectl set hostname [foobar] > > Hope that helps - all best, as ever, > > Andy Cater > Thank you Andy. IIRC that can set domainname too? > > Thanks all. > > > > Cheers, Gene Heskett. > > . 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 | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2022-01-22 01:50 +0100 |
| Message-ID | <DIcLn-4P7-1@gated-at.bofh.it> |
| In reply to | #244294 |
On Fri, Jan 21, 2022 at 07:27:11PM -0500, gene heskett wrote: > On Friday, January 21, 2022 6:45:52 PM EST Andrew M.A. Cater wrote: > > On Fri, Jan 21, 2022 at 06:42:38PM -0500, gene heskett wrote: > > > So how do I officially set the hostname so its reboot proof? > > > > hostnamectl set hostname [foobar] The standard Debian way is to put the desired hostname in /etc/hostname. If I'm reading hostnamectl(1) correctly, the command you wanted should have a hyphen in it: hostnamectl set-hostname NEWNAME However, I've never used this command and I'm not sure what it actually does, or how it interacts with the traditional Debian configuration. > Thank you Andy. IIRC that can set domainname too? That depends on what you mean by "domainname". There is a "domainname" command in the nis package, which sets the NIS domain name. But I somehow suspect this isn't what you mean. I also suspect you aren't talking about Kerberos. Or Samba. Do you mean a DNS domain name of some kind? That's my guess. But even then, the concept is ambiguous. What are you actually trying to do? In order for *other* computers to know your system by a fully qualified domain name, you would need to alter DNS. Either the real live global DNS that everyone uses, if systems are doing DNS lookups on the public Internet, or else a local area network DNS server that you maintain interally. Or else modify the /etc/hosts files on the other computers. Or perhaps what you mean is something like, "When I type telnet iota, I want it to act like I had typed telnet iota.gene.local." In this case, you're probably aiming for a customized /etc/resolv.conf file. Which in turn means you need to read up on how to avoid having your changes to /etc/resolv.conf wiped out by roaming bands of daemons. I've covered this topic so many times that I'm quite tired of it, so just go to <https://wiki.debian.org/resolv.conf> and read. Or maybe you mean something else? Please be specific.
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2022-01-22 03:40 +0100 |
| Message-ID | <DIetQ-5RS-3@gated-at.bofh.it> |
| In reply to | #244295 |
On Friday, January 21, 2022 7:46:40 PM EST Greg Wooledge wrote: > On Fri, Jan 21, 2022 at 07:27:11PM -0500, gene heskett wrote: > > On Friday, January 21, 2022 6:45:52 PM EST Andrew M.A. Cater wrote: > > > On Fri, Jan 21, 2022 at 06:42:38PM -0500, gene heskett wrote: > > > > So how do I officially set the hostname so its reboot proof? > > > > > > hostnamectl set hostname [foobar] > > The standard Debian way is to put the desired hostname in > /etc/hostname. > > If I'm reading hostnamectl(1) correctly, the command you wanted should > have a hyphen in it: hostnamectl set-hostname NEWNAME > > However, I've never used this command and I'm not sure what it actually > does, or how it interacts with the traditional Debian configuration. > > Thank you Andy. IIRC that can set domainname too? > > That depends on what you mean by "domainname". There is a "domainname" > command in the nis package, which sets the NIS domain name. But I > somehow suspect this isn't what you mean. I also suspect you aren't > talking about Kerberos. Or Samba. > > Do you mean a DNS domain name of some kind? That's my guess. But even > then, the concept is ambiguous. What are you actually trying to do? > > In order for *other* computers to know your system by a fully qualified > domain name, you would need to alter DNS. Either the real live global > DNS that everyone uses, if systems are doing DNS lookups on the public > Internet, or else a local area network DNS server that you maintain > interally. Or else modify the /etc/hosts files on the other > computers. > > Or perhaps what you mean is something like, "When I type telnet iota, > I want it to act like I had typed telnet iota.gene.local." In this > case, you're probably aiming for a customized /etc/resolv.conf file. > Which in turn means you need to read up on how to avoid having your > changes to /etc/resolv.conf wiped out by roaming bands of daemons. > I've covered this topic so many times that I'm quite tired of it, so > just go to <https://wiki.debian.org/resolv.conf> and read. > > Or maybe you mean something else? Please be specific. > /etc/resolv.conf has: search coyote.den nameserver 192.168.xx.1 the search line says to look in the /etc/hosts file, failing that, the nameserver line sends the dns lookup query to the router which NAT's me to my isp assigned address, and fwds it to my isp's dns server. And its Just Worked much like that way since redhat 5.0 in 1998. However when I set hostname with hostname, the 169.bs stays out of the picture and networking works the world until a reboot. Setting the hostname with hostnamectl to the alias in /etc/hosts for this machine, gets me exactly the same hostname but then the route reported by "ip a" is the 169.bs.bs.bs and I can't get out of my shirt pocket to even ping the router at 192.168.xx.1. I tried to remove avahi but apt doesn't admit to knowing it. But thats what I had to do to buster in order to get rid of the bogus routing. ip route won't kill it, not even to the next reboot, so how do I get rid of the bogus 169.bs.bs.bs routing forever? That whole avahi thing has never been anything but a headache for me, whoever wrote it is in search of a problem I have never had in 24 years. My whole system here, 7 machines atm, has been as high as a dozen, is dhcpd-less, all host name based with a common hosts file on all machines. And until avahi sticks its camel nose in, it Just Works. So how do I get rid of the 169.xx.xx.xx bs? Forever, with shoot to kill prejudice? Thank you. 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 | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2022-01-22 04:10 +0100 |
| Message-ID | <DIeWR-6hB-1@gated-at.bofh.it> |
| In reply to | #244296 |
On Friday, January 21, 2022 9:34:35 PM EST gene heskett wrote: > On Friday, January 21, 2022 7:46:40 PM EST Greg Wooledge wrote: > > On Fri, Jan 21, 2022 at 07:27:11PM -0500, gene heskett wrote: > > > On Friday, January 21, 2022 6:45:52 PM EST Andrew M.A. Cater wrote: > > > > On Fri, Jan 21, 2022 at 06:42:38PM -0500, gene heskett wrote: > > > > > So how do I officially set the hostname so its reboot proof? > > > > > > > > hostnamectl set hostname [foobar] > > > > The standard Debian way is to put the desired hostname in > > /etc/hostname. > > > > If I'm reading hostnamectl(1) correctly, the command you wanted > > should > > have a hyphen in it: hostnamectl set-hostname NEWNAME > > > > However, I've never used this command and I'm not sure what it > > actually does, or how it interacts with the traditional Debian > > configuration.> > > > Thank you Andy. IIRC that can set domainname too? > > > > That depends on what you mean by "domainname". There is a > > "domainname" command in the nis package, which sets the NIS domain > > name. But I somehow suspect this isn't what you mean. I also > > suspect you aren't talking about Kerberos. Or Samba. > > > > Do you mean a DNS domain name of some kind? That's my guess. But > > even then, the concept is ambiguous. What are you actually trying > > to do? > > > > In order for *other* computers to know your system by a fully > > qualified domain name, you would need to alter DNS. Either the real > > live global DNS that everyone uses, if systems are doing DNS lookups > > on the public Internet, or else a local area network DNS server that > > you maintain interally. Or else modify the /etc/hosts files on the > > other > > computers. > > > > Or perhaps what you mean is something like, "When I type telnet iota, > > I want it to act like I had typed telnet iota.gene.local." In this > > case, you're probably aiming for a customized /etc/resolv.conf file. > > Which in turn means you need to read up on how to avoid having your > > changes to /etc/resolv.conf wiped out by roaming bands of daemons. > > I've covered this topic so many times that I'm quite tired of it, so > > just go to <https://wiki.debian.org/resolv.conf> and read. > > > > Or maybe you mean something else? Please be specific. > > /etc/resolv.conf has: > search coyote.den > nameserver 192.168.xx.1 > > the search line says to look in the /etc/hosts file, failing that, the > nameserver line sends the dns lookup query to the router which NAT's me > to my isp assigned address, and fwds it to my isp's dns server. And > its Just Worked much like that way since redhat 5.0 in 1998. > > However when I set hostname with hostname, the 169.bs stays out of the > picture and networking works the world until a reboot. > Setting the hostname with hostnamectl to the alias in /etc/hosts for > this machine, gets me exactly the same hostname but then the route > reported by "ip a" is the 169.bs.bs.bs and I can't get out of my shirt > pocket to even ping the router at 192.168.xx.1. > > I tried to remove avahi but apt doesn't admit to knowing it. But thats > what I had to do to buster in order to get rid of the bogus routing. > ip route won't kill it, not even to the next reboot, so how do I get > rid of the bogus 169.bs.bs.bs routing forever? That whole avahi thing > has never been anything but a headache for me, whoever wrote it is in > search of a problem I have never had in 24 years. > > My whole system here, 7 machines atm, has been as high as a dozen, is > dhcpd-less, all host name based with a common hosts file on all > machines. And until avahi sticks its camel nose in, it Just Works. So > how do I get rid of the 169.xx.xx.xx bs? Forever, with shoot to kill > prejudice? > Never mind. I found the cure in the bottom of /etc/dhcpcd.conf, define a static_eth0 and a fallback to it if a dhcpd server can't be found, did it, rebooted and its fixed. I have a network. Why isn't that in the wiki? Neither is there any reference to avahi that can be found in the wiki and I spent around 2 hours search and browsing it.. Frustrating is an inadequate description. Adequate isn't for mixed audiences. Anyway, its fixed. How long? Beats me... 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 | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2022-01-22 04:50 +0100 |
| Message-ID | <DIfzz-6Aw-1@gated-at.bofh.it> |
| In reply to | #244296 |
On Fri, Jan 21, 2022 at 09:34:35PM -0500, gene heskett wrote: > /etc/resolv.conf has: > search coyote.den > nameserver 192.168.xx.1 > > the search line says to look in the /etc/hosts file, failing that, the > nameserver line sends the dns lookup query to the router No, that's not correct. The config file that says "look in /etc/hosts first, then look in DNS next" is /etc/nsswitch.conf. Specifically, it's the line that begins with "hosts:" in that file. The "search" line in /etc/resolv.conf means "if I type ftp roadrunner, I want it to act as if I had typed ftp roadrunner.coyote.den". In other words, it's the default DNS search domain for looking up the *other computers* on your local area network. > However when I set hostname with hostname, the 169.bs stays out of the > picture and networking works the world until a reboot. Well, yes. The "hostname" command sets the current hostname, which resides in memory only. It has no permanent effect. And it has nothing at all to do with IP addresses. Or DNS. > Setting the hostname with hostnamectl to the alias in /etc/hosts for this > machine, gets me exactly the same hostname but then the route reported by > "ip a" is the 169.bs.bs.bs and I can't get out of my shirt pocket to even > ping the router at 192.168.xx.1. Routing has nothing to do with your system's hostname. At all. At the most basic level, your system's default route is set by whatever mechanism sets up your network interfaces. On Debian, this can be any of *several* different pieces of software, depending on what's installed and what you've got in your config files. In the *most* basic possible configuration, your routing table will be one automatic entry for your ethernet interface (created from the IP address and netmask which are assigned to that interface), and then one "default" route which is assigned for reaching every host that's *not* part of your LAN. E.g. in /etc/network/interfaces you'd have something like this: auto enp2s0 iface enp2s0 inet static address 192.168.1.21/24 gateway 192.168.1.1 This tells the "ifupdown" software package that you'd like it to manage the enp2s0 network interface, assigning the IP address 192.168.1.21 with a 24-bit netmask, which automatically creates a route to the 192.168.1.0/24 network. In addition, it will create a default route via the 192.168.1.1 address. None of this has *anything* to do with your system's hostname. None of this has *anything* to do with your /etc/hosts file. None of this has *anything* to do with DNS. Of course, there are many other ways to configure network interfaces in Debian. You might be using Network-Manager, for example. Or systemd's systemd-networkd(8). Or you might be using /etc/network/interfaces but telling it to ask for configuration from DHCP. Also, by the way, "ip a" does not report routes. That's "ip r". unicorn:~$ ip r default via 10.0.0.1 dev lan0 10.0.0.0/24 dev lan0 proto kernel scope link src 10.0.0.7 ------------------------------------ You're probably still confused. Let's go over everything again, from the beginning. Your computer has a *network interface*. This interface has some kind of name. The names are very complicated and I don't want to introduce that particular piece of complexity here. Let's say that you've somehow managed to determine your interface's name. Let's say, for this example, that your interface's name is enp2s0. In order for your network interface to *work*, it has to be assigned an IP address and a netmask. This can come from DHCP, or it can come from files that you configure on your system. With an IP address and a netmask, you will be able to communicate with other computers on your *local area network*, by using their IP addresses. If you have a default route, then you can potentially talk to computers *outside* of your LAN. This default route can come from DHCP, or from local files. E.g. with a properly configured default route, you will be able to run commands like "ping 8.8.8.8" and get responses. If you'd like to communicate with other computers by name instead of by IP addresses, you can either put their names and IP addresses in the /etc/hosts file (a simple text file), *or* you can configure your computer to use DNS. DNS is configured in the /etc/resolv.conf file. The most basic piece consists of "nameserver" lines which contain the IP addresses of DNS resolvers which will look up computer names for you. These nameservers can come from DHCP, or they can be configured in your local files. Your computer can also have a hostname. This is how your computer identifies itself when it logs things, so that you can tell which computer wrote which piece of the logfile. Your computer can be named whatever you like. Its name has meaning only to you. Other computers do not know what your hostname is, and they do not care. If you want other computers to be able to contact you by a name, then you add that name to DNS, *or* to the /etc/hosts files of those other computers. The name that you put in DNS or other machines' /etc/hosts files does *not* have to be the same as your hostname. Your hostname is private. It's what your computer calls itself. It's not what other computers call you. Your computer can also have a *list of search domains* for use in hostname lookups. This is typically something you'd only care about if you have a LAN with multiple computers on it, which all want to talk to each other. If you're just a single computer that's on the Internet, you *do not care* about this at all. The main purpose of a list of search domains is to save typing. Let's say you've got a LAN with hosts that are (publically) called "cat.coyote.den" and "dog.coyote.den". If you want to log into the first one, you could type "ssh cat.coyote.den". But that's a lot of typing. If you have "coyote.den" in your list of search domains, then you can simply type "ssh cat". The host resolver will try each of the domains in your search list, one by one, as suffixes, until one of them works. This list of search domains is configured in your local /etc/resolv.conf file. It can be a static entry, or it can come from DHCP.
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2022-01-22 06:00 +0100 |
| Message-ID | <DIgFj-7bA-3@gated-at.bofh.it> |
| In reply to | #244298 |
On Friday, January 21, 2022 10:46:35 PM EST Greg Wooledge wrote: > On Fri, Jan 21, 2022 at 09:34:35PM -0500, gene heskett wrote: > > /etc/resolv.conf has: > > search coyote.den > > nameserver 192.168.xx.1 > > > > the search line says to look in the /etc/hosts file, failing that, > > the > > nameserver line sends the dns lookup query to the router > > No, that's not correct. > > The config file that says "look in /etc/hosts first, then look in DNS > next" is /etc/nsswitch.conf. Specifically, it's the line that begins > with "hosts:" in that file. > > The "search" line in /etc/resolv.conf means "if I type ftp roadrunner, > I want it to act as if I had typed ftp roadrunner.coyote.den". > > In other words, it's the default DNS search domain for looking up the > *other computers* on your local area network. > > > However when I set hostname with hostname, the 169.bs stays out of > > the > > picture and networking works the world until a reboot. > > Well, yes. The "hostname" command sets the current hostname, which > resides in memory only. It has no permanent effect. > > And it has nothing at all to do with IP addresses. Or DNS. > > > Setting the hostname with hostnamectl to the alias in /etc/hosts for > > this machine, gets me exactly the same hostname but then the route > > reported by "ip a" is the 169.bs.bs.bs and I can't get out of my > > shirt pocket to even ping the router at 192.168.xx.1. > > Routing has nothing to do with your system's hostname. At all. > > At the most basic level, your system's default route is set by whatever > mechanism sets up your network interfaces. On Debian, this can be any > of *several* different pieces of software, depending on what's > installed and what you've got in your config files. > > In the *most* basic possible configuration, your routing table will be > one automatic entry for your ethernet interface (created from the IP > address and netmask which are assigned to that interface), and then one > "default" route which is assigned for reaching every host that's *not* > part of your LAN. > > E.g. in /etc/network/interfaces you'd have something like this: > > auto enp2s0 > > iface enp2s0 inet static > address 192.168.1.21/24 > gateway 192.168.1.1 > > This tells the "ifupdown" software package that you'd like it to manage > the enp2s0 network interface, assigning the IP address 192.168.1.21 > with a 24-bit netmask, which automatically creates a route to the > 192.168.1.0/24 network. In addition, it will create a default route > via the 192.168.1.1 address. > > None of this has *anything* to do with your system's hostname. > > None of this has *anything* to do with your /etc/hosts file. > > None of this has *anything* to do with DNS. > > Of course, there are many other ways to configure network interfaces in > Debian. You might be using Network-Manager, for example. Or > systemd's systemd-networkd(8). Or you might be using > /etc/network/interfaces but telling it to ask for configuration from > DHCP. > > Also, by the way, "ip a" does not report routes. That's "ip r". > > unicorn:~$ ip r > default via 10.0.0.1 dev lan0 > 10.0.0.0/24 dev lan0 proto kernel scope link src 10.0.0.7 > > ------------------------------------ > > You're probably still confused. Let's go over everything again, from > the beginning. > > Your computer has a *network interface*. This interface has some kind > of name. The names are very complicated and I don't want to introduce > that particular piece of complexity here. Let's say that you've > somehow managed to determine your interface's name. Let's say, for > this example, that your interface's name is enp2s0. > > In order for your network interface to *work*, it has to be assigned an > IP address and a netmask. This can come from DHCP, or it can come > from files that you configure on your system. > > With an IP address and a netmask, you will be able to communicate with > other computers on your *local area network*, by using their IP > addresses. > > If you have a default route, then you can potentially talk to computers > *outside* of your LAN. This default route can come from DHCP, or from > local files. E.g. with a properly configured default route, you will > be able to run commands like "ping 8.8.8.8" and get responses. > > If you'd like to communicate with other computers by name instead of by > IP addresses, you can either put their names and IP addresses in the > /etc/hosts file (a simple text file), *or* you can configure your > computer to use DNS. > > DNS is configured in the /etc/resolv.conf file. The most basic piece > consists of "nameserver" lines which contain the IP addresses of DNS > resolvers which will look up computer names for you. These nameservers > can come from DHCP, or they can be configured in your local files. > > Your computer can also have a hostname. This is how your computer > identifies itself when it logs things, so that you can tell which > computer wrote which piece of the logfile. Your computer can be named > whatever you like. Its name has meaning only to you. Other computers > do not know what your hostname is, and they do not care. > > If you want other computers to be able to contact you by a name, then > you add that name to DNS, *or* to the /etc/hosts files of those other > computers. The name that you put in DNS or other machines' /etc/hosts > files does *not* have to be the same as your hostname. Your hostname > is private. It's what your computer calls itself. It's not what > other computers call you. > > Your computer can also have a *list of search domains* for use in > hostname lookups. This is typically something you'd only care about > if you have a LAN with multiple computers on it, which all want to > talk to each other. If you're just a single computer that's on the > Internet, you *do not care* about this at all. > > The main purpose of a list of search domains is to save typing. Let's > say you've got a LAN with hosts that are (publically) called > "cat.coyote.den" and "dog.coyote.den". If you want to log into the > first one, you could type "ssh cat.coyote.den". But that's a lot of > typing. If you have "coyote.den" in your list of search domains, then > you can simply type "ssh cat". The host resolver will try each of the > domains in your search list, one by one, as suffixes, until one of > them works. > > This list of search domains is configured in your local > /etc/resolv.conf file. It can be a static entry, or it can come from > DHCP. > > . This is all well and good, Greg, but it still does NOT give a clue what todo when the system picks a fictitious route out of its rear. And that IS my squawk. I did find a fix as posted earlier, but I doubt it will work under a pine tree in Wash State where these two cards will get mailed to once I get a realtime kernel installed and working. And I've got a v5.16.0-rc6-rt12, downright bleeding edge to install tomorrow. Cheers Greg, 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 | <tomas@tuxteam.de> |
|---|---|
| Date | 2022-01-22 08:10 +0100 |
| Message-ID | <DIiH7-fu-3@gated-at.bofh.it> |
| In reply to | #244299 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Jan 21, 2022 at 11:51:20PM -0500, gene heskett wrote: [...] > This is all well and good, Greg, but it still does NOT give a clue what > todo when the system picks a fictitious route out of its rear. Start debugging from bottom to top. For the first round, just deal in IP addresses and routes (those are set in term of IP addresses, not names). Forget about names. Once that part is flying, tackle names :) > And that IS my squawk. > > I did find a fix as posted earlier, but I doubt it will work under a pine > tree in Wash State where these two cards will get mailed to once I get a > realtime kernel installed and working. And I've got a v5.16.0-rc6-rt12, > downright bleeding edge to install tomorrow. Pethaps you'll have to have stern words with your DHCP server. This may be the one giving your machines their weird IP addresses and (at least part of the) routes. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2022-01-22 10:40 +0100 |
| Message-ID | <DIl2h-1xY-1@gated-at.bofh.it> |
| In reply to | #244302 |
On Saturday, January 22, 2022 2:04:32 AM EST tomas@tuxteam.de wrote: > On Fri, Jan 21, 2022 at 11:51:20PM -0500, gene heskett wrote: > > [...] > > > This is all well and good, Greg, but it still does NOT give a clue > > what todo when the system picks a fictitious route out of its rear. > Start debugging from bottom to top. For the first round, just deal in > IP addresses and routes (those are set in term of IP addresses, not > names). Forget about names. > > Once that part is flying, tackle names :) But, I found, quite by serendipity, in the raspios version of bullseye, a fix. Look at the bottom of /etc/dhcpdcp.conf, if there is even a copy of that on your system, this one now that I've looked, doesn't have it, there is an example of what to do if no dhcpd is to be found locally. static_eth0 can be defined, and below that, is an if no dhcpd to be found, fallback to the static_eth0 definition. Unpublished, not really mentioned in the man pages, but edit to put the correct for your site data in it, reboot, and its working. So at least on an rpi4 running bullseye, I found what looks to be the official way to fix it. That file does NOT exist on an x86-64 debian bullseye install. As to how you fix it on debian, I've not a clue. I'd ask on the raspi forum, but I made the mistake of asking about a realtime kernel a third time, way back in wheezy's time, which they officially do not support, so my posting rights were turned off. I can login, but can't post. However, since this, on closer inspection, seems to be an raspios problem, this is the last post on this subject. > > And that IS my squawk. > > > > I did find a fix as posted earlier, but I doubt it will work under a > > pine tree in Wash State where these two cards will get mailed to > > once I get a realtime kernel installed and working. And I've got a > > v5.16.0-rc6-rt12, downright bleeding edge to install tomorrow. > > Pethaps you'll have to have stern words with your DHCP server. This may > be the one giving your machines their weird IP addresses and (at least > part of the) routes. There first has to be an activated server. And the only one here is fielding the radio in the router when the radio is on, but its off to keep the neighbors damned cell phone from using 300gigs a month on my nickle. > Cheers Cheers Tomas, take care and stay well, 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 | <tomas@tuxteam.de> |
|---|---|
| Date | 2022-01-22 11:20 +0100 |
| Message-ID | <DIlEZ-20V-3@gated-at.bofh.it> |
| In reply to | #244314 |
[Multipart message — attachments visible in raw view] — view raw
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?
Cheers
--
t
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2022-01-22 13:20 +0100 |
| Message-ID | <DInx8-38v-9@gated-at.bofh.it> |
| In reply to | #244316 |
On Saturday, January 22, 2022 5:13:59 AM EST 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? > > Cheers its for its own eth0 on the rpi4b. And I guess it is raspi specific. It doesn't exist on this x86-64 bullseye install. Last post Tomas, we are contaminating the archive and the fix I published with further discussion. 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 | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2022-01-23 09:10 +0100 |
| Message-ID | <DIG6J-5Xv-1@gated-at.bofh.it> |
| In reply to | #244322 |
[Multipart message — attachments visible in raw view] — view raw
On Sb, 22 ian 22, 07:13:18, gene heskett wrote: > > its for its own eth0 on the rpi4b. And I guess it is raspi specific. It > doesn't exist on this x86-64 bullseye install. Likely the source of your problems is that Raspberry Pi OS has DHCP enabled by default. It might have been done using Debian specific tools (ifupdown, i.e. /etc/network/interfaces or files under /etc/network/interfaces.d/), some other known tools (systemd-networkd, Network Manager, etc.), or their own concoction. If you intend on keeping the Raspberry Pi OS you have to learn how it's configured and deal with that. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2022-01-22 18:20 +0100 |
| Message-ID | <DIsds-5Y4-9@gated-at.bofh.it> |
| In reply to | #244316 |
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.
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2022-01-22 20:00 +0100 |
| Message-ID | <DItMe-6Lk-5@gated-at.bofh.it> |
| In reply to | #244343 |
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. 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. 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. 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. 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. 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? 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. 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. 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. 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. Take care, and stay well, ALL of you. 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 | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2022-01-22 22:30 +0100 |
| Message-ID | <DIw7n-8hW-5@gated-at.bofh.it> |
| In reply to | #244348 |
On Sat, Jan 22, 2022 at 01:57:38PM -0500, gene heskett wrote: > So my resolv.conf says to search coyote.den, and failing that, use my > isp's nameserver [...] Again: that is NOT what the resolv.conf file does. The /etc/nsswitch.conf file *SHOULD* tell your system to use the /etc/hosts file first, and DNS second. At least, that's the default and the norm. > 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. Honestly? I would not try to convince you to do this. It's additional complexity that you clearly don't need, and perhaps aren't ready to handle. For a LAN with no DHCP and no local DNS, here's what you need: 1) Each system must configure its own IP address, netmask, and default route (gateway). This can be done in /etc/network/interfaces if the interface name is well defined. If the interface name is an issue, then you'll also need to set up a ".link" file in /etc/systemd/network/ to assign the interface name. 2) Each system should have an /etc/hosts file which has a unique header per system (containing something like "127.0.1.1 tlm.coyote.den tlm"), and then a copy-pasted body that's the same for all systems. In that body, you'll specify the LAN IP addresses and the LAN hostnames of all your systems. For example, 127.0.0.1 localhost 192.168.1.1 router.coyote.den router 192.168.1.2 tlm.coyote.den tlm 192.168.1.3 sixty40.coyote.den sixty40 ... Obviously I don't know your LAN IP addresses or most of your hostnames, so I can only guess. But this is the general form that it should have. 3) Systems that want to contact the Internet will also need an /etc/resolv.conf file, telling them where the DNS resolvers are. If your router is also your DNS resolver, then you would use something like this: search coyote.den nameserver 192.168.1.1 The "search" line doesn't actually do much here, because all of your Internet queries are going to contain dots (like www.debian.org), and therefore the search domain isn't used. But just in case you ever try to hand a LAN hostname like "tlm" to a program that wants to contact the Internet, the search domain will turn it into "tlm.coyote.den" for you. Systems that have no business contacting the Internet can omit this file. Of course, that won't stop them from contacting the Internet using raw IP addresses. If one of your computers isn't working correctly, then you can troubleshoot it. We might even be able to help you, if you provide enough information. Use "ip a" to see the addresses that are assigned to your interfaces. Are those correct? If not, then you know there's an issue in step 1. Use "ip r" to see the routing table. Is the default route set correctly? If not, then again, it's a step 1 issue. Can your computer access the Internet, but not the other hosts on the LAN? Then it's probably a step 2 issue. Check your /etc/hosts file. Also check /etc/nsswitch.conf for good measure. Can your computer access the other hosts on the LAN, but not the Internet? Then it could be a step 3 thing (incorrect /etc/resolv.conf) if DNS is the issue. If DNS isn't the issue (e.g. if ping 8.8.8.8 fails), then it could be an incorrect default route. Or it could be a firewall thing. I'm not covering firewalls here, but if you've got one, it could be set up incorrectly and cause *all* kinds of havoc.
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2022-01-23 00:40 +0100 |
| Message-ID | <DIy9c-10P-5@gated-at.bofh.it> |
| In reply to | #244358 |
On Saturday, January 22, 2022 4:20:07 PM EST Greg Wooledge wrote: > On Sat, Jan 22, 2022 at 01:57:38PM -0500, gene heskett wrote: > > So my resolv.conf says to search coyote.den, and failing that, use my > > isp's nameserver [...] > > Again: that is NOT what the resolv.conf file does. > > The /etc/nsswitch.conf file *SHOULD* tell your system to use the > /etc/hosts file first, and DNS second. At least, that's the default > and the norm. Maybe I'm losing it, but I don't see any such directives in this file, copy pasted from the miss-behaving machine. ====================== # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc-reference' and `info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. passwd: files group: files shadow: files gshadow: files hosts: files mdns4_minimal [NOTFOUND=return] dns networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis ======================= I am not all that familiar with this file, is it funkity? > > 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. > > Honestly? I would not try to convince you to do this. It's additional > complexity that you clearly don't need, and perhaps aren't ready to > handle. > > For a LAN with no DHCP and no local DNS, here's what you need: > > 1) Each system must configure its own IP address, netmask, and default > route (gateway). This can be done in /etc/network/interfaces if the > interface name is well defined. It is well defined, but overridden at reboot because something edited the /etc/hostname file, restoring the installers default in the reboot process. That name is not in the hosts file. > If the interface name is an issue, then you'll also need to set up a > ".link" file in /etc/systemd/network/ to assign the interface name. > > 2) Each system should have an /etc/hosts file which has a unique header > per system (containing something like "127.0.1.1 tlm.coyote.den tlm"), > and then a copy-pasted body that's the same for all systems. In that > body, you'll specify the LAN IP addresses and the LAN hostnames of all > your systems. For example, > > 127.0.0.1 localhost > 192.168.1.1 router.coyote.den router > 192.168.1.2 tlm.coyote.den tlm > 192.168.1.3 sixty40.coyote.den sixty40 > ... > > Obviously I don't know your LAN IP addresses or most of your > hostnames, so I can only guess. But this is the general form that it > should have. > > 3) Systems that want to contact the Internet will also need an > /etc/resolv.conf file, telling them where the DNS resolvers are. If > your router is also your DNS resolver, then you would use something > like this: > > search coyote.den > nameserver 192.168.1.1 > > The "search" line doesn't actually do much here, because all of your > Internet queries are going to contain dots (like www.debian.org), and > therefore the search domain isn't used. But just in case you ever try > to hand a LAN hostname like "tlm" to a program that wants to contact > the Internet, the search domain will turn it into > "tlm.coyote.den" for you. Which of course resolves to a 192.168.xx.xx number which doesn't get thru the router without NATing first. The router of course has been reflashed with dd-wrt. > Systems that have no business contacting the Internet can omit this > file. Of course, that won't stop them from contacting the Internet > using raw IP addresses. They all have business with the net, updating the stuff they run several times a week. > If one of your computers isn't working correctly, then you can > troubleshoot it. We might even be able to help you, if you provide > enough information. > > Use "ip a" to see the addresses that are assigned to your interfaces. > Are those correct? If not, then you know there's an issue in step 1. > > Use "ip r" to see the routing table. Is the default route set > correctly? If not, then again, it's a step 1 issue. yes, my use of ip a for routing was a typu. > Can your computer access the Internet, but not the other hosts on the > LAN? Then it's probably a step 2 issue. Check your /etc/hosts file. > Also check /etc/nsswitch.conf for good measure. > > Can your computer access the other hosts on the LAN, but not the > Internet? Then it could be a step 3 thing (incorrect /etc/resolv.conf) > if DNS is the issue. If DNS isn't the issue (e.g. if ping 8.8.8.8 > fails), then it could be an incorrect default route. Or it could be a > firewall thing. I'm not covering firewalls here, but if you've got > one, it could be set up incorrectly and cause *all* kinds of havoc. No firewall. I do use iptables to protect my web pages, on this machine from being mirrored by every bot on the planet, but that is not in series with the miss-behaving machine, which is wired straight out of an 8 port switch with the router doing NAT to the address you'll see in a ping report when you ping the name in my sig. Thanks. 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 | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2022-01-23 01:10 +0100 |
| Message-ID | <DIyCd-1pE-1@gated-at.bofh.it> |
| In reply to | #244371 |
[Multipart message — attachments visible in raw view] — view raw
On 2022-01-22 at 18:38, gene heskett wrote: > On Saturday, January 22, 2022 4:20:07 PM EST Greg Wooledge wrote: > >> On Sat, Jan 22, 2022 at 01:57:38PM -0500, gene heskett wrote: > >>> So my resolv.conf says to search coyote.den, and failing that, >>> use my isp's nameserver [...] >> >> Again: that is NOT what the resolv.conf file does. >> >> The /etc/nsswitch.conf file *SHOULD* tell your system to use the >> /etc/hosts file first, and DNS second. At least, that's the >> default and the norm. > > Maybe I'm losing it, but I don't see any such directives in this > file, copy pasted from the miss-behaving machine. > ====================== > # /etc/nsswitch.conf <snip> > hosts: files mdns4_minimal [NOTFOUND=return] dns 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). > I am not all that familiar with this file, is it funkity? I snipped most of the file, but it looks OK to me; at a glance, it looks roughly identical to the one I've got on my own computer. -- 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 | <DIAul-2vr-1@gated-at.bofh.it> |
| In reply to | #244373 |
On Sat 22 Jan 2022 at 19:07:35 (-0500), The Wanderer wrote: > On 2022-01-22 at 18:38, gene heskett wrote: > <snip> > > > hosts: files mdns4_minimal [NOTFOUND=return] dns > > 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. 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. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2022-01-23 03:30 +0100 |
| Message-ID | <DIANH-2Bx-1@gated-at.bofh.it> |
| In reply to | #244380 |
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: > > On 2022-01-22 at 18:38, gene heskett wrote: > > <snip> > > > > > hosts: files mdns4_minimal [NOTFOUND=return] dns > > > > 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. > > 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. AFAIK, the only .local is in the users directory, as a subdir. Exactly NONE of my hostnames contain a .local postfix. > Cheers, > David. > > . 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]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | linux.debian.user
csiph-web