Re: Assorted arm-buster problems - network configuration

[andreimpopescu]

On Mi, 03 iul 19, 21:03:19, Gene Heskett wrote:
> On Wednesday 03 July 2019 16:12:31 Reco wrote:
> 
> And Gene moved. Question unanswered yet.
> > Hi.
> >
> > On Wed, Jul 03, 2019 at 02:57:35PM -0400, Gene Heskett wrote:
> > > Regardless of what I do, I cannot get rid of the avahi junk in an ip
> > > a report, so my local 192.168.xx.nn/24 net is the only thing that
> > > works. pinging a net name like yahoo.com gets me a successful
> > > address. But no response from yahoo because its sending the ping
> > > from an avahi based address, which since thats outside of my /24
> > > netmask, doesn't get thru the router.
> > >
> > > So, how do I get rid of the avahi stuff?
> > >
> > > I've a nominally 10 machine 192.168.nn.xx that is 100% static based
> > > on host files so I want avahi absolutely and totally neutered,
> > > emasculated, gone Forever plus 100 years at least.
> > >
> > > How can I do that?

It's not necessarily avahi doing that. A DHCP client might also 
configure a 169.254.*.* address for you if it doesn't receive a reply.

In order to have the slightest chance of helping you it is necessary for 
you to provide the information as per below.

Files should preferably be attached, to avoid issues with copy-paste. 

Please do not edit anything except to obscure private information (e.g. 
passwords or a public IP you don't want to post).


1. content of /etc/network/interfaces and all files under 
/etc/network/interfaces.d/

(I seem to recall you are using ifupdown)

2. Full output of:
apt list --installed 'network-manager*' # might be empty
apt list --installed 'avahi*' # might be empty
systemctl status systemd-networkd
ip a # short for 'ip address'
ip r # short for 'ip route'

3. Information on anything (and I do mean anything) else you might have 
done to your network configuration after installing buster, including 
but not limited to:
 * installing stuff, especially if from source
 * removing stuff (especially if not 'purged', dpkg -l would tell)
 * manual changes to files (deletions/permissions/etc.
 (especially those unnecessary "fixes" you call "neutering")

For the record/archives: other users are not seeing your problems.

Buster is - at least for me - the best Debian release yet.

The problems you are seeing are, at least partially, of your own doing, 
most likely due to wrong configuration and an approach of using the 
equivalent of a shotgun to kill a fly and then complaining your walls 
are full of holes.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: armv7 vs buster sudo complains about hostname or something

[Gene Heskett]

On Thursday 04 July 2019 02:47:50 Andrei POPESCU wrote:

> On Mi, 03 iul 19, 20:26:48, Gene Heskett wrote:
> > On Wednesday 03 July 2019 18:06:18 John Paul Adrian Glaubitz wrote:
> > > Hi Gene!
> > >
> > > On 7/3/19 10:42 PM, Gene Heskett wrote:
> > > > Just one of the things its taken over. Now we have a different
> > > > command to set the hostname too if you want it to stick over a
> > > > reboot.  Someone a couple weeks ago showed me how to do that for
> > > > hostname only. I've no clue how it does that because it can do
> > > > it even if /etc/hostname has been made immutable. In fact I'd
> > > > call that a major security breech.
>
> I don't remember using hostnamectl on my Pine A64. For reference:
>
> /etc/hostname:
> pine64
>
> /etc/hosts:
> 192.168.0.64  pine64
> 127.0.0.1 localhost
>
> ::1   localhost ip6-localhost ip6-loopback
>
> ff02::1   ip6-allnodes
> ff02::2   ip6-allrouters
>
> > IF, note all caps, then why does sudo bitch so much?
>
> I seem to recall sudo cares about /etc/hosts.

But I have that address TAB hostname.domain.name TAB alias in the hosts 
file. No errors there.

> Kind regards,
> Andrei


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

[RESOLVED/Thanks] Re: Debian Perl or Brew Perl for production application?

[Didar Hossain]

On Tue, Jul 02, 2019 at 01:36:52PM +0200, Alex Mestiashvili wrote:
> On 7/2/19 11:20 AM, Dave Sherohman wrote:
> > On Mon, Jul 01, 2019 at 06:30:19PM +0200, to...@tuxteam.de wrote:
> >> I tend to stick to Debian packages as my primary choice, resorting
> >> to off-distribution packages when needed (e.g. not packaged for
> >> Debian, or I /need/ a newer version). Of course it takes some foresight
> >> to guess in advance whether you expect such a situation in the
> >> future.
> >>
> >> Rationale: they mesh better with the flow of system updates/upgrades.
> >>
> >> I've found Perl packaging in Debian outstanding. The Debian Perl
> >> packaging team does a damn good job indeed.
> > 
> > Pretty much the same here.  I was initially hired as a Perl developer,
> > then gradually moved into more sysadmin duties and, in both roles, I
> > prefer to stick with the Debian-packaged perl binary.  It gets me
> > security updates as needed and the only reasons I see a particular need
> > for PerlBrew and the like are:
> > 
> > 1) You need different compile-time options than Debian chooses
> > 
> > 2) You need access to a feature that's only present in a newer-than-
> >Debian Perl version
> > 
> > 3) You want to have the "latest and greatest" for its own sake
> > 
> > Personally, I've never encountered #1 or #2 in practice and if #3
> > mattered to me, then I wouldn't be running Debian stable in the first
> > place.
> > 
> 
> +1 here, but in case one need the "latest and greatest" modules, in most
> cases it's dead simple to package a not-yet-packaged module with
> cpan2deb from dh-make-perl package.
> 
> One of the benefits of this approach, is that you don't need to bring
> compilers and sources of the dependencies to the production machine.
> Build packages on a "development" node and install binary packages on
> the production.
> 
> In case you need to replicate the setup, or you have more than one
> machine one can maintain a repository,making installation of a new
> system way easier.
> 
> And you also can contribute back to Debian in case you packaged a new
> software.
> 
> Best,
> Alex

Thank you all for your responses. 

My position was indeed to stick with debian packages for the same reasons you
all mentioned. I am simply prone to self-doubt as my background is more of a
systems admin rather than a developer.

Kind regards,
Didar

-- 
Anthony's Law of Force:
Don't force it; get a larger hammer.

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Thursday 04 July 2019 03:16:31 andreimpope...@gmail.com wrote:

> On Mi, 03 iul 19, 21:03:19, Gene Heskett wrote:
> > On Wednesday 03 July 2019 16:12:31 Reco wrote:
> >
> > And Gene moved. Question unanswered yet.
> >
> > >   Hi.
> > >
> > > On Wed, Jul 03, 2019 at 02:57:35PM -0400, Gene Heskett wrote:
> > > > Regardless of what I do, I cannot get rid of the avahi junk in
> > > > an ip a report, so my local 192.168.xx.nn/24 net is the only
> > > > thing that works. pinging a net name like yahoo.com gets me a
> > > > successful address. But no response from yahoo because its
> > > > sending the ping from an avahi based address, which since thats
> > > > outside of my /24 netmask, doesn't get thru the router.
> > > >
> > > > So, how do I get rid of the avahi stuff?
> > > >
> > > > I've a nominally 10 machine 192.168.nn.xx that is 100% static
> > > > based on host files so I want avahi absolutely and totally
> > > > neutered, emasculated, gone Forever plus 100 years at least.
> > > >
> > > > How can I do that?
>
> It's not necessarily avahi doing that. A DHCP client might also
> configure a 169.254.*.* address for you if it doesn't receive a reply.
>
> In order to have the slightest chance of helping you it is necessary
> for you to provide the information as per below.
>
> Files should preferably be attached, to avoid issues with copy-paste.
>
> Please do not edit anything except to obscure private information
> (e.g. passwords or a public IP you don't want to post).
>
>
> 1. content of /etc/network/interfaces and all files under
> /etc/network/interfaces.d/
>
> (I seem to recall you are using ifupdown)
>
> 2. Full output of:
> apt list --installed 'network-manager*' # might be empty
> apt list --installed 'avahi*' # might be empty
> systemctl status systemd-networkd
> ip a # short for 'ip address'
> ip r # short for 'ip route'
>
> 3. Information on anything (and I do mean anything) else you might
> have done to your network configuration after installing buster,
> including but not limited to:
>  * installing stuff, especially if from source
First, on a u-booting raspi you don't "install". You either download an 
image and put it on a u-sd card with dd, or you generate your own image.

Which is what I have done by using a utility from guysoft called 
RealtimePi, which takes the June 20th version of raspian buster lite 
apart, and supposedly puts it back together with a realtime patched 
version of a compatible kernel, which should have been a 4.19.50-rt-v7 
kernel, but when put on a u-sd, and the u-sd booted, turns out to have 
the unpatched kernel in it.  Why I watched it spend an hour building the 
older 4.4.114-rt-v7 kernel and then it didn't use it is something I have 
not found yet in the build.log. Which I can't get to ATM because ssh 
isn't working either.

I can't get any of that until I can make ssh work, which it is not at the 
moment. ISTR if I restart it from its own console, it might work. 
Depends on the phase of the moon because it might decide to use the 169 
addresses for everything. these two lines at the top of /e/n/i.d/eth0

auto eth0
iface eth0 inet static

is supposed to tell n-m and company to keep their hands off that 
interface, and plainly it is not. It is totally ignoreing the rest of 
that file, so while I may get a valid address, but not one fixed 
gateway|route.  Sitting here. playing with ip on this machine, I finally 
figured out how to get rid of the 169.254.xx.yy trash in the eth0 setup, 
and its possible I might be able to put a postup command or two to clean 
house and make it work, like I did with stretch on a rock64.

>  * removing stuff (especially if not 'purged', dpkg -l would tell)
>  * manual changes to files (deletions/permissions/etc.
>  (especially those unnecessary "fixes" you call "neutering")

I will do whatever it takes to make it "Just Work". But so much has been 
changed with buster that I don't really know where to start. Jessie ran 
good, but realtime wasn't as real as needed, stretch runs a much better 
realtime, but each "upgrade" has been harder and harder to make the 
networking Just Work.

> For the record/archives: other users are not seeing your problems.

Am I the only holdout on the whole English speaking planet still useing 
static networking configs?  I really, seriously, doubt that. But I will 
state that every release newer than wheezy has made it progressively 
more difficult to make a staticly defined network work. Way too many 
chefs stirring in the same pot is how I see it.

> Buster is - at least for me - the best Debian release yet.

It may well be, but its worthless to me running in a Faraday cage because 
I cannot control the networking. And its worthless to me until I can get 
a realtime kernel built into the u-sd. I  build this stuff to do a job, 
and if it can't do the job, I've got 1500 lbs of cast iron I can't 
control to make it move.

> The problems you are seeing are, at least partially, of your own
> doing, most likely du

Re: Assorted arm-buster problems - network configuration

[Felix Miata]

Gene Heskett composed on 2019-07-04 04:42 (UTC-0400):

> every release newer than wheezy has made it progressively 
> more difficult to make a staticly defined network work.
Given the myriad of successes in your 8+ decades, I'm baffled that you are
continually flummoxed by fixed IP networking. Maybe it's because I only use X86
hardware, but DHCP is the only thing that has given me any trouble lately, and
that's only because of a NIC driver that is apparently quite broken. Fixed IP 
here
just continues to work as before. Could it be because I've been planting
net.ifnames=0 on every cmdline since before Wheezy, along with
70-persistent-net.rules (which seems unnecessary any more), and a shared hosts 
file?
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Thursday 04 July 2019 05:25:05 Felix Miata wrote:

> Gene Heskett composed on 2019-07-04 04:42 (UTC-0400):
> > every release newer than wheezy has made it progressively
> > more difficult to make a staticly defined network work.
>
> Given the myriad of successes in your 8+ decades, I'm baffled that you
> are continually flummoxed by fixed IP networking. Maybe it's because I
> only use X86 hardware, but DHCP is the only thing that has given me
> any trouble lately, and that's only because of a NIC driver that is
> apparently quite broken. Fixed IP here just continues to work as
> before. Could it be because I've been planting net.ifnames=0 on every
> cmdline since before Wheezy, along with 70-persistent-net.rules (which
> seems unnecessary any more), and a shared hosts file?

The shared hosts file has been a feature here since the second came 
online it round '00 to run an harbor freight milling machine, 

And I'm not sure in a pi's config, where to put the net.ifnames=0.

/boot/cmdline.txt maybe?  You have grub to splice all that together, but 
the pi's are u-boot, as most of the arm stuff is. But with the pi4 
coming online, with 4Gigs a dram, I'd sure like to see grub-2 ported to 
arms.  That would greatly simplicate kernel swapping.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[mick crane]

On 2019-07-04 09:42, Gene Heskett wrote:


Sorry, I don't see it that way, I see a concentrated effort to make me
use dhcpd, instead of static, every machine in the system knows the
address of ALL the other machines on my local 192.168.xx.nn/24 network.

Using dhcp means I'd have to setup a 2nd this side of my router. I will
try to make ssh work later today, and I will reanswer this message if I
can do that.


I like having ipfire or pfsense  on a separate box doing DHCP server.
you can make other PCs static by making their lease fixed.
and then everything is in one place.
well that's how I understand it anyway.

mick.

--
Key ID4BFEBB31

Re: How to have password shown?

[Dave Sherohman]

On Wed, Jul 03, 2019 at 03:00:24PM +0100, Brian wrote:
> Most people mistype at some time; have you considered why your father
> might be doing it? Logins with convoluted or complex passwords do not
> help, so consider 12345678 or the date of his birthday. I'm tempted to
> say that either would reduce mishaps.

This would basically be my suggestion as well, since you want to get him
in the habit of using a password rather than disabling passwords
entirely.  Just make it a password based on a simple, compact keyboard
pattern, such as 1234 or (assuming a qwerty keyboard) qweasdzxc, so that
he's not moving from one part of the keyboard to another and potentially
making mistakes while doing so.

-- 
Dave Sherohman

Re: How to have password shown?

[Curt]

On 2019-07-04, deloptes  wrote:
> Renato Gallo wrote:
>
>> Fingerprints are a good option
>> 
>> Renato Gallo
>> 
>
> No, they are not and it was explained previously why
>

Sure they are (depending on the use case/implementation). These things are
completely comparative and situational and your statement completely
unqualified and universal. The OP desired having the password revealed in
plaintext on the terminal/console.  Another person thought an insecure password
like 12345 might do the trick.  Still another suggested a passwordless login
for the OP's venerable paternal element. I was asking myself how the
blind/visually impaired handle the problem.  And the cognitively impaired. And
those suffering from motor impairments which might render any "fine" use of the
keyboard a painstaking affair. 

Reco's objections to fingerprints as an authentication method, to which you
might be alluding above, called to mind what I'd previously heard from Schneier
concerning biometrics years ago. Let's see what he said in 2009 (update to an
essay written in 1998).

https://www.schneier.com/blog/archives/2009/01/biometrics.html

 And a stolen biometric can fool some systems. It can be as easy as cutting out
 a signature, pasting it onto a contract, and then faxing the page to someone.
 The person on the other end doesn't know that the signature isn't valid because
 he didn't see it fixed onto the page. Remote logins by fingerprint fail in the
 same way. If there's no way to verify the print came from an actual reader, not
 from a stored computer file, the system is much less secure.

 A more secure system is to use a fingerprint to unlock your mobile phone or
 computer. Because there is a trusted path from the fingerprint reader to the
 stored fingerprint the system uses to compare, an attacker can't inject a
 previously stored print as easily as he can cut and paste a signature. A photo
 on an ID card works the same way: the verifier can compare the face in front of
 him with the face on the card.

Re: Choice of VMs under i386 Stretch?

[Richard Owlett]

On 07/02/2019 04:05 PM, Linux-Fan wrote:

...

For my local purposes, I have created my own metapackage (not in Debian...)
-- this is why I suggested a list of packages: I expect that installing all
of the packages yields the same result (except for automatically vs.
manually installed packages...) as if a metapackage were used. In case 
it is

of use to you, I can send you an e-mail with a copy of my metapackage
(it is about 4 KiB as per `du -sh`, but it does not do well for world-wide
publication because it is not Debian Policy compliant etc. thus not
uploaded/attached anywhere yet).



Please send me a copy.
I've a ~10 year old Lenovo T510 whose hardware should be new enough.

BTW my oldest machine is a Kaypro 10 ;/

Re: [OT] send all email from certain From: addresses into a spam

[Mark Fletcher]

On Wed, Jul 03, 2019 at 06:44:42PM +0300, Reco wrote:
>   Hi.
> 
> On Wed, Jul 03, 2019 at 11:39:22AM -0400, Greg Wooledge wrote:
> > 
> > procmail might have worked, but it's more of a pain to learn procmail
> > than it is to write my own filter.  I also get more flexibility this way.
> > 
> > The write-up of my approach is at
> > .
> 
> Maildrop does exactly this. For instance, 
> 
> ^From:.*User Name/
> 
> Transforms to this snippet of .mailfilter:
> 
> if ( /^From:.*User Name/:h )
>   to /dev/null
> 
> Works with exim, postfix and probably qmail OOB.
> 

Could this also be expanded to delete not only mail from a particular 
user, but also any mail *replying to* that mail as well? In other words, 
get rid of not only the mail that starts a thread, but the entire 
thread?

Or would that be a task better done in mutt?

Mark

Old computers (Re: Choice of VMs under i386 Stretch?)

[rhkramer]

On Thursday, July 04, 2019 09:50:36 AM Richard Owlett wrote:
> BTW my oldest machine is a Kaypro 10 ;/

Just for kicks, I'll mention that my oldest machine is a Digital Group Z-80, 
circa 1976, assembed from a kit, and with 2K on board RAM plus 2 auxillary 
memory boards with 8K each (iirc) for a total of 18K RAM.  Long term storage 
was via a cassete recorder / player with a speed control to adjust playback 
speed for best result.

I programmed some floating point routines in machine language, and had thoughts 
of writing things like a word processor.

I thought (seriously) about buying (or, more accurately, wished that I could 
afford to buy) a used teletype machine (for about $1500) in order to have a 
means of printing.

It (the machine) was working when I retired it, but I should make some fixes if 
I ever un-retired it (I took out the 115 volt AC cooling fan to use as an air 
mover between two rooms of my house),

Aside: the Digital Group machines were pretty neat in that the CPU was on a 
daugherboard, and they made CPU boards with the Z-80, the 6502, the 6800 
(iirc) (and maybe just the plain 8080) -- you could "convert" to any of those 
other CPUs by just buying, assembling, and changing out the CPU daughterboard.

BTW, that wasn't my first computer -- when I was significantly younger (i.e., 
10 
to 15 years before 1976), I acquired two other things (both long gone, I 
think) that were called computers:

   * One was sort of a toy analog computer (one where you input numbers by 
doing things like using potentiometers to set a voltage to represent a 
number), and then read results on a meter (I'm somewhat oversimplifying that 
as I don't really remember much about that.

   * The other was something that I believed had computer in the name, but was 
used to control model trains -- the intent was that you could speak into a 
(built-in) microphone and it was supposed to recognize spoken commands (things 
like "stop" or "go" -- and maybe I'm misremembering the commands, maybe the 
logic was based on detecting and counting syllables in the commands).  It 
never worked very well, but I might actually still have it buried in a box of 
old model train stuff. ;-)

