Why /usr/sbin is not in my root $PATH ?

[Pierre Couderc]

Hi

Why /usr/sbin is not in my root $PATH ?


xxx@server:~$ su root
Password:
root@server:/home/nous# echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin

Why /usr/sbin is not in my root $PATH ?

Is it a bug somewhere in debian ? Installing snap ?

Or is my system corrupted ?

Thanks for any explanation

PC

Re: Why /usr/sbin is not in my root $PATH ?

[Reco]

Hi.

On Thu, Feb 21, 2019 at 09:07:09AM +0100, Pierre Couderc wrote:
> Hi
> 
> Why /usr/sbin is not in my root $PATH ?
> 
> 
> xxx@server:~$ su root

Because you did exactly this. su(1) says:

The optional argument - may be used to provide an environment similar to
what the user would expect had the user logged in directly.

Make a habit of using 'su -', as this behaviour is here to stay.


> Is it a bug somewhere in debian ? Installing snap ?

It's a change in Debian, see #833256.
There are two su utilities, from 'shadow' and from 'util-linux'.
Preserving user's environment unless '-' is specified is a feature of
util-linux's su.

Reco

Re: Why /usr/sbin is not in my root $PATH ?

[Pierre Couderc]

On 2/21/19 9:15 AM, Reco wrote:

Hi.

On Thu, Feb 21, 2019 at 09:07:09AM +0100, Pierre Couderc wrote:

Hi

Why /usr/sbin is not in my root $PATH ?


xxx@server:~$ su root

Because you did exactly this. su(1) says:

The optional argument - may be used to provide an environment similar to
what the user would expect had the user logged in directly.

Make a habit of using 'su -', as this behaviour is here to stay.



Is it a bug somewhere in debian ? Installing snap ?

It's a change in Debian, see #833256.
There are two su utilities, from 'shadow' and from 'util-linux'.
Preserving user's environment unless '-' is specified is a feature of
util-linux's su.

Reco


Thnk you very much. This is the answer I needed. Sorry for the noise ;)

Re: Your Password Reset Link from CorrLinks

[tomas]

On Thu, Feb 21, 2019 at 10:55:44AM +0300, Reco wrote:
>   Hi.
> 
> On Thu, Feb 21, 2019 at 02:30:48AM -0500, Gene Heskett wrote:
> > On Thursday 21 February 2019 01:14:03 w...@corrlinks.com wrote:
> > 
> > > To reset your password, please click the link below.  This link will
> > > expire in 24 hours.
> > >
> > > 
> > 
> > Whats worse is that my isp is rightfully rejecting some of this bs as 
> > spam, but I get the threatening msgs from the debian server, threatening 
> > to unsuscribe me for the bounces.
> 
> You do not bounce to the list - [1]. Yes, even if it's spam.
> They will excommunicate you if you insist on bouncing to the list.

+10 (duh, as an "antisocial network" hater, I never thought I'd be
doing this). You shouldn't /bounce/ spam anyway: where are you going
to bounce it to? To a most probably spoofed address, i.e. to a
totally innocent victim? Thus generating reflected spam, aka Joe
Jobs?

If your mail provider is doing this, he is incompetent and you
should bounce HIM. The only fair game these days is to reject the
message while it's being delivered.

> If you want to notify listmaster team about spam, you should bounce to [2].

I'm using [3]. What do folks think is the Right Thing To Do?

> > debian shoulda rejected it in the first place.
> 
> And you can help this by reporting an offending e-mail as spam, see [1].

Exactly. "debian" is "all of us". We ain't Big Blue or Microsoft
or something (that's at least why /I/ am here).

FWIW, the list spam checker wasn't way off the mark:

  X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on bendel.debian.org
  X-Spam-Level: **
  X-Spam-Status: No, score=2.7 required=4.0 tests=DIGITS_LETTERS,DKIM_SIGNED,
[...]

Interestingly, the mail itself seems genuine, coming from corrlinks [4],
some kind of state-backed jail inmate exploitation schema. Shudder. Just
their web "masters" seem to have enabled a spam hub in their infinite
wisdom.

Cheers

[1] https://wiki.debian.org/Teams/ListMaster/FAQ
[2] mailto:listmas...@lists.debian.org
[3] mailto:report-lists...@lists.debian.org
-- tomás


signature.asc
Description: Digital signature

Re: Your Password Reset Link from CorrLinks

[Reco]

Hi.

On Thu, Feb 21, 2019 at 09:38:54AM +0100, to...@tuxteam.de wrote:
> > If you want to notify listmaster team about spam, you should bounce to [2].
> 
> I'm using [3]. What do folks think is the Right Thing To Do?

[1] says:

You can also help us by bouncing (as in mutt) spam to 
report-lists...@lists.debian.org


It's my understanding that bouncing to [3] should be ok.

> [1] https://wiki.debian.org/Teams/ListMaster/FAQ
> [2] mailto:listmas...@lists.debian.org
> [3] mailto:report-lists...@lists.debian.org

Reco

What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks]

[tomas]

On Thu, Feb 21, 2019 at 11:45:50AM +0300, Reco wrote:

[...]

> You can also help us by bouncing (as in mutt) spam to 
> report-lists...@lists.debian.org

Thanks
-- t


signature.asc
Description: Digital signature

Strange attacks in my log

[Hans]

Hi folks,

I discovered some strange log entries, which are created by "portsentry" (a 
tool for 
wathing port accesses).

It looks like whenever I insert an USB-drive or a SD-Card, the own system wants 
to 
access on an UDP-Port (69 or 161). It tries also to access all other computers 
in the 
network. 

This looks strange for me, because I can not reproduce, why inserting a memeory 
device, network activies are started. 

With wireshark I could see, this is "BJNP" (whatever this means)

Same happens, when pulling the USB-stick or the sd-card out.

This is, what is in the log:

 snip --

