Re: ed! the one true editor! (was Re: sed on a large file)

[Rick Moen via luv-main]

Quoting Craig Sanders (c...@taz.net.au):

> still useful) ed or ex. ed is the original unix text line editor, dating
> back to 1969 and still included with modern unix & linux systems.

It also famously had one of the most ultra-terse man pages in all of
Unix, thus leading to this humour piece (now arguably obsolete now that
Debian provided a rather more fleshed-out man page):



From: p...@athena.mit.edu (Patrick J. LoPresti)
Message-ID: <1991jul11.031731.9...@athena.mit.edu>
Sender: n...@athena.mit.edu (News system)
Subject: The True Path (long)
Date: 11 Jul 91 03:17:31 GMT
Path:
ai-lab!mintaka!olivea!samsung!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!patl
Newsgroups: alt.religion.emacs,alt.slack
Organization: Massachusetts Institute of Technology
Lines: 95
Xref: ai-lab alt.religion.emacs:244 alt.slack:1935

When I log into my Xenix system with my 110 baud teletype, both vi
*and* Emacs are just too damn slow.  They print useless messages like,
'C-h for help' and '"foo" File is read only'.  So I use the editor
that doesn't waste my VALUABLE time.

Ed, man!  !man ed

ED(1)   UNIX Programmer's ManualED(1)

NAME
 ed - text editor

SYNOPSIS
 ed [ - ] [ -x ] [ name ]
DESCRIPTION
 Ed is the standard text editor.
---

Computer Scientists love ed, not just because it comes first
alphabetically, but because it's the standard.  Everyone else loves ed
because it's ED!

"Ed is the standard text editor."

And ed doesn't waste space on my Timex Sinclair.  Just look:

-rwxr-xr-x  1 root  24 Oct 29  1929 /bin/ed
-rwxr-xr-t  4 root 1310720 Jan  1  1970 /usr/ucb/vi
-rwxr-xr-x  1 root  5.89824e37 Oct 22  1990 /usr/bin/emacs

Of course, on the system *I* administrate, vi is symlinked to ed.
Emacs has been replaced by a shell script which 1) Generates a syslog
message at level LOG_EMERG; 2) reduces the user's disk quota by 100K;
and 3) RUNS ED!!

"Ed is the standard text editor."

Let's look at a typical novice's session with the mighty ed:

golem> ed

?
help
?
?
?
quit
?
exit
?
bye
?
hello? 
?
eat flaming death
?
^C
?
^C
?
^D
?

---
Note the consistent user interface and error reportage.  Ed is
generous enough to flag errors, yet prudent enough not to overwhelm
the novice with verbosity.

"Ed is the standard text editor."

Ed, the greatest WYGIWYG editor of all.

ED IS THE TRUE PATH TO NIRVANA!  ED HAS BEEN THE CHOICE OF EDUCATED
AND IGNORANT ALIKE FOR CENTURIES!  ED WILL NOT CORRUPT YOUR PRECIOUS
BODILY FLUIDS!!  ED IS THE STANDARD TEXT EDITOR!  ED MAKES THE SUN
SHINE AND THE BIRDS SING AND THE GRASS GREEN!!

When I use an editor, I don't want eight extra KILOBYTES of worthless
help screens and cursor positioning code!  I just want an EDitor!!
Not a "viitor".  Not a "emacsitor".  Those aren't even WORDS ED!
ED! ED IS THE STANDARD!!!

TEXT EDITOR.

When IBM, in its ever-present omnipotence, needed to base their
"edlin" on a UNIX standard, did they mimic vi?  No.  Emacs?  Surely
you jest.  They chose the most karmic editor of all.  The standard.

Ed is for those who can *remember* what they are working on.  If you
are an idiot, you should use Emacs.  If you are an Emacs, you should
not be vi.  If you use ED, you are on THE PATH TO REDEMPTION.  THE
SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE
FAITHLESS.  DO NOT GIVE IN!!!  THE MIGHTY ED HAS SPOKEN!!!

?
___
luv-main mailing list -- luv-main@luv.asn.au
To unsubscribe send an email to luv-main-le...@luv.asn.au

(forw) Re: [golugtech] DMARC mitigation, ezmlm, and golugt...@lists.troubleshooters.com

[Rick Moen via luv-main]

- Forwarded message from Steve Litt  -

Date: Sun, 25 Sep 2022 05:28:58 -0400
From: Steve Litt 
To: golugt...@lists.troubleshooters.com
Subject: Re: [golugtech] DMARC mitigation, ezmlm, and 
golugt...@lists.troubleshooters.com

On Sun, 2022-09-25 at 02:14 -0700, Rick Moen wrote:

> It is claimed that ezmlm-idx provides a mitigation for the problem.
> I repeat, here and now, my suggestion that you should look into that.

It looks like my Web host, Futurequest, is using ezmlm-idx and has been
for over a decade:
https://www.futurequest.net/forums/showthread.php?t=24961 . Apparently
ezmlm-idx was written by Bruce Guenter, who is employed at Futurequest.
So the remaining questions are:

1) Am I actually using ezmlm-idx

2) Does ezmlm-idx protect against the stuff you talked about

So perhaps everything's already good. Or not. I'll try to figure it out later.

SteveT


-
To unsubscribe, e-mail: golugtech-unsubscr...@lists.troubleshooters.com
For additional commands, e-mail: golugtech-h...@lists.troubleshooters.com


- End forwarded message -
- Forwarded message from Rick Moen  -

Date: Sun, 25 Sep 2022 06:38:31 -0700
From: Rick Moen 
To: golugt...@lists.troubleshooters.com
Subject: Re: [golugtech] DMARC mitigation, ezmlm, and
golugt...@lists.troubleshooters.com
Organization: If you lived here, you'd be $HOME already.

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

> So the remaining questions are:
> 
> 1) Am I actually using ezmlm-idx
> 
> 2) Does ezmlm-idx protect against the stuff you talked about

You're a troublshooter, Steve.  What you need is a test case.

Let's imagine that you have a user on your mailing list using a domain 
with a strongly asserted DMARC policy, say, Steve Litt .
How do we know that yahoo.com has such a policy?  We look directly at
the DMARC record in yahoo.com's DNS, and verify that it declares p=reject or
p=quarantine as the requested policy for receiving MTAs to apply.

:r! dig -t txt _dmarc.yahoo.com. +short
"v=DMARC1\; p=reject\; pct=100\; rua=mailto:d...@rua.agari.com\; 
ruf=mailto:d...@ruf.agari.com\;;

Overly aggressive DMARC policy in a sending user's domain's DNS, check.

Now, you need a receiving mailing list member who's at a domain that
_enforces_ other domains' DMARC policies.  GMail will do nicely, so, 
say, Steve Litt  , as the test receiver.

So, now you have Steve Litt  post to the mailing list.
It hits the MLM, and gets registered in the MLM's cumulative traffic
archive (if any).  And now, you can check with relevant subscribers such
as Steve Litt , to see whether their receiving MTAs
rejected the mailing list copy's remailing to them of Steve Litt
's post.

_If_ the MLM's DMARC mitigation is enabled and is the same as Mailman's,
then, upon transit through the MLM to subscribers (and to the archive if
any), the original

  From: Steve Litt 

would get munged by the MLM to

  From Steve Litt via 

and would have appended this new header:

  Reply-To: Steve Litt 

That is the (altered) form of Steve Litt 's posting
that would be received by all subscribers including Steve Litt
 -- if the same DMARC mitigation as Mailman's 
is applied.

Hope that helps.


-
To unsubscribe, e-mail: golugtech-unsubscr...@lists.troubleshooters.com
For additional commands, e-mail: golugtech-h...@lists.troubleshooters.com


- End forwarded message -
___
luv-main mailing list -- luv-main@luv.asn.au
To unsubscribe send an email to luv-main-le...@luv.asn.au

Re: (forw) DMARC mitigation, ezmlm, and golugt...@lists.troubleshooters.com

[Rick Moen via luv-main]

Sorry, another edit error.

> And that brings me to ezmlm.  Daniel J. Bernstein ("djb") wrote it, and
> there's a lot to like about it.  He orphaned it in 1997.
> 
> The DMARC problem was sprung onto the world in 2012.  Dan purported to 
> retroactively place almost all of his software, by unilateral act of
> will, into the public domain in a public anouncement on Nov. 30, 2007,
> after a hilarious losing fight with Theo de Raadt and other key OpenBSD
> figures in 2013, over Dan's confusing but proprietary licensing that
 
