Re: [DNG] how to clear DNS cache

[Arnt Karlsen]

On Thu, 5 Jan 2017 09:21:08 -0600 (CST), ja...@beau.org wrote in
message <54290.192.168.250.61.1483629668.squir...@beau.org>:

> > Il giorno Wed, 4 Jan 2017 15:11:36 -0800
> > Rick Moen  ha scritto:
> 
> >>  There is obviously a happy middle ground.
> 
> >   Yes, it's called: "let the user decide".  Level (0) menu:
> 
> > A) Let the install program choose all the required settings (basic,
> > no-frills,
> > automatic install, zero questions asked) [Default]
> > B) Customize the system at install time
> 
> I kind of like:
> 
> A) Beginner

..this needs nice safe paranoid defaults that protects beginners 
from bad etc 3-letter etc dudes etc... blunders and not.

..both https://tails.boum.org/ and https://www.qubes-os.org/ are
endorsed by Edward Snowden, despite running systemd... go figure.

> B) Experienced
> C) Expert
> D) NetGod
> 
> The questions asked would depend on the various levels - Beginner gets
> networking set up asking the fewest possible questions, Experienced
> gets asked "Do you want to set up a default recursive name server?"
> Expert gets to pick from the list, and NetGod gets a commmand line to
> set up the name server system the way they want it.


-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev packaging status (was eudev status)

[Ralph Ronnquist]

The devuan/debian packaging of vdev is so far only in "my" repository. 
But I've only fitted it out with the packaging files that differ from 
the "defaults", as generated by "dh_make -a". Please look at the make 
file "debian.mk" for specifics.


I also started on a habit to build it all in a firejail overlay so as to 
not pollute my workspace; the bottom of the top level Makefile gives the 
hint to that. Though, I'm happy to learn and change to "the proper way". 
My forward plan is to merge "my" repository into "unsystemd", and then 
also adapt it to fit into the automagic build process.


I suppose I should also (learn how to) make the source packages; (this 
might require some changes to the source structure, since as it stands, 
the various "vdev packages" get composed by cherry picking in the build 
tree. It could be cleaner)


Anyhow, at the moment, in "ralph.ronnquist/vdev" you find three "debian" 
sub directories for building three packages: "vdevd", "libudev1-compat" 
and "vdev-initramfs". These directories contain only the non-default 
packaging files, while the rest are as generated by "dh_make -a".


Ralph.

Anto wrote on 2017-01-05 00:39:

On 24/12/16 00:17, fsmithred wrote:

On 12/23/2016 05:42 PM, Rob Owens wrote:

On Thu, Dec 22, 2016 at 10:56:58AM -0500, Haines Brown wrote:

I installed jessie-beta on a disk some time ago, and off hand it boots
and runs just fine. However I didn't migrate it to from my current
Debian
Wheezy because I was waiting for the eudev/vdev/udev issue to be
resolved, figuring that migrating up from present udev to one of the
others could well be traumatic. I didn't want to do it on a system
on which I relied for work.

Two questions, if I may:

Is eudev being actively worked on, and is it likely to be in
the upcoming  non-beta Jessie Devuan?

vdev was/is being developed by a Devuan user specifically with Devuan in
mind.  eudev, as others have already stated, is a Gentoo project.  I'm
not sure the status of vdev.


It has been packaged, and it works. (i.e. It works for me and a few
others. If more people try it, then it will work for more people.)

Here are vdev packages made by Ralph Ronnquist:
https://git.devuan.org/ralph.ronnquist/vdev/tree/master/release

Here are vdev packages made by Aitor:
http://packages.gnuinos.org/pool/main/v/vdev/

I should add that the two sets of packages are probably not compatible
with each other. Pick one.

Here's a live-CD iso I made with a sparse devuan install with openbox wm
and...  vdev. I used Ralph's deb packages for this build, and I only made
an amd64 iso. It's already isohybrid, so you can dd or cat it to a usb
stick.
http://distro.ibiblio.org/refracta/files/experimental/jessie-vdev2-20161013_0159.iso


-fsmithred


Hello fsmithred and everybody,

As fas as I understood, a proper debian package must have the debian
packaging files, i.e. the debian directory and its files, so that people
can compile and test it on any supported platforms. So I don't believe
that vdev has been properly packaged so far as I cannot find any debian
packaging files either on
https://git.devuan.org/unsystemd/vdev/tree/master or
https://git.devuan.org/ralph.ronnquist/vdev/tree/master. Or perhaps I am
out of date on the packaging approach used in Devuan. But I believe
Devuan still follows the same packaging method as Debian.

