Re: [DNG] ntp setup
Quoting Olaf Meeuwissen (paddy-h...@member.fsf.org): > I think it's fair to point out that systemd-timesyncd only promises > Simple NTP (SNTP). How good a job it does of that is another matter > but at least it explains some of the "quirks" you mention below. Put that way, fair point. _But_, the larger context is that a systematically better job of time sync, using better code and also (in the case of ntimed-client), _smaller_ code, can be performed instead, gaining all the advantages of a real NTP client. Or, to put it a different way, with several excellent genuine NTP clients to choose among, I deny the existence of a compelling use-case for any SNTP client, let alone one that's more than a little slipshod. (systemd-timed's security history, which I didn't get into, is less than reassuring.) The SNTP protocol is what Windows users settle for, because that's what they're offered by defaul, and mostly they don't know that they're missing out. On Linux, we don't need to settle. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ntp setup
Cheers, Grammarian's bar joke #22: The past, present, Rick Moen and future walked into a bar. It was tense. r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Multiple resignations from Freenode's staff ??? New drama shake the opensource
Quoting Bernard Rosset via Dng (dng@lists.dyne.org):
> Thanks Rick, for this lighthearted take on this!
> Very much welcome and appreciated on my part.
Yr. very welcome.
> This actually is the "dream" of any infra person facing a relentless
> ego-bloated hijacker above in such a situation.
I was part of a Linux effort that went through this, when I was a senior
editor for the online monthly magazine Linux Gazette. Our founding
editor John M. Fisk, MD had, around issue 4, accepted a kind offer from
SSC, Inc. (at that time publishers of Linux Journal) to provide Web
hosting for the magazine. Many years later, SSC, Inc. announced without
consulting the magazine staff that it would be turning the
linuxgazette.com Web site into a continuously evolving Drupal site
without magazine issues or an editor. (SSC's newly hired webmaster just
happened to be a Drupal enthusiast.)
The magazine staff found this didn't meet the magazine's needs and moved
to new hosting the staff themselves built and paid for, at
linuxgazette.net . To our surprise, SSC, Inc. objected bitterly,
claimed to own the branding (hence, trademark) rights to Linux Gazette
(a claim I later eviscerated by checking with Dr. Fisk), and threatened
us with trademark litigation and UDRP proceedings.
Unfortunately for SSC, several members of the Gazette's staff including
me had a working knowledge of trademark and other tort law, we politely
called their bluff, and... nothing happened. Despite numerous people
telling us very emotionally that we needed to capitulate and beg for
mercy, it turned out that SSC, Inc. had no leverage and no plausible
cause of action, and merely made a lot of noise (and attempted a USPTO
trademark registration, which failed for bad drafting before we could
even file opposition[1]). The magazine continued healthily for many years,
until it finally collapsed for unrelated staff reasons.
The people on LWN.net's reader feedback forums who confidently told me,
when LWN was covering SSC's legalistic blustering, that my analysis of
SSC's position being a paper tiger was delusional on my part, that I
needed to surrender instantly, that I was only a technogeek and should
meekly give in to the demands of an actual corporation, etc., somehow
never got back to me to say I was correct and to apologise. Funny about
that.
FWIW, long ago, I wrote a mostly popular essay about the history of
forking in software projects:
http://linuxmafia.com/faq/Licensing_and_Law/forking.html
{1] I pointed out at the time that, because Linux Gazette was a
completely non-commercial magazine, even completely valid trademark
rights, being enforceable only in commerce, would be toothless to
prevent our continuing to use our name. In addition, when I wrote to
Dr. Fisk and asked if he'd assigned any commercial rights to SSC
pursuant to the hosting offer, and he said "absolutely no", that killed
SSC's trademark-based monopoly effort stone-cold.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Multiple resignations from Freenode's staff ??? New drama shake the opensource
Quoting Dimitris via Dng (dng@lists.dyne.org): > there are lawyers-threats involved and he took infra too. so it's > not that simple/light as you're presenting it. > announced here as well : https://twitter.com/freenodestaff As always, persons involve will need to judge for themselves whether legal inevitable blustering must be paid any attention at all, and what attention if any. It is extremely common to threaten vaguely described tort action against software and project forks, by the way. You have not bothered to state what your point is. So, I provisionally conclude that you don't have one beyond "the person is making vague legal threats against departed staff", which is of course exactly what one expects in this situation. And? (Actually, no. I'd rather you not tell me. Yes, I know that computer geeks throw their handkerchiefs and have a fainting spell when someone issues bushwah tort threats, even when those threats aren't against them. I just don't think this mental aberration warrants my time.) > what's most troublesome is that thousands of user data passed > control without any info/consent.. to the crown prince - mt gox > scammer(!) If you don't wish to have the association between your IRC nick and your e-mail address, which ISTR is the entirety of what this term "thousands of user data" refers to, then go tell Freenode's NickServ to "DROP" your nick. (Personally, I think that's pretty feeble 'user data'.) Anyway, the above has no obvious connection to the prior discussion, but you do you. > p.s. most of the "spelling" paradigms you wrote, are not like that.. > but probably OT.. (1) It's a metaphor. Obviously. (2) In every case I cited, the core concept I spoke of applied, that in essence the project continued but left the old name behind. The point is that this is a frequent and somewhat normal pattern in software, and part of the grand tradition to fork if necessary in order to get away from something that stands in the way of the project. My point should be self-evident, so I don't intend to waste time arguing with you just because you wish to debate the self-evidently true. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Multiple resignations from Freenode's staff ??? New drama shake the opensource
Quoting Ludovic Belli??re (belliere.ludo...@proximus.be): > What does it means for devuan? It's a spelling change! 1996: NCSA HTTPd is now spelled "Apache HTTPd" 1997: gcc is now spelled "egcs" (which then got called gcc, again) 1991: GNU libc forked as Linux libc, and then, 1998: Linux libc is now spelled "GNU libc" again. 2003: XFree86 is now spelled "X.org" 2002: Open Projects Network is now spelled "Freenode" 2006: Kanotix's leading edge is now spelled "Sidux" 2010: Sidux is now spelled "Aptosid"[1] 2012: OpenOffice[.org} is now spelled "LibreOffice" 2014: Solaris is now spelled "Illumos" 2021: Freenode is now spelled "LiberaChat" See? It's all about spelling reform. It appears that Mr. Lee's corporate entity "freenode Limited" has, at least for now, Registrant status for three Internet domains, freenode.net/org/com. Mr. Lee appears to have no other assets relevant to what until now was called Freenode and, probably by the end of Thursday, his time, his three Internet domains will point to no Internet infrastructure, as it will all disaffiliate and reconstitute itself as "LiberaChat" -- as is happening in real time as I write this. [1] This sound familiar? "A press release dated September 11 came to the community's attention Monday, September 13 of the renaming or, as some reported, a fork of sidux to aptosid. Due to conflicts with the commercial backer of the Debian-based distribution, sidux developers have separated themselves from the Sidux e.V. association to continue developing aptosid on their own." https://www.linuxjournal.com/content/sidux-developers-provide-clean-upgrade-path-aptosid ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?
Quoting marc (marc...@welz.org.za):
> Hello
And almost certainly goodbye. But before that:
> > It's irrational to talk about rootkits as if they were a security threat
> > (and my apologies in advance if, as seems likely, you're fully aware of
> > the difference; in these discussions, there will always be other readers
> > who don't.
>
> Apologies accepted :)
You know what's really tragic, here? I was trying to be nice -- since
your wording had left it very unclear whether you actually thought
rootkits are an attack vector. I said it's likely you didn't, being
generous of spirit, and apologised if that were the case -- an
obvious pro-forma apology, as a way to be nice. It would, of course, be
obvious that I had objectively offered no offence, therefore I wasn't
actually apologising, just trying to be nice about your unclear wording.
But hey, if you want to be ungracious, and act like you don't want to be
friends, I guess you do you.
> > By definition, a rootkit is a set of coverup tools installed by an
> > intruder _after stealing root via other means entirely). The point is
> > that focussing on what bad guys do after they broken into your system
> > and cracked the root account is largely a waste of time: After they
> > have completely broken security, they can do anything at all, and what
> > particular thing they choose do isn't very interesting -- or relevant
> > to system administration. What _is_ interesting and relevant is how
> > the bad guys got in and how they escalated privilege to root. And those
> > questions are the ones relevant to system administration.
>
> Well, yes and no. Of course if the system is fully compromised, then
> all bets are off. It does also mean that if a bad guy has broken into
> a system with writable {disk,graphics,nic,bios} firmware, then the only
> safe response is to throw away the hardware (owners of RPIs earlier
> than v4 only need to throw away the sd card).
You purport to disagree with what I said, but then throw out a lot of
word salad that doesn't address it.
I'm going to ignore that and move on.
> However, most system administrators don't do that. At best they reformat,
> cross their fingers and continue.
Anyone who does that, I'd fire.
> And you will note the current rootkit under discussion has two modes - a root
> mode where it pretends to be a systemd component, and a userlevel mode where
> it pretends to be a bit of gnome.
Completely irrelevant to what I was saying.
> But more importantly: This is a mailing list for a distribution, and
> distributions are where supply chain attacks can (or might already have)
> happen(ed).
A tautologically true but also totally useless observation.
> Some people subscribe to "with sufficient eyeballs, all bugs are shallow",
> others to "three people can keep a secret, if two are dead". Interestingly
> both apply - the latter when talking about who has access to the build
> infrastructure...
Another totally useless observation -- and also completely irrelevant to
what I said. _If_ you know anything about distros with competent build
infrastructures (including for example Debian), you will know that it is
for obvious reasons accessible only to the most highly trusted people.
Unless one of those happens to be Moriarty the Napoleon of Crime,
authors of *ix ELF infectors, rootkits, UDP-based backdoors, etc. can
dick around with their creations all day long and not be able to
compromise the package collection via the build infrastructure.
> There is always a first time (or a time of first discovery).
Send a telegram.
And I believe I'm done. Run away and play elsewhere, sonny. I'm busy.
[rest snipped per the Law of Diminishing Returns]
--
Cheers,There are really only two hard problems in computer science:
Rick Moen o Cache invalidation policy.
r...@linuxmafia.como Name-space management.
McQ! (4x80)o Off-by-one errors.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?
hen-employer: http://linuxmafia.com/faq/Security/breakin-without-remote-vulnerability.html If you were to speculate that my employer was VA Linux Systems and that the embarassing theft of a token happened when a VA sysadmin ssh'd out to shells.sourceforge.net (a shared public host that he didn't know someone had rooted), and then ssh'd or scp'd back into the sensitive corporate network, I would say "Hmm, no comment.' -- Cheers,Grammarian's bar joke #16: A run-on sentence walks into a Rick Moen bar it starts flirting. With a cute little sentence fragment. r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?
Quoting Dr. Nikolaus Klepp (off...@klepp.biz): > And there's alway the possibillity of 3rd party software, e.g. Teams, > Appimages, ... Always. Looking from a distro-management perspective, doing that falls into the broad category of "User circumvents the distro's management regime", and naturally any result, good or bad, can follow. But by definition, that is not a distro problem, and there is basically no way of absolutely preventing a naive admin from shooting at his or her foot -- at least, not short of providing Tivoised appliances rather than general-purpose, open source distros for general purpose computing. -- Cheers, Grammarian's bar joke #20: The subjunctive Rick Moen would have walked into a bar, had it only known. r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?
Quoting Arnt Karlsen (a...@iaksess.no): > ..very true. Are there ways to trick common Devuan installs > into automatically installing these bad things? > (Other than tricking newbie etc users, sysadmins etc into > doing it?) I don't see any particular structural accidents waiting to happen, above and beyond the norm in Unix. (OTOH, I don't spend a lot of time studying Desktop Environments. Someone else might do a better job at spotting, e.g., software structures likely to lull unwary desktop users into carrying out dangerous actions.) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?
Quoting Arnt Karlsen (a...@iaksess.no): > On Fri, 30 Apr 2021 14:37:20 +0200, Arnt wrote in message > <20210430143720.7311bc82@d44>: > > > > https://www.theregister.com/2021/04/29/stealthy_linux_backdoor_malware_spotted/ > > > > ..how it works: > https://blog.netlab.360.com/stealth_rotajakiro_backdoor_en/ Answer: Avoid installing and running it. This isn't any kind of intrusion tool, just yet another backdoor program that can be installed and activated after intrusion through other means entirely -- indistinguishable except in fine detail from countless others that have existed for decades. And _TheReg_ was very clear about that: The malware is not an exploit; rather it's a payload that opens a backdoor on the targeted machine. It might be installed by an unsuspecting user, an intruder, or through a dropper Trojan. How RotaJakiro has been distributed remains unanswered. So, there ya go: Avoid installing and running it. It's called system administration. -- Cheers, Grammarian's bar joke #26: A gerund and an Rick Moeninfinitive walk into a bar, drinking to forget. r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] connection manager as dns resolver?
Quoting Hendrik Boom (hend...@topoi.pooq.com): > Looks as if the connection manager is taking over dns. > > Who knew? And whom does it talk to? Does it contain its own recursive > DNS resolver? Or does it just pick up on the DHCP signals it gets from > elsewhere and take over? connman (which I don't use, and have only read about) does _not_ appear to include a recursive nameserver. https://launchpad.net/connman The data you've posted so far that I've read in this thread (but I haven't caught up with the full thread, yet) seem bizarre, in suggesting that connman itself is hogging port 53 on localhost -- which would definitely mean either it's handling any recursive requests or nothing is. I'd have been extremely surprised if any connection management utility had an integral recursive nameserver. The latter are complicated projects, which is why there have been relatively few successful ones. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] rm not freeing space (SOLVED)
Quoting Marc Shapiro via Dng (dng@lists.dyne.org):
> On 3/19/21 8:31 PM, tempforever via Dng wrote:
> >
> >To find files last modified in January:
> >(adjust the dates as needed; on Mar. 19 this should locate files dated
> >Jan 1 - 31 but it could be off a day or so)
> >
> >cd /media/archives
> >find -type f -mtime -78 -mtime +46 -ls
>
> Thank you!
>
> That found the files. They were in a hidden directory
> '/media/archives/.Trash-0'.
Aha! For your future convenience, here is a Perl script I get a lot of
use from, when looking for the (individually) largest files within $PWD
and its subtrees:
:r /usr/local/bin/largest20
#!/usr/bin/perl -w
# You can alternatively just do:
# find . -xdev -type f -print0 | xargs -r0 ls -l | sort -rn -k +5 | head -20
# Sometimes also handy: du -cks * | sort -rn
use File::Find;
@ARGV = $ENV{ PWD } unless @ARGV;
find ( sub { $size{ $File::Find::name } = -s if -f; }, @ARGV );
@sorted = sort { $size{ $b } <=> $size{ $a } } keys %size;
splice @sorted, 20 if @sorted > 20;
printf "%10d %s\n", $size{$_}, $_ for @sorted
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Is RSA broken? Or is it a hoax?
Quoting Mike Tubby (m...@tubby.org): > Try this: > https://www.schneier.com/blog/archives/2021/03/no-rsa-is-not-broken.html Thanks, yes. Among the telling points made; The most important point from the StackExchange discussion is that if Schnorr could “destroy RSA”, he would have destroyed one of the RSA Challenge problems to prove it. He did not. Schnorr is a real cryptologist and a real mathematician, though. This isn't a hoax; it just remains to be seen to what degree its claims check out in practice, and whether the maths prove valid when peer reviewed. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Is RSA broken? Or is it a hoax?
I wrote: > > https://eprint.iacr.org/2021/232.pdf > > Snakes. Oil. (**COUGH** Theranos **COUGH**) > We've been here before with Crown Sterling. Sorry, I take that back, having just assumed this was the Crown Sterling guys (again). The current claim is _not_ from Crown Sterling but rather from serious mathematician and cryptographer Claus Peter Schnorr, who claims that prime factorization can be reduced to a much less intractable ‘shortest vector’ problem. My offhand reaction is that Schnorr's claim of greater efficacy has not yet been comprehensively demonstrated much less proven, so we will have to see whether the alleged advance in cryptoanalysis proves out in the real world. As this paper is only two days old, that skeptical evaluation has only now just started. (I haven't worked on number theory in decades, and so cannot comment even if I hadn't just now cracked open the abstract of Schnorr's paper.) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Jitsi-meet server in DMZ
Quoting Mike Tubby (m...@tubby.org): > You'll be lucky of Jitsi works well with NAT due to the nature of > NAT-encumbered protocols like SIP and RTP. Yeah, the server end of Jitsi Meet really needs to be on a public IP address, not behind NAT. You cannot expect the latter to work reliably, and would just need to do it again the right way. -- Cheers, "The market can stay irrational longer than you can stay solvent." Rick Moen --- John Maynard Keynes (attr.) r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Is RSA broken? Or is it a hoax?
Quoting Bernard Rosset via Dng (dng@lists.dyne.org): > This is what the last line of the abstract claims; however the whole > paper goes beyond my understanding. > > https://eprint.iacr.org/2021/232.pdf Snakes. Oil. (**COUGH** Theranos **COUGH**) We've been here before with Crown Sterling. https://www.schneier.com/blog/archives/2019/09/crown_sterling_.html https://www.schneier.com/blog/archives/2019/09/the_doghouse_cr_1.html About the video where Crown Sterling CEO Grobert Grant ran a cooked demonstration of Grant's claimed crypto-cracking algorithm (the stuff talked about in the paper): Ars shared the video with Jake Williams, the founder of Rendition Infosec and a former member of the National Security Agency's Tailored Access Operations group. "I'm dumber for having watched that," Williams said. "Bragging that you can factor a 256 bit RSA key in 2019 is like bragging about hacking an unpatched Windows 2000 box. Sure you did it, but nobody should care." The 256-bit key, Williams said, was "absurdly small." (Digital certificates from recognized certificate authorities have used RSA 2048-bit keys for more than seven years.) https://arstechnica.com/information-technology/2019/09/medicine-show-crown-sterling-demos-256-bit-rsa-key-cracking-at-private-event/ > Any way, pushing for ECDSA or even EdDSA, both of which are more and > more supported out there (and have been for a almost a decade > already), is IMHO the most future-proof take. Maybe. A counter-intuitive aspect of crypto is that older (if still not significantly flawed) algorithms and their implementations are often preferable than newer and theoretically more-promising ones -- because the former have withstood determined and expert attacks for longer. Schneier made this point a few years ago about why he felt that Blowfish is still safer than Twofish, even though he felt the latter is technically superior -- because it was too new to be nearly as battle-tested. (And, again, don't forget that weaknesses in the implementation matter as much or more than theoretical weaknesses in the algorithms themselves. Cracking is cracking, no matter whether it was achieved through exploiting unintended side-channels or anything else.) -- Cheers, "My generals are always right about other people's Rick Moenwars and wrong about our own." -- LBJ r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Motel wifi: was web conferencing software
Quoting Simon Hobson (si...@thehobsons.co.uk): > That latter point means that you go to https://myfavouritewebsite.com > and no you don't get the portal page - you get a certificate warning. > Given that most people these days will have https URLs cached in their > browser, you have to manually and explicitly try and connect to a site > (doesn't matter what, any random URL will do) over HTTP. Counter-tactic: If you're in a place (hotel, motel, conference centre) where you suspect there might be a captive portal, fire up first an _alternate_ Web browser (after temporarily disabling one's bespoke choice of DNS nameserver IP), and try to load something, to see if the captive portal page shows up. After navigating any captive portal, switch to your production-use Web browser. Equivalently (I think?), use a private-browsing tab for the first page load. -- Cheers,Foursquare is for people who wish they were Sims. Rick Moen-- @kellyoxford r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] I kinda sorta got opennic DNS working
Quoting Steve Litt (sl...@troubleshooters.com): > What's the problem? I'm now resolving with some opennic servers. Later > I'll actually make a separate root.hints for opennic, and one for the > regular servers (which might be updated with my next Unbound update). Glad it's working for you. Earlier, it seemed like you were in trouble, and also that OpenNIC's instructions for Unbound suggested an approach different from what you then had. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] I kinda sorta got opennic DNS working
Quoting tito via Dng (dng@lists.dyne.org): > To be honest you advised me: > > me: Hi, > can this opennic.cache file be downloaded freely or do > you need to register? > > You: As mentioned, I have not experimented with alternative DNS roots in > decades. > > I could try to answer your question for you, but, seriously, if you are > going to start experimenting with advanced DNS topics, you really need > to be prepared to do basic data-discovery for yourself at _bare_ > minimum. If you are not, I would advise staying away from such matters. Yes, I did _also_ give the same general advice to you that I gave to Steve. If you interpreted that as advising you to not experiment with software, -- of all things -- then you badly erred. Anyway, this is not even remotely of interest. Please go away. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] I kinda sorta got opennic DNS working
Quoting tito via Dng (dng@lists.dyne.org): > On Wed, 10 Mar 2021 19:38:35 -0800 > Rick Moen wrote: > > > Quoting Dimitris via Dng (dng@lists.dyne.org): > > > > > https://wiki.opennic.org/tier_2_unbound > > > > > > eg. for opennic root servers : > > > # dig . NS @161.97.219.84 > root.hints > > > > Yeah, I _vaguely_ recall (after not paying attention to such matters > > for some decades) that their alternate root servers supply records > > for the consensus TLD nameservers along witn other ones. But, point > > is, people need to follow directions carefully, and also not play > > with this stuff unless/until they are quite sure they know what they > > are doing and are prepared to do relevant diagnosis if necessary. > > This is a circular argument. How do you get prepared If you > don't start playing with stuff. D00d. My friend Steve Litt is an intelligent guy, but he is relatively new to DNS administration, and IMO ought to learn the basics of that field of knowledge better before jumping into advanced, experimental configurations. Your presupposition that I advised Steve to not play with stuff is both epically absurd and also actively annoying. Go away, seriously. You are either trolling (badly) or having some comprehension problem that I really don't wish to deal with. -- Cheers,My pid is Inigo Montoya. You kill -9 Rick Moen my parent process. Prepare to vi. r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Opennic
Quoting Gabe Stanton via Dng (dng@lists.dyne.org): > I'll be blunt as well. I think this argument is a strawman because you > lumped opennic in with other dns providers and dismissed them That is not what I said. Your reading comprehension isssues are not my problem. > > > You made a case for another possibly good alternative for dns > > > providers as oppposed to opennic > > > > That's not what I said. > > Uh okay. Here's the quote. If you weren't talking about a hypothetical > alternative dns provider here, then I'm not the only one here that's > confused. I wasn't talking about OpenNIC _at all_, there. I was pointing out that contractual privity gives one theoretical legal advantages (but not very generally useful ones). I am not responsible for your erroneous readings. > You lumped opennic in with cisco, google, and various others is what > you did. I'm not sure where your misunderstandings are coming from, but I'm really not interested. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting tito via Dng (dng@lists.dyne.org): > > Forgive me, but it's rather late at night in my time zone, and I am > > not at peak alertness, _but_ my guess is that Unbound got set up > > somehow configured to forward outbound recursive queries to those > > entities, leaving me perplexed about why anyone would do that. > > Just by following one of the many tutorials out there. > Initially I was just interested in using dns to filter out adservers > and the like. OK, sure. When I first encountered Unbound, I noticed that (like pdns-recursor) it functioned extremely well without any modification at all, by default, as a high-performance, high-security standalone recursive server, and it just hadn't occurred to me to go out of one's way to turn it into a forwarder. (I mean, if all you want is a forwarder, you can just use dproxy, pdnsd, or Dnsmasq, which are simpler and don't have recursive code.) On the other hand, if you want a fully autonomous recursive nameserver, then _don't_ configure it to forward all queries to some outsourced recursive nameserver elsewhere, but rather let it do its job, as implementing the RD (recursion desired) bit makes handling of queries faster and smarter. In case the reasons why aren't obvious, I tried to cover this humourously in my piece "The Village of Lan: A Networking Fairy Tale": http://linuxmafia.com/~rick/lan.html -- Cheers,My pid is Inigo Montoya. You kill -9 Rick Moen my parent process. Prepare to vi. r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Opennic
Quoting Gabe Stanton via Dng (dng@lists.dyne.org): > Of course using a local (or controlled by you) caching dns resolver > ENHANCES privacy. You really should have stopped there. > That's not even a question and doesn't represent a > real argument against the likelihood that, in the case of everyone > running their own caching resolver, that second level nameservers would > end up being a very good source of info to match dns requests to ip > addresses, to be exploited just as any other big dns provider is likely > to do. Again, I get the impression, to be blunt, that you don't have a realistic understanding of how typical patterns of authoritative nameservice data and caching work. Spend some time logging and studying your recursive nameserver's traffic to TLD nameservers given caching and try to estimate how revealing that data is. You seem to think "very revealing". In which case, plainly there is no basis for further discussion, and I wish you good luck in your further endeavours. > I'm open to any information you have [...] Nope. You'll need to chew up someone else's time. > You made a case for another possibly good alternative for dns providers > as oppposed to opennic That's not what I said. > ...but I didn't hear any rebuttal to any of my > arguments in their favor. I'm sorry, but (1) I don't work for you, and (2) I clarified tnat _all_ I said was that outsourcing recursive DNS to OpenNIC recursive servers was a bad idea for the same reason outsourcing it to anyone else is. You ignored that, and are now wasting your time and mine. I am ending that. > So, here are the good points about opennic. Irrelevant to what I said. Which fact you are ignoring, and thus wasting my and everyone else's time. I am ending (at least) the former. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting wirelessduck--- via Dng (dng@lists.dyne.org): > Au contraire, I’m running unbound right now on my laptop. There are > some situations though where it’s not feasible to run one's own > recursive DNS resolver, such as a home router for non-technical people > that doesn’t support ddwrt/openwrt. On the basis of decades of experience, I deny the premise. > Unfortunately the current version of unbound packaged in Debian/Devuan > has an annoying bug when running under non-systemd+apparmor. > https://bugs.debian.org/947771 I'm minutely familiar with this fact. Fortunately for Devuan admins, they can either hotfix Unbound or use any of several other commodity recursive-only DNS nameservers, all of which I catalogue at http://linuxmafia.com/faq/Network_Other/dns-servers.html . Nota bene: I accept zero responsibility for ensuring that any or all of those recursive-only nameservers is binary-packaged for the current, past, or future releases of Devuan. I note in passing the fact that, if necessary, "./configure; make; make install" is not broken. > I attempted to install knot-resolver as an alternative but it appears > that the upstream packages have gained a hard dependency on systemd. Case in point. > MaraDNS/Deadwood packages in Debian are still using a release from > 2015 _Second_ case in point. > ...so I guess I’ll be trying powerdns-recursor next as that package > appears to be reasonably up to date. Whatever works for you. But local packages/compiles are also a thing. As the guy who wasted a metric lot of time futilely hating me on the Internet, Prof. Daniel J. Bernstein, memorably observed: "This is Unix. Stop acting so helpless." ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] I kinda sorta got opennic DNS working
Quoting tito via Dng (dng@lists.dyne.org): > then please just don't do it. You are under no obligation to answer, > As we say in Italy: "To ask is allowed, to answer is a courtesy", > but once you take the time and effort to answer then it would > make more sense to me to share your knowledge rather than > tell me why you don't want to share it. Distinguo: I didn't raise this topic. IIRC, Mr. Steve Litt suddenly asked about it. The advice I gave, in response, was (I'm pretty sure) correct and useful. You're welcome, by the way. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] I kinda sorta got opennic DNS working
Quoting Dimitris via Dng (dng@lists.dyne.org): > https://wiki.opennic.org/tier_2_unbound > > eg. for opennic root servers : > # dig . NS @161.97.219.84 > root.hints Yeah, I _vaguely_ recall (after not paying attention to such matters for some decades) that their alternate root servers supply records for the consensus TLD nameservers along witn other ones. But, point is, people need to follow directions carefully, and also not play with this stuff unless/until they are quite sure they know what they are doing and are prepared to do relevant diagnosis if necessary. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] I kinda sorta got opennic DNS working
Quoting tito via Dng (dng@lists.dyne.org): > Hi, > can this opennic.cache file be downloaded freely or do you need > to register? As mentioned, I have not experimented with alternative DNS roots in decades. I could try to answer your question for you, but, seriously, if you are going to start experimenting with advanced DNS topics, you really need to be prepared to do basic data-discovery for yourself at _bare_ minimum. If you are not, I would advise staying away from such matters. I am _not_ prepared to spoon-feed novices on such topics. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting tito via Dng (dng@lists.dyne.org): > Hi, > just for fast information, is it enough for unbound to remove: > > forward-zone: > #forward-first: yes > name: "." > forward-tls-upstream: yes > forward-addr: 1.1.1.1@853#cloudflare-dns.com > forward-addr: 1.0.0.1@853#cloudflare-dns.com > forward-addr: 8.8.4.4@853#dns.google > forward-addr: 8.8.8.8@853#dns.google > forward-addr: 9.9.9.9@853#dns.quad9.net > forward-addr: 185.222.222.222@853#dns.sb > forward-addr: 185.184.222.222@853#dns.sb Answer below. > Makes it sense to keep: > > server: > tls-upstream: yes > tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt On that: yes. On the former question, er, I'm actually a bit non-plussed about why those forwarder lines are in your configuration file in the first place. Forgive me, but it's rather late at night in my time zone, and I am not at peak alertness, _but_ my guess is that Unbound got set up somehow configured to forward outbound recursive queries to those entities, leaving me perplexed about why anyone would do that. That having been said, I personally would definitely _not_ want to have that configuration detail in my recursive nameserver state, without an extremely compelling reason, because doing that appears to largely defeat the entire purpose of running one's own recursive nameserver. Analogously, it would be like setting up a fully capable SMTP smarthost on a stable public IP address with free routing to 25/tcp anywhere in the world, but then configuring it to forward all outbound SMTP traffic to an untrustworthy ISP external mail host. Which would lead one to wonder, why? I hope that helps. I have no idea what else you might have in your configuration that ought not to be there, obviously. > I ask because after reading the thread I've tried on one > of my home's net dns servers and it worked (I could browse the web) > but browsing speed was noticeably slower, does it improve > in the long run or do we have to choose between > privacy and speed? I'm seriously not sure why operating a local recursive nameserver would be expected to reduce speed. Obviously, at initial startup of that process, it has nothing yet in cache and needs to do some queries of often-used FQDNS, but I would expect that it would very quickly improve DNS performance over _any_ nameserver on the far side of your uplink, because obviously your speed of local DNS resolution is really fast relative to your uplink, right? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting Gabe Stanton via Dng (dng@lists.dyne.org): > In the absence of a "community of dns server operators and users", is > the optimal option to have everyone run their own recursive server? But > then the upstream servers still get the birds-eye view and will very > likely abuse that information like the big companies do now. Please pardon my being blunt, but I don't think you have a realistic understanding of how typical patterns of authoritative nameservice data and caching work. I rather suspect you haven't stopped to think about that. Let's say I run a local recursive DNS nameserver on my local LAN for use by my and all other local hosts. For the sake of discussion, let us assume that it has what is misleadingly called an 'ICANN' root hints file. At service startup time, the instance starts getting and caching TLD, SLD, etc. authoritative data and caching it for the duration of TTLs. Right, now, kindly tell me where on the planet is the network node that provides a "birds-eye view" of query traffic processed by my recursive server? The root nameservers? Nope, not hardly. All they have is the hits where my nameserver followed the RD-bit-marked queries to find various TLD nameservers. TLD zones' nameservers? Nope, not hardly. They have only analogous logfile data when my nameserver first located and then cached information about SLD nameservers. In fact, the very fact that I am operating a recursive nameserver means that I have greatly impoverished every possible spying vantage point. The best of the bad choices in places to spy on my network's port-53 activity is thus right on the far side of my network uplink, at my local bandwidth provider. And, even there, because of pervasive caching, even my uplink has extremely poor data about what the machines on my local LAN are looking up. Ideally, one has a contractual relationship with a reputable good provider who looks after customer interests in accordance to local business practices and law, such as (to cite the USA local legal concept) the implied covenant of good faith and fair dealing. However, that contract concept is (naturally) not a shield for privacy but rather a cudgel to wield in civil litigation, so the best thing to do is to limit what your immediate uplink can learn about your network traffic. Various crypto schemes help limit that data, but -- my point -- so does operating a local recursive nameserver, rather than outsourcing to -anyone- on the other side of the uplink. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting wirelessduck--- via Dng (dng@lists.dyne.org): > What’s the consensus on Quad9? Are they any better from a privacy > standpoint? To say again, why outsource recursive nameservice to _anyone_? You seem like a large number of people who are weirdly resistant to the notion of basic control of one's own fundamental network infrastructure and looking for some stranger to outsource the task to, and I keep wondering why the obvious alternative of running a recursive DNS nameserver instance locally isn't even considered, let alone the obvious default choice. But hey, whatever works for you. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting Dimitris via Dng (dng@lists.dyne.org): > so, i would be interested to know, if there's a privacy issue with > opennnic? I have no problem with people who decide to adopt alternate roots. What I was talking about upthread was outsourcing one's recursive nameservice to OpenNIC's public recursive nameserver IPs, or any other stranger's. Because, well, why? Recursive service is dead-easy to do with one's local computing resources, protecting one's autonomy, security, performance, and privacy just that tiny bit more. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] I kinda sorta got opennic DNS working
Quoting Steve Litt (sl...@troubleshooters.com):
> When I added four opennic root servers to my unbound's root.hints
{laughs}
Oh, you sweet summer child. Experimenting with alternative DNS roots,
eh?
It's been decades since I've done so, but ISTR that the correct way to
do that is to re-point the root-hints line in your Unbound conf file
to opennic.cache.
> I'd really like to have both icann and opennic root servers in my
> root.hints.
No, you don't.
opennic.cache should include the standard TLD nameservers.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Any interest in a Devuan Meetup in Colorado Springs or Denver? (was "GNUPGP Web of trust")
Quoting Steve Litt (sl...@troubleshooters.com): > AND the tech chops to set it up. I provided a simple copy/paste recipe. My friend Michael Paoli even scripted the entire process: http://www.mpaoli.net/~michael/tmp/2jitsi And just following the official instructions isn't actually difficult, either. "Tech chops" my great aunt. Don't be such a technopeasant. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting Steve Litt (sl...@troubleshooters.com): > If I had demanded of myself to change the root cause instead of > coathangering the symptom, I'd have needed to go to the Void Linux > developers and ask them to find a way to accommodate DNS, in a > travelling situation, without changing /etc/resolv.conf. [acknowledging your point, posted separately, that Void Linux devs could doubtless cite some way to do so, if you asked them.] > What I was trying to say was that if I wanted to change the *design* of > the system, I'd have to petition the Void Linux packagers and the (urk) > Freedesktop.org "upstream". [...] > I violently disagree with the design decision of having the likes of > wicd or NetworkManager modify my /etc/resolv.conf, at least on a > non-portable desktop. Even on a laptop, today you can DNS from 8.8.8.8 > and 8.8.4.4 anywhere you go, so there's no need to use the local ISP's > suggested DNS servers. (I'll get to the 'no need' statement further down.) I doubt you _truly_ aimed at a system redesign to the effect that "Nothing shall be allowed to touch /etc/resolv.conf except me doing 'chattr -i /etc/resolv.conf; vi /etc/resolv.conf; chattr +i /etc/resolv.conf'." Because there are legitimate reasons to do otherwise. TCP/IP-networked systems fall into two broad classes, those that are DHCP clients and those statically IPed. Statically IPed systems are the easy case, I cannot presently think of any system software sysadmins are tempted to run that would want to alter /etc/resolv.conf . That leaves DHCP clients. There are three DHCP client implementations I'm aware of for Linux. My Resolvconf page (link posted earlier) explains how to control what each does to the nameserver line(s) in /etc/resolv.conf . So, I've documented how to override and control (if desired) those system utilities' mucking about. Likewise, My page details how to do likewise with either of the two competing Resolvconf implementations (which is why the page has that name). That leaves 'network managers' like GNOME NetworkManager, wicd, and all that lot. wicd appears to invoke Resolvconf to manage /etc/resolv.conf, so see above. GNOME NetworkManager keeps its grubby paws off /etc/resolv.conf if that file's a symlink (including but not limited to use of Resolvconf, which like wicd, GNOME NetworkManager relies on). So, do that. _Or_, create /etc/NetworkManager/conf.d/90-dns-none.conf containing [main] dns=none ...and restarted the damned GNOME NetworkManager thing. Theoretically, I could research and document how to do likewise for every goshdarned ill-advised tool that occasionally mucks with the nameserver line in /etc/resolv.conf -- systemd-resolvd, netctl, an endless variety of crummy little utilities. I won't, because (1) there's no end to that, but -- more to the point -- (2) people who run crummy little utilities like that need to understand the basics of how they work. Or, here's an idea: Don't have them. I have a standard joke about the "Facebook remedy". People ask me how I solve Facebook problems, and my cheery answer is "Simple! No Facebook; no Facebook problems!" I've not needed those crummy little network-administrative utilities. If I adopted one, I'd take the trouble to research its basics, including how to _properly_ instruct it to keep its grubby little paws off the nameserver line in /etc/resolv.conf . And, by the way, sadly, no you are incorrect that "you can DNS from 8.8.8.8 and 8.8.4.4 anywhere you go": Leaving aside my being disappointed about people willingly outsourcing their recursive DNS to the second-nosiest company on the planet[1] instead of just running a local recursive nameserver, sorry, you'll find that such a setup breaks when negotiating a "captive portal" on, e.g., most hotel and motel WiFi, where crummy artificial DNS on the WAP redirects any initial HTTP query to the portal Web site, where you prove that you're an authorised user before they give your client routing to outside the service network. Overriding that nameserver instruction means you won't see the login Web page, so you won't be able to prove you're a customer, so you won't get a usable connection. The above is a vexing problem for travelers w/laptops who prefer to specify their own choice of nameserver and still use hotel/motel WiFi (and wired ethernet, actually). Best case, you have to disable your nameserver IP override long enough to navigate the captive portal, and then can put the override back. But, no, you cannot just leave your choice of nameserver IPs in place (without disappointment). [1] Nor is it any better to outsource to OpenNIC, Cisco Umbrella, Comodo, Yandex, UncensoredDNS, etc. Here's an idea: How about not outsourcing recursive DNS to anyone? It's not like it's even difficult. We've had this conversation before. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Any interest in a Devuan Meetup in Colorado Springs or Denver? (was "GNUPGP Web of trust")
Quoting Hendrik Boom (hend...@topoi.pooq.com): > On Fri, Mar 05, 2021 at 11:36:57AM -0800, Rick Moen wrote: > > More to the point, Jitsi Meet (reminder: that's its correct name) > > is open source (Apache License 2.0). All it takes to run is a computer > > with adequate RAM and a public IP address. > > AND enough network bandwidth. But less than you might think. Locally, one LUG leader stands up a Jitsi Meet instance occasionally for LUG use in a modest Qemu/KVM virtual machine on a laptop that's on his residential ADSLv1. When I was configuring the instance on Amazon EC2 for the New Zealand Worldcon (Aug. 2020), I took a number of precautions against excessive bandwidth draw, including setting the default to outbound video = off for people joining conferences. That having been said, my main worry was pegging RAM or CPU on the Jitsi Videobridge 2 component, that routes all the video whizzing back and forth. As it turned out, RAM & CPU usage as recorded on Zabbix remained quite low. I'll also mention that each connected user's video link automatically will step down resolution/framerate to reflect how much bandwidth is available. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
I wrote: > Setting /etc/resolv.conf immutable, the classic case that was the first > I saw you fall in love with, is a case in point. There are multiple > ways to ensure that a DHCP client respects and enforces your preference > of recursive nameserver, averting the need for breaking system > administration tools using the immutable bit. Forgot to add: Have documented. http://linuxmafia.com/kb/Network_Other/resolvconf.html (scroll to '3. Tweaking Your DHCP Client's Operation without Resolvconf') ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting Steve Litt (sl...@troubleshooters.com): > My philosophy: One big hammer prevents a 100 step packaging system > raindance. The Big Hammer always seems a great idea for a temporary solution. And I assume you know what the catch is with those. Every single time I've nailed down a sysadmin annoyance using the Big Hammer, it's come back to haunt me later -- and, moreover, it turned out that a further ten minutes of digging would have found a better solution that didn't cripple the system's administrative framework but would, instead, have worked with the framework. Setting /etc/resolv.conf immutable, the classic case that was the first I saw you fall in love with, is a case in point. There are multiple ways to ensure that a DHCP client respects and enforces your preference of recursive nameserver, averting the need for breaking system administration tools using the immutable bit. It has been ever thus. -- Cheers,HULK LIKE TO REMIND EVERYONE THAT "FEWER" MEAN YOU CAN COUNT IT, Rick Moen "LESS" MEAN MUST BE MEASURED. FEWER MISTAKES MEAN LESS SMASH! r...@linuxmafia.com -- @EditorHulk McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting Steve Litt (sl...@troubleshooters.com): > >On Fri, 5 Mar 2021 22:01:33 +0100 (CET) k...@aspodata.se wrote: > > >I /had/ Jitsi Meet running (w/o local turn server and jigasi) on a > >Odroid XU-4 with 2GB RAM. Tested with up to four participants and > >running quite well. Downside: The reserved memory of the videobridge is > >configured under /usr/share/ and thus is not update-proof. > > chattr +i whatever_file Beware this seductive lure towards wielding the Big Hammer, O Grasshopper. Dark is that path's attraction to any junior sysadmin, for ultimately it leads to the Way of Hemsworth and to Cheesy Dialogue. -- Cheers,My pid is Inigo Montoya. You kill -9 Rick Moen my parent process. Prepare to vi. r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Any interest in a Devuan Meetup in Colorado Springs or Denver? (was "GNUPGP Web of trust")
I wrote: > Gentle reminder: The correcct name of this A/V conferencing server > software is Jitsi Meet. The Jitsi Project has published several pieces > of software; Jitsi Meet is the best known among them. Jitsi Project codebases so far: o Jitsi Desktop aka 'Jitsi' aka 'the SIP Communicator': a VoIP and instant messaging application. This was the first project, and is now deemed mature and community-maintained. o Jitsi Meet: videoconferencing server suite leveraging IETF's WebRTC protocol suite. Components include: o Jitsi Videobridge2: media server engine, specifically a WebRTC-compatible video router or 'SFU' (Selective Forwarding Unit). Jitsi Meet always includes at least one of these. o jicofo (JItsi COnference FOcus): "focus" component required to run Jitsi Meet conferences. o Jigasi: Optional SIP telephony gateway for Jitsi Videobridge2. o Jibri: broadcaster and recorder used for saving video call recordings and streaming to YouTube Live o Jidesha: Chrome/Chomium and Firefox extension for calendar integration (formerly also did screensharing). o jitsi-meet-electron: Bespoke desktop client for Jitsi Meet, built atop the Electron engine. o jitsi-meet-electron-utils: what it says on the tin o lib-jitsi-meet: Low-level JavaScript API for providing a customized UI for Jitsi Meet. o docker-jitsi-meet: necessary tools to run a Jitsi Meet stack on Docker using Docker Compose. o jitsi-slack: Slack chat/direct messaging integration to enable starting video conferences from Slack and easily inviting Slack members to conferences. There are _lots more_, but those are the major ones. Point is, the term "Jitsi" is ambiguous, and is not the correct name for Jitsi Meet, at all. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Jitsi advice please
Quoting g4sra via Dng (dng@lists.dyne.org): > My biggest beef with Microsoft Teams, Zoom, and now Jitsi-meetthey > all omitted an essential service. What I want is (looking at you Rick > :P) a test sever which simply echo's back the incoming video\audio to > the client. As mentioned, the straightforward way to do this is using two browser tabs, each logged into the same video session, and verifying that you can see and hear yourself. However, the reason I'm posting is to provide tips about a testing site that vets your browser's ability to fully perform the WebRTC videoconferencing protocol suite: https://test.webrtc.org/ My tip: Don't be alarmed at yellow (warning) advisories like a failure of the "Reflexive connectivity" network test. I always get that result, at home, with detailed reporting as follows: [ INFO ] Gathered candidate of Type: srflx Protocol: udp Address: 96.95.217.102 [ WARN ] Could not connect using reflexive candidates, likely due to the network environment/configuration. Point is, above and similar appear to be harmless. (Web-search the detailed warning, if concerned.) However, for a functional test, there's nothing better than the two-tabs method. A more-general tip: _Please_ consider using earbuds or headphones for all Internet videoconferencing. I can't tell you how much time gets wasted on Jitsi Meet, Zoom, etc. sessions trying to figure out which participant is locally re-injecting audio echoed from his/her PC speakers to his/her nearby microphone. It's a huge waste of time. And, as one of the participants using earbuds, I can at least say 'Not it', every time that happens. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting k...@aspodata.se (k...@aspodata.se): > https://en.wikipedia.org/wiki/Comparison_of_web_conferencing_software > lists four open source systems: > > https://en.wikipedia.org/wiki/Jitsi > https://en.wikipedia.org/wiki/Jami_(software) > https://en.wikipedia.org/wiki/OpenMeetings > https://en.wikipedia.org/wiki/BigBlueButton Thank you, sir. > Anyone knows which one to choose for a smallish group (< 20 persons) ? Logically, the only people truly qualified to answer your question would be people who've setup/administered at least a large subset of the above four, or who are in close contact with someone who has. I'm not such a person; I've set up, administered, and used Jitsi Meet (only) -- and I've been a user of BigBlueButton instances used by Linux Users of Victoria (Aus.) and by Arizona Ubuntu LoCo. It would be wonderful if a qualified person is on this mailing list and can answer. Until then, I can only say that Jitsi Meet struck me as quite practical for a smallish group. The server software grabs gobs of RAM (judged by my old-school sysadmin standards), but that outcome is to be expected because it's Java. FWIW, I note that Jami does voice (SIP) and instant messaging, but not videoconferencing. The other three are generally similar WebRTC-based systems. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Any interest in a Devuan Meetup in Colorado Springs or Denver? (was "GNUPGP Web of trust")
Quoting Steve Litt (sl...@troubleshooters.com): > So while a home-grown installation is all of our goal, until then, > anything on meet.jit.si works pretty darn well, as long as your browser > is Chromium if you're on Linux. Looks like Jitsi Meet's supported browsers list has moved to https://jitsi.github.io/handbook/docs/user-guide/supported-browsers and been updated (2021-03-05, i.e., today). Firefox and Safari (versions unstated; recent isimplied) are now on the supported browsers list, as are in general mobile-device Web browsers -- the main problem case remaining being Web browsers for iOS, which was not possible before iOS 14.3 as the OS did not allow WebRTC, (Jitsi Project say they are now checking out such browsers now that OS support is there.) That supported browsers list of course implies a server running a recent release of Jitsi Meet. Obviously meet.jit.si does; third-party servers might or might not. Alternative client options include bespoke Jitsi Meet clients for iOS and Android and the Electron-based bespoke desktop Jitsi Meet client. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Jitsi advice please
Quoting Hendrik Boom (hend...@topoi.pooq.com): > Technically, it's not Chrome. I use Chromium for jitsi, zoom, Discord, > and Gathertown. I'm more than a little fond of ungoogled-chromium, for such purposes. https://github.com/Eloston/ungoogled-chromium https://ungoogled-software.github.io/ungoogled-chromium-binaries/ https://github.com/ungoogled-software/ungoogled-chromium-debian -- Cheers, And we all know the saying, which is true as well as witty, Rick Moen that a camel is a horse that was designed by a committee. r...@linuxmafia.com-- Allan Sherman, "Peter and the Commissar" McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Any interest in a Devuan Meetup in Colorado Springs or Denver? (was "GNUPGP Web of trust")
Quoting Steve Litt (sl...@troubleshooters.com): > The benefit of this list is if meet.jit.si ever dies during a meeting > or classroom, there can be a predefined list of alternate URLs to go > to. This makes Jitsi a much safer choice than I thought it was. More to the point, Jitsi Meet (reminder: that's its correct name) is open source (Apache License 2.0). All it takes to run is a computer with adequate RAM and a public IP address. BigBlueButton also has many adherents, and is generally similar (including relying on WebRTC and being open source, LGPL). -- Cheers, "2021 showed up, and told 2020 'hold my beer.'" Rick Moen -- @justinaireland r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Any interest in a Devuan Meetup in Colorado Springs or Denver? (was "GNUPGP Web of trust")
Quoting Dimitris via Dng (dng@lists.dyne.org): > a list of jitsi instances : > https://framatalk.org/accueil/en/info Ah, thank you (ευχαριστώ). I've been trying to re-find that. Gentle reminder: The correcct name of this A/V conferencing server software is Jitsi Meet. The Jitsi Project has published several pieces of software; Jitsi Meet is the best known among them. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Jitsi advice please
Quoting goli...@devuan.org (goli...@devuan.org): > I use vivaldi for jitsi (but nothing else). It just works. The proprietary Vivaldi browser is a good choice (other than being proprietary) _because_ it is based on Chromium's Blink rendering engine, hence has good WebRTC support and a decent Javascript engine. Additionally, you get to use a software product coded by Norwegians, which is always a plus. (Vivaldi Technologies, ASA is an Oslo company, and these are ex-Opera Software guys.) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Jitsi advice please
Quoting Steve Litt (sl...@troubleshooters.com): > >On 05/03 10:23, g4sra via Dng wrote: > >> > >> Can anyone recommend a browser (other than Chrome) that they know > >> works with Jitsi-meet ? Any other suggestions to fix the audio ? > > > >If you use headphones you can open two tabs to the same meeting and > >talk to yourself. > > My psychiatrist told me to stop doing that. > > At least, in public. Rumour has it that it's harmless to talk to yourself, as long as you don't _listen_. -- Cheers, "Like looking both ways before crossing the street, and Rick Moenthen getting hit by a submarine." -- Clarke Smith, age 9, r...@linuxmafia.com winner of Washington Post's contest for best description McQ! (4x80) of the year 2020 in a single word or phrase. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Any interest in a Devuan Meetup in Colorado Springs or Denver? (was "GNUPGP Web of trust")
Quoting Steve Litt (sl...@troubleshooters.com): > >In case anyone's interested in an extended and only semi-temperate rant > >on this theme: > >http://linuxmafia.com/faq/Essays/meetup.html > > I love your essay, but you were much too kind to meetup.com. ;-> I'll work on that. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Any interest in a Devuan Meetup in Colorado Springs or Denver? (was "GNUPGP Web of trust")
Quoting o1bigtenor via Dng (dng@lists.dyne.org): > Asking to confirm - - - - so Firefox won't work? Some folks have no problems with particular Firefox versions (talking to Jitsi Meet), but it's not officially recommended as per https://github.com/jitsi/jitsi-meet/wiki/Browser-support .[1] tl;dr: Jitsi Meet relies on browser support for WebRTC (the IETF videoconferencing protocol suite) and some Javascript. Reportedly, the best WebRTC report is in Chromium and browsers that are based on its Blink rendering engine. E.g.: o Chromium o Google Chrome o Microsoft Edge v. 79.0.309 or later o Brave Browswer o Opera Browser v 15 or later Firefox, some others probably work if recent, but not guaranteed. _Or_, use one of the bespoke Jitsi Meet clients, instead of a browser. Longer version: Generically, Web browsers and _versions_ of Web browsers that have good WebRTC support (and a good Javascript engine) should do well. Which is why Chromium/Blink and derivatives are a good choie. Problems with other browser types/versions including high load are sometimes reported. The Jitsi project also has mobile clients (open source) plus an odd desktop client that can, if wished, be used instead of a Web browser. My notes: o Jitsi Meet Client (28MB APK) for Android 5.0 or newer, published via F-Droid: https://f-droid.org/en/packages/org.jitsi.meet/ o Jitsi Meet Client for Android, published on Google Play Store https://play.google.com/store/apps/details?id=org.jitsi.meet o Jitsi Meet Client for iOS, published on Apple iTunes Store https://itunes.apple.com/us/app/jitsi-meet/id1165103905 o Jitsi Meet Electron client (86MB binary: Linux x86_64, MacOS, MS-WIndows), desktop client crafted as a special-purpose single application file using the Electron Javascript engine, which in turn is constructed from the Chromium Web browser and the Node.js runtime Javascript environment. https://github.com/jitsi/jitsi-meet-electron/releases [1] Browser support is a moving target. That page currently reflects status as of May 3, 2020, and may be unmaintained. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Any interest in a Devuan Meetup in Colorado Springs or Denver? (was "GNUPGP Web of trust")
Quoting o1bigtenor (o1bigte...@gmail.com): > > Care to try reframing the question? > > Quoting: > Before any asks: No, I didn't do that on Devuan because I was in a > huge hurry and had a known-good Amazon EC2 AMI of Debian 10 at my > disposal. I expect that my setup instructions will work just great on > Devuan. > > above implies that that list of instructions might be available. > > I was asking for said list. URL was in my initial posting. Once again, then: http://linuxmafia.com/~rick/jitsi.txt I hope it proves useful to you. -- Cheers, "2021 showed up, and told 2020 'hold my beer.'" Rick Moen -- @justinaireland r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Any interest in a Devuan Meetup in Colorado Springs or Denver? (was "GNUPGP Web of trust")
Quoting o1bigtenor (o1bigte...@gmail.com):
> I, for one, p l e a s e ? (!?!)
{sigh}
Care to try reframing the question?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Any interest in a Devuan Meetup in Colorado Springs or Denver? (was "GNUPGP Web of trust")
Quoting Gabe Stanton via Dng (dng@lists.dyne.org): > This is incentive for me to take another crack at getting a jitsi > instance running. It will probably take me a couple months to get one > working since time is limited and there are many things higher on the > priorities list, but I'll work on that and get back to the list when I > have that running. Here are my (raw, and I stress, _raw_) notes from setting up Jitsi Meet (on Amazon EC2, on Debian 10) in a tearing hurry for the 2020 World Science Fiction Convention (the '2020 Worldcon'), which was forced by the exploding pandemic to suddenly convert itself into a virtual event, instead of being in Wellington, NZ: http://linuxmafia.com/~rick/jitsi.txt Here's the 2020 Worldcon's (CoNZealand's) Web site. https://conzealand.nz/ The Worldcon is an all-volunteer-run, all-volunteer-staffed literary science fiction convention held annually somewhere on planet Earth (so far ;-> ). Usual attendance is about 3000 people who fly in from everywhere. A big Worldcon, like London's in 2014, is about 8000 in-person attendees. My instance of Jitsi Meet had no performance problems whatsoever for the usage CoNZealand made -- though I was prepared to spin up more instances of Jitsi Videobridge2 if necessary to share the load. Honestly, once I stopped making a couple of dumb mistakes in site configuration (preserved in my raw notes), it was pretty darned easy to configure. There are sundry site-admin customisations that can be done, which I didn't fully cover in my notes, but aren't that hard to find, and I might even be able to refresh my memory about those if you need to ask. As you might gather from my notes, I got directives from above that changed during the project about whether to try to shim in an oauth2 authentication layer (non-default) and then whether or not to configure an operating mode where only a list of people (staff) with prearranged admin credentials were permitted to create Jitsi Meet rooms. The eventual deployment did not include the latter security controls -- making it work pretty much like meet.jit.si . However, those security controls weren't difficult to do if desired. Before any asks: No, I didn't do that on Devuan because I was in a huge hurry and had a known-good Amazon EC2 AMI of Debian 10 at my disposal. I expect that my setup instructions will work just great on Devuan. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Any interest in a Devuan Meetup in Colorado Springs or Denver? (was "GNUPGP Web of trust")
Quoting Steve Litt (sl...@troubleshooters.com): > From my point of view, meetup.com has inserted itself into LUG > operations as an unneeded middle man for LUGs without an effective > publicity officer. In case anyone's interested in an extended and only semi-temperate rant on this theme: http://linuxmafia.com/faq/Essays/meetup.html -- Cheers,My pid is Inigo Montoya. You kill -9 Rick Moen my parent process. Prepare to vi. r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
Quoting Steve Litt (sl...@troubleshooters.com): > As you know, I was asking many Qemu LAN-peer questions on this list a > week ago. My documentation on the subject has finally achieved > first-draft status. If you'd like to see it, go to: > > http://troubleshooters.com/linux/qemu/nobs.htm This is a very nice piece of work, Steve, and will be endlessly useful. Thank you. -- Cheers,My pid is Inigo Montoya. You kill -9 Rick Moen my parent process. Prepare to vi. r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] OT: Lewis Carroll (was: My Qemu LAN-peer documentation is now in its first draft)
Quoting Ralph Ronnquist via Dng (dng@lists.dyne.org): > I think Lewis Carroll had a stab at this issue as well in "Through The > Looking Glass" where the name of the Black Knight was called > something... or how it was. The White Knight, but yes, exactly -- Carroll playing with what we now call the "use-mention distinction". ‘You are sad,’ the Knight said in an anxious tone: ‘let me sing you a song to comfort you.’ ‘Is it very long?’ Alice asked, for she had heard a good deal of poetry that day. ‘It’s long,’ said the Knight, ‘but very, VERY beautiful. Everybody that hears me sing it--either it brings the TEARS into their eyes, or else--’ ‘Or else what?’ said Alice, for the Knight had made a sudden pause. ‘Or else it doesn’t, you know. The name of the song is called “HADDOCKS’ EYES.”’ ‘Oh, that’s the name of the song, is it?’ Alice said, trying to feel interested. ‘No, you don’t understand,’ the Knight said, looking a little vexed. ‘That’s what the name is CALLED. The name really IS “THE AGED AGED MAN.”’ ‘Then I ought to have said “That’s what the SONG is called”?’ Alice corrected herself. ‘No, you oughtn’t: that’s quite another thing! The SONG is called “WAYS AND MEANS”: but that’s only what it’s CALLED, you know!’ ‘Well, what IS the song, then?’ said Alice, who was by this time completely bewildered. ‘I was coming to that,’ the Knight said. ‘The song really IS “A-SITTING ON A GATE”: and the tune’s my own invention.’ The plot of the White Knight song (which he goes on to sing to Alice) parodies Wordsworth's lyric poem "Resolution and Independence". ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Netiquette
Quoting g4sra via Dng (dng@lists.dyne.org): > What is the netiquette on this list for changing subject lines. > I hate hijacking threads but I also hate breaking them. > Which is the lesser of the two evils ? Standards-compliant mailers' threading doesn't get broken by altering the Subject header. (Last I heard, MS-Outlook still didn't follow the RFCs in that area, and thus gets adversely affected. Probably, some other common mailers share that defect.) In a standards-compliant mailer that relies on Message-IDs and the In-Reply-To header to arrange threading, you will continue to see a reply with changed Subject header sorted immediately below the replied-to post within the conversation's tree of postings. Therefore, changing Subject lines and breaking or not breaking threads are (or, at least, should be) orthogonal concerns. If you wish to deliberately break threading in your reply, snip out the In-Reply-To from your headers before posting. If you don't wish to, then don't do that. Either way, changing or not changing the Subject header ought to have zero effect on threading (except for MS-Outlook victims^W users). Since you're a GMail person, you _may_ find it to be non-trivial to assert control over your SMTP headers, but I wish you good hunting, on that. I'll be polite and not say how I prefer to cure GMail problems. (It's very similar to how I cure Facebook problems.) Personally, I deliberately break the thread by snipping In-Reply-To (or use mutt's new-message command, which amounts to the same thing) if the new discussion will be semantically quite different from the old one. OTOH, if I'm just adjusting the Subject header to account for topic drift, I don't break threading because I regard it as part of the ongoing conversation. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to firewall on Devuan?
Quoting Patrick Bartek via Dng (dng@lists.dyne.org): > I've been using ufw for years. It's a commandline front-end for > iptables. There's also a GUI for it, too. For people's convencience, that would be gufw, a somewhat GNOME-ish Python/GTK thingie. https://github.com/costales/gufw -- Cheers, This limerick goes in reverse. If you start from the bottom-most verse Rick Moen Unless I'm remiss, This limerick's not any worse. rick@linu The neat thing is this:-- Zach Weiner xmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Synaptics Touchpad Fn+F9
Quoting Steve Litt (sl...@troubleshooters.com): > On Sat, 6 Feb 2021 22:40:36 +0100 > Florian Zieboll via Dng wrote: > > libre Grüße, > > And don't bring me down Bruce! > > If you don't get the reference, that's OK, you need to be over 60 to > get it. I skipped that decade's pop music -- but, for the (33 1/3 rpm long-playing vinyl album-rock) record: https://ultimateclassicrock.com/electric-light-orchestra-dont-bring-me-down-bruce/ -- Cheers, "2021 showed up, and told 2020 'hold my beer.'" Rick Moen -- @justinaireland r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Synaptics Touchpad Fn+F9
Quoting Steve Litt (sl...@troubleshooters.com): > > as you replied off-list and I don't know of any better way, I bring > > the issue back to the list: Perhaps someone has a hint on resetting > > the device, if you'd reveal its make and model? > > > > Another idea out of thin air: Did you remove the CMOS battery - or > > does the notebook provide a button (or pins) to reset the bios > > password? > > > > libre Grüße, > > Florian > > > > The following shellscript, called touchtoggle.sh, should do what you > need. > > == > #!/bin/sh > > # touchtoggle.sh Copyright (C) 2019 by Steve Litt > # All rights reserved. > # Licensed via the > # Expat license: https://directory.fsf.org/wiki/License:Expat [...] It's a useful script, and thanks -- but I suggest you immediately add a second line below that 'Licensed via the Expat license' one: # Expat license's requirement to include permission notice text is waived. Otherwise, anyone seeking to redistribute your script is committing the tort of copyright violation unless he/she provides with it a copy of the ~20 lines of Expat License text. I'm pretty sure you were not meaning to impose such a legal obligation on redistributors. BTW, it's some weird FSF fetish to refer to it as "Expat License". Everyone else on planet Earth (including OSI: https://opensource.org/licenses/MIT) refers to it as MIT License. To be tiresomely pedantic, what you used is the commendably minimalist form of MIT's licence that it issued for the Expat graphics library. MIT's slightly longer wording issued attached to the X Consortium software and used (e.g.) for X.org code to this day differs only in having a sentence prohibiting users from mentioning X Consortium in advertising or promotion without written permission, and one stating that "X Window System" is a trademark of X Consortium, Inc. There is no _functional_ difference. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Need install Devuan Beowolf but got "initramfs" prompt
Quoting Steve Litt (sl...@troubleshooters.com): > It *does* list a co-author. Funny thing is, the co-author's name seems > kinda familiar, and I'm wondering where I heard his name before. I think it's actually a franchise -- like Dread Pirate Roberts. Westley:Well, Roberts had grown so rich, he wanted to retire. So he took me to his cabin, and told me his secret. "I am not the Dread Pirate Roberts", he said. "My name is Ryan. I inherited the ship from the previous Dread Pirate Roberts, just as you will inherit it from me. The man I inherited it from was not the real Dread Pirate Roberts either. His name was Cummerbund. The real Roberts has been retired fifteen years and living like a king in Patagonia." Thank you. Then he explained that the name was the important thing for inspiring the necessary fear. You see, no one would surrender to the Dread Pirate Westley. So we sailed ashore, took on an entirely new crew, and he stayed aboard for a while as first mate, all the time calling me Roberts. Once the crew believed, he left the ship, and I have been Roberts ever since. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Need install Devuan Beowolf but got "initramfs" prompt
Quoting Hendrik Boom (hend...@topoi.pooq.com): > Someone did, as I expect you already know. Here's Eric Stephen > Raymond's version: > > http://www.catb.org/~esr/faqs/smart-questions.html All I can say is that Eric Steven Raymond's version would be _much_ better with a co-author credited right at the top of the essay who is often hilariously forgotten in online mentions of the piece. ;-> (Eric spells his middle name Steven, not Stephen.) See if you can tell, reading the piece, which of its passages are in Eric's writing style and which are in that other often-forgotten guy's style. The difference of authorial 'voice' seems night-and-day to me, but -- horses for courses; à chacun son goût. -- Cheers, This limerick goes in reverse. If you start from the bottom-most verse Rick Moen Unless I'm remiss, This limerick's not any worse. rick@linu The neat thing is this:-- Zach Weiner xmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Need install Devuan Beowolf but got "initramfs" prompt
Quoting Steve Litt (sl...@troubleshooters.com): > I'm old, but I seem to remember a web page with a similar name. Years > ago, I wrote those guys who run the web page, with my patented, > always-succeeds method of getting an answer on a technical mailing > list, and those guys didn't want to put my method on their page. They > said my method was "manipulative". Those guys? They're total jerks. You should definitely never trust them; take my word for that. (One of them's a Scandinavian, and my Tante Bjorg warned me to never trust _them_.) > Because I have low self-esteem, I abandoned my method. Now, when I need > email help, I always use the same subject line: "Computer doesn't work", > and submit a 30KB or more file: Either an entire dmesg from the time it > booted last year, or five complete source files in RAR format. To make > sure I don't prejudice those who might help me, I never tell version > numbers, or whether it's Linux, Windows, Mac or BSD. If it's a > programming problem I never identify the language. I never say what I > hope to accomplish, because it's their job to tell me what I want to > accomplish. When I don't get answers, I send a whiny reminder every two > hours. When all this doesn't work, I use a web search. Your ideas are intriguing to me, and I wish to subscribe to your newsletter. https://www.youtube.com/watch?v=jXesMkAYh44 -- Cheers, This limerick goes in reverse. If you start from the bottom-most verse Rick Moen Unless I'm remiss, This limerick's not any worse. rick@linu The neat thing is this:-- Zach Weiner xmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Need install Devuan Beowolf but got "initramfs" prompt
Quoting Antony Stone (antony.st...@devuan.open.source.it): > On Monday 01 February 2021 at 21:02:34, Rick Moen wrote: > > > I think someone should write an online essay called something like 'How > > to Ask Questions the Smart Way', to help such folks. > > https://xkcd.com/927/ As the actual co-author of "How to Ask Questions the Smart Way", who accordingly gets a tonne of irony-challenged e-mail from hopelessly confused end-users with technical problems (who were pointed at our essay, didn't read it, and imagined the authors are a universal free-of-charge Internet helpdesk), sometimes I wish there _were_ 15 competing versions of our essay. -- Cheers, This limerick goes in reverse. If you start from the bottom-most verse Rick Moen Unless I'm remiss, This limerick's not any worse. rick@linu The neat thing is this:-- Zach Weiner xmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Need install Devuan Beowolf but got "initramfs" prompt
Quoting Adrian Zaugg (devuan@mailgurgler.com): > It is difficult to help, if you don't write what you exactly donwloaded, > how you tried to install, on what system etc. It is somehow like: "I ate > somethin' for dinner and now I have stomach ache. Please help me!!!" – > what would you answer? Reading that on a mailing list you probably would > just ignore such a person ... I think someone should write an online essay called something like 'How to Ask Questions the Smart Way', to help such folks. -- Cheers, This limerick goes in reverse. If you start from the bottom-most verse Rick Moen Unless I'm remiss, This limerick's not any worse. rick@linu The neat thing is this:-- Zach Weiner xmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] if2mac V0.3 init.d service for persistent network interface names
Quoting tito via Dng (dng@lists.dyne.org): > attached and inline you will find a improved and more robust version > of if2mac initscript and a example configuration file. [...] > # if2mac v. 0.3 (C) 2020-2021 T.R. GPLv2 For version 0.31, please consider a second line saying "Copyright owner waives the requirement to include a copy of GPLv2." Otherwise, it is technically unlawful for others to redistribute your short shell script _without_ including with it a copy of GPLv2's full licence text: Recipients' right to redistribute or to make derivative works hinges on their complying with that "include the licence test" requirement, which obligation you'll find stated in GPLv2 clause 1 -- and I'm assuming that is not your intent. -- Cheers, "2021 showed up, and told 2020 'hold my beer.'" Rick Moen -- @justinaireland r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why X does keyboard and mouse.
Quoting Hendrik Boom (hend...@topoi.pooq.com): > My ancient experience with X was working on the team developing UIM/X in > the days before Linux. I spent some time reading a manual caalled > something like IC (maybe ICCCM?) about communications between these > various network components, though I never had to do any coding directly > with that communication. ICCCM (Inter-Client Communication Conventions Manual). https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html X deliberately specifies "mechanism, not policy" for how windows interact. As such, an additional specification beyond the X protocol itself was needed for client interoperation. The ICCCM specifies cut and paste buffers, window manager interaction, session management, how to manipulate shared resources and how to manage device colours. These low-level functions are generally implemented within widget toolkits or desktop environments. This isolates application programmers from working directly with the ICCCM itself, as this functionality is delegated to the implementing toolkit. The ICCCM is notorious for being ambiguous and difficult to correctly implement. Furthermore, some parts are obsolete or no longer practical to implement. Efforts to update and clarify the ICCCM for current needs have resulted in the Extended Window Manager Hints (EWMH), which has gained fairly broad acceptance and continues to be extended as the need arises. https://en.wikipedia.org/wiki/Inter-Client_Communication_Conventions_Manual ICCCM came in for some memorable if passing derision in The UNIX-Hater's Handbook. http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html -- Cheers, "The plural of regex is regrets." Rick Moen -- old coder gag, seen on Reddit r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Finding installed packages, but from a backup
Quoting Antony Stone (antony.st...@devuan.open.source.it): > > this might be helpful : > > https://unix.stackexchange.com/questions/161866 > > Hm, some lessons for naïve sysadmins in there :) My _personal_ favourite part of that StackExchange page is where it says there's a solution to that difficult and vexing problem in the Linuxmafia.com Knowledgebase at http://linuxmafia.com/faq/Debian/package-database-rebuild.html . (But probably that's just me.) -- Cheers, "Like looking both ways before crossing the street, and Rick Moenthen getting hit by a submarine." -- Clarke Smith, age 9, r...@linuxmafia.com winner of Washington Post's contest for best description McQ! (4x80) of the year 2020 in a single word or phrase. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] double negative
Quoting Didier Kryn (k...@in2p3.fr): > Just to remind, if you forgot it. > > There's one known case where double positive means negative: C++ "Yeah, yeah." (The gag may not travel well, so: At least in some USA regions, the phrase "Yeah, yeah" is something of a dismissive phrase with meaning at least bordering on denial.) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Historical note on double negation.
Quoting Ian Zimmerman (i...@very.loosely.org): > But if "and" is a conjunction in this sentence pattern, the nouns or > pronouns it joins together form the subject, and so they ought to be in > the nominative, i.e. "John and I". Indeed. I vaguely recall Hendrik suggesting that 'and' functioning as a proposition makes 'John and me' a suitable subject for the sentence, i.e., in the nominative case, which I thought a startling notion both for the idea of 'and' being anything but a conjunction and for the conclusion drawn. I'd have to check the archive to see if I read that entirely right -- but definitely the claim of 'and' being a preposition was part of it. Not that this is worth dwelling on, unless good for points of benevolent entertainment. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Historical note on double negation.
Quoting Hendrik Boom (hend...@topoi.pooq.com): > I've been told that was the case in a long-gonne ancestor of modern > English, possible Old English or the language of Beowulf. It's not quite the same thing, but I am suddenly in a mind to provide a link to a lovely piece by my acquaintance Poul Anderson, the Danish-American science fiction author 'Uncleftish Beholding', in which Poul briefly explains atomic theory in an alternate-universe English that never received any Latin-derived vocabulary. Here, my gift to thee and thee, for the Jul holiday (and let us remember Poul and his wife Karen fondly): https://msburkeenglish.files.wordpress.com/2010/04/uncleftish-beholding-aka-atomic-theory.pdf (Watch out for that ymirstuff-235. It can be troublesome.) -- Cheers,My pid is Inigo Montoya. You kill -9 Rick Moen my parent process. Prepare to vi. r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Historical note on double negation.
Quoting Hendrik Boom (hend...@topoi.pooq.com): > Another such an example is >John and me went swimming. > Here 'and' serves as a preposition. I'm not sure where the location is, where 'and' fails to be a conjunction when used between two nouns in that fashion, but I'm curious what colour the sky is, there. -- Cheers, "Like looking both ways before crossing the street, and Rick Moenthen getting hit by a submarine." -- Clarke Smith, age 9, r...@linuxmafia.com winner of Washtington Post's contest for best description McQ! (4x80) of the year 2020 in a single word or phrase. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Your system is not supported by certbot-auto anymore.
Quoting Hendrik Boom (hend...@topoi.pooq.com): > Good that that works for you. > But for someone with attantion deficit, that couple of minutes a year is > difficult. (1) Keep domains you care about registered with five years of runtime. There really is not disadvantage worth mentioning. (2) Run d-check as a weekly cron job to remind yourself of upcoming domain registrations. http://linuxmafia.com/~rick/preventing-expiration.html http://linuxmafia.com/pub/linux/network/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Your system is not supported by certbot-auto anymore.
Quoting wirelessduck--- via Dng (dng@lists.dyne.org): > A good move to switch from godaddy. Doesn’t really matter where you > switch to, but godaddy appear to be a seriously unethical company. > > https://www.webpronews.com/godaddy-elephant-killing-nodaddy-venovix/ > https://www.wired.com/2007/01/godaddy-meet-no/ More: http://web.archive.org/web/20110627205958/http://nodaddy.com/ http://www.theregister.co.uk/2011/07/12/godaddy_shuts_down_nodaddy/ https://web.archive.org/web/20130310014102/http://asifali.me/post/42323712160/godaddy-deletes-my-domains-and-charges-me-to-restore ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Redhat EEEs CentOS?
Quoting vmlinux (vmli...@charter.net): > Embrace, Extend, Extinguish? Shocking but not surprising. Even more reason > for Devuan to exist. > > https://arstechnica.com/gadgets/2020/12/centos-shifts-from-red-hat-unbranded-to-red-hat-beta/ From: Rick Moen via Sb Date: Thu, 10 Dec 2020 23:41:46 -0800 To: Birmingham Linux User Group Subject: Re: [SB] Strategic CentOS Quoting Brian C via Sb (s...@mailman.lug.org.uk): > CentOS Stream made no technical sense to me when I first read about > it, and it still doesn't. People use CentOS because they want > stability. Concur. > So the recent strategic move I see as effectively killing the CentOS > project, but keeping the name alive to attempt to minimise adverse > reactions. > > And I assume that someone is gambling on a large number of CentOS > users finding it less expensive to switch to RHEL than to something > else. > > Hopefully information will leak about who's been pushing for the > change and when they started. All the signs I'm seeing make me think this is a high-level decision already fully underway and highly unlikely to ever be reversed. I share your surmise about RH Corporate's aim. Still, the suddenly prospect-less CentOS user community can reasonably be grateful for Red Hat, Inc.'s sponsorship of the project for many years until now. Long ago (early 2000s), independent RHEL-rebuild projects sprang up and thrived when a number of people, starting with John Morris (White Box Enterprise Linux) realised that an unbranded RHEL-equivalent was feasible. Morris's work was followed by Tao Linux, Scientific Linux, cAos Linux, NPACI Rocks Cluster Distribution, BioBrew Linux, X/OS Linux, Pie Box Enterprise Linux, and others. I'm not clear on what new obstacles there might now be, e.g., on account of RH, Inc. wishing to make things difficult for Oracle Linux. In olden days, the main task required was to swap in different contents for the two trademark-encumbered non-software SRPMs, the ones named redhat-logos and anaconda-images, and some other work to make the result self-hosting and compile everything to create a binary distro. At the time, there was a mailing list named rhel-rebuild, where the pioneers of the above-cited projects and others hung out. Its information page still exists: https://www.uibk.ac.at/zid/systeme/linux/linux-alt/rhel-rebuild-l.html I'm betting the actual mailing list (hosted for a while on Sympa) is long gone. (Untested, though.) -- Cheers, "2020 is pulling out more plot devices than Rick Moen a TV series on the brink of being canceled." r...@linuxmafia.com (Seen on Reddit, Oct. 2, 2020.) McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Let's Encrypt (was: snapd in Devuan? Dependency on systemd...)
Quoting Adam Borowski (kilob...@angband.pl): > Imagine that you tried and failed to find any door that would taken a > skilled lockpicker more than three seconds to open. Would you leave the > entrance to your flat wide open without a door at all? That's what you're > suggesting. No, I'm not. As I've repeatedly clarified, my sites have correct, competently generated certs. People needing to vet their provenance can do so in a variety of ways. The CAs are merely not among those ways. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Obviousness (was: Let's Encrypt (was: snapd in Devuan? Dependency on systemd...))
Quoting Bernard Rosset via Dng (dng@lists.dyne.org): > >It makes me sad that this view is deemed 'contrarian'. As a sysadmin, I > >consider it obvious common sense. > > I have no idea if it is contrarian or if it is the silent majority > of opinions. However the opinion being more vocal definitely seems > to be the one encouraging TLS encryption. It makes me very sad to contemplate that you think I denigrated or discouraged TLS encryption, as I certainly nowhere did. I could have sworn that I was clear that I encourage it, and in any event was _very_ clear that I was addressing the huge problems with the CA infrastructure, which is a different thing entirely, and has nothing at all to do with the merits of TLS or any other form of encryption. I'm sorry that you so thoroughly misunderstood what I said. Oh well. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Let's Encrypt (was: snapd in Devuan? Dependency on systemd...)
I posted a wrong link, oops. > Retrospective case studies of some of the latter from over the prior decade: > https://lists.dyne.org/lurker/message/20201203.213847.8bf66630.en.html I meant this one: http://linuxmafia.com/pipermail/conspire/2020-December/011311.html ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Let's Encrypt (was: snapd in Devuan? Dependency on systemd...)
Quoting Steve Litt (sl...@troubleshooters.com): > What about the fact that Google gives higher rankings to secure > accounts? For google togive that higher ranking, does self-signing > suffice for enhanced rankings, or does one have to have a cert signed > by a certification company like Let's Encrypt? This makes a big > difference for business websites. Obvious: For my sites, I don't care. If I were running IT operations at, say, my ex-employer Cadence Design Systems, I would pay DigiCert for a relatively meaningful cert attestation -- which, oddly enough, is exactly what they do, for obvious business reasons (because oblivious people use the Web and have money to spend.) Business Web sites can justify the graft every 1-2 years to get signatures that are not _quite_ as meaningless as those from Let's Encrypt or one of the many low-end laugh factory CAs -- as Cadence does in picking (apparently reputable, competent) DigiCert.[1] Retrospective case studies of some of the latter from over the prior decade: https://lists.dyne.org/lurker/message/20201203.213847.8bf66630.en.html [1] I gave minor sideeye to DigiCert's acquisition in 2017 of Symantec's gang-that-couldn't-shoot-straight CA/PKI division, but maybe they through out the rotten apples. (Please note that nothing in this post should be construed to endorse that or any other firm.) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Let's Encrypt (was: snapd in Devuan? Dependency on systemd...)
Quoting Arnt Karlsen (a...@iaksess.no): > ..meanwhile, I too lean towards Ian's contrarianism: > http://michael.orlitzky.com/articles/lets_not_encrypt.xhtml I couldn't possibly agree more. Let's Encrypt is a Potemkin Village approach to the SSL cert problem; it's pretend security that pretends as if a broken and unreliable CA infrastructure weren't that. I continue to self-sign only, and if people want to know why they should trust it, I'll say 'Either (a) don't, or (b) verify the hash with me via any of a large variety of out-of-band methods, like any sensible person.' If they counter that they want an automated lock icon on their Web browsers so they are absolved of the need to think, I say 'Sounds like a personal problem.' It makes me sad that this view is deemed 'contrarian'. As a sysadmin, I consider it obvious common sense. -- Cheers, "2020 is pulling out more plot devices than Rick Moen a TV series on the brink of being canceled." r...@linuxmafia.com (Seen on Reddit, Oct. 2, 2020.) McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Beowulf: 32bit or 64 bit?
Quoting Antony Stone (antony.st...@devuan.open.source.it): > It isn't a can of worms, it's just potentially confusing terminology if you > think that "AMD64" means you have to have a CPU made by AMD. 'x86_64' is irritating to type. Also, AMD deserves the credit, having shown the necessary leadership. -- Cheers, "2020 is pulling out more plot devices than Rick Moen a TV series on the brink of being canceled." r...@linuxmafia.com (Seen on Reddit, Oct. 2, 2020.) McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Configuring cron and exim4 to send e-mail after running cronjob
Quoting Florian Zieboll via Dng (dng@lists.dyne.org): > 'msmtp' is a lightweight and simple option for sending messages to > remote smtp servers from shell scripts. with a variable (e.g. > "$mailcmd") it can be used as drop in replacement for mailx. Generically, things like msmtp tend to be called 'nullmailers', after an early example of the type. I try to track the known options, here: http://linuxmafia.com/faq/Mail/nullmailers.html -- Cheers, "The plural of regex is regrets." Rick Moen -- old coder gag, seen on Reddit r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
Quoting Simon Walter (si...@gikaku.com): > Thanks for the bits of wisdom. > > Do you know any papers/articles/sites that discuss and explain this more? As Steve says, the crusty enfant-terrible of software, Prof. D.J. Bernstein, had some useful things to say about this, so, sure, start there. I swear I've come across other pieces elaborating on why separating recursive from authoritative nameservice is a recommended precaution, but I failed to bookmark/save those, sorry. -- Cheers, "2020 is pulling out more plot devices than Rick Moen a TV series on the brink of being canceled." r...@linuxmafia.com (Seen on Reddit, Oct. 2, 2020.) McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
Quoting Dimitris via Dng (dng@lists.dyne.org): > depends on the role... > bind as a local caching dns for PCs might be overhead. some people > would want something minimal/light for recursion, not the whole bind > "beast"... > unbound is very light in that perspective, and also found dqcache > (packaged) a pretty nice alternative. For a local recursive nameserver[1], I would urge consideration of PowerDNS Recursor, Deadwood, Knot Resolver, or (patched) dnscache, all of which are small, fast, and have reasonable security prospects and history. I'll not be critical of people like Mason choosing to still run BIND9 in that role -- if only because I still do that myself in places out of inertia -- but for that application consider it overfeatured, slow, ponderous, and a bit security-risky. [1] Calling such software 'caching' doesn't really clarify what the core functionality is, since every subvariety of DNS nameserver software except for authoritative-only daemons includes caching. -- Cheers, "2020 is pulling out more plot devices than Rick Moen a TV series on the brink of being canceled." r...@linuxmafia.com (Seen on Reddit, Oct. 2, 2020.) McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
Quoting Olaf Meeuwissen (paddy-h...@member.fsf.org):
> I have a dnsmasq instance that does *authorative* resolution for an
> internal domain.
Well, pseudo-authoritative.
> Anything not in that domain is forwarded to the corporate DNS servers.
> Works fine for me so I think dnsmasq can be more than _just_ a
> forwarder (which is all I wanted to point out).
Yes, dnsmasq does do _stub_ (local-only) authoritative service, as
is mentioned in my DNS software bestiary's entry.
http://linuxmafia.com/faq/Network_Other/dns-servers.html#dnsmasq
When I said '_just_ a forwarder', I meant that it doesn't do (real)
authoritative service or recursive resolving. It cannot even
independently resolve RRs without processing the recursive flag
('iteratively'), i.e., it cannot resolve anything outside its
local-private-domain zonefile except by forwarding the query to a
separate recusive daemon elsewhere.
Naturally, the ability to have a stub zone is also useful.
My point is that dnsmasq is in _no way_ an adequate substitute for
having a locally based recursive nameserver. However, it can be a nice
adjunct to one.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Clarification please
Quoting g4sra via Dng (dng@lists.dyne.org): > Can anybody suggest a suitable authoritative/recursive DNSSEC > supporting name server for SOHO domain use on embedded systems. What > I am looking for is something like dnsmasq. dnsmasq, it should be noted, is _just_ a forwarder. It forwards outbound queries to one or more IP-identified recursive servers you specify. Those recursive servers do the actual work. Respectable recursive(-only) nameserver packages (that are open source): o Unbound o PowerDNS-recursor o dnscache (from the djbdns suite), if patched to modern standards o Deadwood o Knot Resolver o Bundy recursive portion (but it's probably scary betaware) Respectable authoritative(-only) nameserver packages (that are open source): o NSD o PowerDNS Authoritative Server o MaraDNS authoritative portion o rbldnsd o YADIFA o MyDNS-NG (which also does forwarding of out-of-bailiwick queries) o ldapdns o Knot DNS o gndsd o dnsjava o tinydns (from the djbdns suite), if patched to modern standards o Bundy authoritative portion (but it's probably scary betaware) (Something that becomes apparent as one studies this field is that writing an authoritative daemon is relatively easy and many folks have done it. Writing a recursive daemon without messing up is difficult, so there are far fewer successful examples.) I maintain a bestiary of all known DNS software for Linux, here: http://linuxmafia.com/faq/Network_Other/dns-servers.html The above list is extracted from it. The page is still missing one peculiar^W innovative package, called Ironsides. Coverage is coming, Real Soon Now. I _hope_ the page is reasonably clear and complete about DNSSEC support, but: Errare humanum est, sed perseverare autem diabolicum. FWIW, I am no longer comfortable with the idea of a combined authoritative/recursive server on a publicly exposed static IP. That has been deprecated for long decades as bad security, particularly because it increases the risk of cache poisoning of the recursive server. IMO, a LAN connected to public networks, even a small one, ought to have the authoritative service on a separate, public-facing host, and the recursive service on a protected, internal-network machine that is as shielded from public networks as possible. I have personal experience with: BIND9 (and predecessors), NSD, Unbound, PowerDNS Recursor, PowerDNS Authoritative Server, dnscache, tinydns. I can enthusiastically recommend NSD and PowerDNS Server. Before a recent troubling thing with Unbound where the developers made a dumb decision to accomodate containerising, I was a huge Unbound cheerleader and might be again. Necessary disclaimer: I'm personal friends with Deadwood/MaraDNS author Sam Trenholme (but have yet to substantially deploy his software). As an administrator whose experience with BIND goes all the way back to BIND4 days, I know well that it's the path of least resistance to just deploy a do-it-all nameserver package like BIND9, but that's been known to be a bad idea for a long time, and it's past time to stop doing that. -- Cheers,"Rand Paul being patient zero for a Senate Rick Moen viral outbreak is a sign of a writers' room r...@linuxmafia.comdropping too much acid, late in the season." McQ! (4x80)-- @owillis (Oliver Willis) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Self-hosted SMTP (was: TB and Enigmail)
Quoting Bernard Rosset via Dng (dng@lists.dyne.org): > It seems we're drifting away from the main subject. > Count me in! Roger that! Subject header tweaked. > ? > If your emails are being refused by others, including major email > hosters, I would kindly suggest you check you got at least correct > SPF + DKIM entries. You can throw DMARC into the mix if you wish so, > too. Umm... As I already mentioned upthread, my domains' e-mail continue to have very high deliverability. Those domains feature strongly asserted SPF RRs in their auth DNS. However, by carefully considered local policy, I decline to also implement DKIM/DMARC, considering those extensions to have been botched in design and implementation by Yahoo, Inc. (DKIM seems to be the keystone problem, there, particularly its hapless hostility to MLM-mediated forwarding.) Empirically, I so far perceive no measurable loss of host reputation from declining to implement DKIM/DMARC. I _do_ publish, in each of my domains' DNS, deliberately non-compliant DMARC RRs, just to make my stance quite clear, e.g.: :r! dig -t txt _dmarc.linuxmafia.com @ns1.linuxmafia.com +short "DMARC: tragically misdesigned since 2012. Check our SPF RR, instead." > It's saddening to assess how little is known by the general public > (including people who actually work on technical matters in IT) about > key technologies, like DNS (the mother/father of all) or email. True datum: When I began hosting my own SMTP smarthosts, I was still a staff accountant (UK: chartered accountant) for a living, not a sysadmin. Fortunately, nobody told me I couldn't do it, so it worked. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Zoom via Firefox
Quoting d...@d404.nl (d...@d404.nl): > I do not have experience with Zoom but with Jitsi and discovered that > disabling WebRTC leakage in Firefox because of WebRTC leaking ip > addresses also crippled Jitsi. The first comment on this bug is said to address that (even though the bug report is for the standalone Electron-based Jitsi Meet client, 'jitsi-meet-electron'): https://github.com/jitsi/jitsi-meet-electron/issues/324 In short, yes, what you observe is correct, but you can accomplish your objective by blocking WebRTC leakage using the block-WebRTC-leakage feature of the uBlock Origin extension, rather than using the similar feature in Firefox's about:config . ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] TB and Enigmail
Quoting Lars Nood??n via Dng (dng@lists.dyne.org): > Google appears to be doing what it can to cut off not only MUAs like ^^ > Thunderbird but also competing mail providers. ^^^ I believe you mean (specifically) cut off from access to GMail send/receive access by GMail users, as an alternative to using GMail's proprietary WebUI. Yes, that's very strongly my understanding, too. Of course, my own way of eliminating GMail problems is: Don't use GMail, and you thereby magically avoid GMail problems. ;-> > It's increasingly hard to exchange e-mail between lesser known providers > or even self-hosted servers and GMail accounts. This does _not_ accord with my experience. In my experience, if you run a spam-clean and RFC-compliant SMTP operation and take modest anti-forgery measures (such as my domains' strongly asserted SPF RR), your mail domain will have no problem bidirectionally communicating with GMail / Googlemail -- without spamboxing or teergrubing, etc. I keep monitoring this situation, and it may change, but that is still my honest assessment from many decades of self-hosted SMTP smarthost operation. -- Cheers, "I suppose the process of acceptance will pass through the usual Rick Moen four stages: (i) This is worthless nonsense; (ii) This is an rick@linux interesting, but perverse, point of view; (iii) This is true, mafia.com but quite unimportant; (iv) I always said so." -- JBS Haldane ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] TB and Enigmail
Quoting Dimitris T. via Dng (dng@lists.dyne.org): > still recommending TB to clients/people though... In case it's useful, I keep a list of all known MUAs for Linux, here: http://linuxmafia.com/kb/Mail/muas.html Necessary disclaimer: As anyone who's ever kept alive over decades a complex Web page on an evolving subject knows, it absolutely needs updating and maintenance. I just don't currently know what's missing and needing fixing, and won't know until I can next waste a day re-surveying the field, fixing bitrot, etc. I can't remember exactly why I started that page, but sometimes in the past it's been something like hearing, once too often, 'There aren't enough mail clients for Linux', and wanting to rejoin something like 'Really, 123 isn't enough? How many do _you_ use, from day to day?' -- Cheers, Peter G. Neumann: "Mars has been a tough target." Rick Moen Harlan Rosenthal: "That's because the Martians keep r...@linuxmafia.com shooting things down." RISKS Digest, v. 20, #59&60 McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] TB and Enigmail
Quoting John Crisp via Dng (dng@lists.dyne.org): [snip much-appreciated picture of behind-the-scenes management folderol at Thunderbird Project:] > The problem is decent alternatives are not great [...] Just in case people have lost track of this, the long-term nub of the problem is: revenue model. Firefox brought in money. Thunderbird did not. When all is said and done, Mozilla Foundation is an appendage of Mozilla, Inc., which as a for-profit corporation is bound to a depressing pursuit of quarterly earnings targets as a primary objective. From the corporate perspective, Thunderbird development resources are deadweight, a dispensible community sponsorship that earns nothing. I continue to like projects that are limited in feature scope enough to not live or die by corporate underwriting. E.g., mutt continues to be maintainable by a small group of motivated developers. When I want it to be graphical, I run it in an xterm. ;-> -- Cheers, Rick Moen"The first rule of Dunning-Kruger club is r...@linuxmafia.com you don't know you're in Dunning-Kruger club." McQ! (4x80) -- @drankturpentine (Dennis Detwiller) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ?? chacun son go??t (was: Is it worth the effort for SPF, DMARC, DKIM, etc.?)
Quoting Simon Hobson (li...@thehobsons.co.uk): > > Sounds like a problem local to you. > > No, not in the least bit "local to me". I will be generous and assume > that you simply misunderstood what I wrote - it happens a lot :-( > > Prior to SPF, it was perfectly OK to (for example) : > > Have an account (lets say f...@example.com) so that fred can have an > email address that "goes with" his website. So, when I said 'local to you', I meant 'local to people who want to use practices that amount to forging the domain owner's Internet domain, in ways many domain owners including me no longer find tolerable and wish to make not work, i.e., to be rejected as forgeries. Since we're using the hypothetical example of Fred, my assessment then becomes 'Sounds like a problem local to Fred.' And since, as detailed below, no Fred-types are among legitimate users of _my_ domains' mail, I'm not only fine with illegitimate Freds being unable to successfully forge my domain, I'm very happy with that outcome. > For reasons we never understood*, Fred is adamant he is not prepared > (even if we configure it for him) to have a second account in his mail > client to directly collect mail from our mail server using POP or > IMAP. He just wants mail to arrive in his inbox. So instead we simply > forward his mail to his regular account - tends to be > "somegibber...@btinternet.com" and things like that). Of course, some > wanted "sales@...", "support@...", and so on as well - though mostly > these clients were prepared to do it without forwarding to an external > account. For many years that worked just fine. ONLY when more players > started implementing SPF did it break. Basically Fred relied on forging the various domains where he has accounts for mail, in the sense of originating mail from arbitrary originating IP addreseses on his outbound mail, IP addresses that the domain owners have no particular wish to be accepted as sources of their domains' mail (e.g., someone else's MTA). I have no doubt that some Internet domain owners remain oblivious to the reputation problem that results when UCE and other junk can believably impersonate their domains as the claimed sources of outbound mail -- and those oblivious domain owners can make Fred happy as long as that arrangement continues to work for both. The legitimate users of my domain linuxmafia.com (among others) do not include any Freds, because I informed all my users around the year 2000, "Hey, if you're used to sending out your [myaccount]@linuxmafia.com accounts via SMTP lists _other_ than linuxmafia.com itself, please be advised that, starting now, I'll be doing my best to ensure that any such mail fails and is rejected. Please switch to originating linuxmafia.com mail from the linuxmafia.com server ONLY. Thank you.' It's a small operation with only a small number of clueful users. Larger operations offer roving IP-address origination _of their domain's_ mail _from their authenticated users_ via the newer SMTP Submission port, 587/tcp. https://www.mailgun.com/blog/which-smtp-port-understanding-ports-25-465-587/ If one of my users was a Fred, and he wanted his outbound linuxmafia.com mail to be acceptable to end-destinations irrespective of what IP address sent it outbound on 25/tcp, I'd say 'Sorry, Fred, not with my domain.' If you want to do that, feel welcome to register your own domain and you can risk its reputation any way you want. > We didn't change anything, others implemented policies explicitly > designed to break it. By 'others' you mean domain owners, and by 'break it', you mean break deliverability of mail from unauthorised originating IPs forging those owners' domains. And that's the thing. Fred (and you) don't own those domains. Therefore, you don't decide those domains' SMTP deliverability policies, because -not yours-. If you're unclear on the meaning of 'not yours', try to forge SMTP from linuxmafia.com, and the outcome will clarify the concept. > BTW - I did try Sender Re-Writing (this was before DMARC & DKIM were > popular). SRS was a last-ditch attempt to preserve the ability of ~/.forward and /etc/aliases ancient-style forwarding to function for cross-domain delivery in the modern age of domain owners no longer being inclined to permit SMTP forgery. IMO, it was never worth the trouble. By 2000, the handwriting was on the wall that ~/.forward and /etc/aliases cross-domain forwarding had been a casualty of the war on spammers' and others' forgeries, so with almost no regret I ceased using those two antique forwarding methods (except intra-domain). > Again no. It's not about who sends mail purporting to be me, it's > about allowing me to legitimately forward mail from "some random > person" to one of our clients - where that client just wants the email > to appear in his inbox. Basically using someone else's MTA as a relay for your client without prior arrangement. Guess what? Open relays became unacceptable even
[DNG] à chacun son goût (was: Is it worth the effort for SPF, DMARC, DKIM, etc.?)
Quoting Simon Hobson (si...@thehobsons.co.uk): > Rick Moen wrote: > > > My response inevitably is that I really couldn't care less whether > > they like SPF or not. ... > > May I respectfully pick you up on that one. Well, you can _try_. > Regardless of the arguments for and against which have been done to > death for long enough, SPF did predictably break email in many ways - > some of which I used to use, and some which my clients used to use. Sounds like a problem local to you. Possibly you wish to originate port 25 mail on IP addresses you are not prepared to declare in an SPF RR for reference by SMTP receivers. Like, maybe your users think it's still 1995 and that they ought to be free to originate outbound port 25 SMTP connections purporting to represent your domain from arbitary, not-preplanned IP addresses at will. I wouldn't know. What I know is that all legitimate linuxmafia.com mail originates from my MTA's static IPv4 address, and my declaring that in an SPF RR as the sole legitimate origin helps others definitively detect and reject forgeries. Therefore, I publish such an SPF RR, and am happy with the results. You say that for some reason you cannot gain the same benefit? OK, if you say so. But I don't think that such a local (alleged) inability has anything to do with me. > In a small way, by implementing SPF yourself, you've added to the > support for something that broke existing LEGITIMATE mail activities. I doubt your premise that SPF 'breaks' anything -- and find it highly suspicious that you don't support your assertion with anything even remotely resembling specifics. However, additionally, your apparent inability or disinclination to publish information in your DNS saying 'All SMTP mail _not_ originating from IP addresses following this spec should be considered forgeries' (_which is the sum and substance_) utterly fails to be a reason why I ought not to, given that I can and have done so. > So your approach has a hint of "I don't do that, so I don't care about > the people who do and now find it broken". Since nobody else's mail (other than my users') purports to originate from linuxmafia.com, I completely fail to see how my succesful deployment of a precise and accurate SPF RR adversely affects anyone else in the universe, let alone 'takes away their freedom'. You can try to show otherwise, if you want, but it's going to require some awfully compelling evidence, and I'm pretty certain you don't have any nor can acquire any. I'll be frank, too. Experience suggests that people making this argument are unwilling to come to terms with the modern reality that SMTP forgery is a huge problem and that circa-1995 policies of SMTP port 25 origination are a bad idea, and somehow think it's my job to contend better with reality. That actually just is not my job, and I have a lot better things to do with my time. > Hmm, didn't Devuan come into being partly due to someone pushing a > policy of not caring what he breaks for other people ? Sorry, that was > a bit below the belt but I hope it illustrates the issue. I wouldn't calling that hitting below the belt. I'd call it dribbling on your feet, since we're going for metaphorical imagery. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] X11: safe to remove?
Quoting wirelessduck--- via Dng (dng@lists.dyne.org): > > On 3 Oct 2020, at 00:12, Dimitri Minaev via Dng wrote: > > > Because of Swing, I suppose. Java allows one to create GUI apps, > > too. > > The headless jre package also has X11 dependencies. Though I'm certainly aboard for avoiding and eliminating bloat, I'll point out that running selected X11 executables from a headless host, e.g., tunneled over 'ssh -Y' to a remote X server, is a very, very standard use case. This of course includes Java bytecode that makes X11 calls. -- Cheers, "2020 is pulling out more plot devices than Rick Moen a TV series on the brink of being canceled." r...@linuxmafia.com (Seen on Reddit, Oct. 2, 2020.) McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Is t worth the effort for SPF?, DMARC>, DKIM?, etc
Quoting terryc (ter...@woa.com.au): > On Sun, 27 Sep 2020 17:20:06 +0200 > Alessandro Vesely via Dng wrote: > > > > You can also publish DKIM and SPF records so as to produce > > DMARC-aligned authentication for any hosted domain. Users won't > > notice any difference. > > Does anyone have any figures on how effective these methods are? > It seems we get a new idea every few years and none make the slightest ^^^ > difference in spam levels. ^ You have made a fundamental, basic error. SPF and DMARC are _antiforgery_ extensions to DNS and SMTP. They permit a domain owner to publish information in their authoritative DNS to advise recipients of SMTP about what SMTP-originating IP addresses ought to be considered _authorised_ SMTP senders for their domains, vs. which others ought to be rejected as forgeries. Nothing about SPF and DMARC say 'this will reduce spam'. They're about making domain forgery (in received SMTP mail) be detectable and able to be confidently rejected upon receipt. DKIM is a (poorly designed, IMO) method for individual SMTP-mail originating system to cryptographically sign outbound SMTP mail, permitting receiving systems to verify that the mail contents hasn't been tampered with en-route. Since I personally refuse to have anything to do with DKIM or DMARC (both designed by the same team at Yahoo), I'll illustrate SPF's value proposition to a domain owner. I'm the owner/operator of domain linuxmafia.com (among others). Here is that domain's publicly proclaimed SPF record: :r! dig -t txt linuxmafia.com +short "v=spf1 ip4:96.95.217.99 -all" That record says, translated into English, "Please accept as from an authorised SMTP source for domain linuxmafia.com _only_ mail originated by IPv4 address 96.95.217.99. Please hardfail (reject) mail received from any other IP address." My putting that information in my DNS is a huge win for my domain's good reputation as a clean SMTP source, in that it states extremely clearly what mail _purporting_ to be from linuxmafia.com ought to be considered by receiving MTAs (that honour my wishes) to be genuine. Of course, I have zero ability to compel or persuade receiving SMTP systems to check and honour my domain's SPF record, but many do, and every little bit helps. Occasionally, someone tries to convince me that SPF is A Bad Thing for any of several uncompelling reasons, most often because they have been accustomed to originating mail from _their_ domains from arbitrary IP addresses on TCP port 25 (SMTP), and fear that widespread adoption of SPF will somehow make it less likely that their carefree habit will continue much longer. My response inevitably is that I really couldn't care less whether they like SPF or not. It permits me to unambiguously declare to the public that IP address 96.95.217.99 is the only valid source of SMTP mail from my domain, thereby exposing as forgeries mail from anywhere else (falsely) claiming to be from my domain, so it is A Good Thing for my domain, and I don't give a tinker's damn whether my interlocutor approves of it. And none of this has anything particularly to do with 'reducing spam'. That just isn't the point, and the only people debating that supposed issue are folks who never bothered to look up what the thing _is_. > The only result is that there is now an industry of religious extremism > in "blacklisting" sites that don't follow their desired implementation. To be blunt: You have not bothered to understand what you're writing about. I would suggest you do so. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..devuan to the rescue? Easiest possible newbie email server setup, ideas?
Quoting Mark Rousell (mark.rous...@signal100.com): > Option 1 is a bit embarrassing if anyone notices (e.g. > "host-46462.static.bugtown.myisp.net" isn't too cool as the name of your > mail server) but I don't see any technical downside, although DMARC > might perhaps be an issue nowadays. DMARC can be made to be a non-issue. ;-> :r! dig -t txt _dmarc.linuxmafia.com +short "DMARC: tragically misdesigned since 2012. Check our SPF RR, instead." I've had no problems _without_ DMARC/DKIM (but with a strongly asserted SPF record). Have been operating home *ix SMTP smarthosts on static IP with matching rDNS, and maintaining a clean, high-reputation system since the 1980s. I've tried to always have rDNS always match exactly my main mail server's primary identity, though it has several valid alternate public identities (uncle-enzo.linuxmafia.com, hugin.imat.com, unixmercenary.net) that in my experience _also_ enjoy high reputation, despite A-to-PTR mismatch. Basically, in my experience, some operators may be assigning a _very small_ spamicity score to 'rDNS exists but doesn't match': I cannot really tell. What's clear is that 'IP lacks rDNS' is (rightfully) penalised, given RFC mandate for same and its usefulness as an antispam heuristic. And, of course, 'IP is part of a dynamic netblock' is very definitely an antispam heuristic (though operating a public-facing SMTP host on Dynamic DNS is RFC-compliant), so Don't Do That, Then. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Danger: Debian POSIX hostility
Quoting Ian Zimmerman (i...@very.loosely.org): > I worry about a different kind of portability. If I ever have to switch > to BSD (and this remains a possibility, unfortunately), /bin/* shebangs > will not work except for /bin/sh, and /bin/sh is always ash. That is > because on BSD everything not in the core system goes into /usr/local. You know, if going for maximum portability, you can rely, within the shebang, on /usr/bin/env. Like: #!/usr/bin/env bash Although there's no absolute guarantee that env(1) will reside in /usr/bin on all Unix machines ever made, it does live there on BSDs. And I'm willing to bet that it's going to exist and be in /usr/bin on Unixes made written the last quarter-century. https://stackoverflow.com/questions/10376206/what-is-the-preferred-bash-shebang#10383546 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Danger: Debian POSIX hostility
Quoting Peter Duffy (pe...@pwduffy.org.uk): > With respect, I'd tend to disagree with that to some extent. The /bin/sh > symlink is built in, and is there from the point that the system is > installed. That was a _second_ if lesser blunder (in that bash was, even at the inception of Linux, a poor approximation of the Bourne shell), but doesn't excuse the one of failing to put /bin/bash in the shebang if one intends to write a bash-specific script. Which is what was actually under discussion. > So it's a feature made available to users, and it's arguably > not a blunder to use it. It's not a blunder to use a /bin/sh -> /bin/bash symlink. It's a blunder to fail to specify bash in the shebang if you're writing a bash script. > I'd agree that best practice is specifying bash explicitly in the > shebang, if it's required (something that I personally have always done > since I first bitten by the bash/dash problem). For values of 'best practices' approximating 'This will prevent your script accidentally breaking if you use bash-specific features and your script ends up being run at a time or place where /bin/sh is something other than bash.' > I'm trying to remember what happens on systems that default to ksh and > csh - I assume that on those, the shebang always needs to specify the > shell to be used. ksh and pdksh are fairly close approximations of the Bourne shell. csh and tcsh are very much not. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Danger: Debian POSIX hostility
Quoting marc (marc...@welz.org.za): > Hmm - that might require some background: I'd venture that most of > these scripts were written when sh was just a symlink to bash, and > dash didn't exist, nevermind as a debian package. But that was always a blunder. The shebang should have been set to bash explicitly, if bash-specific features are used: In the cases of which you spoke, the coder made a lazy and unsupportable assumption. Also, the fact that Debian Almquist Shell (dash) didn't exist until 2002 is true but irrelevant. Other Bourne clones did, e.g., Kenneth Almquist's ash (Almquist Shell), which predated the Linux kernel, having emerged in 1989. As another example, pdksh has been available since 1983 and is closely Bourne compatible (compliant with the relevant POSIX.2 specs). > I, for one, never bought into the reasoning for migrating > system scripts away from bash to sh. The argument that > bash is too large struck me as odd - there were critical > dependencies on perl and python with a much larger dependency > graph, and much bigger startup costs... Many startup Bourne scripts and other root-run Bourne scripts became about 3x faster when run by dash instead of bash. I think it likely that there are also many fewer potentially dangerous bugs lurking, too, given the great reduction in codebase size. > More importantly I think it is good that one uses the same language > that one types into the terminal every day when extending the > distribution - that makes a sysadmin equal to the distribution maintainer, > instead of specialising that into a different caste... Well, then: Learn Bourne scripting. When you're well informed about that, learn bashisms as an optional extra feature set when and if needed. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Danger: Debian POSIX hostility
Quoting Arnt Karlsen (a...@iaksess.no): [...] > > I'm curious how many, if any, of those are going to enable the > > systemd-homed service in their default installations. My guess is few > > or none, but I lack data. > > ..the bigger problems are how the ones in the know, acts on the ones > they should be protecting: 1. distro packagers on the newbies, and > 2. sysadmins on their un-suspecting users, bosses, share holders etc > owners. I think you're disregarding my point. (Which is mildly vexing, but I'm not a newcomer to the Internet, so I'm used to it.) To restate, once: A bit of bloatware becoming potentially providable and potentially enabled by default in a distribution doesn't make it a foregone conclusion that it will be both. And also it should be noted when that bloatware can be trivially disabled because by its nature it is an optional service. Remember the hilarious security and functionality screwup with systemd-resolved? That was justifiably mocked, but also not the subject of great concern because it was a bit of systemd bloatware that distros were not enabling by default, and could also be trivially disabled because it was an optional service. I'll bet both continue to be case, though I don't care enough to check. Debian, among others, runs rsyslog by default even though systemd-journald has been present since early days. And so on. OK, I've now made the point twice. I'm done. -- Cheers, "My hot flight attendant asked how I like my coffee. Rick Moen And that's when she told me: 'That's cute, honey, but r...@linuxmafia.com the coffee's free. You don't have to pay for it, here." McQ! (4x80)(seen on Twitter) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Danger: Debian POSIX hostility
Quoting Steve Litt (sl...@troubleshooters.com): > I've never been afraid to kludge when it comes to packages, so my > solution was: > > chattr i /etc/resolv.conf > > :-) Without the '+', that is not a solution, just a syntax error. ;-> ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