> he consistently used up until then.  (See;
> http://linuxmafia.com/pub/humour/dan-versus-theo)

The popcorn-worthy Dan vs. Theo spectacle was in Aug. 2001.  I linked to
a preserved copy of the thread that was archived in 2013.

___
luv-main mailing list -- luv-main@luv.asn.au
To unsubscribe send an email to luv-main-le...@luv.asn.au

Re: (forw) DMARC mitigation, ezmlm, and golugt...@lists.troubleshooters.com

[Rick Moen via luv-main]

Correcting edit error.

> I ask because I don't know.  I worry a bit, because, over the decades
> before 2007, when Dan used his semi-covertly-proprietary licensing
> to enforce some modernity-hostile improvements (such as FHS compliance), 
 ^^^ discourage

Dan's pre-2007 licensing made it gratuitously disallowed to ship _binary_ 
packages of djbware programs that differed from Dan's preference, e.g.,
it would have violated his pre-2008 Qmail licence terms to distribute a
binary RPM or deb that installed components in FHS-compliant locations
instead of where Dan wanted them to live.  Some distros, notably Debian,
employed ingenious workarounds like a "qmail-src" package that _locally_
altered the qmail 1.03 source tree to be FHS-compliant and then
autobuilt and installed the matching binaries.  

Most distros, and indeed most potential collaborators, simply applied
their efforts to other codebases.  

___
luv-main mailing list -- luv-main@luv.asn.au
To unsubscribe send an email to luv-main-le...@luv.asn.au

(forw) DMARC mitigation, ezmlm, and golugt...@lists.troubleshooters.com

[Rick Moen via luv-main]

Steve Litt migrated GoLUG's mailing list on an emergency basis
to ezmlm.  I just wanted to make him aware of the DMARC problem.

- Forwarded message from Rick Moen  -

Date: Sat, 24 Sep 2022 21:29:13 -0700
From: Rick Moen 
To: golugt...@lists.troubleshooters.com
Subject: DMARC mitigation, ezmlm, and golugt...@lists.troubleshooters.com
Organization: If you lived here, you'd be $HOME already.

I'm going to need to skip a _whole_ lot of detail, here, as I'm not
going to write a whole darned tutorial about MLMs (mailing list
managers) and the SMTP forgery problem.  I need to skip a lot and get to
the point.

Yahoo introduced around 2012 a suggested set of extensions to SMTP and
DNS to detect and defeat (1) correction and changes to the internal
contents of the sender's mail, and (2) forgery of the sender's domain.
This was a stack of two standards.  DKIM is message-signing, signing the
body-text and selected interior headers using a key published by the
sending domain in the sending domain's DNS.  DMARC is a higher-level 
standard that allows an organisation to publish in its DNS a policy that
specifies which mechanism (DKIM, SPF, or both) is employed when sending
email from that domain; how to check the From: field presented to end
users; how the receiver should deal with failures—and a reporting
mechanism for actions performed under those policies.

Problem:  The way DKIM was drafted, it is hostile to mailing lists, 
in that any mailing list subscriber's domain that publishes a p=reject
or p=quarantine policy in its DNS DMARC record will arrive at
fellow-subscribers' mail providers, after transiting the MLM, now
failing DMARC validation, and _if_ the receiving SMTP host implements
DMARC and honours the sending subscriber's domain's DMARC policy, the
receiving SMTP host will reject or spambox ("quarantine") the posting as
forged.  Rejections get reported back to the MLM software as 55x SMTP
rejections, i.e., hardfail delivery failures, and thus the _receiving_ 
subscribers (not the sending one) get their "bounce scores" in the MLM
incremented, eventually getting delivery disabled and unsubscribed.

Take a moment to think about how pernicious and iceberg-like (9/10 below
the surface) this effect is.  The _sender_ posting from a
DMARC-afflicted domain perceives and experiences no problem.  It is 
_other_ subscribers, ones whose mail providers enforce the _sender's_
domain's overly aggressive DMARC policy, who mysteriously fail to receive 
postings, over time get high bounce scores, get their delivery disabled, 
etc.  _They_ tend eventually, in bewilderment, complain to the
listadmin, who, unless quite technical and/or warned about this menace,
will be also puzzled and apologetic, but have no idea where the problem
arose.  And, ultimately, the problem isn't even the sending subscriber.
It's DKIM/DMARc.

Important to note, also, Yahoo did not _need_ to define DKIM in such a
haphazard way as to break DKIM alignment just by passing the mail
through an MLM reflector.  They could have drafted it so that
MLM-standard modifications, namely the footer, the extra headers, minor
changes to the Subject header, and so on, were disregarded for purposes
of DKIM/DMARC compliance verification.  They just couldn't be arsed to 
do so.

When it was pointed out to the DKIM/DMARC designers that any DMARC
p=reject or p=quarantine policy is damaging to, and hostile to the
operation of, all the entire planet's MLMs, their official answer, 
as seen in the DMARC FAQ[1], amounts to, "Well tough.  Every mailing
list program in the world will have to get rewritten to compensate for
the way DKIM works."

Really.  That's their position.  Rewrite everything, or we'll sabotage
your mailing lists.

The proprietary LISTSERV software came up with some kludge to work
around the DMARC problem.  I _think_ so did Sympa.  And recent versions
of Mailman2 and Mailman3 have a kludge.

I can speak to how the Mailman workaround -- which, by the way, at least
in Mailman2 versions that offer it, is non-default and must be
defensively enabled by a wary listadmin -- functions.

Alteration 1 of 2:  In the listadmin configuration pages for a mailing
list, go to Privacy Options, Sender Filters.  Change "Action to take
when anyone posts to the list from a domain with a DMARC
Reject/Quarantine Policy" from "Accept" (default) to "Munge From".

Here's the help text for that (in part):

  from_is_list (general): Replace the From: header address with the
  list's posting address to mitigate issues stemming from the original
  From: domain's DMARC or similar policies.

  Several protocols now in wide use attempt to ensure that use of the
  domain in the author's address (ie, in the From: header field) is
  authorized by that domain. These protocols may be incompatible with
  common list features such as footers, causing participating email
  services to bounce list traffic merely because of the address in the
  From: field. This has resulted in members being 

Re: SA DKIM rule

[Rick Moen via luv-main]

Quoting Andrew McGlashan (andrew.mcglas...@affinityvision.com.au):

> Yes, but unfortunately it seems that the bad guys do DKIM, DMARC and SPF 
> better than many "good" guys.

This is nonetheless a win, because if the bad guys are forced to profess
their own domains with bad or unestablished/questionable reputations,
instead of forging domains such as mine with _good_ reputations, then
the remaining problem they pose becomes that much smaller and easier to 
contain.

> That is, the bad guys get it right for their emails and they can still
> be very strong candidates for SPAM.

Certainly!  SPF and its botched rival DKIM/DMARC are not antispam
methods; they are anti-forgery methods.

> So long as you are careful with whom the rules apply, choosing only
> known good domains that send spammy like emails that are not spam,
> well that should be good.

BTW, I protect my domain's own reputation, and make clear my view about
DMARC, thus:

:r! dig -t txt linuxmafia.com. +short
"v=spf1 ip4:96.95.217.99 -all"

:r! dig -t txt _dmarc.linuxmafia.com. +short
"DMARC: tragically misdesigned since 2012.  Check our SPF RR, instead."

Briefly:  Not impressed with how the
Firm-Formerly-Called-Yahoo-and-Now-Called-Yahoo-Again ineptly caused 
a forgery and bounces problem for all of the world's mailing lists.
If they'd designed DKIM/DMARC competently, that could have been avoided,
but they were screw-ups, and, damningly, their _official_ FAQ answer was
"Well, yes, DKIM alignment problems are going to break all of the
world's mailing lists, but MLM software is just going to have to be
reingineered to deal with the problem" (paraphrased).

I could say what I think they should do with that, but it would not be
family-friendly, and would involve indelicate actions with a #6 rasp.

___
luv-main mailing list -- luv-main@luv.asn.au
To unsubscribe send an email to luv-main-le...@luv.asn.au

Re: linux laptop

[Rick Moen via luv-main]

Quoting Keech, Richard (richard.ke...@gmail.com):

> after a few years of using windows for my daily needs, I'm considering
> switching back to Linux.  Any thoughts on this
> laptop
> (Lenovo X1 Carbon)?  

The Gen10 refresh does _not_ yet have a ThinkWiki page.
https://www.thinkwiki.org/wiki/Category:X1_Carbon
(nor does Gen8 or Gen9).

Historically, the X1 Carbon series has been superb for Linux.
Eventually.  But...

Here's a third-party assessment:
https://www.xda-developers.com/lenovo-thinkpad-x1-carbon-gen-10-linux/
Reviewer claims that you can optionally order a preload of some Fedora
or Ubuntu.  Reviewer than somewhat vaguely implies that the customer 
can just install the Linux of choice from installation media, but
there's no showing that he did so.  

FWIW, I looked on Lenovo's product pages, and saw _no_ mention of a Linux
preload option.  I suspect the reviewer is mistaken.

This Reddit thread mentions problems with Linux on Intel's 10nm "Tiger Lake"
processor microarchitecture, and there are signs of a variety of
teething issues in diverse areas:
https://www.reddit.com/r/thinkpad/comments/tqyyc1/thinkpad_x1_carbon_gen_10_with_linux/

My _own_ longtime rule of thumb is "Yes, top-line ThinkPads are
wonderful, but never buy models when they're new, but rather give them
about 2 years to season.  Cabernet Sauvignon, not Beaujolais Nouveau.
;->

___
luv-main mailing list -- luv-main@luv.asn.au
To unsubscribe send an email to luv-main-le...@luv.asn.au

Re: Flounder Meeting Saturday 6th August 01:00UTC

[Rick Moen via luv-main]

I wrote:

> I hope you wouldn't mind clarifying/confirming opening time.

Sent seconds before seeing Russell's follow-up.
___
luv-main mailing list -- luv-main@luv.asn.au
To unsubscribe send an email to luv-main-le...@luv.asn.au

Re: Flounder Meeting Saturday 6th August 01:00UTC

[Rick Moen via luv-main]

Quoting russ...@coker.com.au (russ...@coker.com.au):

> Main topic of the meeting will be SE Linux, but there will be lots of 
> discussion about other FOSS things and a teaser for some future security 
> related meetings.
> 
> https://flounder.linux.org.au/events/flounder-aug-2022-selinux/

I hope you wouldn't mind clarifying/confirming opening time.
Subject header (above) says 01:00 UTC, which equates to 11am 
Melbourne time (Australian Eastern Standard Time zone):

$ TZ='Australia/Melbourne' date -d  'TZ="UTC" 2022-08-06 01:00'
Sat Aug  6 11:00:00 EST 2022
$ 

_However_, the linked page contradicts the above claim, saying instead 
03:00 UTC (with unofficial room opening about an hour before, for
socialising).  As the page says, that is 1pm Melbourne time:

$ TZ='Australia/Melbourne' date -d  'TZ="UTC" 2022-08-06 03:00'
Sat Aug  6 13:00:00 EST 2022
$ 

Bonus link:  Known anglophone LUGs holding regular videoconferenced
meetings/events:  balug.org/covid  (If FLOSS Down Under holds these
events on a continuing basis, I will certainly add an entry.)

Tips about using GNU date(1) to deal with the vexing time-zones problem,
written by yr. humble servant:  balug.org/covid#timezone_conversion

___
luv-main mailing list -- luv-main@luv.asn.au
To unsubscribe send an email to luv-main-le...@luv.asn.au

Re: What happens when ???protestware??? sabotages open source in response to current events? | SC Media

[Rick Moen via luv-main]

Quoting russ...@coker.com.au (russ...@coker.com.au):

> That is criminal behaviour and unacceptable in the free software
> community.  NPM and similar repositories are a bad idea from the
> start.  

Indeed.  Here was my extemporanenous comment on the matter when a friend 
claimed the incident "gave open source a bad name", and that "How long
before someone puts out a version with the location checking reversed?
It shouldn't be impossible for them to trick people into downloading
it."

I wrote:

  I'll ask you a better question:  Why would you trust a fork from just
  someone of an otherwise known codebase?  A person willing to run
  anything from anyone is fodder for the first bad actor (or just bad
  coder) to walk by.  Please don't take this the wrong way, but implying
  that it'd be easy to get many people to trust the untrustworthy strikes
  me as failing Software 101, and in particular open source 101.


  The guy I shave wrote in 1999 a modestly influential essay on the right
  to fork, BTW.  http://linuxmafia.com/faq/Licensing_and_Law/forking.html

  The reasons why in operating systems with package managers as
  gatekeepers we make a point of not trusting upstream are detailed here
  in this editorial footnote of mine:
  http://linuxmafia.com/~rick/weatherwax.html#1

  E.g., there was a time when the upstream maintainers of Adblock Plus and
  of NoScript were in a dumb feud, and one of them inserted code into the
  tip version that sabotaged the other -- but distributions' package
  managers didn't accept that change and avoided sending it out to
  distribution users.  Thus my point about gatekeeping.


  Now, I will tell you that the _particular_ bit of Javascript nastiness
  discussed in the story, node-ipc, is part of a Wild West of Javascript
  stuff that is deliberately kept as its own little "trust me" world, and
  I as a sysadmin would want to have nothing to do with it.  

  When Google wrote the Chromium Web browser (the basis of the proprietary 
  Google Chrome browser), they wrote a Javascript engine called Blink.  
  Third-party yoyos extracted Blink to make it the engine for a (mostly) 
  server-side Javascript runtime environment called node.js.  Then, not 
  done creating baroque horrors, they thought "Wait, node.js needs to 
  have plugins and libraries and stuff.  We're too special to make those 
  handled by system software management, so we're writing our own package 
  manager, domain-specific to node.js.  We'll call it npm."  

  And this node-ipc thing is an npm-installable thing. 

  So, your system security regime and your real package management knows
  absolutely nothing about anything you install using npm.  Your system
  cannot vet that code or make sure it doesn't misbehave or violate system
  policy.  It's like having a wing of your house that doesn't respect
  building codes, was never inspected, and that the homeowner doesn't get
  to check.  Javascript weenies think this is great.  Sysadmins look at
  the idea and say "Not on my system, bud."

-- 
Cheers,"One of the reasons it takes such a long time to make a picture 
Rick Moen  like 'Jaws' is because it's not the time it takes to take the 
rick@linux take that takes the time; it's the time it takes between takes 
mafia.com  that takes the time that takes the takes."  -- Roy Scheider
___
luv-main mailing list -- luv-main@luv.asn.au
To unsubscribe send an email to luv-main-le...@luv.asn.au

Re: Covid19

[Rick Moen via luv-main]

Quoting Keith Bainbridge (keithrbaugro...@gmail.com):

> Thanks Rick.
> 
> I's not ideal, but allows more of us to join in, maybe.
> 
> So microphones off and questions are typed into the notes bit of
> jitsi. A moderator asks questions when appropriate, mostly at the
> end.

That's certainly one way to do it.  Some other open-source online
videoconferencing software provides stronger moderator tools, such as
Big Blue Button, which LUV has used to good effect in the past.

It might be that a more-informal set of arrangements would work, too.
I would actually recommend going light on moderator control unless/until
it proves needed, but prepare in advance to use the available controls
if they're required.

(Just as Russell perceives LUGs to be prone to extremism, I perceive 
LUGs to tend to flirt with needless hyper-control.  ;->  )

___
luv-main mailing list -- luv-main@luv.asn.au
To unsubscribe send an email to luv-main-le...@luv.asn.au

Re: Covid19

[Rick Moen via luv-main]

Quoting Keith Bainbridge (keithrbaugro...@gmail.com):

> I have enjoyed the few on-line meets I have watched, so I'd like the
> flexibility of watching on-line when I can to continue if that's not
> too difficult. I gather I'm not alone here.

Just to elaborate briefly on the notion of a hybrid meeting:  Picture an
in-person venue where those who are provably vaccinated and willingly
assume risk can gather.  In the room is a large monitor with speakers
and a quality microphone (I use one of these:
https://www.amazon.com/gp/product/B0779PKLV9/ ). Those are connected to
a computer running a Jitsi Meet conference, set to displqy in Gallery
,Mode.  The presenter might be among the remote online participants, or
might be at the in-person venue.

I've had modestly good success with those.  "Hybrid" meetings are
definitely a different duck from either all-online or all-in-person
meetings, and maintaining fruitful interaction between the two groups of
attendees is awkward and requires some care and diligence.  Using good
speakers and microphone helps.
 
___
luv-main mailing list -- luv-main@luv.asn.au
To unsubscribe send an email to luv-main-le...@luv.asn.au

Re: Covid19

[Rick Moen via luv-main]

Good people:  I sent two reactions to Russell's posting to luv-talk 
because I thought my comments were further from luv-main's topic mandate
than was Russell's original post.  They _might_ be topical enough, here;
I was trying to err on the side of good netiquette.

At this point, I was intending to reference them by URL, but it appears
that Web links to Mailman3's Postorius archiver are now broken(?).  
Starting from https://www.luv.asn.au/faq/ , I cannot navigate to
archives any more.  (The broken links I noted in the FAQ earlier are
also still broken.)

Quoting Brian May (br...@linuxpenguins.xyz):

> It is a concern of mine that governments are rushing to open up too much
> too soon, especially as under 12 year children can't get vaccinated yet.
> While we don't have many young children attending meetings, people who
> do attend may have such kids at home, who are still at risk (I have one
> here who turns 12 next month).

I commend LUV's caution, in this regard -- being concerned not just
about breakthrough infection, but also children, the immunosuppressed,
and the remaining unvaccinated.

> When we do decide to have in person meetings again, do we want to impose
> the requirement that everybody should be double vaccinated?

As a distant foreigner, I will refrain from advising, but I will mention
(as I did in one of my luv-talk postings) that my local LUG here in
Silicon Valley, along with several other San Francisco Bay Area LUGs,
has had good success with "hybrid" outdoor meetings interacting with
remote participants who're on Jitsi Meet.  In-person attendees are
required to bring proof of vaccination.  Example announcement:
http://linuxmafia.com/pipermail/conspire/2021-October/011793.html

As the weather improves (becomes drier) in Vic., perhaps that will 
become more feasible, and could be pondered as to whether it would be
wise (if local infection prospects have improved enough).


Should I cross-post back to this thread my comments on luv-talk?
Some of it concerned a modelling tool (https://www.microcovid.org/)
for realistically quantifying COVID-19 risk for possible activities.


___
luv-main mailing list -- luv-main@luv.asn.au
To unsubscribe send an email to luv-main-le...@luv.asn.au

Re: Close shave: Missing Window Manager on Ubuntu 20.04 XFCE

[Rick Moen via luv-main]

Quoting Rodney Brown (rdbrown...@gmail.com):

> After a reboot, I lost the Window manager, so no frame, title,
> minimize, maximize or close buttons.
> 
> Lots of ineffectual thrashing around with a Ctrl-Alt-F1 console
> sessions, system-ctrl session manager restarts.
> 
> xfwm4 --replace provided a window manager, but mouse issues left it
> uncomfortable.
> 
> It might have been possible to use another console session and lynx
> or w3m to google around, but I was glad of another machine to google
> with...
> 
> Finally the right search terms found the advice that a damaged,
> cached session could cause this. The recommended rm fixed the
> problem.
> 
> I don't know whether this is relevant to other session
> manager/window manager combinations.
> 
> rm -r ~/.cache/sessions/

X session managers cause a significant number of problems.  Have you 
considered just not running one?

The purpose of an X session manager is to keep track of what graphical
applications are running and their approximate state, such that if the
X session terminates abnormally, upon launching a new X session, the
same applications can be launched with the same state.

I actually actively do _not_ want that.  In particular, if some
application is taking my X session down, the last thing I want to have
happen automatically at next X startup is for it to be autolaunched
again in the same fashion.  Also, as you've seen, if the X session
manager's own state data gets fried, it can sabotage X.  

All of those risks are necessary just to perform a function I don't
think is desirable.  So, for me, it's an obvious choice;  Don't run one.
No session manager; no session manager problems.

___
luv-main mailing list -- luv-main@luv.asn.au
To unsubscribe send an email to luv-main-le...@luv.asn.au

Re: Meeting 30th Sep 6pm to 8pm.

[Rick Moen via luv-main]

Quoting Alexar Pendashteh (h...@alexar.me):

> There is no event scheduled for Thursday but nothing stops us from
> having one!
> 
> We can get online at 6pm and watch a video together about SE-Linux. We
> can have a discussion in text during the play and in audio afterwards.

I am hoping to join (for at least a while) despite time-zone skew,
towards which end, please forgive my faulty memory, but I cannot
remember where online LUV currently hold meetings.

There may be a few items of LUV public outreach needing attention.
E.g., I thought, "Ah, I'll just look in the archives for the online
meeting location."  The Mailman3 footer no longer seems to point to the
archives, as it did with Mailman2:

> ___
> luv-main mailing list -- luv-main@luv.asn.au
> To unsubscribe send an email to luv-main-le...@luv.asn.au

So, I thought, "Ah, well, I'll find it via the LUV Web site.
https://www.luv.asn.au/ has a Mailing Lists link, going to
https://lists.luv.asn.au/mailman3/postorius/lists/ .  Selecting any
mailing list, such as this one, brings up a new-style-as-of-MM3
"listinfo" page, such as
https://lists.luv.asn.au/mailman3/postorius/lists/luv-main.luv.asn.au/
At first, I was perplexed as the normal (MM2-style) archives link seemed
to be missing, then I noticed "Archives" on a top navbar (very
non-traditional place).  Selecting that goes to a top-level Hyperkitty
(new MM3 archiver) container page, not a mailing list-specific one:
https://lists.luv.asn.au/mailman3/hyperkitty/

And there, the latest luv-main posting included in the back-postings
archive is one by Russel on 16 Jan 2021 -- so it appears that archiving
has been broken for a while.

In truth, before following the "Mailing Lists" link on
https://www.luv.asn.au/ , I stopped at the FAQ, and note that the
mailing list links at https://www.luv.asn.au/faq/#The_LUV_mailing_lists 
and many others in the FAQ got broken by the MM2 -> MM3 transition and
will need some attention, as opportunity permits.

It would be lovely if https://twitter.com/linuxusersvic had upcoming
event venue/date/time details, and also the Events link on
https://www.luv.asn.au/, which currently shows no upcoming events.

I notice that LUV participate in Meetup.com , e.g.,
https://www.meetup.com/Linux-Users-of-Victoria/events/jnbsfsyccnbhb/
claims there's one coming up on Tu 5 Oct. 2021 about "Software
Packaging".  

There's a default setting in Meetup where the details of how to attend
an event (in this case, an online one) are displayed only to logged-in
persons using Meetup, Inc. logins.  I understand the advantages of this
setting, but one regrettable effect is that people like me who find
Meetup, Inc. excessively obnoxious (as, e.g, a spam-source) and long ago
deleted our Meetup logins, cannot get meeting details via the event
listings.


Anyway, would someone be kind enough to post the online meeting
location?  Thank you kindly.

-- 
Cheers,   Grammarian's bar joke #24:  A verb walks into a bar,
Rick Moen sees a beautiful noun, and suggests they conjugate.  
r...@linuxmafia.com   The noun declines.
McQ! (4x80)
___
luv-main mailing list -- luv-main@luv.asn.au
To unsubscribe send an email to luv-main-le...@luv.asn.au

Re: Instruction to join tonight's event (7pm on Tuesday)

[Rick Moen via luv-main]

Quoting Duncan Roe (duncan_...@optusnet.com.au):

> duncan_...@optusnet.com.au cannot post to luv-main! This seems to be because 
> all
> but 1 of optus's mail servers are listed on
> https://whatismyipaddress.com/blacklist-check
  ^

Useful, thanks!  I've added it to the other three I keep listed on
http://linuxmafia.com/kb/Mail/ :

http://www.dnsbl.info/
http://multirbl.valli.org/
https://mxtoolbox.com/blacklists.aspx

___
luv-main mailing list -- luv-main@luv.asn.au
To unsubscribe send an email to luv-main-le...@luv.asn.au

Re: Instruction to join tonight's event (7pm on Tuesday)

[Rick Moen via luv-main]

Quoting Andrew McGlashan (andrew.mcglas...@affinityvision.com.au):

> The more recnent history of jitsi isn't promising, so it might not
> even be worth considering these days.  Ownership by Atlassian and
> beyond.

_Former_ ownership by Atlassian (2015-03-04 to 2018-10).  In 2018,
relevant trademarks and copyrights (to the code) were bought out by 8x8,
Inc., a California VoIP provider, which has continued to develop the 
Jitsi Meet codebase as Apache Licence 2.0 open source code.

Personally, I have no special reason to hate 8x8, Inc., and all
development has been transparent and highly forkable by the community,
so even if they turn out to be operated by James Moriarty, the Napoleon
of Crime, I'm not sure what the relevance would be.  I mean, they're not
even Oracle Corporation.  ;->

-- 
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)
___
luv-main mailing list -- luv-main@luv.asn.au
To unsubscribe send an email to luv-main-le...@luv.asn.au

Re: Instruction to join tonight's event (7pm on Tuesday)

[Rick Moen via luv-main]

Quoting Alexar Pendashteh (h...@alexar.me):

> Regarding the meetup being a pripriotry platform, I agree that it is not
> the ideal solution however, our use of Meetup is solely for advertising our
> events and helping new members discover us. Some other groups are using
> meetup.com as their primary base and I agree with you that that is not a
> good idea. For us, our base is our website which uses open source software.
> And our events, so far has been also using open source software which some
> of them we also own the infrastructure they run on. So, in short, meetup.com
> has served us very well so helping new members finding us. It would
> definitely be great to advertise our events on platforms that have audience
> and are not propriotary. I don't personally know any.

Some comments about Meetup, from my own perspective as the maintainer of a
local (to me in Silicon Valley) online calendar (named 'BALE') of upcoming
Linux & related technical events:

http://linuxmafia.com/kb/Essays/meetup.html

-- 
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)
___
luv-main mailing list -- luv-main@luv.asn.au
To unsubscribe send an email to luv-main-le...@luv.asn.au

Re: gphoto2 file size limitations

[Rick Moen via luv-main]

Quoting Brian May (br...@linuxpenguins.xyz):

> But it is disabled by default. To enable it you need to run Windows
> software. But this requires registration to download. But you cannot
> register from Australia. WTF!!!

Perhaps you or someone you know who has access to a commercial VPN 
provider can initiate download via passthrough to a country where
download is permitted.

-- 
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.
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

(forw) Reminder: https://meet.jit.si/ALE-NW

[Rick Moen via luv-main]

Just starting

- Forwarded message from Rick Moen  -

Date: Sun, 20 Sep 2020 10:08:40 -0700
From: Rick Moen 
To: consp...@linuxmafia.com
Subject: Reminder: https://meet.jit.si/ALE-NW 
Organization: If you lived here, you'd be $HOME already.

The first LUG to respond correctly to the pandemic by having online
meetings, Atlanta Linux Enthusiasts, is holding its regular 3pm-6pm
Eastern Daylight Time meeting today.

That's noon PDT.  See you there, perhaps.

https://meet.jit.si/ALE-NW

As always with Jitsi Meet, Chromium, or Google Chrome, or other
Chromium-derived browsers are reported to give best results.  I see that 
audio-only participation via telephone is also possible as follows:


ALE-NW
To join your meeting, dial one of these numbers and then enter the pin.

PIN: 2273 9711 43

Country Dial-in Numbers
US  +1.512.647.1431
UK  +44.203.885.2179
France  +33.1.87.21.0005
Germany +49.89.380.38719
Netherland  +31.85.208.1541
Spain   +34.932.205.409
Canada  +1.437.538.3987
Australia   +61.8.7150.1136
Brazil  +55.21.3500.0112
Japan   +81.3.4510.2372
Switzerland +41.61.588.0496


- End forwarded message -
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

(forw) Re: [conspire] CABAL meetings of the apocalypse, Saturday, Sept. 12, 4pm

[Rick Moen via luv-main]

[Online event described will be at 9am Sunday AEST, Melbourne time.]

The first virtual meeting of CABAL, the LUG that normally meets in West
Menlo Park, California (which as a reminder is one of the relatively
sane parts of the USA).  

Thanks again to Trent W. Buck for the cool timezone-dumping trick, which 
he'll note I swiped.

There will be no special topic, though I might give a briefing about my
experience installing in a tearing hurry and administering Jitsi Meet on
Amazon EC2 to provide one of major functions of the recent World Science
Fiction Convention ('Worldcon') in Wellington, New Zealand, when it was
obliged to operate as the first-ever virtual Worldcon.


- Forwarded message from Rick Moen  -

Date: Sat, 12 Sep 2020 00:26:42 -0700
From: Rick Moen 
To: consp...@linuxmafia.com
Subject: [conspire] CABAL meetings of the apocalypse, Saturday, Sept. 12, 4pm
Organization: If you lived here, you'd be $HOME already.

Hi ho!  Seeing that the world is falling apart, the sky is the 
colour of a dead television channel, and the air is barely breathable, 
let's get together on Jitsi Meet!


CABAL Virual Edition:  Saturday, Sept. 12, 2020, 4pm - 8pm Pacific
Daylight Time.[1]

Where?  Here, via videoconferencing:  http://meet.jit.si/cabal 


You will need:

o  Computer w/supported Web browser.  Best results reported with:
  o  Chromium
  o  Chrome
  o  Microsoft Edge v. 79.0.309 or later
  o  (some others, e.g., Firefox, might work but are not guaranteed)

o  A computer with mic and speakers/headphones.  Headphones/earbuds
   are recommended (because they avert audio feedback loops).

Upon joining @ that URL, your browser will probably ask if the page 
may have permission to connect to your microphone and speaker.  Say yes.


If you haven't done computer videoconferencing before:

o  You can check your setup for problems at https://test.webrtc.org/ .
   (Don't worry about minor bobbles like 'Reflexive connectivity'
   getting dinged.)

o  You might want to show up 15 minutes early, to thrash out problems.
   (Problems are common during first-time videoconferencing.)


I will have fresh garlic bread and other home cooking.  You probably won't,
unless you're in my household, but, hey, that's the year 2020 for you.
I expect we'll continue with 2nd Saturday 4-8 pm online CABAL meetings
for the duration of the Martian Death Flu.

When will reality get restored?  Haha.  "Der mentsh trakht un got lakht."


I will promise with extreme insincerity to give a prize to the farthest
flung videoconfercing participant.  Astronauts calling from the ISS
will automatically win.


[1] If not in the Pacific Daylight Time time zone, check using 
https://www.worldtimebuddy.com/  Or try something lik this Bourne shell
recipe (tested on Debian):

:r! grep worldclock .bashrc
alias worldclock='zdump 
America/{Los_Angeles,Mexico_City,New_York,Sao_Paulo} 
Europe/{London,Berlin,Moscow} Asia/Calcutta PRC Japan 
Australia/{Perth,Melbourne}'

-- 
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)

