Re: X server does not start after upgrading to Debian 10

[Felix Miata]

Felix Miata composed on 2019-07-08 23:21 (UTC-0400):

> ISTR your experience is known to upstream, but I get lost trying to
> find anything I want in their tracking systems. :-P

https://gitlab.freedesktop.org/xorg/xserver/issues/542 might be what I was
thinking of.
-- 
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: X server does not start after upgrading to Debian 10

[Felix Miata]

Teemu Likonen composed on 2019-07-07 15:13 (UTC+0300):

> Solved. The X server chooses automatically some wrong graphics module
> ("modeset" I guess). If I force it to use "intel" module the X server
> works again. 
The Intel DDX hasn't had an official release since five years ago:
https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/

Intel pays its driver writers to focus on the modesetting DDX. I only use the
modesetting DDX on Intel Graphics new enough for modesetting DDX support:

# inxi -GxxS
System:Host: ab250 Kernel: 4.19.0-5-amd64 x86_64 bits: 64 compiler: gcc v: 
8.3.0 Desktop: Trinity R14.0.7 tk: Qt 3.5.0 
   wm: Twin dm: TDM Distro: Debian GNU/Linux 10 (buster) 
Graphics:  Device-1: Intel HD Graphics 630 vendor: ASUSTeK driver: i915 v: 
kernel bus ID: 00:02.0 chip ID: 8086:5912 
   Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: 
fbdev,vesa resolution: 2560x1440~60Hz 
   OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (Kaby Lake GT2) v: 
4.5 Mesa 18.3.6 compat-v: 3.0 
   direct render: Yes 

# inxi -GxxS
System:Host: gx780 Kernel: 4.19.0-5-amd64 x86_64 bits: 64 compiler: gcc v: 
8.3.0 Desktop: Trinity R14.0.7 
   tk: Qt 3.5.0 wm: Twin dm: TDM Distro: Debian GNU/Linux 10 (buster) 
Graphics:  Device-1: Intel 4 Series Integrated Graphics vendor: Dell driver: 
i915 v: kernel bus ID: 00:02.0 
   chip ID: 8086:2e12 
   Display: x11 server: X.Org 1.20.4 driver: modesetting resolution: 
1920x1200~60Hz 
   OpenGL: renderer: Mesa DRI Intel Q45/Q43 v: 2.1 Mesa 18.3.6 direct 
render: Yes 

# inxi -GxxS
System:Host: 00srv Kernel: 4.12.14-lp151.28.7-default x86_64 bits: 64 
compiler: gcc v: 7.4.0 Console: tty 0 wm: kwin
   dm: N/A Distro: openSUSE Leap 15.1
Graphics:  Device-1: Intel 4th Generation Core Processor Family Integrated 
Graphics vendor: Micro-Star MSI driver: i915
   v: kernel bus ID: 00:02.0 chip ID: 8086:041e
   Display: server: X.Org 1.20.3 driver: modesetting unloaded: 
fbdev,vesa alternate: intel resolution: 1920x1200~60Hz
   OpenGL: renderer: Mesa DRI Intel Haswell v: 4.5 Mesa 18.3.2 
compat-v: 3.0 direct render: Yes

# inxi -GxxS
System:Host: big41 Kernel: 4.19.0-5-amd64 x86_64 bits: 64 compiler: gcc v: 
8.3.0 Desktop: Trinity R14.0.7 
   tk: Qt 3.5.0 wm: Twin dm: TDM Distro: Debian GNU/Linux 10 (buster) 
Graphics:  Device-1: Intel 4 Series Integrated Graphics vendor: Biostar 
Microtech Intl Corp driver: i915 v: kernel 
   bus ID: 00:02.0 chip ID: 8086:2e32 
   Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: 
fbdev,vesa resolution: 1920x1200~60Hz 
   OpenGL: renderer: Mesa DRI Intel G41 v: 2.1 Mesa 18.3.6 direct 
render: Yes 

Your need for the deprecated DDX must be specific to your particular
GPU. The one you have ought to be specified in your bug report. The
report might get quicker traction if you announce it to the Intel
developers on their mailing list:
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
https://01.org/linuxgraphics/documentation/how-report-bugs shows the
information they want to see in reports, and where to report.

ISTR your experience is known to upstream, but I get lost trying to
find anything I want in their tracking systems. :-P
-- 
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: Check your signing key expiration dates!

[Nate Bargmann]

* On 2019 08 Jul 04:01 -0500, Brad Rogers wrote:
> Just updated it here, and there were changes, 16 signatures cleaned, but
> nothing other than that.  However, I know the last key refresh I did was
> a few months ago.  With the DoS attack, I'm not likely to be refreshing
> keys wholesale any more, even with "keyserver-options import-clean" in
> my gpg.conf.

I may just be pedant here, but I found the current manual page for gpg
in Buster shows that 'import-clean' is a value for the 'import-options'
key.  I had it paired with the 'keyserver-options' and it seemed to work
there too.

For updates I am now using the parcimonie package to update keys over
TOR.  It's an interesting thing.

- 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

OTRS

[Leonardo S. S. da Rocha]

Olá pessoal, boa noite!

estou tendo um probleminha com OTRS sobre máquinas com Debian. Temos
(um grupo de pesquisa na universidade) uma máquina com ProxMox que é
baseado no Debian (concorrente do OpenStack) e sobre ela algumas VMs.
Numa delas eu instalei e configurei o OTRS. Como estas VMs passam para
fora da rede da universidade pelo IP fixo que está configurado nesse
proxmox, eu tenho um firewall rodando nessa máquina. Em cada uma das
VMs as aplicações são servidas pelo Apache e no host (máquina com
proxmox) eu faço um load balance com nginx. Ocorre que se eu abrir o
OTRS localmente ele roda perfeitamente. No entanto, quando eu tento
acessar ele de fora da rede aparece um erro no carregamento da página
como mostra o link abaixo:

https://scontent.fldb3-1.fna.fbcdn.net/v/t1.0-9/64820915_2328071433906171_5667532895548342272_o.jpg?_nc_cat=106&_nc_oc=AQnNBUIIOt89ELJRr5off-EglCa_1Dcb-WkpDLq0K_kbY3U0dNwX22VPA-U_POaUgWOLZG4sYQWHWgCQ14BRvCDs&_nc_ht=scontent.fldb3-1.fna=beb47967b71b64a75effb23b329d3c5a=5DBA7DD1

Estou recorrendo à comunidade do OTRS no entanto não encontrei nada
ainda. Pensei em recorrer à lista por acreditar que alguém possa ter
passado por isso já.

Alguma sugestão gente?

Agradeço muito.

Abraço.

Leonardo Rochal.

analisador de rede

[Daniel Mota]

Opa! Pra "tempo real"?
Uso o bmon, tá nos repositórios.

Em seg, 8 de jul de 2019 18:32, Vitor Hugo 
escreveu:

> Existe algum programa para analisar o consumo de trafego da rede?
>
>

Re: [i3] [xrandr] xrandr cannot find output modes when execed on startup by i3

[Felix Miata]

Jakub Alba composed on 2019-07-09 00:45 (UTC+0200)
...
Which DDX is your i3 using? Whichever, switch to the other. Does it still 
happen?

Try adding one or two empty xrandr lines before your real one in default.sh. I 
had
something similar happen 2-3 years ago, before I discovered the modesetting DDX
could work better than the intel DDX.

Another possibility: move xrandr from your homedir to /etc/X11/Xsession.d/.
-- 
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: Upgrading to Buster but keeping Postgresql-9.6

[Richard Hector]

On 9/07/19 9:24 AM, Phil Endecott wrote:
> Andrei POPESCU wrote:
>> On Lu, 08 iul 19, 20:02:36, Phil Endecott wrote:
>>> Dear Experts,
>>>
>>> Does anyone have any advice about the possibility of upgrading
>>> systems from Stretch to Buster, but keeping Postgresql-9.6 for
>>> the time being?
>>
>> Is upgrading to buster a necessity? Stretch will be supported by
>> Debian for one more year and probably some more by the LTS effort.
> 
> Indeed, not upgrading to Buster is a possibility.  Also upgrading
> PostgreSQL
> to version 11 is a possibility.  I think I understand the issues with each
> of those options, but I don't have a good understanding of the issues with
> trying to keep pg-9.6 on Buster.

Another option is to switch to using the pgdg repo for 9.6:

https://wiki.postgresql.org/wiki/Apt

I'm not sure if there are any implications of switching the packages for
the same version - I don't think so. I believe they're packaged by the
same person.

Richard



signature.asc
Description: OpenPGP digital signature

Re: fix for no ssh

[David Wright]

On Mon 08 Jul 2019 at 19:21:37 (+0300), Andrei POPESCU wrote:
> On Lu, 08 iul 19, 10:19:35, Curt wrote:
> > 
> > I thought you were saying that
> > '/etc/udev/rules.d/70-persistent-net.rules' remains a valid mechanism
> > for defining interface names in Buster (fixed). But the release-notes
> > (hmm, I think they've been modified since I last looked and now state
> > that that file is no longer "officially" supported by udev---but may
> > work in some cases). So I wouldn't be filing a bug report against that
> > stanza any longer, as current situation seems unverifiable. 
>  
> For the record, the current wording (no official support) is based on 
> input from the Debian systemd maintainers. They should know what is 
> supported or not ;)
> 
> As far as I know the /etc/udev/rules.d/70-persistent-net.rules method 
> can fail to properly rename the interfaces in certain situations which 
> can leave your system without networking.
> 
> Not nice on remote machines.
> 
> It is also my understanding that systems with only one interface (of a 
> given type[1]) are pretty safe with it or net.ifnames=0, so the impact 
> on regular[2] desktop/laptop users should be minimal.
> 
> [1] assuming ethernet cards are always named ethX and wireless cards are 
> always named wlanX by the kernel. I might have had a wireless card that 
> came up as ethX, but that was a long time ago. Still, something to be 
> aware of.

I'm still running one that comes up in jessie as eth0 and eth1;
stretch gets it right with enp2s2 and wlp2s4 respectively.

> [2] one ethernet interface, usually integrated in the motherboard and 
> one (additional) wireless interface for the laptops. Anything more 
> complicated than that might break without warning.
> 
> > Well, at the very least people should be informed who is likely to be
> > affected by the bug
> 
> In my understanding a lot of daemons are affected. Would it make sense 
> to (try to) list them all?

I guess I don't use my interfaces very adventurously so I don't see
many instances of their names, but one or two look odd. On jessie
(old-style names), and ignoring comments, I see

# grep -r -e '\' -e 'eth[01]' /etc/
/etc/wicd/manager-settings.conf:wireless_interface = eth1
/etc/wicd/manager-settings.conf:wired_interface = eth0
/etc/samba/smb.conf:;   interfaces = 127.0.0.0/8 eth0
/etc/samba/dhcp.conf:   wins server =eth1:192.168.6.1
/etc/resolvconf/interface-order:eth*([^.]).inet6
/etc/resolvconf/interface-order:eth*([^.]).ip6.@(dhclient|dhcpcd|pump|udhcpc)
/etc/resolvconf/interface-order:eth*([^.]).inet
/etc/resolvconf/interface-order:eth*([^.]).@(dhclient|dhcpcd|pump|udhcpc)
/etc/resolvconf/interface-order:eth*
/etc/udev/rules.d/70-persistent-net.rules: … … … [obviously]
# 

The wicd settings were entered by myself.
Actually, smb.conf is a comment line (with ;) but I think it was
written from information derived from the system. But dhcp.conf
looks odd because eth1: (my wireless interface) has never seen
a network numbered 192.168.6.0.

Turning to a new stretch installation, I see

# grep -r -e '\' -e 'eth[01]' -e 'enp1s0' -e '\

Re: fix for no ssh

[Nicholas Geovanis]

On Mon, Jul 8, 2019 at 6:15 PM John Hasler  wrote:

> Andy Smith writes:
> > To arrive
> > at a situation where the entirety of the CPU was open to inspection
> > would probably require a complete reworking of the modern economy,
> > i.e. make it less purely capitalist for a start.
>
> More capitalist: eliminate copyrights and patents.  Eliminating the
> capital gains tax break would also help.
>

Capitalism gave us all 3 of copyrights, patents and capital gains tax
breaks.
Capitalism can take them away any time it wants   :-)
It doesn't.


> John Hasler
> jhas...@newsguy.com
> Elmwood, WI USA
>
>

Re: fix for no ssh

[Henrique de Moraes Holschuh]

On Mon, 08 Jul 2019, Andrei POPESCU wrote:
> In my understanding what sysv-init does (crediting entropy over reboots) 
> is not secure for various reasons.

Writes to /dev/urandom using dd *DOES NOT* and *NEVER HAS* credited any
entropy to the pool.

Which is what sysvinit (actually, initscripts) did, last time I checked.

-- 
  Henrique Holschuh

Re: fix for no ssh

[John Hasler]

Andy Smith writes:
> I think if we stopped using Intel and AMD then there would be some
> other near-monopoly manufacturer that would arise and embed
> unauditable blobs so we'd be in exactly the same position. To arrive
> at a situation where the entirety of the CPU was open to inspection
> would probably require a complete reworking of the modern economy,
> i.e. make it less purely capitalist for a start.

More capitalist: eliminate copyrights and patents.  Eliminating the
capital gains tax break would also help.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: etiquette of sharing executable files