Feb 21 10:14:39 localhost udisksd[13607]: g_object_unref: assertion'G_IS_OBJECT 
(object)' failed Feb 21 10:14:44 localhost scanbd: /usr/sbin/scanbd: no 
devices, not 
starting any polling thread Feb 21 10:14:47 localhost portsentry[6172]: 
attackalert: 
Connect from host: 192.168.2.117/192.168.2.117 to UDP port: 161 Feb 21 10:14:47 
localhost portsentry[6172]: attackalert: Host: 192.168.2.117 is already 
blocked. 
Ignoring Feb 21 10:14:48 localhost portsentry[6172]: attackalert: Connect from 
host: 
192.168.2.117/192.168.2.117 to UDP port: 161 Feb 21 10:14:48 localhost 
portsentry[6172]: attackalert: Host: 192.168.2.117 is already blocked. Ignoring 
Feb 
21 10:14:53 localhost scanbd: /usr/sbin/scanbd: no devices, not starting any 
polling 
thread Feb 21 10:15:01 localhost CRON[27395]: (root) CMD (if [ -x /usr/bin/
gsmsmsrequeue ]; then /us


-- snap -

Same log appeares on the other computers (with the same source). I inserted the 
card in the computer with the ip "192.168.2.117".

Can anybody confirm this, or does know some background?

Thanks for enlightening me.

Best regards

Hans


signature.asc
Description: This is a digitally signed message part.

Your Password Reset Link from CorrLinks

[Web]

To reset your password, please click the link below.  This link will expire in 
24 hours.

https://www.corrlinks.com/R.aspx?c=3dfbad26-9ef1-401b-b0f7-c89d49a8a73c

Re: Strange attacks in my log

[Reco]

Hi.

On Thu, Feb 21, 2019 at 10:29:49AM +0100, Hans wrote:
> Hi folks,
> 
> I discovered some strange log entries, which are created by "portsentry" (a 
> tool for 
> wathing port accesses).
> 
> It looks like whenever I insert an USB-drive or a SD-Card, the own system 
> wants to 
> access on an UDP-Port (69 or 161).
udp:69 is TFTP.
udp:161 is SNMP.

I can understand udp:161. One of the functions of snmpd is filesystem
monitoring, and you have this scanbd thing that implies SANE that
implies snmpd.
But establishing TFTP session 'just because' is weird.


> It tries also to access all other computers in the network. 

Broadcast, unicast, or ...?


> This looks strange for me, because I can not reproduce, why inserting a 
> memeory 
> device, network activies are started. 
> 
> With wireshark I could see, this is "BJNP" (whatever this means)

Curious. Can you share a this network dump in pcap format?
As in,

tcpdump -s0 -w /tmp/69_161.pcap -ni any udp port 69 or udp port 161


> Same happens, when pulling the USB-stick or the sd-card out.
> 
> This is, what is in the log:
> 
>  snip --
> 
> Feb 21 10:14:39 localhost udisksd[13607]: g_object_unref: 
> assertion'G_IS_OBJECT 
> (object)' failed Feb 21 10:14:44 localhost scanbd: /usr/sbin/scanbd: no 
> devices, not 
> starting any polling thread

Useless


> Feb 21 10:14:47 localhost portsentry[6172]: attackalert: 
> Connect from host: 192.168.2.117/192.168.2.117 to UDP port: 161

So it's a local SNMP connection, if I get it right?

Reco

Re: Strange attacks in my log

[Dan Purgert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hans wrote:
> Hi folks,
>
> I discovered some strange log entries, which are created by
> "portsentry" (a tool for wathing port accesses).
>
> It looks like whenever I insert an USB-drive or a SD-Card, the own
> system wants to access on an UDP-Port (69 or 161). It tries also to
> access all other computers in the network. 

UDP 161 is used for SNMP (Simple Network Management Protocol) -- well,
it's "assigned" to that protocol, but like TCP port 53 (DNS over TCP),
it may not be used all that much.

UDP 69 is TFTP.

>
> This looks strange for me, because I can not reproduce, why inserting
> a memeory device, network activies are started. [...]

Could be triggering some service on the machine in question. What OS is
the host you're plugging this card into running?


-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAlxuepwACgkQjhHd8xJ5
ooHnQwf/TrmqKAeLc1zkKWfs1Oykk2t+HvD8DixH6380c3HHLIL0Wxp1IsxMEV7N
AsdFmYygp2KFzo+CqzhIdYQkN2mV2DikkQEeMsgoJCTSCEGk5c9shSnSjjErH3J0
+y8xMfGD8edRD/rLfbmoqWsHjzthEfhPDLQNvi7YtVlssfL6/MR9F8sv6mYUiTQR
HE8YN276x47ytVBDIsfX1yvaxpxt51Zg3bdVPNWBfO2r79DuHJaaSykv8lB/VT3F
3Aj/+u78ZkhSlhJvN3JajZIbvOg9nXGSpNZRa4KFKCrKVXvJw6+zT4vaa3/B4Bvx
TTGV94s/vF4OKPtUpK3piEDEejTroQ==
=or9p
-END PGP SIGNATURE-

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: Strange attacks in my log

[Hans]

Am Donnerstag, 21. Februar 2019, 11:19:08 CET schrieb Reco:
Hi Reco (and all others),

sure, I attached the wireshark pcap. Thre is nothing secret in it.

However, I know, what the ports are for, but it is not understandable for me, 
why there are networking protocols are started, when I just put a stick into 
the required slot. And these devices are still not mounted! There is no sense 
IMO, why the computer is scanning the network at all.

This is really weired. I wouldn't have noticed it, when I wouldn't have 
installed several alerting tools. 

Notice: You just put an usb-stick into the slot - and the system is starting 
network protocols and begin scanning the network. WTF???

My systems are all debian/testing (32-bit and 64-bit), all have the same 
configurations and package versions.

Hope this helps.

Best regards

Hans 



>   Hi.
> 
> On Thu, Feb 21, 2019 at 10:29:49AM +0100, Hans wrote:
> > Hi folks,
> > 
> > I discovered some strange log entries, which are created by "portsentry"
> > (a tool for wathing port accesses).
> > 
> > It looks like whenever I insert an USB-drive or a SD-Card, the own system
> > wants to access on an UDP-Port (69 or 161).
> 
> udp:69 is TFTP.
> udp:161 is SNMP.
> 
> I can understand udp:161. One of the functions of snmpd is filesystem
> monitoring, and you have this scanbd thing that implies SANE that
> implies snmpd.
> But establishing TFTP session 'just because' is weird.
> 
> > It tries also to access all other computers in the network.
> 
> Broadcast, unicast, or ...?
> 
> > This looks strange for me, because I can not reproduce, why inserting a
> > memeory device, network activies are started.
> > 
> > With wireshark I could see, this is "BJNP" (whatever this means)
> 
> Curious. Can you share a this network dump in pcap format?
> As in,
> 
> tcpdump -s0 -w /tmp/69_161.pcap -ni any udp port 69 or udp port 161
> 
> > Same happens, when pulling the USB-stick or the sd-card out.
> > 
> > This is, what is in the log:
> > 
> >  snip --
> > 
> > Feb 21 10:14:39 localhost udisksd[13607]: g_object_unref:
> > assertion'G_IS_OBJECT (object)' failed Feb 21 10:14:44 localhost scanbd:
> > /usr/sbin/scanbd: no devices, not starting any polling thread
> 
> Useless
> 
> > Feb 21 10:14:47 localhost portsentry[6172]: attackalert:
> > Connect from host: 192.168.2.117/192.168.2.117 to UDP port: 161
> 
> So it's a local SNMP connection, if I get it right?
> 
> Reco



wireshark_udp_192.168.2.117.pcap
Description: application/vnd.tcpdump.pcap


signature.asc
Description: This is a digitally signed message part.

Re: Strange attacks in my log

[Reco]

Hi.

On Thu, Feb 21, 2019 at 11:42:58AM +0100, Hans wrote:
> Am Donnerstag, 21. Februar 2019, 11:19:08 CET schrieb Reco:
> Hi Reco (and all others),
> 
> sure, I attached the wireshark pcap. Thre is nothing secret in it.

That's interesting. Aforementioned pcap does not contain udp:69, but it
does contain broadcast udp:161 (src: 192.168.2.117 dst:
255.255.255.255), requesting three OIDs via SNMP v2c:

$ snmptranslate -mALL .1.3.6.1.2.1.1.1.0
RFC1213-MIB::sysDescr.0
$ snmptranslate -mALL .1.3.6.1.2.1.1.2.0
RFC1213-MIB::sysObjectID.0
$ snmptranslate -mALL .1.3.6.1.2.1.2.2.1.6.1
RFC1213-MIB::ifPhysAddress.1


A hint. One should not (ab)use SNMP this way. Even if you're doing
device discovery - you're doing it wrong by sending SNMP to broadcast.
Explains why your other hosts see this though.


> However, I know, what the ports are for, but it is not understandable for me, 
> why there are networking protocols are started, when I just put a stick into 
> the required slot. And these devices are still not mounted! There is no sense 
> IMO, why the computer is scanning the network at all.

There can be an explanation, though, but Wireshark/tcpdump in not
suitable to get it.

Install auditd.
Invoke "auditctl -a always,exit -S connect".
Insert any usb stick
Invoke "auditctl -D" to clear the rules.

All the answers should wait one at /var/log/audit/audit.log

Reco

Re: Your Password Reset Link from CorrLinks

[Andy Smith]

Hello,

On Thu, Feb 21, 2019 at 10:55:44AM +0300, Reco wrote:
> On Thu, Feb 21, 2019 at 02:30:48AM -0500, Gene Heskett wrote:
> > On Thursday 21 February 2019 01:14:03 w...@corrlinks.com wrote:
> > > 
> > 
> > Whats worse is that my isp is rightfully rejecting some of this bs as 
> > spam, but I get the threatening msgs from the debian server, threatening 
> > to unsuscribe me for the bounces.
> 
> You do not bounce to the list - [1]. Yes, even if it's spam.
> They will excommunicate you if you insist on bouncing to the list.

Before we get carried away here, I highly suspect that Gene is talking
about their mail server rejecting the mail during the SMTP conversation,
which is a correct thing to do if the mail is unwanted. This doesn't
generate what we would typically refer to as a bounce.

However, since the SMTP conversation is with Debian's list server,
Debian's list server then warns Gene that mail it has tried to deliver
to Gene has been rejected. Multiple such rejections would lead to the
list server deciding that Gene's account has become invalid, and the
automatica unsubscription of Gene from this list. Again, no actual
bounces here, and everyone involved is behaving reasonably.

Rejecting unwanted email during the SMTP connection is the correct thing
to do, but it is pointless rejecting mail from known list servers as
they are not in a position to do anything about that and repeated
rejection of email will lead to them unsubscribing you. So Gene might
like to find way to establish when the peer is a list server and just
discard the mail in that case. Or deliver it to some sort of quarantine
area.

Ideally of course, the Debian list server would have spotted that this
particular email is not useful for the debian-user list and not accepted
it in the first place. This is really hard though, because this email is
not spam. Unless "spam" is something you define as "email I don't want".
This email appears to be from a legitimate and real service, and
although we as humans can see that it would never be likely to be of
interest to debian-user, it's hard for a computer program to do that.
What seems to have happened here is that some other human has decided
to prank the list by putting the list's address into that web site.

So, since it is the case that there is often going to be email that
Debian's list server fails to notice is inappropriate but the user's own
mail server does (because the user knows more about what they are willing
to accept), it would be better for the user not to reject the list
server's mail if possible, or else accept that a spate of such
rejections may result in unwanted unsubscription from the list.

I don't think it's fair to suggest that Debian's list server is at fault
for accepting this email, because as mentioned it's not spam, it's just
off-topic, and furthermore is likely the result of deliberate pranking
by a human. Expecting Debian's list server to detect that with no prior
information seems a bit much.

Certainly as you suggest people could contact listmaster@ with a pointer
to this thread and ask for future mail from corrlinks.com to be rejected
though, as it would seem such mail would never be relevant.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Why /usr/sbin is not in my root $PATH ?

[Greg Wooledge]

On Thu, Feb 21, 2019 at 09:31:31AM +0100, Pierre Couderc wrote:
> On 2/21/19 9:15 AM, Reco wrote:
> > On Thu, Feb 21, 2019 at 09:07:09AM +0100, Pierre Couderc wrote:
> > > Why /usr/sbin is not in my root $PATH ?

Because you upgraded to buster (or unstable), and Debian in its infinite
wisdom has changed the behavior of su between stretch and buster.

> > Make a habit of using 'su -', as this behaviour is here to stay.

Or use one of several other workarounds, for example putting /usr/sbin
and /sbin into your regular user account's PATH.

> > It's a change in Debian, see #833256.
> > There are two su utilities, from 'shadow' and from 'util-linux'.
> > Preserving user's environment unless '-' is specified is a feature of
> > util-linux's su.
> > 
> Thnk you very much. This is the answer I needed. Sorry for the noise ;)

It's not noise.  This is going to be the number one support issue for
buster, I just know it.  This question is going to come up repeatedly.
The su change breaks *so* much.

Red Hatters have apparently been living with this behavior for years,
and they came up with the "su -" workaround.  And hey, if that works
for them, great.

The problem with "su -" is that it strips out *all* of your environment,
*and* it changes your working directory to /root.  So, some things which
work perfectly well in stretch (with "su") will no longer work in buster
(with "su -").

Example 1:

$ make
$ su -
# make install# fails because you're no longer in the build dir

Example 2:

$ export LANG=something LESS=-X ...
$ su -
# man something   # your environment settings have been lost

I haven't upgraded to buster yet, so I haven't had to make any changes to
my own environment yet, but I suspect I'll be adding /usr/sbin and /sbin
to my regular account's PATH.  That will break the smallest amount of
stuff for my usage patterns, as I will be able to continue using a normal
"su" which will retain my environment and my working directory.

Re: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks]

[Gene Heskett]

On Thursday 21 February 2019 03:59:37 to...@tuxteam.de wrote:

> On Thu, Feb 21, 2019 at 11:45:50AM +0300, Reco wrote:
>
> [...]
>
> > You can also help us by bouncing (as in mutt) spam to
> > report-lists...@lists.debian.org
>
> Thanks
> -- t
This _might_ be a good idea, if that address took forwards. My incoming 
chain does not include the ability to do other than accept, then divert 
to /var/mail/virii or /dev/null. But my one attempt to forward to that 
address when debians poor spam/viri filters failed often enough to get 
my attention several years ago, resulted in its being bounced back to me

Don't give me, or my current ISP a hard time because their spam filtering 
is far better then debians. I get very little spam from them because 
they do active bouncing, using barracuda I believe, or they'll put it in 
a spam folder, but thats rare, 4 to 10 msgs a day. When I moved my 
server from my former employers server because the facility had been 
sold and my lifetime account was going away, I had to call the tech 
people at Shentel and compose a whitelist. Putting debian on that 
whitelist raised the spam content around 10% here. My incoming spam gets 
fed to sa-learn at about 1 am, and the folder copied to a 1 day save in 
case I need to retrieve something. Its coming up on 8 am local, and only 
3 more have been caught by SA. I'll have maybe 15 by the end of the 
collection day. I thank my ISP for their active filtering as its caught 
hundreds I don't have to even waste the bandwidth to download.

I could probably, with some study, have procmail forward that stuff to 
the above address in near real time.

But if all it generates is bounces, why bother? That just serves to prove 
to me that debian has zero interest in containing UCE. Since I don't set 
the rules, or write the checks for debian, that just how it is.

Thats a choice debian has made as its the least manpower choice, and I 
grok that.

But redirecting the blame to me or my ISP because debians filtering is 
poor, is poor form in any language. I go look at every message that I 
get threatening messages from your server over because my ISP bounced 
it, and there have been no exceptions in 2 years, every time you got a 
bounce from my ISP, it was blatantly UCE that the debian server should 
have sent to  /dev/null, and I'll not apologize for that. I do not 
consider its me or my ISP's problem. 

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks]