For me, I will be more confident to install a package that has never
been packaged before, when I can successfully compile it under my
environment using dpkg-buildpackage. Especially for device manager
packages, I have to be very careful as the chances to break my PC is
quite high. At the first stage of vdev development, I always broke my
test PC until I decided to stop testing and just wait for a vdev package
with debian packaging files available.

So is there anywhere I can find the debian packaging files of vdev?

Thanks in advance.

Cheers,

Anto

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] how to clear DNS cache

[Rick Moen]

I wrote:

> I didn't think it necessary to belabour the fact that if a network
> daemon, one that inherently needs open Internet access to work, is
> prevented from having open Internet access, it won't work.

I should hasten to add, sure, there is also the hotel wifi
captive-portal annoyance.  Might justify a displayed note saying 'Note:
Must be disabled to reach some wifi login pages.'
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] how to clear DNS cache

[Rick Moen]

Quoting Steve Litt (sl...@troubleshooters.com):


[BIND9:]

> I didn't like it for that same reason, but always wondered if it were
> just a case of my drinking the djb kool aid.

Dan's many criticisms of BIND9 and of its BIND8 predecessor (a
from-scratch rewrite separating the two) were always well-founded in
fact even if so very slathered in assholish rhetoric, and surrounded by
dickish personal conduct, that people often resisted his truths just
because of his extremely offputting manner and conduct.  (I never did,
FWIW.)

The very least of that assholish rhetoric is speaking as if BIND8 and
BIND9 were the very same codebase rather than a from-scratch rewrite
having occurred between them.  It goes on from there, as you are
probably aware.


[PowerDNS;]

> Nix on that, for similar reasons as my keeping away from dbus-necessary
> software. 

I of course concur.  The pair of PowerDNS packages are aimed at huge
installations, primarily, e.g., my $FIRM where I did the migration to
PowerDNS from BIND9.


[Deadwood:]

> Sounds excellent. Maintained by one is less of a problem when there are
> so many alternatives.

Sam Trenholme freely admits sometimes when he took a while getting
around to fixing a problem in MaraDNS or Deadwood, telling people on his
mailing list that he's obliged to put work and other priorities first.
He says, quite reasonably, that if anyone wants faster response, he'll
gladly accept most forms of, y'know, money.

On the one hand, this means that maintenance is a bit thinly available.
On the other, it's somewhat likely true of many other open source
codebases including the competitors, and the only big difference is that
Sam is bluntly honest about it.  (On the gripping hand, to use an old
Niven & Pournelle metaphor, I get the impression that Unbound is
-very- responsively maintained.)


[Unbound:]

> Sounds excellent.

IMO, as should be obvious, it is.


[Debian djbdns/dbndns:]

> As the author of runit, Gerrit Pape is my main man. If I continue using
> djbdns, I'd certainly get his version, *if* I could get a source version
> not tightly bound to Debian, and to dbus and systemd.

Project page:  https://packages.debian.org/source/sid/djbdns
Please let me know how it goes.


[N-DJBDNS:]

> Ain't no redhat in this shop.

But you might look at the N-DJBDNS source tree if Gerrit Pape's Debian
djbdns/dbndns doesn't suit for some reason.  Not every coder's work
sucks automatically just because you don't like his/her employer.


> If the others are small, this wouldn't be a priority with me.

All of dnscache, Unbound, and Deadwood qualify as small, fast, light.


> I don't find Jonathan de Boyne Pollard credible.

But that doesn't prevent verifiable factual assertions of his from being
correct, and am pretty certain that one was.  I haven't verified it
myself, but it certainly _sounds_ like the sort of thing Dan would
ignore as 'Yes, my software doesn't resolve Akamai's incredibly
squirrely delegation, because I don't like the way Akamai does that and
consider it Bad and Wrong.'  That would match his established pattern of 
deciding to deliberately ignore RFCs he doesn't like that the
consensus-reality world regards as routine and saying 'I don't care.
They suck.'

I'm not arguing with Dan's judgement that certain RFCs suck, or even with
the particular ones he dislikes.  I'm just saying that this pattern of
behaviour is part of what you get with djbware -- this being one of the
several points I made in my Web essay, and indeed one of the particular
points in it to which Dan specifically objected, when he made his
legal threat.



> I think we've all read those exchanges.

{shrug}  I'm well-known within a tiny little circle of software people.  ;->


