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 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2017-09-25 16:30 +0200 |
| Message-ID | <utCyu-7ys-19@gated-at.bofh.it> |
| In reply to | #187181 |
Le 25/09/2017 à 15:54, Greg Wooledge a écrit : > On Mon, Sep 25, 2017 at 03:45:06PM +0200, Pascal Hambourg wrote: >> Prepare to be disappointed if you modify directly resolv.conf, because the >> software which wrote it first could rewrite it after you, as DHCP clients do >> each time they renew the lease. > > In a battle between me and stupid new software programs, I always win > in the end. I hope so. The user shall prevail. > I will do whatever it takes to make the software behave correctly, > even if what it takes is REMOVING the software. For sure. But there is the forcible way and the graceful way. Here is a little experience of mine. I had a host configured with DHCP. As expected, dhclient wrote the IPv4 DNS addresses received from the DHCP server into resolv.conf. My network also had an IPv6 router sending advertisements containing IPv6 DNS addresses and I wanted that addresses to be included in resolv.conf, so I installed rdnssd. Unfortunatly, both dhclient and rdnssd rewrote resolv.conf, erasing the addresses added by the other. Either DNS addresses worked, but it was not what I wanted. Then I installed resolvconf and resolv.conf now contained both IPv4 addresses from dhclient and IPv6 addresses from rdnssd.
[toc] | [prev] | [next] | [standalone]
| From | Gary Roach <gary719_list1@verizon.net> |
|---|---|
| Date | 2017-09-30 04:20 +0200 |
| Message-ID | <uvfxL-6jP-1@gated-at.bofh.it> |
| In reply to | #187182 |
On 09/25/2017 07:20 AM, Pascal Hambourg wrote: > Le 25/09/2017 à 15:54, Greg Wooledge a écrit : >> On Mon, Sep 25, 2017 at 03:45:06PM +0200, Pascal Hambourg wrote: >>> Prepare to be disappointed if you modify directly resolv.conf, >>> because the >>> software which wrote it first could rewrite it after you, as DHCP >>> clients do >>> each time they renew the lease. >> >> In a battle between me and stupid new software programs, I always win >> in the end. > > I hope so. The user shall prevail. > >> I will do whatever it takes to make the software behave correctly, >> even if what it takes is REMOVING the software. > > For sure. But there is the forcible way and the graceful way. > > Here is a little experience of mine. > I had a host configured with DHCP. As expected, dhclient wrote the IPv4 > DNS addresses received from the DHCP server into resolv.conf. My network > also had an IPv6 router sending advertisements containing IPv6 DNS > addresses and I wanted that addresses to be included in resolv.conf, so > I installed rdnssd. Unfortunatly, both dhclient and rdnssd rewrote > resolv.conf, erasing the addresses added by the other. Either DNS > addresses worked, but it was not what I wanted. Then I installed > resolvconf and resolv.conf now contained both IPv4 addresses from > dhclient and IPv6 addresses from rdnssd. > > Well the philosophy and stories are nice but my access to the internet is still among the missing. I have a Debian Stretch system installed and am using NetworkManager. This worked until I installed qemu virtual machine over the host OS. Since then the host system does not seem able to find a DNS server. The really strange thing is that I installed Kubuntu as the guest OS and that works fine. I suspect that qemu has glommed onto the eth0 device and won't let the host in. I have gone over and over the NetworkManager documentation and have found no way to fix this. The situation is getting critical. I need to load some software into the host system and can't, I also can't upgrade the system and can't. I really need some help here. Gary R
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2017-09-30 08:50 +0200 |
| Message-ID | <uvjL3-yG-1@gated-at.bofh.it> |
| In reply to | #187414 |
Le 30/09/2017 à 04:18, Gary Roach a écrit : >> > Well the philosophy and stories are nice but my access to the internet > is still among the missing. We are waiting for the information asked by Reco several days ago : ip address list ip route list cat /etc/resolv.conf tcpdump -nvi any udp port 53 or tcp port 53 run while doing getent hosts www.debian.org
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2017-09-30 14:00 +0200 |
| Message-ID | <uvoB5-3DX-15@gated-at.bofh.it> |
| In reply to | #187414 |
On 2017-09-30, Gary Roach <gary719_list1@verizon.net> wrote: >> > Well the philosophy and stories are nice but my access to the internet > is still among the missing. I have a Debian Stretch system installed and > am using NetworkManager. This worked until I installed qemu virtual > machine over the host OS. Since then the host system does not seem able > to find a DNS server. The really strange thing is that I installed > Kubuntu as the guest OS and that works fine. I suspect that qemu has > glommed onto the eth0 device and won't let the host in. I have gone > over and over the NetworkManager documentation and have found no way > to fix this. The situation is getting critical. I need to load some > software into the host system and can't, I also can't upgrade the > system and can't. You're in good hands with Reco and Hambourg, however I read that libvirt creates iptable rules, uses dnsmasq, but actually I don't understand any of this--had I understood something I probably would have said to turn that stuff off to troubleshoot, if you haven't already. > I really need some help here. > > Gary R > > -- "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-25 17:40 +0200 |
| Message-ID | <utDEe-8eJ-13@gated-at.bofh.it> |
| In reply to | #187175 |
On Monday 25 September 2017 08:56:54 Greg Wooledge wrote: > On Sat, Sep 23, 2017 at 06:03:12PM -0700, Gary Roach wrote: > > I have been trying for several day to get firefox to work on a newly > > installed Debian Stretch system. It Seems that Firefox can't find a > > DNS server. I am having the same problem with apt-get update. None > > of my mirrors can be reached. > > ls -ld /etc/resolv.conf > cat /etc/resolv.conf > dpkg -l resolvconf network-manager > grep ^hosts: /etc/nsswitch.conf > > > Ping works just fine. > > pinging what? > > > I can't even reach the other computers > > on my home network if I use their names. IP addresses work OK. > > LAN configuration can be done in several ways. For most small home > LANs, you probably just want to put the IPs and hostnames in > /etc/hosts on each machine. > > For larger or fancier setups, you can configure a private DNS server. > > > I have > > installed resolvconf > > *shudder* Uncontrollably. > I mean, unless this is a laptop or a tablet or a phone or something. > Then it may be appropriate, because you might actually WANT your > resolv.conf file to be rewritten every time the wind changes > direction. > > For desktop machines with a static internal network configuration, > it's an abomination. And unfortunately it's not the only malevolent > fiend trying to usurp control of your resolv.conf file. There's also > dhclient, and network-manager, and systemd-resolved, and who knows > what else. > > See <https://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/> for > some of your options. Of course, before you can apply any of those > suggestions, you have to seize back control of your resolv.conf file > in the first place. Make sure it's a FILE and not a symlink, and put > the correct content into it. Make sure name resolution works. Then > choose your favorite solution to keep the file under YOUR control. For me, its a root session, and a "chattr +i resolv.conf" If for some reason you need to edit it later, you'll have to use the -i argument first. As long as that +i bit is set, its protected from everything but a mke2fs. 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@gmail.com> |
|---|---|
| Date | 2017-09-25 18:20 +0200 |
| Message-ID | <utEgW-iV-7@gated-at.bofh.it> |
| In reply to | #187183 |
Hi. On Mon, Sep 25, 2017 at 11:33:50AM -0400, Gene Heskett wrote: > > I mean, unless this is a laptop or a tablet or a phone or something. > > Then it may be appropriate, because you might actually WANT your > > resolv.conf file to be rewritten every time the wind changes > > direction. > > > > For desktop machines with a static internal network configuration, > > it's an abomination. And unfortunately it's not the only malevolent > > fiend trying to usurp control of your resolv.conf file. There's also > > dhclient, and network-manager, and systemd-resolved, and who knows > > what else. > > > > See <https://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/> for > > some of your options. Of course, before you can apply any of those > > suggestions, you have to seize back control of your resolv.conf file > > in the first place. Make sure it's a FILE and not a symlink, and put > > the correct content into it. Make sure name resolution works. Then > > choose your favorite solution to keep the file under YOUR control. > > For me, its a root session, and a "chattr +i resolv.conf" > If for some reason you need to edit it later, you'll have to use the -i > argument first. As long as that +i bit is set, its protected from > everything but a mke2fs. A common misconception. Here's how a determined userspace can beat immutable bit: # mkdir testetc # touch testetc/resolv.conf # chattr +i testetc/resolv.conf # mv testetc/ testetc.orig # mkdir testetc # touch testetc/resolv.conf # echo evil dns > testetc/resolv.conf Of course you could try to counter that with "chattr +i /etc", but doing *that* should break an unimaginable number of things. If you really need immutable /etc/resolv.conf you should try the Read-Only Root Debian - [1]. [1] https://wiki.debian.org/ReadonlyRoot Reco
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2017-09-25 18:30 +0200 |
| Message-ID | <utEqB-mA-5@gated-at.bofh.it> |
| In reply to | #187187 |
On Mon, Sep 25, 2017 at 07:10:10PM +0300, Reco wrote: > A common misconception. Here's how a determined userspace can beat > immutable bit: > > # mkdir testetc > # touch testetc/resolv.conf > # chattr +i testetc/resolv.conf > # mv testetc/ testetc.orig > # mkdir testetc > # touch testetc/resolv.conf > # echo evil dns > testetc/resolv.conf You'd have to replace all the other files in /etc as well, or the system wouldn't work very well. But that's not the point. The point isn't to harden the system against an attacker bent on subverting your name lookups. It's to protect your locally modified configuration file from being overwritten by well-meaning but stupid software programs. (And yes, there are other ways to achieve that, but I've already posted the <https://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/> URL in this thread. Oops, I did it again.)
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2017-09-25 18:40 +0200 |
| Message-ID | <utEAh-q7-3@gated-at.bofh.it> |
| In reply to | #187188 |
Hi. On Mon, Sep 25, 2017 at 12:21:49PM -0400, Greg Wooledge wrote: > On Mon, Sep 25, 2017 at 07:10:10PM +0300, Reco wrote: > > A common misconception. Here's how a determined userspace can beat > > immutable bit: > > > > # mkdir testetc > > # touch testetc/resolv.conf > > # chattr +i testetc/resolv.conf > > # mv testetc/ testetc.orig > > # mkdir testetc > > # touch testetc/resolv.conf > > # echo evil dns > testetc/resolv.conf > > You'd have to replace all the other files in /etc as well, or the > system wouldn't work very well. But that's not the point. The point > isn't to harden the system against an attacker bent on subverting your > name lookups. It's to protect your locally modified configuration file > from being overwritten by well-meaning but stupid software programs. If the program misbehaves and it cannot be changed - why bother keeping such program in your OS? I mean, it's Debian maillist, right? Everything that's misbehaves can be fed to 'apt-get purge' and replaced with something more sensible. > (And yes, there are other ways to achieve that, but I've already posted > the <https://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/> URL > in this thread. Oops, I did it again.) An interesting link. It lacks my second favorite approach though (first one being read-only root filesystem): iptables -t nat -A OUTPUT -p udp ! -d <my_dns> --port 53 -j DNAT \ --to-destination <my_dns>:53 iptables -t nat -A OUTPUT -p tcp ! -d <my_dns> --port 53 -j DNAT \ --to-destination <my_dns>:53 ip6tables -A OUTPUT -p udp --dport 53 -j REJECT ip6tables -A OUTPUT -p tcp --dport 53 -j REJECT Let them overwrite my resolv.conf with all kinds of gibberish, but it will resolve the way *I* want it. Reco
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-09-25 23:40 +0200 |
| Message-ID | <utJgB-3Dz-5@gated-at.bofh.it> |
| In reply to | #187187 |
On Monday 25 September 2017 12:10:10 Reco wrote: > Hi. > > On Mon, Sep 25, 2017 at 11:33:50AM -0400, Gene Heskett wrote: > > > I mean, unless this is a laptop or a tablet or a phone or > > > something. Then it may be appropriate, because you might actually > > > WANT your resolv.conf file to be rewritten every time the wind > > > changes direction. > > > > > > For desktop machines with a static internal network configuration, > > > it's an abomination. And unfortunately it's not the only > > > malevolent fiend trying to usurp control of your resolv.conf file. > > > There's also dhclient, and network-manager, and systemd-resolved, > > > and who knows what else. > > > > > > See <https://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/> > > > for some of your options. Of course, before you can apply any of > > > those suggestions, you have to seize back control of your > > > resolv.conf file in the first place. Make sure it's a FILE and > > > not a symlink, and put the correct content into it. Make sure > > > name resolution works. Then choose your favorite solution to keep > > > the file under YOUR control. > > > > For me, its a root session, and a "chattr +i resolv.conf" > > If for some reason you need to edit it later, you'll have to use the > > -i argument first. As long as that +i bit is set, its protected from > > everything but a mke2fs. > > A common misconception. Here's how a determined userspace can beat > immutable bit: > > # mkdir testetc > # touch testetc/resolv.conf > # chattr +i testetc/resolv.conf > # mv testetc/ testetc.orig > # mkdir testetc > # touch testetc/resolv.conf > # echo evil dns > testetc/resolv.conf > > Of course you could try to counter that with "chattr +i /etc", but > doing *that* should break an unimaginable number of things. > > If you really need immutable /etc/resolv.conf you should try the > Read-Only Root Debian - [1]. > > [1] https://wiki.debian.org/ReadonlyRoot > > Reco Unforch, this isn't /root stuffs, but /etc stuffs. And it works. And I could care less how disappointed n-m or dhcpd is. Or even resolvconf itself. Particularly when its as buggy as a 10 day old road kill in August. Yes, there is a place for dhcp, but its for sure not on a home, small number of machines network thats all static. 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:00 +0200 |
| Message-ID | <uu2jh-7SW-19@gated-at.bofh.it> |
| In reply to | #187214 |
On Mon 25 Sep 2017 at 17:32:28 (-0400), Gene Heskett wrote: > > On Mon, Sep 25, 2017 at 11:33:50AM -0400, Gene Heskett wrote: > > > For me, its a root session, and a "chattr +i resolv.conf" > > > If for some reason you need to edit it later, you'll have to use the > > > -i argument first. As long as that +i bit is set, its protected from > > > everything but a mke2fs. > > Unforch, this isn't /root stuffs, but /etc stuffs. And it works. And I > could care less how disappointed n-m or dhcpd is. Or even resolvconf > itself. Particularly when its as buggy as a 10 day old road kill in > August. > > Yes, there is a place for dhcp, but its for sure not on a home, small > number of machines network thats all static. I don't recognise this as a very frequent use case nowadays, with so many laptops etc. So for simplicity, I configure my laptops and desktops alike, with wicd, dhcp and resolvconf. I put hostnames, MACs, and static nameservers' addresses into the "cheap plastic consumer-grade router" (which has no DNS server) because that doesn't travel anywhere, and /etc/hosts looks after LAN addresses. And if I want to do fast bulk transfers between machines in the same room, I connect a cat5 cable and use the IPv6 addresses to avoid disturbing the normal networking through the router. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-09-26 21:10 +0200 |
| Message-ID | <uu3p0-jm-11@gated-at.bofh.it> |
| In reply to | #187268 |
On Tuesday 26 September 2017 13:51:33 David Wright wrote: > On Mon 25 Sep 2017 at 17:32:28 (-0400), Gene Heskett wrote: > > > On Mon, Sep 25, 2017 at 11:33:50AM -0400, Gene Heskett wrote: > > > > For me, its a root session, and a "chattr +i resolv.conf" > > > > If for some reason you need to edit it later, you'll have to use > > > > the -i argument first. As long as that +i bit is set, its > > > > protected from everything but a mke2fs. > > > > Unforch, this isn't /root stuffs, but /etc stuffs. And it works. > > And I could care less how disappointed n-m or dhcpd is. Or even > > resolvconf itself. Particularly when its as buggy as a 10 day old > > road kill in August. > > > > Yes, there is a place for dhcp, but its for sure not on a home, > > small number of machines network thats all static. > > I don't recognise this as a very frequent use case nowadays, with > so many laptops etc. Probably true, but the lappy I bought for while I was out playing consultant after I retired, which put me in a motel or the owner guest house for months at a time for several years, is now quite aged and hasn't been powered up in several months for anything but updates to its mint 15 install. So I could be the exception to that "rule". > So for simplicity, I configure my laptops and > desktops alike, with wicd, dhcp and resolvconf. I put hostnames, MACs, > and static nameservers' addresses into the "cheap plastic > consumer-grade router" (which has no DNS server) because that doesn't > travel anywhere, And in turn that cheap plastic consumer grade router no doubt has an NSA back door clear into the smallest machine on your network. My router is a plastic buffalo netfinity, paid about $70 for it and it has been reflashed with the real dd-wrt, not the version that it came with, which among many other features has a dhcp client to get its address from my isp, but it also has a server that can if configured to do so, hand out 200 some leases. It also has no back doors for the NSA, and in 15 years of running dd-wrt on 3 different pieces of hardware, has had only one person come thru it and I gave him the username and pw to do so. Lots of features I don't enable are there. Port forwarding is one, you can see my web page (in the sig) which I run in a sandbox on this machine. > and /etc/hosts looks after LAN addresses. And if I > want to do fast bulk transfers between machines in the same room, > I connect a cat5 cable and use the IPv6 addresses to avoid disturbing > the normal networking through the router. I'll have to plead ipv6 ignorance as the nearest outside ipv6 is at least 100 miles away from me. My questions as to how to enable it between the 10 or so ipv4 addresses available here if everything is booted up, have been ignored. I don't know if the first of two switches I have here even passes it, and haven't seen a "getting started with ipv6 for dummies" tutorial, if it even exists. I suspect it will arrive here after I've not made morning roll call for several years. So like a jar of pickles I found while cleaning out the veggie drawer today, its been shoved to the back of the bottom shelf. :) But you should get yourself a real router, and reflash it with some real router firmware, dd-wrt, tomato or one of the other lesser known router firmwares. dd-wrt is bulletproof to the point I don't run iptables or its ilk on the machines of my local network. Don't need it. > Cheers, > David. You too, David. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2017-09-25 19:40 +0200 |
| Message-ID | <utFwl-15m-1@gated-at.bofh.it> |
| In reply to | #187183 |
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."
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2017-09-25 20:00 +0200 |
| Message-ID | <utFPI-1cJ-3@gated-at.bofh.it> |
| In reply to | #187193 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2017-09-25 21:00 +0200 |
| Message-ID | <utGLL-1Ok-5@gated-at.bofh.it> |
| In reply to | #187194 |
Hi. On Mon, Sep 25, 2017 at 01:53:17PM -0400, Greg Wooledge wrote: <Belkin DHCP server rant skipped> > Would I be happier if I could use a more elegant solution? Yes. Being disappointed with built-in Zyxel DHCP server I merely disabled it and set up a proper ISC DHCP server. I don't know, it's probably unelegant to you, but it's not a DHCP server unless ISC made it. > Should the dhclient program have a CONFIG FILE OPTION to say > "NEVER TOUCH THE resolv.conf FILE"? YES! > > Does it? NO! I need to ask - what are you using instead of proper DHCP client? Every DHCP client worthy of its name (ISC one, for instance) allows one to redefine every part of client configuration via hooks. For instance dhcpcd that I use has this specific example in its manpage: So to stop dhcpcd from touching your DNS settings or starting wpa_supplicant you would do:- nohook resolv.conf, wpa_supplicant > Do I expect it ever to have one in the future? BWA-hahahaha! No. But the future *is* here already. > So we use what works, because the other choices don't fucking work. Tsk, tsk. Language. Also, of course they work. Reco
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2017-09-25 21:30 +0200 |
| Message-ID | <utHeO-2eS-17@gated-at.bofh.it> |
| In reply to | #187202 |
On Mon, Sep 25, 2017 at 09:59:26PM +0300, Reco wrote: > I need to ask - what are you using instead of proper DHCP client? titan:~$ dpkg -l | grep dhc ii isc-dhcp-client 4.3.5-3 amd64 DHCP client for automatically obtaining an IP address ii isc-dhcp-common 4.3.5-3 amd64 common manpages relevant to all of the isc-dhcp packages > Every DHCP client worthy of its name (ISC one, for instance) allows one > to redefine every part of client configuration via hooks. > For instance dhcpcd that I use has this specific example in its manpage: > > So to stop dhcpcd from touching your DNS settings or starting > wpa_supplicant you would do:- nohook resolv.conf, wpa_supplicant titan:~$ man dhclient | grep resolv titan:~$ man dhclient.conf | grep resolv titan:~$ dhclient --help 2>&1 | grep resolv titan:~$ So, your solution was to rip isc-dhcp-client entirely out of the system and replace it with something else. Mine was to chattr +i resolv.conf. The cyberciti.biz FAQ page gives another solution that involves creating an sh function in some undocumented directory to overwrite some undocumented internal part of the DHCP client with a function that does nothing. What I mean by undocumented: according to the web page, the directory used to be named /etc/dhcp3/dhclient-enter-hooks.d/ and yet: titan:~$ man dhclient | grep hook titan:~$ man dhclient.conf | grep hook titan:~$ I have not tested this solution. I'm just assuming that it will work if we replace the old directory name with the new one (/etc/dhcp/...). I would expect the "hooks.d" part to be in there somewhere. It's not. So, if you want to disparage me because I could have done this secret undocumented ridiculously intrusive thing that one can only learn about from a third party web page, sure, go ahead. Tell me how stupid and lazy I am for preferring a simple command that just WORKS over this undocumented hook thing, at the same time that you yourself THREW THE ENTIRE SOFTWARE PACKAGE AWAY rather than try to deal with it. Fine: I'm stupid and lazy and ignorant and unwilling to learn. But at least my computer works (now).
[toc] | [prev] | [next] | [standalone]
| From | Don Armstrong <don@debian.org> |
|---|---|
| Date | 2017-09-25 21:30 +0200 |
| Message-ID | <utHeN-2eS-11@gated-at.bofh.it> |
| In reply to | #187194 |
On Mon, 25 Sep 2017, Greg Wooledge wrote:
> Should the dhclient program have a CONFIG FILE OPTION to say
> "NEVER TOUCH THE resolv.conf FILE"? YES!
>
> Does it? NO!
It does. Simply:
cat - <<EOF > /etc/dhcp/dhclient-enter-hooks.d/disablemakeresolvconf
make_resolv_conf() { : ; }
EOF
as is documented in dhclient-script(8):
When it starts, the client script first defines a shell function,
make_resolv_conf , which is later used to create the
/etc/resolv.conf file. To override the default behaviour,
redefine this function in the enter hook script.
--
Don Armstrong https://www.donarmstrong.com
An elephant: A mouse built to government specifications.
-- Robert Heinlein _Time Enough For Love_ p244
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2017-09-25 21:50 +0200 |
| Message-ID | <utHya-2oD-15@gated-at.bofh.it> |
| In reply to | #187206 |
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. :-(
[toc] | [prev] | [next] | [standalone]
| From | Don Armstrong <don@debian.org> |
|---|---|
| Date | 2017-09-25 23:20 +0200 |
| Message-ID | <utIXf-3we-17@gated-at.bofh.it> |
| In reply to | #187210 |
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*. But since most people don't care about that power, resolvconf is a much better method to use to manage resolv.conf than chattr or any of the other hacks. It does the right thing in almost every case and has hooks for dhclient, NetworkManger, pppd, ifupdown, dnsmasq, etc. -- Don Armstrong https://www.donarmstrong.com 2: There is no out. There is only in. -- "The Prisoner (2009 Miniseries)"
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2017-09-26 15:20 +0200 |
| Message-ID | <utXWi-5gz-5@gated-at.bofh.it> |
| In reply to | #187213 |
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.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2017-09-26 15:50 +0200 |
| Message-ID | <utYpj-5qG-9@gated-at.bofh.it> |
| In reply to | #187244 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Sep 26, 2017 at 09:09:47AM -0400, Greg Wooledge wrote: [...] > 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. To be fair, dhclient-script is figures in the output of man -k dhclient And is mentioned several times in the dhclient man page (in the see-also section, among other things). > 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. Dhclient-script is also ref'd to from dhclient-conf(5). Alas, not in the "see-also" section (IMHO it should be). I know this would be preaching to the choir for the ones and lost on the others -- but do give Emacs' WoMan mode a try. It is Emacs' man page viewer, and does a good job of making clickable links of all those embedded refs. Hypertext! (I know, I know: another story started like this one and isn't ending well, but... ;-) Don't get me wrong: it happens to me all the time that it's there, in front of my nose, and I don't see it. I take this as a chance to ask myself: "how would I have done that, as a writer, to help my other self? how can I, as a reader, be smarter next time?) Doumentation Is Hard (TM) Cheers - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlnKWbcACgkQBcgs9XrR2kbTKwCcCrVDUK3riaKtJ2vW7mTrxH2l JZgAn1yjHGVLAtXNiHpD1Temy+QaV1dp =LLxs -----END PGP SIGNATURE-----
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | linux.debian.user
csiph-web