[Greg Wooledge]

On Thu, Feb 21, 2019 at 08:21:00AM -0500, Gene Heskett wrote:
> > On Thu, Feb 21, 2019 at 11:45:50AM +0300, Reco wrote:
> > [...]
> >
> > > You can also help us by bouncing (as in mutt) spam to
> > > report-lists...@lists.debian.org

> This _might_ be a good idea, if that address took forwards.

Forwarding and bouncing are completely different operations.  If you
aren't using mutt/neomutt and don't have a literal bounce feature, then
please just ignore this part.

Re: Why /usr/sbin is not in my root $PATH ?

[Brad Rogers]

On Thu, 21 Feb 2019 08:20:46 -0500
Greg Wooledge  wrote:

Hello Greg,

>$ make
>$ su -
># make install# fails because you're no longer in the build dir

Just do;

$ make
$ sudo make install

Works fine.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Life goes quick and it goes without warning
Bombsite Boy - The Adverts


pgpRyh8BRh5KW.pgp
Description: OpenPGP digital signature

Re: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks]

[Reco]

Hi.

On Thu, Feb 21, 2019 at 08:21:00AM -0500, Gene Heskett wrote:
> On Thursday 21 February 2019 03:59:37 to...@tuxteam.de wrote:
> 
> > On Thu, Feb 21, 2019 at 11:45:50AM +0300, Reco wrote:
> >
> > [...]
> >
> > > You can also help us by bouncing (as in mutt) spam to
> > > report-lists...@lists.debian.org
> >

> This _might_ be a good idea, if that address took forwards. My incoming 
> chain does not include the ability to do other than accept, then divert 
> to /var/mail/virii or /dev/null. But my one attempt to forward to that 
> address when debians poor spam/viri filters failed often enough to get 
> my attention several years ago, resulted in its being bounced back to me

There's a difference between 'Forward' and 'Bounce'. That e-mail is for bounces.


> Don't give me, or my current ISP a hard time because their spam filtering 
> is far better ...  using barracuda

LOL. Did you mean *this* Barracuda - [1]?
The thing's a best possible example of how you *do not* filter spam
*ever*.


> I believe, or they'll put it in 
> a spam folder, but thats rare, 4 to 10 msgs a day.

Here (office, not this MTA) we have 1 (that's 'one') per week if we're
lucky (and on unlucky weeks it's exactly 0). And yes, it's Amavisd +
SpamAssassin + Greylistd.


Reco

[1] http://www.dontbouncespam.org/

Re: Why /usr/sbin is not in my root $PATH ?

[Reco]

Hi.

On Thu, Feb 21, 2019 at 08:20:46AM -0500, Greg Wooledge wrote:
> On Thu, Feb 21, 2019 at 09:31:31AM +0100, Pierre Couderc wrote:
> > On 2/21/19 9:15 AM, Reco wrote:
> > > On Thu, Feb 21, 2019 at 09:07:09AM +0100, Pierre Couderc wrote:
> > > > Why /usr/sbin is not in my root $PATH ?
> 
> Because you upgraded to buster (or unstable), and Debian in its infinite
> wisdom has changed the behavior of su between stretch and buster.

A small nit. They've changed the implementation of su.
Behaviour change is a consequence.


> > > Make a habit of using 'su -', as this behaviour is here to stay.
> 
> Or use one of several other workarounds, for example putting /usr/sbin
> and /sbin into your regular user account's PATH.

That'll work too.

Reco

Re: Why /usr/sbin is not in my root $PATH ?

[Greg Wooledge]

On Thu, Feb 21, 2019 at 01:30:05PM +, Brad Rogers wrote:
> On Thu, 21 Feb 2019 08:20:46 -0500
> Greg Wooledge  wrote:
> 
> Hello Greg,
> 
> >$ make
> >$ su -
> ># make install# fails because you're no longer in the build dir
> 
> Just do;
> 
> $ make
> $ sudo make install
> 
> Works fine.

Yes, that's another workaround: "just never use su at all, ever again".

Please remember, though, that sudo is not installed by default in Debian.
So, as with every other workaround that we're discussing, some action is
required on the part of the user to implement the workaround.

At some point I'm going to need to write a wiki page to explain the
change, and list some known workarounds, so that users can pick which
one they want to implement.

Re: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks]

[Gene Heskett]

On Thursday 21 February 2019 08:32:18 Reco wrote:

>   Hi.
>
> On Thu, Feb 21, 2019 at 08:21:00AM -0500, Gene Heskett wrote:
> > On Thursday 21 February 2019 03:59:37 to...@tuxteam.de wrote:
> > > On Thu, Feb 21, 2019 at 11:45:50AM +0300, Reco wrote:
> > >
> > > [...]
> > >
> > > > You can also help us by bouncing (as in mutt) spam to
> > > > report-lists...@lists.debian.org
> >
> > This _might_ be a good idea, if that address took forwards. My
> > incoming chain does not include the ability to do other than accept,
> > then divert to /var/mail/virii or /dev/null. But my one attempt to
> > forward to that address when debians poor spam/viri filters failed
> > often enough to get my attention several years ago, resulted in its
> > being bounced back to me
>
> There's a difference between 'Forward' and 'Bounce'. That e-mail is
> for bounces.
>
> > Don't give me, or my current ISP a hard time because their spam
> > filtering is far better ...  using barracuda
>
> LOL. Did you mean *this* Barracuda - [1]?
> The thing's a best possible example of how you *do not* filter spam
> *ever*.
>
Maybe, but it works.
> > I believe, or they'll put it in
> > a spam folder, but thats rare, 4 to 10 msgs a day.
>
> Here (office, not this MTA) we have 1 (that's 'one') per week if we're
> lucky (and on unlucky weeks it's exactly 0). And yes, it's Amavisd +
> SpamAssassin + Greylistd.
>
>
> Reco
>
> [1] http://www.dontbouncespam.org/


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks]

[Gene Heskett]

On Thursday 21 February 2019 08:25:54 Greg Wooledge wrote:

> On Thu, Feb 21, 2019 at 08:21:00AM -0500, Gene Heskett wrote:
> > > On Thu, Feb 21, 2019 at 11:45:50AM +0300, Reco wrote:
> > > [...]
> > >
> > > > You can also help us by bouncing (as in mutt) spam to
> > > > report-lists...@lists.debian.org
> >
> > This _might_ be a good idea, if that address took forwards.
>
> Forwarding and bouncing are completely different operations.  If you
> aren't using mutt/neomutt and don't have a literal bounce feature,
> then please just ignore this part.

I am not using mutt. TDE version of kmail. And I'd point out that the 
threat of a list unsubscribe is blamed on a "bounce". That specific 
word.

And as far as I know, fetchmail has no ability/facility to bounce a 
message. Fetchmail-6.3.26 IIRC. Locally built from tarball.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Why /usr/sbin is not in my root $PATH ?

[Brad Rogers]

On Thu, 21 Feb 2019 08:37:35 -0500
Greg Wooledge  wrote:

Hello Greg,

>Yes, that's another workaround: "just never use su at all, ever again".

You're putting words in my mouth.  I was dealing with one use case, not
saying "..never use..".

>Please remember, though, that sudo is not installed by default in

Good point, I'd forgotten that.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Looking for something I can call my own
Chairman Of The Bored - Crass


pgp1BYbaDCwU3.pgp
Description: OpenPGP digital signature

Re: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks]

[Reco]

Hi.

On Thu, Feb 21, 2019 at 08:43:47AM -0500, Gene Heskett wrote:
> On Thursday 21 February 2019 08:32:18 Reco wrote:
> 
> > Hi.
> >
> > On Thu, Feb 21, 2019 at 08:21:00AM -0500, Gene Heskett wrote:
> > > On Thursday 21 February 2019 03:59:37 to...@tuxteam.de wrote:
> > > > On Thu, Feb 21, 2019 at 11:45:50AM +0300, Reco wrote:
> > > >
> > > > [...]
> > > >
> > > > > You can also help us by bouncing (as in mutt) spam to
> > > > > report-lists...@lists.debian.org
> > >
> > > This _might_ be a good idea, if that address took forwards. My
> > > incoming chain does not include the ability to do other than accept,
> > > then divert to /var/mail/virii or /dev/null. But my one attempt to
> > > forward to that address when debians poor spam/viri filters failed
> > > often enough to get my attention several years ago, resulted in its
> > > being bounced back to me
> >
> > There's a difference between 'Forward' and 'Bounce'. That e-mail is
> > for bounces.
> >
> > > Don't give me, or my current ISP a hard time because their spam
> > > filtering is far better ...  using barracuda
> >
> > LOL. Did you mean *this* Barracuda - [1]?
> > The thing's a best possible example of how you *do not* filter spam
> > *ever*.
> >
> Maybe, but it works.

You haven't read the link, haven't you?
You ISP's parody for spam filtering will kick you out the list.
Just because it's written in such way.

Reco

Re: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks]

[Greg Wooledge]

> > Forwarding and bouncing are completely different operations.  If you
> > aren't using mutt/neomutt and don't have a literal bounce feature,
> > then please just ignore this part.
> 
> I am not using mutt. TDE version of kmail. And I'd point out that the 
> threat of a list unsubscribe is blamed on a "bounce". That specific 
> word.

English sucks.  Words are overloaded and have multiple meanings.

The word "bounce" in particular is being used in two very different ways
in this thread.

(1) When an SMTP receiver accepts a message and then later discovers that
it cannot deliver said message, it is "supposed" to generate
a response message to inform the sender that the message was
undeliverable.  This response is called a "bounce".

That design is from the early days of the Internet, when spam was
not (such) an issue.  It worked great in 1990 when the main problems
were speed, reliability and cost of site-to-site connections.  The
goal was to ensure that mail got through no matter what.  Receivers
expected that every incoming message was important and was sent in
good faith.  The intent was for the receiver to try *really* hard to
make the delivery or send the message on its way, even if it was
sent to the wrong place by accident, and even if the original sender
couldn't stay connected while the receiver tried to figure out how
to deal with the message.

Today, that design is EXTREMELY bad, because spammers have taken
advantage of it.  Spammers forge the sender address, and then send
their spam to an invalid (or just random) recipient address.  If
the receiver naively implements the old SMTP protocols including
separate "bounce" responses, then the spam is sent to the forged
sender address by the naive victim, and is that much harder to trace
back to the actual spammer.  This is known as a "joe job", because
an innocent victim gets blamed for it.

(2) Mutt has a feature that lets you send an EXACT copy of a message to
a different address, preserving all of the headers and content
verbatim.  Mutt calls this "bouncing".

It's different from "forwarding", which strips out all the headers and
generates a whole new message with your own regular outgoing headers.