[Dan Purgert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Greg Wooledge wrote:
> On Sun, Jul 07, 2019 at 12:06:36PM +0200, Nicolas George wrote:
>> DO NOT TRY TO SECOND-GUESS THE USER.
>
> While I absolutely agree with that, I would also add:
>
> DO SENSIBLE THINGS BY DEFAULT.
>
> That is, if the user doesn't tell you what to do, try to do the most
> common, or the safest, thing.  But if the user explictly tells you to
> do something, you do it.
>
> Nuking a pre-existing directory's files, for example, is not a sensible
> thing to do by default.  BUT, if the user uses the --wipe-files option
> with the --directory /home/me option, then by all means, nuke those files.

The one time I scripted rm, i tested it with a mv to /tmp first.  saved
my bacon.

and i learned an important lesson about quoting substitutions.


-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl0jy+EACgkQjhHd8xJ5
ooF7AQf+N0e66GKISjAmHZ0ay8jBGhM2sJKtOZlZsXibdLY7nbcCE8NpRPXffCxn
kVDoHL8R804Sq9HYuyYy6UmncjmTHySqx8COzGeJJ7mkL/2Hhc2QoyD7dniXRlGh
QK/8e+VjKyCLoVZ2n8iZMEsqyXdp8JVClogNRYRv7viqSVrfBi74DNFqLORbXfZ3
nA8aO6k5uHN0xw9beEMTZOQ6ZxILh6fXox/ti2WdGXu/bxWq6Ld8KYBTXiNAyPrt
nu1gSHTWcOu9pbVdM5rrcqBg8TpnTWoJh1bZCp+cvB6Y87KYliniOTmEgbdI7FqV
M5GxwkE/ZeDGw+97cnQh0SWIl3xTng==
=/D6j
-END PGP SIGNATURE-

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

[i3] [xrandr] xrandr cannot find output modes when execed on startup by i3

[Jakub Alba]

I've just upgraded from Stretch to Buster. I use a xrandr script invoked 
by i3 on startup to set screen layout. Here is the fragment of my config 
responsible for that:


# set multimonitor screen layout & background
exec --no-startup-id setscreenlayout && setbg

`setscreenlayout` is just this:

#!/bin/sh

if [ -f ~/.screenlayout/default.sh ]; then
~/.screenlayout/default.sh
fi

And `~/.screenlayout/default.sh` is this:

#!/bin/sh
xrandr --output HDMI1 --primary --mode 3840x2160 --pos 0x0 \
--rotate normal --output DP1 --off --output eDP1 \
--off --output VIRTUAL1 --off

It used to work in Stretch, but after the upgrade xrandr prints this to 
stderr:


xrandr: Output DP1 is not disconnected but has no modes
xrandr: cannot find mode 3840x2160

And everything stays as if xrandr was never run. When I run the script 
`setscreenlayout` manually (from the terminal) later, it works. When I 
add `xrandr >/dev/null` just after `#!/bin/sh` in 
`~/.screenlayout/default.sh`, it works. However, it's clear that 
something is broken.


I'm not sure which package (i3 vs xrandr) I should report a bug against.

On a related note, I have a Python script which prints on subsequent 
lines (without any delay) the titles of subsequently focused windows. I 
use it to print the title of the currently focused window in i3bar. But 
now it doesn't work when it's invoked by i3blocks when i3 starts. It 
starts working again after I restart the i3 session in place. The script 
(something I found on Stack Overflow and tweaked a little bit):


https://paste.debian.net/hidden/11dfbe1c/

I prints the following to stderr:


Traceback (most recent call last):
  File "/home/yakubin/.scripts/statusbar/window-title", line 100, in 
get_window_name(get_active_window()[0])
  File "/home/yakubin/.scripts/statusbar/window-title", line 29, in 
get_active_window
Xlib.X.AnyPropertyType).value[0]
AttributeError: 'NoneType' object has no attribute 'value'


Perhaps these two problems have a common cause?

JA

Re: analisador de rede

[Carlos Donizete Froes]

Ola Vitor,

> Existe algum programa para analisar o consumo de trafego da rede?

Conheço dois software que utilizava um tempo atras: "iptraf" e o "nload".

# apt install nload

Não é necessario executar como root.

$ nload

# apt install iptraf

Este software é necessario esta como root.

# iptraf-ng

Ate mais!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ Debian Wiki: https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780


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

Re: Fwd: fix for no ssh

[Andy Smith]

Hi Nicholas,

On Mon, Jul 08, 2019 at 04:49:00PM -0500, Nicholas Geovanis wrote:
> On Mon, Jul 8, 2019 at 3:45 PM Andy Smith  wrote:
> > Flash forward to 2017 and T'so himself wrote a patch to add a
> > configure option to allow RDRAND to be used early on to bootstrap
> > entropy. Thereafter it would not be the exclusive source of entropy.
> > That is what has been enabled in buster's kernel and is what is at
> > the heart of this discussion.
> > These are two different scenarios.
> 
> Granted, they are different scenarios.
> But I don't ever recall the mainstream kernel in a leading
> distribution blocking on lack of entropy by default at any time in
> T'so's career. Until now. Sure, it looks like the source permitted
> blocking all along (maybe). But I never heard of this being used
> in a non-custom-built mainstream distro before.
> Has T'so had any comments on that? Does he find it appropriate or wise?

This whole getrandom()-can-block thing has been going on for
multiple years; it has been a huge debate within the Linux
development community. I'd have to read it all again I think to try
to summarise Theodore T'so's position on all of it, and I don't
really want to do that.

There was good coverage in LWN:

https://lwn.net/Articles/760584/