> Geez, only local people have called me an idiot. I'd love to have
> Poettering call me an idiot.

I'll note in passing that Dan's assertion of my idiocy was based on
his deliberate _misrepresentation_ of my characterisation of his
then-licensing.  I.e., his cartoon distortion of what I said might
indeed be seen as idiotic, but what I _said_ IMO wasn't.

I occasionally am obliged to clarify that, as here on spf-devel back in
2004:  http://linuxmafia.com/~rick/faq/just-another-djb-groupie.html
 
-- 
Cheers, "The crows seemed to be calling his name, thought Caw."
Rick Moen -- Deep Thoughts by Jack Handy 
r...@linuxmafia.com 
McQ! (4x80)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [OT] setnet v0.2: a shell script for network config

[Gregory Nowak]

On Thu, Jan 05, 2017 at 10:08:52PM +, KatolaZ wrote:
> Steve, that's already been fixed. The detection of interface type is
> implemented using iwconfig now, and is not based on interface names
> any more.

That isn't going to work everywhere unfortunately. As of now, the
built-in wifi adapter on the raspberry pi 3 shows no wireless
extensions when running as arm64.



Greg


-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] how to clear DNS cache

[Simon Hobson]

ja...@beau.org wrote:

> I kind of like:
> 
> A) Beginner
> B) Experienced
> C) Expert
> D) NetGod

Isn't this missing the point ?
If the problem is working around broken DHCP and/or local resolvers, then it 
comes down to :
A) If network configuration works and we can resolve the names we need to - 
then we don't need to ask the question at all. There's nothing to 
fix/workaround, no need for any user interaction.
B) Network configuration fails (IP address is gained, but DNS doesn't work) - 
then we have to start asking questions regardless of installation level. It 
comes down to starting down the route of "Your local network configuration 
appears to be broken, how do you want us to try and work around that ?".

IMO the initial options should be something a bit simpler, like (perhaps the 
ordering is wrong) :
[ ] Go back and retry network configuration
[ ] Manual DNS server entry ...
[ ] Try a public server ...
[ ] Try running a local resolver ...
[ ] Let the installer try a few things for you (automatic configuration based 
on tests) ...

Manual server entry is self explanatory - if you know of a working server, then 
bung it's IP address in.

Try a public server could then lead on to a dialog where the user is asked to 
pick one or more server(s) to try and use.

Similarly, Try a local resolver could ask the user which local resolver package 
to use - but IMO that's a bit moot as we should be able to run just one that's 
pre-defined for the duration of the install process and which "just disappears" 
when the ramdisk/tempfs/unionfs used by the installer goes away.

It probably makes sense to run some tests to determine if DNS lookups are 
actually possible. One logical approach would be to publish a dummy DNS entry 
(ie one not actually used for anything) just for the purpose of this - and with 
a known result. That way, the installer can be hard-coded with the response(s) 
it expects without the issues of it breaking when (for example) a repository 
server moves.

Try a few things might be a case of running a few tests to try and probe what 
the network allows. Perhaps see if the default gateway does DNS recursion for 
us, then try some known public (or root) servers and see if we get an answer. 
Depending on what we find, configure the installation environment automatically.


Rick Moen  wrote:

> Without objection, I'll point out that one leading advantage of a local
> recursive server (what you probably mean when you say 'caching DNS
> server'[1]) is that it Just Works

Unless you are in one of the situations previously mentioned where it doesn't 
...

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] how to clear DNS cache

[Steve Litt]

On Thu, 5 Jan 2017 13:47:14 -0800
Rick Moen  wrote:

> Quoting Steve Litt (sl...@troubleshooters.com):
> 
> > Which of the preceding is best? I've always been partial to
> > dnscache/tinydns, but installing it is a long cumbersome procedure
> > giving Arch installation a run for its money. I've never heard of
> > Unbound, PowerDNS Recursor, or Deadwood.  
> 
> The question you ask is very debatable.  
> 
> 
> As you probably know, BIND9 is of questionable architecture, being a
> single monolithic
> all-singing/all-dancing binary, slow, large, overfeatured.  I would
> rule it out on grounds of being not _just_ a recursive nameserver.

I didn't like it for that same reason, but always wondered if it were
just a case of my drinking the djb kool aid.

> 
> 
> PowerDNS Recursor is the recursive-server matching element to PowerDNS
> Authoritative Server from the same folks.  Both are back-ended into
> SQL databases (default MySQL).  

Nix on that, for similar reasons as my keeping away from dbus-necessary
software. 

[snip] 

> Deadwood is by Sam Trenholme, author of MaraDNS, who is (fair
> disclosure) like you a friend of mine.  He wrote it as the
> from-scratch replacement for the recursive-server daemon in the
> antecedent MaraDNS suite, i.e., if you install the
> currently-maintained MaraDNS 2.x suite, you get Deadwood as its
> recursive-server component rather than the original implementation --
> but Sam also decided to package Deadwood separately for people who
> want _just_ recursive functions.  As noted in my
> http://linuxmafia.com/faq/Network_Other/dns-servers.html#deadwood
> writeup, in a comparative test by Sam of compiling stripped binaries
> with the same compiler optimisation, Deadwood weighed in as the
> second smallest binary.  Advantage: has good security history.
> Disadvantage: maintained by just one guy, and part-time at that.

Sounds excellent. Maintained by one is less of a problem when there are
so many alternatives.

> 
> 
> Unbound was the second effort by the .nl TLD people, NL Labs, after
> they wrote NSD, an authoritative server so successful it's now used
> by many TLD nameservers and root nameservers.  Advantages: clean
> design, extremely well maintained, good security history.  And it Just
> Works.[tm] Disadvantages: can't think of any offhand.

Sounds excellent.

> 
> 
> To discuss dnscache (the recursive server from djbdns), you must
> discuss whose fork and with what patchsets, because DJB's version
> djbdns 1.06 codebase that was his final release cannot itself be
> recommended because of unpatched problems.  Maintained forks:
> 
> o zinq-djbdns by Mark Johnson
> o Debian djbdns/dbndns by Debian developer Gerrit Pape (both binary
>   packages cited being built from single Debian source package
> djbdns). 

As the author of runit, Gerrit Pape is my main man. If I continue using
djbdns, I'd certainly get his version, *if* I could get a source version
not tightly bound to Debian, and to dbus and systemd.

> o N-DJBDNS by Red Hat developer Prasad J. Pandit 

Ain't no redhat in this shop.

> 
> There used to be a fourth, by Joshua Small, named LolDNS, but he
> orphaned his effort soon after he started it in 2013.  (If you're an
> optimist, you could say it's completed and mature rather than
> orphaned.  You be the judge.)
> 
> The big question about any update of the historic djbdns 1.06 codebase
> is whether the maintainer has applied _enough_ patches to fix its many
> documented problems.  Also, quality of the patches applied is
> something you could judge if you wanted to make a hobby of this.
> Advantages: Patched dnscache from zinq-djbdns was the smallest
> compiled binary in Sam Trenholme's comparison.  

If the others are small, this wouldn't be a priority with me.

> Security history is
> good.  Disadvantage: Original coder (by one of the world's most
> contentious personalities in software) 

Oh come on now, he's like you, he never argues with anyone!

> is famously eccentric in his
> coding style along with everything else, and what he writes is
> FHS-hostile by strong default tendency unless the package works at
> it.  

You got something against /service and /command?

:-)