See the documentation at 
and .

Re: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks]

[Gene Heskett]

On Thursday 21 February 2019 09:01:04 Greg Wooledge wrote:

> > > Forwarding and bouncing are completely different operations.  If
> > > you aren't using mutt/neomutt and don't have a literal bounce
> > > feature, then please just ignore this part.
> >
> > I am not using mutt. TDE version of kmail. And I'd point out that
> > the threat of a list unsubscribe is blamed on a "bounce". That
> > specific word.
>
> English sucks.  Words are overloaded and have multiple meanings.
>
A quite high vacuum at times.

> (2) Mutt has a feature that lets you send an EXACT copy of a message
> to a different address, preserving all of the headers and content
> verbatim.  Mutt calls this "bouncing".

If this is such a good feature, why is mutt the only agent doing it?
>
> It's different from "forwarding", which strips out all the headers
> and generates a whole new message with your own regular outgoing
> headers.

Ok, but this doesn't change the messages content, which is what generally 
makes it UCE. So I fail to see the absolute isolation implied. Its still 
valuable for bayes training. Just takes more copies of it to average out 
the noise of where it came FROM.
>
> See the documentation at
>  and
> .

I have read the link reco sent, many times at many addresses. Can't argue 
a bit about 99% of it ought to go to /dev/null based of don't give them 
a clue it actually was seen by a human eyeball. It ought to all go 
to /dev/null. When no response is generated, they'll run out of money to 
buy bandwidth, and TANSTAAFL will see to it that space gets rented to 
the next sucker, who bought the last truckload of cabbage patch dolls to 
unload as collectors items. Or maybe it was pet rocks?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks]

[Curt]

On 2019-02-21, Gene Heskett  wrote:
>
>> (2) Mutt has a feature that lets you send an EXACT copy of a message
>> to a different address, preserving all of the headers and content
>> verbatim.  Mutt calls this "bouncing".
>
> If this is such a good feature, why is mutt the only agent doing it?
>>

As a matter of fact, Alpine has the same feature and uses the same
designating term ('BOUNCE (redirect) message to :').

I hadn't actually thought before now about the ambiguity of the word and
the possible confusion that might arise given its other, perhaps more
historically valid, meaning.

Re: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks]

[Dan Ritter]

Gene Heskett wrote: 
> On Thursday 21 February 2019 09:01:04 Greg Wooledge wrote:
> 
> > > > Forwarding and bouncing are completely different operations.  If
> > > > you aren't using mutt/neomutt and don't have a literal bounce
> > > > feature, then please just ignore this part.
> > >
> > > I am not using mutt. TDE version of kmail. And I'd point out that
> > > the threat of a list unsubscribe is blamed on a "bounce". That
> > > specific word.
> >
> > English sucks.  Words are overloaded and have multiple meanings.
> >
> A quite high vacuum at times.
> 
> > (2) Mutt has a feature that lets you send an EXACT copy of a message
> > to a different address, preserving all of the headers and content
> > verbatim.  Mutt calls this "bouncing".
> 
> If this is such a good feature, why is mutt the only agent doing it?

Because mutt has lots of input from sysadmins, whereas most mail
agents are trying to be easy to use for people who don't read
manuals.

Imagine if the interface for a CNC mill was developed by
Microsoft with the goal that no user could ever cut
themselves on sharp edges. Every edge will be chamfered or
radiused, and you'll never be able to get two pieces to line 
up next to each other seamlessly.

The UNIX philosophy is that at any moment, a user might change into a
sysadmin or a programmer, so make those tools available if they
know how to invoke them.

-dsr-

Re: Strange attacks in my log

[Hans]

Hmm, tried "auditctl -a always,exit -S connect -F arch=b64


Tha manual told nothing about a logfile. 

What do I do wrong?

Hans




wireshark_udp_192.168.2.117.pcap
Description: application/vnd.tcpdump.pcap


signature.asc
Description: This is a digitally signed message part.

Re: Strange attacks in my log

[Reco]

Hi.

On Thu, Feb 21, 2019 at 04:29:11PM +0100, Hans wrote:
> Hmm, tried "auditctl -a always,exit -S connect -F arch=b64

auditctl -a always,exit -S connect

Ignore 'syscall mismatch' warning, it will work anyway.

> Tha manual told nothing about a logfile. 

It's /var/log/audit/audit.log.
Red Hat documentation at it's finest.

Reco

Re: Your Password Reset Link from CorrLinks

[James H. H. Lampert]

On 2/21/19, 12:38 AM, to...@tuxteam.de wrote:

You shouldn't /bounce/ spam anyway: where are you going to bounce it
to? To a most probably spoofed address, i.e. to a totally innocent
victim? Thus generating reflected spam, aka Joe Jobs?


That depends. Some spammers don't see themselves as spammers, and
therefore aren't spoofing other addresses. They just either (1) fail to
honor unsubscribe requests, (2) don't put unsubscribe links in the plain
text, or (3) omit either the unsubscribe link or the plain text (or
both) entirely.

--
JHHL

Re: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks]

[tomas]

On Thu, Feb 21, 2019 at 08:21:00AM -0500, Gene Heskett wrote:
> On Thursday 21 February 2019 03:59:37 to...@tuxteam.de wrote:
> 
> > On Thu, Feb 21, 2019 at 11:45:50AM +0300, Reco wrote:
> >
> > [...]
> >
> > > You can also help us by bouncing (as in mutt) spam to
> > > report-lists...@lists.debian.org
> >
> > Thanks
> > -- t
> This _might_ be a good idea, if that address took forwards. My incoming 
> chain does not include the ability to do other than accept, then divert 
> to /var/mail/virii or /dev/null. But my one attempt to forward to that 
> address when debians poor spam/viri filters failed often enough to get 
> my attention several years ago, resulted in its being bounced back to me

I do it all the time (perhaps twice a week). No problems so far.

> Don't give me, or my current ISP a hard time because their spam filtering 
> is far better then debians.

This only shows that you still have much to learn about spam :-)

Filtering for an open list with roughly 600 subscribers is far more
difficult than filtering for one person, since the breadth of topics
and styles for non-spam is significantly higher. This is a real
challenge for statistical filters.

I think that, given the constraints, Debian list spam filters aren't
bad.

  "The Debian Listmasters do their best to stop as many such
   emails as possible from reaching the lists. On a typical day,
   over 40,000 such messages are blocked." [1]

> I get very little spam from them because they do active bouncing,
> using barracuda I believe,

*spit*

A couple of times I had the "honor". Dunno whether it was a bad
sysadmin or barracuda itself. Not a nice souvenir, mind you.

[...]

> But if all it generates is bounces, why bother? That just serves to prove 
> to me that debian has zero interest in containing UCE. Since I don't set 
> the rules, or write the checks for debian, that just how it is.

See above. If you go to the below reference, you even get to
propose SpamAssassin rules to the Debian list masters. I'm
sure they can use some help. They're volunteers, after all.

Saying they have "zero interest" (even if they not only do the
heavy lifting of filtering out 40K spams /a day/, but also document
what they are doing, for your and my reading convenience, all at
no cost, on a volunteer basis) is offensive.

> But redirecting the blame to me or my ISP because debians filtering is 
> poor [...]