By the way, despite the years mentioned in this email, I am only 29 (or, at 
least, I try to convince women of that) (the same age (or was it 39) that Jack 
Benny always claimed to be, even when he appeared to be much older,

(I woke up with a headache today, and am not "in shape" to do any serious 
work, so I'd doing things like this).

Happy 4th of July (Independence Day) to all of us (in the USA or not).  I hope 
the soldiers that might be marching in Trump's July 4th celebration are not 
"goose stepping".

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Thursday 04 July 2019 06:15:56 mick crane wrote:

> On 2019-07-04 09:42, Gene Heskett wrote:
> 
>
> > Sorry, I don't see it that way, I see a concentrated effort to make
> > me use dhcpd, instead of static, every machine in the system knows
> > the address of ALL the other machines on my local 192.168.xx.nn/24
> > network.
> >
> > Using dhcp means I'd have to setup a 2nd this side of my router. I
> > will try to make ssh work later today, and I will reanswer this
> > message if I can do that.
>
> I like having ipfire or pfsense  on a separate box doing DHCP server.
> you can make other PCs static by making their lease fixed.
> and then everything is in one place.
> well that's how I understand it anyway.
>
> mick.
I do have a dhcpd configured in dd-wrt. but its set to only respond to 
the MAC's of my sons smartfones when they come by and I enable the 
radio. That way their phones can use my bandwidth. If I could control 
which way those are bridged so the local AMC's see locals at fixed 
addresses, while the wifi stuff is bridged only to the internet, that 
would be ideal.  But I don't believe I can control the bridge direction 
based on the MAC of the client. So I'd have to setup a separate server, 
ideally in the distribution switch, that assigned a dhcp address 
according to the incoming MAC. In my lashup, I have a managed switch, 
but its running the default setup which does not enable a dhcpd, if it 
even has one.  And I can't think of a way to ping picnc, and reliably 
hit 192.168.xx.yy, the address of picnc. Using host files for local dns 
is so much simpler.

Now I've been standing in front of its monitor for about an hour, a neck 
breaker because its well above my eye level. With NIX-Crafts ip tutorial 
in hand, trying to get rid of the default route in the 169.254 range, 
and while it may not return a syntax error thats usually gibberish, 
showing something thats totally disconnected from what I told it to do, 
there is no way in hell to delete the 169.junk from an ip r report. And 
this is with a sudo in front of whatever.

If I try to ping yahoo.com it properly asks my isp's dns for an address 
for yahoo, gets it and displays it but then pings it from the 169 
address, which is of coarse sent to /dev/null in the router if it even 
gets that far as it must traverse the switch to get that far.

I've tried to dpkg --purge the dhcp* stuff I can see, but dpkg says its 
not installed so it must be in the kernel, a non-realtime 4.19.50 for 
armhf.  So unless someone can tell me how to nuke, or at least change 
its preference for the 169 crap as defaults, this rpi-3b will never be 
able to run on buster. I must be able to make it use the 
192.168.nn.hostname-address for everything. But something is overriding 
me.

What is it?  And can I nuke or otherwise disable it?

The scripts in /etc/init.d for both avahi-daemon and dhcpd have been 
removed by rm.  Made absolutely zero difference to an ip a or ip r 
report. I can only conclude that systemd thinks its smarter than me. I 
have armbian installed on a rock64, and there I had a heck of a time 
with the stretch version of this same routing problem, but duplicating 
that setup on buster, and getting working results cannot be done with 
the tools at hand.

Someone gave me a link to a systemd tut, a pdf I was gonna print but its 
almost 40 pages thats both 5 years out of date, and by page 2 has 
dissolved into undecypherable jargon that needs translated to working 
English. Is there an uptodate one for dummies that actually covers 
buster?

Thanks everybody.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Choice of VMs under i386 Stretch?

[Nate Bargmann]

* On 2019 04 Jul 08:51 -0500, Richard Owlett wrote:
> I've a ~10 year old Lenovo T510 whose hardware should be new enough.

I've a T410 running Buster amd64 and have simply installed the
VirtualBox binaries from the Sid repository (manually downloaded and
installed).  I also have QEMU installed for testing some ARM stuff.
Works like a charm.

> BTW my oldest machine is a Kaypro 10 ;/

I'm not that old, my original was a Color Computer 2 a bit over 35 years
ago.  The oldest machine I have now is an IBM T23.  Anything older was
given away or scrapped.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us  GPG key: D55A8819  GitHub: N0NB


signature.asc
Description: PGP signature

Re: [OT] send all email from certain From: addresses into a spam

[Reco]

Hi.

On Thu, Jul 04, 2019 at 11:29:20PM +0900, Mark Fletcher wrote:
> On Wed, Jul 03, 2019 at 06:44:42PM +0300, Reco wrote:
> > On Wed, Jul 03, 2019 at 11:39:22AM -0400, Greg Wooledge wrote:
> > > 
> > > procmail might have worked, but it's more of a pain to learn procmail
> > > than it is to write my own filter.  I also get more flexibility this way.
> > > 
> > > The write-up of my approach is at
> > > .
> > 
> > Maildrop does exactly this. For instance, 
> > 
> > ^From:.*User Name/
> > 
> > Transforms to this snippet of .mailfilter:
> > 
> > if ( /^From:.*User Name/:h )
> > to /dev/null
> > 
> > Works with exim, postfix and probably qmail OOB.
> > 
> 
> Could this also be expanded to delete not only mail from a particular 
> user, but also any mail *replying to* that mail as well? In other words, 
> get rid of not only the mail that starts a thread, but the entire 
> thread?

I don't see a universal way of doing this, but I'd try a match against a
References header.
For instance, your e-mail has this References header:

References: 
<20190703153922.gz2...@eeg.ccf.org>


So, assuming that you wish to block threads that are started by me,
participated by me, etc, you'll need (:h should correctly process a
multiline header):

if ( /^From:.*recovery...@enotuniq.net/:h )
to /dev/null
if ( /^References:.*enotuniq.net/:h )
to /dev/null

But that assumes that everybody in the thread are using a sane e-mail
client. And relies on Message-ID that can include literally anything
(but it does include a domain most of the time).


> Or would that be a task better done in mutt?

That's an option too. The obvious disadvantage is that you see e-mails
and (sub)threads that you want to delete.

Reco

Re: Choice of VMs under i386 Stretch?

[Stefan Monnier]

> If it had been done 10 years ago it wouldn't need to be done now. :)

[ The initial install was in 2003, FWIW.  ]
I do use 64bit Debian on another machine, but to tell you the truth,
I don't notice any difference at all (other than bigger hex numbers in
GDB which take up more screen real estate and are harder to
remember/decipher ;-), so there's a serious lack of motivation.

