Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #187138 > unrolled thread
| Started by | Gary Roach <gary719_list1@verizon.net> |
|---|---|
| First post | 2017-09-24 03:10 +0200 |
| Last post | 2017-09-26 05:20 +0200 |
| Articles | 20 on this page of 102 — 17 participants |
Back to article view | Back to linux.debian.user
Can't find the DNS Servers Gary Roach <gary719_list1@verizon.net> - 2017-09-24 03:10 +0200
Re: Can't find the DNS Servers Cindy-Sue Causey <butterflybytes@gmail.com> - 2017-09-24 06:40 +0200
Re: Can't find the DNS Servers Gary Roach <gary719_list1@verizon.net> - 2017-09-25 21:50 +0200
Re: Can't find the DNS Servers Reco <recoverym4n@gmail.com> - 2017-09-26 09:00 +0200
Re: Can't find the DNS Servers Richard Hector <richard@walnut.gen.nz> - 2017-09-27 11:20 +0200
Re: Can't find the DNS Servers Reco <recoverym4n@gmail.com> - 2017-09-27 18:40 +0200
Re: Can't find the DNS Servers Gary Roach <gary719_list1@verizon.net> - 2017-10-01 22:40 +0200
Re: Can't find the DNS Servers David Wright <deblis@lionunicorn.co.uk> - 2017-10-02 04:30 +0200
Re: Can't find the DNS Servers Gary Roach <gary719_list1@verizon.net> - 2017-10-02 04:30 +0200
Re: Can't find the DNS Servers Weaver <weaver@riseup.net> - 2017-10-02 04:40 +0200
Re: Can't find the DNS Servers Reco <recoverym4n@gmail.com> - 2017-10-02 09:10 +0200
Re: Can't find the DNS Servers Gene Heskett <gheskett@shentel.net> - 2017-10-02 12:30 +0200
Re: E-mail headers 101 (was: Can't find the DNS Servers) Reco <recoverym4n@gmail.com> - 2017-10-02 12:40 +0200
Re: E-mail headers 101 (was: Can't find the DNS Servers) Gene Heskett <gheskett@shentel.net> - 2017-10-02 13:00 +0200
Re: Can't find the DNS Servers David Wright <deblis@lionunicorn.co.uk> - 2017-10-02 23:10 +0200
Re: Can't find the DNS Servers Gary Roach <gary719_list1@verizon.net> - 2017-10-03 22:40 +0200
Re: Can't find the DNS Servers David Wright <deblis@lionunicorn.co.uk> - 2017-10-04 01:00 +0200
Re: Can't find the DNS Servers Gary Roach <gary719_list1@verizon.net> - 2017-10-04 01:50 +0200
Re: Can't find the DNS Servers Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-04 14:40 +0200
Re: Can't find the DNS Servers David Wright <deblis@lionunicorn.co.uk> - 2017-10-04 19:00 +0200
Re: Can't find the DNS Servers Reco <recoverym4n@gmail.com> - 2017-10-04 08:20 +0200
Re: Can't find the DNS Servers Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-04 14:30 +0200
Re: Can't find the DNS Servers Reco <recoverym4n@gmail.com> - 2017-10-04 14:40 +0200
Re: Can't find the DNS Servers Michael Stone <mstone@debian.org> - 2017-10-04 15:00 +0200
Re: Can't find the DNS Servers Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-04 15:30 +0200
Re: Can't find the DNS Servers David Wright <deblis@lionunicorn.co.uk> - 2017-10-04 19:00 +0200
Re: Can't find the DNS Servers Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-04 19:30 +0200
Re: Can't find the DNS Servers David Wright <deblis@lionunicorn.co.uk> - 2017-10-04 20:40 +0200
Re: Can't find the DNS Servers Gene Heskett <gheskett@shentel.net> - 2017-10-05 00:20 +0200
Re: Can't find the DNS Servers David Wright <deblis@lionunicorn.co.uk> - 2017-10-05 02:30 +0200
Re: Can't find the DNS Servers Gene Heskett <gheskett@shentel.net> - 2017-10-05 04:00 +0200
Re: Can't find the DNS Servers David Wright <deblis@lionunicorn.co.uk> - 2017-10-06 05:00 +0200
Re: Can't find the DNS Servers Gene Heskett <gheskett@shentel.net> - 2017-10-06 07:30 +0200
Re: Can't find the DNS Servers David Wright <deblis@lionunicorn.co.uk> - 2017-10-06 18:00 +0200
Re: Can't find the DNS Servers Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-05 15:00 +0200
Re: Can't find the DNS Servers David Wright <deblis@lionunicorn.co.uk> - 2017-10-06 03:40 +0200
Re: Can't find the DNS Servers Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-06 15:10 +0200
Re: Can't find the DNS Servers David Wright <deblis@lionunicorn.co.uk> - 2017-10-06 18:00 +0200
Re: Can't find the DNS Servers Reco <recoverym4n@gmail.com> - 2017-10-04 20:10 +0200
Re: Can't find the DNS Servers Michael Stone <mstone@debian.org> - 2017-10-04 20:10 +0200
Re: Can't find the DNS Servers Reco <recoverym4n@gmail.com> - 2017-10-04 20:20 +0200
Re: Can't find the DNS Servers David Wright <deblis@lionunicorn.co.uk> - 2017-10-04 20:40 +0200
Re: Can't find the DNS Servers Reco <recoverym4n@gmail.com> - 2017-10-04 22:00 +0200
Re: Can't find the DNS Servers Gary Roach <gary719_list1@verizon.net> - 2017-10-05 01:00 +0200
Re: Can't find the DNS Servers Reco <recoverym4n@gmail.com> - 2017-10-05 08:30 +0200
Re: Can't find the DNS Servers Gary Roach <gary719_list1@verizon.net> - 2017-10-04 22:10 +0200
Re: Can't find the DNS Servers Reco <recoverym4n@gmail.com> - 2017-10-04 22:50 +0200
Re: (solved) Can't find the DNS Servers Gary Roach <gary719_list1@verizon.net> - 2017-10-05 19:10 +0200
Re: (solved) Can't find the DNS Servers Reco <recoverym4n@gmail.com> - 2017-10-05 19:10 +0200
Re: (solved) Can't find the DNS Servers Brian <ad44@cityscape.co.uk> - 2017-10-05 19:40 +0200
Re: (solved) Can't find the DNS Servers Gary Roach <gary719_list1@verizon.net> - 2017-10-05 20:40 +0200
Re: (solved) Can't find the DNS Servers Brian <ad44@cityscape.co.uk> - 2017-10-06 16:10 +0200
Re: Can't find the DNS Servers David Wright <deblis@lionunicorn.co.uk> - 2017-10-02 23:00 +0200
Re: Can't find the DNS Servers Reco <recoverym4n@gmail.com> - 2017-10-02 23:40 +0200
Re: Can't find the DNS Servers David Wright <deblis@lionunicorn.co.uk> - 2017-10-03 05:10 +0200
Re: Can't find the DNS Servers Greg Wooledge <wooledg@eeg.ccf.org> - 2017-09-25 15:00 +0200
Re: Can't find the DNS Servers Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-09-25 15:20 +0200
Re: Can't find the DNS Servers Greg Wooledge <wooledg@eeg.ccf.org> - 2017-09-25 15:30 +0200
Re: Can't find the DNS Servers Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-09-25 15:50 +0200
Re: Can't find the DNS Servers Greg Wooledge <wooledg@eeg.ccf.org> - 2017-09-25 16:00 +0200
Re: Can't find the DNS Servers Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-09-25 16:30 +0200
Re: Can't find the DNS Servers Gary Roach <gary719_list1@verizon.net> - 2017-09-30 04:20 +0200
Re: Can't find the DNS Servers Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-09-30 08:50 +0200
Re: Can't find the DNS Servers Curt <curty@free.fr> - 2017-09-30 14:00 +0200
Re: Can't find the DNS Servers Gene Heskett <gheskett@shentel.net> - 2017-09-25 17:40 +0200
Re: Can't find the DNS Servers Reco <recoverym4n@gmail.com> - 2017-09-25 18:20 +0200
Re: Can't find the DNS Servers Greg Wooledge <wooledg@eeg.ccf.org> - 2017-09-25 18:30 +0200
Re: Can't find the DNS Servers Reco <recoverym4n@gmail.com> - 2017-09-25 18:40 +0200
Re: Can't find the DNS Servers Gene Heskett <gheskett@shentel.net> - 2017-09-25 23:40 +0200
Re: Can't find the DNS Servers David Wright <deblis@lionunicorn.co.uk> - 2017-09-26 20:00 +0200
Re: Can't find the DNS Servers Gene Heskett <gheskett@shentel.net> - 2017-09-26 21:10 +0200
Re: Can't find the DNS Servers Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-09-25 19:40 +0200
Re: Can't find the DNS Servers Greg Wooledge <wooledg@eeg.ccf.org> - 2017-09-25 20:00 +0200
Re: Can't find the DNS Servers Reco <recoverym4n@gmail.com> - 2017-09-25 21:00 +0200
Re: Can't find the DNS Servers Greg Wooledge <wooledg@eeg.ccf.org> - 2017-09-25 21:30 +0200
Re: Can't find the DNS Servers Don Armstrong <don@debian.org> - 2017-09-25 21:30 +0200
Re: Can't find the DNS Servers Greg Wooledge <wooledg@eeg.ccf.org> - 2017-09-25 21:50 +0200
Re: Can't find the DNS Servers Don Armstrong <don@debian.org> - 2017-09-25 23:20 +0200
Re: Can't find the DNS Servers Greg Wooledge <wooledg@eeg.ccf.org> - 2017-09-26 15:20 +0200
Re: Can't find the DNS Servers <tomas@tuxteam.de> - 2017-09-26 15:50 +0200
Re: Can't find the DNS Servers Darac Marjal <mailinglist@darac.org.uk> - 2017-09-26 16:10 +0200
Re: Can't find the DNS Servers Gene Heskett <gheskett@shentel.net> - 2017-09-26 17:40 +0200
Re: Can't find the DNS Servers Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-09-26 16:30 +0200
Re: Can't find the DNS Servers Gene Heskett <gheskett@shentel.net> - 2017-09-26 17:30 +0200
Re: Can't find the DNS Servers Michael Stone <mstone@debian.org> - 2017-09-26 17:40 +0200
Re: Can't find the DNS Servers <tomas@tuxteam.de> - 2017-09-26 17:40 +0200
Re: Can't find the DNS Servers Gene Heskett <gheskett@shentel.net> - 2017-09-26 18:00 +0200
Finding the appropriate manpage [Re: Can't find the DNS Servers] Don Armstrong <don@debian.org> - 2017-09-26 23:20 +0200
Re: Finding the appropriate manpage [Re: Can't find the DNS Servers] Lck Ras <likcoras@riseup.net> - 2017-09-27 16:20 +0200
Re: Finding the appropriate manpage [Re: Can't find the DNS Servers] Curt <curty@free.fr> - 2017-09-27 17:20 +0200
Re: Can't find the DNS Servers Gene Heskett <gheskett@shentel.net> - 2017-09-26 00:50 +0200
Re: Can't find the DNS Servers David Wright <deblis@lionunicorn.co.uk> - 2017-09-26 20:50 +0200
Re: Can't find the DNS Servers Greg Wooledge <wooledg@eeg.ccf.org> - 2017-09-26 21:10 +0200
Re: Can't find the DNS Servers Gene Heskett <gheskett@shentel.net> - 2017-09-26 21:40 +0200
Re: Can't find the DNS Servers Greg Wooledge <wooledg@eeg.ccf.org> - 2017-09-26 21:50 +0200
Re: Can't find the DNS Servers Michael Stone <mstone@debian.org> - 2017-09-26 22:10 +0200
Re: Can't find the DNS Servers Gene Heskett <gheskett@shentel.net> - 2017-09-27 05:30 +0200
Re: Can't find the DNS Servers David Wright <deblis@lionunicorn.co.uk> - 2017-09-27 00:50 +0200
Re: Can't find the DNS Servers Gene Heskett <gheskett@shentel.net> - 2017-09-26 21:30 +0200
Re: Can't find the DNS Servers Greg Wooledge <wooledg@eeg.ccf.org> - 2017-09-26 21:50 +0200
Re: Can't find the DNS Servers Gene Heskett <gheskett@shentel.net> - 2017-09-27 05:40 +0200
Re: Can't find the DNS Servers Celejar <celejar@gmail.com> - 2017-09-26 05:20 +0200
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Darac Marjal <mailinglist@darac.org.uk> |
|---|---|
| Date | 2017-09-26 16:10 +0200 |
| Message-ID | <utYIF-5O1-5@gated-at.bofh.it> |
| In reply to | #187244 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, Sep 26, 2017 at 09:09:47AM -0400, Greg Wooledge wrote: >On Mon, Sep 25, 2017 at 02:12:07PM -0700, Don Armstrong wrote: >> On Mon, 25 Sep 2017, Greg Wooledge wrote: >> > On Mon, Sep 25, 2017 at 12:20:45PM -0700, Don Armstrong wrote: >> > > as is documented in dhclient-script(8): >> > >> > Well now that's just EVIL. :-( >> >> It's much more powerful than a single variable because you can have it >> do *anything*. > >No, you don't understand. I had no idea that man page EXISTED! >For years, I have been searching back and forth and up and down in >dhclient(8) and dhclient.conf(5) and finding NOTHING. > >Turns out the REASON I couldn't find anything was because some bright >spark decided to split the documentation into multiple man pages. > >> > Well now that's just EVIL. :-( > >So, apparently the only way to find anything is to open umpteen terminal >windows, one man page in each terminal window. Jump to the bottom of >each man page, find the SEE ALSO section, open EVERY linked man page in >another terminal window. Recursively. Then perform your searches in >every single window in parallel until one of them hits. > [cut] > >All this grief and agony because they couldn't just put all the >information that THE MOST COMMON USE CASES will need into a single >document. > [tl;dr] I think you might be under a misconception about what man pages are FOR. From the first few lines of "man man": man - an interface to the on-line reference manuals They are *reference* manuals. I believe that the point of man pages is to answer questions such as: * What's the option for filtering out files: --filter or --exclude * What was that weird option for doing something dangerous "DoWhatIWant"... "YesIReallyMeanThis"... something like that. * Can I perform this action recursively? As a result, man pages are usually little more than lists of command line parameters which explanations of what they do. What man pages generally DON'T cover are: * How do I use this program for X? * Why do I need this program? * What the difference between this program and that program? * How do I use this program with that program? The GNU solution to that was the 'info' system. 'info' is a hyperlinked text format - a bit like having a web site on your computer. Look at the info page for grub, as an example: the information is grouped by topic, there's obscure things like limitations on the core size per platform and so on. It's just a pity that most programs don't provide info pages. -- For more information, please reread.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-09-26 17:40 +0200 |
| Message-ID | <uu07M-6zu-9@gated-at.bofh.it> |
| In reply to | #187249 |
On Tuesday 26 September 2017 10:04:42 Darac Marjal wrote: > On Tue, Sep 26, 2017 at 09:09:47AM -0400, Greg Wooledge wrote: > >On Mon, Sep 25, 2017 at 02:12:07PM -0700, Don Armstrong wrote: > >> On Mon, 25 Sep 2017, Greg Wooledge wrote: > >> > On Mon, Sep 25, 2017 at 12:20:45PM -0700, Don Armstrong wrote: > >> > > as is documented in dhclient-script(8): > >> > > >> > Well now that's just EVIL. :-( > >> > >> It's much more powerful than a single variable because you can have > >> it do *anything*. > > > >No, you don't understand. I had no idea that man page EXISTED! > >For years, I have been searching back and forth and up and down in > >dhclient(8) and dhclient.conf(5) and finding NOTHING. > > > >Turns out the REASON I couldn't find anything was because some bright > >spark decided to split the documentation into multiple man pages. > > > >> > Well now that's just EVIL. :-( > > > >So, apparently the only way to find anything is to open umpteen > > terminal windows, one man page in each terminal window. Jump to the > > bottom of each man page, find the SEE ALSO section, open EVERY > > linked man page in another terminal window. Recursively. Then > > perform your searches in every single window in parallel until one > > of them hits. > > [cut] > > >All this grief and agony because they couldn't just put all the > >information that THE MOST COMMON USE CASES will need into a single > >document. > > [tl;dr] > > I think you might be under a misconception about what man pages are > FOR. > > From the first few lines of "man man": > > man - an interface to the on-line reference manuals > > They are *reference* manuals. I believe that the point of man pages is > to answer questions such as: > > * What's the option for filtering out files: --filter or --exclude > * What was that weird option for doing something dangerous > "DoWhatIWant"... "YesIReallyMeanThis"... something like that. > * Can I perform this action recursively? > > As a result, man pages are usually little more than lists of command > line parameters which explanations of what they do. > > What man pages generally DON'T cover are: > > * How do I use this program for X? > * Why do I need this program? > * What the difference between this program and that program? > * How do I use this program with that program? > > The GNU solution to that was the 'info' system. 'info' is a > hyperlinked text format - a bit like having a web site on your > computer. Look at the info page for grub, as an example: the > information is grouped by topic, there's obscure things like > limitations on the core size per platform and so on. > > It's just a pity that most programs don't provide info pages. Ditto the more intelligent yet, pinfo. 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) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2017-09-26 16:30 +0200 |
| Message-ID | <utZ22-5UA-19@gated-at.bofh.it> |
| In reply to | #187244 |
Le 26/09/2017 à 15:09, Greg Wooledge a écrit : > > lucky, I'll focus on that page rather than dhcp-options(5) which is > very confusing, and seems to be talking in abstractions. It sure as > hell doesn't clearly define what options go in what files, nor even > which options are for the client and which are for the server. dhcp-options(5) describes options of the DHCP protocol itself, so they apply to both clients and servers. > Their > only mentions of resolv.conf are in a DHCPV6 section. What the hell > is DHCPV6? Does it have something to do with IPv6? Yes, DHCPv6 is the IPv6 version of DHCP. > How would I know whether I'm using DHCPV6 or not? Tough question. It depends on how you configure your network interfaces, with /etc/network/interfaces, NetworkManager or whatever... I do not use it because I am satisfied with the simpler IPv6 stateless auto-configuration (SLAAC) protocol on the client stations, and static IPv6 configuration on the servers.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-09-26 17:30 +0200 |
| Message-ID | <utZY5-6wo-19@gated-at.bofh.it> |
| In reply to | #187244 |
On Tuesday 26 September 2017 09:09:47 Greg Wooledge wrote: > On Mon, Sep 25, 2017 at 02:12:07PM -0700, Don Armstrong wrote: > > On Mon, 25 Sep 2017, Greg Wooledge wrote: > > > On Mon, Sep 25, 2017 at 12:20:45PM -0700, Don Armstrong wrote: > > > > as is documented in dhclient-script(8): > > > > > > Well now that's just EVIL. :-( > > > > It's much more powerful than a single variable because you can have > > it do *anything*. > > No, you don't understand. I had no idea that man page EXISTED! > For years, I have been searching back and forth and up and down in > dhclient(8) and dhclient.conf(5) and finding NOTHING. > > Turns out the REASON I couldn't find anything was because some bright > spark decided to split the documentation into multiple man pages. > > > > Well now that's just EVIL. :-( > > So, apparently the only way to find anything is to open umpteen > terminal windows, one man page in each terminal window. Jump to the > bottom of each man page, find the SEE ALSO section, open EVERY linked > man page in another terminal window. Recursively. Then perform your > searches in every single window in parallel until one of them hits. > > So let's see... I'll assume dhclient(8) is the root of the search > tree. This links to dhcpd(8), dhcrelay(8), dhclient-script(8), > dhclient.conf(5), dhclient.leases(5), dhcp-eval(5). So now I need > to open 6 more windows, or 7 total. > > dhcpd(8) doesn't exist, because this isn't a server, so make it 6. > > dhcrelay(8) doesn't exist. Don't even know what that is. 5. > > dhclient-script(8) links to dhclient(8), dhcpd(8), dhcrelay(8), > dhclient.conf(5), dhclient.leases(5). No new windows. > > dhclient.conf(5) links to dhcp-options(5), dhcp-eval(5), > dhclient.leases(5), dhcpd(8), dhcpd.conf(5). dhcpd.conf(5) doesn't > exist, so just one new window, for dhcp-options(5). I'm up to 6 open > now. > > dhclient.leases(5) links to dhclient(8), dhcp-options(5), > dhclient.conf(5), dhcpd(8), dhcpd.conf(5). No new ones. > > dhcp-eval(5) links to dhcpd.conf(5), dhcpd.leases(5), > dhclient.conf(5), dhcp-options(5), dhcpd(8), dhclient(8). > dhcpd.leases(5) doesn't exist, so no new ones. > > dhcp-options(5) links to dhcpd.conf(5), dhcpd.leases(5), > dhclient.conf(5), dhcp-eval(5), dhcpd(8), dhclient(8). No new ones. > > So I've got my 6 terminal windows open. I've spent 10 minutes so far, > and I haven't even READ a single bit of any of the pages. Just the > SEE ALSOs. > > Now I get to try to wrack my brain for keywords, and repeat my keyword > searches 6 times, once in every window. > > Turns out "resolv" (my first keyword) pops up in window #2, which is > dhclient-script(8), and also in window #6, dhcp-options(5). > > From there, you can guess what the next steps are, because apparently > you were already aware of the existence of dhclient-script(8). If I'm > lucky, I'll focus on that page rather than dhcp-options(5) which is > very confusing, and seems to be talking in abstractions. It sure as > hell doesn't clearly define what options go in what files, nor even > which options are for the client and which are for the server. Their > only mentions of resolv.conf are in a DHCPV6 section. What the hell > is DHCPV6? Does it have something to do with IPv6? How would I know > whether I'm using DHCPV6 or not? Try searching for V6 in the other > five windows... nothing at all! And so on. > > All this grief and agony because they couldn't just put all the > information that THE MOST COMMON USE CASES will need into a single > document. > > What are the most common use cases? An excellent question. Here's > my guess: > > 1) Client is plugged into the network without being configured. > Simply uses whatever the DHCP server spits out. If that's wrong, too > bad. > > 2) Client uses what the DHCP server spits out, but the administrator > of the client will try to work around whichever bits of the DHCP > server's responses are wrong. In my experience, it's the > nameservers that are most likely to need local adjustment. That's why > you have this thread. And all the previous threads. And all the web > pages out there that advise people to use chattr +i. And all the > people who use chattr +i. And all the self-proclaimed experts who say > "No, you're doing it wrong!" but then don't offer a better way. > > 3) Client uses what the DHCP server spits out, but the administrator > of the client is also the administrator of the DHCP server, and can > correct things in the DHCP server to make all the clients happy. > > The first use case needs no documentation at all. > > The second use case needs some way for the admin of the client to be > able to search for resolv.conf in the documentation and actually FIND > IT. I searched in dhclient(8) and in dhclient.conf(5) and fid not find > it. I honestly, truly believed that I had done my best. That I had > put in the required effort. That I had been intelligent and diligent > and resourceful. That I had given the software the benefit of the > doubt, but this feature was simply not present, or not documented > anywhere. > > The third use case... well, that's not me right now. In the past I > have set up a DHCP server on an OpenBSD machine, and found things to > be fairly straightforward. I was able to find the options I needed, > and what file to put them in, and so on. It's really obvious and > simple where you put the nameservers when you have control of the > server. > > It's clear that the INTENDED way is for the configuration to be done > on the server. > > But, you see, most people DO NOT HAVE CONTROL OF THE SERVER. > > So, my conclusion based on my experiences was that the only way to > configure ISC's DHCP to end up with correct nameservers on the client > was to have control of the server, or to subvert the client's > execution environment in such a way that dhclient cannot modify > resolv.conf at all (e.g. chattr +i). > > I believed this for YEARS. > > And then you said this: > > > > as is documented in dhclient-script(8): > > Which, by the way, is NOT referenced from dhclient.conf(5)'s SEE ALSO > section. Because, why would the primary client configuration document > make it easy to find the instructions for configuring the client? > > > > Well now that's just EVIL. :-( > > And then you didn't even understand my response. Which just shows how > completely out of touch with each other the various groups are. + at least 10,000. This nail has been beat completely thru a 12" thick marble wall, and this gentleman has defined the problem that exists with many of the man pages, not exclusive to dhcp related stuffs, its an endemic linux virus that makes it 100x more difficult for the user who can read (and there are some who can read but not grok) to take the advantages offered and use them to get his job done without half a megabyte of pleading with a mailing list for enlightenment. I'll give you the ip man page as another perfect example. I've never read a more obtuse manpage in my life. I get the impression the manpage writer is charged 10 dollars a word for emmiting anything over 100 words. The whole man pages tree on the install I am currently doing is 13 megabytes. The sd card its on is 32 gigabytes, so we'll have at least 10 gigabytes we could use for man pages without impacting its ability to store and use a 300 kilobyte package, if they were just written to teach us what to do. 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) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2017-09-26 17:40 +0200 |
| Message-ID | <uu07M-6zu-3@gated-at.bofh.it> |
| In reply to | #187257 |
On Tue, Sep 26, 2017 at 11:21:35AM -0400, Gene Heskett wrote: >I'll give you the ip man page as another perfect example. I've never >read a more obtuse manpage in my life. I get the impression the manpage >writer is charged 10 dollars a word for emmiting anything over 100 >words. > >The whole man pages tree on the install I am currently doing is 13 >megabytes. The sd card its on is 32 gigabytes, so we'll have at least >10 gigabytes we could use for man pages without impacting its ability to >store and use a 300 kilobyte package, if they were just written to teach >us what to do. If you aren't volunteering to write the man pages, could you at least tone down the rhetoric and find a way to express your concerns without the name calling and insulting characterizations? Mike Stone
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2017-09-26 17:40 +0200 |
| Message-ID | <uu07M-6zu-13@gated-at.bofh.it> |
| In reply to | #187258 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Sep 26, 2017 at 11:30:48AM -0400, Michael Stone wrote: [...] > If you aren't volunteering to write the man pages, could you at > least tone down the rhetoric and find a way to express your concerns > without the name calling and insulting characterizations? Thankyou. - -- t -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlnKdBUACgkQBcgs9XrR2kb/jACdFB+v3ppXa1sZXhEtTRloqYUH 0AYAn0Dcx12s+iPuaN+J0Zm73zKXwVeT =Cf+p -----END PGP SIGNATURE-----
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-09-26 18:00 +0200 |
| Message-ID | <uu0r7-6G9-9@gated-at.bofh.it> |
| In reply to | #187258 |
On Tuesday 26 September 2017 11:30:48 Michael Stone wrote: > On Tue, Sep 26, 2017 at 11:21:35AM -0400, Gene Heskett wrote: > >I'll give you the ip man page as another perfect example. I've never > >read a more obtuse manpage in my life. I get the impression the > > manpage writer is charged 10 dollars a word for emmiting anything > > over 100 words. > > > >The whole man pages tree on the install I am currently doing is 13 > >megabytes. The sd card its on is 32 gigabytes, so we'll have at > > least 10 gigabytes we could use for man pages without impacting its > > ability to store and use a 300 kilobyte package, if they were just > > written to teach us what to do. > > If you aren't volunteering to write the man pages, could you at least > tone down the rhetoric and find a way to express your concerns without > the name calling and insulting characterizations? > > Mike Stone I am not calling out a specific authors name, but as Johnny Carson once said in paraphrasing words if the foo shits, wear it. Looking at the overall picture vis-a-vis man pages, I call 'em like I see 'em. Remaining life to enjoy a well written manpage or pinfo output, for me is too short to do otherwise. I've had my 4 score + a few years already. 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) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Don Armstrong <don@debian.org> |
|---|---|
| Date | 2017-09-26 23:20 +0200 |
| Subject | Finding the appropriate manpage [Re: Can't find the DNS Servers] |
| Message-ID | <uu5qO-1Br-17@gated-at.bofh.it> |
| In reply to | #187244 |
On Tue, 26 Sep 2017, Greg Wooledge wrote: > For years, I have been searching back and forth and up and down in > dhclient(8) and dhclient.conf(5) and finding NOTHING. > Turns out the REASON I couldn't find anything was because some bright > spark decided to split the documentation into multiple man pages. > So, apparently the only way to find anything is to open umpteen > terminal windows, one man page in each terminal window. In almost every case, if you don't know the right man page, apropos (or man -k) will help you find it. If that's not good enough, man -K dhclient will eventually find all of them. dhclient (8) - Dynamic Host Configuration Protocol Client dhclient-script (8) - DHCP client network configuration script dhclient.conf (5) - DHCP client configuration file dhclient.leases (5) - DHCP client lease database alternatively, you could run dpkg -L isc-dhcp-client|grep man; to see all of the manpages that the dhcp client provides: /usr/share/man/man5/dhclient.conf.5.gz /usr/share/man/man5/dhclient.leases.5.gz /usr/share/man/man8/dhclient-script.8.gz /usr/share/man/man8/dhclient.8.gz -- Don Armstrong https://www.donarmstrong.com Those who begin coercive elimination of dissent soon find themselves exterminating dissenters. Compulsory unification of opinion achieves only the unanimity of the graveyard. -- Justice Roberts in 319 U.S. 624 (1943)
[toc] | [prev] | [next] | [standalone]
| From | Lck Ras <likcoras@riseup.net> |
|---|---|
| Date | 2017-09-27 16:20 +0200 |
| Subject | Re: Finding the appropriate manpage [Re: Can't find the DNS Servers] |
| Message-ID | <uullT-4d4-5@gated-at.bofh.it> |
| In reply to | #187286 |
On 09/27/2017 06:16 AM, Don Armstrong wrote:
> In almost every case, if you don't know the right man page, apropos (or
> man -k) will help you find it. If that's not good enough, man -K
> dhclient will eventually find all of them.
>
> dhclient (8) - Dynamic Host Configuration Protocol Client
> dhclient-script (8) - DHCP client network configuration script
> dhclient.conf (5) - DHCP client configuration file
> dhclient.leases (5) - DHCP client lease database
Plus the dhclient(8) manpage lists other related manuals in its SEE ALSO
section:
SEE ALSO
dhcpd(8), dhcrelay(8), dhclient-script(8), dhclient.conf(5),
dhclient.leases(5), dhcp-eval(5).
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2017-09-27 17:20 +0200 |
| Subject | Re: Finding the appropriate manpage [Re: Can't find the DNS Servers] |
| Message-ID | <uumhY-4St-11@gated-at.bofh.it> |
| In reply to | #187309 |
On 2017-09-27, Lck Ras <likcoras@riseup.net> wrote: > On 09/27/2017 06:16 AM, Don Armstrong wrote: >> In almost every case, if you don't know the right man page, apropos (or >> man -k) will help you find it. If that's not good enough, man -K >> dhclient will eventually find all of them. >> >> dhclient (8) - Dynamic Host Configuration Protocol Client >> dhclient-script (8) - DHCP client network configuration script >> dhclient.conf (5) - DHCP client configuration file >> dhclient.leases (5) - DHCP client lease database > > Plus the dhclient(8) manpage lists other related manuals in its SEE ALSO > section: > > SEE ALSO > dhcpd(8), dhcrelay(8), dhclient-script(8), dhclient.conf(5), > dhclient.leases(5), dhcp-eval(5). > Plus there is a new thing in town called the Internet, an extensive respository of searchable knowledge (as well as invidious horseshit). I put 'dhclient resolv.conf' into the Evil Search Engine (TM) and the very first hit spoke of the very dhclient-script hookerino suggested by D. Armstrong. For kicks, I just put the following search terms in the search engine mentioned above, in plain English: how do you prevent dhclient from modifying resolv.conf First hit, third post in the thread, D. Armstrong's hookerino: https://www.centos.org/forums/viewtopic.php?t=24741 Put me down as unconvinced (by anything--I know, I know, this has nothing to do with man pages, but if 'they' can change the subject in mid-stream, why can't I--though I didn't, I mean up there)? -- "A simpering Bambi narcissist and a thieving, fanatical Albanian dwarf." Christopher Hitchens, commenting shortly after the nearly concurrent deaths of Lady Diana and Mother Theresa.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-09-26 00:50 +0200 |
| Message-ID | <utKmm-4iS-1@gated-at.bofh.it> |
| In reply to | #187194 |
On Monday 25 September 2017 13:53:17 Greg Wooledge wrote:
> On Mon, Sep 25, 2017 at 07:32:05PM +0200, Pascal Hambourg wrote:
> > Le 25/09/2017 à 17:33, Gene Heskett a écrit :
> > > For me, its a root session, and a "chattr +i resolv.conf"
> >
> > Here we have a saying that roughly translates to :
> > "When you have a hammer, any problem looks like a nail."
>
> No. Seriously, just stop.
>
> Those of us who have done chattr +i on one or more systems have, in
> many cases, TRIED OTHER SOLUTIONS first and found them wanting.
>
> Take me for example.
>
> At work, I edited /etc/dhcp/dhclient.conf and removed the options that
> tell dhclient to ask for domain-name-servers (et al.). This works
> fine for me at work. The DHCP servers at work respect my wish not to
> be given a domain-name-server, so dhclient never touches resolv.conf
> and everyone is happy.
>
> Then I tried the same thing at home.
>
> The results were NOT the same.
>
> The Belkin plastic router at home sends me a domain-name-server even
> if I do not ask for one. And dhclient apparently overwrites
> resolv.conf every time it receives a domain-name-server from the DHCP
> server.
>
> EVEN IF IT DID NOT REQUEST ONE.
>
> So, the solution that I used at work does not work at home.
>
> You know what DOES work, though?
>
> chattr +i works.
>
> Do I prefer this solution? No.
>
> Would I be happier if I could use a more elegant solution? Yes.
>
> Should the dhclient program have a CONFIG FILE OPTION to say
> "NEVER TOUCH THE resolv.conf FILE"? YES!
>
> Does it? NO!
>
> Do I expect it ever to have one in the future? BWA-hahahaha! No.
>
> So we use what works, because the other choices don't fucking work.
>
> This is not about lack of creativity.
>
> It is not about being too blind or ignorant or stubborn to use the
> other solutions. ("Everything looks like a nail.")
>
> This is about the other soluttions NOT WORKING.
>
> It is about ISC being too blind or ignorant or stubborn to consider
> that many people run the DHCP client software WITHOUT being the ones
> in charge of the DHCP server on the same network.
>
> Or, not considering that many people use cheap plastic consumer-grade
> routers that don't behave the same way the ISC DHCP server behaves.
>
> Am I getting through yet?
I am with Greg on this one. And I HAVE tried everything the man pages
tell me, and it does NOT work, so I do what DOES WORK. Someday, maybe
dhcpd will be smart enough to actually do what we tell it to do.
But that day hasn't even shown a cloud of dust on the time horizon I can
see from a 83 yo in <2 weeks viewpoint.
Because all you so-called experts THINK it works ok the way it is, we
get badmouthed and called idiots. Bad dog, no biscuit, not even the
smell of one in an all static network situation.
Something that I have been dealing with on a daily basis now for
something like 24 years at a tv station as its CE. We were, I think, the
first tv station in the US to have a web page, folks had to dial it up
for the first 6 months. Then we bought a block of 16 addresses, and a
56k line, and put the amiga that served it on one of the addresses. Jim
and I wrote that web server in ARexx.
If you want to be called an expert, first go fix dhcpd. Or n-m, but it
likely uses dhcpd to do its damage. Then ask to be called an expert.
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)
Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2017-09-26 20:50 +0200 |
| Message-ID | <uu35E-8ph-25@gated-at.bofh.it> |
| In reply to | #187217 |
On Mon 25 Sep 2017 at 18:41:33 (-0400), Gene Heskett wrote:
> On Monday 25 September 2017 13:53:17 Greg Wooledge wrote:
>
> > On Mon, Sep 25, 2017 at 07:32:05PM +0200, Pascal Hambourg wrote:
> > > Le 25/09/2017 à 17:33, Gene Heskett a écrit :
> > > > For me, its a root session, and a "chattr +i resolv.conf"
> > >
> > > Here we have a saying that roughly translates to :
> > > "When you have a hammer, any problem looks like a nail."
> >
> > No. Seriously, just stop.
> >
> > Those of us who have done chattr +i on one or more systems have, in
> > many cases, TRIED OTHER SOLUTIONS first and found them wanting.
> >
> > Take me for example.
> >
> > At work, I edited /etc/dhcp/dhclient.conf and removed the options that
> > tell dhclient to ask for domain-name-servers (et al.). This works
> > fine for me at work. The DHCP servers at work respect my wish not to
> > be given a domain-name-server, so dhclient never touches resolv.conf
> > and everyone is happy.
> >
> > Then I tried the same thing at home.
> >
> > The results were NOT the same.
> >
> > The Belkin plastic router at home sends me a domain-name-server even
> > if I do not ask for one. And dhclient apparently overwrites
> > resolv.conf every time it receives a domain-name-server from the DHCP
> > server.
> >
> > EVEN IF IT DID NOT REQUEST ONE.
> >
> > So, the solution that I used at work does not work at home.
> >
> > You know what DOES work, though?
> >
> > chattr +i works.
> >
> > Do I prefer this solution? No.
> >
> > Would I be happier if I could use a more elegant solution? Yes.
> >
> > Should the dhclient program have a CONFIG FILE OPTION to say
> > "NEVER TOUCH THE resolv.conf FILE"? YES!
> >
> > Does it? NO!
> >
> > Do I expect it ever to have one in the future? BWA-hahahaha! No.
> >
> > So we use what works, because the other choices don't fucking work.
> >
> > This is not about lack of creativity.
> >
> > It is not about being too blind or ignorant or stubborn to use the
> > other solutions. ("Everything looks like a nail.")
> >
> > This is about the other soluttions NOT WORKING.
> >
> > It is about ISC being too blind or ignorant or stubborn to consider
> > that many people run the DHCP client software WITHOUT being the ones
> > in charge of the DHCP server on the same network.
> >
> > Or, not considering that many people use cheap plastic consumer-grade
> > routers that don't behave the same way the ISC DHCP server behaves.
> >
> > Am I getting through yet?
>
> I am with Greg on this one. And I HAVE tried everything the man pages
> tell me, and it does NOT work, so I do what DOES WORK. Someday, maybe
> dhcpd will be smart enough to actually do what we tell it to do.
>
> But that day hasn't even shown a cloud of dust on the time horizon I can
> see from a 83 yo in <2 weeks viewpoint.
>
> Because all you so-called experts THINK it works ok the way it is, we
> get badmouthed and called idiots. Bad dog, no biscuit, not even the
> smell of one in an all static network situation.
Well sometimes I wonder if we're using different tools, so I always
treat your fixes with a great deal of salt. For example, I could
bypass the partitioner in the Debian-installer, I couldn't make
aptitude destroy my system by removing lots of packages without
explicitly being told to, and I couldn't make # passwd demand
the old password, to name a few examples.
On this topic, I still can't understand the contents of your
immutable /etc/resolv.conf file, even without the comma:
nameserver 192.168.XX.1
search host dns
domain coyote.den
Can you detail these domains called host and dns?
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2017-09-26 21:10 +0200 |
| Message-ID | <uu3p1-jm-49@gated-at.bofh.it> |
| In reply to | #187270 |
On Tue, Sep 26, 2017 at 01:42:39PM -0500, David Wright wrote: > On this topic, I still can't understand the contents of your > immutable /etc/resolv.conf file, even without the comma: > > nameserver 192.168.XX.1 > search host dns > domain coyote.den > > Can you detail these domains called host and dns? I keep thinking that it's some relic from libc4 or libc5, before the adoption of nsswitch.conf, but I am at a loss how to find documentation that old to prove or disprove my guess. The nearest I could find is <http://www.tldp.org/LDP/nag/node82.html> which describes an /etc/host.conf file that contains "order bind hosts". I can't tell whether Gene's setup is an erroneous take on this obsolete configuration file (somehow merging it into resolv.conf), or something else entirely. Perhaps something even older, or something from a non-Linux system.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-09-26 21:40 +0200 |
| Message-ID | <uu3S2-ts-5@gated-at.bofh.it> |
| In reply to | #187274 |
On Tuesday 26 September 2017 14:59:41 Greg Wooledge wrote: > On Tue, Sep 26, 2017 at 01:42:39PM -0500, David Wright wrote: > > On this topic, I still can't understand the contents of your > > immutable /etc/resolv.conf file, even without the comma: > > > > nameserver 192.168.XX.1 > > search host dns > > domain coyote.den > > > > Can you detail these domains called host and dns? > > I keep thinking that it's some relic from libc4 or libc5, before the > adoption of nsswitch.conf, but I am at a loss how to find > documentation that old to prove or disprove my guess. > > The nearest I could find is <http://www.tldp.org/LDP/nag/node82.html> > which describes an /etc/host.conf file that contains "order bind > hosts". I can't tell whether Gene's setup is an erroneous take on this > obsolete configuration file (somehow merging it into resolv.conf), or > something else entirely. Perhaps something even older, or something > from a non-Linux system. I started with Red Hat 5.0, in the late '90's. And it looks like stretch may have deprecated the executable, locate can only find the .conf files, one in /etc, and one in /usr/share/libc-bin/nsswitch.conf. Maybe its something libc-bin uses? They are identical FWTW. 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) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2017-09-26 21:50 +0200 |
| Message-ID | <uu41J-zi-51@gated-at.bofh.it> |
| In reply to | #187279 |
On Tue, Sep 26, 2017 at 03:33:48PM -0400, Gene Heskett wrote:
> > > nameserver 192.168.XX.1
> > > search host dns
> > > domain coyote.den
> I started with Red Hat 5.0, in the late '90's. And it looks like stretch
> may have deprecated the executable, locate can only find the .conf
> files, one in /etc, and one in /usr/share/libc-bin/nsswitch.conf. Maybe
> its something libc-bin uses? They are identical FWTW.
>From Red Hat 5.2 (Apollo) resolver(5):
NAME
resolver - resolver configuration file
SYNOPSIS
/etc/resolv.conf
...
search Search list for host-name lookup. The search list is normally
determined from the local domain name; by default, it contains
only the local domain name. This may be changed by listing the
desired domain search path following the search keyword with
spaces or tabs separating the names. Most resolver queries will
be attempted using each component of the search path in turn un-
til a match is found. Note that this process may be slow and
will generate a lot of network traffic if the servers for the
listed domains are not local, and that queries will time out if
no server is available for one of the domains.
The search list is currently limited to six domains with a total
of 256 characters.
...
4th Berkeley Distribution November 11, 1993 1
I still think you're carrying along some mistake that you made decades
ago, which has simply never caused any problems, but is also not doing
anything beneficial. But if you can tell us *which* man page you saw
this in, that would be of interest.
P.S. there's nothing new in stretch here. Even the wheezy man page for
resolv.conf(5) looks basically the same as stretch's. Compare:
https://manpages.debian.org/wheezy/manpages/resolv.conf.5.en.html
https://manpages.debian.org/stretch/manpages/resolv.conf.5.en.html
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2017-09-26 22:10 +0200 |
| Message-ID | <uu4l4-V9-11@gated-at.bofh.it> |
| In reply to | #187282 |
On Tue, Sep 26, 2017 at 03:43:35PM -0400, Greg Wooledge wrote:
>NAME
> resolver - resolver configuration file
>
>SYNOPSIS
> /etc/resolv.conf
>
>...
> search Search list for host-name lookup. The search list is normally
> determined from the local domain name; by default, it contains
> only the local domain name. This may be changed by listing the
> desired domain search path following the search keyword with
> spaces or tabs separating the names. Most resolver queries will
> be attempted using each component of the search path in turn un-
> til a match is found. Note that this process may be slow and
> will generate a lot of network traffic if the servers for the
> listed domains are not local, and that queries will time out if
> no server is available for one of the domains.
>
> The search list is currently limited to six domains with a total
> of 256 characters.
>...
>4th Berkeley Distribution November 11, 1993 1
>
>
>I still think you're carrying along some mistake that you made decades
>ago, which has simply never caused any problems, but is also not doing
>anything beneficial.
This. Here's an extract from the oldest debian man page I know of for
this file (from 1995--and people complain about how up to date the
documentation is today!):
domain Local domain name. Most queries for names within
this domain can use short names relative to the
local domain. If no domain entry is present, the
domain is determined from the local host name
returned by gethostname(2); the domain part is
taken to be everything after the first `.'.
Finally, if the host name does not contain a domain
part, the root domain is assumed.
search Search list for host-name lookup. The search list
is normally determined from the local domain name;
by default, it begins with the local domain name,
then successive parent domains that have at least
two components in their names. This may be changed
by listing the desired domain search path following
the search keyword with spaces or tabs separating
the names. Most resolver queries will be attempted
December 14, 1989 1
RESOLVER(5) RESOLVER(5)
using each component of the search path in turn
until a match is found. Note that this process may
be slow and will generate a lot of network traffic
if the servers for the listed domains are not
local, and that queries will time out if no server
is available for one of the domains.
The search list is currently limited to six domains
with a total of 256 characters.
The domain and search keywords are mutually exclusive. If
more than one instance of these keywords is present, the
last instance will override.
The last paragraph is why it's just odd, not problematic. The current
man page is basically identical.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-09-27 05:30 +0200 |
| Message-ID | <uubcR-5fT-5@gated-at.bofh.it> |
| In reply to | #187282 |
On Tuesday 26 September 2017 15:43:35 Greg Wooledge wrote:
> On Tue, Sep 26, 2017 at 03:33:48PM -0400, Gene Heskett wrote:
> > > > nameserver 192.168.XX.1
> > > > search host dns
> > > > domain coyote.den
> >
> > I started with Red Hat 5.0, in the late '90's. And it looks like
> > stretch may have deprecated the executable, locate can only find the
> > .conf files, one in /etc, and one in
> > /usr/share/libc-bin/nsswitch.conf. Maybe its something libc-bin
> > uses? They are identical FWTW.
>
> From Red Hat 5.2 (Apollo) resolver(5):
>
>
> NAME
> resolver - resolver configuration file
>
> SYNOPSIS
> /etc/resolv.conf
>
> ...
> search Search list for host-name lookup. The search list is
> normally determined from the local domain name; by default, it
> contains only the local domain name. This may be changed by listing
> the desired domain search path following the search keyword with
> spaces or tabs separating the names. Most resolver queries will be
> attempted using each component of the search path in turn un- til a
> match is found. Note that this process may be slow and will generate
> a lot of network traffic if the servers for the listed domains are not
> local, and that queries will time out if no server is available for
> one of the domains.
>
> The search list is currently limited to six domains with
> a total of 256 characters.
> ...
> 4th Berkeley Distribution November 11, 1993
> 1
>
>
> I still think you're carrying along some mistake that you made decades
> ago, which has simply never caused any problems, but is also not doing
> anything beneficial. But if you can tell us *which* man page you saw
> this in, that would be of interest.
>
> P.S. there's nothing new in stretch here. Even the wheezy man page
> for resolv.conf(5) looks basically the same as stretch's. Compare:
>
> https://manpages.debian.org/wheezy/manpages/resolv.conf.5.en.html
> https://manpages.debian.org/stretch/manpages/resolv.conf.5.en.html
For stretch, I'm looking at the manpage from an arm64 based card. And
I've checked the rest of the mostly wheezy machines. The first machine,
running my G0704 had:
order hosts nameserver
and its worked well that way for 2 years. But I changed it out for
search etc etc anyway.
next is the ark/intel shoebox running a small Chinese 7x12 lathe I call
lathe, affectionately known as TLM, for The Little Monster, it has a 1
hp spindle motor and is forever breaking drive parts.
It has only one line, the nameserver address in the router, which must
know about the local net as it can ping the rest of the machines just
fine. So that one is wrong, and its been wrong since sometime in July
2015. I really ought to fix it. But it also Just Works(TM).
Next is a small 4 axis milling machine called shop. It has:
search hosts,dns
nameserver 192.168.71.1
note comma, wrong according to the man page as its says spaces or tabs
for separators. But its been that way since the last install in July
2015.
No problems that have made me question the net config in the last 27
months.
Next, back in the garage, where a raspberry pi 3b is currently running a
much bigger Sheldon lathe. Its running jessie. And says:
search hosts,dns
nameserver 192.168.71.1
Note comma, which the man page says is wrong. But it, like the other 4,
works.
And finally from the stretch install on a rock64 that I hope can replace
the pi:
rock64@rock64Sheldon:/usr/share/man$ cat /etc/resolv.conf
## screw dhcpd, can't find its ass with both hands!
domain coyote.den
nameserver 192.168.71.1
search hosts nameserver
But the network stuff there is doofy, I have to specify the gateway
twice to actually get it into the route -n output.
cat /etc/network/interfaces.d/eth0
auto eth0
iface eth0 inet static
address 192.168.71.2/24
gateway 192.168.71.1
up route add default gw 192.168.71.1
If I remove either of the last 2 lines, no gateway. And I haven't a clue.
So theres at least 3 variations on this theme, all of which work.
And I found I can't run a calculator and parted at the same time. So when
I told mkswap to make swap on the 2nd partition on a terabyte drive,
which I thought I'd set to 2GB, twice its memory, when I got around to
doing a mkswap, and adding it to /etc/fstab, then doing a swapon -a,
imagine my surprise to see htop telling me I had 7532MB of swap. But it
has drive to throw away anyway. Shrug. :)
And the stretch man page is the same as wheezy's ANAICT. The final
paragraph:
The domain and search keywords are mutually exclusive. If more than one
instance of these keywords is present, the last instance wins.
The search keyword of a system's resolv.conf file can be
overridden on a per-process basis by setting the environment variable
LOCALDOMAIN to a space-separated list
of search domains.
The options keyword of a system's resolv.conf file can be
amended on a per-process basis by setting the environment variable
RES_OPTIONS to a space-separated list
of resolver options as explained above under options.
The keyword and value must appear on a single line, and the
keyword (e.g., nameserver) must start the line. The value follows the
keyword, separated by white space
So obviously theres more than one ironclad rule as to how to skin this
cat, and the final question is: Does it work? Yes.
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)
Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2017-09-27 00:50 +0200 |
| Message-ID | <uu6PT-2mP-3@gated-at.bofh.it> |
| In reply to | #187274 |
On Tue 26 Sep 2017 at 14:59:41 (-0400), Greg Wooledge wrote: > On Tue, Sep 26, 2017 at 01:42:39PM -0500, David Wright wrote: > > On this topic, I still can't understand the contents of your > > immutable /etc/resolv.conf file, even without the comma: > > > > nameserver 192.168.XX.1 > > search host dns > > domain coyote.den > > > > Can you detail these domains called host and dns? > > I keep thinking that it's some relic from libc4 or libc5, before the > adoption of nsswitch.conf, but I am at a loss how to find documentation > that old to prove or disprove my guess. > > The nearest I could find is <http://www.tldp.org/LDP/nag/node82.html> > which describes an /etc/host.conf file that contains "order bind hosts". > I can't tell whether Gene's setup is an erroneous take on this obsolete > configuration file (somehow merging it into resolv.conf), or something > else entirely. Perhaps something even older, or something from a > non-Linux system. Oh yes, I think you're right. It even explains the comma that Gene had in the file until this month. I see that my own ancient host.conf still had order hosts,bind in it in 2000. The example with <space> in your reference seems to be unusual. Judging by my ancient email logs (Subject: lines only), there was a flurry around July 1998 which was about when libc6 started (hamm). Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-09-26 21:30 +0200 |
| Message-ID | <uu3Il-pY-7@gated-at.bofh.it> |
| In reply to | #187270 |
On Tuesday 26 September 2017 14:42:39 David Wright wrote:
> On Mon 25 Sep 2017 at 18:41:33 (-0400), Gene Heskett wrote:
> > On Monday 25 September 2017 13:53:17 Greg Wooledge wrote:
> > > On Mon, Sep 25, 2017 at 07:32:05PM +0200, Pascal Hambourg wrote:
> > > > Le 25/09/2017 à 17:33, Gene Heskett a écrit :
> > > > > For me, its a root session, and a "chattr +i resolv.conf"
> > > >
> > > > Here we have a saying that roughly translates to :
> > > > "When you have a hammer, any problem looks like a nail."
> > >
> > > No. Seriously, just stop.
> > >
> > > Those of us who have done chattr +i on one or more systems have,
> > > in many cases, TRIED OTHER SOLUTIONS first and found them wanting.
> > >
> > > Take me for example.
> > >
> > > At work, I edited /etc/dhcp/dhclient.conf and removed the options
> > > that tell dhclient to ask for domain-name-servers (et al.). This
> > > works fine for me at work. The DHCP servers at work respect my
> > > wish not to be given a domain-name-server, so dhclient never
> > > touches resolv.conf and everyone is happy.
> > >
> > > Then I tried the same thing at home.
> > >
> > > The results were NOT the same.
> > >
> > > The Belkin plastic router at home sends me a domain-name-server
> > > even if I do not ask for one. And dhclient apparently overwrites
> > > resolv.conf every time it receives a domain-name-server from the
> > > DHCP server.
> > >
> > > EVEN IF IT DID NOT REQUEST ONE.
> > >
> > > So, the solution that I used at work does not work at home.
> > >
> > > You know what DOES work, though?
> > >
> > > chattr +i works.
> > >
> > > Do I prefer this solution? No.
> > >
> > > Would I be happier if I could use a more elegant solution? Yes.
> > >
> > > Should the dhclient program have a CONFIG FILE OPTION to say
> > > "NEVER TOUCH THE resolv.conf FILE"? YES!
> > >
> > > Does it? NO!
> > >
> > > Do I expect it ever to have one in the future? BWA-hahahaha! No.
> > >
> > > So we use what works, because the other choices don't fucking
> > > work.
> > >
> > > This is not about lack of creativity.
> > >
> > > It is not about being too blind or ignorant or stubborn to use the
> > > other solutions. ("Everything looks like a nail.")
> > >
> > > This is about the other soluttions NOT WORKING.
> > >
> > > It is about ISC being too blind or ignorant or stubborn to
> > > consider that many people run the DHCP client software WITHOUT
> > > being the ones in charge of the DHCP server on the same network.
> > >
> > > Or, not considering that many people use cheap plastic
> > > consumer-grade routers that don't behave the same way the ISC DHCP
> > > server behaves.
> > >
> > > Am I getting through yet?
> >
> > I am with Greg on this one. And I HAVE tried everything the man
> > pages tell me, and it does NOT work, so I do what DOES WORK.
> > Someday, maybe dhcpd will be smart enough to actually do what we
> > tell it to do.
> >
> > But that day hasn't even shown a cloud of dust on the time horizon I
> > can see from a 83 yo in <2 weeks viewpoint.
> >
> > Because all you so-called experts THINK it works ok the way it is,
> > we get badmouthed and called idiots. Bad dog, no biscuit, not even
> > the smell of one in an all static network situation.
>
> Well sometimes I wonder if we're using different tools, so I always
> treat your fixes with a great deal of salt. For example, I could
> bypass the partitioner in the Debian-installer, I couldn't make
> aptitude destroy my system by removing lots of packages without
> explicitly being told to, and I couldn't make # passwd demand
> the old password, to name a few examples.
>
> On this topic, I still can't understand the contents of your
> immutable /etc/resolv.conf file, even without the comma:
>
> nameserver 192.168.XX.1
> search host dns
"host" is a typu, s/b "hosts", which means it checks the /etc/hosts file
for the name you typed, and if not found there it queries the local dns
server at nameserver's address, which if its not in dd-wrt's name cache,
gets forwarded to my isp's dns servers. Takes about an extra 50ms to
resolve a name its not heard of in recent history. And 100% transparent
to me.
the dns is a synonym for nameserver, I have /etc/resolv.conf's using
both, and while the man page says a "space separated" list of sources, I
ran in my stupidity, resolv.conf's that had comma separated lists. Work
just fine for over 20 years. Keywords "search" and "order" seem also to
be interchangeable, and either is handled in the order given.
> domain coyote.den
This I think is a leftover from when it was the place to put your
domainname, but now we've had the domainname utility to set that for
what, a decade?, and I could probably remove that line. Belt and
suspenders I guess. :)
> Can you detail these domains called host and dns?
See inline above.
> Cheers,
> David.
Cheers David, 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)
Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2017-09-26 21:50 +0200 |
| Message-ID | <uu41J-zi-47@gated-at.bofh.it> |
| In reply to | #187276 |
On Tue, Sep 26, 2017 at 03:19:51PM -0400, Gene Heskett wrote: > > domain coyote.den > > This I think is a leftover from when it was the place to put your > domainname, but now we've had the domainname utility to set that for > what, a decade?, and I could probably remove that line. Belt and > suspenders I guess. :) The domainname(1) command is for NIS, not DNS. The "domain" directive in resolv.conf is deprecated (maybe?) in favor of the "search" list, but the latter is a list of domain names, not places to consult. (If "domain" is given and "search" is not, then "search" uses the name that is in "domain" as its only entry.) The list of places to consult for name resolution is in /etc/nsswitch.conf in recent releases, and was in /etc/host.conf a very long time ago.
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | linux.debian.user
csiph-web