Repeat with me:
 - you don't bounce spam at all, because you're bouncing to
   the wrong address anyway, thus just enhancing the problem.

   (There is still a reason to bounce a (legitimate) mail,
   but NEVER-EVER when you think it's spam).

 - you don't reject to mailing lists: they'll conclude that
   you have delivery problems and unsubscribe you.

This is common consensus, and for a reason. If your provider isn't
doing that, they ain't pros and are just pissing in our common well.

Sorry for being so clear, but I feel strongly about mail: it's the last
means of communication left where I have the choice of client software,
the other stuff being "antisocial networks", where some random web
designer gets to decide what I see and how. I hope I die before this
dystopia is upon us (I'm old, mind you).

Cheers

[1] https://www.debian.org/MailingLists/#ads
-- tomás


signature.asc
Description: Digital signature

Re: Why /usr/sbin is not in my root $PATH ?

[Greg Wooledge]

On Thu, Feb 21, 2019 at 04:14:53PM +, Jonathan de Boyne Pollard wrote:
> You could point them to StackExchange in the meantime.  (-:
> 
> * https://unix.stackexchange.com/a/460769/5132

On that page:
> Doing plain 'su' is a really bad idea for many reasons,

Name one!  Seriously, what kind of inane statement is that?

> If you want to restore behaviour more similar to the previous one you can
> add 'ALWAYS_SET_PATH yes' in /etc/login.defs.

OK, I'll just go to Debian's online man pages and find the buster
man page for su (or login.defs) to find out what that is...

... hey, where's the buster man pages?

Oh, lovely.  There aren't any.  So I'd have to extract the man page out 
of a buster .deb by hand, or actually RUN buster, to find out how to
document the changes in buster and how to work around them.

*sigh* ... it's going to be one of *those* upgrades, isn't it.

Re: Your Password Reset Link from CorrLinks

[tomas]

On Thu, Feb 21, 2019 at 08:20:23AM -0800, James H. H. Lampert wrote:
> On 2/21/19, 12:38 AM, to...@tuxteam.de wrote:
> >You shouldn't /bounce/ spam anyway: where are you going to bounce it
> >to? To a most probably spoofed address, i.e. to a totally innocent
> >victim? Thus generating reflected spam, aka Joe Jobs?
> 
> That depends. Some spammers don't see themselves as spammers, and
> therefore aren't spoofing other addresses. They just either (1) fail to
> honor unsubscribe requests, (2) don't put unsubscribe links in the plain
> text, or (3) omit either the unsubscribe link or the plain text (or
> both) entirely.

Well, if /you are sure/ they havent spoofed the From:, or Reply-To:
then go ahead. But you just /can't be sure/, so don't do it.

Never received bounce spam aka backscatter spam? Remember that time
(perhaps 1-2 years ago) where this very list was plagued by an
especially evil form of backscatter involving the useful idiot at
the other end of some smartphone?

Cheers
[1] https://en.wikipedia.org/wiki/Backscatter_spam

-- t


signature.asc
Description: Digital signature

Re: Strange attacks in my log

[Hans]

Am Donnerstag, 21. Februar 2019, 16:46:42 CET schrieb Reco:
Yes, worked. However, I did not find any unusual, however, putting a stick in 
is starting "colord-sane", which will explain the UDP request.

This does not explain, why a sd-card or usb-stick is calling this.

The only explanation I have, is that the kernel starts some module, which acts 
as watched. 

I wonder, why no one else noticed this behaviour, as this looks a "normal" 
behaviour on all systems.

Very strange.

Best 

Hans
>   Hi.
> 
> On Thu, Feb 21, 2019 at 04:29:11PM +0100, Hans wrote:
> > Hmm, tried "auditctl -a always,exit -S connect -F arch=b64
> 
> auditctl -a always,exit -S connect
> 
> Ignore 'syscall mismatch' warning, it will work anyway.
> 
> > Tha manual told nothing about a logfile.
> 
> It's /var/log/audit/audit.log.
> Red Hat documentation at it's finest.
> 
> Reco



signature.asc
Description: This is a digitally signed message part.

Re: Why /usr/sbin is not in my root $PATH ?

[Jonathan de Boyne Pollard]

Greg Wooledge:


At some point I'm going to need to write a wiki page to explain the 
change, and list some known workarounds, so that users can pick which 
one they want to implement.



You could point them to StackExchange in the meantime.  (-:

* https://unix.stackexchange.com/a/460769/5132

Message exchange systems (was: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks])

[Stefan Monnier]

> Sorry for being so clear, but I feel strongly about mail: it's the last
> means of communication left where I have the choice of client software,

Mostly true.  It does suffer from a terrible design w.r.t encryption, tho.

The other existing mediums (with a choice of clients) I'm aware of are
XMPP and Matrix.

XMPP has many more clients than Matrix, but has the downside that it was
designed for instant messages where delivery either happens "immediately"
or not at all, so it's not a great choice as a replacement for email
(although IIUC they have designed various patches on top of the design to
try and provide more-or-less reliable delivery even is some of the
machines along the way are or go offline at an inopportune moment).

I use Matrix on my phone (i.e. to exchange brief messages and pictures),
but not (yet) for email-like communications (where I need a real
keyboard).


Stefan

Re: Message exchange systems (was: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks])

[tomas]

On Thu, Feb 21, 2019 at 11:38:50AM -0500, Stefan Monnier wrote:
> > Sorry for being so clear, but I feel strongly about mail: it's the last
> > means of communication left where I have the choice of client software,
> 
> Mostly true.  It does suffer from a terrible design w.r.t encryption, tho.
> 
> The other existing mediums (with a choice of clients) I'm aware of are
> XMPP and Matrix.

[...]

Thanks. I might live longer, then. No idea whether some might read that
as a menace ;-P

Cheers
-- t


signature.asc
Description: Digital signature

Re: Your Password Reset Link from CorrLinks

[James H. H. Lampert]

On 2/21/19, 8:27 AM, to...@tuxteam.de wrote:


Never received bounce spam aka backscatter spam? Remember that time
(perhaps 1-2 years ago) where this very list was plagued by an
especially evil form of backscatter involving the useful idiot at
the other end of some smartphone?


No question, I've definitely received it. Just as I've received phone 
calls from victims of phone-spam with same-prefix caller-ID spoofing 
(given that I know for a fact that there is nobody with the same prefix 
as my cell phone who has any business calling me on it, I treat all 
calls with my own prefix as either phone spam or attempts to call a 
spammer who spoofed my number).


But even when I had an ISP whose server-side spam filter allowed 
bouncing as an option, I used that option only when it was obvious the 
sender address was not spoofed.


--
JHHL

Re: Why /usr/sbin is not in my root $PATH ?

[Reco]

On Thu, Feb 21, 2019 at 11:26:29AM -0500, Greg Wooledge wrote:
> On Thu, Feb 21, 2019 at 04:14:53PM +, Jonathan de Boyne Pollard wrote:
> > You could point them to StackExchange in the meantime.  (-:
> > 
> > * https://unix.stackexchange.com/a/460769/5132
> 
> On that page:
> > Doing plain 'su' is a really bad idea for many reasons,
> 
> Name one!  Seriously, what kind of inane statement is that?

I have five reasons for you. They are called AIX, HP-UX, Solaris, RHEL
and busybox's su in no particular order.
It's not the first time Debian project chose to do exactly the same
others did for decades.


> > If you want to restore behaviour more similar to the previous one you can
> > add 'ALWAYS_SET_PATH yes' in /etc/login.defs.
> 
> OK, I'll just go to Debian's online man pages and find the buster
> man page for su (or login.defs) to find out what that is...
> 
> ... hey, where's the buster man pages?

Exactly there they belong. In .deb archives.

Reco

Re: Strange attacks in my log

[Reco]

Hi.

On Thu, Feb 21, 2019 at 05:29:56PM +0100, Hans wrote:
> Am Donnerstag, 21. Februar 2019, 16:46:42 CET schrieb Reco:
> Yes, worked. However, I did not find any unusual, however, putting a stick in 
> is starting "colord-sane", which will explain the UDP request.

Judging from the whopping 151 lines of the source of this colord-sane -
it cannot explain UDP.
Just a wild guess, though. Do you have HPLIP installed?

Oh, can I see the audit please? Unless it's private and all that.


> This does not explain, why a sd-card or usb-stick is calling this.

True.


> The only explanation I have, is that the kernel starts some module, which 
> acts 
> as watched. 

Nope. See, nor kernel itself nor its modules do not have SNMP
implementation. Kernel can send broadcasts if told to. Kernel can
receive an answer to these broadcasts.
But nothing in the kernel can talk or understand SNMP.
It definitely was some userspace program.


> I wonder, why no one else noticed this behaviour, as this looks a "normal" 
> behaviour on all systems.

How many people run portsentry?
How many actually watch for the packets that are outgoing from the host?

Reco

Re: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks]

[rhkramer]

On Thursday, February 21, 2019 09:01:04 AM Greg Wooledge wrote:
> (2) Mutt has a feature that lets you send an EXACT copy of a message to
> a different address, preserving all of the headers and content
> verbatim.  Mutt calls this "bouncing".

I'm just coming in from left field (without having kept up with the content or 
intent of the discussion), but:

I'm guessing that the behavior you describe can be mimic'ed in kmail by 
pressing T on a(n open) received email, changing the address, and then 
pressing send.

I guess what I haven't paid attention to is whether that is a useful behavior.

(Of course, I assume things like the time sent are changed in the headers, and 
presumably all the Received: headers (at the new recipient).)

> 
> It's different from "forwarding", which strips out all the headers and
> generates a whole new message with your own regular outgoing headers.
> 
> See the documentation at
>  and
> .

Re: Why /usr/sbin is not in my root $PATH ?

[Greg Wooledge]

Well, for those who are interested, I've added some information to
.  I'm trusting that the
ALWAYS_SET_PATH thing from that random web page was actually correct,
because verification would take a lot of work.  It's a wiki, so someone
else can correct it if it's wrong.

When I linked to EnvironmentVariables I also found a section at the
end of *that* page which describes the current behavior of su, so I
updated that page slightly as well.

I can't even begin to guess how many places assume the current su
behavior or how difficult it will be to find and change them all.

control the order of service initialization in the Debian 9

[Marcio Demetrio Bacci]

Hi,

I need to control the order of service initialization in my Debian 9 Server.

The problem is the following:

I beliave that my DRBD service don't start because the iscsi doesn't ready.
This way, I intend to change priority of DRBD initialization  to initialize
after iscsi service.

Where can I change the order of services initialization ?

Regards,

Márcio Bacci

Re: Why /usr/sbin is not in my root $PATH ?

[ghe]

On 2/21/19 10:15 AM, Reco wrote:

> It's not the first time Debian project chose to do exactly the same
> others did for decades.

Can you say Ptolemy? He (and his followers) did exactly the same he did
for centuries.

Another Busterism, BTW: ping now requires root privileges. It does on my
computer, anyway. Maybe I made a mistake when I installed -- somebody
sure did.

The idea of putting sbin, etc. (and looking at who has execute) in my
user path is becoming more and more attractive.

Who needs Unix? OS360 and msdos and CP/M did the job for decades...

-- 
Glenn English

Re: Why /usr/sbin is not in my root $PATH ?

[Reco]

Hi.

On Thu, Feb 21, 2019 at 11:12:12AM -0700, ghe wrote:
> Another Busterism, BTW: ping now requires root privileges. It does on
> my
> computer, anyway. Maybe I made a mistake when I installed -- somebody
> sure did.

Ping *always* required root, more precisely, CAP_NET_RAW.
So they either made ping root-owned suid, or assigned CAP_NET_RAW
capability to it (that's stretch btw):

$ /sbin/getcap /bin/ping
/bin/ping = cap_net_raw+ep

So, run /var/lib/dpkg/info/iputils-ping.postinst (or whatever iputils
alternative you have installed), and enjoy sanity restored.

Reco

Re: Why /usr/sbin is not in my root $PATH ?

[Reco]

Hi.

On Thu, Feb 21, 2019 at 11:12:12AM -0700, ghe wrote:
> Another Busterism, BTW: ping now requires root privileges. It does on
> my
> computer, anyway. Maybe I made a mistake when I installed -- somebody
> sure did.

Ping *always* required root, more precisely, CAP_NET_RAW.
So they either made ping root-owned suid, or assigned CAP_NET_RAW
capability to it (that's stretch btw):

$ /sbin/getcap /bin/ping
/bin/ping = cap_net_raw+ep

So, run "/var/lib/dpkg/info/iputils-ping.postinst configure" (or whatever 
iputils
alternative you have installed), and enjoy sanity restored.


PS I should watch who I'm replying to.

Reco

Re: control the order of service initialization in the Debian 9

[Reco]

Hi.

On Thu, Feb 21, 2019 at 03:10:44PM -0300, Marcio Demetrio Bacci wrote:
> Hi,
> 
> I need to control the order of service initialization in my Debian 9 Server.
> 
> The problem is the following:
> 
> I beliave that my DRBD service don't start because the iscsi doesn't ready.

Last time I've checked DRBD service did not start automatically at all.
Moreover, someone tried to be clever, and put the need of user
interaction into /etc/init.d/drbd in the form of "drbdadm
wait-con-int".
I admire the intention, but the result hardly usable if you do not have
an access to the console.

So, forcing iSCSI dependency may not do you any good.


> This way, I intend to change priority of DRBD initialization  to initialize
> after iscsi service.

See these lines at /etc/init.d/drbd?

# Required-Start: $local_fs $network $syslog
# Required-Stop:  $local_fs $network $syslog

Change them:

# Required-Start: $local_fs $network $syslog open-iscsi
# Required-Stop:  $local_fs $network $syslog open-iscsi

And invoke "systemctl daemon-reload".

Reco

Re: Why /usr/sbin is not in my root $PATH ?

[ghe]

On 2/21/19 11:18 AM, Reco wrote:

> Ping *always* required root, 

Maybe, but I didn't know that. I've been on Debian since the days of the
major Toy Story characters, and I've always just typed 'ping' and it punged.

But thanks, somebodyAtDebian, for correcting my decades old expectation.

-- 
Glenn English

Re: Why /usr/sbin is not in my root $PATH ?

[Greg Wooledge]

On Thu, Feb 21, 2019 at 11:36:44AM -0700, ghe wrote:
> On 2/21/19 11:18 AM, Reco wrote:
> 
> > Ping *always* required root, 
> 
> Maybe, but I didn't know that. I've been on Debian since the days of the
> major Toy Story characters, and I've always just typed 'ping' and it punged.
> 
> But thanks, somebodyAtDebian, for correcting my decades old expectation.

You might be confused here.  The ping program is intended to *work* for
all users, but in order to work, it needs a special capability.
Traditionally the ping program acquired this capability by being installed
with the setuid bit.  In more recent releases of Debian, /bin/ping is
no longer setuid, and instead uses the Linux capabilities feature
for its special power-up.

 is the
first link I found which explains this.  Seems like the right level of
exposition for this thread.

It's possible that somehow you removed your /bin/ping and restored it from
a backup, but you didn't re-run the thing that gives it the special
capabilities it needs.  Or, who knows, maybe something else happened.

Re: Why /usr/sbin is not in my root $PATH ?

[ghe]

On 2/21/19 11:50 AM, Greg Wooledge wrote:

> It's possible that somehow you removed your /bin/ping and restored it from
> a backup, but you didn't re-run the thing that gives it the special
> capabilities it needs.  

Don't think so. Just a vanilla netinstall. Like always. I think.

> Or, who knows, maybe something else happened.

Something did :-) The shell, or something, talks about socket not being
accessible. Certainly reasonable/believable.

Thanks -- will fix...

-- 
Glenn English

Re: Why /usr/sbin is not in my root $PATH ?

[Ric Moore]

On 2/21/19 1:36 PM, ghe wrote:

On 2/21/19 11:18 AM, Reco wrote:


Ping *always* required root,


Maybe, but I didn't know that. I've been on Debian since the days of the
major Toy Story characters, and I've always just typed 'ping' and it punged.


I just typed "ping redhat.com", as user, and it pinged. But I couldn't 
get it to "pung". :) Ric

Running Debian on an AMD Ryzen system

[Sam Varghese]

I would value feedback from anyone on this list who has been running
Debian on an AMD Ryzen system. I have gone back through list posts for a
year and cannot find anything on this subject.

I am running the testing stream and am looking to upgrade a 10-year-old PC
which I use for work. Having had good experiences with AMD processors in
the past - my current box has a K6-2 chip - I would prefer to go with a
processor from the same company.

If anyone does respond, could you please copy me in? I am not subscribed
to the list.

Thanks,
Sam
--
(Sam Varghese)

Re: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks]