> VMs running on a core 2 definitely have unfixable security issues and aren't
> great performers.  That certainly limits the use cases.

AFAIK all CPUs since also have unfixable security issues (spectre).
So I'm not sure it makes much difference.
In any case, my point is that often it's best to use what you have
rather than what is "best".

> Since faster and more efficient hardware can literally be found for free

Regarding faster: my laptop is a Thinkpad T61 with a hand-upgraded Core
2 CPU, and the reason I'm using that is that it's the best 4/3 laptop
I could find.
All the more recent models use short screens and hence don't qualify.

It does deserve to be upgraded, and I'm willing to spend a fair bit of
money for that, but so far noone has decided to re-enter the 4/3
marketplace AFAIK (the "thinkpad" T70 has been the only exception I know
of, but it was very short run).

As for efficiency, AFAIK the production of a laptop takes more
energy than all the electricity it uses in its lifetime, so using my old
laptop is arguably more efficient.

> these days, running on something that old has a strong component of personal
> choice.

Just like choosing something more recent is a personal choice, yes.
With global ecological implications.

> Which is fine, but not a strong argument. Put a different way, it's
> fine if that's what you want to do, but terrible advice for others.

I didn't advise it.  I only pointed out that running a VM in a 32bit
system is not silly at all.


Stefan

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Thursday 04 July 2019 03:16:31 andreimpope...@gmail.com wrote:

> On Mi, 03 iul 19, 21:03:19, Gene Heskett wrote:
> > On Wednesday 03 July 2019 16:12:31 Reco wrote:
> >
> > And Gene moved. Question unanswered yet.
> >
> > >   Hi.
> > >
> > > On Wed, Jul 03, 2019 at 02:57:35PM -0400, Gene Heskett wrote:
> > > > Regardless of what I do, I cannot get rid of the avahi junk in
> > > > an ip a report, so my local 192.168.xx.nn/24 net is the only
> > > > thing that works. pinging a net name like yahoo.com gets me a
> > > > successful address. But no response from yahoo because its
> > > > sending the ping from an avahi based address, which since thats
> > > > outside of my /24 netmask, doesn't get thru the router.
> > > >
> > > > So, how do I get rid of the avahi stuff?
> > > >
> > > > I've a nominally 10 machine 192.168.nn.xx that is 100% static
> > > > based on host files so I want avahi absolutely and totally
> > > > neutered, emasculated, gone Forever plus 100 years at least.
> > > >
> > > > How can I do that?
>
> It's not necessarily avahi doing that. A DHCP client might also
> configure a 169.254.*.* address for you if it doesn't receive a reply.
>
> In order to have the slightest chance of helping you it is necessary
> for you to provide the information as per below.
>
> Files should preferably be attached, to avoid issues with copy-paste.
>
> Please do not edit anything except to obscure private information
> (e.g. passwords or a public IP you don't want to post).
>
I have restarted ssh, so now thats working and I'm logged in.  I will use 
copy/paste but I'll do word wrapping by hand.
>
> 1. content of /etc/network/interfaces and all files under
> /etc/network/interfaces.d/
pi@picnc:~ $ cat /etc/network/interfaces.d/*
auto eth0

iface eth0 inet static
address 192.168.71.12/24
gateway 192.168.71.1
post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6

Which the last line disables ipv6  on this machines mostly stretch install.

> (I seem to recall you are using ifupdown)
What ever works. More often than not, a reboot.  But if I reboot it from
here, I'll have to go to that machine and restart ssh, so lets start 
with fixing that.
>
> 2. Full output of:
> apt list --installed 'network-manager*' # might be empty
pi@picnc:~ $ sudo apt list --installed 'network-manager*'
Listing... Done

> apt list --installed 'avahi*' # might be empty
pi@picnc:~ $ sudo apt list --installed 'avahi*'
Listing... Done
avahi-daemon/testing,now 0.7-4+b1 armhf [installed]

> systemctl status systemd-networkd
pi@picnc:~ $ sudo systemctl status systemd-networkd
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; 
vendor preset: enabled)
   Active: inactive (dead)
 Docs: man:systemd-networkd.service(8)


> ip a # short for 'ip address'
pi@picnc:~ $ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff
inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0
   valid_lft forever preferred_lft forever
inet 169.254.163.253/16 brd 169.254.255.255 scope global noprefixroute eth0
   valid_lft forever preferred_lft forever
inet6 fe80::1445:918c:cf73:6a79/64 scope link
   valid_lft forever preferred_lft forever
3: wlan0:  mtu 1500 qdisc pfifo_fast state 
DOWN group default qlen 1000
link/ether b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff

> ip r # short for 'ip route'
pi@picnc:~ $ ip r
default dev eth0 scope link src 169.254.163.253 metric 202
169.254.0.0/16 dev eth0 scope link src 169.254.163.253 metric 202
192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12

>
> 3. Information on anything (and I do mean anything) else you might
> have done to your network configuration after installing buster,
> including but not limited to:
>  * installing stuff, especially if from source
>  * removing stuff (especially if not 'purged', dpkg -l would tell)
>  * manual changes to files (deletions/permissions/etc.
>  (especially those unnecessary "fixes" you call "neutering")
>
> For the record/archives: other users are not seeing your problems.
>
> Buster is - at least for me - the best Debian release yet.
>
> The problems you are seeing are, at least partially, of your own
> doing, most likely due to wrong configuration and an approach of using
> the equivalent of a shotgun to kill a fly and then complaining your
> walls are full of holes.

Since we are dealing in hyperbole, I do own a shotgun, but for fly's I'd 
use a 6.5 creedmore, the hole is about the size of the fly and will 
usually have blood-stained edges.

I actually bet and won a 6 pack of beer doing that at 100 meters with 
a

Re: Assorted arm-buster problems - network configuration

[Reco]

Hi.

On Thu, Jul 04, 2019 at 11:40:30AM -0400, Gene Heskett wrote:
> On Thursday 04 July 2019 03:16:31 andreimpope...@gmail.com wrote:
> 
> > On Mi, 03 iul 19, 21:03:19, Gene Heskett wrote:
> > > On Wednesday 03 July 2019 16:12:31 Reco wrote:
> > >
> > > And Gene moved. Question unanswered yet.

Some of us are still working every day to earn that paycheck at the end
of the month, you know ;)


> > > > On Wed, Jul 03, 2019 at 02:57:35PM -0400, Gene Heskett wrote:
> > > > > Regardless of what I do, I cannot get rid of the avahi junk in
> > > > > an ip a report, so my local 192.168.xx.nn/24 net is the only
> > > > > thing that works. pinging a net name like yahoo.com gets me a
> > > > > successful address. But no response from yahoo because its
> > > > > sending the ping from an avahi based address, which since thats
> > > > > outside of my /24 netmask, doesn't get thru the router.
> > > > >
> > > > > So, how do I get rid of the avahi stuff?
> > > > >
> > > > > I've a nominally 10 machine 192.168.nn.xx that is 100% static
> > > > > based on host files so I want avahi absolutely and totally
> > > > > neutered, emasculated, gone Forever plus 100 years at least.
...
> pi@picnc:~ $ cat /etc/network/interfaces.d/*
> auto eth0
> 
> iface eth0 inet static
> address 192.168.71.12/24
> gateway 192.168.71.1
> post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
> 

> > ip r # short for 'ip route'
> pi@picnc:~ $ ip r
> default dev eth0 scope link src 169.254.163.253 metric 202
> 169.254.0.0/16 dev eth0 scope link src 169.254.163.253 metric 202
> 192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12

These caught my attention.
What about this trick (metric is 1024 unless you define it, and default
route with lower metric wins):

auto eth0
iface eth0 inet static
address 192.168.71.12/24
gateway 192.168.71.1
metric 64
post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6

There's also another dirty trick:

mkdir /etc/systemd/system/avahi-daemon.service.d
cat > /etc/systemd/system/avahi-daemon.service.d/override.conf <

nXML "No completions available"

[Bob Bernstein]

I am in my new-ish:
Linux debian.localdomain 4.9.0-9-amd64 #1 SMP Debian 
4.9.168-1+deb9u3 (2019-06-16) x86_64 GNU/Linux

I seek to edit a DocBook XML file in emacs23. The file 
begins:




Does that seem okay? However, trying out autocompletion 
with Esc-TAB gives me the error message noted in my 
Subject: "no completions available."

I created the small file many years ago and am able to use 
xsltproc and an xsl style sheet to produce a suitable pdf. 
Now I want to edit it. I remember virtually nothing of how 
to actually _use_ nXML in emacs, that is, keystrokes. 
(How, for example can I bring up a list of valid tags for 
insertion at a given point in the file?)

Thank you

-- 
Never ascribe to malice what can be explained by stupidity.

kde kmail to much email Unable to fetch item from backend

[Thomas]

Hello,
I have an Gmail Mail account and lots of email.
Iam not able to open this folder succesfull anymore.
After some time I get this message.

Unable to fetch item from backend (collection -1) Unable to retrieve item from 
resource.

Whats the problem and how solve it.

Thanks Thomas

Re: Choice of VMs under i386 Stretch?

[Michael Stone]

On Thu, Jul 04, 2019 at 11:26:39AM -0400, Stefan Monnier wrote:

If it had been done 10 years ago it wouldn't need to be done now. :)


(General observation: it's really quite annoying that you remove all 
attribution when you quote previous emails in your replies.)



VMs running on a core 2 definitely have unfixable security issues and aren't
great performers.  That certainly limits the use cases.


AFAIK all CPUs since also have unfixable security issues (spectre).
So I'm not sure it makes much difference.


That's not true, but I really don't want to start another thread against 
CPU FUD so I'll leave it at that.



As for efficiency, AFAIK the production of a laptop takes more
energy than all the electricity it uses in its lifetime, so using my old
laptop is arguably more efficient.


That's a bogus argument when applied to secondhand hardware. When 
comparing two pieces of used hardware and effectively deciding which one 
gets thrown away, there's no particular virtue in choosing the older 
(probably less power efficient) one.



I only pointed out that running a VM in a 32bit system is not silly at all.


Humans do a lot of things that are objectively silly for their own 
amusement.

Re: Assorted arm-buster problems - network configuration

[mick crane]

On 2019-07-04 15:40, Gene Heskett wrote:

On Thursday 04 July 2019 06:15:56 mick crane wrote:


On 2019-07-04 09:42, Gene Heskett wrote:


> Sorry, I don't see it that way, I see a concentrated effort to make
> me use dhcpd, instead of static, every machine in the system knows
> the address of ALL the other machines on my local 192.168.xx.nn/24
> network.
>
> Using dhcp means I'd have to setup a 2nd this side of my router. I
> will try to make ssh work later today, and I will reanswer this
> message if I can do that.

I like having ipfire or pfsense  on a separate box doing DHCP server.
you can make other PCs static by making their lease fixed.
and then everything is in one place.
well that's how I understand it anyway.

mick.

I do have a dhcpd configured in dd-wrt. but its set to only respond to
the MAC's of my sons smartfones when they come by and I enable the
radio. That way their phones can use my bandwidth. If I could control
which way those are bridged so the local AMC's see locals at fixed
addresses, while the wifi stuff is bridged only to the internet, that
would be ideal.


pfsense, ipfire have got handy web GUI's for all that.
I have WAP plugged in that is blocked to the local network but allowed 
to the internet.


got to say I admire your tenacity.

cheers

mick

--
Key ID4BFEBB31

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Thursday 04 July 2019 12:18:13 Reco wrote:

>   Hi.
>
> On Thu, Jul 04, 2019 at 11:40:30AM -0400, Gene Heskett wrote:
> > On Thursday 04 July 2019 03:16:31 andreimpope...@gmail.com wrote:
> > > On Mi, 03 iul 19, 21:03:19, Gene Heskett wrote:
> > > > On Wednesday 03 July 2019 16:12:31 Reco wrote:
> > > >
> > > > And Gene moved. Question unanswered yet.
>
> Some of us are still working every day to earn that paycheck at the
> end of the month, you know ;)

Yeah, terrible state of affairs. :)  Social Security, the biggest ponzi 
scheme on the planet. If you or I done it. they'd jack up the jail, 
throw us under it and set it back down on us. And claim they've never 
heard of us. :( 

>
> > > > > On Wed, Jul 03, 2019 at 02:57:35PM -0400, Gene Heskett wrote:
> > > > > > Regardless of what I do, I cannot get rid of the avahi junk
> > > > > > in an ip a report, so my local 192.168.xx.nn/24 net is the
> > > > > > only thing that works. pinging a net name like yahoo.com
> > > > > > gets me a successful address. But no response from yahoo
> > > > > > because its sending the ping from an avahi based address,
> > > > > > which since thats outside of my /24 netmask, doesn't get
> > > > > > thru the router.
> > > > > >
> > > > > > So, how do I get rid of the avahi stuff?
> > > > > >
> > > > > > I've a nominally 10 machine 192.168.nn.xx that is 100%
> > > > > > static based on host files so I want avahi absolutely and
> > > > > > totally neutered, emasculated, gone Forever plus 100 years
> > > > > > at least.
>
> ...
>
> > pi@picnc:~ $ cat /etc/network/interfaces.d/*
> > auto eth0
> >
> > iface eth0 inet static
> > address 192.168.71.12/24
> > gateway 192.168.71.1
> > post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
> >
> > > ip r # short for 'ip route'
> >
> > pi@picnc:~ $ ip r
> > default dev eth0 scope link src 169.254.163.253 metric 202
> > 169.254.0.0/16 dev eth0 scope link src 169.254.163.253 metric 202
> > 192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12
>
> These caught my attention.
> What about this trick (metric is 1024 unless you define it, and
> default route with lower metric wins):
>
Those that are set are set to metric 202.  And the metric 24 had no 
effect, and error someplace it does not identify.

> auto eth0
>   iface eth0 inet static
>   address 192.168.71.12/24
>   gateway 192.168.71.1
>   metric 64
>   post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
But I'll leave it that way and reboot, which means I'll have to goto its 
own keyboard and restart ssh. Which then works...???  Why is that?

> There's also another dirty trick:
>
> mkdir /etc/systemd/system/avahi-daemon.service.d
> cat > /etc/systemd/system/avahi-daemon.service.d/override.conf < [Service]
> PrivateNetwork=yes
> EOF
> systemctl daemon-reload
> systemctl restart avahi-daemon

With it purged, waste of time by my reasoning, but I'll print this and go 
do it anyway.

> I'd also consider exterminating avahi with extreme prejudice, i.e.
> 'apt purge avahi-daemon'. Really simplifies things. Not installing
> this software in the first place works even better.
>
That also has been done just before a powerdown reboot. But now, even 
though service ssh status says it up and running, I can't login from 
here. And getting rid of avahi and libnsswch or whatever its called made 
no difference in the ip a or ip r reports. But hang on, I'm going to see 
why ssh isn't working at all now.

Thanks Reco


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Lee]

On 7/4/19, Gene Heskett  wrote:
> On Thursday 04 July 2019 03:16:31 andreimpope...@gmail.com wrote:
>
>> On Mi, 03 iul 19, 21:03:19, Gene Heskett wrote:
>> > On Wednesday 03 July 2019 16:12:31 Reco wrote:
>> >
>> > And Gene moved. Question unanswered yet.
>> >
>> > >  Hi.
>> > >
>> > > On Wed, Jul 03, 2019 at 02:57:35PM -0400, Gene Heskett wrote:
>> > > > Regardless of what I do, I cannot get rid of the avahi junk in
>> > > > an ip a report, so my local 192.168.xx.nn/24 net is the only
>> > > > thing that works. pinging a net name like yahoo.com gets me a
>> > > > successful address. But no response from yahoo because its
>> > > > sending the ping from an avahi based address, which since thats
>> > > > outside of my /24 netmask, doesn't get thru the router.
>> > > >
>> > > > So, how do I get rid of the avahi stuff?
>> > > >
>> > > > I've a nominally 10 machine 192.168.nn.xx that is 100% static
>> > > > based on host files so I want avahi absolutely and totally
>> > > > neutered, emasculated, gone Forever plus 100 years at least.
>> > > >
>> > > > How can I do that?
>>
>> It's not necessarily avahi doing that. A DHCP client might also
>> configure a 169.254.*.* address for you if it doesn't receive a reply.
>>
>> In order to have the slightest chance of helping you it is necessary
>> for you to provide the information as per below.
>>
>> Files should preferably be attached, to avoid issues with copy-paste.
>>
>> Please do not edit anything except to obscure private information
>> (e.g. passwords or a public IP you don't want to post).
>>
> I have restarted ssh, so now thats working and I'm logged in.  I will use
> copy/paste but I'll do word wrapping by hand.
>>
>> 1. content of /etc/network/interfaces and all files under
>> /etc/network/interfaces.d/
> pi@picnc:~ $ cat /etc/network/interfaces.d/*
> auto eth0
>
> iface eth0 inet static
> address 192.168.71.12/24
> gateway 192.168.71.1
> post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
>
> Which the last line disables ipv6  on this machines mostly stretch install.
>
>> (I seem to recall you are using ifupdown)
> What ever works. More often than not, a reboot.  But if I reboot it from
> here, I'll have to go to that machine and restart ssh, so lets start
> with fixing that.
>>
>> 2. Full output of:
>> apt list --installed 'network-manager*' # might be empty
> pi@picnc:~ $ sudo apt list --installed 'network-manager*'
> Listing... Done
>
>> apt list --installed 'avahi*' # might be empty
> pi@picnc:~ $ sudo apt list --installed 'avahi*'
> Listing... Done
> avahi-daemon/testing,now 0.7-4+b1 armhf [installed]
>
>> systemctl status systemd-networkd
> pi@picnc:~ $ sudo systemctl status systemd-networkd
> ● systemd-networkd.service - Network Service
>Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled;
> vendor preset: enabled)
>Active: inactive (dead)
>  Docs: man:systemd-networkd.service(8)
>
>
>> ip a # short for 'ip address'
> pi@picnc:~ $ ip a
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group
> default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
>valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc pfifo_fast state
> UP group default qlen 1000
> link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff
> inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0
>valid_lft forever preferred_lft forever
> inet 169.254.163.253/16 brd 169.254.255.255 scope global noprefixroute
> eth0
>valid_lft forever preferred_lft forever
> inet6 fe80::1445:918c:cf73:6a79/64 scope link
>valid_lft forever preferred_lft forever
> 3: wlan0:  mtu 1500 qdisc pfifo_fast
> state DOWN group default qlen 1000
> link/ether b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff

I'm guessing that
1. your machine is set up to request an ip address via dhcp
2. the dhcp client software isn't smart enough to realize you've
configured a static address on the interface and tries to get an
address via dhcp anyway, fails, and assigns a 169.254.x.x address to
the interface

Best bet would be to turn off dhcp on that interface.  I don't
remember if I couldn't figure out how to disable dhcp or if it was
just that I _really_ don't want anything of mine doing mDNS; in any
case, I nuked avahi:

$ apt list --installed 'avahi*'
Listing... Done

Regards,
Lee

Re: Choice of VMs under i386 Stretch?

[Curt]

On 2019-07-04, Michael Stone  wrote:
> On Thu, Jul 04, 2019 at 11:26:39AM -0400, Stefan Monnier wrote:
>>> If it had been done 10 years ago it wouldn't need to be done now. :)
>
> (General observation: it's really quite annoying that you remove all 
> attribution when you quote previous emails in your replies.)
>

It really is very annoying, primarily because it's intentional, and so
intentionally annoying, which is really, really annoying.

-- 
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." in Nature. 

Re: Assorted arm-buster problems - network configuration

[Brian]

On Thu 04 Jul 2019 at 19:18:13 +0300, Reco wrote:

[...]

> I'd also consider exterminating avahi with extreme prejudice, i.e. 'apt
> purge avahi-daemon'. Really simplifies things. Not installing this
> software in the first place works even better.

Gene Heskett can follow this advice if he wishes. It is to be hoped
that every other user ignores it.

-- 
Brian.

Re: Assorted arm-buster problems - network configuration

[Tixy]

On Thu, 2019-07-04 at 20:01 +0100, Brian wrote:
> On Thu 04 Jul 2019 at 19:18:13 +0300, Reco wrote:
> 
> [...]
> 
> > I'd also consider exterminating avahi with extreme prejudice, i.e.
> > 'apt
> > purge avahi-daemon'. Really simplifies things. Not installing this
> > software in the first place works even better.
> 
> Gene Heskett can follow this advice if he wishes. It is to be hoped
> that every other user ignores it.

Why? It's advice I decided for myself 10 or more years ago after seeing
constant reports of zeroconf bugs in various OSes and kit, and
realising that sort of thing was also running on my Linux machines. The
whole idea of automagically setting up networks just sounds like a
problem and security hole waiting to happen. So I decided to nuke it
from orbit, it was the only safe thing to do.

-- 
Tixy

Re: Assorted arm-buster problems - network configuration

[tomas]

On Thu, Jul 04, 2019 at 08:56:45PM +0100, Tixy wrote:
> On Thu, 2019-07-04 at 20:01 +0100, Brian wrote:
> > On Thu 04 Jul 2019 at 19:18:13 +0300, Reco wrote:
> > 
> > [...]
> > 
> > > I'd also consider exterminating avahi with extreme prejudice, i.e.
> > > 'apt
> > > purge avahi-daemon'. Really simplifies things. Not installing this
> > > software in the first place works even better.
> > 
> > Gene Heskett can follow this advice if he wishes. It is to be hoped
> > that every other user ignores it.
> 
> Why? It's advice I decided for myself 10 or more years ago after seeing
> constant reports of zeroconf bugs in various OSes and kit, and
> realising that sort of thing was also running on my Linux machines. The
> whole idea of automagically setting up networks just sounds like a
> problem and security hole waiting to happen. So I decided to nuke it
> from orbit, it was the only safe thing to do.

As always, all generalizations suck. Some do avahi, others don't (full
disclosure: I am in the "don't" camp, as many may have guessed :-)

Still, I dislike such statements as "exterminate". But YMMV.

Cheers
-- t


signature.asc
Description: Digital signature

Re: Assorted arm-buster problems - network configuration

[Brian]

On Thu 04 Jul 2019 at 22:05:09 +0200, to...@tuxteam.de wrote:

> On Thu, Jul 04, 2019 at 08:56:45PM +0100, Tixy wrote:
> > On Thu, 2019-07-04 at 20:01 +0100, Brian wrote:
> > > On Thu 04 Jul 2019 at 19:18:13 +0300, Reco wrote:
> > > 
> > > [...]
> > > 
> > > > I'd also consider exterminating avahi with extreme prejudice, i.e.
> > > > 'apt
> > > > purge avahi-daemon'. Really simplifies things. Not installing this
> > > > software in the first place works even better.
> > > 
> > > Gene Heskett can follow this advice if he wishes. It is to be hoped
> > > that every other user ignores it.
> > 
> > Why? It's advice I decided for myself 10 or more years ago after seeing
> > constant reports of zeroconf bugs in various OSes and kit, and
> > realising that sort of thing was also running on my Linux machines. The
> > whole idea of automagically setting up networks just sounds like a
> > problem and security hole waiting to happen. So I decided to nuke it
> > from orbit, it was the only safe thing to do.
> 
> As always, all generalizations suck. Some do avahi, others don't (full
> disclosure: I am in the "don't" camp, as many may have guessed :-)

If nobody objects I would like to reword that statement. Many, many
users will have avahi-daemon on their systems; a few won't. The idea
that

  > Not installing this software in the first place works even better.

requires clarification.

-- 
Brian.

Re: Assorted arm-buster problems - network configuration

[tomas]

On Thu, Jul 04, 2019 at 09:42:11PM +0100, Brian wrote:
> On Thu 04 Jul 2019 at 22:05:09 +0200, to...@tuxteam.de wrote:

[...]

> > As always, all generalizations suck. Some do avahi, others don't (full
> > disclosure: I am in the "don't" camp, as many may have guessed :-)
> 
> If nobody objects I would like to reword that statement. Many, many
> users will have avahi-daemon on their systems; a few won't. The idea
> that
> 
>   > Not installing this software in the first place works even better.
> 
> requires clarification.

Clever move :-)

Cheers
-- t


signature.asc
Description: Digital signature

Re: Assorted arm-buster problems - network configuration

[andreimpopescu]

On Jo, 04 iul 19, 11:40:30, Gene Heskett wrote:
> >
> > 1. content of /etc/network/interfaces and all files under
> > /etc/network/interfaces.d/
> pi@picnc:~ $ cat /etc/network/interfaces.d/*

Is below the literal output of the cat above?

Please post also /etc/network/interfaces.

> auto eth0
> 
> iface eth0 inet static
> address 192.168.71.12/24
> gateway 192.168.71.1
> post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
> 
> Which the last line disables ipv6  on this machines mostly stretch install.

It doesn't, but IPv6 is not your problem anyway.

> > (I seem to recall you are using ifupdown)
> What ever works. More often than not, a reboot.

'ifupdown' is the name of the package providing /etc/network/interfaces.

> But if I reboot it from
> here, I'll have to go to that machine and restart ssh, so lets start 
> with fixing that.
> >
> > 2. Full output of:
> > apt list --installed 'network-manager*' # might be empty
> pi@picnc:~ $ sudo apt list --installed 'network-manager*'
> Listing... Done
> 
> > apt list --installed 'avahi*' # might be empty
> pi@picnc:~ $ sudo apt list --installed 'avahi*'
> Listing... Done
> avahi-daemon/testing,now 0.7-4+b1 armhf [installed]

In my understanding 169.254.*.* addresses are configured by 
avahi-autoipd, not avahi-daemon, so this is also not your problem.

> > systemctl status systemd-networkd
> pi@picnc:~ $ sudo systemctl status systemd-networkd
> ● systemd-networkd.service - Network Service
>Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; 
> vendor preset: enabled)
>Active: inactive (dead)
>  Docs: man:systemd-networkd.service(8)
 
systemd-networkd is also not running, so you can stop blaming systemd.

> > ip a # short for 'ip address'
> pi@picnc:~ $ ip a
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
> default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
>valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> group default qlen 1000
> link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff
> inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0
>valid_lft forever preferred_lft forever
> inet 169.254.163.253/16 brd 169.254.255.255 scope global noprefixroute 
> eth0
>valid_lft forever preferred_lft forever

This is not a problem.

> inet6 fe80::1445:918c:cf73:6a79/64 scope link
>valid_lft forever preferred_lft forever
> 3: wlan0:  mtu 1500 qdisc pfifo_fast state 
> DOWN group default qlen 1000
> link/ether b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff
> 
> > ip r # short for 'ip route'
> pi@picnc:~ $ ip r
> default dev eth0 scope link src 169.254.163.253 metric 202

But this is...

In addition to the full /etc/network/interfaces please post also the 
output of

pgrep -a dhcp

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Thursday 04 July 2019 16:05:09 to...@tuxteam.de wrote:

> On Thu, Jul 04, 2019 at 08:56:45PM +0100, Tixy wrote:
> > On Thu, 2019-07-04 at 20:01 +0100, Brian wrote:
> > > On Thu 04 Jul 2019 at 19:18:13 +0300, Reco wrote:
> > >
> > > [...]
> > >
> > > > I'd also consider exterminating avahi with extreme prejudice,
> > > > i.e. 'apt
> > > > purge avahi-daemon'. Really simplifies things. Not installing
> > > > this software in the first place works even better.
> > >
> > > Gene Heskett can follow this advice if he wishes. It is to be
> > > hoped that every other user ignores it.
> >
> > Why? It's advice I decided for myself 10 or more years ago after
> > seeing constant reports of zeroconf bugs in various OSes and kit,
> > and realising that sort of thing was also running on my Linux
> > machines. The whole idea of automagically setting up networks just
> > sounds like a problem and security hole waiting to happen. So I
> > decided to nuke it from orbit, it was the only safe thing to do.
>
> As always, all generalizations suck. Some do avahi, others don't (full
> disclosure: I am in the "don't" camp, as many may have guessed :-)
>
> Still, I dislike such statements as "exterminate". But YMMV.
>
> Cheers
> -- t
In this case, it made zero difference. It. nsswtch, dhcpd and all its ilk 
have been purged, but the default routes remain stubbornly, even over 
powerdown reboots, at 169.254.0.0/16. I next will grep the whole system 
looking for it and any file containing it will get edited to replace it 
with MY 192.168.nn/24 domain. If that doesn't fix it, it gets nuked. 
Since It nothing but a 64GB u-sd card I can rewrite in 10 minutes, I 
officially don't care if I destroy its ability to boot. It also has a 
duff kernel, RealtimePi having been watched as it spent an hour building 
a 4.4.114 rt kernel, but then reused the 4.19.50 kernel in the original 
image's zip. So I wind up with an identicaly functioning 2019-06-20 
buster image for nominally 4 hours work by the pi 3b.

I do have a good stretch version but with an earlier rt kernel, which 
works very well except for the nominal 2 frames a second video speeds. 
latency-test reports 28 u-secs of jitter in the 1 kilohertz servo 
thread, compared to a jessie builds 70+ microseconds.

Buster however is supposed to have faster video, but w/o a network I 
can't install the test tools to measure it, this is the main pusher to 
make buster work.  And I can't measure the video speeds without a 
network.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: kde kmail to much email Unable to fetch item from backend

[Keith Christian]

I have no suggestions for your Kmail problem, you might try Thunderbird and
see if that does the job or else email the KDE team.

Keith

On Thu, Jul 4, 2019 at 10:56 AM Thomas  wrote:

> Hello,
> I have an Gmail Mail account and lots of email.
> Iam not able to open this folder succesfull anymore.
> After some time I get this message.
>
> Unable to fetch item from backend (collection -1) Unable to retrieve item
> from
> resource.
>
> Whats the problem and how solve it.
>
> Thanks Thomas
>
>

Re: [OT] send all email from certain From: addresses into a spam

[Celejar]

On Thu, 4 Jul 2019 18:17:36 +0300
Reco  wrote:

...

> For instance, your e-mail has this References header:
> 
> References: 
> <20190703153922.gz2...@eeg.ccf.org>
> 
> 
> So, assuming that you wish to block threads that are started by me,
> participated by me, etc, you'll need (:h should correctly process a
> multiline header):
> 
> if ( /^From:.*recovery...@enotuniq.net/:h )
>   to /dev/null
> if ( /^References:.*enotuniq.net/:h )
>   to /dev/null
> 
> But that assumes that everybody in the thread are using a sane e-mail
> client. And relies on Message-ID that can include literally anything
> (but it does include a domain most of the time).

Wait, but wouldn't that block any threads referring to any mail sent
from any address at the specified domain? This might work fine for a
small domain, but it's going to be bad for mail coming from Gmail
accounts ...

Celejar

Re: Debian Buster RC 2 wont start GUI on a Radeon HD 5750

[aprekates]

I reported an issue to the debian-installer
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931436

As i found, the firmware included installers are unofficial
but since they do exist why not correct them.

Also i'm curious why i dont remember having issue with
the same GPU in my previous debian 9 install .

Also i'd like to see some hardware statistics of the debian
users.

Alexandros.


On 1/7/19 7:30 μ.μ., aprekates wrote:

Is that sth that can be corrected , or is
happening due to legal issues ?

But in the installer there is the option to use
non-free packages. So shouldnt that be reported
as an issue?

Alexandros

On 1/7/19 1:41 μ.μ., basti wrote:

Hello,
you need:

firmware-amd-graphics *and*
firmware-linux-nonfree

I had a similar Problem last week.

Re: [OT] send all email from certain From: addresses into a spam

[Joel Roth]

On Wed, Jul 03, 2019, Greg Wooledge wrote:
> On Wed, Jul 03, 2019 at 06:30:32PM +0300, Reco wrote:
> > I'm merely curious why you have to write a new program for this.
> > I mean, there are maildrop and procmail for client-side and sieve for
> > the server-side already.
> 
> procmail might have worked, but it's more of a pain to learn procmail
> than it is to write my own filter.  I also get more flexibility this way.
> 
> The write-up of my approach is at
> .

Cool.

For those who are friendly with perl, Email::Filter or
Email::Filter::Rules provides a less cryptic alternative to
procmail. I use Email::Filter with Net::IMAP::Client so that
I run one filter process per mail check, rather than one
process per mail when triggering the filter from a .forward
file.

-- 

Joel Roth

"Welcome to the World Heat Bank, where we store your waste
energy and return it with interest"

Re: Kiddie - encyclopedia

[Bagas Sanjaya]

Paul Sutton:

Hi

Just found the 'kiddie' encyclopedia website as a link on a school
website.  There is an entry for Debian which as you can see some of
which has not been updated since version 6.0

https://kids.kiddle.co/Debian

I don't mind offering to help them update the page so my first question is

Are the community happy for me to do this via their web form

In which case can I have some help with this, so the table that ends
with squeeze (6) needs updating with the other information.l  I would
update this to include some info on Buster. The LTS cut off date for
Lenny also needs to be included.  oddly there is a screenshot from
Jessie at the top of that page.


Just thought I would ask

Regards

Paul

Well, after inspecting the site it looks like the content was scraped from 
Wikipedia, as stated below in the footer:
Kiddle encyclopedia articles are based on selected content and facts 
from Wikipedia , rewritten for children and 
students. 

Unlike Wikipedia, there is no visible "Edit Article" button which every one 
(including you) can edit, nor wiki login
and registration page. Also there is only online contact form to contact kiddle 
webmasters.

Regarding scraped content, Google says:
Purely scraped content, even from high-quality sources, may not 
provide any added value to your users without additional useful 
services or content provided by your site; it may also constitute 
copyright infringement in some cases.

In kiddle encyclopedia case, the webmasters scraped Wikipedia content and 
modified it so that it was written for
children.

Special:Log link also not found, so kiddle webmasters hid their scraping trace.

I CC'ed this message to debian-publicity to let them know about out-of-date 
information found on kiddle encyclopedia.

Cheers, Bagas

Re: armv7 vs buster sudo complains about hostname or something

[andreimpopescu]

On Jo, 04 iul 19, 03:30:55, Gene Heskett wrote:
> On Thursday 04 July 2019 02:47:50 Andrei POPESCU wrote:
> >
> > I seem to recall sudo cares about /etc/hosts.
> 
> But I have that address TAB hostname.domain.name TAB alias in the hosts 
> file. No errors there.

How about showing us (attaching) the complete file ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Assorted arm-buster problems - network configuration

[andreimpopescu]

On Jo, 04 iul 19, 04:42:40, Gene Heskett wrote:
> On Thursday 04 July 2019 03:16:31 andreimpope...@gmail.com wrote:
> >
> > 3. Information on anything (and I do mean anything) else you might
> > have done to your network configuration after installing buster,
> > including but not limited to:
> >  * installing stuff, especially if from source
> First, on a u-booting raspi you don't "install". You either download an 
> image and put it on a u-sd card with dd, or you generate your own image.
> 
> Which is what I have done by using a utility from guysoft called 
> RealtimePi, which takes the June 20th version of raspian buster lite 
> apart, and supposedly puts it back together with a realtime patched 
> version of a compatible kernel, which should have been a 4.19.50-rt-v7 
> kernel, but when put on a u-sd, and the u-sd booted, turns out to have 
> the unpatched kernel in it.  Why I watched it spend an hour building the 
> older 4.4.114-rt-v7 kernel and then it didn't use it is something I have 
> not found yet in the build.log. Which I can't get to ATM because ssh 
> isn't working either.

Just the fact that you are running Raspbian instead of pure Debian is 
already an important clue and possibly a major hindrance in helping you 
(we don't know what other customizations have been done to that).

I will bet you this though: that image has usable dpkg and apt. If I'm 
right, do you promise to put the "shotgun" away? :)

If I'm wrong I offer to dig up my Raspberry Pi and try to reproduce your 
problems.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: How to have password shown?

[Richard Hector]

On 4/07/19 3:34 AM, Reco wrote:
> You cannot change your fingerprint (legally, that is).

Say what? Are you saying there's a jurisdiction in which it's illegal
for me to sand off, cut, or otherwise mutillate my own fingerprint?

Richard



signature.asc
Description: OpenPGP digital signature

Re: [OT] send all email from certain From: addresses into a spam

[Reco]

Hi.

On Thu, Jul 04, 2019 at 06:30:12PM -0400, Celejar wrote:
> On Thu, 4 Jul 2019 18:17:36 +0300
> Reco  wrote:
> 
> ...
> 
> > For instance, your e-mail has this References header:
> > 
> > References: 
> > <20190703153922.gz2...@eeg.ccf.org>
> > 
> > 
> > So, assuming that you wish to block threads that are started by me,
> > participated by me, etc, you'll need (:h should correctly process a
> > multiline header):
> > 
> > if ( /^From:.*recovery...@enotuniq.net/:h )
> > to /dev/null
> > if ( /^References:.*enotuniq.net/:h )
> > to /dev/null
> > 
> > But that assumes that everybody in the thread are using a sane e-mail
> > client. And relies on Message-ID that can include literally anything
> > (but it does include a domain most of the time).
> 
> Wait, but wouldn't that block any threads referring to any mail sent
> from any address at the specified domain? This might work fine for a
> small domain, but it's going to be bad for mail coming from Gmail
> accounts ...

That's another disadvantage, I agree. But it's a feature at the same
time. For instance, outlook.com sents nothing but spam to this maillist,
so any e-mails from that domain can be safely 'blocked' this way.

Reco

Re: How to have password shown?

[Reco]

Hi.

On Fri, Jul 05, 2019 at 04:33:30PM +1200, Richard Hector wrote:
> On 4/07/19 3:34 AM, Reco wrote:
> > You cannot change your fingerprint (legally, that is).
> 
> Say what? Are you saying there's a jurisdiction in which it's illegal
> for me to sand off, cut, or otherwise mutillate my own fingerprint?

Depends on where you live and on what you're doing for the living.
I imagine a government employee (say, military or law enforment) will
have a hard time explaining "accidental" fingerprint mutilation on all
ten fingers.
Last time I travelled to England - they took my fingerprints beforehand,
and checked them at Heathrow's customs. Suffice to say I'd be sent back
home on a nearest airplane if they haven't match.

Reco

Re: Assorted arm-buster problems - network configuration

[Reco]

On Thu, Jul 04, 2019 at 09:42:11PM +0100, Brian wrote:
> On Thu 04 Jul 2019 at 22:05:09 +0200, to...@tuxteam.de wrote:
> 
> > On Thu, Jul 04, 2019 at 08:56:45PM +0100, Tixy wrote:
> > > On Thu, 2019-07-04 at 20:01 +0100, Brian wrote:
> > > > On Thu 04 Jul 2019 at 19:18:13 +0300, Reco wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > I'd also consider exterminating avahi with extreme prejudice, i.e.
> > > > > 'apt
> > > > > purge avahi-daemon'. Really simplifies things. Not installing this
> > > > > software in the first place works even better.
> > > > 
> > > > Gene Heskett can follow this advice if he wishes. It is to be hoped
> > > > that every other user ignores it.

Oh, it seems that I've touched a nerve. My apologies just in case.


> > > Why? It's advice I decided for myself 10 or more years ago after seeing
> > > constant reports of zeroconf bugs in various OSes and kit, and
> > > realising that sort of thing was also running on my Linux machines. The
> > > whole idea of automagically setting up networks just sounds like a
> > > problem and security hole waiting to happen. So I decided to nuke it
> > > from orbit, it was the only safe thing to do.
> > 
> > As always, all generalizations suck. Some do avahi, others don't (full
> > disclosure: I am in the "don't" camp, as many may have guessed :-)
> 
> If nobody objects I would like to reword that statement. Many, many
> users will have avahi-daemon on their systems; a few won't.

[1] says that half of the Debian users participating in popcon have
avahi-daemon installed. Your assertion that "don't camp" is a minority
is off. That's a first.

Second, contrary to the popular thinking here, the world does not start
and does not end with GNOME and x86 along with the CUPS installed.
And while avahi enhances CUPS' usability indeed, it has little
usefulness otherwise.

Third, whatever good avahi does is limited to a single L2 network
segment by the very definition of how it works. This particular problem
shows it BTW.


> The idea
> that
> 
>   > Not installing this software in the first place works even better.
> 
> requires clarification.

Easy. You don't understand what the software does (Gene's here), or you
don't need its functions (I'm here) - you just do not install it. You
don't fight with it, you don't try to "disable" it in myriad ways, and
you do not build assorted kludges alongside of it - you do not install
it, simple as that.


[1] https://qa.debian.org/popcon.php?package=avahi

Reco