> > This sub-thread appears to have people concerned about the Debian
> > kernel's willingness by default to use RDRAND at early boot (a patch
> > which T'so wrote), but using a statement made by T'so in 2013 about
> > something else to oppose it.
> 
> OK. You imply that their concerns were misguided (I wasn't one of them).

For the avoidance of doubt, I think that if we don't trust our CPUs
then we start to go down the rabbit hole where we can't trust
anything. HOWEVER…

Theodore T'so himself has made the argument that most places you
might compromise a CPU involve big teams of people and keeping the
secret that it's happened would likely be infeasible. Not so RDRAND,
which is thought to be the work of one or a small team of
developers, and which would be very easy to compromise.

So, as far as I understand it, that is why T'so opposed the use of
RDRAND as the *only* entropy source for Linux, but T'so in fact
*suggests* the use of RDRAND in tandem with other entropy sources as
a means to avoid boot-time entropy starvation. Because it's one of
the easiest ways to get around that problem, and even if compromised
isn't going to do any harm when mixed in.

That sounds sensible to me so I would agree with him that RDRAND is
suspicious but usable in that context. And I do go so far as to
provide entropy from external hardware sources for me and my
customers since 2013.

Actually I just tested this earlier in a new buster VM and by
default:

[1.170404] random: crng done (trusting CPU's manufacturer)

With 'nordrand' kernel command line and no use of external entropy:

[1.231884] random: fast init done
[   48.655256] random: crng init done

with 'nordrand' and external entropy:

[   10.879583] random: crng init done

The daemon for the external entropy starts quite late so I may be
able to improve matters by forcing it to start earlier, but I'm okay
with leaving RDRAND enabled so am not going to spend too much effort
on this.

> The evidence they chose may be untenable. But you have not
> addressed their actual concern.

I don't know whether you mean their concern about RDRAND possibly
being unsafe, or their concern about Debian choosing to make use of
it even though some believe it may be unsafe. Your next bit makes me
think you mean the latter so that's what I'll go with.

> I'm sure that your answer will include "but the standard
> debian process to include this new feature in the kernel was
> followed..". So everything is OK. Right?

How to solve the "lack of entropy at boot time" problem was
discussed at length on debian-devel multiples times over multiple
years and that's how the wiki page at:

https://wiki.debian.org/BoottimeEntropyStarvation

came to exist. That page links to two of the debian-devel threads
and in those threads Theodore T'so did give some recommendations.

Debian developers made a decision based on those discussions which
were held in the open. I'm not sure who it fell to, to make the
ultimate decision. Probably the kernel team as they decided whether
to enable the RDRAND option? It's a tricky problem without a perfect
solution. Not everyone will be happy with the outcome, though there
does seem to be enough configurability there for them to have things
work differently, with different trade-offs.

If this has come as a surprise to some Debian users, that is only
because they didn't choose to get involved in such a deeply
technical discussion.

It's not that unusual that some users get upset by developer
decisions and isn't usually worth commenting upon, but it struck me
that in this sub-thread there is a particularly big misunderstanding
going on, as some are quoting T'so in a completely different context
as support for 

Fwd: fix for no ssh

[Nicholas Geovanis]

On Mon, Jul 8, 2019 at 3:45 PM Andy Smith  wrote:

> Hello,
> 
> Flash forward to 2017 and T'so himself wrote a patch to add a
> configure option to allow RDRAND to be used early on to bootstrap
> entropy. Thereafter it would not be the exclusive source of entropy.
> That is what has been enabled in buster's kernel and is what is at
> the heart of this discussion.
> These are two different scenarios.
>

Granted, they are different scenarios.
But I don't ever recall the mainstream kernel in a leading distribution
blocking on lack of entropy by default
at any time in T'so's career. Until now. Sure, it looks like the source
permitted blocking all along (maybe).
But I never heard of this being used in a non-custom-built mainstream
distro before.
Has T'so had any comments on that? Does he find it appropriate or wise?


> This sub-thread appears to have people concerned about the Debian
> kernel's willingness by default to use RDRAND at early boot (a patch
> which T'so wrote), but using a statement made by T'so in 2013 about
> something else to oppose it.
>

OK. You imply that their concerns were misguided (I wasn't one of them).
The evidence they chose may be untenable. But you have not addressed their
actual concern.
I'm sure that your answer will include "but the standard debian process
to include this new
feature in the kernel was followed..". So everything is OK. Right?


> Cheers,
> Andy
> https://bitfolk.com/ -- No-nonsense VPS hosting
>

Re: Upgrading to Buster but keeping Postgresql-9.6

[Phil Endecott]

Andrei POPESCU wrote:

On Lu, 08 iul 19, 20:02:36, Phil Endecott wrote:

Dear Experts,

Does anyone have any advice about the possibility of upgrading
systems from Stretch to Buster, but keeping Postgresql-9.6 for
the time being?


Is upgrading to buster a necessity? Stretch will be supported by Debian 
for one more year and probably some more by the LTS effort.


Indeed, not upgrading to Buster is a possibility.  Also upgrading PostgreSQL
to version 11 is a possibility.  I think I understand the issues with each
of those options, but I don't have a good understanding of the issues with
trying to keep pg-9.6 on Buster.

(There doesn't seem to be a Debian-Postgresql mailing list, hmmm.)


Phil.

analisador de rede

[Vitor Hugo]

Existe algum programa para analisar o consumo de trafego da rede?

Re: Assorted arm-buster problems - network configuration

[Lee]

On 7/8/19, Gene Heskett  wrote:
> On Monday 08 July 2019 14:48:59 Lee wrote:
>
>> On 7/8/19, Andrei POPESCU  wrote:
>> > On Lu, 08 iul 19, 13:37:26, Lee wrote:
>> >> On 7/7/19, andreimpope...@gmail.com 
> wrote:
>> >> > The dangers are not at all obvious to me, possibly because I
>> >> > haven't used it much (if at all).
>> >>
>> >> Read the first three paragraph of the "Security Considerations"
>> >> section https://tools.ietf.org/html/rfc6762#section-21
>> >>
>> >> Assuming everything on the network is a trusted host is a dangerous
>> >> assumption, so paragraph 1 is N/A
>> >>
>> >> Assuming a trusted host won't get hacked is a dangerous assumption,
>> >> so paragraph 3 is N/A.
>> >>
>> >> All that's left is paragraph 2 -- and uninstalling whatever
>> >> software uses mDNS :)
>> >
>> > Security is not a black/white thing, it's more like a balancing act.
>>
>> Agreed
>>
>> > In my opinion mDNS/zeroconf can make perfect sense in some
>> > environments and be a complete no-go in others.
>>
>> Apparently it's not clear that I agree :(
>>
>> I thought about concluding with something about different people
>> making different assumptions & some not wanting or able to set up
>> their own dns server & living with the risk, but it seemed like such
>> an obvious conclusion that I didn't bother.
>>
>> Regards,
>> Lee
>
> If referring to my problem Lee,

Nope, this sub-thread is a result of my offering a hyperbolic opinion
to someone else.

You're very clearly in the "my network, my rules" camp, so I won't be
offering any opinions on how you should/shouldn't run your own network
:)

Regards,
Lee

Re: Upgrading to Buster but keeping Postgresql-9.6

[Andrei POPESCU]

On Lu, 08 iul 19, 20:02:36, Phil Endecott wrote:
> Dear Experts,
> 
> Does anyone have any advice about the possibility of upgrading
> systems from Stretch to Buster, but keeping Postgresql-9.6 for
> the time being?

Is upgrading to buster a necessity? Stretch will be supported by Debian 
for one more year and probably some more by the LTS effort.

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


signature.asc
Description: PGP signature

Re: fix for no ssh

[Andrei POPESCU]

Sorry for replying to myself.

On Lu, 08 iul 19, 23:50:02, Andrei POPESCU wrote:
> 
> On the other hand Debian felt like from the moment I started with it and 
   
   home

> I was happy to be able to return to it once it gained sufficient support 
> for my current hardware.

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


signature.asc
Description: PGP signature

Re: fix for no ssh

[Andrei POPESCU]

On Lu, 08 iul 19, 14:50:18, Gene Heskett wrote:
> 
> But I must say even I was surprised by the near total bailout when I 
> mentioned that it was raspian. Obviously in retrospect, there is bad 
> blood?

Not from me. I was very much happy with Raspbian when I my Raspberry Pis 
were still in use.

On the other hand Debian felt like from the moment I started with it and 
I was happy to be able to return to it once it gained sufficient support 
for my current hardware.

As far as I'm concerned trying to diagnose problems on Raspbian would 
take significantly more time, because:

1. I don't know where/how much it diverges from pure Debian.

   (It's been years since I last used it)

2. I don't have the means to test my assumptions/advice.

   (I don't like to provide wrong advice, even though I know somebody 
   will correct it, literally within minutes [1])


It also doesn't help when posters don't provide the information being 
asked for (or mangle it). If they know so well what is or not relevant 
how come they can't they solve their own problems?

Given the above I believe my limited available time is just better spent 
helping people that are running something closer to pure Debian.

[1] which reminds me of https://xkcd.com/386/ :)

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


signature.asc
Description: PGP signature

Re: fix for no ssh

[Andy Smith]

Hello,

On Mon, Jul 08, 2019 at 02:50:18PM -0400, Gene Heskett wrote:
> On Monday 08 July 2019 14:14:10 Andy Smith wrote:
> > On Mon, Jul 08, 2019 at 05:48:24PM -, Curt wrote:
> > > it "amounts to trusting that CPU manufacturer (perhaps with the
> > > insistence or mandate of a Nation State's intelligence or law
> > > enforcement agencies) has not installed a hidden back door to
> > > compromise the CPU's random number generation facilities."
> >
> > Again, everyone using a popular CPU is already in that position.
> 
> Absolutely Andy. But from the argument thread my original post generated, 
> there are IMO, quite a few who have become addicted to the koolaid.

The koolaid of using a mainstream CPU?

I think if we stopped using Intel and AMD then there would be some
other near-monopoly manufacturer that would arise and embed
unauditable blobs so we'd be in exactly the same position. To arrive
at a situation where the entirety of the CPU was open to inspection
would probably require a complete reworking of the modern economy,
i.e. make it less purely capitalist for a start.

When the problem is as big as that, I'm not sure that being captured
by it can be referred to as "koolaid" to be honest.

(Before an ARM fanboy pulls me up for not mentioning them, I'm
talking about the mainstream. If Intel and AMD didn't exist then I
suspect ARM would be just as bad for this, if not worse.)

> Theodore T. has been right wayy more than he's been wrong.

I think you may have been confused by the posted statement of T'so's
which began:

"I am so glad I resisted pressure from Intel engineers to let
/dev/random rely only on the RDRAND instruction."

This was from 2013 and was from T'so opposing the trusting of the
RDRAND instruction for *all* of the Linux kernel's entropy needs.

Flash forward to 2017 and T'so himself wrote a patch to add a
configure option to allow RDRAND to be used early on to bootstrap
entropy. Thereafter it would not be the exclusive source of entropy.
That is what has been enabled in buster's kernel and is what is at
the heart of this discussion.

These are two different scenarios.

This sub-thread appears to have people concerned about the Debian
kernel's willingness by default to use RDRAND at early boot (a patch
which T'so wrote), but using a statement made by T'so in 2013 about
something else to oppose it.

> Raspian is usually not more than a day or so behind debian,

Discussion of Raspbian is off-topic here, and I don't see what it
has to do with the topic of this sub-thread (entropy starvation at
boot). I think you would be better off discussing Raspbian on
Raspbian mailing lists.

Cheers,
Andy

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

Re: Problem Installing DiscoveryStudio2019 in Buster

[David Wright]

On Mon 08 Jul 2019 at 16:13:56 (-0400), Greg Wooledge wrote:
> On Mon, Jul 08, 2019 at 03:09:45PM -0500, David Wright wrote:
> > On Mon 08 Jul 2019 at 14:55:45 (-0400), Greg Wooledge wrote:
> > > On Mon, Jul 08, 2019 at 02:49:40PM -0400, Stephen P. Molnar wrote:
> > > > It came from the Biovia web site.
> > > 
> > > Like I know what a "Biovia" is.
> > 
> > It looks like a company to me.
> > 
> > > I'm guessing it has something to do with "Molecular-Modeling", and
> > > therefore I lump it into the broad category of "academia", which means
> > > it's poorly written but "works" as long as you build your entire machine
> > > to conform to whatever it requires.
> > 
> > Like Gnu, Linux, TeX, Python, …?
> 
> Like scripts that are written for bash but with a #!/bin/sh shebang
> because they only tested on one CentOS box.
> 
> Wouldn't surprise me if they parse the output of /sbin/ifconfig eth0 to
> get information to create/validate a license key.  And oh boy will THAT
> be fun, if that's the case, now that eth0 is not an officially valid
> interface name, and /sbin/ifconfig is not installed by default, and even
> if you DO install it, its output format has changed.
> 
> But maybe I'll be pleasantly surprised and the /bin/sh symlink will be
> the only backflip required.

And this only happens in academia? 

Cheers,
David.

Re: Problem Installing DiscoveryStudio2019 in Buster

[Greg Wooledge]

On Mon, Jul 08, 2019 at 03:09:45PM -0500, David Wright wrote:
> On Mon 08 Jul 2019 at 14:55:45 (-0400), Greg Wooledge wrote:
> > On Mon, Jul 08, 2019 at 02:49:40PM -0400, Stephen P. Molnar wrote:
> > > It came from the Biovia web site.
> > 
> > Like I know what a "Biovia" is.
> 
> It looks like a company to me.
> 
> > I'm guessing it has something to do with "Molecular-Modeling", and
> > therefore I lump it into the broad category of "academia", which means
> > it's poorly written but "works" as long as you build your entire machine
> > to conform to whatever it requires.
> 
> Like Gnu, Linux, TeX, Python, …?

Like scripts that are written for bash but with a #!/bin/sh shebang
because they only tested on one CentOS box.

Wouldn't surprise me if they parse the output of /sbin/ifconfig eth0 to
get information to create/validate a license key.  And oh boy will THAT
be fun, if that's the case, now that eth0 is not an officially valid
interface name, and /sbin/ifconfig is not installed by default, and even
if you DO install it, its output format has changed.

But maybe I'll be pleasantly surprised and the /bin/sh symlink will be
the only backflip required.

Re: Problem Installing DiscoveryStudio2019 in Buster

[David Wright]

On Mon 08 Jul 2019 at 14:55:45 (-0400), Greg Wooledge wrote:
> On Mon, Jul 08, 2019 at 02:49:40PM -0400, Stephen P. Molnar wrote:
> > It came from the Biovia web site.
> 
> Like I know what a "Biovia" is.

It looks like a company to me.

> I'm guessing it has something to do with "Molecular-Modeling", and
> therefore I lump it into the broad category of "academia", which means
> it's poorly written but "works" as long as you build your entire machine
> to conform to whatever it requires.

Like Gnu, Linux, TeX, Python, …?

Cheers,
David.

Re: Upgrading to Buster but keeping Postgresql-9.6

[Jochen Spieker]

Phil Endecott:
> 
> Does anyone have any advice about the possibility of upgrading
> systems from Stretch to Buster, but keeping Postgresql-9.6 for
> the time being?

With previous Debian releases you always had to migrate your cluster to
the new Postgres version manually. The new packages are installed, but
the old ones stay around and you can pg_upgradecluster when you are
ready.

J.
-- 
I frequently find myself at the top of the stairs with absolutely
nothing happening in my brain.
[Agree]   [Disagree]
 


signature.asc
Description: PGP signature

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Monday 08 July 2019 14:48:59 Lee wrote:

> On 7/8/19, Andrei POPESCU  wrote:
> > On Lu, 08 iul 19, 13:37:26, Lee wrote:
> >> On 7/7/19, andreimpope...@gmail.com  
wrote:
> >> > The dangers are not at all obvious to me, possibly because I
> >> > haven't used it much (if at all).
> >>
> >> Read the first three paragraph of the "Security Considerations"
> >> section https://tools.ietf.org/html/rfc6762#section-21
> >>
> >> Assuming everything on the network is a trusted host is a dangerous
> >> assumption, so paragraph 1 is N/A
> >>
> >> Assuming a trusted host won't get hacked is a dangerous assumption,
> >> so paragraph 3 is N/A.
> >>
> >> All that's left is paragraph 2 -- and uninstalling whatever
> >> software uses mDNS :)
> >
> > Security is not a black/white thing, it's more like a balancing act.
>
> Agreed
>
> > In my opinion mDNS/zeroconf can make perfect sense in some
> > environments and be a complete no-go in others.
>
> Apparently it's not clear that I agree :(
>
> I thought about concluding with something about different people
> making different assumptions & some not wanting or able to set up
> their own dns server & living with the risk, but it seemed like such
> an obvious conclusion that I didn't bother.
>
> Regards,
> Lee

If referring to my problem Lee, dns the way I have it setup since roughly 
1998 works perfectly. Its the lack of a dhcpd-like server, which adds 
needless complexity IMO to an otherwise working system I've been using 
since before I retired my amiga in 2000. In my case, both avahi-daemon 
and dchpcd5 were inventing bogus ip addresses, and setting the metric 
very low, forcing the system to use the bogus 169.254.etc numbers.  And 
they were cached, I suspect in /proc/network, so in order to achieve a 
working system, issueing the testing pings from the machines own 
address, asking the router for the NAT translation.  The router of 
course is running dnsmasq so it caches the common stuff, and if it does 
not have it in the cache its asks my ISP's dns. Takes about 90 ms if it 
has to ask a shentel dns server.

But both the router and the managed switch that connects the rest of my 
machines, respond only to 192.168.71.00/24 stuff, so 169 stuff 
is /dev/nulled as it should be.

So I had no external network access from that machine. I do have a dhcpd 
server in the router, facing the radio when its turned on and supposedly 
responding only to the MAC's of my sons smartfones.  So they can use my 
bandwidth when within range, but their smartfones can't see me. Most of 
the time they are 1000+ miles out of range.

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 

Upgrading to Buster but keeping Postgresql-9.6

[Phil Endecott]

Dear Experts,

Does anyone have any advice about the possibility of upgrading
systems from Stretch to Buster, but keeping Postgresql-9.6 for
the time being?

This is for a couple of cloud servers that are running Postgresql
with streaming replication from one to the other.  I guess my
questions are: (a) will this actually work, i.e. will Postgresql-9.6
continue to run OK with the rest of the system upgraded, and (b)
what "apt magic runes" do I need to invoke to make it happen?  I
guess this is "pinning", is it?  That's not something I've ever
had to do before.

Many thanks for any suggestions.


(Please Cc: me in any replies, so I'll see them sooner.)


Phil.

Re: Assorted arm-buster problems - network configuration

[Brian]

On Mon 08 Jul 2019 at 13:37:26 -0400, Lee wrote:

> On 7/7/19, andreimpope...@gmail.com  wrote:
> > On Sb, 06 iul 19, 15:36:37, Lee wrote:
> >>
> >> "an accident waiting to happen" was from me and I also gave the rfc
> >> for mdns, so that's hardly "nothing of substance to support that
> >> view."  If you're having trouble finding the rfc, it's here
> >>   https://tools.ietf.org/html/rfc6762
> >
> > Care to elaborate though?
> 
> While reading about a security issue I came across the line "An
> insecure protocol will eventually be exploited." - which sounds right
> to me.  And the standard q for most security issues involving an
> insecure protocol seems to be
> q: how do i prevent  from happening?
> a: by not allowing it in the first place.
> 
> Hopefully we're clear about my bias now :)

Indeed we are. Everyone has a bias of one sort or another. It is often
what makes things interesting.
> 
> > The dangers are not at all obvious to me, possibly because I haven't
> > used it much (if at all).
> 
> Read the first three paragraph of the "Security Considerations" section
>   https://tools.ietf.org/html/rfc6762#section-21
> 
> Assuming everything on the network is a trusted host is a dangerous
> assumption, so paragraph 1 is N/A
> 
> Assuming a trusted host won't get hacked is a dangerous assumption, so
> paragraph 3 is N/A.
> 
> All that's left is paragraph 2 -- and uninstalling whatever software
> uses mDNS :)

I am unsure your analysis necessarily leads to to the conclusion you
make. Perhaps it does for you, but the section is, after all, dealing
only with considerations. You have assessed them and come to a decision
which fits your situation. 

Anyway, thank you for this diligent response. It is differs somewhat
from

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

This lead only to boltstering the OP's inate prejudices against software
he lacks understanding of and that does not fit into his world view..

-- 
Brian.

Re: Re : Re : Lumière bleue des moniteurs led ?

[Yann Serre]

Le 08/07/2019 à 18:40, Eric Degenetais a écrit :

Personnellement, j'aimerais bien une démonstration autre que le
matériel publicitaire des opticiens ATOLL pour leurs lunettes
anti-bleu que l'intensité de la lumière bleue en question est
suffisante pour tromper le système nerveux. L'intensité lumineuse d'un
cran LED est quand même sacrément inférieure à celle du soleil.

Cordialement
__
Éric Dégenètais


Il me semble que lunettes en question filtrent surtout les UV.
En photo/vidéo ces mêmes filtres UV sont utilisés depuis très longtemps.
P'tet qu'en plus des UV les lunettes Atol pour écrans mangent un peu sur 
la longueur d'onde du bleu...
Mais je pense aussi que médicalement parlant, avoir les rétines exposées 
directement à une source d'UV va poser des problèmes sur le long 
terme... Les UV du soleil, on ne les reçoit que par réflexion, pas 
directement sur les rétines. Et je parie que plus les ondes lumineuses 
sont courtes, moins elle sont énergétiques après réflexion sur une 
surface absorbante (cad pas un miroir, la neige, la surface de l'eau,...).


Sinon pour ce qui est du soleil, le bleu, les UV sont diffractés par 
l'atmosphère (la vapeur d'eau entre autres).
A midi GMT la partie bleue du spectre pénètre et éclaire directement le 
sol. Plus le soir tombe, plus la lumière traverse l'atmosphère de biais, 
plus l'extrémité bleue du spectre va "rebondir" sur l'atmosphère et se 
perdre dans l'espace (...space ...pace ...ace ...ce ...e ...).
Bref, la partie du soleil qui arrive au niveau du sol est de plus en 
plus dans l'extrémité rouge du spectre. Et depuis nos ancêtres (les 
petits mammifères qui ont survécu aux dinosaures) cette lumière 
rougeoyante réveille des hormones qui préparent au sommeil.


Au dessus de mon bureau, le soir, l'éclairage d'ambiance est généré 
uniquement par 30W de LEDS rouges et une petite ampoule LED très jaune 
(7W @ 2200°K). Cette lumière d'ambiance rouge se mélange à celle des 
écrans. Un peu comme l'ambiance de nuit des navires militaires. Je ne 
sais pas si c'est vraiment efficace de diluer le bleu dans beaucoup de 
rouge, mais c'est ce que j'expérimente depuis quelques années, sans trop 
de fatigue visuelle ni de problèmes d'endormissement ensuite.


Bon avec tout ça, on n'est pas trolldi.

Bonne semaine à tous.

Yann

Re: Problem Installing DiscoveryStudio2019 in Buster

[Stephen P. Molnar]

On 07/08/2019 02:55 PM, Greg Wooledge wrote:

On Mon, Jul 08, 2019 at 02:49:40PM -0400, Stephen P. Molnar wrote:

It came from the Biovia web site.

--
Stephen P. Molnar, Ph.D.Life is a fuzzy set
http://www.Molecular-Modeling.net   Multivariate and stochastic

Like I know what a "Biovia" is.

I'm guessing it has something to do with "Molecular-Modeling", and
therefore I lump it into the broad category of "academia", which means
it's poorly written but "works" as long as you build your entire machine
to conform to whatever it requires.

Good luck.



https://www.3dsbiovia.com/

--
Stephen P. Molnar, Ph.D.Life is a fuzzy set
http://www.Molecular-Modeling.net   Multivariate and stochastic
614.312.7528 (c)
Skype:  smolnar1

Re: Problem Installing DiscoveryStudio2019 in Buster

[Stephen P. Molnar]

On 07/08/2019 02:46 PM, Erwan David wrote:

Le 08/07/2019 ?? 20:40, Stephen P. Molnar a ??crit :

I have just installed Buster and have encountereda  a problem
attempting the installation of biovia_2019_.ds2019client.bin:

comp@AbNormal:~/Downloads/DiscoveryStudio$ ./biovia_2019.ds2019client.bin
Verifying archive integrity...  100%   All good.
Uncompressing 'DS Client and extracting files, please wait ..' 100%
./install_DSClient.sh: 49: ./install_DSClient.sh: [[: not found
./install_DSClient.sh: 70: ./install_DSClient.sh: Syntax error:
redirection unexpected
Press Return to close this window...

And not too surprising, Press Return did close the window.

Anyone have any ideas as to a solution?

Thanks in advance.


[[ is a bash built-in not defined in dash.

It might be that the .bin file is a bash script presented as a sh one.

If file biovia_2019_.ds2019client.bin resturns "/bin/sh script" that
would be almost sure. In that case try

bash ./biovia_2019.ds2019client.bin to force bash interpreter




Good idea, but it didn't work!  Got the same result, it just took longer.

--
Stephen P. Molnar, Ph.D.Life is a fuzzy set
http://www.Molecular-Modeling.net   Multivariate and stochastic
614.312.7528 (c)
Skype:  smolnar1

Re: Problem Installing DiscoveryStudio2019 in Buster

[Sven Joachim]

On 2019-07-08 20:46 +0200, Erwan David wrote:

> Le 08/07/2019 à 20:40, Stephen P. Molnar a écrit :
>> I have just installed Buster and have encountereda  a problem
>> attempting the installation of biovia_2019_.ds2019client.bin:
>>
>> comp@AbNormal:~/Downloads/DiscoveryStudio$ ./biovia_2019.ds2019client.bin
>> Verifying archive integrity...  100%   All good.
>> Uncompressing 'DS Client and extracting files, please wait ..' 100%
>> ./install_DSClient.sh: 49: ./install_DSClient.sh: [[: not found
>> ./install_DSClient.sh: 70: ./install_DSClient.sh: Syntax error:
>> redirection unexpected
>> Press Return to close this window...
>>
>> And not too surprising, Press Return did close the window.
>>
>> Anyone have any ideas as to a solution?
>>
>> Thanks in advance.
>>
> [[ is a bash built-in not defined in dash.
>
> It might be that the .bin file is a bash script presented as a sh one.

Probably not, since the file which complains is called
"/install_DSClient.sh".  The .bin file appears to be a self-extracting
archive which then runs the shell script.

> If file biovia_2019_.ds2019client.bin resturns "/bin/sh script" that
> would be almost sure. In that case try
>
> bash ./biovia_2019.ds2019client.bin to force bash interpreter

Most likely that will not work.  To use bash as /bin/sh for the biova
installer, switchsh[1] could be used instead.

Cheers,
   Sven


1. https://packages.debian.org/buster/switchsh

Re: Problem Installing DiscoveryStudio2019 in Buster

[Greg Wooledge]

On Mon, Jul 08, 2019 at 02:49:40PM -0400, Stephen P. Molnar wrote:
> It came from the Biovia web site.
> 
> -- 
> Stephen P. Molnar, Ph.D.Life is a fuzzy set
> http://www.Molecular-Modeling.net   Multivariate and stochastic

Like I know what a "Biovia" is.

I'm guessing it has something to do with "Molecular-Modeling", and
therefore I lump it into the broad category of "academia", which means
it's poorly written but "works" as long as you build your entire machine
to conform to whatever it requires.

Good luck.

Re: Problem Installing DiscoveryStudio2019 in Buster

[Greg Wooledge]

On Mon, Jul 08, 2019 at 08:46:30PM +0200, Erwan David wrote:
> bash ./biovia_2019.ds2019client.bin to force bash interpreter

That won't work, because...

> Le 08/07/2019 à 20:40, Stephen P. Molnar a écrit :
> > comp@AbNormal:~/Downloads/DiscoveryStudio$ ./biovia_2019.ds2019client.bin
> > Verifying archive integrity...  100%   All good.
> > Uncompressing 'DS Client and extracting files, please wait ..' 100%
> > ./install_DSClient.sh: 49: ./install_DSClient.sh: [[: not found
> > ./install_DSClient.sh: 70: ./install_DSClient.sh: Syntax error:
> > redirection unexpected
> > Press Return to close this window...

It's not the ./biovia_2019.ds2019client.bin script that's actually
got these errors in it.  It's the "./install_DSClient.sh" script, which
I'm guessing is part of the payload that's extracted and/or downloaded
by ./biovia_2019.ds2019client.bin.

It may be impossible to specify that ./install_DSClient.sh needs to be
run by bash, due to internal checksums, or glob knows what else.  So,
your safest option is to reconstruct the environment in which this
"biovia" thing is known to work, which probably means /bin/sh -> bash.

Re: fix for no ssh

[Gene Heskett]

On Monday 08 July 2019 14:14:10 Andy Smith wrote:

> Hi Curt,
>
> On Mon, Jul 08, 2019 at 05:48:24PM -, Curt wrote:
> > it "amounts to trusting that CPU manufacturer (perhaps with the
> > insistence or mandate of a Nation State's intelligence or law
> > enforcement agencies) has not installed a hidden back door to
> > compromise the CPU's random number generation facilities."
>
> Again, everyone using a popular CPU is already in that position.
>
> Cheers,
> Andy

Absolutely Andy. But from the argument thread my original post generated, 
there are IMO, quite a few who have become addicted to the koolaid. And 
thats not a good thing. Theodore T. has been right wayy more than 
he's been wrong. Raspian is usually not more than a day or so behind 
debian, and differ in that they assemble a ready to run image using the 
same code base, perhaps with some additional non-free stuff to make the 
hardware work a bit better. Point being that in the case of my original 
problem, the software in the middle of the discussion differed only in 
the object it was compiled for, and the source probably remains byte for 
byte identical.

But I must say even I was surprised by the near total bailout when I 
mentioned that it was raspian. Obviously in retrospect, there is bad 
blood?

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: Problem Installing DiscoveryStudio2019 in Buster

[Stephen P. Molnar]

On 07/08/2019 02:44 PM, Greg Wooledge wrote:

On Mon, Jul 08, 2019 at 02:40:18PM -0400, Stephen P. Molnar wrote:

I have just installed Buster and have encountereda  a problem attempting the
installation of biovia_2019_.ds2019client.bin:

comp@AbNormal:~/Downloads/DiscoveryStudio$ ./biovia_2019.ds2019client.bin
Verifying archive integrity...  100%   All good.
Uncompressing 'DS Client and extracting files, please wait ..' 100%
./install_DSClient.sh: 49: ./install_DSClient.sh: [[: not found
./install_DSClient.sh: 70: ./install_DSClient.sh: Syntax error: redirection
unexpected
Press Return to close this window...

Whoever wrote this shell script does not know what they're doing.  You've
uncovered 2 bugs in it already.  There are probably a few hundred more.

As a workaround, because you do not have direct access to the script
(apparently it's in the downloaded payload), you may have to change
your /bin/sh symlink to point to bash instead of dash.  You may either
leave it there, or change it back, after this is done.

I would give serious consideration to finding a non-broken alternative
to whatever this thing is, except there probably isn't any alternative,
and you're stuck with it.




It came from the Biovia web site.

--
Stephen P. Molnar, Ph.D.Life is a fuzzy set
http://www.Molecular-Modeling.net   Multivariate and stochastic
614.312.7528 (c)
Skype:  smolnar1

Re: Assorted arm-buster problems - network configuration

[Lee]

On 7/8/19, Andrei POPESCU  wrote:
> On Lu, 08 iul 19, 13:37:26, Lee wrote:
>> On 7/7/19, andreimpope...@gmail.com  wrote:
>>
>> > The dangers are not at all obvious to me, possibly because I haven't
>> > used it much (if at all).
>>
>> Read the first three paragraph of the "Security Considerations" section
>>   https://tools.ietf.org/html/rfc6762#section-21
>>
>> Assuming everything on the network is a trusted host is a dangerous
>> assumption, so paragraph 1 is N/A
>>
>> Assuming a trusted host won't get hacked is a dangerous assumption, so
>> paragraph 3 is N/A.
>>
>> All that's left is paragraph 2 -- and uninstalling whatever software
>> uses mDNS :)
>
> Security is not a black/white thing, it's more like a balancing act.

Agreed

> In my opinion mDNS/zeroconf can make perfect sense in some environments
> and be a complete no-go in others.

Apparently it's not clear that I agree :(

I thought about concluding with something about different people
making different assumptions & some not wanting or able to set up
their own dns server & living with the risk, but it seemed like such
an obvious conclusion that I didn't bother.

Regards,
Lee

Re: Problem Installing DiscoveryStudio2019 in Buster

[Erwan David]

Le 08/07/2019 à 20:40, Stephen P. Molnar a écrit :
> I have just installed Buster and have encountereda  a problem
> attempting the installation of biovia_2019_.ds2019client.bin:
>
> comp@AbNormal:~/Downloads/DiscoveryStudio$ ./biovia_2019.ds2019client.bin
> Verifying archive integrity...  100%   All good.
> Uncompressing 'DS Client and extracting files, please wait ..' 100%
> ./install_DSClient.sh: 49: ./install_DSClient.sh: [[: not found
> ./install_DSClient.sh: 70: ./install_DSClient.sh: Syntax error:
> redirection unexpected
> Press Return to close this window...
>
> And not too surprising, Press Return did close the window.
>
> Anyone have any ideas as to a solution?
>
> Thanks in advance.
>
[[ is a bash built-in not defined in dash.

It might be that the .bin file is a bash script presented as a sh one.

If file biovia_2019_.ds2019client.bin resturns "/bin/sh script" that
would be almost sure. In that case try

bash ./biovia_2019.ds2019client.bin to force bash interpreter

Re: Problem Installing DiscoveryStudio2019 in Buster

[Greg Wooledge]

On Mon, Jul 08, 2019 at 02:40:18PM -0400, Stephen P. Molnar wrote:
> I have just installed Buster and have encountereda  a problem attempting the
> installation of biovia_2019_.ds2019client.bin:
> 
> comp@AbNormal:~/Downloads/DiscoveryStudio$ ./biovia_2019.ds2019client.bin
> Verifying archive integrity...  100%   All good.
> Uncompressing 'DS Client and extracting files, please wait ..' 100%
> ./install_DSClient.sh: 49: ./install_DSClient.sh: [[: not found
> ./install_DSClient.sh: 70: ./install_DSClient.sh: Syntax error: redirection
> unexpected
> Press Return to close this window...

Whoever wrote this shell script does not know what they're doing.  You've
uncovered 2 bugs in it already.  There are probably a few hundred more.

As a workaround, because you do not have direct access to the script
(apparently it's in the downloaded payload), you may have to change
your /bin/sh symlink to point to bash instead of dash.  You may either
leave it there, or change it back, after this is done.

I would give serious consideration to finding a non-broken alternative
to whatever this thing is, except there probably isn't any alternative,
and you're stuck with it.

Problem Installing DiscoveryStudio2019 in Buster

[Stephen P. Molnar]

I have just installed Buster and have encountereda  a problem attempting 
the installation of biovia_2019_.ds2019client.bin:


comp@AbNormal:~/Downloads/DiscoveryStudio$ ./biovia_2019.ds2019client.bin
Verifying archive integrity...  100%   All good.
Uncompressing 'DS Client and extracting files, please wait ..' 100%
./install_DSClient.sh: 49: ./install_DSClient.sh: [[: not found
./install_DSClient.sh: 70: ./install_DSClient.sh: Syntax error: 
redirection unexpected

Press Return to close this window...

And not too surprising, Press Return did close the window.

Anyone have any ideas as to a solution?

Thanks in advance.

--
Stephen P. Molnar, Ph.D.Life is a fuzzy set
http://www.Molecular-Modeling.net   Multivariate and stochastic
614.312.7528 (c)
Skype:  smolnar1

Re: DPMS ( OT: Jonas)

[Christopher M]

Jonas,

Weird I got your reply via the website but I never got a reply via
email. 

Sorry for the triple send.. I wasnt sure if my messages were going
through or not.. I never got a reply back saying my messages went
through. 


Chris

Re: Assorted arm-buster problems - network configuration

[Brian]

On Sat 06 Jul 2019 at 18:14:04 -0400, Gene Heskett wrote:

> So I now have a working network. Free of the bogus inventions of dhcpd5 
> and avahi.  That _was_ the point of all this hoopla in the first place.
> 
> Now, I have learned what works to _my_ satisfaction.
> 
> Have you? Or did you quit reading the instant I went off the edge of your 
> menu?

No; I read it three times before going to bed. A good dose of fiction
helps me sleep better. :)

-- 
Brian.

RE: DPMS ( I had to rejoin the group hopefully my message goes through this time )

[Jonas Smedegaard]

Quoting Christopher M (2019-07-08 14:52:54)
> I am not sure if my message came through so I am sending it again:

Three duplicates is enough, thanks:

https://lists.debian.org/6565230fbe88f8f6db08b7ded2f149b7c6f8d37f.ca...@cwm030.com
https://lists.debian.org/fecde663e12ddafc9f02ba23b01b3eb15e434b36.ca...@cwm030.com
https://lists.debian.org/e2dc3ff0b9a3cd27bd9d55a4dc75f4bd5dfc2ff4.ca...@cwm030.com


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: aptitude new packages list forgets old

[Sven Joachim]

On 2019-07-08 19:21 +0200, Matus UHLAR - fantomas wrote:

> I am trying to look which packages are new in buster that were not in
> stretch. I am using aptitude since it't great tool for browsing packages.

Beware that the list of new packages in buster is way too large to
browse casually.  In main alone there are over 13,000 new binary
packages!

> until now it was easy:
>
> do 'f'orget new packages in aptitude
> change sources.list to point to new release
> do 'u'pdate packages list
> ... voila
>
> but now, when I do this, aptitude seems to forget all info about packages
> previously available.

Indeed.  I have seen this before, also when switching mirrors in
sources.list.  I seems that aptitude somehow forgets about the
previously available packages before it sees the one from the new
repository, which could be called a bug.

> What do I wrong? Thanks

I don't think you did actually anything wrong, since what you did ought
to work.  To work around that, you could do either:

- run "apt update" rather than aptitude after you changed sources.list,
  or

- _add_ an entry for the new release in sources.list rather than
  replacing the current one (you may remove the old entry later).

If you want to actually do that now, you need to point back your
sources.list to stretch temporarily and run
"aptitude update && aptitude forget-new" before proceeding with one of
the above suggestions.

HTH,
Sven

Re: fix for no ssh

[Andy Smith]

Hi Curt,

On Mon, Jul 08, 2019 at 05:48:24PM -, Curt wrote:
> it "amounts to trusting that CPU manufacturer (perhaps with the
> insistence or mandate of a Nation State's intelligence or law
> enforcement agencies) has not installed a hidden back door to
> compromise the CPU's random number generation facilities."

Again, everyone using a popular CPU is already in that position.

Cheers,
Andy

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

Re: Assorted arm-buster problems - network configuration

[Andrei POPESCU]

On Lu, 08 iul 19, 13:37:26, Lee wrote:
> On 7/7/19, andreimpope...@gmail.com  wrote:
> 
> > The dangers are not at all obvious to me, possibly because I haven't
> > used it much (if at all).
> 
> Read the first three paragraph of the "Security Considerations" section
>   https://tools.ietf.org/html/rfc6762#section-21
> 
> Assuming everything on the network is a trusted host is a dangerous
> assumption, so paragraph 1 is N/A
> 
> Assuming a trusted host won't get hacked is a dangerous assumption, so
> paragraph 3 is N/A.
> 
> All that's left is paragraph 2 -- and uninstalling whatever software
> uses mDNS :)

Security is not a black/white thing, it's more like a balancing act.

In my opinion mDNS/zeroconf can make perfect sense in some environments 
and be a complete no-go in others.

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


signature.asc
Description: PGP signature

RE: DPMS ( I had to rejoin the group hopefully my message goes through this time )

[Christopher M]

--- Begin Message ---
I am not sure if my message came through so I am sending it again:



Hi,

In Deb 9 KDE on Deb 9 as soon as I logged in DPMS would be disabled and
my screen would not turn off. I would have to manually go into the
command line and run a line ( I forget what it was I ran) but basically
it was the command to enable DPMS which once enabled, the screen would
turn on and off... But if I was to log off or restart, DPMS would be
disabled again. 

I am writing to find out why this happens and how can I make DPMS
enabled on start by itself or writing out a script to automatically
enable DPMS on start. 

This problem is what is keeping me from using Debian... I really like
the OS. But this is my only hold up. This problem made me go back to
Kubuntu 18.04 until I can figure out why this is happening to me, and
find a way to fix my problem. 


Thanks in advance.
Chris

--- End Message ---

Re: buster changes vim mouse behavior again...

[Andrei POPESCU]

On Lu, 08 iul 19, 08:48:15, Dave Sherohman wrote:
> 
> Today I did a test install of buster, however, and found a new problem:
> It seems that buster's vim detects the middle-click and "helpfully" goes
> immediately into insert mode, meaning that ":set paste" and "O" are
> entered as part of the file contents rather than being processed as
> commands.

So far I haven't been able to make middle click reliably[1] paste into 
vim, but I attributed that to my unusual setup:

1. ssh from Chrome OS to a buster running screen.
2. Debian buster with LXDE on Crouton (basically a chroot under Chrome 
OS)

Same with neovim.

If you do figure out how it's supposed to work please do post on list.

[1] on rare occasions it does work, once. So far I was not able to find 
the pattern.

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


signature.asc
Description: PGP signature

Re: Assorted arm-buster problems - network configuration

[Lee]

On 7/7/19, Curt  wrote:
> On 2019-07-06, Lee  wrote:
>>
>> "an accident waiting to happen" was from me and I also gave the rfc
>> for mdns, so that's hardly "nothing of substance to support that
>
> I see. So the totality of the mdns rfc (*somewhat* more succinct than a
> 19th century Russian novelistic endeavor) is the substantive foundation
> of your sound technical argument that avahi and its daemons are "an
> accident waiting to happen" (whatever that means exactly, but I fear to
> ask because you might refer me to Webster's Unabridged or the L.A. phone
> book circa 1974, which would entrain just too much summer reading for
> me, friend, as I prefer to do my wading through the sea).

In other words, you didn't even take a quick peek at the security
considerations section.  Right?

Regards,
Lee

Re: fix for no ssh

[Curt]

On 2019-07-08, Andrei POPESCU  wrote:
>
>> Well, at the very least people should be informed who is likely to be
>> affected by the bug
>
> In my understanding a lot of daemons are affected. Would it make sense
> to (try to) list them all?

Well, then, you should make that explicit, viz. that almost everyone
risks waiting for minutes to hours booting due to entropy starvation
unless they are lucky enough to have a modern x86 CPU that supports the
RDRAND instruction, in which case Debian will effectuate by default a
workaround whose author, probably the leading expert in all things
random for the Linux OS named Theodore Ts'o, has stated clearly and
repeatedly is a BAD IDEA, because it "amounts to trusting that CPU
manufacturer (perhaps with the insistence or mandate of a Nation State's
intelligence or law enforcement agencies) has not installed a hidden
back door to compromise the CPU's random number generation facilities."

> I considered all of them. Ultimately I settled on none, because I only
> get about 5 seconds delay on my PINE A64+ (arm64):

I should be so lucky.

-- 
"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." From a recent article in *Nature*. Holy shit. 

Re: Lumière bleue des moniteurs led ?

[G2PC]

> Je cherche à savoir s'il existe un paquetage sous debian stretch 9.9.0 qui
> permet de filtrer efficacement la lumière bleue des moniteurs led.

F.Lux et Redshift :
https://wiki.visionduweb.fr/index.php?title=Installer_Configurer_Utiliser_des_logiciels_sur_GNU_Linux#F.lux

Re: Re : Lumière bleue des moniteurs led ?

[Eric Degenetais]

Éric Dégenètais

Le lun. 8 juil. 2019 19:26, Raphaël POITEVIN  a
écrit :

> hamster  writes:
> > Donc pour ne pas retarder l'endormissement, il faudrait ne plus
> > regarder d'écran 1 a 2 h avant de se coucher, ce que peu de monde fait.
> > Ou alors virer le bleu des écrans dès qu'il fait nuit.
>
> Le plus pertinent est de lire en Braille ! :-)
>

Pour ma part, le seul effet que j'ai ressenti en travaillant sur des écrans
aux couleurs réglées pour "reposer les yeux" (d'après l'utilisateur
habituel de la machine) c'est une gêne visuelle par perte de contraste qui
à la longue me donne des maux de crâne.

> --
> Raphaël
>
>

Re: Assorted arm-buster problems - network configuration

[Lee]

On 7/7/19, andreimpope...@gmail.com  wrote:
> On Sb, 06 iul 19, 15:36:37, Lee wrote:
>>
>> "an accident waiting to happen" was from me and I also gave the rfc
>> for mdns, so that's hardly "nothing of substance to support that
>> view."  If you're having trouble finding the rfc, it's here
>>   https://tools.ietf.org/html/rfc6762
>
> Care to elaborate though?

While reading about a security issue I came across the line "An
insecure protocol will eventually be exploited." - which sounds right
to me.  And the standard q for most security issues involving an
insecure protocol seems to be
q: how do i prevent  from happening?
a: by not allowing it in the first place.

Hopefully we're clear about my bias now :)

> The dangers are not at all obvious to me, possibly because I haven't
> used it much (if at all).

Read the first three paragraph of the "Security Considerations" section
  https://tools.ietf.org/html/rfc6762#section-21

Assuming everything on the network is a trusted host is a dangerous
assumption, so paragraph 1 is N/A

Assuming a trusted host won't get hacked is a dangerous assumption, so
paragraph 3 is N/A.

All that's left is paragraph 2 -- and uninstalling whatever software
uses mDNS :)

Regards,
Lee

aptitude new packages list forgets old

[Matus UHLAR - fantomas]

Hello,

I am trying to look which packages are new in buster that were not in
stretch. I am using aptitude since it't great tool for browsing packages.

until now it was easy:

do 'f'orget new packages in aptitude
change sources.list to point to new release
do 'u'pdate packages list
... voila

but now, when I do this, aptitude seems to forget all info about packages
previously available.

What do I wrong? Thanks

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Saving Private Ryan...
Private Ryan exists. Overwrite? (Y/N)

Re : Re : Lumière bleue des moniteurs led ?

[nicolas . patrois]

Le 08/07/2019 17:20:04, hamster a écrit :

> Est-ce de l'incompréhension ou bien carrément de la mauvaise foi ?

Pète un coup, ça ira mieux.
[…]

> Pour ceux qui veulent creuser le sujet, c'est par la :
> https://www.youtube.com/watch?v=AZBRng9L_pc

As-tu plutôt un texte à lire qu4une vidéo à regarder ?

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Re: Re : Lumière bleue des moniteurs led ?

[Raphaël POITEVIN]

hamster  writes:
> Donc pour ne pas retarder l'endormissement, il faudrait ne plus
> regarder d'écran 1 a 2 h avant de se coucher, ce que peu de monde fait.
> Ou alors virer le bleu des écrans dès qu'il fait nuit.

Le plus pertinent est de lire en Braille ! :-)
-- 
Raphaël

SSHFS : Une alerte est manquante sur l'état des droits de clé privée

[G2PC]

SSHFS : Une alerte est manquante sur l'état des droits de clé privée


Avis aux développeurs de paquets, pour corriger le bogue suivant, ouvert
sur le Github officiel du paquet SSHFS.


Je suis probablement mauvais, mais je crée mes clés privées sur le
serveur, après une première connexion avec un simple mot de passe.
Une fois cela fait, je copie le contenu de mes clés sur la machine locale.
Pour cela, je suis en mode graphique et je crée deux fichiers sur ma
machine: id_rsa_private et id_rsa.pub qui ont, par défaut, les droits 664.

Je remarque le message d'alerte suivant, avec SSH, lorsque je souhaite
me connecter avec mon utilisateur local simple, à l'aide de la clé privée:

ssh USER@SERVEUR -i /home/USERLOCAL/.ssh/SERVEUR/id_rsa_private

@
WARNING: UNPROTECTED PRIVATE KEY FILE!
@
Permissions 0664 for '/home/USERLOCAL/.ssh/SERVEUR/id_rsa_private' are
too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

On note ici la traduction de l'anglais vers le français : This private
key will be ignored. -> La clé privée est ignorée !


Avec ça, je comprends mieux!
J'ai identifié ce qui ressemble à un bogue, ou plutôt à un manque de
précision, sur SSHFS, mais, cela me semble important.


sshfs -o allow_other, IdentityFile = / home / USERLOCAL / .ssh / SERVEUR
/ id_rsa_private USERSERVEUR @ SERVEUR: / home / USERSERVEUR / FOLDER /
home / USERLOCAL / FOLDER

Si l'utilisateur qui se connecte est l'utilisateur root de la machine
locale, la phrase secrète est requise lors du montage de dossiers partagés.

Si l'utilisateur qui se connecte est un simple utilisateur de la machine
locale, le mot de passe de l'utilisateur sur le SERVEUR est demandé lors
du montage des dossiers partagés.
Attention ! Ce n'est pas le comportement normal! Si la clé privée qui
est copiée localement a les droits, 600, c'est la phrase secrète qui
sera demandée. C'est ce que nous voulons !


Donc, ici, SSHFS ne nous informe pas de la présence de la clé, qui
possède de mauvais droits, tout comme le fait SSH, lors d’une connexion
en tant que simple utilisateur local.
Pourtant, le comportement semble identique ! SSHFS va ignorer la clé
privée ! OUTCH :/

Je pense vraiment que SSHFS devrait être capable de mettre en garde sur
le problème des droits appliqués à la clé privée, de la même manière que
le fait déjà SSH.


https://github.com/libfuse/sshfs/issues/180

Re: Re : Lumière bleue des moniteurs led ?

[hamster]

Le 08/07/2019 à 18:55, elgueroe...@yahoo.fr a écrit :
>> Le lundi 8 juillet 2019 à 13:04:10 UTC+2, hamster
>>  a écrit :
>>
>> Pour la lumière bleue, il ne s'agit pas d'abimer les yeux mais d'activer
>> les recepteurs spécifiques au bleu qui sont derrière la rétine et qui
>> servent au corps a synchroniser l'horloge biologique avec le jour. Il
>> faut donc qu'il y ait du bleu en journée mais qu'il n'y en ait pas (ou
>> en tout cas beaucoup moins) après le coucher du soleil, sinon l'horloge
>> biologique reste en mode "jour" et ca peut provoquer des difficultés
>> d'endormissement.
>
> c'est un peu paradoxal ça: si tu veux dormir
> il vaut mieux ne pas regarder l'écran de l'ordi,
> bleu ou pas. Et si tu veux travailler sur l'ordi la nuit
> il vaut mieux ne pas avoir envie de dormir.

Est-ce de l'incompréhension ou bien carrément de la mauvaise foi ?

Je te laisse le bénéfice du doute et j'explique : l'horloge biologique
ne se met pas brusquement en mode "nuit" dès que tu éteins ton écran. De
plus, quand tu regarde des écrans avec beaucoup de bleu, la sensation de
sommeil ne viens pas quand il commence a se faire tard, du coup tu a
tendance a continuer a rester sur l'écran faute d'avoir envie d'aller te
coucher. Donc pour ne pas retarder l'endormissement, il faudrait ne plus
regarder d'écran 1 a 2 h avant de se coucher, ce que peu de monde fait.
Ou alors virer le bleu des écrans dès qu'il fait nuit.

Pour ceux qui veulent creuser le sujet, c'est par la :
https://www.youtube.com/watch?v=AZBRng9L_pc

Re: Re : Lumière bleue des moniteurs led ?

[elgueroeric]

 

Le lundi 8 juillet 2019 à 13:04:10 UTC+2, hamster  a écrit 
:

Pour la lumière bleue, il ne s'agit pas d'abimer les yeux mais d'activer
les recepteurs spécifiques au bleu qui sont derrière la rétine et qui
servent au corps a synchroniser l'horloge biologique avec le jour. Il
faut donc qu'il y ait du bleu en journée mais qu'il n'y en ait pas (ou
en tout cas beaucoup moins) après le coucher du soleil, sinon l'horloge
biologique reste en mode "jour" et ca peut provoquer des difficultés
d'endormissement.


c'est un peu paradoxal ça: si tu veux dormir
il vaut mieux ne pas regarder l'écran de l'ordi,
bleu ou pas. Et si tu veux travailler sur l'ordi la nuit
il vaut mieux ne pas avoir envie de dormir.

e.e.
  

Re: fix for no ssh

[Andy Smith]

Hello,

On Mon, Jul 08, 2019 at 04:18:28PM -, Curt wrote:
> Well, looking at Ted Ts'o short patch, where he mentions the security
> implications of the thing at some length, *twice*

I think that some of Ted's stance might not be because Ted thinks it
is dangerous but because there has been in the past very vocal
opposition to any use of RDRAND, given that it is part of the
unauditable innards of the CPU.

> and reading the following from Ts'o circa 2013:
> 
> https://daniel-lange.com/documents/130905_Ted_Tso_on_RDRAND.pdf
> 
>  I am so glad I resisted pressure from Intel engineers to let /dev/random
>  rely only on the RDRAND instruction.

Note that relying *only* on RDRAND and using RDRAND as *one* of the
entropy sources are different situations.

Cheers,
Andy

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

Re: Re : Re : Lumière bleue des moniteurs led ?

[Eric Degenetais]

Personnellement, j'aimerais bien une démonstration autre que le
matériel publicitaire des opticiens ATOLL pour leurs lunettes
anti-bleu que l'intensité de la lumière bleue en question est
suffisante pour tromper le système nerveux. L'intensité lumineuse d'un
cran LED est quand même sacrément inférieure à celle du soleil.

Cordialement
__
Éric Dégenètais

Le lun. 8 juil. 2019 à 14:11,  a écrit :
>
> Le 08/07/2019 11:03:52, hamster a écrit :
>
> > PS : tu pourrais te renseigner ou demander pour quelle raison on veut
> > faire ça avant de décréter de façon lapidaire que ça sert a rien alors
> > que tu sais même pas de quoi tu parle.
>
> J’y peux rien si la demande initiale n’est pas claire non plus.
>
> nicolas patrois : pts noir asocial
> --
> RÉALISME
>
> M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains 
> ? Un cerveau plus gros ?
> P : Non... Une carte bleue suffirait...
>

Re: configuration du serveur smtp.gmail.com

[Basile Starynkevitch]

On 7/8/19 5:33 PM, Pierre Frenkiel wrote:

bonjour,
Je voudrais utiliser le serveur smtp.gmail.com pour envoyer des mails
(via alpine). J'ai la config suivante dans .alpinerc

   smtp-server=smtp.gmail.com:587/tls/user=pierre.frenkiel



Si on raisonne non pas au niveau du choix d'un logiciel comme alpine 
(que je ne connais pas) mais au niveau du problème posé (envoyer sur un 
PC Linux un courriel via smtp.gmail.com sans taper de mot de passe), 
alors le récent mais fort long fil de discussion 
https://lists.debian.org/debian-user-french/2019/07/msg00077.html répond 
à cette question.



Mais il y a probablement d'autres contraintes implicites. Où alors 
l'utilisation spécifique de alpine est très importante. Car il y a 
d'autres MUA  équivalents en 
fonctionalité (pas en "look & feel"), notamment mutt.



Librement


--
Basile STARYNKEVITCH   == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France; 
(mobile phone: cf my web page / voir ma page web...)

Re: fix for no ssh

[Andrei POPESCU]

On Lu, 08 iul 19, 10:19:35, Curt wrote:
> 
> I thought you were saying that
> '/etc/udev/rules.d/70-persistent-net.rules' remains a valid mechanism
> for defining interface names in Buster (fixed). But the release-notes
> (hmm, I think they've been modified since I last looked and now state
> that that file is no longer "officially" supported by udev---but may
> work in some cases). So I wouldn't be filing a bug report against that
> stanza any longer, as current situation seems unverifiable. 
 
For the record, the current wording (no official support) is based on 
input from the Debian systemd maintainers. They should know what is 
supported or not ;)

As far as I know the /etc/udev/rules.d/70-persistent-net.rules method 
can fail to properly rename the interfaces in certain situations which 
can leave your system without networking.

Not nice on remote machines.

It is also my understanding that systems with only one interface (of a 
given type[1]) are pretty safe with it or net.ifnames=0, so the impact 
on regular[2] desktop/laptop users should be minimal.

[1] assuming ethernet cards are always named ethX and wireless cards are 
always named wlanX by the kernel. I might have had a wireless card that 
came up as ethX, but that was a long time ago. Still, something to be 
aware of.

[2] one ethernet interface, usually integrated in the motherboard and 
one (additional) wireless interface for the laptops. Anything more 
complicated than that might break without warning.

> Well, at the very least people should be informed who is likely to be
> affected by the bug

In my understanding a lot of daemons are affected. Would it make sense 
to (try to) list them all?

> and for those using amd64 how to check for the RDRAND
> instruction, 

I agree that checking for the RDRAND instruction would indeed be a good 
addition. Someone (tm) needs to do the research and come up with a 
patch.

As I currently don't own any amd64 systems I can only offer to support 
with the wording, process of submitting the patch, etc.

> as well as what to do about it if they don't have it (that's what I'd 
> like to know, at any rate).

haveged is mentioned in the Release Notes.

jitterentropy-rngd was mentioned here on list as a newer alternative to 
haveged.

Using an external hardware random generator is another option I know of, 
possibly the most secure, if you trust the implementation.

I considered all of them. Ultimately I settled on none, because I only 
get about 5 seconds delay on my PINE A64+ (arm64):

amp@pine64:~$ sudo dmesg | grep 'random.*done'
[6.785377] random: fast init done
[   11.632783] random: crng init done


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


signature.asc
Description: PGP signature

Re: fix for no ssh

[Curt]

On 2019-07-08, Greg Wooledge  wrote:
>
> I don't have any opinions at this time about the trustworthiness of
> various x86 CPU RDRAND instructions, but...

Well, looking at Ted Ts'o short patch, where he mentions the security
implications of the thing at some length, *twice*---once in the "intro"
I quoted, and once again in the comments of the patch itself, where he
says

 Since this is not something that can be independently audited, this
 amounts to trusting that CPU manufacturer (perhaps with the insistence
 or mandate of a Nation State's intelligence or law enforcement
 agencies) has not installed a hidden back door to compromise the CPU's
 random number generation facilities.

and reading the following from Ts'o circa 2013:

https://daniel-lange.com/documents/130905_Ted_Tso_on_RDRAND.pdf

 I am so glad I resisted pressure from Intel engineers to let /dev/random
 rely only on the RDRAND instruction.   To quote from the article below:
"By this year, the Sigint Enabling Project had found ways inside some of
 the encryption chips that scramble information for businesses and
 governments, either by working with chipmakers to insert back doors"
 Relying solely on the hardware random number generator which is using an
 implementation sealed inside a chip which is impossible to audit is a
 BAD idea
(quoted article "N.S.A. Foils Much Internet Encryption" from nytimes.com)

the opinion I form is this is dishonest and wrong of Debian, *as things
now stand and to my knowledge of the workaround and the Buster
release-notes describing it*, to implement a default, exclusive reliance
on the RNG of a closed-source, black-box cpu, without clearly spelling
out the grave security concerns attached to this reliance (I'd like to
see a direct quote of Theodore Ts'o in the release-notes, who, after
all, is the authority in this matter.

> What on earth happened to simply saving entropy on disk across reboots?

This is the very "insecurity" (entropy saved across boot) which systemd
strived to get rid of, as I understand it (thus the problem).

-- 
"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." From a recent article in *Nature*. Holy shit. 

Re: fix for no ssh

[Andy Smith]

Hello,

On Mon, Jul 08, 2019 at 02:40:16PM -, Curt wrote:
> But as an innate altruist (just kidding), I'm wondering whether the
> regular user is aware of the implications of all this. What about people
> in Nation States ...  Well, you get the idea.

Thing is, if you can't trust that your CPU's implementation of
RDRAND hasn't been compromised then how can you trust that any other
aspect of your CPU hasn't been compromised?

Every Intel CPU contains a whole other operating system (Minix) and
no one outside of Intel knows exactly what it does. The situation
will not be markedly better at AMD.

Personally I use RDRAND and also hardware entropy sources
(EntropyKey and OneRNG).

Cheers,
Andy

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

Please consider the environment before reading this e-mail.
 — John Levine

Re: Failed to fetch http://ftp.us.debian.org/debian/dists/buster/InRelease:

[Jonas Smedegaard]

Quoting local10 (2019-07-08 12:49:19)
> Jul 8, 2019, 11:27 AM by mailingli...@mattcrews.com:
> 
> > Use "apt update" instead of "aptitude update" or "apt-get update"
> >
> > Specifically you want to:
> >
> > # apt update && apt upgrade && apt full-upgrade
> >
> 
> I normally use aptitude instead of apt and would prefer to continue 
> using it, if possible. aptitude was working fine until July 7 or so. 
> Also, I'm already running Buster so "full-upgrade" shouldn't be 
> necessary for me. Tried "full-upgrade" with aptitude just to see if 
> anything would change, still getting the same errors.

You can (like me!) continue to use aptitude - only need for apt seems to 
be to trigger an interactive approval of switching from testing to 
stable.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: [OT] Trustfulness. Was: Re: fix for no ssh

[Reco]

Hi.

On Mon, Jul 08, 2019 at 05:57:49PM +0200, Thomas Schmitt wrote:
> Hi,
> 
> Curt quoted:
> >  This will prevent getrandom(2) from blocking, if there is a
> >  willingness to trust the CPU manufacturer.
> >  Signed-off-by: Theodore Ts'o 
> 
> Apropos trusting strange allies:
> 
>   # mount debian-10.0.0-amd64-netinst.iso /mnt/iso
>   mount: /dev/loop0 is write-protected, mounting read-only
>   # mount /mnt/iso/boot/grub/efi.img /mnt/fat
>   # strings /mnt/fat/efi/boot/bootx64.efi | fgrep Microsoft | wc -l
>   43
> 
> It is futile to change the table cloth before the pig is out of the soup
>   http://iartprints.com/uploadpic/michael_sowa/big/pig_in_soup.jpg

rgrep Microsoft /lib/modules

Even if you're not using UEFI, they are still there :)

Reco

[RESOLVED] Re: Failed to fetch http://ftp.us.debian.org/debian/dists/buster/InRelease:

[local10]

Jul 8, 2019, 11:55 AM by svenj...@gmx.de:

> You only have to run "apt update" once and affirm the questions it asks,
> then aptitude will run fine again.  See bug #915246[1] and its siblings.
>

That resolved the issue for me. Thanks to everyone who responded.

[OT] Trustfulness. Was: Re: fix for no ssh

[Thomas Schmitt]

Hi,

Curt quoted:
>  This will prevent getrandom(2) from blocking, if there is a
>  willingness to trust the CPU manufacturer.
>  Signed-off-by: Theodore Ts'o 

Apropos trusting strange allies:

  # mount debian-10.0.0-amd64-netinst.iso /mnt/iso
  mount: /dev/loop0 is write-protected, mounting read-only
  # mount /mnt/iso/boot/grub/efi.img /mnt/fat
  # strings /mnt/fat/efi/boot/bootx64.efi | fgrep Microsoft | wc -l
  43

It is futile to change the table cloth before the pig is out of the soup
  http://iartprints.com/uploadpic/michael_sowa/big/pig_in_soup.jpg


Have a nice day :)

Thomas

Re: Failed to fetch http://ftp.us.debian.org/debian/dists/buster/InRelease:

[Sven Joachim]

On 2019-07-08 17:49 +0200, local10 wrote:

> Jul 8, 2019, 11:27 AM by mailingli...@mattcrews.com:
>
>> Use "apt update" instead of "aptitude update" or "apt-get update"
>>
>> Specifically you want to:
>>
>> # apt update && apt upgrade && apt full-upgrade
>>
>
> I normally use aptitude instead of apt and would prefer to continue
> using it, if possible.

You only have to run "apt update" once and affirm the questions it asks,
then aptitude will run fine again.  See bug #915246[1] and its siblings.

Cheers,
   Sven


1. https://bugs.debian.org/915246

Re: Failed to fetch http://ftp.us.debian.org/debian/dists/buster/InRelease:

[Greg Wooledge]

On Mon, Jul 08, 2019 at 05:49:19PM +0200, local10 wrote:
> I normally use aptitude instead of apt and would prefer to continue using it, 
> if possible. aptitude was working fine until July 7 or so. Also, I'm already 
> running Buster so "full-upgrade" shouldn't be necessary for me. Tried 
> "full-upgrade" with aptitude just to see if anything would change, still 
> getting the same errors.

You only have to do the "apt update" one time, to get the prompt to
accept the changes.  After that you can go back to your regular tools.

Re: Failed to fetch http://ftp.us.debian.org/debian/dists/buster/InRelease:

[local10]

Jul 8, 2019, 11:27 AM by mailingli...@mattcrews.com:

> Use "apt update" instead of "aptitude update" or "apt-get update"
>
> Specifically you want to:
>
> # apt update && apt upgrade && apt full-upgrade
>

I normally use aptitude instead of apt and would prefer to continue using it, 
if possible. aptitude was working fine until July 7 or so. Also, I'm already 
running Buster so "full-upgrade" shouldn't be necessary for me. Tried 
"full-upgrade" with aptitude just to see if anything would change, still 
getting the same errors.

Thanks

configuration du serveur smtp.gmail.com

[Pierre Frenkiel]

bonjour,
Je voudrais utiliser le serveur smtp.gmail.com pour envoyer des mails
(via alpine). J'ai la config suivante dans .alpinerc

   smtp-server=smtp.gmail.com:587/tls/user=pierre.frenkiel

ça marche, à ceci près que je dois entrer le mot de passe à chaque envoi.
Y a-t-il un moyen d'indiquer ce mot de passe dans la config?

Cordialement,
--
Pierre Frenkiel

Re: fix for no ssh

[Greg Wooledge]

On Mon, Jul 08, 2019 at 02:40:16PM -, Curt wrote:
> Earlier I thought bullseye was some sort of idiom for Buster going live.
> Color me ignorant. 

Bullseye will be the next version of Debian after buster, probably in
2-3 years.  Cue the confusion about two similar-looking release names
back to back.

> So Debian Buster, as it now stands and I understand it, trusts in the
> correctness of the hardware random number generator, as well as in the
> absence of any back door that might compromise it, universally and
> without qualification, of every Debian Buster user's x86 cpu (default
> kernel command line CONFIG_RANDOM_TRUST_CPU), in the name of security.
> 
> That's a safer solution than installing haveged? 

I don't have any opinions at this time about the trustworthiness of
various x86 CPU RDRAND instructions, but...

What on earth happened to simply saving entropy on disk across reboots?
Why isn't there an option simply to do that?  I get that it may be an
issue for certain kinds of virtual machines, but I give less than one
crap about virtual machines.  Can I get the previous sensible behavior
as an option for my physical machines?

Re: Failed to fetch http://ftp.us.debian.org/debian/dists/buster/InRelease:

[Matthew Crews]

On 7/8/19 8:23 AM, local10 wrote:
> Hi,
> 
> Debian Buster updates started failing for me about a couple of days ago. I 
> understand it may be related to  Buster being moved from testing to stable 
> but that shouldn't have affected me as I specifically target buster instead 
> of testing.
> 
> Any ideas? Thanks

Use "apt update" instead of "aptitude update" or "apt-get update"

Specifically you want to:

# apt update && apt upgrade && apt full-upgrade




signature.asc
Description: OpenPGP digital signature

Failed to fetch http://ftp.us.debian.org/debian/dists/buster/InRelease:

[local10]

Hi,

Debian Buster updates started failing for me about a couple of days ago. I 
understand it may be related to  Buster being moved from testing to stable but 
that shouldn't have affected me as I specifically target buster instead of 
testing.

Any ideas? Thanks


# aptitude update && aptitude safe-upgrade --show-versions --purge-unused
Get: 1 http://ftp.us.debian.org/debian  buster 
InRelease [118 kB]
Get: 2 http://security.debian.org  buster/updates 
InRelease [39.1 kB]
Fetched 118 kB in 2s (73.7 kB/s)  
E: Repository 'http://ftp.us.debian.org/debian 
 buster InRelease' changed its 'Suite' value 
from 'testing' to 'stable'
E: Repository 'http://security.debian.org  
buster/updates InRelease' changed its 'Suite' value from 'testing' to 'stable'
E: Failed to download some files
W: Failed to fetch http://ftp.us.debian.org/debian/dists/buster/InRelease 
:
W: Failed to fetch http://security.debian.org/dists/buster/updates/InRelease 
:
E: Some index files failed to download. They have been ignored, or old ones 
used instead.


# cat /etc/apt/sources.list

#deb cdrom:[Debian GNU/Linux testing _Buster_ - Official Snapshot amd64 DVD 
Binary-1 20180820-04:16]/ buster contrib main
deb http://ftp.us.debian.org/debian/  buster 
main non-free
deb http://security.debian.org/  buster/updates 
main non-free

Displaylink issue after upgrading to Buster

[janm]

Hi

One of my monitors is connected via Displaylink, USB 2.0. This has always 
worked perfectly but on upgrading to Buster, that monitor now only comes up 
with screen corruption. Error messages from journalctl:

jul 08 15:46:14 debian kernel: udl 3-1.4.1:1.0: swiotlb buffer is full (sz: 
360448 bytes)
jul 08 15:46:14 debian kernel: udl 3-1.4.1:1.0: DMA: Out of SW-IOMMU space for 
360448 bytes
jul 08 15:46:20 debian kernel: udl 3-1.4.1:1.0: swiotlb buffer is full (sz: 
1245184 bytes)
jul 08 15:46:20 debian kernel: udl 3-1.4.1:1.0: DMA: Out of SW-IOMMU space for 
1245184 byte

Downgrading to an older kernel removes the error messages, but also leaves the 
monitor blank.

Since this is pretty annoying, I would like to help solve this. However, I've 
no clue what to file a bug against. Any hint would be very appreciated.

Kind regards

Jan

Re: fix for no ssh

[Curt]

On 2019-07-08, Andrei POPESCU  wrote:
>
> The timing was also not very good for the buster release cycle.
> Hopefully this will be sorted out properly in time for bullseye.

Earlier I thought bullseye was some sort of idiom for Buster going live.
Color me ignorant. 

But concerning the currently proposed workaround for x86 CPU's (from
which I cannot "benefit," apparently), it's edifying to note what Ted
himself said about his own patch:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=39a8883a2b989d1d21bd8dd99f5557f0c5e89694

 random: add a config option to trust the CPU's hwrng

 This gives the user building their own kernel (or a Linux distribution)
 the option of deciding whether or not to trust the CPU's hardware
 random number generator (e.g., RDRAND for x86 CPU's) as being correctly
 implemented and not having a back door introduced (perhaps courtesy of
 a Nation State's law enforcement or intelligence agencies).

 This will prevent getrandom(2) from blocking, if there is a
 willingness to trust the CPU manufacturer.

 Signed-off-by: Theodore Ts'o 

So Debian Buster, as it now stands and I understand it, trusts in the
correctness of the hardware random number generator, as well as in the
absence of any back door that might compromise it, universally and
without qualification, of every Debian Buster user's x86 cpu (default
kernel command line CONFIG_RANDOM_TRUST_CPU), in the name of security.

That's a safer solution than installing haveged? 

I know, I know, I can use any kernel command line I want. I could switch
to another distribution without these problems. I could go fuck myself.
But as an innate altruist (just kidding), I'm wondering whether the
regular user is aware of the implications of all this. What about people
in Nation States ...  Well, you get the idea.

> Kind regards,
> Andrei


-- 
"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." From a recent article in *Nature*. Holy shit. 

Re: Assorted arm-buster problems - network configuration

[David Wright]

On Mon 08 Jul 2019 at 08:36:38 (-0400), Greg Wooledge wrote:
> On Sat, Jul 06, 2019 at 08:46:19AM -0500, David Wright wrote:
> > On Fri 05 Jul 2019 at 20:10:42 (-0400), Gene Heskett wrote:
> > > But that begs another question Greg.  If it hasn't anything to do with 
> > > avahi-daemon, whyinhell did purging avahi-daemon take the libnsswitch 
> > > package with it?
> 
> > I'm puzzled too. Can you tell us which package you're talking about as
> > I can only find:
> > 
> > Package lib32nss-mdns
> > Package libnss3
> [snip]
> 
> I'm pretty sure Gene means this one:
> 
> wooledg:~$ apt-cache show avahi-daemon | grep libnss
> Recommends: libnss-mdns
> 
> As I demonstrated somewhere else in this thread,[1] removing avahi-daemon
> also removes libnss-mdns, and installing avahi-daemon also installs
> libnss-mdns, at least when using apt with whatever settings I'm currently
> using.  Which are probably pretty close to the defaults.
> 
> [1] https://lists.debian.org/debian-user/2019/07/msg00258.html

Yes, thanks for that; posting saves others from having to test what's
going on. I guess we should hardly be surprised. So the Debian system
that's allegedly completely broken (and has been "nuked" into who
knows what shape) turns out to be not a Debian system at all. Such a
waste of time.

Cheers,
David.

buster changes vim mouse behavior again...

[Dave Sherohman]

Last time around, stretch changed mouse behavior in vim by setting
"mouse=a" by default.  To deal with this, my checklist for stretch
updates/installs includes

---
vi /etc/vim/vimrc.local
:set mouse=
:set paste
O
" Don't silently ignore these settings in favor of those in default.vim
let g:skip_defaults_vim = 1

" Middle-mouse should paste from X clipboard, NOT vim clipboard!
set mouse=
---

I copy (mouse highlight)/paste (middle-click) the first line into my
terminal, manually type the first `:set mouse=`, and then copy/paste the
rest of it.

Works great in stretch.

Today I did a test install of buster, however, and found a new problem:
It seems that buster's vim detects the middle-click and "helpfully" goes
immediately into insert mode, meaning that ":set paste" and "O" are
entered as part of the file contents rather than being processed as
commands.

I suppose that's handy for simple cases like this, where I ultimately am
just inserting text into a file, but I also frequently want to run the
same command in vim on a couple dozen different files, so it's really
handy to be able to paste commands into the vim window and have the
command executed instead of being inserted into the file's content.

So how do I bring back the old behavior?

In addition to ":set mouse=", I've also tried ":set ttymouse=" and
":set sessionoptions-=terminal", but these had no effect on this
behavior.



Crossposting notice:  I have also posted this question on the vi/vim
stack exchange site at
https://vi.stackexchange.com/questions/20548/allow-pasting-into-all-modes-not-just-insert

-- 
Dave Sherohman

firefox 67

[Gérard Sarram]

Bonjour,
Ce message n'a pas été transmis. Mes excuses à ceux qui avaient répondu au
1er post.

bonjour,
@F.Mescam
oui, j'ai utilisé ce site, mais une fois décompressé pas de .config

@JC.Etiemble
gdebi est installé chez-moi, mais retour de l'installateur: "la dépendance
ne peut être satisfaite libc6 est à une version antérieure à 2.28"

@ basile starynkevitch
oui je crois que c'est la seule solution, mais je souhaite rester en stable.
Ma version actuelle de firefox est 60.7.2esr. Peut-être est-ce suffisant
pour éviter la faille de sécurité annoncée il y a quelque temps
merci à tous

Ma conclusion : je reste avec FF version 60.7.2 qui semble n'être plus
affectée par la faille de sécurité
gesar

Re: interface web à ssh + scp

[Pierre Malard]

Salut,

Je crois que l’option « soft » est la plus « gentille » effectivement. Par 
contre, si cela pose problème quand même, tu peux travailler en NFSv4 sur TCP 
avec une valeur « retrans » plus grande. Il va te falloir lire la section « 
TRANSPORT METHODS » du man…

Mais, ceci étant, tant que t achète et tendre n’utilisera pas le montage de 
restauration elle ne devrait pas avoir trop de messages foireux ou de blocages 
si tu utilise l’option « soft ». Il n’y aura de « NFS time out still trying… » 
qui tue que si elle va dessus alors que son câble est débranché.

Sinon, l’autre solution serait d’ouvrir un partage CIFS/SMB mais là, cela 
signifie également l’installation d’un serveur Samba avec toute la légèreté du 
truc et, question performances, ce n’est pas NFS…

Désolé de ne pas pouvoir t’aider plus.

> Le 7 juil. 2019 à 16:33, Basile Starynkevitch  a 
> écrit :
> 
> 
> 
> On 7/7/19 3:51 PM, Basile Starynkevitch wrote:
>> 
>> On 7/7/19 11:32 AM, Pierre Malard wrote:
>>> Bonjour,
>>> 
>>> Je ne veux pas m’immiscer dans les scènes de ménages ;-) mais je vais 
>>> tenter de répondre à la dernière partie sur l’interface de transfert. C’est 
>>> peut-être par un biais que tu peux résoudre ton problème ; enfin espérons 
>>> le…
>>> Nous avons a peu près le même problème sur le réseau dont on s’occupe et je 
>>> pense qu’on a apporté une réponse aux recherches dans les sauvegardes de 
>>> façon opérationnelle. Nous sauvegardons le contenu des « home dir » de nos 
>>> utilisateurs (qui se trouvent sur un serveur sous Linux) offrant un partage 
>>> NFS/Samba et souhaitions qu’il puissent seuls récupérer leurs sauvegardes 
>>> simplement sans besoin d’ajouter le moindre outil spécial et quelque soit 
>>> l’OS sous lequel ils travaillent. Dis nous si cela peu convenir à ton cas.
>> Oui, probablement. Le point technique est peut-être l'option intr du montage 
>> NFS. Il faut que ma chère et tendre puisse travailler sur ses fichiers même 
>> si le cable Ethernet est coupé (oiu débranché par maladresse).
> 
> Ah, le poids des ans, et la vieillesse. L'option intr (voir nfs(5) 
>  pour les détails) est 
> abandonnée depuis le noyau linux 2.6.25... Il y a des jours où je me sens 
> vieux :-[ C'est dur de vieillir :-)
> 
> Pour les vieux comme moi, je pensais (sauf si je suis devenu gâteux, à mon 
> grand âge :-), c'est à considérer sérieusement ;-) ) à l'option intr du 
> montage NFS de SunOS4
> 
> En Linux moderne, j'ai mis dans le /etc/fstab de la machine hermes (sous 
> Ubuntu 18.04) de ma chère épouse
> 
> ## rimski est l' ordinateur de Basile bureau rose
> ## dessus /xtra contient la sauvegarde
> rimski:/xtra /Rimski_Xtra nfs nfsvers=3,bg,ro,nolock,soft,fsc
> 
> Ca convient, comme remplacement approximatif de feu l'option intr ? Plus 
> prosaïquement, je cherche un montage NFS qui soit gentil vis à vis des 
> occasionnels mais peu évitables débranchements intempestifs de câble 
> Ethernet. Je dois publiquement avouer que ma chère épouse est plus maniaque 
> que moi de l'aspirateur :-) mais nul n'est parfait.
> 
> Librement
> 
> 
> 
> --
> 
> Basile STARYNKEVITCH   == http://starynkevitch.net/Basile 
> 
> opinions are mine only - les opinions sont seulement miennes
> Bourg La Reine, France;  
> 
> (mobile phone: cf my web page / voir ma page web...)

--
Pierre Malard

   « La vérité ne triomphe jamais, mais ses ennemis finissent
toujours par mourir... »
   Max Placnk (1858-1947)
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: From Buster RC2 to Buster stable

[Greg Wooledge]

On Sun, Jul 07, 2019 at 11:51:56AM +1200, Richard Hector wrote:
> E: Repository 'http://security.debian.org/debian-security buster/updates
> InRelease' changed its 'Suite' value from 'testing' to 'stable'
> N: This must be accepted explicitly before updates for this repository
> can be applied. See apt-secure(8) manpage for details.

> Unfortunately, apt-secure(8) doesn't appear to tell me _how_ to accept
> this change ...

Yeah, it's the worst "helpful" error message I've seen in a long time.

I ended up googling the error message, and stumbled across a web forum
post somewhere that had the necessary hint ("use apt instead, and it
will prompt you").  Then I added that to the NewInBuster wiki page, so
hopefully some other people will see it and benefit from it.

Re: xfce4-screenshooter does not copy images to clipboard

[Curt]

On 2019-07-07, Erik Dobák  wrote:
>
> same behavior with xclip -o --selection clip-board > clip10.txt
>

I think you must pipe the primary to the clipboard before redirecting
the clipboard to a file.

xclip -o | xclip -sel clip > clip10.txt

https://github.com/astrand/xclip

I was unaware of this program. Interesting tool.

-- 
"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." From a recent article in *Nature*. Holy shit. 

Re: etiquette of sharing executable files

[Greg Wooledge]

On Sun, Jul 07, 2019 at 12:06:36PM +0200, Nicolas George wrote:
> DO NOT TRY TO SECOND-GUESS THE USER.

While I absolutely agree with that, I would also add:

DO SENSIBLE THINGS BY DEFAULT.

That is, if the user doesn't tell you what to do, try to do the most
common, or the safest, thing.  But if the user explictly tells you to
do something, you do it.

Nuking a pre-existing directory's files, for example, is not a sensible
thing to do by default.  BUT, if the user uses the --wipe-files option
with the --directory /home/me option, then by all means, nuke those files.

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Monday 08 July 2019 08:36:38 Greg Wooledge wrote:

> On Sat, Jul 06, 2019 at 08:46:19AM -0500, David Wright wrote:
> > On Fri 05 Jul 2019 at 20:10:42 (-0400), Gene Heskett wrote:
> > > But that begs another question Greg.  If it hasn't anything to do
> > > with avahi-daemon, whyinhell did purging avahi-daemon take the
> > > libnsswitch package with it?
> >
> > I'm puzzled too. Can you tell us which package you're talking about
> > as I can only find:
> >
yes, thats the one

> > Package lib32nss-mdns
> > Package libnss3
>
> [snip]
>
> I'm pretty sure Gene means this one:
>
> wooledg:~$ apt-cache show avahi-daemon | grep libnss
> Recommends: libnss-mdns
>
> As I demonstrated somewhere else in this thread,[1] removing
> avahi-daemon also removes libnss-mdns, and installing avahi-daemon
> also installs libnss-mdns, at least when using apt with whatever
> settings I'm currently using.  Which are probably pretty close to the
> defaults.
>
> [1] https://lists.debian.org/debian-user/2019/07/msg00258.html

ditto's here. But I think I'll disable the kernel pinning until such time 
as I get a realtime built and installed.

Thanks Greg.

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: will Release come back for testing/updates at security.debian.org?

[songbird]

Andrei POPESCU wrote:
> On Du, 07 iul 19, 08:23:59, songbird wrote:
>>   with the change to testing the past day the error message pops up:
>>=20
>> E: The repository 'http://security.debian.org/debian-security testing/upd=
> ates Release' no longer has a Release file.
>
> Not sure why you even have 'security' for testing in your sources.list=20
> as all security updates migrate from unstable.
>
> https://www.debian.org/security/faq#testing

  i'm sure it is there because at some point someone said
to pick up security updates to testing that way.  i don't
normally follow a lot of packages in unstable or stable.

  if i understand the information on that page correctly
it implies that security updates come via unstable but
what about those done by the security team for packages
in testing and during freezes?  just in case someone 
does poke something to that repository in testing i'd 
like to pick it up when it happens.

  if it never happens then that repository should be
removed IMO.


  songbird

Re: Assorted arm-buster problems - network configuration

[Greg Wooledge]

On Sat, Jul 06, 2019 at 08:46:19AM -0500, David Wright wrote:
> On Fri 05 Jul 2019 at 20:10:42 (-0400), Gene Heskett wrote:
> > But that begs another question Greg.  If it hasn't anything to do with 
> > avahi-daemon, whyinhell did purging avahi-daemon take the libnsswitch 
> > package with it?

> I'm puzzled too. Can you tell us which package you're talking about as
> I can only find:
> 
> Package lib32nss-mdns
> Package libnss3
[snip]

I'm pretty sure Gene means this one:

wooledg:~$ apt-cache show avahi-daemon | grep libnss
Recommends: libnss-mdns

As I demonstrated somewhere else in this thread,[1] removing avahi-daemon
also removes libnss-mdns, and installing avahi-daemon also installs
libnss-mdns, at least when using apt with whatever settings I'm currently
using.  Which are probably pretty close to the defaults.

[1] https://lists.debian.org/debian-user/2019/07/msg00258.html

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

[Celejar]

On Sun, 7 Jul 2019 09:00:05 +0300
Reco  wrote:

>   Hi.
> 
> On Sat, Jul 06, 2019 at 11:09:36PM -0400, Celejar wrote:
> > On Fri, 5 Jul 2019 09:35:46 +0300
> > Reco  wrote:
> > 
> > ...
> > 
> > > 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.
> > 
> > Perhaps almost entirely spam, but not quite 'nothing but spam':
> > 
> > https://lists.debian.org/debian-user/2018/03/msg00901.html
> > https://lists.debian.org/debian-user/2018/12/msg00732.html
> 
> A whopping two non-spam e-mails in a year? That's called negligible in
> my book.

Fair enough. Everyone has his own tolerance for false positives.

Celejar

Re : Re : Lumière bleue des moniteurs led ?

[nicolas . patrois]

Le 08/07/2019 11:03:52, hamster a écrit :

> PS : tu pourrais te renseigner ou demander pour quelle raison on veut
> faire ça avant de décréter de façon lapidaire que ça sert a rien alors
> que tu sais même pas de quoi tu parle.

J’y peux rien si la demande initiale n’est pas claire non plus.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

libvirt - Problem with encrypted QEMU-VM after upgrade to buster

[Dominik]

After upgrading to busters, my VMs fail to start:

 virsh --connect qemu:///system start Feigenbaum
error: Failed to start domain Feigenbaum
error: internal error: process exited while connecting to monitor: 
2019-07-08T11:32:00.290494Z qemu-system-x86_64: --object 
secret,id=sec0,file=/etc/libvirt/secret/Feigenbaum.secret: Unable to 
read /etc/libvirt/secret/Feigenbaum.secret: Failed to open file 
“/etc/libvirt/secret/Feigenbaum.secret”: Permission denied



The VMs are encrypted and /etc/libvirt/secret/ contains the key files 
for decryption.


I suspect apparmor to cause the problem, thus I extended the profile:

/etc/apparmor.d/usr.lib.libvirt.virt-aa-helper  to include the following 
lines:


  /etc/libvirt/secrets/** rw,
  /etc/libvirt/secrets/ r,

after parsing the profile with

sudo apparmor_parser -r /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper

The "premission denied" still occurs.

Re: READY! Tomas Ukkonen: Genocide. SOS.

[Tomas Ukkonen]

Hi

Someone seemed to have modified the previous email I send to you.

The sentence should have been "Title seem to have lost full  lenght."

Fix the title as soon as possible.

Tomas Erno Ukkonen, M. Sc.Sent from ProtonMail, encrypted email.

‐‐‐ Original Message ‐‐‐
On Saturday, 6th Julyta 2019, klo 17.54, Tomas Ukkonen 
 wrote:

> Hi
> 

> I have born in October 4th 1980.
> 

> USA independence day is 4th July (now).
> 

> Title seem be have lost film lenght.
> 

> Fix it to:
> 

> Genocide. Sos. My Mother Merja Ukkonen (Lehtovaara) Was Hit by Car in 1997s. 
> Born in 1950s. My Father Hannu Kalevi Ukkonen Brain Functions Were Reduced by 
> 1985 Together with Whole Population (University Chemist). We Moved to 
> Outokumpu. I Have Born in 1980.
> 

> I need long term loan?
> 

> HUAWEI - Hannu Ukkonen A Waste Ei
> HUAWEI - Hannu Ukkonen A We I (Ai)
> 

> Hannu Ukkonen has worked in executive board of Ekokem toxic waste management 
> unit and nuclear power unit.
> 

> Musician Skaven - Mercury Rain (Mer(ja) CurY R Ain)
> 

> Tomas Ukkonen, M. Sc.
> Sent from ProtonMail mobile
> 

>  Original Message 
> On 6. heinäk. 2019 klo 10.37, CD Baby < no-re...@cdbaby.com> wrote:
> Hi Tomas,
> 

> Your CD Baby page is ready for Tomas Ukkonen: Genocide. SOS..
> THE PERMANENT WEB ADDRESS IS...
> http://store.cdbaby.com/cd/tomasukkonen118
> 

> __
> 

> Check out your new page now.
> 

> Test the audio. Test the links. Imagine you're a customer. Start a customer 
> account and put the album in your shopping cart. Pretend to buy it. Make sure 
> everything works and looks the way you want it to. If you need to make any 
> changes, log into your members account HERE and change away!
> 

> Once you're happy with how everything is displayed, you can start to promote 
> the album to your email list, on your website, Facebook, etc. Please note, 
> For the first 24 hours you can only access the album by typing in the direct 
> URL for the CD BABY album page. After the first 24 hours, the album should 
> appear in normal search results and you will be able to use the link maker at 
> cdbaby.com/link
> 

> Encourage your fans to write reviews that will display at the bottom of your 
> CD Baby page.
> 

> Starting tomorrow, your album will be featured in two different places in our 
> STYLE/GENRE GALLERIES:
> 

> http://store.cdbaby.com/new/765
> and
> http://store.cdbaby.com/new/218
> Cool, huh?
> 

> 
> 

> Linkmakers
> 

> Be sure to place a prominent link on your own website, blog, and social 
> networking profiles to take people straight to your CD Baby page.
> Check out our Link Maker, here:
> http://members.cdbaby.com/link
> Choose your favorite design and paste the HTML code onto your site. It's that 
> easy.
> 

> ___
> 

> Extras?
> 

> If you are looking for extra promotional advice, be sure to check out the 
> many resources we've provided HERE for free!
> 

> As a CD Baby client, you can use Show.co's powerful and elegant music 
> promotion tools for free. Get started by logging into your CD Baby account 
> and clicking "Free Marketing Tools" in the dashboard.
> 

> And don't forget about all the other ways to earn money through your music 
> sales! Check out the other services we offer HERE, including YouTube 
> monetization, sync licensing, publishing administration, and much more.
> 

> If you have any more questions, check out our Help Center. Now go tell the 
> world about your new album!
> 

> --
> The CD Baby Team
> 

> P.S. - We'd love to hear from you about your experience with CD Baby! Please 
> take our 2 minute survey so we can keep getting better.
> 

> Haga clic aquí para leer este email en español.
> 

> Clique aqui para ler este e-mail em português.

publickey - tomas.ukkonen@protonmail.ch - 0x96E6CF27.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Debian Buster RC2 : Mise en veille systématique

[Eric Degenetais]

Le ven. 5 juil. 2019 10:42, Christian Quentin <
christian.quen...@architecte-du-web.com> a écrit :

> Le 2019-07-05 06:50, Jean-Michel OLTRA a écrit :
>
>
> Bonjour,
>
> Bonjour

>
> Le jeudi 04 juillet 2019, Christian Quentin a écrit...
>
>
> Que je clique sur le bouton Eteindre/Redémarrer ou que je tape halt dans
> un terminal (ou shutdown now), le résultat est le même : le PC met très
> longtemps à s'éteindre et finalement se met en veille. J'ai un petit
> voyant lumineux qui confirme que le PC (un portable HP 15_bw0xx) reste
> sous tension.
>
>
> Et avec `systemctl poweroff`, ça fait pareil ?
>
> Oui. Je viens de faire l'essai. Même comportement.
>
En fin de compte, ça ressemble à un plantage au shutdown plutôt qu'à une
mise en veille systématique, non ?

Cordialement

Éric Dégenètais

>

Re: Re : Lumière bleue des moniteurs led ?

[hamster]

Le 08/07/2019 à 12:47, nicolas.patr...@gmail.com a écrit :
> Vous avez des boutons sur votre écran pour régler la luminosité et les
> couleurs.
> Vous pouvez utiliser un thème sombre pour vous reposer les yeux mais une 
> chose est sûre la lumière bleue de l’écran n’est pas assez forte pour abîmer 
> vos yeux.

Au niveau des thèmes, j'aimais beaucoup le thème dans les orange et
marron d'ubuntu a l'époque 2008 - 2010, mais aujourd'hui sur debian/mate
j'arrive plus a retrouver le meme genre de couleurs. Si quelqu'un peut
me conseiller je suis preneur.

Pour la lumière bleue, il ne s'agit pas d'abimer les yeux mais d'activer
les recepteurs spécifiques au bleu qui sont derrière la rétine et qui
servent au corps a synchroniser l'horloge biologique avec le jour. Il
faut donc qu'il y ait du bleu en journée mais qu'il n'y en ait pas (ou
en tout cas beaucoup moins) après le coucher du soleil, sinon l'horloge
biologique reste en mode "jour" et ca peut provoquer des difficultés
d'endormissement. Comme j'ai pas envie de changer a la main les réglages
de mon écran tous les matins et tous les soirs, il y a le logiciel
redshift qui le fait automatiquement pour moi.

PS : tu pourrais te renseigner ou demander pour quelle raison on veut
faire ca avant de décréter de facon lapidaire que ca sert a rien alors
que tu sais meme pas de quoi tu parle.

Re: fix for no ssh

[Curt]

On 2019-07-08, Andrei POPESCU  wrote:
>
> The timing was also not very good for the buster release cycle.
> Hopefully this will be sorted out properly in time for bullseye.

That would be great. Then if they could resuscitate ecryptfs-utils
I would be a happy camper.

;-)

> Kind regards,
> Andrei
> 


-- 
"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." From a recent article in *Nature*. Holy shit. 

Re : Lumière bleue des moniteurs led ?

[nicolas . patrois]

Le 08/07/2019 09:40:01, Nicolas Dobigeon a écrit :

> Je confirme pour le paquet "redshift", ma compagne et moi l'utilisons
> sur KDE et Mate avec leurs plugins en systray.
> Et ça fait son job, certains peuvent dire que ce n'est pas parfait, je
> n'ai pas de sonde pour contrôler les températures colorimétriques avec ou
> sans le soft.
> Mais le gain en conforme est tout de même la et je ne ferais marche
> arrière pour rien au monde =)

Vous avez des boutons sur votre écran pour régler la luminosité et les couleurs.
Vous pouvez utiliser un thème sombre pour vous reposer les yeux mais une chose 
est sûre la lumière bleue de l’écran n’est pas assez forte pour abîmer vos yeux.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Re: fix for no ssh

[Curt]

On 2019-07-08, Andrei POPESCU  wrote:
>
>
> On Lu, 08 iul 19, 09:44:51, Curt wrote:
>> On 2019-07-08, Andrei POPESCU  wrote:
>> >
>> > On Lu, 08 iul 19, 09:06:33, Curt wrote:
>> >> On 2019-07-08, Andrei POPESCU  wrote:
>> >> >
>> >> > This was fixed before the release.

>> >> What?
>> >
>> > Is there something wrong with the current wording?

>> I guess, as I thought I was referring to the release-notes, which
>> haven't been.

> English is not my first language so I'm not sure what you mean here.
> Please kindly rephrase.

I thought you were saying that
'/etc/udev/rules.d/70-persistent-net.rules' remains a valid mechanism
for defining interface names in Buster (fixed). But the release-notes
(hmm, I think they've been modified since I last looked and now state
that that file is no longer "officially" supported by udev---but may
work in some cases). So I wouldn't be filing a bug report against that
stanza any longer, as current situation seems unverifiable. 

Sorry if I'm unclear.

> If there is still some inaccuracy please do provide more details
> (preferably with references) otherwise it's impossible to fix.

>> > Yes, please! I'm sure you know how to use reportbug ;)

>> Actually, I don't, but I could give it a try.
>
> You've been using Debian long enough, I'm sure you'll work it out ;)
>
>> There was some uncertainty in a recent thread about whether "it" had
>> been fixed or not.
>
> With "it" being...

Whether '/etc/udev/rules.d/70-persistent-net.rules' was respected or not
as means of defining interface names.

>> > I have no idea which daemons on my system are using getramdom().
>
>> You got me there. AFAIK, openssh and openssl.
>
> Apparently nowadays many daemons need it, and not only for encryption
> (e.g. to generate UUIDs).

Well, at the very least people should be informed who is likely to be
affected by the bug, and for those using amd64 how to check for the RDRAND
instruction, as well as what to do about it if they don't have it
(that's what I'd like to know, at any rate).

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

-- 
"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." From a recent article in *Nature*. Holy shit. 

Re: fix for no ssh

[Andrei POPESCU]

On Lu, 08 iul 19, 09:01:36, Curt wrote:
> On 2019-07-08, Andrei POPESCU  wrote:
> >
> >> Wow. Another reason to love systemd :-(
> >
> > Not clear to me why you are blaming systemd here.
> 
> Because systemd is to blame (at least in the opinion of some people in the
> know, like Stefan Frisch, for instance):
> 
> https://qa.debian.org/developer.php?login=s...@debian.org
> 
> https://lists.debian.org/debian-devel/2018/12/msg00184.html
> 
> ...
> 
>  The problem is that systemd (and probably /etc/init.d/urandom, too) does not 
> set 
>  the flag that allows the kernel to credit the randomness and so the kernel 
> does 
>  not know about the entropy contained in that file. Systemd upstream argues 
> that 
>  this is supposed to protect against the same OS image being used many times 
>  [3]. (More links to more discussion can be found at [4]).
> 
>  But an identical OS image needs to be modified anyway in order to be secure 
>  (re-create ssh host keys, change root password, re-create ssl-cert's private 
>  keys, etc.). Injecting some entropy in some way is just another task that 
>  needs to be done for that use case.  So basically the current implementation 
>  of systemd-random-seed.service breaks stuff for everyone while not fixing 
> the 
>  thing they are claiming to fix.

Oh, right. Read this before, but forgot about it.

Even if the upstream systemd developers are right (and I don't have 
anywhere near the expertise to judge on that), they could have handled 
it better.

The timing was also not very good for the buster release cycle. 
Hopefully this will be sorted out properly in time for bullseye.

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


signature.asc
Description: PGP signature