___
conspire mailing list
consp...@linuxmafia.com
http://linuxmafia.com/mailman/listinfo/conspire

- End forwarded message -
- Forwarded message from Rick Moen  -

Date: Sat, 12 Sep 2020 00:47:41 -0700
From: Rick Moen 
To: consp...@linuxmafia.com
Subject: Re: [conspire] CABAL meetings of the apocalypse, Saturday, Sept. 12,
4pm
Organization: If you lived here, you'd be $HOME already.

Quoting Rick Moen (r...@linuxmafia.com):

> CABAL Virual Edition:  Saturday, Sept. 12, 2020, 4pm - 8pm Pacific
> Daylight Time.[1]
> 
> Where?  Here, via videoconferencing:  http://meet.jit.si/cabal 


Forgot to say:  If you can't (or would rather not) videoconference in,
via Web browser, you can _instead_ join audio-only by dialing in
telephonically.  

Call-in numbers and access PIN follow.

PIN: 3654 3335 40

Country Dial-in Number
US  +1.512.647.1431
UK  +44.203.885.2179
France  +33.1.87.21.0005
Germany +49.89.380.38719
Netherlands +31.85.208.1541
Spain   +34.932.205.409
Canada  +1.437.538.3987
Australia   +61.8.7150.1136
Brazil  +55.21.3500.0112
Japan   +81.3.4510.2372
Switzerland +41.61.588.0496


___
conspire mailing list
consp...@linuxmafia.com
http://linuxmafia.com/mailman/listinfo/conspire

- End forwarded message -
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Jitsi

[Rick Moen via luv-main]

Quoting Keith Bainbridge (keithrbaugro...@gmail.com):

> Russell, Rick mentioned earlier today that you are restricting
> access to meets. Should I need a password?  that I haven't noticed.

I can't remember what I might have said except perhaps that, on 
Russell's server, a room isn't available to ordinary, anonymous users
until someone with prearranged username/password credentials enters it
to 'open' the room.  Thus, the 'a' room in use on Russell's server
became available this evening around 6pm when Russell authenticated
himself to Jitsi Meet, and opened it.

Nobody has otherwise set any password.  (In Jitsi Meet, it's possible to
set / unset / change an entry password for an in-use room, e.g., if it
suddenly becomes necessary to deter disruptive people from entering.)


___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Jitsi

[Rick Moen via luv-main]

Quoting Keith Bainbridge (keithrbaugro...@gmail.com):

> I see that my mic is registering some back-ground noise at times.
> Can anybody hear that?

Speaking for myself, I'm not hearing background noise in the room, 
only conversation among Russell, Andrew, Wen, and occasionally me.
(Nick just now joined us, too.)

We see a user panel representing you appear and seem to be connected
(with video and audio muted), and then some 10 seconds later
disconnecting -- and then the cycle repeats.

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Jitsi

[Rick Moen via luv-main]

Quoting Keith Bainbridge (keithrbaugro...@gmail.com):

> Evening all, particularly those chatting in the meet. I saw Russell,
> Rick and 3 others in the brief time I get between dumps-out.
> 
> You can probably see how long I Russell and a couple of others have
> their mic's muted, and a couple have camera muted as well.

Yes, we've been seeing you drop in and out repeatedly.

> I do hear a noise like somebody is blowing into a mic when I rejoin
> the meet automatically.   I figure it's the link opening

That indeed sounds like the low-key 'whoosh' sound when any new member 
joins a room.

-- 
Cheers, "It's still magic even if you know how it's done."
Rick Moen   -- Terry Pratchett, _A Hat Full of Sky_
r...@linuxmafia.com 
McQ! (4x80)
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Jitsi

[Rick Moen via luv-main]

Quoting Russell Coker (russ...@coker.com.au):

> LUV members are welcome to inspect LUV services and try to find configuration 
> errors.  If you suspect that I may have made a mistake in access control then 
> test it out and let me know of any problems that occur.

I doubt there are configuration errors, but have a few modest
suggestions that I'll post to your blog entry on the subject.
(You may well have already considered them, but I figure the 
discussion is benificial.)  Thank you again for the good work, and 
I look forward to chatting again, this evening.

-- 
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)
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Jitsi

[Rick Moen via luv-main]

Quoting Keith Bainbridge (keithrbaugro...@gmail.com):

> I have just enetered the meet with
> 
> https://j.luv.asn.au/a
> 
> after some experimenting with android jitsi app. It then worked as a
> link in chromium.   I'll have it running in the background from
> mid-afternoon - waiting for the host, and volume low - or I could
> claim I am the host and see what happens.
  

If you 'claim your are the host' (perfectly harmless; try it), 
Jitsi Meet asks you for a known username/password, and won't let you
into the room without it.  This is because Russell has (wisely) 
configured the server in what is called 'secure domain' mode:  Only
persons who've authenticated as authorised users are permitted to create
and thus open rooms.  Once a room is open, then anonymous members of the
public may then enter it.

The Jitsi Project's meet.jit.si server (available for use by the public
at large), _by contrast,_ runs in an entirely non-authenticated mode.  
Anyone may create a room on it, upon request.  (Persons in that room 
can then, however, add a password for entry.) 

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Jitsi

[Rick Moen via luv-main]

Quoting Andrew Pam (and...@sericyb.com.au):

> Hmm.  It mostly fails with Firefox and mostly succeeds with Chrome, so
> maybe that was the problem.  Even with Chrome the "Reflexive
> connectivity" and "Video bandwidth" tests fail.  Are there any ports I
> have to open on my firewall for Jitsi?

Checking my rushed notes for server setup of jitsi.conzealand.nz :

80/tcp for Web UI HTTP to redirect
443/tcp for Web UI HTTPS
4443/tcp for RTP media over TCP  (transport for WebRTC A/V)
1/udp for RTP media over UDP
optional:  2-20050/udp for jigasi (SIP access)

(That's for a fairly generic setup, which ended up not including SIP.)

ISTR that the two you say fail don't necesarily matter much.

-- 
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)
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Jitsi

[Rick Moen via luv-main]

Quoting Keith Bainbridge (keithrbaugro...@gmail.com):

> If anybody else is having trouble joining Russells meet, please try
> this, as a proof that you can join a meet
> 
> https://meet.jit.si/SBCCandSBCGeelongForums

FYI, Russell and I were both successfully in https://j.luv.asn.au/a .
(And then I popped into your meet.jit.si room and said hullo there, too.

I've heard that this testing site is also useful for debugging
connection problems.  It does a comprehensive test of your connection &
Web browser's ability to support the WebRTC videoconferencing protocols
that underlie Jitsi Meet.

https://test.webrtc.org/

-- 
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)
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: [luv-talk] LUV status

[Rick Moen via luv-main]

Quoting Russell Coker (russ...@coker.com.au):

> Thanks Rick for pointing out other video meetups.  Rick if there's any 
> interesting Linux video meetup you plan to join please send the link to luv-
> main.

Will be glad to.

> 2020 is a dumpster fire.  I'm more depressed than usual and finding it
> difficult to arrange things.  I've setup a LUV Jitsi VM with low ping
> times in Melbourne (less than 5ms ping time to www.theage.com.au), we
> just need to arrange some stuff.

Russell, if I may help or advise, I of course will -- but I take it 
as given that you have this in hand.

-- 
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)
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Black Lives Matter

[Rick Moen via luv-main]

Quoting Russell Coker (russ...@coker.com.au):

> https://twitter.com/BiellaColeman/status/1268988146181648388
> 
> Biella Coleman (who is known for her anthropological research on the Debian 
> community among other things) just Tweeted about DKG (ACLU staff and Debian 
> Developer) being beaten by the police.

Biella's a longtime friend of mine.  The treatment of DKG (among many
others) by NYPD is truly shocking.

-- 
Cheers, Some people, when confronted with a problem, think,
Rick Moen   "I know, I'll use Dvorak!"  Now they have k,s rosnpdm;e
r...@linuxmafia.com   -- Colter Reed
McQ! (4x80)  
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: mailman

[Rick Moen via luv-main]

Quoting Russell Coker (russ...@coker.com.au):

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959435
> 
> Mailman has just been removed from Debian/Unstable because it is "obsolete".  
> Why would it be regarded as obsolete and if so what should we replace it with?

Debian-recommended replacement is package mailman3 or metapackage
mailman3-full.

Personally, I'm not looking forward to that, as GNU Mailman 3.x
is IMO a poster-child for Second System Effect.

The bug claims the cause of breakage in package mailman is dependency
python-dnspython becoming no longer available.  That's from this
upstream:  http://www.dnspython.org/  One notes that upstream did a
migration from Python 2.x to Python 3, and I'm pretty sure that's the
root cause of the cascade of package removals, i.e., the familiar
and current Mailman 2.x versions all work with Python 2.7.x, while
Mailman 3 goes with Python 3.

-- 
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)
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Video Conferencing

[Rick Moen via luv-main]

Quoting Julien Goodwin (luv-li...@studio442.com.au):

[Chromium:]

> Yes, Google absolutely accepts changes back, I believe Microsoft have
> had a bunch of things merged back in from their Edge browser.
> 
> What level of CLA / grant etc. is required for that I don't know.

Thank you, Julien.  That's good to know, and kind of you to speak up.

-- 
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 
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Video Conferencing

[Rick Moen via luv-main]

Quoting Andrew McGlashan (andrew.mcglas...@affinityvision.com.au):

> Okay, I was wrong then.  However, Chromium is still, in some respects
> "Google property".  Not sure which one gets updates first or how well
> they bounce those updates back and forth.

The code checkins occur at the Chromium repo, which is a rolling
codebase with (usually) multiple daily snapshots.  Occasionally, Google
decides to take a snapshot of the code, add in proprietary extras, and
release that as the next version of Google Chrome.

Yes, certainly Chromium is in some respects 'Google property', in that 
although anyone has the right to fork, only very rarely does anyone
presume to do so, on account of maintenance being a gigantic job.
(One example is the ungoogled-chromium browser.  There are also a 
number of non-Google proprietary browsers based on Chromium.)

I am unclear on whether Google accepts code contributions from
non-employees into its repo for Chromium.

-- 
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 
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Video Conferencing

[Rick Moen via luv-main]

Quoting Andrew McGlashan (andrew.mcglas...@affinityvision.com.au):

> Definitely not a support of Google Chrome, but it will likely get
> security patches more quickly than Chromium.

This seems surprising, given that Chromium is the base code:  My 
understanding is that Google occasionally takes a snapshot, decides to
deem it stable, and adds a few few proprietary extras before releasing
that as a Google Chrome thing.  (I have avoided ever running Google
Chrome, as I try to have minimal dealings with the second-nosiest
company on the planet, and see no reason to trust its binary-only code,
given ample alternatives.)

Of course, the burden is on users (and distro packagers) to refresh as
suits local/distro policy.  Just getting a Chromium daily build, e.g.,
directly from Google at chromium.org (ugh! proprietary-OS bad habits
ahoy), and then _never updating_ would have adverse results over time.
So, Don't Do That, Then.

Perhaps you're referring to the lack of an 'automatic update' feature
internal to the Chromium codebase.  Personally, I consider those
undesirable generically, tending to interfer with a distro's own
maintenance policy.  (Proprietary OSes of course don't have distro
policies, so sucks to be them.)

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Video Conferencing

[Rick Moen via luv-main]

Quoting Russell Coker (russ...@coker.com.au):

> https://www.schneier.com/blog/archives/2020/04/security_and_pr_1.html
> Bruce Schneier wrote an informative blog post about the problems with Zoom.

The Citizen Lab report from two days ago, to which Schneier links, is
particularly damning, e.g., the firm lying about the nature of the
crypto.
https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto-a-quick-look-at-the-confidentiality-of-zoom-meetings/

> https://jitsi.org/
> He recommends Jitsi which has Debian packages among other things.

I participate in Jitsi Meet videoconferences on a Devuan Project server
just about every week, and it works consistently very well indeed --
bearing in mind that the requirement don't include much as to security,
and the Jitsi project doesn't promise much.

Although in theory any modern Web browser able to support WebRTC would
suffice, I always recommend Chromium.  People trying to use, e.g.,
Firefox are more likely to have problems.  (I suppose one could equally
pick Google Chrome, but why use a proprietary variant of Chromium when
you could use Chromium?)

-- 
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 
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: meetings

[Rick Moen via luv-main]

Quoting russ...@coker.com.au (russ...@coker.com.au):

> https://en.wikipedia.org/wiki/Coronavirus_disease_2019

Outstanding single-stop resource maintained by a qualified expert:
https://arstechnica.com/science/2020/03/dont-panic-the-comprehensive-ars-technica-guide-to-the-coronavirus/

Anyway, as I was saying the other day to another mailing list:
Keep Calm, Keep Two Metres Away, and Hope for a Vaccine
(suggested poster text).

-- 
Cheers, "Why doesn't anyone invite copyeditors to parties,
Rick Moen   when we're such cool people out with whom to hang?"
r...@linuxmafia.com-- @laureneoneal (Lauren O'Neal)
McQ! (4x80)
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Running a public DNS server at home - Is this safe?

[Rick Moen via luv-main]

Quoting David Zhan (david.zhan.l...@gmail.com):

> Hi everyone,

Everyone:  'Hi!'

> I am thinking about running a public DNS server (with Pi-Hole)  at
> home, but not sure if that's safe.

Safe against what?

In the security field, we tend to use concepts like 'threat model' and
'attack surface'.  You may want to look those up and consider what your
concerns are and how to articulate them.

Exposing any network daemon to remote networks, not to mention the
public Internet, necessarily expands your attack surface.  This is 
why you should (1) not run public-facing software without compensating
benefit, (2) be picky about which software option you elect to run and
how it's configured, and (3) maintain your system, e.g., roll out
necessary fixes  that may addresss security problems in a timely manner.


Relevant to that, you may be pondering choice of software.  Here are
some good maintained open-source DNS daemons available for Linux:

Authoritative-only:
--
Knot DNS
NSD for small/medium-sized deployments
PowerDNS Authoritative Server for large sites
YADIFA

Recursive-only:
--
Deadwood
dnscache from djbdns/dbndns, which appears to be the best-maintained fork
   of djbdns
PowerDNS Recursor
Unbound

Generally, I prefer NSD (auth-only) and Unbound (recursive-only).

Notably absent from that list is BIND9.  Some more details about that
are in my DNS software bestiary:
http://linuxmafia.com/faq/Network_Other/dns-servers.html

If the category distinctions (authoritative, recursive, etc.) are
unfamilary, my somewhat puckish allegory about the 'Village of Lan'
(that I penned in 2010) may help:
http://linuxmafia.com/~rick/lan.html


> I planned to share this server with my friends in Melbourne but I
> don't want them be able locate my home.

Well, far be it from me to criticise what you say you want to do, but,
FWIW, I long ago decided that, for my _own_ Internet presence, I would
pointedly take the opposite approach, e.g., in the (totally
discretionary) LOC (location) reference records I publish in my domain
zones, e.g.:

$ dig -t LOC linuxmafia.com. @ns1.linuxmafia.com. +short
37 25 53.825 N 122 11 52.128 W 15.00m 1m 1m 10m
$ 

In fact, to lampshade the joke, I also publish an 'ICBM address' on my
personal Web page, accurate to about a centimetre, giving the exact
location of my favourite chair in my living room.

   ICBM: 122.204196°W, 37.430410°N, 49.28 metres elevation

I have it on good authority that my 'Here, let me make it trivial for you
to determine the exact physical location of me and my computing gear' 
spooked at least a couple of people who set out to 'doxx' me and found
it worrying that I rolled out the red carpet for them.  ;->




> Questions:
> 
> Will my user be able to locate my home accurately?
> (To suburb is acceptable, but street is a bit scary..)

Assuming you don't do as I do and flamboyantly publish that information
in LOC records and ICBM address data, then the user's ability to do that
would be limited to the accuracy of geoIP data, which also tends to cost
money to the consumers of that data.  Ever notice that Google News makes
a guess at your physical location based on your public IP address?
That's using geoIP services.  But notice that it's fairly approximate,
at most isolating the IP's location to a neighbourhood. and sometimes
it's comically wrong, depending.


> Will I be facing other risks? 

Of course you will.

This is where you start studying security, the way we sysadmins do.
One modest starting point, a piece I wrote about a LinuxWorld Expo
security talk in 2000:
http://web.archive.org/web/20080427075329/http://security.itworld.com/4352/LWD000829hacking/pfindex.html




> P.S.: I will put that server behind a properly configured firewall, so
> the server itself should be alright.

{headdesk}

Nope.

Most people use 'firewall' to mean 'set of IP/port filter rulesets'.  
Consider a hypothetical example server.  It has a minimally configured 
instance of NSD for authoritative nameservice to the public Internet, it
runs Portable OpenSSH for remote administrative access, runs atop Linux, 
and has no other network services whatsoever.  Therefore, the attack
surface consists of:

o  code exposed on port 22 (SSH)
o  code exposed on port 53 (NSD)
o  Linux TCP/IP stack

Add to that a 'properly configured firewall'.  What does your attack
surface now consist of?  Answer:  the same, except there is additional
possible exposure to stack congestion on account of the netfilter rules.
> 
> ___
> luv-main mailing list
> luv-main@luv.asn.au
> https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: upgrade

[Rick Moen via luv-main]

Quoting Mark Trickett (marktrick...@gmail.com):

> A small query, nothing fixed, but when is Buster expected
> to be released? 

Russell already gave you the serious answer, so I can now supply the
frivolous one that doesn't help you.   ;->  There are two traditional
answers inside Debian Projet to the question 'When will the next stable
release be?'

1.  When it's ready.
2.  Sooner if you help.

Some would add, and in fact have been known to print on t-shirts:

3.  Debian: Even hell freezes faster.

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: scsi

[Rick Moen via luv-main]

Quoting Andrew Greig (pushin.li...@gmail.com):

> I have a SCSI scanner Epson GT7000, which I love, but occasionally in
> the past I may have turned it off, and as a consequence it is not
> detected at boot. In the old days when boot times were quick I would
> turn it on and reboot, but boot up time is not trivial in my Ubuntu
> system and so I am inquiring is there a way for the system to discover
> that the scanner is now turned on. Is there a way for the device to
> say "hey, I'm here now, let's play".  Or for the system to say, "well
> you weren't here at the start, but we'll let you play"

As the root user, try:

echo 1 > /sys/class/scsi_device/device/rescan

(Variations on that are covered at
https://thornelabs.net/2012/08/22/linux-rescan-scsi-bus.html, which
please also see.[1])

There is also a related script rescan-scsi-bus.sh traditionally said to
be furnished by something called sg3_utils, which I have not seen.)

(Disclaimer #1:  The first tip worked long ages ago, but I've not tested
it in a long time.)

(Disclaimer #2:  I am in a very different time zone where I am up a bit
past my bed time, ergo not ideally situated to fact-check before trying
to help.  Sorry, good sir.)

[1] Web-search on 'scsi rescan linux' if not yet getting anywhere.
Could work.

-- 
Cheers,"He who laughs last, lasts."
Rick Moen   -- Leo Rosten
r...@linuxmafia.com
McQ! (4x80)
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: domain-checking tools (was: Melbourne IT - anyone have any contacts?)

[Rick Moen via luv-main]

Quoting brad...@northtech.us (brad...@northtech.us):

> As an admin I can't say that I concur in the least - especially when
> there is the choice of proxies in the form of privacy bureaus.

You'll note I didn't say I agreed with the policy, just that the
rationale made sense.  (I expect my overall view ought to be clear given
that I've been trying for over a decade to promote and maintain software
tools that rely on public WHOIS data.)

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: domain-checking tools (was: Melbourne IT - anyone have any contacts?)