> According to djbware expert Jonathan de Boyne Pollard, some
> functionality problems remain even in patched dnscache compared to
> competitors, such as frequent failure to resolve Akamai and some
> other companies' DNS that do baroque delegations without glue records.

I don't find Jonathan de Boyne Pollard credible. From my viewpoint,
he's a systemd apologist with an overly featured init system that's
trying to be a systemd me-too, and he picks nits about simpler init
systems, concerning little corner cases that will happen only to very
few, that can easily be worked around. He seems to be a fan of
complexity. Unlike runit and s6, I never got nosh running, and perhaps
this reveals a personal deficiency, but I just don't care.

If JdBP finds problems with patched djbdns, I 

Re: [DNG] how to clear DNS cache

[Rick Moen]

Quoting Steve Litt (sl...@troubleshooters.com):

> Yes yes yes, I understand that now. I hadn't really thought it through
> when I asked that question.
> 
> In general though, I like the idea of public DNS as something that
> *just works*. I can later switch to the DNS server suggested by my DHCP
> suggestion, or install a caching DNS server on my computer.

Without objection, I'll point out that one leading advantage of a local
recursive server (what you probably mean when you say 'caching DNS
server'[1]) is that it Just Works -- in exactly the same way as 'public
DNS' does, plus you get faster response, because it's local and you have
low connection latency.


[1] The term 'caching server' doesn't tell you much, and doesn't really
say what the software _does_.  Lots of different sorts of nameservice
software do caching.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] how to clear DNS cache

[Rick Moen]

