Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #201736 > unrolled thread
| Started by | Pierre Frenkiel <pierre.frenkiel@gmail.com> |
|---|---|
| First post | 2018-10-27 10:30 +0200 |
| Last post | 2018-10-27 14:50 +0200 |
| Articles | 20 on this page of 73 — 17 participants |
Back to article view | Back to linux.debian.user
i386 version for chrome Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2018-10-27 10:30 +0200
Re: i386 version for chrome Andrew Wood <andrewjameswood@ymail.com> - 2018-10-27 10:40 +0200
Re: i386 version for chrome Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2018-10-27 12:40 +0200
Re: i386 version for chrome Roberto C. Sánchez <roberto@debian.org> - 2018-10-27 13:10 +0200
Re: i386 version for chrome Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2018-10-27 13:30 +0200
Re: i386 version for chrome Curt <curty@free.fr> - 2018-10-27 14:10 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-27 15:10 +0200
Re: i386 version for chrome Curt <curty@free.fr> - 2018-10-27 16:10 +0200
Re: i386 version for chrome Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2018-10-27 17:00 +0200
Re: i386 version for chrome Curt <curty@free.fr> - 2018-10-27 18:00 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-27 17:00 +0200
Re: i386 version for chrome Steve McIntyre <steve@einval.com> - 2018-10-27 17:20 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-27 19:20 +0200
Re: i386 version for chrome Steve McIntyre <steve@einval.com> - 2018-10-27 20:30 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-27 23:30 +0200
Re: i386 version for chrome Brian <ad44@cityscape.co.uk> - 2018-10-28 00:50 +0200
Re: i386 version for chrome David <bouncingcats@gmail.com> - 2018-10-28 00:30 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 01:00 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 01:00 +0200
Re: i386 version for chrome David <bouncingcats@gmail.com> - 2018-10-28 23:00 +0100
Re: i386 version for chrome Curt <curty@free.fr> - 2018-10-28 10:10 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 12:00 +0100
Re: i386 version for chrome Curt <curty@free.fr> - 2018-10-29 12:00 +0100
resolv.conf (was i386 version for chrome) Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2018-10-28 13:00 +0100
Re: resolv.conf (was i386 version for chrome) Reco <recoverym4n@enotuniq.net> - 2018-10-28 13:50 +0100
Re: resolv.conf (was i386 version for chrome) Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2018-10-28 14:20 +0100
Re: resolv.conf (was i386 version for chrome) Reco <recoverym4n@enotuniq.net> - 2018-10-28 14:20 +0100
Re: resolv.conf (was i386 version for chrome) Reco <recoverym4n@enotuniq.net> - 2018-10-28 14:50 +0100
Re: resolv.conf (was i386 version for chrome) Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2018-10-28 16:40 +0100
Re: i386 version for chrome Steve McIntyre <steve@einval.com> - 2018-10-28 01:00 +0200
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-28 16:00 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 17:20 +0100
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-29 11:30 +0100
Re: i386 version for chrome Reco <recoverym4n@enotuniq.net> - 2018-10-27 20:40 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-27 23:40 +0200
Re: i386 version for chrome Reco <recoverym4n@enotuniq.net> - 2018-10-28 08:00 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 11:10 +0100
Re: i386 version for chrome Reco <recoverym4n@enotuniq.net> - 2018-10-28 11:40 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 12:10 +0100
Re: i386 version for chrome Reco <recoverym4n@enotuniq.net> - 2018-10-28 13:50 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 17:10 +0100
Re: i386 version for chrome Reco <recoverym4n@enotuniq.net> - 2018-10-28 17:30 +0100
Re: i386 version for chrome The Wanderer <wanderer@fastmail.fm> - 2018-10-28 18:00 +0100
Re: i386 version for chrome john doe <johndoe65534@mail.com> - 2018-10-28 18:10 +0100
Re: i386 version for chrome Reco <recoverym4n@enotuniq.net> - 2018-10-28 18:20 +0100
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-29 12:20 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-29 13:30 +0100
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-29 13:40 +0100
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-29 14:00 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-29 15:50 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-29 15:50 +0100
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-29 16:10 +0100
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-29 21:20 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-29 21:20 +0100
Re: i386 version for chrome John Hasler <jhasler@newsguy.com> - 2018-10-29 21:30 +0100
Re: i386 version for chrome Brian <ad44@cityscape.co.uk> - 2018-10-29 21:40 +0100
Re: i386 version for chrome Brian <ad44@cityscape.co.uk> - 2018-10-29 21:50 +0100
Re: i386 version for chrome Brian <ad44@cityscape.co.uk> - 2018-10-28 20:00 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 20:10 +0100
Re: i386 version for chrome Brian <ad44@cityscape.co.uk> - 2018-10-28 20:30 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-29 00:40 +0100
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-29 12:20 +0100
Re: i386 version for chrome Thomas D Dial <tdial@acm.org> - 2018-10-28 04:10 +0100
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-28 15:50 +0100
Re: i386 version for chrome Matthew Crews <mailinglists@mattcrews.com> - 2018-10-27 17:10 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-27 17:40 +0200
Re: i386 version for chrome Matthew Crews <mailinglists@mattcrews.com> - 2018-10-27 22:00 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 00:10 +0200
Re: i386 version for chrome David Wright <deblis@lionunicorn.co.uk> - 2018-11-03 04:10 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-11-03 04:40 +0100
Re: i386 version for chrome tony <lists@vanderhoff.org> - 2018-10-27 15:10 +0200
Re: i386 version for chrome Matthew Crews <mailinglists@mattcrews.com> - 2018-10-27 13:50 +0200
Re: i386 version for chrome Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2018-10-27 14:50 +0200
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2018-10-28 10:10 +0100 |
| Message-ID | <wNPf4-40u-19@gated-at.bofh.it> |
| In reply to | #201769 |
On 2018-10-27, Gene Heskett <gheskett@shentel.net> wrote: >> >> Gene, the line >> >> > >dns-search hosts dns >> >> that you show above does not match anything documented by >> the manpages on wheezy. I checked >> interfaces(5) >> resolv.conf(5) >> resolvconf(8) >> nsswitch.conf(5) >> >> Gene, what are you trying to achieve with that line? > > Whatever it takes to get a working gateway at bootup. Next time I reboot, > I'll kill that line first. If I can't ping yahoo.com, (= no gateway. so > it cannot get to the internet) I'll put it back. > It seems 'dns-search' is fairly well-known but undocumented, the flags (if that's the term) 'hosts' and 'dns' seem weird, though (and exclusive to your config). I'm reading: dns-search determines which domain is appended for dns lookups. Normally you will specify here the same domain as returned by hostname -f.* The dns-search entry would create a corresponding entry in /etc/resolv.conf (if you have resolvconf installed--or something, too complicated for my pea-brain). Maybe you know all this already. *(As per man 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.) So it seems your config would create the following entries in /etc/resolv.conf nameserver 192.168.NN.1 search hosts dns Anyway, hope I haven't added to the confusion rather than the contrary. -- "Now she understood that Anna could not have been in lilac, and that her charm was just that she always stood out against her attire, that her dress could never be noticeable on her." Leo Tolstoy, Anna Karenina
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2018-10-28 12:00 +0100 |
| Message-ID | <wNQXw-4Q6-13@gated-at.bofh.it> |
| In reply to | #201774 |
On Sunday 28 October 2018 04:53:10 Curt wrote: > On 2018-10-27, Gene Heskett <gheskett@shentel.net> wrote: > >> Gene, the line > >> > >> > >dns-search hosts dns > >> > >> that you show above does not match anything documented by > >> the manpages on wheezy. I checked > >> interfaces(5) > >> resolv.conf(5) > >> resolvconf(8) > >> nsswitch.conf(5) > >> > >> Gene, what are you trying to achieve with that line? > > > > Whatever it takes to get a working gateway at bootup. Next time I > > reboot, I'll kill that line first. If I can't ping yahoo.com, (= no > > gateway. so it cannot get to the internet) I'll put it back. > > It seems 'dns-search' is fairly well-known but undocumented, the flags > (if that's the term) 'hosts' and 'dns' seem weird, though (and > exclusive to your config). > > I'm reading: > > dns-search determines which domain is appended for dns lookups. > Normally you will specify here the same domain as returned by > hostname -f.* Which is itself and patently wrong for this since the local dns query path is supposed to be the hosts file first, and failing that ask dnsmasq in the router, failing finding it in the dnsmasq cache, it gets forwarded to the dns server at my ISP. And I've had it setup that way since red hat 5.1 in 1998. 20 years of linux, and another 10 before that with AmigaDos. > The dns-search entry would create a corresponding entry in > /etc/resolv.conf (if you have resolvconf installed--or something, too > complicated for my pea-brain). Mine too. And resolvconf is installed by the installer, so the best you can do is blow away that link and make resolv.conf a real file with a list of nameservers topped by the search order which starts with the hosts file, followed by either dns or nameserver which are, or were, interchangeable in effect. > Maybe you know all this already. The above is what I've understood since my first successful linux install. If its been changed then fix the man pages to reflect todays practice. The pages for ip are incomprehensible gibberish. > *(As per man 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.) > > So it seems your config would create the following entries in > /etc/resolv.conf > > nameserver 192.168.NN.1 > search hosts dns > > Anyway, hope I haven't added to the confusion rather than the > contrary. No. you are confirming what I've been doing for 20 years, but not until jessie was I ever forced to put stuff that belongs in /e/resolv.conf, into that AND the /e/n/i/eth0 to make jessie work. The armbian stretch install is what gave me a working gateway. Nobody elses amd64/arm64 install based on stretch has worked. I'll try it on an SSD in an old dell dimension next after dl-ing the latest iso, but right now a $2.30 buck regulator in the BoB box driving my big mill has died a horrible death, spitting epoxy off the top of the chip, and probably toasted the BoB by applying 7x its normal vcc voltage to it while the chip was exploding 200 milliseconds after power up on my biggest milling machine. So I expect I'd better get 2 of them ordered from ebay today. I also bought 10 of that regulator just so I'll have spares. Out here in the wilds of West (by God) Virginia, I'm often nearly 30 days acquiring service parts so when I design something, I am learning to buy spares, or draw it up and make it on a milling machine or lathe, generally writing my own gcode to make the pcb's. That I can do, but make stretch assign a gateway? Taint happened yet except for armbian on an arm64. -- 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 | Curt <curty@free.fr> |
|---|---|
| Date | 2018-10-29 12:00 +0100 |
| Message-ID | <wOdr4-1iW-5@gated-at.bofh.it> |
| In reply to | #201781 |
On 2018-10-28, Gene Heskett <gheskett@shentel.net> wrote:
>>
>> I'm reading:
>>
>> dns-search determines which domain is appended for dns lookups.
>> Normally you will specify here the same domain as returned by
>> hostname -f.*
>
> Which is itself and patently wrong for this since the local dns query
> path is supposed to be the hosts file first, and failing that ask
> dnsmasq in the router, failing finding it in the dnsmasq cache, it gets
> forwarded to the dns server at my ISP. And I've had it setup that way
> since red hat 5.1 in 1998. 20 years of linux, and another 10 before that
> with AmigaDos.
>
The only examples of the dns-search parameter I can find (besides yours)
are of the sort found in the resolv.conf wiki:
https://wiki.debian.org/resolv.conf
With resolvconf installed, you can tell it to do nothing whenever some daemon
tries to modify resolv.conf, by putting resolvconf=NO in the
/etc/resolvconf.conf file. (Note: this is not the /etc/resolv.conf file!)
Alternatively, you can use dns-nameserver entries in the appropriate stanza in
/etc/network/interfaces:
iface eth0 inet static
address 192.168.1.3
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameserver 192.168.1.254
dns-nameserver 8.8.8.8
dns-search foo.org bar.com
--
"Now she understood that Anna could not have been in lilac, and that her charm
was just that she always stood out against her attire, that her dress could
never be noticeable on her." Leo Tolstoy, Anna Karenina
[toc] | [prev] | [next] | [standalone]
| From | Pierre Frenkiel <pierre.frenkiel@gmail.com> |
|---|---|
| Date | 2018-10-28 13:00 +0100 |
| Subject | resolv.conf (was i386 version for chrome) |
| Message-ID | <wNRTz-5oE-1@gated-at.bofh.it> |
| In reply to | #201774 |
On Sun, 28 Oct 2018, Curt wrote:
> So it seems your config would create the following entries in /etc/resolv.conf
>
> nameserver 192.168.NN.1
> search hosts dns
>
hi,
I thought it was better to rename this thread, as the discussion shifted
a little.
I have a question about resolv.conf:
I tried to remove it, and the result was:
on my desktop PC, dns no more works
on my laptop, it still works (without any running avahi or network-manager)
any explanation?
best regards,
--
Pierre Frenkiel
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2018-10-28 13:50 +0100 |
| Subject | Re: resolv.conf (was i386 version for chrome) |
| Message-ID | <wNSFX-5U3-9@gated-at.bofh.it> |
| In reply to | #201783 |
Hi. On Sun, Oct 28, 2018 at 12:53:11PM +0100, Pierre Frenkiel wrote: > On Sun, 28 Oct 2018, Curt wrote: > > > So it seems your config would create the following entries in /etc/resolv.conf > > > > nameserver 192.168.NN.1 > > search hosts dns > > > > hi, > I thought it was better to rename this thread, as the discussion shifted > a little. > I have a question about resolv.conf: > I tried to remove it, and the result was: > on my desktop PC, dns no more works > on my laptop, it still works (without any running avahi or network-manager) > > any explanation? strace getent hosts bad.solutions If you're interested in lowly implementation details the answer will be in there. Requires installing strace for obvious reasons. Reco
[toc] | [prev] | [next] | [standalone]
| From | Pierre Frenkiel <pierre.frenkiel@gmail.com> |
|---|---|
| Date | 2018-10-28 14:20 +0100 |
| Subject | Re: resolv.conf (was i386 version for chrome) |
| Message-ID | <wNT8Z-6iC-3@gated-at.bofh.it> |
| In reply to | #201788 |
On Sun, 28 Oct 2018, Reco wrote: > strace getent hosts bad.solutions thanks for your answer, but the output is rather obscure for a non-guru user, except a lot of "no such file or directory" In particular, I don't see how to explain the difference of behaviour on my 2 computers. best regards, -- Pierre Frenkiel
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2018-10-28 14:20 +0100 |
| Subject | Re: resolv.conf (was i386 version for chrome) |
| Message-ID | <wNT8Z-6iC-1@gated-at.bofh.it> |
| In reply to | #201790 |
Hi. On Sun, Oct 28, 2018 at 02:13:30PM +0100, Pierre Frenkiel wrote: > On Sun, 28 Oct 2018, Reco wrote: > > > strace getent hosts bad.solutions > > thanks for your answer, but the output is rather obscure for a non-guru user, > except a lot of "no such file or directory" > In particular, I don't see how to explain the difference of behaviour on > my 2 computers. Not pretending to be a guru, but can you post the results somewhere? Reco
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2018-10-28 14:50 +0100 |
| Subject | Re: resolv.conf (was i386 version for chrome) |
| Message-ID | <wNTC2-6se-5@gated-at.bofh.it> |
| In reply to | #201791 |
Hi.
On Sun, Oct 28, 2018 at 04:17:17PM +0300, Reco wrote:
> Hi.
>
> On Sun, Oct 28, 2018 at 02:13:30PM +0100, Pierre Frenkiel wrote:
> > On Sun, 28 Oct 2018, Reco wrote:
> >
> > > strace getent hosts bad.solutions
> >
> > thanks for your answer, but the output is rather obscure for a non-guru user,
> > except a lot of "no such file or directory"
> > In particular, I don't see how to explain the difference of behaviour on
> > my 2 computers.
>
> Not pretending to be a guru, but can you post the results somewhere?
I don't repost those two strace outputs, archives will be better without
them.
The result is somewhat unexpected (to me at least):
Judging from multiple:
stat("/etc/resolv.conf", 0x7ffbffffae40) = -1 ENOENT
The host's resolver is configured for conventional DNS resolution.
/etc/resolv.conf is not present, so resolver tries to find DNS at
127.0.0.1 udp:53:
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
Which it does (zero return code), and sends DNS query there:
sendto(3, "\307N\1\0\0\1\0\0\0\0\0\0\3bad\tsolutions\0\0\34\0\1", 31, MSG_NOSIGNAL, NULL, 0) = 31
And something that's listening udp:53 on your laptop replies:
recvfrom(3, "\307N\201\200\0\1\0\0\0\1\0\0\3bad\tsolutions\0\0\34\0\1\300"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, [28->16]) = 91
The fact that libc's resolver have a hardcoded fallback to localhost in
the absense of resolv.conf was not known to me until now, but it's
documented at resolv.conf(5):
If this file does not exist, only the name server on the local
machine will be queried
So, answering your original question, you have working name resolution
because you have a caching nameserver on your laptop. My money's on
dnsmasq.
Reco
[toc] | [prev] | [next] | [standalone]
| From | Pierre Frenkiel <pierre.frenkiel@gmail.com> |
|---|---|
| Date | 2018-10-28 16:40 +0100 |
| Subject | Re: resolv.conf (was i386 version for chrome) |
| Message-ID | <wNVku-7xv-23@gated-at.bofh.it> |
| In reply to | #201792 |
On Sun, 28 Oct 2018, Reco wrote: > So, answering your original question, you have working name resolution > because you have a caching nameserver on your laptop. My money's on > dnsmasq. you are right: I had bind installed on my laptop, but on my desktop the bind9 package was missing. After installing it and running named it works. Thanks a lot for your help. best regards, -- Pierre Frenkiel
[toc] | [prev] | [next] | [standalone]
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2018-10-28 01:00 +0200 |
| Message-ID | <wNFIK-6wG-15@gated-at.bofh.it> |
| In reply to | #201767 |
David wrote: >On Sun, 28 Oct 2018 at 05:21, Steve McIntyre <steve@einval.com> wrote: > >There seems to be an ongoing theme here with lines that look like > *search hosts dns >popping up in other places in Gene's system. > >See: >https://lists.debian.org/debian-user/2017/10/msg00857.html >https://lists.debian.org/debian-user/2017/10/msg00859.html > >Gene, the line >> >dns-search hosts dns >that you show above does not match anything documented by >the manpages on wheezy. I checked > interfaces(5) > resolv.conf(5) > resolvconf(8) > nsswitch.conf(5) > >Gene, what are you trying to achieve with that line? It *looks* like a misunderstood reference to nsswitch.conf maybe: hosts: files dns (from my system). -- Steve McIntyre, Cambridge, UK. steve@einval.com "Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast." Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2018-10-28 16:00 +0100 |
| Message-ID | <wNUHM-750-19@gated-at.bofh.it> |
| In reply to | #201770 |
On Sat, Oct 27, 2018 at 10:58:49PM +0000, Steve McIntyre wrote: >It *looks* like a misunderstood reference to nsswitch.conf maybe: > >hosts: files dns We've been through this before, explained it thoroughly, he never listens, then he brings it back again and the cycle repeats. It's impossible to debug his setup because he ignores the advice and clings to stuff that doesn't make any sense and can't possibly work.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2018-10-28 17:20 +0100 |
| Message-ID | <wNVXb-80h-1@gated-at.bofh.it> |
| In reply to | #201798 |
On Sunday 28 October 2018 10:51:50 Michael Stone wrote: > On Sat, Oct 27, 2018 at 10:58:49PM +0000, Steve McIntyre wrote: > >It *looks* like a misunderstood reference to nsswitch.conf maybe: > > > >hosts: files dns > > We've been through this before, explained it thoroughly, he never > listens, then he brings it back again and the cycle repeats. It's > impossible to debug his setup because he ignores the advice and clings > to stuff that doesn't make any sense and can't possibly work. Except its worked for 20 years, why doesn't it work now? And if its been changed, why is that change not noted in the man pages? 2 good questions. If the best you can do is take pot shots at me for asking why, its best dropped as I've found an install that works on arm64 in armbian. -- 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 | 2018-10-29 11:30 +0100 |
| Message-ID | <wOcY1-19G-5@gated-at.bofh.it> |
| In reply to | #201803 |
On Sun, Oct 28, 2018 at 12:18:42PM -0400, Gene Heskett wrote: >On Sunday 28 October 2018 10:51:50 Michael Stone wrote: > >> On Sat, Oct 27, 2018 at 10:58:49PM +0000, Steve McIntyre wrote: >> >It *looks* like a misunderstood reference to nsswitch.conf maybe: >> > >> >hosts: files dns >> >> We've been through this before, explained it thoroughly, he never >> listens, then he brings it back again and the cycle repeats. It's >> impossible to debug his setup because he ignores the advice and clings >> to stuff that doesn't make any sense and can't possibly work. > >Except its worked for 20 years, why doesn't it work now? And if its been >changed, why is that change not noted in the man pages? As has been explained to you over and over, it never worked. In no version of debian did it ever do anything like what you seem to think it did. But, I'm sure you'll ignore this time also. >2 good questions. I disagree.
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2018-10-27 20:40 +0200 |
| Message-ID | <wNBF7-49l-1@gated-at.bofh.it> |
| In reply to | #201756 |
Hi. On Sat, Oct 27, 2018 at 01:13:07PM -0400, Gene Heskett wrote: > Then give me an install that can be made to work in a hosts file defined > local network that can accept a gateway statement in its e/n/i file. The > default install does NOT accept it until the network has been brought > up. In another news, you cannot have a default gateway unless it's reachable according to existing routing table. The reason is simple - a default gateway is not 'global', the kernel must decide with interface to attach to a default gateway route. So you bring a network interface up, add an address to it and only then configure a default gateway. And that's not specific to a Linux, it works that way in any OS I've seen so far. Reco
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2018-10-27 23:40 +0200 |
| Message-ID | <wNEtk-5Qx-15@gated-at.bofh.it> |
| In reply to | #201760 |
On Saturday 27 October 2018 14:37:38 Reco wrote: > Hi. > > On Sat, Oct 27, 2018 at 01:13:07PM -0400, Gene Heskett wrote: > > Then give me an install that can be made to work in a hosts file > > defined local network that can accept a gateway statement in its > > e/n/i file. The default install does NOT accept it until the network > > has been brought up. > > In another news, you cannot have a default gateway unless it's > reachable according to existing routing table. Its reachable, and listed in every hosts file here by both name and address. > The reason is simple - a default gateway is not 'global', the kernel > must decide with interface to attach to a default gateway route. > So you bring a network interface up, add an address to it and only > then configure a default gateway. Then how does one guarantee its done in that order? And what was changed to prevent its working in the newer way of doing things? > And that's not specific to a Linux, it works that way in any OS I've > seen so far. Windows, since xp anyway, must have an internal sequence for that as I have yet to have any trouble setting up a gateway assignment in any of the neighbors windows boxen. Thats not even a major reason I don't allow a windows install on the property any longer than it takes to fix up their fumble fingers attempts to make it connect to their cable or dsl modem. > Reco Thanks Reco. -- 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 | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2018-10-28 08:00 +0100 |
| Message-ID | <wNNdf-2Cx-3@gated-at.bofh.it> |
| In reply to | #201765 |
Hi. On Sat, Oct 27, 2018 at 05:35:49PM -0400, Gene Heskett wrote: > On Saturday 27 October 2018 14:37:38 Reco wrote: > > > Hi. > > > > On Sat, Oct 27, 2018 at 01:13:07PM -0400, Gene Heskett wrote: > > > Then give me an install that can be made to work in a hosts file > > > defined local network that can accept a gateway statement in its > > > e/n/i file. The default install does NOT accept it until the network > > > has been brought up. > > > > In another news, you cannot have a default gateway unless it's > > reachable according to existing routing table. > > Its reachable, and listed in every hosts file here by both name and > address. Not before you bring up any non-local network interface. > > The reason is simple - a default gateway is not 'global', the kernel > > must decide with interface to attach to a default gateway route. > > So you bring a network interface up, add an address to it and only > > then configure a default gateway. > > Then how does one guarantee its done in that order? By using ifupdown, for instance. > And what was changed > to prevent its working in the newer way of doing things? ifupdown works for me that way since etch was testing. If it does not - there's always troubleshooting in form of 'ifup -v'. Reco
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2018-10-28 11:10 +0100 |
| Message-ID | <wNQb8-4Ah-9@gated-at.bofh.it> |
| In reply to | #201773 |
On Sunday 28 October 2018 02:55:09 Reco wrote: > Hi. > > On Sat, Oct 27, 2018 at 05:35:49PM -0400, Gene Heskett wrote: > > On Saturday 27 October 2018 14:37:38 Reco wrote: > > > Hi. > > > > > > On Sat, Oct 27, 2018 at 01:13:07PM -0400, Gene Heskett wrote: > > > > Then give me an install that can be made to work in a hosts file > > > > defined local network that can accept a gateway statement in its > > > > e/n/i file. The default install does NOT accept it until the > > > > network has been brought up. > > > > > > In another news, you cannot have a default gateway unless it's > > > reachable according to existing routing table. > > That is the problem, a route -n is without a gateway assignment and has been missing since my first attempt to install stretch. > > Its reachable, and listed in every hosts file here by both name and > > address. > > Not before you bring up any non-local network interface. Then why, after giving the installer all that info, and it uses that during the install, does it not have a gateway set after the initial reboot or any subsequent reboot? And nothing you can do will give it a gateway, so you wind up playing 10,000 monkeys writing Shakespear, and a reboot for every session of nano trying to find the magic twanger that makes it work? I have made jessie work on an armhf but its been done after the initial reboot. An armbian install that claims its debian 9, is the only install out of 5 or 6 from various sources including the debian-arm iso twice. For the jessie install on an r-pi-3b, this /e/n/i works: auto lo # The loopback network interface iface lo inet loopback address 127.0.0.1 netmask 255.255.255.0 auto eth0 # regular network for coyote.den iface eth0 inet static address 192.168.NN.12 netmask 255.255.255.0 gateway 192.168.NN.1 but it doesn't work if the interface address is given in address/24 format so the netmask isn't needed. To me, thats all the evidence needed to point the guilty finger at something in the ifup code. > > > > The reason is simple - a default gateway is not 'global', the > > > kernel must decide with interface to attach to a default gateway > > > route. So you bring a network interface up, add an address to it > > > and only then configure a default gateway. > > > > Then how does one guarantee its done in that order? > > By using ifupdown, for instance. > > > And what was changed > > to prevent its working in the newer way of doing things? > > ifupdown works for me that way since etch was testing. > If it does not - there's always troubleshooting in form of 'ifup -v'. As in "ifup -vvv eth0"? What log file, on stretch, would I find that trace data in? Theres not anything in /v/l/syslog w/o the -v. And theres nothing more frustrating than a silent failure like this has been so far. > Reco -- 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 | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2018-10-28 11:40 +0100 |
| Message-ID | <wNQEa-4Jp-5@gated-at.bofh.it> |
| In reply to | #201778 |
Hi. On Sun, Oct 28, 2018 at 05:59:52AM -0400, Gene Heskett wrote: > On Sunday 28 October 2018 02:55:09 Reco wrote: > > > Hi. > > > > On Sat, Oct 27, 2018 at 05:35:49PM -0400, Gene Heskett wrote: > > > On Saturday 27 October 2018 14:37:38 Reco wrote: > > > > Hi. > > > > > > > > On Sat, Oct 27, 2018 at 01:13:07PM -0400, Gene Heskett wrote: > > > > > Then give me an install that can be made to work in a hosts file > > > > > defined local network that can accept a gateway statement in its > > > > > e/n/i file. The default install does NOT accept it until the > > > > > network has been brought up. > > > > > > > > In another news, you cannot have a default gateway unless it's > > > > reachable according to existing routing table. > > > > That is the problem, a route -n is without a gateway assignment and has > been missing since my first attempt to install stretch. Ok. > > > Its reachable, and listed in every hosts file here by both name and > > > address. > > > > Not before you bring up any non-local network interface. > > Then why, after giving the installer all that info, and it uses that > during the install, does it not have a gateway set after the initial > reboot or any subsequent reboot? Works for me every time I tried it, so I cannot answer that. > And nothing you can do will give it a gateway, so you wind up playing > 10,000 monkeys writing Shakespear, and a reboot for every session of > nano trying to find the magic twanger that makes it work? I have made > jessie work on an armhf but its been done after the initial reboot. An > armbian install that claims its debian 9, is the only install out of 5 > or 6 from various sources including the debian-arm iso twice. > > For the jessie install on an r-pi-3b, this /e/n/i works: > > auto lo > > # The loopback network interface > iface lo inet loopback > address 127.0.0.1 > netmask 255.255.255.0 > > auto eth0 > > # regular network for coyote.den > iface eth0 inet static > address 192.168.NN.12 > netmask 255.255.255.0 > gateway 192.168.NN.1 > > but it doesn't work if the interface address is given in address/24 > format so the netmask isn't needed. Ever consider you're doing it the wrong way? This will work: iface eth0 inet static address 192.168.NN.12 netmask 24 gateway 192.168.NN.1 > To me, thats all the evidence needed > to point the guilty finger at something in the ifup code. Accusing software of something may ease one's mind, but it won't make it work. Usually, that is. > > > > The reason is simple - a default gateway is not 'global', the > > > > kernel must decide with interface to attach to a default gateway > > > > route. So you bring a network interface up, add an address to it > > > > and only then configure a default gateway. > > > > > > Then how does one guarantee its done in that order? > > > > By using ifupdown, for instance. > > > > > And what was changed > > > to prevent its working in the newer way of doing things? They have this wonderful principle at movie industry - show but do not tell. Please provide 'ifup -v' output that shows ifupdown misbehaviour, or it did not happen. > > ifupdown works for me that way since etch was testing. > > If it does not - there's always troubleshooting in form of 'ifup -v'. > > As in "ifup -vvv eth0"? -vvv is not documented, and I'm too lazy to dig into the source to see if it does something at all. ifdown eth0 ifup -v eth0 > What log file, on stretch, would I find that trace data in? Stdout/stderr, as documented by ifup(8). > Theres not anything in /v/l/syslog w/o the -v. And there should not be anything about ifupdown, unless someone redirects stdout/stderr of /etc/init.d/networking to syslog. Reco
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2018-10-28 12:10 +0100 |
| Message-ID | <wNR7c-58w-5@gated-at.bofh.it> |
| In reply to | #201779 |
On Sunday 28 October 2018 06:30:32 Reco wrote: > Hi. > > On Sun, Oct 28, 2018 at 05:59:52AM -0400, Gene Heskett wrote: > > On Sunday 28 October 2018 02:55:09 Reco wrote: > > > Hi. > > > > > > On Sat, Oct 27, 2018 at 05:35:49PM -0400, Gene Heskett wrote: > > > > On Saturday 27 October 2018 14:37:38 Reco wrote: > > > > > Hi. > > > > > > > > > > On Sat, Oct 27, 2018 at 01:13:07PM -0400, Gene Heskett wrote: > > > > > > Then give me an install that can be made to work in a hosts > > > > > > file defined local network that can accept a gateway > > > > > > statement in its e/n/i file. The default install does NOT > > > > > > accept it until the network has been brought up. > > > > > > > > > > In another news, you cannot have a default gateway unless it's > > > > > reachable according to existing routing table. > > > > That is the problem, a route -n is without a gateway assignment and > > has been missing since my first attempt to install stretch. > > Ok. > > > > > Its reachable, and listed in every hosts file here by both name > > > > and address. > > > > > > Not before you bring up any non-local network interface. > > > > Then why, after giving the installer all that info, and it uses that > > during the install, does it not have a gateway set after the initial > > reboot or any subsequent reboot? > > Works for me every time I tried it, so I cannot answer that. > > > And nothing you can do will give it a gateway, so you wind up > > playing 10,000 monkeys writing Shakespear, and a reboot for every > > session of nano trying to find the magic twanger that makes it work? > > I have made jessie work on an armhf but its been done after the > > initial reboot. An armbian install that claims its debian 9, is the > > only install out of 5 or 6 from various sources including the > > debian-arm iso twice. > > > > For the jessie install on an r-pi-3b, this /e/n/i works: > > > > auto lo > > > > # The loopback network interface > > iface lo inet loopback > > address 127.0.0.1 > > netmask 255.255.255.0 > > > > auto eth0 > > > > # regular network for coyote.den > > iface eth0 inet static > > address 192.168.NN.12 > > netmask 255.255.255.0 > > gateway 192.168.NN.1 > > > > but it doesn't work if the interface address is given in address/24 > > format so the netmask isn't needed. > > Ever consider you're doing it the wrong way? > This will work: > > iface eth0 inet static > address 192.168.NN.12 > netmask 24 > gateway 192.168.NN.1 > in 20 years, I have never seen that syntax used. What man page do I find that format in. > > To me, thats all the evidence needed > > to point the guilty finger at something in the ifup code. > > Accusing software of something may ease one's mind, but it won't make > it work. Usually, that is. > > > > > > The reason is simple - a default gateway is not 'global', the > > > > > kernel must decide with interface to attach to a default > > > > > gateway route. So you bring a network interface up, add an > > > > > address to it and only then configure a default gateway. > > > > > > > > Then how does one guarantee its done in that order? > > > > > > By using ifupdown, for instance. > > > > > > > And what was changed > > > > to prevent its working in the newer way of doing things? > > They have this wonderful principle at movie industry - show but do not > tell. > Please provide 'ifup -v' output that shows ifupdown misbehaviour, or > it did not happen. Now that I know theres a new syntax in town, I'll try it. When the next install fails. > > > ifupdown works for me that way since etch was testing. > > > If it does not - there's always troubleshooting in form of 'ifup > > > -v'. > > > > As in "ifup -vvv eth0"? > > -vvv is not documented, and I'm too lazy to dig into the source to see > if it does something at all. > > ifdown eth0 > ifup -v eth0 > > > What log file, on stretch, would I find that trace data in? > > Stdout/stderr, as documented by ifup(8). Too volatile, scrolled off screen by the remainder of the boot. I want a log file I can insert into an email. Then we'll all see whats happening. > > Theres not anything in /v/l/syslog w/o the -v. > > And there should not be anything about ifupdown, unless someone > redirects stdout/stderr of /etc/init.d/networking to syslog. Howto? > > Reco -- 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 | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2018-10-28 13:50 +0100 |
| Message-ID | <wNSFX-5U3-15@gated-at.bofh.it> |
| In reply to | #201782 |
Hi. On Sun, Oct 28, 2018 at 07:04:02AM -0400, Gene Heskett wrote: > > Ever consider you're doing it the wrong way? > > This will work: > > > > iface eth0 inet static > > address 192.168.NN.12 > > netmask 24 > > gateway 192.168.NN.1 > > > in 20 years, I have never seen that syntax used. What man page do I find > that format in. interfaces(5), the usual place. > > -vvv is not documented, and I'm too lazy to dig into the source to see > > if it does something at all. > > > > ifdown eth0 > > ifup -v eth0 > > > > > What log file, on stretch, would I find that trace data in? > > > > Stdout/stderr, as documented by ifup(8). > > Too volatile, scrolled off screen by the remainder of the boot. I want a > log file I can insert into an email. Then we'll all see whats happening. Er, Gene, -v is there for user invocations, not for init scripts. /etc/init.d/networking uses ordinary ifup, as nobody will want seeing all those gory implementation details at each boot. > > > Theres not anything in /v/l/syslog w/o the -v. > > > > And there should not be anything about ifupdown, unless someone > > redirects stdout/stderr of /etc/init.d/networking to syslog. > > Howto? Don't. Simply don't. It requires wrapping with '| logger' every ifup/ifdown at /etc/init.d/networking. Reco
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | linux.debian.user
csiph-web