[Rick Moen via luv-main]

Quoting Anthony (anthony-...@hogan.id.au):

> The Aus approach was indeed taken due to spam considerations, trying to
> limit data mining of whois records (the daily rate limiting), and renewal
> scams based upon listed expiry dates (I remember reading through auDA doco
> as it came into being after Melbourne IT lost the exclusive gig). 

Yes, after initially being astonished at the withholding of expiry dates
in .au domain WHOIS, I read about the rationale, and one must of course 
acknowledge that it makes sense.

FWIW, I offered Ben's and Jesse's domain-check scripts as candidate 
solutions for Russell's problem because he said merely that he was
seeking a tool to monitor expiration status for _domains_.  The 
stated context wasn't specifically _.au_ ones -- but, note, I also made
sure to highlight the _Linux Gazette_ article to highlight the .au
roadblock so Russell wouldn't be surprised.

All GTLDs (I think) and _almost_ all country-code TLDs (ccTLD) domains'
data parse fine.  (I think.)  ICANN keeps creating weird and obscure
GTLDs, though, which is one reason why any tool like Ben's and Jesse's
needs occasional maintenance.  And the _other_ reason is that even
long-established TLDs sometimes change their WHOIS date reporting in
ways that break parsing, for no good reason.


To craft a monitoring tool for .au domains, I believe one would need to
write code to login to registrar records as the owner, and parse the
expiry data there.  Which _could_ work.  Or:
https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454

;->

> Back on track... I think we're seeing the eventual death of WHOIS, due to
> GDPR.

Interesting point.  WHOIS service, and most particularly classic 43/tcp
WHOIS service, has been the red-headed stepchild for decades for other
reasons, too.  For one thing, the current breed of desktop users almost
never even think to use it.  MS-Windows doesn't come with a client, and
MacOS X has only a Unix-standard console client, so Macheads typically
never notice it.  And, as with the main reason why Gopher was supplanted
by the Web, port-43 WHOIS service is text-bound and non-advertising-friendly.

Quite a few ccTLDs offer WHOIS only via Web front-ends, partly in
consequence.

And now, as you say, argubly there's Yet Another GDPR Objection to deal
with.  I fear you're right.

> Hopefully there'll at least be a system that provides base info:

One can conceive of a standard authenticated-owner interface to permit
domain principals to look up such data, sidestepping EU privacy
objections.  Maybe.  But of course, public ability to check _other_
people's domain details, relied on by Ben and Jesse's tools and frankly
by many people all the time, suffers.  E.g., I can't tell you how many
times I've tried to help an acquaintance with, say, his/her domain about
to expire, and the e-mail addresses on record were utterly useless but the 
names and telephone numbers of the Registrant, Administrative Contact,
and Technical Contact were crucial.

The 'e-mail addresses prove useless for an unexpectedly expiring domain' 
syndrome is predictable, if you think about it:  If the listed contact
e-mails had been an effective means of reaching the key people, they
wouldn't have ignored about five or six consecutive renewal notices.
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: domain-checking tools (was: Melbourne IT - anyone have any contacts?)

[Rick Moen via luv-main]

Quoting Anthony (anthony-...@hogan.id.au):

> Australian domain whois also doesn't show expiry info.

Quite.

This astonishing-to-me-in-2007 fact is highlighted prominently in my
referenced _Linux Gazette_ article.  The domain I tested, as revealed in
the article, was, in fact, luv.asn.au.  (That revelation means that all
three implementations of the checking script are useless for .au
domains, sadly.  Fortunately, even for hosts in Oz, .au is not the only
possible TLD.  For hosts where that DNS constraint applies, true, other
solutions would be required.)

> Unfortunately you can't poll whois for a .au domain more than 20 times a
> day from the same IP.

FWIW, Ben Okopnik's (and, IIRC, Jesse Monroy's) Perl code includes
rate-limiting code for some _other_ TLDs that are punitive of frequent
queries, albeit not quite that punitive. 


___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: domain-checking tools (was: Melbourne IT - anyone have any contacts?)

[Rick Moen via luv-main]

I wrote:

> To this day, every Sunday I get e-mail via a cron job that runs
> domain-check against a set of about three dozen domains (mine,
> friends', and those of institutions I care about) to tell me which of
> them are within 90 days of expiration (and if any are past
> expiration).


FYI, here's an example report sent using said cron job, that leverages
Ben Okopnik's 'domain-check' Perl script:


--

Date: Sun, 24 Dec 2017 07:12:02 -0800
From r...@linuxmafia.com Sun Dec 24 07: 2:02 2017
From: root 
To: r...@linuxmafia.com
Subject: domain-check: Domain expiration warning (90 day cutoff)

According to 'whois', these domains will expire soon:

pentaclemoon.com (in 16 days)
electriclichen.com (in 20 days)
berkeleylug.com (in 26 days)
animelosangeles.com (in 26 days)
chicon.org (in 30 days)
grrattitude.com (in 33 days)
computerhistory.org (in 39 days)
maruch.org (in 43 days)
spinster.org (in 44 days)
lugod.org (in 44 days)
wsfa.org (in 45 days)
badens.org (in 47 days)
linuxdojo.net (in 60 days)
chair-in-the-sky.com (in 65 days)
cain.org (in 65 days)
svlug.net (in 71 days)
nblug.org (in 72 days)
landley.net (in 77 days)
zwilnik.net (in 82 days)
nesfa.org (in 83 days)
mib.org (in 86 days)
whensday.info (in 88 days)
likkitownsend.com (in 90 days)
desamojones.com (in 90 days)

--


That mail was generated by my local /etc/cron.weekly/domain-check
cron job, which is as follows:


--

#! /bin/sh

# domain-check  Cron script to check domain expirations.
#
#   This is a pitifully primitive cron script to invoke domain-check
#   by Ben Okopnik ( b...@linuxgazette.net ) against lists
#   of domains in /usr/local/share.  A better replacement
#   would notify a list of appropriate persons for each
#   domain, rather than just Rick Moen.
#
#   Written by Rick Moen (r...@linuxmafia.com)
#   $Id: cron.weekly,v 1.01 2007/07/02 21:03:05 rick

set -o errexit  #aka "set -e": exit if any line returns non-true value
set -o nounset  #aka "set -u": exit upon finding an uninitialised variable

test -e /usr/local/share/domains || exit 0
test -x /usr/local/bin/domain-check || exit 0


/usr/local/bin/domain-check -w -e=r...@linuxmafia.com  -x=90 
-F=/usr/local/share/domains

--



My /usr/local/share/domains file is simply an ASCII list of domains
I wish to be periodically checked, listed one per line.

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

domain-checking tools (was: Melbourne IT - anyone have any contacts?)

[Rick Moen via luv-main]

Quoting Russell Coker (russ...@coker.com.au):

> Does anyone know of a good way of monitoring this?  I have experimented with 
> monitoring the output of the "whois" command, but they are quite aggressive 
> about blocking multiple connections from the same IP address.

Yes, albeit some TLDs have uninformative whois output or other problems.

In http://linuxmafia.com/pub/linux/network/, you will find both
domain-check (various numbered versions thereof) and d-check.  Both are
Perl scripts for this purpose.  To this day, every Sunday I get e-mail
via a cron job that runs domain-check against a set of about three dozen
domains (mine, friends', and those of institutions I care about) to tell
me which of them are within 90 days of expiration (and if any are past
expiration).

You'll also find a shell script called domain-check.ryan, the
ur-implementation that started all this.  (Master index for this
directory is the http://linuxmafia.com/pub/linux/network/00index.txt
file.)

In 2007, when I was contributing editor to _Linux Gazette_ (now defunct), I
wrote an article called 'Preventing Domain Expiration'[1], that talked
about the utility of running Ryan Matteson's 'domain-check' shell script
and being warned about pending expirations.  Unfortunately, Ryan's work
didn't handle important TLDs (such as .org) and presented maintenance
difficulties, so Perl coder Ben Okopnik, with some help from me, wrote 
Ben's replacement Perl implementation of domain-check, the one that is
present in many versions.

In the years since then, Ben has EOLed said code.  It has now accumulated
a few problems, solely on account of new TLDs whose whois output it
cannot parse, or changed behaviour at incumbent TLDs.  I checked with my
friend Jesse Monroy, who (FWIW) absolutely hated Ben's coding style, and
decided to write his own from-scratch Perl replacement, which is what d-check 
is.  

As I say in 00index.txt, Jesse's upstream repo is: 
https://github.com/jessemonroy650/d-check

My various template, example, and cron script files, although tuned for
Ben's domain-check, may be of use and can be found in that same
directory.

> All I want is a way of discovering when my domains will expire which doesn't 
> depend on receiving email from Melbourne IT or similar.

Done.  Yr. welcome.


[1] http://linuxmafia.com/~rick/preventing-expiration.html
Warning:  Article talks mostly about _Ryan's_ domain-check, because Ben's
was just then newly written and a bit raw.  However, please take care to
avoid Ryan's shell-script implementation of the idea, as it's a quite flawed
implementation compared to _both_ Ben's and Jesse's Perl versions.
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Biting the bullet - RAID

[Rick Moen via luv-main]

Quoting Craig Sanders (c...@taz.net.au):

> I haven't cited a "variety of ills" because there aren't a variety of them.
> There's just one: assuming that drive device names will remain the same on
> every reboot, every time, forever.  That one ill can result in a multitude of
> problems, but they all stem from that one error.  And they're all avoidable by
> simply not making that mistake.

All I can say is that your description of my 26 years' experience in
using Linux in precisely that way as a 'mistake' (recipe for problems)
has found no match in my particular experience, under the constraints
described.

> A SHA1 or MD5 or whatever hash is slightly shorter but no more human-readable
> than current UUIDs.

Looks substantially shorter, to me.  Also, I'll guesstimate, too, that
a substantially shorter hash than that would yield reasonable uniqueness.

> I don't need to tell myself the bleeding obvious.

Again, 26 years' experience, as detailed, says otherwise.

> Good for you. You're lucky. 

I _very_ much doubt that.  In fact, I smell a crock (a gross exaggeration).

> However, assuming that your experience is universal is always a bad
> idea.

This I carefully did _not_ do.  Please read more carefully.

> Giving out advice based on that presumed universality is even worse.

And this I _very_ much did not do.  Please read a great deal more
carefully.


> You mean by NOT having lots of drives in my machines?

I mean by being more careful about matching of drives to machines.
Works for Me.[tm[

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Biting the bullet - RAID

[Rick Moen via luv-main]

Quoting Craig Sanders (c...@taz.net.au):

> i.e. label collisions are not an accident, they're the inevitable result of
> poor planning.

Sure.

> The trouble is that unless you want to use UUIDs there isn't any alternative.

Well, speak for yourself.

I've been using /dev/sdX (never used IDE ;->  ) on Linux since 1992, and
for whatever reason never encounter the variety of ills you cite.

> There's not much use to a "unique" identifier that is only "unique" some of
> the time, or only unique as long as any humans involved don't do the kinds of
> things that us humans are prone to doing.

Personally, I'd settle (or consider settling, depending on outcomes) for
a human-compatible identifier that's roughly as unique as an SHA1 hash
is, or maybe even an order of magnitude or so less so.  As I'm sure you
know, those are not guaranteed absolutely reliable as a digest form of
the things they stand for, but for all _practical_ purposes they are.

For purposes of my disk identifiers, it really doesn't bother me that a
few thousand other disks somewhere else on the planet might at some
given time have the same identifier.  As the late Adam Osbourne or
Osbourne Computer used to say, 'Adequacy is sufficient.'  (Hey, I'm old,
and I was a member of the Homebrew Computer Club as a teenager.)


> So it makes sense to give a UUID to disks/partitions/filesystems by default.

You keep telling yourself that.  ;->

> and then one day you'll compile the latest shiniest new kernel and discover
> that the kernel devs really weren't joking when they said you can't rely on
> the names to remain the same.

You keep saying that.  It's been 26 years.

> I see it frequently.  But my main file server has 8 SATA drives plugged into
> an LSI SAS controller and a few more in SATA ports on the motherboard. 

Yeah, personally I'd carefully avoid that.

> mdev already has helper scripts that create the same kind of /dev/disk/by-*
> symlinks that udev does.

Well, I'll not use those.  ;->

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Biting the bullet - RAID

[Rick Moen via luv-main]

Quoting Craig Sanders (c...@taz.net.au):

> Fortunately, you can assign labels to partitions or filesystems when
> you create them (or add one later), and these are much easier to read
> and use.

Care to learn hour to make a Linux system go belly-up in a way
field-proven to puzzle Linux experts for days?  Simple:  Accidentidally
connect two disks with the same assigned disk label, and then attempt to
boot it.

This was posted a decade or so ago to the Silicon Valley Linux User
Group by one of the leading experts who'd just solved the problem after
being stumped by it for days.  (I can't remember the exact signs of
distress the system gave, if any, before falling over.)  

I didn't try to replicate the problem.  I merely made a mental note
that, IMO, this was an adequate reason to eschew disk labels completely:
one fewer bizarre failure mode to watch out for.

I always imagined that someone was handed an account of that shambles
and told 'Please design for the Linux community a disc identifier system 
that avoids all such failure modes through the expedient of using an
absolutely guaranteed, totally unique identifier.  Feel free to
sacrifice all other objectives such as ergonomics and
human-compatibility.  Just be absolutely certain the identifiers are
unique, at any cost.'  Eh volia!  UUIDs.


> changes in the order that kernel modules are loaded

FWIW, I generally compile my own kernel, and critical drivers get
compiled inline.  Never seen the above problem, and my kernel practices 
may help somewhat.

> minor variations in the timing of exactly when drives are detected by
> the BIOS or kernel (e.g. sometimes a disk might take a few
> milliseconds longer to spin up on a cold boot)

Still have never seen that on my systems.  Still waiting, since 1992.
It may help that I favour relatively simple and homogeneous hardware.


> BTW, modern linux systems populate a directory called /dev/disk/by-id/
> with symlinks to the actual device names.

I look forward eventually to losing udev on server systems and migrating
to mdev, which among other things will lose the above.  ;->

> If you're using LVM with RAID-1, you don't need mdadm - LVM can do RAID-1
> itself.

But mdadm / the Linux md driver are superb at doing Linux software RAID,
so IMO should be favoured as best of breed.

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Biting the bullet - RAID

[Rick Moen via luv-main]

Quoting Craig Sanders (c...@taz.net.au):

> The debian installer (and presumably ubuntu and others) let you switch to
> another console tty with Alt-F2, Alt-F3 etc to get a root shell.  You can
> manually create the partitions you want, then switch back to tty1 to install
> on the partitions you just created.
> 
> IIRC, on debian tty1 is the installer menu, tty2 & tty3 are for shells, and
> tty4 is a log tail of info and error messages etc printed by the installer.

And very handy all the other virtual consoles are, too.  (1994 thanks 
you for that tip, Craig.  ;->  )

Still, I continue to prefer to use a best-of-breed live-CD disk with a 
very recent kernel (maximal hardware support) and highly reliable and
diverse command-line tools for utility purposes such as partitioning and
initial mkfs -- a superior environment for that purpose, IMO, than
distro installers, even ones I like, like Debian's, are ever likely to
furnish.  I therefore also recommend that approach to others.
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Biting the bullet - RAID

[Rick Moen via luv-main]

Quoting George Georgakis (luv-...@tripleg.net.au):

> On 20/05/2018 12:54 PM, Rick Moen via luv-main wrote:
> 
> > ISTR that mdadm.conf can be fully reconsructed from that stored
> > metadata, even.
> 
> mdadm --detail --scan > /etc/mdadm.conf ?

Looks right!

-- 
Rick Moen"If accuracy / Is what you crave / 
r...@linuxmafia.com  Then you should call it / Myanmar Shave."  
McQ!  (4x80)   -- @FakeAPStylebook
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Biting the bullet - RAID

[Rick Moen via luv-main]

Quoting Andrew Greig (pushin.li...@gmail.com):

> Thanks Rick,
> I travelled so long without problems that technology has oustripped my
> understanding.  It is 18 years on Linux for me and around 17.5 since you
> informed me (graciously) about the bad habit of cross posting. So nice to
> hear from you.

Delighted to hear from you, too, Andrew.  

I should have added that, at least on all Linux system implementations
I've seen for the past couple of decades, the mdadm.conf file ends up
being slightly redundant during normal operation, because array
construction stores all required RAID metadata for the RAID array in the
RAID superblock stored on each physical device in the array.  ISTR that 
mdadm.conf can be fully reconsructed from that stored metadata, even.

That's talked about briefly, here:
https://raid.wiki.kernel.org/index.php/RAID_setup#The_Persistent_Superblock_.282011.29

The larger point I'm making is that md RAID has become, over a long
period of time, pretty bulletproof, speaking in general terms.  (Of
course, nothing is entirely safe from an absent-minded sysadmin.  ;->  )
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Biting the bullet - RAID

[Rick Moen via luv-main]

Quoting Andrew Pam (and...@sericyb.com.au):

> You really do want to use UUIDs for the RAID members, though.  You want
> to make sure the drives get assembled into the array correctly
> regardless of how they're connected or enumerated.

mdadm and the md driver don't rely on /dev/sdX assignments after
assembly of an array.  You can confirm this by looking inside
/etc/mdadm/mdadm.conf .

-- 
Cheers,
Rick Moen  ROMANI, ITE DOMVM!
r...@linuxmafia.com
McQ!  (4x80)
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Biting the bullet - RAID

[Rick Moen via luv-main]

Quoting Andrew Pam (and...@sericyb.com.au):

> Note that if you do this the drive names can still change when you plug
> the other two disks back in.

Correction:  Merely plugging in discs changes _no_ /dev/sdX device
assignments.  Changing what's plugged in at boot time often does.

> That's why you should use UUIDs and not worry about what names they
> are assigned.

_Or_ don't change what mass storage devices are plugged in at boot time,
and be prepared to occasionally update /etc/fstab if major kernel
upgrades change the enumeration order.

(Some us consider the cure of UUIDs to be in a spirited competition with
the disease.)

> With Ubuntu 18.04 it should default to using a swapfile and no swap
> partition.  If you're having trouble with the partitioning, the simplest
> solution is to tell the installer to use the entire 1TB drive in the
> default configuration that it recommends rather than doing it manually.

Personally, I always do partitioning and initial mkfs operations using
whatever live-CD distribution I most have confidence in (currently
Siduction), and then separately let the distro installer use the
filesystems and disc layout thus created.  But horses for courses.


___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: host name - domain name

[Rick Moen via luv-main]

Quoting Craig Sanders (c...@taz.net.au):

> The domain itself needs, at minimum, an SOA record, two or more NS records,
> and an MX record.

[...]

This is very good, Craig.   (I would want to also include appropriate SPF
TXT RRs.)

I tried for a while to draft a 'how to write a zonefile' tutorial using
my prototype example RFC 1035 ('BIND') zonefile and configuration at 
http://linuxmafia.com/pub/linux/network/bind9-examples-linuxmafia.tar.gz,
but found the task surprisingly difficult, because you have to not only
present an example in good form, but also explain why you did particular
things and avoided particular errors (e.g., avoiding NS'ing or MX'ing to
a CNAME).

> $ORIGIN example.com
> $TTL 86400

ITYM '$ORIGIN example.com.'

The '$ORIGIN' line at the top is something I, likewise, prefer to do as
syntactic sugar, but it should be understood to be not functionally
necessary and to create some small pitfalls if you do it.  (Once, I
copied an existing zonefile to populate a new zone, and forgot to edit
the '$ORIGIN' line in the new zonefile, creating briefly puzzling
dysfunction until I caught the error.



> BTW, having a matching reverse-DNS entry for the MX records hostname is nice,
> and definitely worth doing if you can, but it's not necessary.  Very few mail
> servers reject mail because of something trivial like that - it's not common
> these days for people to have any control over the .in-addr.arpa zones for the
> tiny subnets they get allocated by their ISP.

It's still been my experience, FWIW, that significant numbers of
receiving SMTP domains consider sender's lack of a valid reverse to be
suspiciously spammy, even though it's not RFC-required.

So, personally, I would always ask my ISP to set an appropriate reverse in
the applicable *.in-addr.arpa zone.  (For these purposes, it's not
necessary to have the .in-addr.arpa namespace delegated, just set
appropriately.)
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: GMail + Email Client

[Rick Moen via luv-main]

Quoting Andrew McGlashan (andrew.mcglas...@affinityvision.com.au):

> I think that TB was "almost" orphaned, but it hasn't been; still it is
> not getting much real support from Mozilla whom seem to care only about
> their 57+ browser

Firefox gets them revenue.  Thunderbird doesn't.

It's always important to remember who's the customer and what is the
revenue model for any profit-oriented business.  In this case, Mozilla
Corporation makes its revenue primarily from Google, Inc for making 
Firefox & SeaMonkey's default search engine be Google Search, and from
click-through revenlues on advertisements placed on search result pages.
https://en.wikipedia.org/wiki/Mozilla_Corporation

> TB is the absolute best email client and it really needs more love to
> keep it that way.

The absolute best e-mail client is mutt.  The best _graphical_ e-mail
client is mutt in an xterm.  ;->

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Network Security Device

[Rick Moen via luv-main]

Quoting Robert Brown (rebr...@exemail.com.au):

> So maybe I will re-frame my original question.
> 
> Not being a developer or other IT professional, what software
> package could be put together on say, a Raspberry Pi or other
> device, that could be a watchdog against invasion/intrusion of our
> home networks?  Can it do as good or better than what an Akita
> claims?

My upthread answer concerning Akita's offering might have been just a
little cynical and flippant.  My experience is that 'active defence' 
technologies are likely to backfire in various ways, thus my jibe about
DoSing yourself (meaning doing a Denial of Service against yourself).
That's not even counting the various potential downsides of outsourcing that
entire task (along with a huge amount of sensitive information about
your computing) to some distant group of people you don't even know at
all (who in this case are a firm named Axius).

What Linux and the constellation of open source (and proprietary)
software codebases for it give you -- that I'm acquainted with -- is an
enormous variety of security monitoring and network management kits.
Those include, as you noticed, network intrusion detection system (NIDS)
codebases such as Snort, OpenWIPS, etc., and host-based intrusion
detection systems such as OSSEC.  In general, it would be up to you to
configure and deploy that software for your particular purpose and
situation.  In general, that software would not come preconfigured to 
actively network-isolate using ARP table entries or othrwise devices of
yours whose network activity it decides it doesn't approve of (the
'active defence' part that I deem likely to shoot at your feet).

What my upthread comment was intended to suggest, albeit flippantly, is
that there's an entire huge discussion you're skipping about what it is,
and is not, wise to attempt to do, and why.  Perhaps your best move
would be to start learning network security at a fundamental level,
though I most certainly understand the urge to want to buy a packaged
product instead of climbing that mountain.

Bruce Schneier the security writer has a famous saying:  'Security is a
process, not a product.'  Of course, people selling security products
do not concur.  ;->

Axius are, I will readily admit, not at all wrong that the emerging
Internet of Things is a security calamity waiting to happen.  I'm sure
they are not the first or the last people who'll argue 'Well, just
outsource the entire issue to us, then.'


___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Network Security Device

[Rick Moen via luv-main]

Quoting Robert Brown (rebr...@exemail.com.au):

> Does this:
> 
> https://www.kickstarter.com/projects/akita/akita-instant-privacy-for-smart-homes
> 
> do anything special that is not already available in linux software?

Like permitting you to DoS yourself?  ;->

Linux software does famously include DoSing-yourself functionality.

-- 
"If I have seen farther than others, it is because I was standing on the 
shoulders of giants." (Isaac Newton)  "If I have not seen as far as others, it 
is because giants were standing on my shoulders." (Hal Abelson, quoting Jeff 
Goll)  "In computer science, we stand on each other's feet." (Brian K. Reed)
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Intel CPUs

[Rick Moen via luv-main]

Quoting Steve Roylance (royla...@corplink.com.au):

> hi
> 
> this email is quoted on /. and credited to this list
> 
> https://hardware.slashdot.org/story/18/01/05/142201/when-f00f-bug-hit-20-years-ago-intel-reacted-the-same-way

And, you know, the previous time I was on Slashdot, it was on account of
Sam Varghese's excellent writing, too.  (Darn you, Sam!  ;->  )

Sam doesn't toot his own horn, so it's left to me to point out 
the gentleman's consistently good work on IT Wire,
https://www.itwire.com/ (not to mention any number of other places).

-- 
Cheers,   "A recursive .sig
Rick Moen Can impart wisdom and truth.
r...@linuxmafia.com   Call proc signature()
McQ! (4x80)   -- WalkingTheWalk on Slashdot
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Intel CPUs

[Rick Moen via luv-main]

Quoting Rohan McLeod (r...@jeack.com.au):

> Well it seems Intel has been very naughty
> https://www.theregister.co.uk/2018/01/04/intels_spin_the_registers_annotations/

Intel has a long history of trying to dissemble and misdirect their way
out of paying for grave CPU flaws.  Remember the 'Pentium Processor
Invalid Instruction Erratum' of 1997, exposing all Intel Pentium and
Pentium MMX CPUs to remote security attack, stopping them in their
tracks if they can be induced to run processory instruction 'F0 0F C7 C8'?

No, of course you don't.  That's why Intel gave it the mind-numbingly
boring official name Pentium Processor Invalid Instruction Erratum',
hoping to replace its popular names 'F00F bug' and 'Halt-and-Catch Fire
bug'.

That's also why Intel's judo-move response was to create an information
page stating that it had dealt with the CPU bug by linking to each of
the various x86 OS vendors' bug-fix pages.  'Here, we fixed the grave
defect in our CPU by sitting on our asses and letting software coders
work around our error.'

The press, of course, cooperated by simply pointing people to Intel's
page and implying that Intel 'developed a fix'.  That's what they're
going to do this time, too, I'm sure of that.

My page about the F00F bug.  
'F00F Bug' on http://linuxmafia.com/kb/Hardware/
(See in particular my dissection of Intel's spin-control tactics a year
after the scandal broke.)

-- 
Cheers, « Le doute n'est pas une état bien agréable, mais
Rick Moen   l'assurance est un état ridicule. »  ("Doubt is not 
r...@linuxmafia.com a pleasant condition, but certainty is absurd.')
McQ! (4x80)   -- Voltaire 
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: device naming (was Re: Ethernet port setup part2)

[Rick Moen via luv-main]

Quoting russ...@coker.com.au (russ...@coker.com.au):

> Sometimes you just have to do such things.

We all make sacrifices to get by.  ;->

> I run a server that has as its main purpose preparing SD card images for 
> embedded PCs.  The images are made by the people who install the embedded PCs 
> on-site (who wear high-visibility clothing).
> 
> Getting them to unplug USB devices during system boot isn't a viable option.  
> I just have to make the system work with a SD card being sda and hard drives 
> being sde and sdf if it boots with the USB device connected.

I would think that using either disk labels or UUIDs for the hard drive
filesystems in /etc/fstab would be more than sufficient for that
functional need.  (Of course, I'm not denigrating your choice of
tactics, which is naturally something you know best.)

> As for Ethernet device names, here are the device names I chose for one of my 
> systems:
> ethbl
> ethbr
> gethm
> getht
> lo
> mb0

On RHEL/CentOS, you were always able to do that without (and before)
udev, courtesy of the ability to hard-map device names to MAC addresses.
On other distributions, ifrename suffices to get you the same thing.

Nothing wrong with using udev for this if you like it.  My only
objection is to Freedesktop.org-style PR advocacy suggesting 
it's somehow essential and ground-breaking, when clearly it's neither.

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: device naming (was Re: Ethernet port setup part2)

[Rick Moen via luv-main]

Quoting Craig Sanders (c...@taz.net.au):

> І've had it happen to me on several occasions - both disks and NICs.

I of course believe you, and am reading the details you provide below
this with interest.  Thank you.

> The most common cause in my experience wasn't adding or removing drives/NICs,
> it was:
> 
> a) upgrading the kernel, which changed the order that devices were detected,
> resulting in eth0 and eth1 being swapped, or sda & sdb being swapped, etc.

This I can readily believe, and I _think_ I once observed it during a 
(very) major kernel transition -- and I considered this small beer in
context, FWIW.

> and
> 
> b) driver modules being loaded in a different order (same cause, different
> incarnation) - this could be partially solved by listing the modules you want
> loaded in /etc/modules, they'll load in the order listed (unless something
> else triggers them being loaded earlier).