Quoting Steve Litt (sl...@troubleshooters.com):

> I really like djbdns, but its installation is long and error prone, and
> djb uses directories like /service that no distro will ever use.

Dan really hates FHS.  ;->

I haven't really properly investigated the three (arguably still four)
maintained forks of djbdns.  It's more than possible that one or more of
them altered that, and I'd expect (at minimum) Garrit Pape and Prasad J.
Pandit to have produced FHS-leaning packages of their forked codebases,
because I expect they'd want to follow Debian and Red Hat (respectively)
policy.

http://linuxmafia.com/faq/Network_Other/dns-servers.html#debian-djbdns
http://linuxmafia.com/faq/Network_Other/dns-servers.html#ndjbdns

> On a selfish note, because every computer I use either has runit or has
> already installed Daemontools or Daemontools-encore, it would be nice
> if the daemontools part of djbdns install was made optional.

With work, you can use other superservers such as xinetd/inetd, instead.

I can't remember, does dnscache run by default under daemontools (and
require it), or is that just tinydns et alii?


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [OT] setnet v0.2: a shell script for network config

[KatolaZ]

On Thu, Jan 05, 2017 at 03:26:00PM -0500, Steve Litt wrote:

[cut]

> 
> Do you have it yet so it doesn't deduce the connection type
> (wired/wifi) by the device name? I'd love to use it, but it refuses to
> work, and before I go in and change your code to make devicenames
> starting with 'e' wired and 'w' wifi, are you going to fix that in the
> next couple days?

Steve, that's already been fixed. The detection of interface type is
implemented using iwconfig now, and is not based on interface names
any more.

HH

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] how to clear DNS cache

[Florian Zieboll]

On Thu, 5 Jan 2017 15:02:09 -0500
Steve Litt  wrote:

> Which of the preceding is best? I've always been partial to
> dnscache/tinydns, but installing it is a long cumbersome procedure
> giving Arch installation a run for its money. I've never heard of
> Unbound, PowerDNS Recursor, or Deadwood.


On my home router, I have unbound resolving - when setting it up, I had
been surprised how few of a hassle it is to get it up and running: In
fact, only the Raspberry Pi's lack of a hardwareclock caused editing
beyond unbound.conf.

Here my "simplest possible" move from dnsmasq to dnssec'ed unbound and
isc-dhcpd:

https://cheatsheet.zwischenspeicher.info/2016/05/12-2016-05-11/

Libre Grüße,

Florian

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [OT] setnet v0.2: a shell script for network config

[Steve Litt]

On Thu, 5 Jan 2017 00:45:08 +
KatolaZ  wrote:

> On Thu, Jan 05, 2017 at 12:32:57AM +, KatolaZ wrote:
> > Hi all,
> > 
> > sorry for the OT. I just wanted to let you know that I have released
> > the new version of setnet, that simple shell+dialog script for
> > network configuration we talked about earlier this week. You can
> > find the deb package here:
> > 
> >   http://kalos.mine.nu/setnet/
> > 
> > Please feel free to give it a try, if you like, and report
> > bugs/issues here:
> > 
> >   https://git.devuan.org/KatolaZ/setnet
> >   
> 
> I forgot to say that the project is also available on github:
> 
>   https://github.com/KatolaZ/setnet

Do you have it yet so it doesn't deduce the connection type
(wired/wifi) by the device name? I'd love to use it, but it refuses to
work, and before I go in and change your code to make devicenames
starting with 'e' wired and 'w' wifi, are you going to fix that in the
next couple days?

Thanks,

SteveT

Steve Litt 
December 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] how to clear DNS cache

[Steve Litt]

On Wed, 4 Jan 2017 15:11:36 -0800
Rick Moen  wrote:

> Quoting Alessandro Selli (alessandrose...@linux.com):
> 
> > This is something that belongs to a different stage in the OS
> > installation, when:
> > 
> > 1) the user determined that a DNS server must be installed;
> > 2) that it has to run as a local recursive nameserver;
> > 3) that a particular implementation of such a server must be
> > installed.  
> 
> This view amounts to 'consign it to an expert installation profile',
> which then is functionally the same as 'don't bother', as discussed
> below.
> 
> I should stress that I didn't _literally_ have in mind the installer 
> offering the user all five open source recursive nameservers for
> Linux. I showed all five checkboxes to stress the breadth of options
> _all_ of which are being ignored -- even in your amazing and rather
> amusing list.