[David Wright]

On Thu 21 Feb 2019 at 16:32:18 (+0300), Reco wrote:
> On Thu, Feb 21, 2019 at 08:21:00AM -0500, Gene Heskett wrote:
> > On Thursday 21 February 2019 03:59:37 to...@tuxteam.de wrote:
> > > On Thu, Feb 21, 2019 at 11:45:50AM +0300, Reco wrote:
> > >
> > > [...]
> > >
> > > > You can also help us by bouncing (as in mutt) spam to
> > > > report-lists...@lists.debian.org
> 
> > This _might_ be a good idea, if that address took forwards. My incoming 
> > chain does not include the ability to do other than accept, then divert 
> > to /var/mail/virii or /dev/null. But my one attempt to forward to that 
> > address when debians poor spam/viri filters failed often enough to get 
> > my attention several years ago, resulted in its being bounced back to me
> 
> There's a difference between 'Forward' and 'Bounce'. That e-mail is for 
> bounces.
> 
> > Don't give me, or my current ISP a hard time because their spam filtering 
> > is far better ...  using barracuda
> 
> LOL. Did you mean *this* Barracuda - [1]?
> The thing's a best possible example of how you *do not* filter spam
> *ever*.

My mail hosting service uses that, and I think they might have
overreacted to its past (and present?) woes. They filter mail
*from* me between their mail submission host and their gateway
host (which sends it out to the Internet). Recently it has
sometimes taken a couple of days for random emails to make
that passage, and in several instances, emails got stuck.
When I complained about non-delivery, they sent me a listing
showing them sitting in a queue, "Blocked".

Now, if they are refusing to send them out, the service should
be sending them back to me as a rejection with reasons, but
I guess they're afraid of bouncing them at all. They know they
came from me, they host my domain, and they know the emails are
legitimate because they just authenticated the submission.
But they just throw their hands in the air, saying "We didn't
write the rules, we have no control over them."

> [1] http://www.dontbouncespam.org/

BTW I got an email only the other day from this outfit (corr),
asking me if I would become a "friend of a convict". As it was
sent to my deblis address, they had presumably harvested it.
I would have examined it more closely had this item arrived
earlier. The outfit looks relatively local on the scale of
this place (IA).

Cheers,
David.

Re: Running Debian on an AMD Ryzen system

[Dan Ritter]

Sam Varghese wrote: 
> I would value feedback from anyone on this list who has been running
> Debian on an AMD Ryzen system. I have gone back through list posts for a
> year and cannot find anything on this subject.
> 
> I am running the testing stream and am looking to upgrade a 10-year-old PC
> which I use for work. Having had good experiences with AMD processors in
> the past - my current box has a K6-2 chip - I would prefer to go with a
> processor from the same company.
> 
> If anyone does respond, could you please copy me in? I am not subscribed
> to the list.

I have installed Debian on several Ryzen machines. No particular
problems, unless you are using the built-in graphics systems, in
which case you may need to get X11 via stretch-backports.

What are you concerned about?

-dsr-

Re: Running Debian on an AMD Ryzen system

[Sam Varghese]

On Fri, February 22, 2019 7:46 am, Dan Ritter wrote:
> Sam Varghese wrote:
>> I would value feedback from anyone on this list who has been running
>> Debian on an AMD Ryzen system. I have gone back through list posts for a
>> year and cannot find anything on this subject.
>>
>> I am running the testing stream and am looking to upgrade a 10-year-old
>> PC
>> which I use for work. Having had good experiences with AMD processors in
>> the past - my current box has a K6-2 chip - I would prefer to go with a
>> processor from the same company.
>>
>> If anyone does respond, could you please copy me in? I am not subscribed
>> to the list.
>
> I have installed Debian on several Ryzen machines. No particular
> problems, unless you are using the built-in graphics systems, in
> which case you may need to get X11 via stretch-backports.
>
> What are you concerned about?

Thanks for your response, Dan.

I have seen some older reports about kernel issues and crashes. Hence my
concern.

I presume that the built-in graphics system can be disabled from the BIOS
(or UEFI) and a stock standard graphics card used instead. Would I be
correct in assuming that?

Please copy me in as I am not subscribed to the list.

Thanks,
Sam

Re: Running Debian on an AMD Ryzen system

[Dan Ritter]

Sam Varghese wrote: 
> 
> On Fri, February 22, 2019 7:46 am, Dan Ritter wrote:
> > What are you concerned about?
> 
> Thanks for your response, Dan.
> 
> I have seen some older reports about kernel issues and crashes. Hence my
> concern.

I haven't seen any while running Stretch or later.


> I presume that the built-in graphics system can be disabled from the BIOS
> (or UEFI) and a stock standard graphics card used instead. Would I be
> correct in assuming that?

For desktops, yes. My son is using a Ryzen 2300U laptop, and the
stretch-backports amdgpu X11 system works well for him. His last
remaining issue is that the touchscreen isn't working, which is
not a Ryzen issue.

Ryzen (and ThreadRipper)_chips without a G or U suffix have no
built-in graphics anyway, so it's not an issue unless you're
buying one of those.

-dsr-

Re: Running Debian on an AMD Ryzen system

[Sam Varghese]

On Fri, February 22, 2019 8:11 am, Dan Ritter wrote:
> Sam Varghese wrote:

>> I have seen some older reports about kernel issues and crashes. Hence my
>> concern.
>
> I haven't seen any while running Stretch or later.

>> I presume that the built-in graphics system can be disabled from the
>> BIOS
>> (or UEFI) and a stock standard graphics card used instead. Would I be
>> correct in assuming that?

> For desktops, yes. My son is using a Ryzen 2300U laptop, and the
> stretch-backports amdgpu X11 system works well for him. His last
> remaining issue is that the touchscreen isn't working, which is
> not a Ryzen issue.
>
> Ryzen (and ThreadRipper)_chips without a G or U suffix have no
> built-in graphics anyway, so it's not an issue unless you're
> buying one of those.

Thanks a lot for your input, Dan. Much appreciated.

Sam

Re: Running Debian on an AMD Ryzen system

[Étienne Mollier]

Sam Varghese wrote:
> I have seen some older reports about kernel issues and crashes. Hence my
> concern.

Good Day,

You were probably referring to CPU idle states bugs appearing
under certain circumstances.

I have been confronted to an AMD Ryzen machine a few months ago,
on which processor C-states had to be disabled in UEFI config,
meaning increased energy consumption when idling.  The problem
was similar to the one described on Chris's wiki:

https://utcc.utoronto.ca/~cks/space/blog/linux/RyzenMachineLinuxHangs
https://utcc.utoronto.ca/~cks/space/blog/linux/RyzenApparentlyStable

It has been a while since the last time I checked those AGESA
updates for the motherboard, and am not sure if the problem
would still hold true with latest kernel/firmware upgrades/etc
though.

Kind Regards,
-- 
Étienne Mollier 

All opinions are my own.

Re: Running Debian on an AMD Ryzen system

[Michael Stone]

On Fri, Feb 22, 2019 at 07:20:52AM +1100, Sam Varghese wrote:

I would value feedback from anyone on this list who has been running
Debian on an AMD Ryzen system. I have gone back through list posts for a
year and cannot find anything on this subject.

I am running the testing stream and am looking to upgrade a 10-year-old PC
which I use for work. Having had good experiences with AMD processors in
the past - my current box has a K6-2 chip - I would prefer to go with a
processor from the same company.

If anyone does respond, could you please copy me in? I am not subscribed
to the list.


I've been using a Ryzen as my primary desktop for a while. There's 
nothing particularly noteworthy in doing so, which is probably why 
you're not seeing much. As usual with modern CPUs, get the latest 
firmware update available for your motherboard--which will include 
updates that affect the performance & stability of the CPU itself to a 
much greater extent than in the k6-2 days.

Debian package missing

[Damon Bakker]

Hi there,


I'd like to notify that

http://security-cdn.debian.org/dists/jessie/updates/main/binary-amd64/Packages

is now missing. It is used in the pipelines of bitbucket and now it seems 
they're broken.

Re: control the order of service initialization in the Debian 9

[Marcio Demetrio Bacci]

Thank you for help me, but my problem persists.


I have already changed my file /etc/init.d/drbd

This is my /etc/init.d/drbd