FWIW, my own preference is to locally compile a kernel with needed
drivers monolithically included and not building unneeded ones at all.
(On non-server systems, I do the same except compile as modules drivers
I might reasonable expect to some day want but not initially.)

I would be interested to know the circumstances in which 'modules loaded
in a different order', specifically if any were _other than...

> Adding drives and controller cards and USB **also** changes the order

This, again, is exactly what I would expect and spoke of upthread, and 
what I would consider small beer.

That is, _of course_ adding/removing drives and controller cards may
change device order.  When you do so, you expect that and expect to
update one or two relevant system rc files.

USB?  Yes, indeed, notorious agent of chaos that it is -- which is one
of multiple reasons why you don't leave casual-use hotplugged
mass-storage devices plugged in during system reboots, and why I'd be
adverse to relying on USB-connected network interfaces if I had any
alternative at all.

So, to recap, unless you can (please!) detail instances where 'driver
modules loaded in a different order' _without_ the above obvious and
well-understood causative factors, I think you've just reiterated
exactly what I said upthread.


> e.g. on my my system, I have four Crucial SSDs plugged into the motherboard
> (my boot drives and root zpool), a variety of WD & Seagate drives plugged into
> a SAS controller card (my main storage and backup zpools). Also a USB card
> reader, and an android phone (which sits in its USB connected dock recharging
> and displaying a clock whenever I'm at home, also running a sip client to
> connect to my asterisk server over my local wifi).
> 
> On most reboots, the SAS ports are detected first, then the USB card reader
> (which doesn't even have any cards inserted), then the phone, then finally my
> motherboard SATA ports.  I can't remember the details, but this order changed
> when I made some changes to BIOS settings...motherboard ports used to come
> first, now they don't.  I don't care enough to find out why or change it
> because it doesn't matter at all if i use UUIDs or LABELs or /dev/disk/by-*

USB _is_ a notorious agent of chaos.  (My surmise, admittedly.)  But you
might also indeed be getting the several HBA drivers loaded in variable
order.

I'll bet that the device node instability would vanish if you compile in
the drivers monolithically.  That's what I'd try, anyway -- might put an
end to that nonsense, and good riddance.

> The SAS port drives aren't even detected in any predictable order.  All of the
> 4TB ST4000DX drives (my "backup" zpool) are plugged into one SFF-8087 socket
> on the SAS card (which goes to one of my 4-drive hot swap bays), and the 1TB
> WDs and STs are plugged into the other (which goes into another 4-drive bay).
> You'd expect them to be detected in that order, but...nope.

But (and my apologies if you clarify this; I'm a bit pressed for time),
I'm betting that the devices within each _set_ of ports, the motherboard
SATA set, the PCI-E SAS set, and the set of any block devices on USB, 
each are assigned devices contiguously.  So, see above.


> If I happen to reboot without my phone plugged in to a USB port, then the
> Crucial drives would probably be /dev/sdm to /dev/sdp rather thn n to q.

As mentioned, I would always carefully avoid having a casual-use
hotpluggable (e.g., USB) mass-storage device plugged in _at all_ during
boot time.  Your Mileage May Differ.{tm}

You might not want to do that, but this basically explains my experience 
that shifting nodes, if at all, happens only very rarely during major
kernel transitions or hardware addition/removal.  Making sure hotplug
mass storage is gone during reboots helps prevent that outcome.

Monolithically compiled drivers may help, too, but I don't _always_ do
it, yet I don't observe what you say happens, so I'm not sure it's
strictly necessary.  If I -did- see that, though, monolithically
compiled drivers would be the first thing I'd try.

> 

Re: Ethernet port setup part2

[Rick Moen via luv-main]

I just remembered:

> I vaguely recall that a system swapped eth0 and eth1 when replacing a
> 2.0.x kernel with a 2.2.x kernel (or 2.4 to 2.6, or something like
> that).  Which didn't surprise me much, and is why God made rc files
> editable.
> 
> And ifrename is cool.

I've encountered _zero_ instances of network interfaces changing their
device nodes on RHEL/CentOS, under any circumstances, for the simple
reason of DEVICE and HWADDR directives being used in the default
/etc/sysconfig/networking/devices/ifcfg-* files.

DEVICE=eth0
HWADDR=11:22:33:44:55:66

Which can optionally be used to assign devices names of your choosing
such as 'lan' and 'wan'.

I guess the 'network interfaces have come up in a different order' scenario
seems to be primarily a Debian/*buntu, etc. one (that has never arisen
in my use-cases), and mostly involves USB (and other equally flaky
hotplug hardware schemes).

Did I mention that ifrename is cool?  ;->

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Ethernet port setup part2

[Rick Moen via luv-main]

Quoting Craig Sanders (c...@taz.net.au):

> You can't rely on the kernel assigning any name to any particular network
> interface - same as you can't rely on a hard disk getting the same /dev/sdX
> name on every reboot.

For the record, over decades of administering Linux servers, I've just
never had a problem with (by which I mean, not encountered) either
network interfaces or hard disks / SSDs getting a new device name upon
reboot.  So, I think this risk is massively overstated.

I'd speculate that it primarily relates to the effect of hardware
changes (adding/removing internal hardware) and, most of all,
hotpluggable devices such as (most notably) USB.  And yes, _of course_
USB devices change device nodes upon reuse.  ;->

I vaguely recall that a system swapped eth0 and eth1 when replacing a
2.0.x kernel with a 2.2.x kernel (or 2.4 to 2.6, or something like
that).  Which didn't surprise me much, and is why God made rc files
editable.

And ifrename is cool.

So, in short, I greatly doubt there's a significant need, except for
people highly reliant on USB for critical infrastructure (you poor
sods!) to have the Freedesktop.org Predicatble Network Interface Names
kludge^W scheme, nor the Freedesktop.org
/dev/disk/by-{path,id,label,partlabel,partuuid,uuid} scheme, either.
In my experience, the Linux kernel can do just fine managing automated
device nodes, and automatic loading of firmware, by itself, using its own
devtmpfs code
(https://unix.stackexchange.com/questions/77933/using-devtmpfs-for-dev),
which IIRC Torvalds and company wrote as a reaction to ongoing bad
behaviour from the systemd/udev people.

Along those lines, I also greatly doubt here's a significant need,
except for people highly reliant on USB for critical infrastructure, for
udev, either.  Especially for server deployments, I'm not even convinced
mdev is necessary.  One Ulrich Dangel is quoted at the StackExchange
link as saying udev is needed because it manages permissions and adds
meaningful symlinks as well as running external scripts.  Well, I've
always been able to manage permissions perfectly fine by myself, the
'meaningful symlinks' appears to refer to the
/dev/disk/by-{path,id,label,partlabel,partuuid,uuid} stuff I can do
without, and the 'running external scripts' bit I can either handle
myself or have mdev do as a hotplug handler referenced via
/proc/sys/kernel/hotplug.

https://wiki.gentoo.org/wiki/Mdev
https://github.com/slashbeast/mdev-like-a-boss

> I switched from using ifrename to this udev method years ago. so long
> ago I've forgotten when.

ifrename is cool.  ;->

> Anyway, I'll be switching to dual Intel NICs when І get my new ryzen
> threadripper X399 motherboard in a month or two. I've been waiting for years
> (since 2011 or so) for AMD to come out with a new CPU that's both affordable
> and worth upgrading to, and Intel's so overpriced that I would have had to
> spend ~$1000 just to get similar performance to what I already have with
> my Phenom II 1090T...if i'm going to spend that kind of money, I want an
> *upgrade* worth that much.

It's too bad about AMD Platform Security Processor (PSP).
https://libreboot.org/faq.html#amd

Seems that we're on our way to being able to totally neuter Intel Management
Engine, but not yet PSP.  (Personally, I like the thought of my systems
not being able to be remotely controlled by others invisibly.)



___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Btrfs has been deprecated in RHEL

[Rick Moen via luv-main]

I wrote:

> Quoting russ...@coker.com.au (russ...@coker.com.au):
> 
> > What rights do the Linux kernel coders have in this regard?
> 
> Copyright title conferring ownership of the abstract right of
> distribution of derivative works.
> 
> If you're going to go around alleging that in-kernel filesystems are not
> derivative works of the Linux kernel, good luck with that.  To quote
> a saying from Damon Runyon, riffing off Ecclesiastes 9:11, 'The race is
> not to the swift, nor the battle to the strong..., but that's the way to
> bet.'
> 
> > If you knowingly infringe then that's the case.  If you believe that
> > Canonical and Oracle have sorted things out then you are clear.


> In one of the two USA copyright cases commonly cited for contributory
> copyright infringement, Metro-Goldwyn-Mayer Studios Inc. v. Grokster,
> Ltd., 545 U.S. 913 (2005), respondent Grokster was found to have actual
> knowledge of infringement.  However, in the other case commonly cited,
> Sony Corp. v.  Universal City Studios, Inc., 464 U.S. 417 (1984), the
> court found Sony to have had 'constructive knowledge', which is to say
> not actual knowledge but circumstances where Sony should have known.

And, yet again, for reasons that passeth understanding, you chose to
speak as if violating the GPLv2 licence terms of the Linux kernel
doesn't matter, or the authors of the Linux kernel don't own copyright
title.

(Or that in-kernel filesystem drivers aren't derivative works of the
kernel, and again, _good luck_ with that argument.)

To be clear, I very much doubt that the mainline kernel authors are
likey to go around suing small businesses and individual users for
contributory (or other) copyright violation, especially if they don't
-distribute- the infringing derivative work, which is the problem with
Ubuntu's copyright violation.

But users who participate in this infringement of the kernel coders'
licensing terms are free to feel a bit sleazy, and IMO ought to.

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Btrfs has been deprecated in RHEL

[Rick Moen via luv-main]

Quoting russ...@coker.com.au (russ...@coker.com.au):

> What rights do the Linux kernel coders have in this regard?

Copyright title conferring ownership of the abstract right of
distribution of derivative works.

If you're going to go around alleging that in-kernel filesystems are not
derivative works of the Linux kernel, good luck with that.  To quote
a saying from Damon Runyon, riffing off Ecclesiastes 9:11, 'The race is
not to the swift, nor the battle to the strong..., but that's the way to
bet.'

> If you knowingly infringe then that's the case.  If you believe that
> Canonical and Oracle have sorted things out then you are clear.

In one of the two USA copyright cases commonly cited for contributory
copyright infringement, Metro-Goldwyn-Mayer Studios Inc. v. Grokster,
Ltd., 545 U.S. 913 (2005), respondent Grokster was found to have actual
knowledge of infringement.  However, in the other case commonly cited,
Sony Corp. v.  Universal City Studios, Inc., 464 U.S. 417 (1984), the
court found Sony to have had 'constructive knowledge', which is to say
not actual knowledge but circumstances where Sony should have known.

So, no.

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Btrfs has been deprecated in RHEL

[Rick Moen via luv-main]

Quoting russ...@coker.com.au (russ...@coker.com.au):

> Oracle has not chosen to persue any action against Canonical.

More to the point, so far, so have the Linux kernel coders.  But the
copyright violation is real, and Canonical risk either set of
stakeholders filing and getting them severely sanctioned and that
practice terminated at any time.

> In any case it's not a problem for people who use Ubuntu.

I personally don't like dealing with companies that indulge shady
business practices that violate the ethics of the open source community,
and this isn't the first time Canonical have done so.  Moreover, I
personally eschew dealings with firms inclined to make potentially fatal
legal mistakes.

As to customer legal liability, probably as you say, but I wouldn't rule
that out.  https://www.law.cornell.edu/wex/contributory_infringement
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Btrfs has been deprecated in RHEL

[Rick Moen via luv-main]

Quoting russ...@coker.com.au (russ...@coker.com.au):

> Well in the real world ZFS on Ubuntu is working well.  I prefer Debian but 
> Ubuntu has better support for ZFS due to different legal advice.

Different and quite clearly wrong, in my view.  (No, I'm not an
attorney, but I have been a major participant in OSI's licence
evaluations for some decades, and made a particular study of such
things.)

In my view, Canonical are willful copyright violators and are staking a
great deal on a guess that kernel stakeholders are not going to haul
them into court, where they would very likely lose in a major way, be
ordered to pay a great deal in monetary damages, and be enjoined against
further violation.

If such an action were brought under USA copyright law, and Canonical
were to lose, the basic level of statutory damages would be between US
$750 and US $30,000, depending on the facts of the case and the court's
mood (and the seriousness of the infringing act, and the infringer's
financial net worth), but if willfulness is proved, then plaintiff would
also be awarded up to US $150,000 in additional statutory damages.
That's aside from, in addition to, any compensatory aka 'actual' damages
plus profits made by the infringer.
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Btrfs has been deprecated in RHEL

[Rick Moen via luv-main]

Quoting russ...@coker.com.au (russ...@coker.com.au):

> Last time I checked XFS had no support for reducing the size of a
> filesystem.  

Correct.

> But if Stratis is going to use multiple XFS filesystems to compare
> with the multiple ZFS mount points or BTRFS subvols then it will be a
> massive problem.

The design paper claims online grow abilities adequately meets their
needs.  I've only just now skim-read that paper, so I cannot comment.

> Stratis is aiming for a version 1.0 release next year, and version 3.0 is 
> aimed at having ZFS feature parity.  That's not good for all the people who 
> need ZFS features today!

Welcome to the real world of software development, eh?

RH aren't going to ship ZFS unless Oracle Corp. issue a licence
exception (alongside the CDDL terms), and that's not going to happen.

(Well, RH could ship FUSE_ZFS, but they aren't going to do that
either, for reasons of performance.)

> XFS has no support for checksums that compares to ZFS and BTRFS.  To do it 
> properly you need to do it in the filesystem.  

Whitepaper section 10.2.2 et seq. talks about their plans in this area.

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Btrfs has been deprecated in RHEL

[Rick Moen via luv-main]

Quoting Steve Roylance (royla...@corplink.com.au):

> the announcement is at
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html

Maybe Stratis after interim use of XFS.
https://www.phoronix.com/scan.php?page=news_item=Stratis-Red-Hat-Project
https://stratis-storage.github.io/StratisSoftwareDesign.pdf

It's funny seeing XFS make a resurgence.  I used it on Debian back
before ext3 had become mainstream.  At the time, it seemed solid
technology but its Linux future was (then) in doubt because it was a
huge patchset.
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Error when Installing Debian 8

[Rick Moen via luv-main]

Quoting zlin...@virginbroadband.com.au (zlin...@virginbroadband.com.au):

> Now it actually works OK, the ramdisk image was installed correctly.
> What it has done though it prevents the kernel from being upgraded.
> I have sort of got around this by compiling my own kernel (I do this
> as a matter of course anyway), this of course required me to dump
> systemd as it WILL NOT work with a standard kernel from kernel.org.

If you wish to retain the freedom to compile a kernel _your_ way 
without special bespoke requirements being imposed on you by systemd,
you can do so on Debian systems -- through the simple expedient of
apt-get installing one of the other packaged init systems.  In Debian 9
'Stretch', those are:  openrc, runit, upstart, sysvinit.

I installed Debian 8 'Jessie' and documented easy conversion to use
the 'Jessie' openrc package, here:  
http://linuxmafia.com/faq/Debian/openrc-conversion.html

Please note carefully the caveats about certain DEs (the kitchen-sink
metapackages for GNOME, MATE, Cinnamon, KDE, and Razor-qt) and a couple
of other packages with overly large dependency trees (e.g., hplip) and
what to do about that.

I strongly recommend testing using a VM before taking any such steps on
a real system.  That is what I did to write the referenced Web page.
FYI, I switched that Debian 8 'Jessie' test system to track
debian-unstable ('sid'), and it continues to work beautifully, so I
expect you would have very good results on Debian 9 'Stretch', the
current debian-stable branch.

When I have time, I'll probably repeat the VM experiment using a fresh
ISO image of Official Debian 9 'stretch', to reconfirm the data on that
page.  

P.S.:  If you're compiling your own kernel anyway, and would consider
putting systemd in the dustbin, then you can further simplify by
compiling monolithically into the kernel binary all drivers essential to
early boot and root FS mounting on your hardware.  That having been
done, you can dispense with the initrd (initial RAMdisk), further
simplifying your system.

-- 
Cheers, "The crows seemed to be calling his name, thought Caw."
Rick Moen -- Deep Thoughts by Jack Handey 
r...@linuxmafia.com 
McQ! (4x80)
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: splitting a diff

[Rick Moen via luv-main]

Quoting Russell Coker (russ...@coker.com.au):

> I have a diff file that has changes to multiple source files that I
> want to split up for sending upstream.  Is there a good tool for
> splitting this?
> 
> The ideal would be something that takes a list of source files on the
> command line, and writes the diffs for them to one file and the diffs
> for everything else to another.

splitdiff(1) divides single unified diff into individual diffs for each 
of the affected files

combinediff(1) can do the reverse operation.

http://linuxcommand.org/man_pages/splitdiff1.html

Hope that helps!

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: LUV DNS

[Rick Moen via luv-main]

Quoting Russell Coker (russ...@coker.com.au):

> As we had 2 servers still operating correctly at all times users would not 
> have noticed.

I can offer LUV two more authoritative nameservers, if you don't mind
them being across an ocean (meteor-proofing ;-> ):

ns1.linuxmafia.com, IP 198.144.195.186
ns1.svlug.org, IP 64.62.190.98

RFC2182 section 5 recommends minimum 3, maximum 7 per domain.

(.sig is to smoke out the resident Latinists, and amuse them.)

-- 
Cheers,  Homo in Domu Alba, qui est iratus et habet in 
Rick Moenartificialibus capillum:  Quod homo non sit
r...@linuxmafia.com  honesta, et est perniciosa in rei publicae.
McQ! (4x80)   
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Fwd: Debian 7 - Update error

[Rick Moen via luv-main]

Quoting Brian May (br...@linuxpenguins.xyz):

> There are multiple GUIs out there, you haven't said which one you are
> using.

Indeed, since he could be using KPackageKit, or kpackage, or synaptic,
or Apper, or update-manager, or aptitude (ncurses full-screen mode), or
who knows what-all, and since every single deb-based system has apt-get
and it always works the same, _and_ since I'm unlikely to install
something non-standard just to be able to help Peter Ross, I suggested
the tool that's always available and always does the job.

-- 
Cheers,  "If you ever drop your keys into a river of molten lava, 
Rick Moenlet 'em go, because, man, they're gone."
r...@linuxmafia.com  -- Deep Thoughts by Jack Handey
McQ! (4x80)
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Debian 7 - Update error

[Rick Moen via luv-main]

Quoting Peter Ross (petross...@gmail.com):

> > So, why are you suddenly changing the subject to 'a stereotypical office
> > worker', Peter?
> 
> Because the desktop is aiming for the average user who is not an admin.

Well, while the desktop is toiling away at that endeavour, I'm busy
telling the truth about what tools avoid huge dependency pitfalls and 
avoid concealing oft-critical stderr information.  My other alternatives
appear to be (1) lying, or (2) not helping.

Which would be your recommendation, sir?

(The 'average user' is on a smartphone, by the way.)

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Debian 7 - Update error

[Rick Moen via luv-main]

Quoting Peter Ross (petross...@gmail.com):

> In  my case my "rpm and FreeBSD infested brain" was on holidays and
> was about to update the only "apt-get driven" system I have around at
> the moment.  So, what is the command line tool I have to learn?

The one that would suffice is apt-get.  It would be good to also be
aware of dpkg, which is to apt-get what rpm is to yum.

And how would you know that?  By ten minutes looking at pretty much any
new-admin tutorial for any deb-based Linux (or Illumos) distribution.

> A lot of command line tools, and technologies, vary over time, and not
> only between distributions and Unix flavours. I am still used to
> ifconfig but a minimal install under Red Hat does not even has it.

1.  You can have it very easily if you insist.
2.  Red Hat omits the net-tools utilities (that include ifconfig) in
favour of the iproute2 utilities because the former have been
unmaintained for almost 16 years, and also lack some functionality.

http://inai.de/2008/02/19
https://dougvitale.wordpress.com/2011/12/21/deprecated-linux-networking-commands-and-their-replacements/
http://andys.org.uk/bits/2010/02/24/iproute2-life-after-ifconfig/

At this point, complaining about excessive tool churn because ifconfig
is slowly fading away is like complaining that nobody installs BIND4 or
lpd or wu-ftpd any more.

> On top of it, I know how many users baulk if you give them a terminal.

Traumatic growing up, isn't it?  ;->

> Just instruct a stereotypical office worker over the phone to open the
> command line under Windows.

I'm sorry, weren't we talking about "novice users" (which you put in
scare quotes to indicate the ironic nature of your reference) needing to
resort to apt-get rather than a DE-based graphical package-operations tool?  
Thus, you were speaking of a root-account-using system administrator.
So, why are you suddenly changing the subject to 'a stereotypical office
worker', Peter?

That having been said, if a 'stereotyical office worker' mentioned to me
that a graphical tool in his or her corporate Linux desktop machine was 
giving strange and flaky results, I would indeed reply that console
equivalents have the advantages cited.  If the person then said he/she
didn't wish to use them, I would sincerely wish that person luck with
all future efforts, then turn away to more fruitful pursuits elsewhere
(such as teaching people willing to learn).


> So, you already scare 50+% of the population away with your advice.

You say that as if it were somehow _my_ problem.


> There was Nextstep.

I loved NeXTStep.  Very nice for a proprietary BSD.  Pity what happened
to it.  ;->

And when you wanted to do serious text processing, file operations,
etc., on NeXTStep, you used standard console tools.  I certainly did, as
did all other NeXTStep users I ever met, back in the day.

> I have not touched MacOS X for a while but the spirit
> seems to live there.

No, it really, _really_ does not.  Take it from an old NeXTStep user
whose wife spent many years under Steve Jobs as an Apple coder, it
absolutely does not.


> I also loved AIX's smitty.

Never been smitten by SMIT, myself.

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Debian 7 - Update error

[Rick Moen via luv-main]

Quoting Peter Ross (petross...@gmail.com):

> Hi all,
> 
> answered the question myself: Do not use the GUI;-)
> 
> "apt-get clean; apt-get update; apt-get upgrade" worked.
> 
> Sad, a bit, that "novice users" still need the command line, it seems.

Reasons it is best to avoid relying on dependency-laden graphical tools
to do system upgrades include the strong possibility that the updates to
that tool's dependencies may make it misbehave or crash.  

You said you eventually 'realized it does not do the "apt-get update"
behind the scenes', which reminds me of another reason:  Graphical tools
in many cases give markedly less diagnostic and operational information
to the user, when they run, than do their console equivalents.  Also, in
some other cases (not a relevant concern in this case, I think), I have
found that the X-based tool suppressed stderr completely, while running
the equivalent console tool showed exactly what the problem was,
automatically, because stderr went to the console by default.

The best very advice to novices, IMO, is to get to know standard Unix
console tools, because they'll be consistently useful across diverse
systems and across decades, while the other stuff is here today,
something wildly different tomorrow.

-- 
Cheers, "The crows seemed to be calling his name, thought Caw."
Rick Moen -- Deep Thoughts by Jack Handey 
r...@linuxmafia.com 
McQ! (4x80)
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Web performance

[Rick Moen via luv-main]

I wrote:

> Basically this is a query of the form 'Please suggest open source
> alternatives to proprietary package X', which generically (1)
> presupposes intimate knowledge of proprietary package X and (2)
> implicitly assumes that the pinnacle of success would be replicating
> package X's feature set, as opposed to doing something smarter and more
> useful-to-you.
> 
> Perhaps you should back up and describe what specific real-world problem
> you're trying to solve. 

Or, as Stackoverflow.com puts it on, e.g.,
http://stackoverflow.com/questions/5903825/are-there-any-comparable-frameworks-to-dynatrace-that-are-open-source
 :

  Questions asking us to recommend or find a book, tool, software
  library, tutorial or other off-site resource are off-topic for Stack
  Overflow as they tend to attract opinionated answers and spam.  Instead,
  describe the problem and what has been done so far to solve it. 

Some of the links on that page may be useful, such as the ones to
'Performing a Stress Test on Web Application?' and 'Open source Load
Testing framework' -- depending, of course, on what specific real-world
problem you are trying to solve.

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Web performance

[Rick Moen via luv-main]

Quoting Russell Coker (russ...@coker.com.au):

> Is there a good FOSS system for monitoring web performance? 

Please define 'Web performance'.

> I've just seen a demo of Dynatrace which is impressive and it would be
> good if there was a free alternative.

Basically this is a query of the form 'Please suggest open source
alternatives to proprietary package X', which generically (1)
presupposes intimate knowledge of proprietary package X and (2)
implicitly assumes that the pinnacle of success would be replicating
package X's feature set, as opposed to doing something smarter and more
useful-to-you.

Perhaps you should back up and describe what specific real-world problem
you're trying to solve.  I doubt that your specific pragmatic problem
centres around any Dynatrace, LLC product.

OTOH, it's possible you have no actual pragmatic need, and are just
curious if the small number of people familiar with proprietary package
X can suggest an open source alternative with the same feature
checklist.

-- 
Cheers,"It's easier to act your way into a new way of thinking
Rick Moen  than think your way into a new way of acting."
r...@linuxmafia.com-- Jerry Sternin 
McQ! (4x80)
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Virtualbox

[Rick Moen via luv-main]

Quoting Glenn McIntosh (neonsig...@meme.net.au):

> They have a dual licensing system, where VirtualBox itself is GPL, but
> the extensions are under a closed licence. The extensions including
> things like USB support for the guest.

USB 2.0 support.  (USB 1.1 is built into the GPLed core code.)
 
-- 
Cheers,"It's easier to act your way into a new way of thinking
Rick Moen  than think your way into a new way of acting."
r...@linuxmafia.com-- Jerry Sternin 
McQ! (4x80)
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: How to make systemd more reliable

[Rick Moen via luv-main]

Quoting Craig Sanders (c...@taz.net.au):

[init systems:]

> the majority had no say in it, and probably aren't capable of switching
> to something else if systemd doesn't meet their needs.

They can follow recipes, though.  There's a continuum from people who
can fully maintain software through people confident patching and
building software, to those who can manage a few local packages and some 
third-party package repos for particular purposes, to those fearful of
or unable to handle doing _anything_ non-default.  All but that last
category _can_ follow a recipe.  (If they're willing, and not just heady
with the recently trendy appeal of being outraged on the Internet.)

I wrote a recipe telling all about how to make current Debian 8 'Jessie'
use either OpenRC or your choice of the other packaged init systems
_partly_ to make a point to the Devuan crowd -- that the people loudly
claiming Debian is now systemd-captive are mistaken, and are indulging
gratuitous melodrama.  (This was not entirely well received.)

And, of course (equally), I wrote said recipe to assist those seeking such
a recipe.

I fully concur with Russell that most Debian users really neither know
nor care about options among init systems -- for the simple reason that
most *ix users, at all times, seldom even think of such things.  (But I
would assert that those of us who value reliable system, deterministic
operation and security do.)

> so it's OK to break promises because some (other) people said some mean
> things somewhere along the line?
> 
> right.
> 
> i think what actually happened is that they knowingly lied just to get their
> preferred option approved, and actually had no intention of enabling or even
> allowing continued support of anything except systemd.

Quite possibly, but this needs to be seen in proper context.  IIRC, it's
things like 'daemon package [foo] has an unfixed bug in its SysVInit 
script'.  (Invented theoretical example, because I can't be arsed to
find a real one.)  In which case, guys, your hands aren't broken:  Make
whatever's the obvious fix.  If you're a Debian developer, do a NMU.  If
you're not, put it up in a local repo.  Either your patch will get
merged or perhaps your superior outside package will embarrass the DD
into doing it right _or_ your package will become the standard version.

I've been pretty lazy in the past in allowing bloat and questionable
architectural decisions to enter my systems via Debian package
dependencies, but I finally got my attention drawn to the problem -- 
and it wasn't systemd but rather the whole stack of rather ridiculous
desktop-computing glue creating a dependency hairball:  systemd, udev
(now a wholly owned subsidiary of systemd), PolKit (policykit-1),
udisk2, packagekit, network-manager, systemd-logind, D-Bus.  

IMO, those bits of CADT-ware don't belong on my systems, particularly
servers, and mine is the only opinion that ultimately matters locally,
so I set about getting rid of them.  No polemics required:  It's merely
a technical task, and not actually a particularly difficult one.  As I
showed on my Web page. 

Further, if Debian package maintainers make stupid decisions over time,
I can correct those.  A .deb isn't exactly difficult to understand,
dissect, change, and rebuild, after all.  So, noisy politicking isn't
required, and IMO is almost always a rather poor way to get real-world
objectives achieved.

(Speaking of politicking, I note with amusement the spin-aspiring
Subject header.  Russell, I'll bet that was yours, right?  Here, let me
help:  https://en.wikipedia.org/wiki/Begging_the_question )


> By inclination, i'm in the anything-but-systemd camp because systemd is
> the only one that's actively hostile to other software that it sees as
> competing with it (now or in future).

At least some in the Debian community are particularly annoyed by
the systemd team's unwillingness to take patches for portability 
to kernels beyond Linux. That led Adam Borowski to jokingly dismiss 
OpenRC because it lacks "a hostile upstream". 

https://lwn.net/Articles/511726/

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: How to make systemd more reliable

[Rick Moen via luv-main]

Quoting russ...@coker.com.au (russ...@coker.com.au):

> I don't approve content-free hate comments.  There were no comments about 
> actual issues so none were approved.

I believe you, of course.

Yeah, that's genuinely weird.  I really have no idea why a bunch of
deplorable types (sorry, joke from current USAian national politics)
would be set off by that blog post with displays of culture-wars
bigotry, as it's just a straightforward and well-written software tutorial.

> https://mako.cc/copyrighteous/pledge-to-killfile-andrew-suffield

Hmm, key part of rationale was:

  However, since responses that quote unecessarily provocative messages
  are visible by folks who have ignored the sender, blocking email from a
  person (also known as killfiling) only works if done en-mass.

Mistaken rationale.  Please see 'Procmail Trollkiller - Filter to
autodelete posts from a roster of trolls and all first-level replies
unless the mail is addressed to you directly' on
http://linuxmafia.com/kb/Mail/ .

Further to that:

http://linuxmafia.com/~rick/lexicon.html#edwards

   Edwards's Law

  "You cannot apply a technological solution to a sociological problem."
  Nobody seems to know who Edwards was, but pretty much the entire system
  administrator profession rests on the implicit assumption that he/she
  was egregiously mistaken.

  This plausible-sounding but empty-headed dictum is most often referred
  to as "Edwards' [sic] Law" -— by the depressingly huge mass of
  semi-literates unable to correctly write possessives of singular nouns
  ending in "s".

(In _no_ way am I expressing opposition to stronger measures, including
in particular bannings.  I'm just saying that the cited rationale for
the case of Suffield rests on the assumption that one is not very good
at effective use of killfiling.)


> Andrew eventually chose to resign from Debian.

I'm sure Debian Project is better for that.  It's better than the usual
escalation pattern where people do as much damage as they're permitted
before finally flaming out.  Which is a second item on my 'lexicon'
page.  ;->

(http://linuxmafia.com/~rick/lexicon.html#moenslaw-murdersuicide)


> Things really have improved.  Anyone who doesn't think so probably doesn't 
> know what used to happen.

Glad to hear it.  I'm just an interested outsider and a Debian-using
sysadmin.

> http://www.newyorker.com/humor/daily-shouts/as-a-vocal-male-feminist-im-offended-that-i-wasnt-invited-to-your-bachelorette-party

I'm not particularly 'vocal' and certainly not offended at anything --
just really amused at being told I'm 'not a feminist' after 40 years'
involvement with N.O.W. activities.

But you have the same right to redefine words to suit your rhetoric as
everyone else on the Internet, I guess.

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: How to make systemd more reliable

[Rick Moen via luv-main]

Quoting russ...@coker.com.au (russ...@coker.com.au):

> Yet occasionally people do such things.

I see you're back to ignoring my point.  Ah well.

> > Also, poorly socialised nerds don't perceive NSA as taking their toys
> > away the way (e.g.) entitlement-crazed debian-user subscribers do when
> > faced with the prospect of 1000+ developers not promising to do do
> > exactly what they, the debian-user subscribers, want.
> 
> The Snowden revelations effectively forced the world to use HTTPS.  That took 
> a few toys away.

Again, pretty much failing to grasp nuance and context, here.  I don't
think the intended meaning of 'taking their toys away' was unclear, but
you're not really following, and seemingly not actually trying.

> > However, I think it a rather more likely factor that the 8Chan types had
> > already glommed onto the systemd discussion within Debian as being a
> > symbolic 'SJW' issue, hence they jumped in with their characteristic
> > vitriol even though they overwhelmingly have little or no interest in
> > Debian or even Linux.
> 
> However would they have got that idea?

Um, because they're pretty much a crazy rage-mob?  I mean, you _do_ have
some idea what I mean when I say '8chan types', right?

> https://etbe.coker.com.au/2015/01/13/systemd-notes/
> 
> No, I'm referring to the above blog post which was linked from the anti-
> systemd-people post.

Then, I'm no wiser, since no comments are displayed there.  Perhaps you
deleted them (but the archive.org snapshots all have 'Comments are
closed' at the bottom, too).

> When someone makes malicious bug reports it takes a lot more effort to delete 
> them than simply deleting a message.  It is impossible for a regular DD to 
> killfile someone from the BTS, only the sysadmin team can do that.

Welcome to the Internet, I guess.  It's 2016, and there are bored
net.randoms doing rage-mobbing.  (And, again, in all likelihood, I'm
betting that many of those were just joy-riding outsiders getting their
entertainment from piling fuel on a scrapheap fire.)


> Surprising really given all the other toxic stuff that has happened in
> Debian.  Debian is so much better than it used to be!

_I'm_ not surprised.  Joey was reacting to some pretty serious internal
ugliness within the project's internal affairs to which, as a key
developer, he had a front-row seat.  And _also_, separately from and in
addition to that, IMO the project haplessly being dragged by the GNOME
multiseat API, of all the petty things, into bad administrative
decisions was pretty pathetic.

You think those bad administrative decisions were correct, so you think
everything's better and better.  We shall therefore politely agree to
disagree on this matter.


> But it was this issue out of the thousands of issues that have arisen 
> previously that got the involvement of the outside users and demonstrated the 
> problem to a level that Joey couldn't ignore.

I think it very clearly called Joey's attention to pre-existing
structural problems that he felt are unfixable.  And therefor resigned
as a DD and orphaned all of his packages.

> No, it's just that I am sticking to the exact meaning of my statement and not 
> allowing you to reinterpret it.

Again, I really don't think my meaning was difficult to grasp, but I do
think you have a serious deafness to context and nuance.  (This is
rather common among computerists, of course.)


> I think that when a man is claiming to be a feminist it's strongly
> correlated to him being a jerk.  This is evidence to support that
> theory.

Well, as they say in the American South, 'Bless your heart.'  ;->

Still not interested in that copy of my 1976 cheque to join N.O.W.?  
And maybe I can throw in some 1980s and 1990s snapshots of my doing
escort duty of Planned Parenthood clients, walking them through Operation
Rescue picket lines, for good measure.
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: How to make systemd more reliable

[Rick Moen via luv-main]

Quoting russ...@coker.com.au (russ...@coker.com.au):

> More complex things have been done in Debian before.  Getting the full GNOME 
> functionality without systemd might not be possible, but getting the 
> functionality that most people want (IE what has been commonly available 
> before systemd) shouldn't be difficult.  Unless of course they alienate most 
> of the people who are capable of doing the coding in question.

Even at that, maintaining compatible repos of components modified to the
preferences of a community is something done all the time.  I pointed
out to the Devuan people that the Siduction and (now-dormant) Aptosid
distributions have done exactly this, for many years.

(Both of those are installable live-CD distros closely compatible with
Debian-unstable with repos to do stabilisation and add some small local
improvements.)

 
> Why systemd out of all the things that I have blogged about?

Give me a few milion AUS$, and I'll do a proper sociological study.
Short of that, I can speculate: 

Being angry at SE-Linux maintainers would be the world's lamest and
least dramatic way of expressing pique at NSA over data collection.
Also, poorly socialised nerds don't perceive NSA as taking their toys
away the way (e.g.) entitlement-crazed debian-user subscribers do when
faced with the prospect of 1000+ developers not promising to do do
exactly what they, the debian-user subscribers, want.

I intend the phrase 'taking their toys away' figuratively, but sometimes
this can be observed more literally, a spit the dummy instance[1] --
such as when my co-worker Nick Moffitt at VA Linux Systems rashly
mentioned on the internal developers' mailing list that one of the tools
they were using is proprietary.  I told him 'Nick, you shouldn't have
been surprised at the screams of outrage.  They read your posting as
threatening to take their toys away.'  Technogeeks do that at the drop
of a hat.

However, I think it a rather more likely factor that the 8Chan types had
already glommed onto the systemd discussion within Debian as being a
symbolic 'SJW' issue, hence they jumped in with their characteristic
vitriol even though they overwhelmingly have little or no interest in
Debian or even Linux.

And, if you're referring in particular to your 'anti-systemd-people'
blog post, if you didn't set out to flamebait that lot (and, actually,
to flamebait anyone who's not an admirer of the systemd suite), you sure
did a heck of a job of it without trying in _that_ posting.  I mean, if
you tell me you weren't aiming for that, I'll believe you, but I've
seldom seen something that _is_ that flamebaity, so intended or not.

And, of course, that lot are simply the noisiest people around.

> Why is systemd the sole technical issue which has resulted in so much abuse?  
> Why are 2 of the 3 topics which get abuse targetted by the same people?

Because you drew spillover from dumb, noisy, emotive culture-warfare
habituated by dumb, noisy, emotive people.  Obviously.  Has nothing
really to do with Debian, and nothing even really to do with Linux.


> Actually others have been identified.  But some of the discussion in question 
> has been on private mailing lists.

I commented (obviously) only on what I saw, which is what you posted
here and on your blog.

 
> The options that were most seriously considered for a Debian default were 
> systemd and SysVInit.

I'm of course aware of that, but this seems entirely unresponsive to my point.  


> Some addresses have been banned from the Debian BTS.  But that doesn't
> scale well and causes some annoyance to people maintaining the
> packages in question and the Debian sysadmin team.  You don't get to
> just use a killfile if you are part of a project like Debian.

I see nothing in the Social Contract, New Maintainer's Guide, or any
other aspect of being a DD that would in any way mitigate against
killfiling abusive people.  Nor should there be.

But on the other had, Joey Hess is a good friend of mine, and I know
quite a bit about how his dismay over the whole systemd fiasco lead to
his resignation and walking away -- a terrible loss to the project.  
I might point out that his primary source of alienation was not the 
flamers but rather the extreme organisational dysfunction revealed to
him by the way the project conducted itself.  Joey came to the
conclusion that the Debian Constitution is toxic, causing dysfunction
and pushing away good people as an emergent effect.


> True.  But the whole process of arguing about systemd has put a lot of people 
> off.  Anyone who's not up for an argument is probably giving such packages a 
> wide berth.

As I said, Joey is a good friend of mine -- and in his view the problem
was less the outside users' misbehaviour than Debian Project's, itself.

(I make no comment on his view.  You would have to ask him for any
further particulars, so please don't expect me to provide them.)


> It is exactly linked with those utilities.

{sigh}  Your phrase 

Re: How to make systemd more reliable

[Rick Moen via luv-main]

Quoting russ...@coker.com.au (russ...@coker.com.au):

> Yes, you can do that.  It's much easier than creating a new web site
> for a new "distribution" which seems to be Debian with a few packages
> changed.

Indeed, some of the Devuan people were rather upset with me.  ;->  (A
bunch of them had quite a fit over my expressed view that the desired
objective could have been achieved without a distribution fork.
Refreshingly, the project leader was not among those, and recognised
that I merely politely hold an opinion differing from that of their
project.)

(I note with appreciation your having addressed this very point in your
blog post:  'The sensible option would be to just maintain a separate
repository of modified packages as has been done many times before.'  I
entirely agree.)

You'll note that I carefully document on my page what _cannot_ be easily
achieved with my approach, at least without supplementing Debian 8 using
third-party package repos.  The main thing is, of course, GNOME as a
whole (but the lion's share of GNOME apps are within easy reach).


> It's what I see.

Nothing wrong with your saying so.  (I don't like flamers, misogynists,
and homophobes, either.)  I merely note that this entirely fails to to
address the technical substance -- and acts as if there were nothing to
discuss about that.  And it seems more than a little suspicious that you
spent pretty much all your time viewing with alarm the aforementioned
deplorable people, with nothing I recall about other non-systemd people
with dramatically different attitudes.  You know some of those, of
course, and did when you wrote your blog post.  Their absence from your
wall of anti-deplorables text seems... convenient.


> I am happy for people to document how to not use systemd and I don't
> flame anyone for doing so.  Why do they flame me and others for
> describing how to use systemd?

Because the existence of 7.2 billion homo saps guarantees a significant
number of very odd people on the Internet?  And because of John
Gabriel's 'Greater Internet F***wad Theory'?  ;->  (Warning:  crude
language, but in context not gratuitous)
https://photos.smugmug.com/photos/i-mHzvgPv/2/O/i-mHzvgPv.jpg



> > I'm sure you're aware that this variety of rhetoric suffers a rather
> > serious 'if so, so what?' problem (residing somewhere among the
> 
> It's "if so don't deal with those people" as so many people have done.

I think you're (probably) missing the point.

Your blog post flogs the point that some bunch of unidentified (except
for one notorious example) bunch of people expressing anti-systemd views
behaved badly.  But if so, so what?  This not only says absolutely
nothing about the software (to be fair, your blog intro says it won't
really address the software), but also nothing about non-systemd users
who aren't going around screaming and shouting, aren't cursing D-Ds in
bug reports, and otherwise aren't abusing volunteers or spewing ugly
antisocial behaviour.  

It pretends as if those (including yr. humble servant, I hope) don't
exist.  Worse, it attempts to slur us by association, e.g.:  'Decent
people don’t want to be associated with people like MikeeUSA, the fact
that the anti-systemd people seem happy to associate with him isn’t
going to help their cause.'  



> There are more than a few DDs who have nothing to do with SysVInit
> because of the people who they have to deal with if they choose to do
> so.  Why go to the effort of supporting software if there is a better
> alternative that has the added benefit of avoiding assholes?

_Again_ with the comparison to _just_ SysVInit, as if OpenRC, Runit, and
Upstart weren't also maintained packages in Debian-main, and as if nosh
weren't available in a compatible .deb from a third-party repo, and as
if s6, perp, nosh, ninit, sinit, minit, finit, Epoch, and uinit were not
available in source and easy to build.

Anyway, I have a difficult time believing DDs are helpless to use
killfiles.

> There's nothing wrong with being a bit "conservative" in the
> dictionary sense (IE not the Trump or Abbott sense).  Being
> conservative in such ways is why we have had SysVInit for so long.

This is of course changing the subject, as this is not what I meant by
'mere conservatism'.

> Upstart is no longer the default for Ubuntu, I guess it's future isn't
> that good.

I've never liked Upstart myself -- but it's open source and able to be
maintained if anyone continues to care.


> If you want a tiny minimal init then having one that is linked with
> cp, mv, etc probably isn't the way to go.

Busybox isn't exactly 'linked with' those.  The code in the Busybox
binary able to fulfill those functions isn't used when invoked as
/sbin/init, I'm pretty sure.  However, yes, it's certainly not ideal.
The likes of the s6 PID1 init are probably a lot better.


> The PID1 program could reap processes and then inform the supervision
> process about it.

Yes, but this introduces complexity that's just not really worth 

Re: How to make systemd more reliable

[Rick Moen via luv-main]

Quoting russ...@coker.com.au (russ...@coker.com.au):

> People who have chosen systemd have spent a lot of time making it work better 
> and solving some real problems that other init systems have had for many 
> years.  People who want to choose SysVInit have spent a lot of time flaming 
> people who write the code.

I continue to like OpenRC a great deal, as the init system.  I'm still
looking around for the most conservatively written, narrowly scoped PID1 
process.  (OpenRC doesn't handle being PID1.)

I've written a description of how to (very easily) convert Debian 8
'Jessie' over to OpenRC -- or to runit, sysvinit, or upstart, all of
those available packaged in Debian 8 -- and make that architecture
decision persist.  It turned out to be very easy.  Actually I wrote
the basic details on this mailing list, in response to a question about
that.  Later, I fleshed out the topic for my Web site:
http://linuxmafia.com/faq/Debian/openrc-conversion.html


> We had a "debate" about the relative merits of the various init systems on 
> this list some time ago.  It turned out that only one of the people who were 
> criticising systemd had actually used it, and that person wasn't making the 
> more extreme criticisms.
> 
> https://etbe.coker.com.au/2015/04/26/anti-systemd-people/

Both on this mailing list and on your blog, you seem obsessed with, in
effect, calling some set of unnamed but broadly scoped critics names,
e.g., that they're just flamers, misogynistic, homophobic, and driven by
hostility and hate.

I'm sure you're aware that this variety of rhetoric suffers a rather
serious 'if so, so what?' problem (residing somewhere among the
subvarieties of non-sequitur appeal).  But anyway, I generally find it a
great deal more interesting to discuss technology, than to detail at
length how awful are the tribe on the other side of the figurative
river.

In your more _charitable_ moments, you've been known to dismiss being fond
of something other than systemd as mere conservatism -- relying on,
among other things, the false assumption that anything else is
backwards.  A point I'll get to in a moment.  However, I did want to
stop here and praise the 'mere conservatism' rhetoric as at least not
the total non-sequitur fallacy that the name-calling is.  ;->


> It's quite likely that I have contributed more patches for init systems than 
> anyone else on this list.  The attitude of SysVInit fans doesn't make me 
> inclined to spend any more effort patching that init system.

You know, I just remembered what this 'systemd must always be compared to
SysVInit and nothing else' trope reminds me of:

djbware fans would always characteristically compare qmail only with
Sendmail, and djbdns only with BIND.  This behaviour persisted _long_
after Postfix, Exim, and Courier-MTA emerged as competitors to qmail,
and long after NSD/Unbound, PowerDNS, and MaraDNS/Deadwood emerged as
competitors to djbdns.  A cynic might imagine these worthies to be
unwilling to compare against _modern_ alternatives to Prof. Bernstein's
eccentric creations.

Anyway, thank heavens, Unix open source offers a smorgasbord of
worthwhile options in the software categories in question.  Here is a
partial list:

init systems:  systemd, Upstart, Epoch, finit, SysVinit, initng, runit, 
   s6, OpenRC, BSD init, nosh.

inits (PID1):  BusyBox, SysVinit, ninit, sinit, minit, systemd,
   BSD init, Upstart, finit, runit, Epoch, nosh, uinit.

service managers:  OpenRC, finit, runit, daemontools / daemontools-encore, 
   systemd, s6-rc, initng, Epoch, nosh, anopa, supervisord.



My current idea of a good system composite is a really tiny, minimal
PID1 (leaning towards BusyBox[1]) spawning OpenRC as the init system.  
If I ever actually need service supervision, I'd probably use runit 
or supervisord on whatever daemons merit such supervision.

Because, really, building big feature sets into PID1?  I rather think
not.  It should catch signals and reparent orphan processes (reap
zombies), and collect their return status.  Processing poweroff and
reboot is nice (as part of catching signals).  All else including the
rest of process handling (the 'init systems' bit), such as process
supervision, dependency management, daemon start/stop, libdbus
interface, handling /dev changes, monitoring mount points / 
files / sockets / timers, parsing of various files / messages / strings,
and all the rest, need not be in PID1, so I'd rather it _not_ be in such
a sensitive and vital place.

Yes, having process supervision in PID1 is the only way for total
process control to be possible, but I don't have any use-cases where
that is actually needed.

And socket activation is actually a big dumb bad idea as we know from
initd/xinetd, but available with sundry toolkits if you actually want
it.

Please notice that I don't call either systemd or its acolytes names.  I
merely say 'I'm glad you like it' to the latter and 'No thanks for now,
but I'll 

Re: How to make systemd more reliable

[Rick Moen via luv-main]

Quoting Andrew Pam (and...@sericyb.com.au):

> On 29/09/16 16:12, Rick Moen via luv-main wrote:
> >ftp://linuxmafia.com/pub/humour/ed-is-the-standard-text-editor
> 
> I miss TECO.  Oh no, wait, no I don't.
> 
> Cheers,
> Andrew

{laughs}

But what does your _name_ do in TECO?  ;->

(I first encountered vi during summer session at Evans Hall, University 
of California at Berkeley -- the very building in which it was written.
This was circa 1980, I think.  I absolutely _loathed_ it.  Irony, there,
as for the last twenty years or so I might as well set
init=/usr/bin/vim, as I spend most of my time, there.)

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: How to make systemd more reliable

[Rick Moen via luv-main]

Quoting Paul van den Bergen (paul.vandenber...@gmail.com):

> Fanbois huh?  vi or emacs?

ftp://linuxmafia.com/pub/humour/ed-is-the-standard-text-editor

(For some reason, many Yanks cannot seem to locate my humour directory.  
I blame the education system -- lamentable problems spelling the English
language, and all that.)

-- 
Cheers,My pid is Inigo Montoya.  You kill -9
Rick Moen  my parent process.  Prepare to vi.
r...@linuxmafia.com
McQ!  (4x80)
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: pdns security update (was Re: NBN satelite setup)

[Rick Moen via luv-main]

Oh, meant to add:

> >  - powerdns is serious overkill for my needs (home server with only a
> >few domains).
> 
> Yeah.  $WORK did a massive conversion of hundreds of domains from BIND9
> to PowerDNS Authoritative Server, and there were various problems along
> the way.  I'm not convinced it was a good idea, even for a large
> Internet firm that does that many domains.  Probably on balance (gains
> in performance and security), but with some reservations.

I recently stumbled upon a (new?) feature of BIND9's 'rndc' control
utility that reduces the relative attraction of PowerDNS:  ability to
add/remove zones without restarting BIND:

  Problem

  You want to add a new zone or delete an existing zone without restarting
  or reloading a name server.

  Solution

  Add a new zone statement to named.conf or delete an existing one, then
  run rndc reconfig (for BIND 9) or ndc reconfig (for BIND 8).

https://www.safaribooksonline.com/library/view/dns-bind/0596004109/ch05s07.html


At $WORK prior to the changeover to PowerDNS, we had greatly reduced the
risk inherent in restarting BIND9 by building into our rollout process
what they flattered me by naming the 'Rick test' using BIND9's
named-checkconf utility:

#Double-check BIND conffile:
/usr/sbin/named-checkconf -z -t /var/named/chroot/ /etc/named.conf | \
egrep 'missing|not allowed|unknown|not at top of zone|\
appears to be an address|no current owner name|MAXTTL|file not found|\
may not be used with|outside epoch|in future|invalid|unsupported|no TTL|\
ignoring| TTL set to prior TTL' | sort -u 
#Should return null.

This 'lints' the conffiles and all referenced zonefiles (-z), giving you
advance warning of problems that might either prevent BIND9 startup or 
invalidate individual zones at load time.  This alone prevented a lot of
downtime.  And 'rndc relaod [zone]' eliminated most restarts.
_However_, ability to add/remove zones without restarting BIND is huge,
and should eliminate almost all restarts.
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: pdns security update (was Re: NBN satelite setup)

[Rick Moen via luv-main]

Quoting Craig Sanders (c...@taz.net.au):

> On Fri, Sep 16, 2016 at 01:12:07AM -0700, Rick Moen wrote:
> 
> > _But_ that is completely unrelated to pdnsd.
> 
> ah, my mistake.  i assumed he was talking about powerdns.

No worries.  ;->

> > http://linuxmafia.com/faq/Network_Other/dns-servers.html
> 
> good page that, i've read it before but not for some time. IMO a useful
> addition to it would be a list of authoritative servers that use bind9
> RFC-1034 zonefiles.

You know, they kind of _could_ have called that format the RFC-1034 file
format, as some RRs are described/defined there, but because all the key
ones are described/defined in accompanying RFC-1035, it's generally
called 'RFC-1035 format'.

Anyway, yes, good idea -- and I actually do document RFC 1035 support
where I know about it.

> apart from "it aint broke, why fix it?" laziness, one of the reasons i'm
> still using bind9 is because I don't want to rewrite my zone files in
> a new format (or even have to learn a new format), and I haven't been
> overly happy with the few alternatives I've tried that could use bind
> zonefiles.
> 
>  - powerdns is serious overkill for my needs (home server with only a
>few domains).

Yeah.  $WORK did a massive conversion of hundreds of domains from BIND9
to PowerDNS Authoritative Server, and there were various problems along
the way.  I'm not convinced it was a good idea, even for a large
Internet firm that does that many domains.  Probably on balance (gains
in performance and security), but with some reservations.

>  - last time i looked at it (years ago, not long after it was released),
>there were some incompatibilities between NSD's interpretation of
>bind zonefiles and bind9's interpretation.

I believe you, but haven't seen this.  I've administered NSD on
ns1.svlug.org from NSD 2.x days onwards, and it's been really good.
I've not encountered any zonefile-parsing weirdness.  (I still run BIND9
on ns1.linuxmafia.com .)

Searching for data on this, I find some docs in their initial public
release candidate:
https://www.nlnetlabs.nl/downloads/nsd/OLD/nsd-1.0.0-rc2/REQUIREMENTS
'Section C. Technical Specifications has C.1. Zone file format and RR
records.'  It basically _claimed_ NSD would parse any valid RFC 1035
file containing only IN-class RRs.  FWIW, I've not seen NSE 2.x and
later's parser reject or get wrong anything from my own zones.

> Also, I didn't want to
> have to run two name servers (internet-facing authoritative and
> private LAN recursive) - although dnsproxy or similar could solve
> that problem now. it's probably worth another look.

I found about a year ago what struck me at the time as the ideal
solution to that problem but failed to add it to my linuxmafia.com
knowledgebase.  Maybe it was dnsproxy.  

Here's a creative solution from one of the NLnet Labs guys:
https://www.nlnetlabs.nl/pipermail/nsd-users/2014-August/001998.html

  It is possible, but not using the same address+port of course. One
  solution is to have NSD only listen on localhost while unbound listens
  on the external adress. You can then use stub-zone configuration in
  unbound to make it use the localhost adress for lookups in any zone you
  are serving from NSD.

  This is what i do for my home network, for a production setup I would
  rather keep authorative and caching DNS services fully separated.

However, followup from a different poster stresses that this is
appropriate only for serving a private zone from NSD, as it wouldn't
have the AA bit set.  This is similar:
https://www.nlnetlabs.nl/pipermail/nsd-users/2014-August/002000.html

The ArchLinux wiki proposes a different soution:  Bind NSD to
127.0.0.1:53530, and bind Unbound to *:53 with the auhtoritative zones
declared as ones to refer to NSD using the 'local-zone' and 'stub-zone' 
features:
https://wiki.archlinux.org/index.php/Nsd

The 'Dnsspoof' examples on
https://web.archive.org/web/20160329083109/https://calomel.org/unbound_dns.html
show some ways to leverage the DNS host being dual-homed (if it is).

Other solutions might beckon if the host is multihomed, e.g., bind NSD
to the public-facing real IP, and bind Unbound to the private RFC1918
address.

Personally, when I do my next server rebuild on ns1.linuxmafia.com 
(which is a totally public-facing 'bastion host', not dual-homed),
what I'll probably do is IP-alias a second public IP address onto the
public network port (its sole network port other than loopback), 
and bind NSD to one and Unbound to the other -- which has the benefit of
simplicity, letting me easily ACL the daemons individually, and keeping
their configurations totally separate.  Fortunately, I have spare IPs.

None of this tested by your present correspondent.  Yet.  ;->

>  - maradns provides a conversion tool for bind zonefiles, but doesn't use
>them natively.  otherwise, i'd probably switch to it.   I've used it
>several times on gateway boxes i've built for other people.

I like author Sam Trenholme quite 

Re: pdns security update (was Re: NBN satelite setup)

[Rick Moen via luv-main]

Quoting Craig Sanders (c...@taz.net.au):

> On Wed, Sep 14, 2016 at 07:10:43AM +1000, zlin...@virginbroadband.com.au 
> wrote:
> > I am using pdnsd 
> 
> FYI, I saw this DSA come in a few days ago:
> 
> https://www.debian.org/security/2016/dsa-3664
> 
> Debian Security Advisory
> DSA-3664-1 pdns -- security update

Craig, PowerDNS Authoritative Server is sometimes called 'pdns', and
that is the name of the related Debian package.  (Complementary codebase
PowerDNS Recursor has Debian package pdns-recursor.)  _But_ that is
completely unrelated to pdnsd.

http://linuxmafia.com/faq/Network_Other/dns-servers.html#pdnsd
http://linuxmafia.com/faq/Network_Other/dns-servers.html#pdns
http://linuxmafia.com/faq/Network_Other/dns-servers.html#pdns-recursor

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: NBN satelite setup

[Rick Moen via luv-main]

Quoting zlin...@virginbroadband.com.au (zlin...@virginbroadband.com.au):

> I am using pdnsd as a local cacheing from a sugestion from Russell
> Coker, this turned out to be a real excellent sugestion as it sped
> up page loading no end (this was on dialup).

I'm sure it would -- just from the caching.  However, FWIW, you can do
better still, by running a recursive nameserver such as Unbound.  pdnsd
is terrific for what it is, but it's ultimately just a small caching
forwarder with no intelligence of its own.

http://linuxmafia.com/faq/Network_Other/dns-servers.html#pdnsd
http://linuxmafia.com/faq/Network_Other/dns-servers.html#unbound

To explain and disambiguate the type of DNS software:
http://linuxmafia.com/pipermail/sf-lug/2008q3/006880.html
http://linuxmafia.com/pipermail/sf-lug/2008q3/005293.html

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: outage

[Rick Moen via luv-main]

Quoting Brian May (br...@linuxpenguins.xyz):

> A classic example is the "signal failure" excuse that is vastly overused
> by Metro trains and prior companies. We rarely hear what went wrong,
> unless it results in being able to divert blame (rightly or wrongly)
> onto somebody else (e.g. possum getting electrocuted and shorting high
> voltage power or lightning strike).

I'm reminded about the old British Rail gag about 'the wrong type of snow'
being cited as an excuse for problems.
https://en.wikipedia.org/wiki/The_wrong_type_of_snow

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Brother scanner driver

[Rick Moen via luv-main]

Quoting Rohan McLeod (r...@jeack.com.au):

> Bob via luv-main wrote:
> > Hello all,
> > I have set a box for a friend running Kubuntu 16.04 with a brother
> > MF7680DW multifunction printer/scanner attached via usb.
> 
> Are you sure that model number is correct ; google can't seem to find it !

I suspect:  Brother MFC-7860DW Compact Monochrome Laser All-in-One Printer
(Note digit transposition.)

There's some sort of dismal proprietary binary-only SANE driver from the
manufacturer.  (Personally, I regard that as the manufacturer telling
you 'Hullo, you bought unwisely, and should sell this hardware to
someone and buy a replacement supported by open source, but perhaps
that's just me.)

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Anyone for Telstra Air

[Rick Moen via luv-main]

Quoting Andrew McGlashan (andrew.mcglas...@affinityvision.com.au):

> I don't use ANY Telstra services and I most definitely NEVER use public
> WiFi, as I believe that NEITHER can be trusted; that includes Telstra
> themselves of course!

One alternative is to use networks but not trust them.  This is my
preference on _any_ network, frankly.

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Who owns Android ?

[Rick Moen via luv-main]

Quoting Ben McGinnes (b...@adversary.org):

> On Thu, May 12, 2016 at 11:54:41AM +1000, Russell Coker via luv-main wrote:
> > 
> > Libertarianism is all about liberty for the super-rich and serfdom
> > for people like us.
> 
> 
> For instance my lot, Pirate Party
> Australia...

Yay, Pirate Party!  My wife and I were just at lecture at Institute for
the Future in Palo Alto given by Smári McCarth, co-founder of Iceland's 
Pirate Party, entitled 'From the Panama Papers to the Pirate Party'.
http://www.iftf.org/future-now/article-detail/smari-mccarthy-from-the-panama-papers-to-the-pirate-party/

Anyway, in hopes of making this thread useful, I'll post links to
recommended resources about open source applications on Android:

http://linuxmafia.com/pipermail/conspire/2016-May/008449.html
http://linuxmafia.com/pipermail/conspire/2016-May/008450.html
http://linuxmafia.com/pipermail/conspire/2016-May/008454.html


P.S.:  LUV member Mark Trickett, in particular, will also wish to see
http://linuxmafia.com/kb/Debian/openrc-conversion.html .  You're welcome.
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Impending Crypto Monoculture

[Rick Moen via luv-main]

Quoting Andrew McGlashan (andrew.mcglas...@affinityvision.com.au):

> letsencrypt perhaps?  It works very well.

It (https://letsencrypt.org/, a recently invented, automated, no-charge
CA) solves the one specific problem it set out to solve, well.  And it's
commendably well intended & benevolent.

But, IMO, the entire CA model is unfixably broken, _so_ Let's Encrypt is a
benign attempt to prop up a hopelessly bad CA framework that needs to just die.
For details, rather than my recapping the conversation I had about
Let's Encrypt just this past month, please see:

http://linuxmafia.com/pipermail/conspire/2016-March/008389.html

Further downthread discussion:
http://linuxmafia.com/pipermail/conspire/2016-March/008390.html
http://linuxmafia.com/pipermail/conspire/2016-March/008391.html
http://linuxmafia.com/pipermail/conspire/2016-March/008392.html

-- 
Cheers,  "My life has a superb cast,
Rick Moenbut I cannot figure out the plot."
r...@linuxmafia.com   -- Ashleigh Brilliant
McQ! (4x80)  
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Impending Crypto Monoculture

[Rick Moen via luv-main]

Quoting Chris Samuel (ch...@csamuel.org):

> It's an interesting situation, though I think I'd trust Dan a bit more than I 
> trust the USG now. :-)

I trust Dan a _great_ deal more than I do the USG, and that's after he
sort-of-almost-threatened a bogus lawsuit against me 2001 for committing
'libel' [sic] against his software on my Web page (and acting 'against
the law' on it), the Web page I'd pointed people to from 1999 onwards,
rather than continually repeating why I had disliked adminstering qmail
for a living during 1999 (back when qmail was still relevant).
https://linuxmafia.com/~rick/faq/dan-brandishing-legal-threats

That being said, Guttman's point is extremely well taken that we need
more than just djbware.  Personally, I'm all for being a patent
scofflaw, if necessary.

-- 
Cheers,   "My opinions may have changed, 
Rick Moen but not the fact that I'm right."
r...@linuxmafia.com   -- Ashleigh Brilliant
McQ! (4x80)  
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: simple CLI MUA for GPG

[Rick Moen via luv-main]

Quoting luv-main@luv.asn.au (luv-main@luv.asn.au):
> On 12.04.16 11:01, Rick Moen via luv-main wrote:
> > 
> >   In August, I wrote [link] about the NSA's plans to move to 
> > quantum-resistant
> >   algorithms for its own cryptographic needs.
> 
> Rick,
> 
> Reading your post in mutt, I see 3 x "[link]", but no urls anywhere.
> Opening the raw post in vim, and piping the body to "base64 -d", the
> result is still the same. Were there urls in it when posted?

As I post in ASCII (by preference), I merely wrote '[link]' where
Schneier had a hyperlink in the cited HTML article, so interested people
would know that links existed there.

Article is, as I said, at
https://www.schneier.com/blog/archives/2015/10/why_is_the_nsa_.html,
where you will find the links and can follow them.

Sorry that the intent was unclear.

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: simple CLI MUA for GPG

[Rick Moen via luv-main]

Quoting Trent W. Buck (trentb...@gmail.com):

> My (armchair, inexpert) impression is that this isn't a reasonable
> inference.
> 
> It'd be like saying "the wheel feel off my bicycle, therefore all
> wheeled vehicles are suspect".

Oh, I certainly wasn't saying 'doubt everything', as unfocussed
paranoia is pointless and non-functional.  Rather doubt _more_ (and
examine carefully), is all I was saying.

In case you weren't following links, Schneier noted six months ago the
curiosity of the Never Say Anything people moving away from
elliptic curve cryptography citing some alleged future threat from quantum
computing, and linked to both a long academic paper by two cryptographers
speculating as to the government's real motives for doing this, and a
much shorter commentary and critique of that paper by Matthew Green
(http://blog.cryptographyengineering.com/2015/10/a-riddle-wrapped-in-curve.html).

  If you’re looking for a nice dose of crypto conspiracy theorizing and
  want to read a paper by some very knowledgeable cryptographers, I have
  just the paper for you.  Titled “A Riddle Wrapped in an Enigma” by Neal
  Koblitz and Alfred J. Menezes, it tackles one of the great mysteries of
  the year 2015.  Namely: why did the NSA just freak out and throw its
  Suite B program down the toilet?

Interesting reading -- and again I think of Schneier's dictum that in
cryptography newer is worse, all other things being equal.

In a nutshell, what Green finds to be the most plausible and compelling
hypothesis in Koblitz and Menezes's paper is that NSA isn’t
worried about quantum computers at all, but rather that they’ve made a
major advance in _classical_ cryptanalysis of the elliptic curve discrete
logarithm problem, rendering ECC as a class of ciphers generically weak 
and making its advantage in key length no longer worth the drawback.


> You may also wish to be angry about more broadly, about
> https://en.wikipedia.org/wiki/FIPS_140-2#Reception
> http://opensslrampage.org/post/83555615721/the-future-or-lack-thereof-of-libressls-fips

I frequently do admire the attitude of Theo de Raadt and company.

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: simple CLI MUA for GPG

[Rick Moen via luv-main]

Quoting Andrew McGlashan (andrew.mcglas...@affinityvision.com.au):

> The NIST problem is specific to /their/ earlier recommendations; and no,
> I don't think you can trust NIST.

For me specifically as opposed to most people here, the subversion of
NIST was particularly irritating because it's funded by _my_ tax
dollars.  ('Their recommendtions' were seemingly fed to them by No Such
Agency -- and NIST had the abysmal judgement to accept same uncritically.)

> But if you stay clear of the particular NIST EC option, then other EC
> options are okay.

Well, that's the interesting question, isn't it?   It's not at all clear
that such are OK.  (Please see links.)  Much has necessarily been cast
into doubt.

-- 
Cheers,  Controversy is dreaded only by the advocates of error.
Rick Moen -- Benjamin Rush
r...@linuxmafia.com 
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: simple CLI MUA for GPG

[Rick Moen via luv-main]

Quoting Glenn McIntosh (neonsig...@meme.net.au):

> Ecrypt have published a couple of reports on keysizes. A 512bit EC
> keysize is roughly equivalent to a 15424 bit RSA keysize.
> http://www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf
> 
> These are really just a statement of the mathematical difficulty of
> brute forcing the keys using the best current algorithms, eg a general
> number field sieve for prime factoring vs a naive meet-in-the-middle
> attack to find a discrete logarithm. There are no mathematical proofs of
> the hardness of any of these problems.
> 
> As you point out, security also involves other factors - how well an
> algorithm has been examined by third parties, the soundness of the
> protocols, endpoint security, and so on.

Thank you.  I note, without special objection to the elliptic curve
cryptography recommendation but merely for completeness, that at least
one ECC-based standards, a random number generator based on elliptic
curve mathematics, has proven upon examination to have been compromised:

http://www.wired.com/2013/09/nsa-backdoor/

  Early this month the New York Times drew a connection between their
  talk and memos leaked by Edward Snowden, classified Top Secret, that
  apparently confirms that the weakness in the standard and so-called
  Dual_EC_DRBG algorithm was indeed a backdoor. The Times story implies
  that the backdoor was intentionally put there by the NSA as part of a
  $250-million, decade-long covert operation by the agency to weaken and
  undermine the integrity of a number of encryption systems used by
  millions of people around the world.

  The Times story has kindled a firestorm over the integrity of the
  byzantine process that produces security standards. The National
  Institute of Standards and Technology, which approved Dual_EC_DRBG and
  the standard, is now facing a crisis of confidence [...]

Yeah, thank you _so_ much, Never Say Anything people.  Now, I have to
worry that I can't trust anything from NIST.  Bastards.

IETF and CFRG drew the same conclusions last year, and started moving
towards non-NIST elliptic curves for Internet standards:
https://tools.ietf.org/html/draft-irtf-cfrg-curves-02


I also note this curio from half a year ago:

https://www.schneier.com/blog/archives/2015/10/why_is_the_nsa_.html

  Why Is the NSA Moving Away from Elliptic Curve Cryptography?

  In August, I wrote [link] about the NSA's plans to move to quantum-resistant
  algorithms for its own cryptographic needs.

  Cryptographers Neal Koblitz and Alfred Menezes just published a long
  paper [link] speculating as to the government's real motives for doing this.
  They range from some new cryptanalysis of ECC to a political need after
  the DUAL_EC_PRNG disaster -- to the stated reason of quantum computing
  fears.

  Read the whole paper. (Feel free to skip over the math if it gets too
  hard, but keep going until the end.)

  EDITED TO ADD (11/15): A commentary and critique [link] of the paper by 
Matthew
  Green.

I found the Green paper particularly interesting.

Some days, seems like Charles Stross's _Halting State_ is becoming
non-fiction.

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main