I really like djbdns, but its installation is long and error prone, and
djb uses directories like /service that no distro will ever use. Every
distro I ever saw providing djbdns (superset of dnscache) did it in a
way that required gargantuan troubleshooting. If Devuan did it, it
would need to be done in a reasonable way with good documentation.

On a selfish note, because every computer I use either has runit or has
already installed Daemontools or Daemontools-encore, it would be nice
if the daemontools part of djbdns install was made optional.

SteveT

Steve Litt 
December 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] how to clear DNS cache

[Steve Litt]

On Wed, 04 Jan 2017 22:00:29 +
Rainer Weikusat  wrote:

> Steve Litt  writes:
> > On Tue, 3 Jan 2017 11:06:53 +0100
> > Jaromil  wrote:
> >  
> >> On Mon, 02 Jan 2017, Jaromil wrote:
> >>   
> >> > what a pity Debian has switched to Google's DNS by default.
> >> 
> >> for the record and the sake of historical correctness:
> >> 
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658
> >> 
> >> there is however an issue we need to look at for Devuan: it seems
> >> the default dns resolver for our distribution is also back to
> >> 8.8.8.8, at least someone on irc backfired to this thread with
> >> this claim.  
> >
> > What's wrong with 8.8.8.8?  
> 
> Why would I want to send a list of all web sites I visit to an
> advertising company providing a 'free' service who wants to have this
> information because it's valuable business data?

Yes yes yes, I understand that now. I hadn't really thought it through
when I asked that question.

In general though, I like the idea of public DNS as something that
*just works*. I can later switch to the DNS server suggested by my DHCP
suggestion, or install a caching DNS server on my computer.

I completely understand now.

SteveT

Steve Litt 
December 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] how to clear DNS cache

[Steve Litt]

On Wed,  4 Jan 2017 21:27:36 +0100 (CET)
k...@aspodata.se wrote:

> Rick Moen:
> ...
> > But yet again, nobody is yet thinking to include what seems most
> > obvious to me:
> > 
> >  [ ] Run Unbound as local recursive nameserver on this host.
> >  [ ] Run PowerDNS Recursor as local recursive nameserver on this
> > host. 
> >  [ ] Run BIND9 as local recursive nameserver on this host.
> >  [ ] Run dnscache as local recursive nameserver on this host.
> >  [ ] Run Deadwood as local recursive nameserver on this host.  
> 
> Best suggestion to date.

Which of the preceding is best? I've always been partial to
dnscache/tinydns, but installing it is a long cumbersome procedure
giving Arch installation a run for its money. I've never heard of
Unbound, PowerDNS Recursor, or Deadwood.

 
SteveT

Steve Litt 
December 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] how to clear DNS cache

[Rainer Weikusat]

Hendrik Boom  writes:
> On Wed, Jan 04, 2017 at 10:00:29PM +, Rainer Weikusat wrote:
>> I'm running a caching resolver locally because that "always works"
>> (unless blocked by the ISP which may become mandatory in the UK 'soon'
>> ...), even if an out-of-the-ordinary cache flush is called for because
>> of a 'recent' DNS information change.
>
> Which brings us around full circle to the original question -- how to 
> do a cache flush!

For bind,

rndc flush

In case of a usual 'SOHO' setup, there will be a (presumably caching)
resolver running on 'the router' which provides its own address as name
server via DHCP. My setup is such that my 'work computer' gets a static
address assigned via DHCP with this address also being used as DHCP
nameserver address. The Debian default bind configuration can be used
as-is for running a caching, recursive resolver locally. Packages
desiring to mess with the resolver configuration usually use
resolvconf(8). This generates such a configuration and relies on
/etc/resolv.conf being a symlink to the generated file. Replacing the
symlink with a real file containing

nameserver 127.0.0.1
search [ [ https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] apt configuration and repositories

[Massimiliano Baldinelli]

On 27/12/2016 08:39, Petr Gajdůšek wrote:


Package: *
Pin: release o=Debian
Pin-Priority: -1

Package: *
Pin: release o=Debian Backports
Pin-Priority: -1


Added a Debian source to sources.list and these stanzas in a file in 
/etc/apt/preferences.d/ and now aptitude is dowloading also Translations-en.



1: https://git.devuan.org/devuan/devuan-project/issues/75


So this is only a temporary "fix", if I understand it correctly, sooner 
or later there will be native Devuan long descriptions too :-)


--
   "Sin clave no hay salsa."

   ---=== Powered by Devuan GNU+Linux ===---