#!/bin/bash
#
# chkconfig: - 70 08
# description: Loads and unloads the drbd module
#
# Copyright 2001-2013 LINBIT
#
# Philipp Reisner, Lars Ellenberg
#
### BEGIN INIT INFO
# Provides: drbd
# Required-Start: $local_fs $network $syslog open-iscsi
# Required-Stop:  $local_fs $network $syslog open-iscsi
# Should-Start:   sshd multipathd
# Should-Stop:sshd multipathd
# Default-Start:  2 3 4 5
# Default-Stop:   0 1 6
# X-Start-Before: heartbeat corosync
# X-Stop-After:   heartbeat corosync
# X-Interactive:  true
# Short-Description:Control DRBD resources.
# Description:Control all DRBD resources.
#   You SHOULD NOT enable this init script
#   when using a cluster manager such as Pacemaker.
#   Start will try to:
# load the DRBD driver module,
# configure (bring up as Secondary) all DRBD resources as described
in
# the config file, and promote those resources where the
# "become-primary-on" config statement matches.
#   Stop will try to:
# demote and unconfigure all DRBD resources described in the config
# file, and remove the module.
### END INIT INFO

DEFAULTFILE="/etc/default/drbd"
DRBDADM="drbdadm"
DRBDSETUP="drbdsetup"
PROC_DRBD="/proc/drbd"
MODPROBE="/sbin/modprobe"
RMMOD="/sbin/rmmod"
UDEV_TIMEOUT=10
ADD_MOD_PARAM=""

PATH=/sbin:/bin

if [ -f $DEFAULTFILE ]; then
  . $DEFAULTFILE
fi

# we only use these two functions, define fallback versions of them ...
log_daemon_msg() { echo -n "${1:-}: ${2:-}"; }
log_end_msg() { echo "."; }
# ... and let the lsb override them, if it thinks it knows better.
if [ -f /lib/lsb/init-functions ]; then
. /lib/lsb/init-functions
fi

assure_module_is_loaded()
{
[ -e "$PROC_DRBD" ] && return

$MODPROBE -s drbd $ADD_MOD_PARAM || {
echo "Can not load the drbd module."$'\n'
exit 5 # LSB for "not installed"
}
# tell klogd to reload module symbol information ...
[ -e /var/run/klogd.pid ] && [ -x /sbin/klogd ] && /sbin/klogd -i
}

drbd_pretty_status()
{
local proc_drbd=$1
# add resource names
if ! type column &> /dev/null ||
   ! type paste &> /dev/null ||
   ! type join &> /dev/null ||
   ! type sed &> /dev/null ||
   ! type tr &> /dev/null
then
cat "$proc_drbd"
return
fi
sed -e '2q' < "$proc_drbd"
sed_script=$(
i=0;
_sh_status_process() {
let i++ ;

stacked=${_stacked_on:+"^^${_stacked_on_minor:-${_stacked_on//[!a-zA-Z0-9_
-]/_}}"}
printf "s|^ *%u:|%6u\t&%s%s|\n" \
$_minor $i \
"${_res_name//[!a-zA-Z0-9_ -]/_}" "$stacked"
};
eval "$(drbdadm sh-status)" )

p() {
sed -e "1,2d" \
  -e "$sed_script" \
  -e '/^ *[0-9]\+: cs:Unconfigured/d;' \
  -e 's/^\(.* cs:.*[^ ]\)   \([rs]...\)$/\1 - \2/g' \
  -e 's/^\(.* \)cs:\([^ ]* \)st:\([^ ]* \)ds:\([^
]*\)/\1\2\3\4/' \
  -e 's/^\(.* \)cs:\([^ ]* \)ro:\([^ ]* \)ds:\([^
]*\)/\1\2\3\4/' \
  -e 's/^\(.* \)cs:\([^ ]*\)$/\1\2/' \
  -e 's/^ *[0-9]\+:/ x &??not-found??/;' \
  -e '/^$/d;/ns:.*nr:.*dw:/d;/resync:/d;/act_log:/d;' \
  -e 's/^\(.\[.*\)\(sync.ed:\)/... ...
\2/;/^.finish:/d;' \
  -e 's/^\(.[0-9 %]*oos:\)/... ... \1/' \
  < "$proc_drbd" | tr -s '\t ' '  '
}
m() {
join -1 2 -2 1 -o 1.1,2.2,2.3 \
<( ( drbdadm sh-dev all ; drbdadm -S sh-dev all ) |
cat -n | sort -k2,2) \
<(sort < /proc/mounts ) |
sort -n | tr -s '\t ' '  ' | sed -e 's/^ *//'
}
# echo "=== p ==="
# p
# echo "=== m ==="
# m
# echo "="
# join -a1 <(p|sort) <(m|sort)
# echo "="
(
echo m:res cs ro ds p mounted fstype
join -a1 <(p|sort) <(m|sort) | cut -d' ' -f2-6,8- | sort -k1,1n
-k2,2
) | column -t
}

# Try to settle regardless of udev version or presence,
# so "/etc/init.d/drbd stop" is able to rmmod, without interfering
# temporary module references caused by udev scanning the devices.
# But don't wait too long.
_udev_settle()
{
if udevadm version ; then
# ok, we have udevadm, use it.
udevadm settle --timeout=5
else
# if udevsettle is not there,
# no matter.
udevsettle --timeout=5
fi
}

run_hook()
{
n="hook_$1"
if t=$(type -t "$n") && [[ "$t" == "function" ]] ; then

Problems upgrading grub-pc

[Brad Rogers]

Hello,

Today, upgrading a testing install at the end of which report was
"setting up grub-pc"  The problem is that it just sat there, and didn't
complete.  Attempts to correct the problem with;
 '# dpkg --configure grub-pc'
also failed to complete the update.

Downgrading to the previous version didn't help, that too just sits
there failing to complete.

Anybody else seeing this?

If anybody has a solution, I'd love to know what it is, as my searches
failed to get me anywhere.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
I guess I shouldn't have strangled her to death
Ugly - The Stranglers


pgpqCHtX0MlYy.pgp
Description: OpenPGP digital signature

Quick pointer please? Installing Intel wireless, post OS installation

[deb]

So, I punched on to install Debian 9.7 onto the Intel NUC

(https://www.provantage.com/intel-boxnuc7i7bnh~7ITSP1CM.htm)

bypassing the wireless part, as I was still stuck on it asking for 
iwlwifi-8265-26.ucode, iwlwifi-8265-25.ucode, iwlwifi-8265-24.ucode,  
iwlwifi-8265-23.ucode


in the networking section. (Those .ucode files do not exist as far as 
we've seen).



So I have a running Debian now, but no internet connection either.

(No immediate Ethernet access).


If I now want to attempt the Intel wireless setup/install,

using the iwlwifi-8265-22.ucode that it also asked for

where do I do this at | from?

Any starter pointers?

*
*

*Is it just do this?*

*| then install the **|firmware-iwlwifi|**package using your favorite 
package management utility, then reboot and the driver should be 
auto-loaded and ready for use.*


found here

https://www.startpage.com/do/dsearch?query=install+nuc+wireless+post+installation+debian&cat=web&pl=opensearch&language=english

Re: Quick pointer please? Installing Intel wireless, post OS installation

[deb]

On 2/21/2019 7:12 PM, deb wrote:



So, I punched on to install Debian 9.7 onto the Intel NUC

(https://www.provantage.com/intel-boxnuc7i7bnh~7ITSP1CM.htm)

bypassing the wireless part, as I was still stuck on it asking for 
iwlwifi-8265-26.ucode, iwlwifi-8265-25.ucode, iwlwifi-8265-24.ucode,  
iwlwifi-8265-23.ucode


in the networking section. (Those .ucode files do not exist as far as 
we've seen).



So I have a running Debian now, but no internet connection either.

(No immediate Ethernet access).


If I now want to attempt the Intel wireless setup/install,

using the iwlwifi-8265-22.ucode that it also asked for

where do I do this at | from?

Any starter pointers?

*
*

*Is it just do this?*

*| then install the **|firmware-iwlwifi|**package using your favorite 
package management utility, then reboot and the driver should be 
auto-loaded and ready for use.*


found here

https://www.startpage.com/do/dsearch?query=install+nuc+wireless+post+installation+debian&cat=web&pl=opensearch&language=english 






... and I'll have the iwlwifi-8265-22.ucode and iwlwifi-8265-21.ucode in 
a /lib/firmware folder on a USB drive to pull from, whilst synaptics-ing.

[Solved] Re: Problems upgrading grub-pc

[Brad Rogers]

On Thu, 21 Feb 2019 23:27:04 +
Brad Rogers  wrote:

Hello,

>Today, upgrading a testing install at the end of which report was
>"setting up grub-pc"  The problem is that it just sat there, and didn't
>complete.  Attempts to correct the problem with;

Well, in exasperation, and with a sense of trepidation, I rebooted the
system.  Exasperation, because I'd run out of ideas and clues.
Trepidation, because I had no idea whether the machine would reboot
successfully.  All went well, thankfully.

I then retried the upgrade and that proceeded without errors.  I have no
idea what was wrong, but clearly it was a transient issue.

So, problem overcome.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Stained glass windows keep the cold outside
Religion - Public Image Ltd


pgpBCCYMAWrf1.pgp
Description: OpenPGP digital signature

Re: Running Debian on an AMD Ryzen system

[Felix Miata]

Sam Varghese composed on 2019-02-22 07:20 (UTC+1100):

> I would value feedback from anyone on this list who has been running
> Debian on an AMD Ryzen system. I have gone back through list posts for a
> year and cannot find anything on this subject.

(IMO, as one who has not purchased any new AMD products in over a decade)

Debian is a Gnu/Linux distribution. Distributions package FOSS software created 
by loads of
upstream projects. Thus, limiting your search to Debian (or this support list) 
risks missing
problems that Debian users simply haven't reported but might be discovered 
without the limiting
search terms.

It is common knowledge that buying hardware that is younger than 6-9 months 
before a stable
distribution's release is fraught with various dangers to those wishing simply 
to get work done
with a new PC. It takes time for FOSS development to catch up with new hardware.

"Ryzen" was initially released roughly 4 months before the original release of 
current Debian
Stable (9.0, Stretch) in June 2017, which translated to a fairly high prospect 
of various types of
missing functionality or defects in support of Ryzen products. Stable releases 
are primarily
subject to defect repairs, not feature (support) additions. The dot releases 
that follow the
original 9.0 do violate that general principle only to some extent.

Ryzen is a family name comprised of several generations. Since initial Ryzen 
release there have
been at least 3 newer generations. Effectively, "Ryzen" as a generic term is 
newer than Stable.
Thus, careful shopping is warranted to ensure you aren't buying hardware that 
won't be adequately
supported at time of purchase.

Having seen numerous complaints recently about latest "Ryzen" products in 
various forums, I highly
recommend digesting https://en.wikipedia.org/wiki/Ryzen or equivalent before 
searching using Debian
as a limiting term, else your choice may force you to use Testing/Buster or 
some other more recent
distribution instead of Stable/Stretch.
-- 
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: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks]

[Celejar]

On Thu, 21 Feb 2019 08:40:28 -0500
Gene Heskett  wrote:

> On Thursday 21 February 2019 08:25:54 Greg Wooledge wrote:
> 
> > On Thu, Feb 21, 2019 at 08:21:00AM -0500, Gene Heskett wrote:
> > > > On Thu, Feb 21, 2019 at 11:45:50AM +0300, Reco wrote:
> > > > [...]
> > > >
> > > > > You can also help us by bouncing (as in mutt) spam to
> > > > > report-lists...@lists.debian.org
> > >
> > > This _might_ be a good idea, if that address took forwards.
> >
> > Forwarding and bouncing are completely different operations.  If you
> > aren't using mutt/neomutt and don't have a literal bounce feature,
> > then please just ignore this part.
> 
> I am not using mutt. TDE version of kmail. And I'd point out that the 
> threat of a list unsubscribe is blamed on a "bounce". That specific 
> word.
> 
> And as far as I know, fetchmail has no ability/facility to bounce a 
> message. Fetchmail-6.3.26 IIRC. Locally built from tarball.

'Bouncing' a message is typically done by a MUA (Kmail, in your case),
not the MDA (fetchmail, in your case). Other MUAs besides mutt/neomutt
do have 'bounce' options (although they may not always be called that),
e.g., in Sylpheed, it's Message -> Redirect.

Celejar

Re: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks]

[Gene Heskett]

On Thursday 21 February 2019 09:59:53 Celejar wrote:

> On Thu, 21 Feb 2019 08:40:28 -0500
>
> Gene Heskett  wrote:
> > On Thursday 21 February 2019 08:25:54 Greg Wooledge wrote:
> > > On Thu, Feb 21, 2019 at 08:21:00AM -0500, Gene Heskett wrote:
> > > > > On Thu, Feb 21, 2019 at 11:45:50AM +0300, Reco wrote:
> > > > > [...]
> > > > >
> > > > > > You can also help us by bouncing (as in mutt) spam to
> > > > > > report-lists...@lists.debian.org
> > > >
> > > > This _might_ be a good idea, if that address took forwards.
> > >
> > > Forwarding and bouncing are completely different operations.  If
> > > you aren't using mutt/neomutt and don't have a literal bounce
> > > feature, then please just ignore this part.
> >
> > I am not using mutt. TDE version of kmail. And I'd point out that
> > the threat of a list unsubscribe is blamed on a "bounce". That
> > specific word.
> >
> > And as far as I know, fetchmail has no ability/facility to bounce a
> > message. Fetchmail-6.3.26 IIRC. Locally built from tarball.
>
> 'Bouncing' a message is typically done by a MUA (Kmail, in your case),
> not the MDA (fetchmail, in your case). Other MUAs besides mutt/neomutt
> do have 'bounce' options (although they may not always be called
> that), e.g., in Sylpheed, it's Message -> Redirect.
>
> Celejar

kmail has that. I should learn to use it, at least once/

Thanks.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: What to do about spam in debian-user [was: Your Password Reset Link from CorrLinks]

[Gene Heskett]

On Thursday 21 February 2019 11:20:52 to...@tuxteam.de wrote:

> On Thu, Feb 21, 2019 at 08:21:00AM -0500, Gene Heskett wrote:
> > On Thursday 21 February 2019 03:59:37 to...@tuxteam.de wrote:
> > > On Thu, Feb 21, 2019 at 11:45:50AM +0300, Reco wrote:
> > >
> > > [...]
> > >
> > > > You can also help us by bouncing (as in mutt) spam to
> > > > report-lists...@lists.debian.org
> > >
> > > Thanks
> > > -- t
> >
> > This _might_ be a good idea, if that address took forwards. My
> > incoming chain does not include the ability to do other than accept,
> > then divert to /var/mail/virii or /dev/null. But my one attempt to
> > forward to that address when debians poor spam/viri filters failed
> > often enough to get my attention several years ago, resulted in its
> > being bounced back to me
>
> I do it all the time (perhaps twice a week). No problems so far.
>
> > Don't give me, or my current ISP a hard time because their spam
> > filtering is far better then debians.
>
> This only shows that you still have much to learn about spam :-)
>
> Filtering for an open list with roughly 600 subscribers is far more
> difficult than filtering for one person, since the breadth of topics
> and styles for non-spam is significantly higher. This is a real
> challenge for statistical filters.
>
> I think that, given the constraints, Debian list spam filters aren't
> bad.
>
>   "The Debian Listmasters do their best to stop as many such
>emails as possible from reaching the lists. On a typical day,
>over 40,000 such messages are blocked." [1]
>
> > I get very little spam from them because they do active bouncing,
> > using barracuda I believe,
>
> *spit*
>
> A couple of times I had the "honor". Dunno whether it was a bad
> sysadmin or barracuda itself. Not a nice souvenir, mind you.
>
> [...]
>
> > But if all it generates is bounces, why bother? That just serves to
> > prove to me that debian has zero interest in containing UCE. Since I
> > don't set the rules, or write the checks for debian, that just how
> > it is.
>
> See above. If you go to the below reference, you even get to
> propose SpamAssassin rules to the Debian list masters. I'm
> sure they can use some help. They're volunteers, after all.
>
> Saying they have "zero interest" (even if they not only do the
> heavy lifting of filtering out 40K spams /a day/, but also document
> what they are doing, for your and my reading convenience, all at
> no cost, on a volunteer basis) is offensive.
>
> > But redirecting the blame to me or my ISP because debians filtering
> > is poor [...]
>
> Repeat with me:
>  - you don't bounce spam at all, because you're bouncing to
>the wrong address anyway, thus just enhancing the problem.
>
Spam should be sent to /dev/null.  I've no argument with that at all.

>(There is still a reason to bounce a (legitimate) mail,
>but NEVER-EVER when you think it's spam).
>
>  - you don't reject to mailing lists: they'll conclude that
>you have delivery problems and unsubscribe you.

Tell that to Shentel.net, I gotten hoarse just trying to make them let 
fetchmail nuke what its pulled. But too many dummies use the same via 
imap, and get pissed when their message disappears, so us fetchmail 
users take it on the chin by being forced to login in with a browser 
daily and cleaning house.

> This is common consensus, and for a reason. If your provider isn't
> doing that, they ain't pros and are just pissing in our common well.
>
> Sorry for being so clear, but I feel strongly about mail: it's the
> last means of communication left where I have the choice of client
> software, the other stuff being "antisocial networks", where some
> random web designer gets to decide what I see and how. I hope I die
> before this dystopia is upon us (I'm old, mind you).

So am I tomas, currently 84 TBE.
>
> Cheers
>
> [1] https://www.debian.org/MailingLists/#ads
> -- tomás


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Running Debian on an AMD Ryzen system

[tv.deb...@googlemail.com]

On 22/02/2019 03:50, Étienne Mollier wrote:

Sam Varghese wrote:

I have seen some older reports about kernel issues and crashes. Hence my
concern.


Good Day,

You were probably referring to CPU idle states bugs appearing
under certain circumstances.

I have been confronted to an AMD Ryzen machine a few months ago,
on which processor C-states had to be disabled in UEFI config,
meaning increased energy consumption when idling.  The problem
was similar to the one described on Chris's wiki:

https://utcc.utoronto.ca/~cks/space/blog/linux/RyzenMachineLinuxHangs
https://utcc.utoronto.ca/~cks/space/blog/linux/RyzenApparentlyStable

It has been a while since the last time I checked those AGESA
updates for the motherboard, and am not sure if the problem
would still hold true with latest kernel/firmware upgrades/etc
though.

Kind Regards,



Hi, I bought ryzen CPUs from the very first weeks they were available in 
Europe, the first batch I got were all defective, the 1700s would hang 
anytime they were left idling without disabling C6 management in bios. 
The 1800Xs were also exhibiting this bug, but with a second one on top 
under heavy compilation load, GCC would throw random errors and the 
compilation would fail. There was various workarounds that allowed me to 
use the CPUs while progressively returning them to the manufacturer for 
exchange. All affected CPUs were made during the very first weeks of 
manufacturing, after that AMD fixed the problem and all newer chips were 
fine.
I currently have a mix of ryzen 5s, a few 1700 and 1800X left that are 
not affected by any bugs and run perfectly, and newer 2xxx second gen 
CPUs that I never had any problem with.


Unless you buy second hand from unscrupulous people or get a dusty batch 
or first week first gen chips, you will not be affected by those 
problems. In any case AMD did their part and the RMA process after 
confirming the problem with them was good.


I have no experience with their integrated graphics, I use discrete 
Radeon GPUs, but for the CPU part I am really happy with the 
cost/performance ratio. Especially for 3D modeling/rendering and video 
they work great, software compilation is one of their strong point too, 
anything heavily multi-threaded really.


My two sons play on ryzens too and they don't complain, associated with 
a decent GPU they run common "big" titles on Steam Linux or standalone. 
Again the cost/performance ratio seems very good to me.


Look at the motherboards you could be interested in too and chipset 
features, it's important to consider full system price rather than just CPU.


Hope it helps.

Re: control the order of service initialization in the Debian 9

[Reco]

Hi.

On Thu, Feb 21, 2019 at 07:53:11PM -0300, Marcio Demetrio Bacci wrote:
> Thank you for help me, but my problem persists.

Yup. Just as planned.


> I have already changed my file /etc/init.d/drbd
> 
...
> run_hook start_before-wait
> $DRBDADM wait-con-int # User interruptible version of wait-connect
> all
...

This funny snippet forces init script to wait for partner nodes *or* for
the user interaction.
Works as intended for sysvinit, but systemd relocates all this user
interaction to the console.

And since the script does not get any interaction - systemd kills
appropriate unit for timing out:

> Feb 21 19:39:32 bkp systemd[1]: dev-drbd0.device: Job
> dev-drbd0.device/start timed out.


Personally I change the offending line to:

/usr/bin/timeout 120 $DRBDADM wait-con-int || true
# User interruptible version of wait-connect all

But that's hackish approach at best.

Reco

stracing login process with systemd?

[Eduard Bloch]

Dear Lazynet,

I have some trouble with one desktop system running Sid. After some
updates a couple of weeks ago, user programs started to fail, like
pulseaudio no longer running or "systemctl suspend" not working.

After little investigation I have found out that "systemd --user"
process is not working which is supposed to run user-specific services.

Which is probably somethign that libpam-systemd should have invoked -
that was the best guess I could extract from the documentation (the
manpage of systemd is AFAICS NOT telling you who/what is supposed to
start the user systemd).

I had some exchange with the maintainer in the BTS but so far that's not
really fruitful. I would like to just strace the whole login process
(console or xdm) and check what's happening there around systemd
invocation, and what's failing.

Does anyone know how to insert strace or any similar tracing utility?

I can imagine that one could try to use kernel tracing here but that
would be a huge hammer.

Thanks,
Eduard.

-- 
Every great idea is worthless without someone to do the work. --Neil Williams