(registered Linux user #297134)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] how to clear DNS cache

[Rick Moen]

Quoting Alessandro Selli (alessandrose...@linux.com):

I skipped down to the very bottom of your latest, and found:

> It's not any silly if you are to perform an install in a corporate,
> locked-down datacenter.  The fact that you never had to operate in such
> an environment

...which is the _opposite_ of what I had just said.

And that further illustrates why I said 'Here's an idea:  We're done.'
Enjoy your day!

-- 
Cheers,   "If God dwells inside us, as some people say, I sure hope 
Rick Moen He likes enchiladas, because that's what He's getting!"
r...@linuxmafia.com-- Deep Thoughts by Jack Handy
McQ! (4x80)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] how to clear DNS cache

[Alessandro Selli]

Il giorno Thu, 5 Jan 2017 02:26:25 -0800
Rick Moen  ha scritto:

> Quoting Alessandro Selli (alessandrose...@linux.com):
> 
>> I followed the same logic when I listed 26 alternate public DNS servers to
>> choose from.  I know it contradicts my own argument that the install
>> program should ask the fewest possible questions.
>
> Before I follow you further down this rabbit hole, I'm curious:  Are 
> you still speaking about Devuan and its distro installer?  Because my 
> understanding is that Devuan is not currently aspiring to have 'zero
> questions asked' (your phrase) nor anything like the fewest possible 
> interactions with the installing administrator for the default
> installation mode.

  I stated it very clearly: «*In my view*, the install program that asks the
shortest list of questions is the  best one for automated, bulk
installations.» (emphasis added)

> I have been assuming we were impliedly talking about the default
> installation mode, not a non-default fully-automated mode nor a
> non-default expert installation mode, or anything else of that sort.

  I am not entertaining this thread just for the sake of describing the
status quo.  Are you?  Or is everyone proposing and debating proposals for
a change?

> I ask because your current posting meanders all over those things, which
> is confusing, because that wasn't the conversation I thought I was
> having, nor (I'm pretty sure) one I especially wish to (no offence
> intended).  Seems to me, we could spend ages discussing all of those
> additional things, and, IMO, have little to show for it.

  You are under no obligation to participate in a discussion you do not
like/think is a waste of your precious time.

[...]

>>> I'm merely suggesting that if you're already offering a screen to
>>> input the IPs of recursive nameservers (and Devuan is), then a
>>> checkbox for a local recursive nameserver is a trivial addition with
>>> disproportionally large benefits.
>> 
>> I agree, however IPs are input manually in the case the user elected
>> to do so (as in a manual interface configuration) or when automatic
>> interface configuration failed.
>
> Correct me if I'm mistaken:  The default Devuan installer does promt the
> user for nameserver IPs if the user is electing to supply a fixed IP 
> address for a network interface, right?

  Isn't this *exactly* what I wrote?  If so, what is your point?

>  That would be where I said a 
> checkbox for '[ ] install and use a local recursive nameserver' would 
> be a trivial addition with disproportionately large benefits.

  I do not agree.  I do not think a recursive nameserver would solve many
of the the problems that caused a failed automatic resolver configuration.
This option could of course be there (the install program would have falled
into manual, interactive mode anyway), but IMO the benefits are going to be
pretty limited.

> Although certainly a host on dynamic IP _can_ make effective use of a
> local recursive nameserver bound to localhost, I hadn't yet put 
> specific thought into where in the installer, if at all, it would 
> make sense to ask and to offer that enhancement.

  "If at all"?  Are you backpedaling already?

> I don't currently have time to ponder those specifics, but certainly 
> on some screen or other it would be perfectly feasible to offer that as
> a checklist item.

  Wasn't the screen that checklist item was to be presented already put
down?  Shouldn't that be the screen that shows up when the user selects the
manual interface configuration or the DHCP client fails DNS configuration?

>  Season to suit with '(Make sure you know what you're
> doing)' advisories if you honestly think this causes significant failure
> modes, which in my mere 35 years as a Unix admin have been nonexistent
> other than captive portals on some hotel wifi except in one or two
> client sites with such stiflingly severe border firewalling that damned
> near nothing could talk to outside.  But we'll get to those latter
> situations, below.

  I already stated twice, if not three times, what specific situation and
environment this solution would not address and solve: clamped-down
telco datacenter networks.  They evidently are not part of your experience,
they are part of mine.

>>> I don't mean to sound hostile, but _what_ administrative attention?
>> 
>> I already stated that selecting forwarders might be required to let the
>> DNS server work in a given environment.  In all the telco datacenters
>> where I operated internal nodes where not allowed to perform recursive
>> queries on their own.
>
> Thank you for clarifying that by 'a local recursive DNS server needs
> some administrative attention', you do not actually mean attention to
> the software at all.

  What do you mean by "attention to the software"?  Why do you think
configuring the DNS to include forwarders does not constitute "attention to
the software"?

>  You mean situations where outbound access to port
> 53 

Re: [DNG] how to clear DNS cache

[Rick Moen]

Quoting Alessandro Selli (alessandrose...@linux.com):

> I followed the same logic when I listed 26 alternate public DNS servers to
> choose from.  I know it contradicts my own argument that the install program
> should ask the fewest possible questions.

Before I follow you further down this rabbit hole, I'm curious:  Are 
you still speaking about Devuan and its distro installer?  Because my 
understanding is that Devuan is not currently aspiring to have 'zero
questions asked' (your phrase) nor anything like the fewest possible 
interactions with the installing administrator for the default
installation mode.

I have been assuming we were impliedly talking about the default
installation mode, not a non-default fully-automated mode nor a
non-default expert installation mode, or anything else of that sort.

I ask because your current posting meanders all over those things, which
is confusing, because that wasn't the conversation I thought I was
having, nor (I'm pretty sure) one I especially wish to (no offence
intended).  Seems to me, we could spend ages discussing all of those
additional things, and, IMO, have little to show for it.

So, regrettably I'll be disregarding at this time most of your post, as 
I cannot really see the connection to the discussion I _thought_ I
was in.

It's possible I am misunderstanding, in which case my regrets about
that.


> > I'm merely suggesting that if you're already offering a screen to
> > input the IPs of recursive nameservers (and Devuan is), then a
> > checkbox for a local recursive nameserver is a trivial addition with
> > disproportionally large benefits.
> 
> I agree, however IPs are input manually in the case the user elected
> to do so (as in a manual interface configuration) or when automatic
> interface configuration failed.

Correct me if I'm mistaken:  The default Devuan installer does promt the
user for nameserver IPs if the user is electing to supply a fixed IP 
address for a network interface, right?  That would be where I said a 
checkbox for '[ ] install and use a local recursive nameserver' would 
be a trivial addition with disproportionately large benefits.

Although certainly a host on dynamic IP _can_ make effective use of a
local recursive nameserver bound to localhost, I hadn't yet put 
specific thought into where in the installer, if at all, it would 
make sense to ask and to offer that enhancement.

I don't currently have time to ponder those specifics, but certainly 
on some screen or other it would be perfectly feasible to offer that as
a checklist item.  Season to suit with '(Make sure you know what you're
doing)' advisories if you honestly think this causes significant failure
modes, which in my mere 35 years as a Unix admin have been nonexistent
other than captive portals on some hotel wifi except in one or two
client sites with such stiflingly severe border firewalling that damned
near nothing could talk to outside.  But we'll get to those latter
situations, below.


> > I don't mean to sound hostile, but _what_ administrative attention?
> 
> I already stated that selecting forwarders might be required to let the DNS
> server work in a given environment.  In all the telco datacenters where I
> operated internal nodes where not allowed to perform recursive queries on
> their own.

Thank you for clarifying that by 'a local recursive DNS server needs
some administrative attention', you do not actually mean attention to
the software at all.  You mean situations where outbound access to port
53 on the outside Internet has been artificially blocked.

This is not what most people mean when they say 'needs some
administrative attention'.  

When you say 'selecting forwarders might be required', this describes a
rare -- and somewhat contrived (IMO) -- example situation where a
recursive nameserver has been, in essence, artificially forbidden from
functioning as a normal recursive nameserver, except by handing off all
outbound queries to a _different_ (corporate-blessed) recursive
nameserver that has a gateway ACL permitting _it_ to open sockets to 
arbitrary outside port 53.  Which situation is one where operating 
a recursive nameserver on the host being installed is pointless because
there already is a local recursive nameserver.

So, to sum, it turns out that your example of the claim that 'of course
a local recursive DNS server too needs some administrative attention'
turns out to be a situation where a local recursive DNS server doesn't
make sense.

Aha.

I don't think we would reasonably say 'Of course a Web browser too needs
some administrative attention' just because some networks don't permit
outbound sockets to 80/tcp on outside servers without configuring the 
client Web software to send all outbound queries to a designated proxy
IP.  I mean, such situations do exist, but making that claim without
explaining in the next sentence what specifically you mean would be 
playing disputation games rather than having a conversation.



> [...]