Re: [stable] gestion sous domaines

[Dethegeek]

Bonjour

Sous NGINX il faut créer autant blocs server {} que de sous domaines. Chaque 
bloc a une entrée 

Chacun peut avoir son certificat TLS.

Côté DNS le mieux est d'avoir un enregistrement A avec NSxxx.ip-xx-xx-xx.eu et 
des enregistrements CNAME pour les sous domaines.

https://nginx.org/en/docs/http/server_names.html



Le 18 novembre 2020 04:40:40 GMT+01:00, "Gaëtan Perrier" 
 a écrit :
>Bonjour,
>
>J'ai un serveur dédié sur lequel tourne une stable.
>Il a une adresse du genre nsXXX.ip-xx-xx-xx.eu (adresse donnée par le
>fournisseur du serveur).
>J'ai installé nginx et j'ai un service qui tourne dessus et répond sur cette
>adresse.
>Maintenant je voudrais gérer un 2e service.
>J'ai cru comprendre qu'il est possible de créer des sous-domaines pour accéder
>au 2 services facilement, du style service1.nsXXX.ip-xx-xx-xx.eu et
>service2.nsXXX.ip-xx-xx-xx.eu. Mais j'avoue n'avoir pas tout compris sur la
>façon de le faire et des prérequis pour pouvoir le faire ?
>
>Gaëtan
>
>
>

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: [stable] gestion sous domaines

[fabricer]

Hello Gaëtan,

Tes 2 sous-domaines, tu les crées dans ta gestion DNS ('A' et ''). 
Tu les fais pointer vers la même machine nsXXX.ip-xx-xx-xx.eu. C'est 
probablement chez ton hébergeur que ça se passe.


Ensuite, comme du parles de ngnix, je suppose que tu veux associer un 
site différent en fonction du sous-domaine. Alors, dans 
/etc/ngnix/sites-available, tu créés 2 fichier de conf différents qui 
commencent par:


server {
  server_name service1.TON_DOMAINE;

 location / {
root /data_service1;
  }
...

ensuite, tu n'oublies de créer un lien dans /etc/ngnix/sites-enable et 
de redémarrer ngnix.


Je ne te parles pas de SSL, de ngnix en mode proxy, ...

a+

f.


Le 18/11/2020 à 04:40, Gaëtan Perrier a écrit :

Bonjour,

J'ai un serveur dédié sur lequel tourne une stable.
Il a une adresse du genre nsXXX.ip-xx-xx-xx.eu (adresse donnée par le
fournisseur du serveur).
J'ai installé nginx et j'ai un service qui tourne dessus et répond sur cette
adresse.
Maintenant je voudrais gérer un 2e service.
J'ai cru comprendre qu'il est possible de créer des sous-domaines pour accéder
au 2 services facilement, du style service1.nsXXX.ip-xx-xx-xx.eu et
service2.nsXXX.ip-xx-xx-xx.eu. Mais j'avoue n'avoir pas tout compris sur la
façon de le faire et des prérequis pour pouvoir le faire ?

Gaëtan

[stable] gestion sous domaines

[Gaëtan Perrier]

Bonjour,

J'ai un serveur dédié sur lequel tourne une stable.
Il a une adresse du genre nsXXX.ip-xx-xx-xx.eu (adresse donnée par le
fournisseur du serveur).
J'ai installé nginx et j'ai un service qui tourne dessus et répond sur cette
adresse.
Maintenant je voudrais gérer un 2e service.
J'ai cru comprendre qu'il est possible de créer des sous-domaines pour accéder
au 2 services facilement, du style service1.nsXXX.ip-xx-xx-xx.eu et
service2.nsXXX.ip-xx-xx-xx.eu. Mais j'avoue n'avoir pas tout compris sur la
façon de le faire et des prérequis pour pouvoir le faire ?

Gaëtan





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

Re: clipgrab as alternative to youtube-dl

[Fred]

On 11/17/20 2:41 PM, The Wanderer wrote:

On 2020-11-17 at 16:27, Fred wrote:


On 11/17/20 1:27 PM, The Wanderer wrote:


On 2020-11-17 at 15:21, Fred wrote:


I also looked into compiling the source code which is often as easy as
following some simple instructions.  The compile makes use of qmake
which gives the error:

qmake: could not exec '/usr/lib/i386-linux-gnu/qt4/bin/qmake': No such
file or directory

/usr/bin/qmake is a link that points to /usr/bin/qtchooser which is
picking the wrong version of qt.  Qt5 is needed and is installed.  I
have set an environment variable QT_SELECT=qt5 but the chooser is not
fooled.  So, if the binary is not usable how do I select qt5?


I think you have the qtchooser syntax wrong.

'man qtchooser' says that the value passed to QT_SELECT is the same as
that which would be passed to 'qtchooser -qt='. Testing that, I get:



$ QT_SELECT=4 qtchooser -print-env
QT_SELECT="4"
QTTOOLDIR="/usr/lib/x86_64-linux-gnu/qt4/bin"
QTLIBDIR="/usr/lib/x86_64-linux-gnu"


IOW: the value you need to pass in is '5', not 'qt5'.


Hi,
You are quite right.  I don't see from the man page how one is required
to tell qtchooser to set the environment variable instead of doing it
oneself.  In a hurry I didn't notice the option -qt=version.


AFAICT, you don't need to tell qtchooser to do it. As the test still
quoted above shows, if you just set QT_SELECT and don't specify -qt=,
the other settings will be adjusted to match.

The practical necessities depend on exactly what is being invoked and
how, but it seems to me that if the build system is in fact calling
qtchooser, then setting QT_SELECT=5 should make it use Qt5.


Hi,
qtchooser -qt=5 -print-envdoes change to 5

qtchooser -qt=5   does not change the version.  Some command needs 
to follow.


qtchooser -print-env shows "default"

To compile clipgrab:  qmake -qt=5 clipgrab.pro & & make
qmake is a link to qtchooser.

Best regards,
Fred

Re: MX-Linux 19.2

[Keith Bainbridge]

+111

Keith Bainbridge

keith.bainbridge.3...@gmx.com

On 18/11/20 9:51 am, ellanios82 wrote:



 : just my prefs. : do much prefer mail-lists over forums : in
general  :)

Re: MX-Linux 19.2

[ellanios82]

On 11/18/20 12:54 AM, Jude DaShiell wrote:

Since MX-Linux is debian-based and has synaptic and probably also has apt-get 
if you want to do a version upgrade you're going to need to learn the code name 
for your desired version and change the existing code name in 
/etc/apt/sources.list file.  Then as root in a terminal
apt-update followed by apt-dist-upgrade ought to start the process.  It may be 
more complex than that.  You do have an MX-Linux forum available to you for 
participation.  Now, if you want an MX-Linux email list groups.io and 
freelists.org are available.  If the group doesn't exist on those two sites you 
could create it.  Then of course googlegroups.com
also exists but that's an advertising platform.  The yahoogroups.com is 
permanently shutting down as of December 15, 2020 so they're not available for 
list creation.  I've never done anything with MX-Linux since I'm a screen 
reader user and the first thing I'd need to research would be its accessibility 
support.



  - many thanks




 rgds

Re: MX-Linux 19.2

[ellanios82]

On 11/18/20 12:47 AM, Patrick Bartek wrote:

On Tue, 17 Nov 2020 23:11:56 +0200
ellanios82  wrote:


On 11/17/20 10:54 PM, Dan Ritter wrote:

ellanios82 wrote:

??Dear List


??- am using MX-Linux 19.2 :

 What steps to upgrade to 19.3 please ?
  

1. Find a mailing list or forum for MX-Linux.

2. Ask for instructions.

You might consider reading www.mxlinux.org.

-dsr-

- Thank you

[ did look for mailing list for MX-Linux but could not locate]

I don't think MX-Linux has a mail list, but they do have a forum:

   https://forum.mxlinux.org/

Here's the Support page:

https://mxlinux.org/support/

B


 - many thanks

 : just my prefs. : do much prefer mail-lists over forums : in general  :)




 Saludos

Re: MX-Linux 19.2

[Patrick Bartek]

On Tue, 17 Nov 2020 23:11:56 +0200
ellanios82  wrote:

> On 11/17/20 10:54 PM, Dan Ritter wrote:
> > ellanios82 wrote:  
> >> ??Dear List
> >>
> >>
> >> ??- am using MX-Linux 19.2 :
> >>
> >>  What steps to upgrade to 19.3 please ?
> >>  
> > 1. Find a mailing list or forum for MX-Linux.
> >
> > 2. Ask for instructions.
> >
> > You might consider reading www.mxlinux.org.
> >
> > -dsr-  
> 
> - Thank you
> 
> [ did look for mailing list for MX-Linux but could not locate]

I don't think MX-Linux has a mail list, but they do have a forum:

  https://forum.mxlinux.org/

Here's the Support page:

https://mxlinux.org/support/

B

Re: MX-Linux 19.2

[ellanios82]

On 11/18/20 12:20 AM, matthew dyer wrote:

Hi,

What is MX  Linux?  I have never heard of it.  Thanks.

Matthew



 Hi !


 at  one can find MX-Linux somewhere near the 
top of Right-hand column



 - there one can get Link to write-up on the Distro.


.

 Saludos

Re: clipgrab as alternative to youtube-dl

[The Wanderer]

On 2020-11-17 at 16:27, Fred wrote:

> On 11/17/20 1:27 PM, The Wanderer wrote:
>
>> On 2020-11-17 at 15:21, Fred wrote:
>> 
>>> I also looked into compiling the source code which is often as easy as
>>> following some simple instructions.  The compile makes use of qmake
>>> which gives the error:
>>>
>>> qmake: could not exec '/usr/lib/i386-linux-gnu/qt4/bin/qmake': No such
>>> file or directory
>>>
>>> /usr/bin/qmake is a link that points to /usr/bin/qtchooser which is
>>> picking the wrong version of qt.  Qt5 is needed and is installed.  I
>>> have set an environment variable QT_SELECT=qt5 but the chooser is not
>>> fooled.  So, if the binary is not usable how do I select qt5?
>> 
>> I think you have the qtchooser syntax wrong.
>> 
>> 'man qtchooser' says that the value passed to QT_SELECT is the same as
>> that which would be passed to 'qtchooser -qt='. Testing that, I get:

>> $ QT_SELECT=4 qtchooser -print-env
>> QT_SELECT="4"
>> QTTOOLDIR="/usr/lib/x86_64-linux-gnu/qt4/bin"
>> QTLIBDIR="/usr/lib/x86_64-linux-gnu"
>> 
>> 
>> IOW: the value you need to pass in is '5', not 'qt5'.
> 
> Hi,
> You are quite right.  I don't see from the man page how one is required 
> to tell qtchooser to set the environment variable instead of doing it 
> oneself.  In a hurry I didn't notice the option -qt=version.

AFAICT, you don't need to tell qtchooser to do it. As the test still
quoted above shows, if you just set QT_SELECT and don't specify -qt=,
the other settings will be adjusted to match.

The practical necessities depend on exactly what is being invoked and
how, but it seems to me that if the build system is in fact calling
qtchooser, then setting QT_SELECT=5 should make it use Qt5.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: clipgrab as alternative to youtube-dl

[Stefan Monnier]

>> I would like to try clipgrab as youtube-dl sometimes doesn't work.
> Feel free to try whatever you like, but if you want youtube-dl to work,
> don't use the Debian packages of it.  It changes too fast for a stable
> release to handle.  Use upstream instead.

Debian's `youtube-dl` works fine for me, but indeed you don't want to
use the version from Debian `stable`.  I normally use Debian `testing` but
have found it necessary to update it from Debian `unstable` occasionally.
Luckily it doesn't come with any significant dependency, so installing
from `unstable` is not problematic, even on Debian `stable`.


Stefan

Re: clipgrab as alternative to youtube-dl

[Fred]

On 11/17/20 1:27 PM, The Wanderer wrote:

On 2020-11-17 at 15:21, Fred wrote:


I also looked into compiling the source code which is often as easy as
following some simple instructions.  The compile makes use of qmake
which gives the error:

qmake: could not exec '/usr/lib/i386-linux-gnu/qt4/bin/qmake': No such
file or directory

/usr/bin/qmake is a link that points to /usr/bin/qtchooser which is
picking the wrong version of qt.  Qt5 is needed and is installed.  I
have set an environment variable QT_SELECT=qt5 but the chooser is not
fooled.  So, if the binary is not usable how do I select qt5?


I think you have the qtchooser syntax wrong.

'man qtchooser' says that the value passed to QT_SELECT is the same as
that which would be passed to 'qtchooser -qt='. Testing that, I get:


$ qtchooser -qt=4 -print-env
QT_SELECT="4"
QTTOOLDIR="/usr/lib/x86_64-linux-gnu/qt4/bin"
QTLIBDIR="/usr/lib/x86_64-linux-gnu"
wanderer@apologia:~$ qtchooser -qt=5 -print-env
QT_SELECT="5"
QTTOOLDIR="/usr/lib/qt5/bin"
QTLIBDIR="/usr/lib/x86_64-linux-gnu"
$ QT_SELECT=4 qtchooser -print-env
QT_SELECT="4"
QTTOOLDIR="/usr/lib/x86_64-linux-gnu/qt4/bin"
QTLIBDIR="/usr/lib/x86_64-linux-gnu"


IOW: the value you need to pass in is '5', not 'qt5'.


Hi,
You are quite right.  I don't see from the man page how one is required 
to tell qtchooser to set the environment variable instead of doing it 
oneself.  In a hurry I didn't notice the option -qt=version.


Thanks for the help.
Best regards,
Fred

Re: clipgrab as alternative to youtube-dl

[Fred]

On 11/17/20 1:24 PM, Greg Wooledge wrote:

On Tue, Nov 17, 2020 at 01:21:55PM -0700, Fred wrote:

I would like to try clipgrab as youtube-dl sometimes doesn't work.


Feel free to try whatever you like, but if you want youtube-dl to work,
don't use the Debian packages of it.  It changes too fast for a stable
release to handle.  Use upstream instead.



Hi Greg,

I have never used the Debian package for youtube-dl.  For the last 
several months when I tried to update there was a message saying the 
current version could not be found.  This was probably because of a 
recent DMCA takedown.  However, I just tried an update and it was 
successful.  The version date is today.


Maybe I don't need clipgrab after all!

Best regards,
Fred

Re: MX-Linux 19.2

[ellanios82]

On 11/17/20 10:54 PM, Dan Ritter wrote:

ellanios82 wrote:

??Dear List


??- am using MX-Linux 19.2 :

 What steps to upgrade to 19.3 please ?


1. Find a mailing list or forum for MX-Linux.

2. Ask for instructions.

You might consider reading www.mxlinux.org.

-dsr-


- Thank you

[ did look for mailing list for MX-Linux but could not locate]

Re: MX-Linux 19.2

[Dan Ritter]

ellanios82 wrote: 
> 
> ??Dear List
> 
> 
> ??- am using MX-Linux 19.2 :
> 
>  What steps to upgrade to 19.3 please ?
> 

1. Find a mailing list or forum for MX-Linux.

2. Ask for instructions.

You might consider reading www.mxlinux.org.

-dsr-

MX-Linux 19.2

[ellanios82]

 Dear List


 - am using MX-Linux 19.2 :

   What steps to upgrade to 19.3 please ?


 Thanks

  Ellan

...

Re: Encountered a bug with a dependency of wondershaper, but I'm unsure which dependency, and how to proceed with submitting a bug report

[Dan Ritter]

Graham Bull wrote: 
> I've been using wondershaper on Debian Stable for the past couple of years
> and it's been excellent.
> 
> I got a new pc recently with modern hardware and thus I installed Debian
> Testing on it.
> 
> I've noticed when I set the same rules within wondershaper on Stable and
> Testing, I get different behavior.
> Stable acts as expected, low latency and able to hit the limits set.
> Testing suffers a lot of latency and I'm only able to reach a fraction of
> the limit set.
> 
> When I remove the wondershaper rules everything works as expected (I can
> max my internet connection on both computers).
> 
> I've determined Stable and Testing use the same version of
> wondershaper=1.1a-10.
> 
> Wondershaper has one dependency:
> 
> Stable: iproute2=4.20.0-2
> Testing: iproute2=5.9.0-1
> 
> iproute2 has around 8 dependencies.
> 
> At this point I'm confused about how I should proceed with debugging my
> issue.
> 
> Any advice of how to collect more info for debugging purposes or how to
> proceed would be very much appreciated!

At this point, you might be better served by simply switching to
fq_codel, unless you have a particularly odd network connection.

In my /etc/network/interfaces on the firewall:
up tc qdisc replace dev eth3 root fq_codel

Wondershaper itself changed a lot after the 1.1 version that Debian
packages; you might want to ping the nominal maintainer and see
if they want to upgrade to 1.4.blah -- or, given the
availability of fq_codel, just drop the package.

-dsr-

Re: clipgrab as alternative to youtube-dl

[The Wanderer]

On 2020-11-17 at 15:21, Fred wrote:

> I also looked into compiling the source code which is often as easy as 
> following some simple instructions.  The compile makes use of qmake 
> which gives the error:
> 
> qmake: could not exec '/usr/lib/i386-linux-gnu/qt4/bin/qmake': No such 
> file or directory
> 
> /usr/bin/qmake is a link that points to /usr/bin/qtchooser which is 
> picking the wrong version of qt.  Qt5 is needed and is installed.  I 
> have set an environment variable QT_SELECT=qt5 but the chooser is not 
> fooled.  So, if the binary is not usable how do I select qt5?

I think you have the qtchooser syntax wrong.

'man qtchooser' says that the value passed to QT_SELECT is the same as
that which would be passed to 'qtchooser -qt='. Testing that, I get:


$ qtchooser -qt=4 -print-env
QT_SELECT="4"
QTTOOLDIR="/usr/lib/x86_64-linux-gnu/qt4/bin"
QTLIBDIR="/usr/lib/x86_64-linux-gnu"
wanderer@apologia:~$ qtchooser -qt=5 -print-env
QT_SELECT="5"
QTTOOLDIR="/usr/lib/qt5/bin"
QTLIBDIR="/usr/lib/x86_64-linux-gnu"
$ QT_SELECT=4 qtchooser -print-env
QT_SELECT="4"
QTTOOLDIR="/usr/lib/x86_64-linux-gnu/qt4/bin"
QTLIBDIR="/usr/lib/x86_64-linux-gnu"


IOW: the value you need to pass in is '5', not 'qt5'.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: clipgrab as alternative to youtube-dl

[Greg Wooledge]

On Tue, Nov 17, 2020 at 01:21:55PM -0700, Fred wrote:
> I would like to try clipgrab as youtube-dl sometimes doesn't work.

Feel free to try whatever you like, but if you want youtube-dl to work,
don't use the Debian packages of it.  It changes too fast for a stable
release to handle.  Use upstream instead.

clipgrab as alternative to youtube-dl

[Fred]

Hello,

I would like to try clipgrab as youtube-dl sometimes doesn't work.  I 
would not have made a donation on the clipgrab web site if I had first 
noticed that no support what so ever is available.


There is a binary for Linux available for download as a AppImage file. 
What is an AppImage file and what does one do with it.  The program was 
probably compiled for Ubuntu.  Is it likely to also run on Debian?


I also looked into compiling the source code which is often as easy as 
following some simple instructions.  The compile makes use of qmake 
which gives the error:


qmake: could not exec '/usr/lib/i386-linux-gnu/qt4/bin/qmake': No such 
file or directory


/usr/bin/qmake is a link that points to /usr/bin/qtchooser which is 
picking the wrong version of qt.  Qt5 is needed and is installed.  I 
have set an environment variable QT_SELECT=qt5 but the chooser is not 
fooled.  So, if the binary is not usable how do I select qt5?


Best regards,
Fred

Encountered a bug with a dependency of wondershaper, but I'm unsure which dependency, and how to proceed with submitting a bug report

[Graham Bull]

Hi all,

I've been using wondershaper on Debian Stable for the past couple of years
and it's been excellent.

I got a new pc recently with modern hardware and thus I installed Debian
Testing on it.

I've noticed when I set the same rules within wondershaper on Stable and
Testing, I get different behavior.
Stable acts as expected, low latency and able to hit the limits set.
Testing suffers a lot of latency and I'm only able to reach a fraction of
the limit set.

When I remove the wondershaper rules everything works as expected (I can
max my internet connection on both computers).

I've determined Stable and Testing use the same version of
wondershaper=1.1a-10.

Wondershaper has one dependency:

Stable: iproute2=4.20.0-2
Testing: iproute2=5.9.0-1

iproute2 has around 8 dependencies.

At this point I'm confused about how I should proceed with debugging my
issue.

Any advice of how to collect more info for debugging purposes or how to
proceed would be very much appreciated!

Regards, Graham

Re: Installation des page en français pour "man" en Buster

[didier gaumet]

Le mardi 17 novembre 2020 à 16:20:03 UTC+1, bubu a écrit :
[...]
> Si je veux avoir mon "man" en français sur Buster
> 
> Les paquets "manpages-fr-extra", "manpages-fr-dev", "manpages-fr" sont
> désuets en Buster.
> 
> Je pourrais installer ceux de Stretch ou ceux de testing (Bullseys) avec
> dpkg?

Je crains que ma réponse ne fasse qu'épaissir le mystère (avant qu'une bonne 
âme ne nous éclaire):

les paquets précités sont effectivement absents des dépôts de Buster alors 
qu'ils sont présents dans les dépôts
des distributions précédentes et suivantes.
Pourtant je suis en Buster (avec un peu de Backports), aucun de ces paquets 
n'est présent sur mon installation et mes pages man sont en français (testé à 
l'instant avec man man et man vim).
Je ne sais pas comment cela se fait, j'ai cherché (sans doute mal) une 
explication dans le journal des modifs Debian et je n'en ai pas trouvé. 
Peut-être une organisation de l'internationalisation des pages man différente 
dans Buster par rapport aux releases précédentes et suivantes?

Re: pygopherd

[Brad Rogers]

On Tue, 17 Nov 2020 08:25:12 -0600
Glenn Holmer  wrote:

Hello Glenn,

>Is it just for lack of a maintainer? Does it have to do with the Python
>3 migration?

Did you look at the reason(s) for removal?  Pretty much all the info you
require is there.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
I'll be the paint on the side if you'll be the tin
Love Song - The Damned


pgpimUWrVIoLO.pgp
Description: OpenPGP digital signature

Re: Errors using "apt update"

[Ming]

On Tue, 17 Nov 2020 12:10:08 -0500, Jerry Mellon wrote:
> Gentleman/Ladies
> 
> I have experienced a problem using "apt update". The program appears
> to work, but I end up with the list of errors.
> 
> [...] 
> 

Run the following command: apt-key list --keyid-format LONG, then
Check if you have the correct public key.

For example, for the following error

> W: An error occurred during the signature verification. The repository
> is not updated and the previous index files will be used. GPG error: 
> http://security.debian.org buster/updates InRelease: The following
> signatures couldn't be verified because the public key is not
> available: NO_PUBKEY AA8E81B4331F7F50 NO_PUBKEY 112695A0E562B32A

Normally you should be able to find the following output(contains the
public key ID that is indicated in the error message):

...
/etc/apt/trusted.gpg.d/debian-archive-buster-security-automatic.gpg
---
pub   rsa4096/4DFAB270CAA96DFA 2019-04-14 [SC] [expires: 2027-04-12]
  Key fingerprint = 5E61 B217 265D A980 7A23  C5FF 4DFA B270 CAA9
6DFA
uid [ unknown] Debian Security Archive Automatic
Signing Key (10/buster) 
sub   rsa4096/112695A0E562B32A 2019-04-14 [S] [expires: 2027-04-12]
...

/etc/apt/trusted.gpg.d/debian-archive-stretch-security-automatic.gpg

pub   rsa4096/EDA0D2388AE22BA9 2017-05-22 [SC] [expires: 2025-05-20]
  Key fingerprint = 6ED6 F5CB 5FA6 FB2F 460A  E88E EDA0 D238 8AE2
2BA9
uid [ unknown] Debian Security Archive Automatic
Signing Key (9/stretch) 
sub   rsa4096/AA8E81B4331F7F50 2017-05-22 [S] [expires: 2025-05-20]


If you cannot find these public keys, you may need to obtain and import
them manually.

But the problem is that these public keys are included in the debian
distribution by default. If everything was normal before, where did
these public keys go? This may be a problem that you need to check.

-- 
PGP fingerprint: 3C47 5977 4819 267E DD64  C7E4 6332 5675 A739 C74E


pgpUTSyy9pRBF.pgp
Description: OpenPGP digital signature

Errors using "apt update"

[Jerry Mellon]

Gentleman/Ladies

I have experienced a problem using "apt update". The program appears to
work, but I end up with the list of errors.

W: An error occurred during the signature verification. The repository
is not updated and the previous index files will be used. GPG error: 
http://security.debian.org buster/updates InRelease: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY AA8E81B4331F7F50 NO_PUBKEY 112695A0E562B32A
W: An error occurred during the signature verification. The repository
is not updated and the previous index files will be used. GPG error: 
http://deb.debian.org/debian buster InRelease: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY
04EE7237B7D453EC NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY DCC9EFBF77E11517
W: An error occurred during the signature verification. The repository
is not updated and the previous index files will be used. GPG error: 
http://deb.debian.org/debian buster-updates InRelease: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 04EE7237B7D453EC NO_PUBKEY 648ACFD622F3D138
W: An error occurred during the signature verification. The repository
is not updated and the previous index files will be used. GPG error: 
http://mirror.isoc.org.il/pub/debian /buster InRelease: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 04EE7237B7D453EC NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY
DCC9EFBF77E11517
W: Failed to fetch http://deb.debian.org/debian/dists/buster/InRelease  
The following signatures couldn't be verified because the public key is
not available: NO_PUBKEY 04EE7237B7D453EC NO_PUBKEY 648ACFD622F3D138
NO_PUBKEY DCC9EFBF77E11517
W: Failed to fetch 
http://security.debian.org/dists/buster/updates/InRelease  The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY AA8E81B4331F7F50 NO_PUBKEY 112695A0E562B32A
W: Failed to fetch 
http://mirror.isoc.org.il/pub/debian/dists//buster/InRelease  The
following signatures couldn't be verified because the public key is not
available: NO_PUBKEY 04EE7237B7D453EC NO_PUBKEY 648ACFD622F3D138
NO_PUBKEY DCC9EFBF77E11517
W: Failed to fetch 
http://deb.debian.org/debian/dists/buster-updates/InRelease  The
following signatures couldn't be verified because the public key is not
available: NO_PUBKEY 04EE7237B7D453EC NO_PUBKEY 648ACFD622F3D138
W: Some index files failed to download. They have been ignored, or old
ones used instead.

Any help clearing these Errors will be greatly appreciated. 
Using Debian 10.5. for i386 version.
Thank you for your attention.
Jerry --- jfmel...@netscape.net

configuração de pointing stick

[G.Paulo]

Caros, 

Preciso configurar o "pointing stick", aquele "mouse" na forma de botão 
(geralmente de cor vibrante) que fica no meio do teclado, cujo nome em 
português eu não sei mas que, às vezes, recebe apelidos cômicos.

Pelo que pesquisei, precisaria de um pacote chamado 
"gpointing-device-settings", que não está mais nas distribuições. Dele, não 
encontrei um substituto.

Alguém tem uma dica sobre como fazer esta configuração? Em tempo, uso Debian 
10.6.

Sds.
G.Paulo.

Re: [Postfix] Rejeter les messages venant d'une IP sans reverse (ou mal formé)

[Jérémy Prego]

Le 17/11/2020 à 17:21, Roger Price a écrit :
> On Tue, 17 Nov 2020, JUPIN Alain wrote:
>
>> Sur une installation Postfix d'une Debian 10.6 (à jour), j'ai toujours
>> un nombre relativement important de messages qui viennent d'adresse IP
>> "inconnues"
>> Exemple : Received: from [149.27.181.246] (unknown [149.27.181.246])
>>
>> On voit que l'adresse IP n'a pas de reverse, mais comment les bloquer ?
>> J'ai la directive suivante dans le main.cf :
>> smtpd_sender_restrictions = reject_non_fqdn_sender,
>> reject_unknown_sender_domain, permit_sasl_authenticated,
>> permit_mynetworks
>>
>> PS : La plupart de ces messages passent en SPAM mais pas tous, mais
>> autant tous les bloquer !
>
> Y compris ceci ?
>
> Received: from [IPv6:2a01:e0a:242:8fe0:54a5:f697:9115:ccdb] (unknown
> [IPv6:2a01:e0a:242:8fe0:54a5:f697:9115:ccdb])
>     (Authenticated sender: ajupin)
>     by smtp6-g21.free.fr (Postfix) with ESMTPSA id CFFA3780346
>     for ; Tue, 17 Nov 2020
> 15:53:21 + (UTC)
> From: JUPIN Alain 
>
il ne faut pas tout confondre.

là, tu as collé une ip d'un client qui se connecte au smtp de free pour
envoyé le mail par ce dernier. le smtp de free lui a un reverse correct.
du coup le mail passse. ce n'est pas l'ip collé précédemment qui se
connecte directement au smtp distant. :)
> Roger

Jerem

Re: [Postfix] Rejeter les messages venant d'une IP sans reverse (ou mal formé)

[Roger Price]

On Tue, 17 Nov 2020, JUPIN Alain wrote:


Sur une installation Postfix d'une Debian 10.6 (à jour), j'ai toujours
un nombre relativement important de messages qui viennent d'adresse IP
"inconnues"
Exemple : Received: from [149.27.181.246] (unknown [149.27.181.246])

On voit que l'adresse IP n'a pas de reverse, mais comment les bloquer ?
J'ai la directive suivante dans le main.cf :
smtpd_sender_restrictions = reject_non_fqdn_sender,
reject_unknown_sender_domain, permit_sasl_authenticated, permit_mynetworks

PS : La plupart de ces messages passent en SPAM mais pas tous, mais
autant tous les bloquer !


Y compris ceci ?

Received: from [IPv6:2a01:e0a:242:8fe0:54a5:f697:9115:ccdb] (unknown 
[IPv6:2a01:e0a:242:8fe0:54a5:f697:9115:ccdb])

(Authenticated sender: ajupin)
by smtp6-g21.free.fr (Postfix) with ESMTPSA id CFFA3780346
for ; Tue, 17 Nov 2020 15:53:21 + 
(UTC)

From: JUPIN Alain 

Roger

Re: [Postfix] Rejeter les messages venant d'une IP sans reverse (ou mal formé)

[Cyrille Bollu]

Apparement, il s'agit de l'option "reject_unknown_reverse_client_hostname"
que tu dois ajouter à ta liste de smtpd_sender_restriction

 

Bàt,

 

Cyrille

 

"JUPIN Alain" aju...@jupin.net – 17 novembre 2020 16:53
 

> Bonjour,
>
> Sur une installation Postfix d'une Debian 10.6 (à jour), j'ai toujours
> un nombre relativement important de messages qui viennent d'adresse IP
> "inconnues"
> Exemple : Received: from [149.27.181.246[1]] (unknown
[149.27.181.246[1]])
>
> On voit que l'adresse IP n'a pas de reverse, mais comment les bloquer ?
> J'ai la directive suivante dans le main.cf[2] :
> smtpd_sender_restrictions = reject_non_fqdn_sender,
> reject_unknown_sender_domain, permit_sasl_authenticated,
permit_mynetworks
>
> PS : La plupart de ces messages passent en SPAM mais pas tous, mais
> autant tous les bloquer !
>
> Merci par avance
>
>  



Links:
--
[1] http://149.27.181.246
[2] http://main.cf

[Postfix] Rejeter les messages venant d'une IP sans reverse (ou mal formé)

[JUPIN Alain]

Bonjour,

Sur une installation Postfix d'une Debian 10.6 (à jour), j'ai toujours
un nombre relativement important de messages qui viennent d'adresse IP
"inconnues"
Exemple : Received: from [149.27.181.246] (unknown [149.27.181.246])

On voit que l'adresse IP n'a pas de reverse, mais comment les bloquer ?
J'ai la directive suivante dans le main.cf :
smtpd_sender_restrictions = reject_non_fqdn_sender,
reject_unknown_sender_domain, permit_sasl_authenticated, permit_mynetworks

PS : La plupart de ces messages passent en SPAM mais pas tous, mais
autant tous les bloquer !

Merci par avance

-- 
Alain JUPIN

Re: An old box running Debian 8

[Andrei POPESCU]

On Ma, 17 nov 20, 09:24:05, David Wright wrote:
> On Sun 15 Nov 2020 at 10:41:55 (+0200), Andrei POPESCU wrote:
> > On Sb, 14 nov 20, 16:36:03, Miroslav Skoric wrote:
> > > On 11/13/20 9:29 PM, David Wright wrote:
> > > 
> > > > I would have thought that Debian has made kernel testing just about as
> > > > easy as they can since:
> > > > jessie  installs with 3.16 but 4.9  is also available,
> > > > stretch installs with 4.9  but 4.19 is also available,
> > > > buster  installs with 4.19
> > > > so there's full overlap. (I've not looked at backports.)
> > > 
> > > That's actually what I also thought about.
> > > 
> > > Btw, when you say 'installs', do you mean a fresh installation only, or it
> > > includes a 'forced' kernel update during a distribution upgrade? My old 
> > > box
> > > was installed for the first time in squeeze, then upgraded to wheezy, then
> > > to jessie.
> 
> By "installs with", I meant the former, ie the version supplied with
> the debian-installer. Once you're happy with that version, it's
> possible to install the newer version, leaving the old one as a
> fallback (assuming the usual things like enough room in /boot, etc).
> 
> > It depends on whether you have the corresponding linux-image- 
> > package installed or not.
> 
> I'm not sure what difference this would make. Looking at all
> the linux-image-X86* packages in stretch, they all depend on
> linux-image-4.9-* packages.

That was meant for the dist-upgrade case. Without the corresponding 
linux-image- meta-package the kernel will be left as is and 
the user has to manually install a newer kernel from the next 
distribution.

Depending on when in the release cycle the dist-upgrade is done the 
newer kernel image may not even be available yet

The linux-image- also depends on the default kernel for the 
distribution, e.g. in case of stretch it depends on a
4.9 linux image, for a 4.19 image one has to install 
linux-image-4.19- (or the linux image package itself).

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


signature.asc
Description: PGP signature

Re: Instructions for command line usage of WiFi.

[David Wright]

On Sun 15 Nov 2020 at 10:59:10 (-0800), pe...@easthope.ca wrote:
> From: Reco 
> Date: Fri, 6 Nov 2020 08:25:39 +0300
> > [1] also states that:
> >
> > The wpasupplicant package ...
> > 
> > In simplier terms: no wpasupplicant = no WPA2.
> 
> Your simplified statement is invaluable.  "Less is more".
> 
> The rather inscrutable section entitled "wpa_supplicant" follows the 
> section entitled "WPS" which follows the section entitled "Command 
> Line".  The structure of the document certainly doesn't explain the 
> relationship of components well. Unhelpful to a novice.  Obvously no 
> problem for an expert.  But who should be helped by documentation?

The trouble is that someone with expertise has to empathise with
new users ignorant of the process and terminology, and then
restructure or rewrite the whole page.

> I guess most connections now require authentication.  The explanation 
> should be consistent with reality.
> 
> My effort to make WiFi work, using network access by a mobile tablet, 
> was tough going.  Installation of packages was painful.  I abandoned 
> the effort, took the HDD back to a system with wired Ethernet, 
> installed LXDE, wicd and dependencies and got WiFI to work.  =8~)

There's no need for a DE in order to run wicd—I didn't think of
suggesting it because your first post seemed to say that you
wanted to try making connections with low-level tools like iw,
wpasupplicant, etc, something that I've always intended to
try out but never quite found the time for. Perhaps if and when
wicd gets dropped through lack of Python3 support.

> I wonder why the netinstall process in the ISO image doen't include at 
> least the base support for WiFi?  Too much data?  Negligence in 
> planning the ISO build?

They're all there, viz:

$ ls -Glg netinst/10.2.0/amd64-with/iso-contents-unpacked/pool/main/w/w*[sa]
netinst/10.2.0/amd64-with/iso-contents-unpacked/pool/main/w/wireless-tools:
total 164
-r--r--r-- 1  12624 Sep 15  2018 libiw30-udeb_30~pre9-13_amd64.udeb
-r--r--r-- 1  21548 Sep 15  2018 libiw30_30~pre9-13_amd64.deb
-r--r--r-- 1  12184 Sep 15  2018 wireless-tools-udeb_30~pre9-13_amd64.udeb
-r--r--r-- 1 113580 Sep 15  2018 wireless-tools_30~pre9-13_amd64.deb

netinst/10.2.0/amd64-with/iso-contents-unpacked/pool/main/w/wpa:
total 1548
-r--r--r-- 1  324536 Sep 18  2019 
wpasupplicant-udeb_2.7+git20190128+0c1e29f-6+deb10u1_amd64.udeb
-r--r--r-- 1 1254660 Sep 18  2019 
wpasupplicant_2.7+git20190128+0c1e29f-6+deb10u1_amd64.deb
$ 

The same wireless packages are also on the free-firmware-only
versions of netinst, which I don't bother to download myself,
but usually the problem is that so much wireless hardware
requires non-free firmware to fully function.

The other problem is (or was¹) the removal of the contents of
/etc/network/interfaces as the final step of the installer,
meaning you have to immediately enter it all again.

> Incidentally, I'd prefer to say that authentication is conducted by 
> "authenticator" and "authenticatee".  Meaning is fairly obvious.  
> Symmetry is as valuable in technical terminology as in vehicle design.
> Yah, I've read https://en.wikipedia.org/wiki/Supplicant_(computer).
> Can't help but think that the authors of 802.1X were being a little 
> too clever with "authenticator" and "supplicant".  Make it simple as 
> possible!

Hmm. It gives a lot of scope for a typo to cause havoc. Perhaps the
authors of 802.1X (if they coined it) learnt something from PPP,
where the supplicant was known as the peer, in a system designed
for connecting two peers. What's more, I think that most people
consider themselves as the authenticator when they authenticate
themselves with a passport at immigration control. So, quite ambiguous.

¹ I haven't followed up on whether there have been improvements
  surrounding bug #694068.

Cheers,
David.

Re: An old box running Debian 8

[David Wright]

On Sun 15 Nov 2020 at 10:41:55 (+0200), Andrei POPESCU wrote:
> On Sb, 14 nov 20, 16:36:03, Miroslav Skoric wrote:
> > On 11/13/20 9:29 PM, David Wright wrote:
> > 
> > > I would have thought that Debian has made kernel testing just about as
> > > easy as they can since:
> > > jessie  installs with 3.16 but 4.9  is also available,
> > > stretch installs with 4.9  but 4.19 is also available,
> > > buster  installs with 4.19
> > > so there's full overlap. (I've not looked at backports.)
> > 
> > That's actually what I also thought about.
> > 
> > Btw, when you say 'installs', do you mean a fresh installation only, or it
> > includes a 'forced' kernel update during a distribution upgrade? My old box
> > was installed for the first time in squeeze, then upgraded to wheezy, then
> > to jessie.

By "installs with", I meant the former, ie the version supplied with
the debian-installer. Once you're happy with that version, it's
possible to install the newer version, leaving the old one as a
fallback (assuming the usual things like enough room in /boot, etc).

> It depends on whether you have the corresponding linux-image- 
> package installed or not.

I'm not sure what difference this would make. Looking at all
the linux-image-X86* packages in stretch, they all depend on
linux-image-4.9-* packages.

One minor point: if linux-image-586/linux-image-3.16.0-10-586
is your current kernel version, linux-image-4.9-686 is the
next kernel to try. (For some reason, there was never a non-PAE
version of 3.16.0-*-686 packaged.)

So AFAICT, to upgrade to my "also available" kernels above, you
have to specifically install them. I hesitate to use the term
"force" because that has different connotations for apt/dpkg.

And I wouldn't combine it with a regular distribution upgrade.
In fact, that's the whole point of my posting: to do each kernel
change "long" after a distribution upgrade and "long" before the
next one. ("Long" might be a single day of regression testing the
system to make sure you're happy that everything still works
after the change.)

So the sequence would be:

jessie with 3.16 running ok
  new kernel installation
jessie with 4.9 running ok
  distribution upgrade
stretch with 4.9 running ok
  new kernel installation
stretch with 4.19 running ok
  distribution upgrade
buster with 4.19 running ok

Cheers,
David.

Fwd: Installation des page en français pour "man" en Buster

[bubu]

 Message transféré 
Sujet : Installation des page en français pour "man" en Buster
Date :  Tue, 17 Nov 2020 09:35:38 -0500
De :Martin Vézina 
Pour :  bu...@no-log.org



bubu, pourrait tu posté ce message sur
 pour moi? C'est le message que je
voulais posté initialement avant cette dérape.

--

Si je veux avoir mon "man" en français sur Buster

Les paquets "manpages-fr-extra", "manpages-fr-dev", "manpages-fr" sont
désuets en Buster.

Je pourrais installer ceux de Stretch ou ceux de testing (Bullseys) avec
dpkg?

Re: Kernel global lock in sr.c slows down parallel operations to multiple drive

[Marc SCHAEFER]

On Tue, Nov 17, 2020 at 07:04:59AM -0500, The Wanderer wrote:
> FWIW, I parsed this as "and possibly file a(nother) bug report[ about
> this bug, since the one I thought I remembered having filed before seems
> to have disappeared, if it ever existed in the first place]".

Exactly, thank you for parsing!

Actually I just found the old bug report:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816211

Of course, as it was reported on a backport kernel, I guess no one cared
:)

Re: pygopherd

[Roberto C . Sánchez]

On Tue, Nov 17, 2020 at 08:25:12AM -0600, Glenn Holmer wrote:
>I see that pygopherd (gopher server) is removed from the repo:
>[1]https://tracker.debian.org/pkg/pygopherd
>Is it just for lack of a maintainer? Does it have to do with the Python 3
>migration?

It appears to have been removed at the request of the QA team for lack
of python3 support.

More info:

https://tracker.debian.org/news/1088836/removed-20185-from-unstable/
https://bugs.debian.org/937449

Based on the discussion in #937449, John Goerzen was working on a port.
You might contact him to determine the status of it and if he might be
working on getting it back into Debian.

Regards,

-Roberto

-- 
Roberto C. Sánchez

pygopherd

[Glenn Holmer]

I see that pygopherd (gopher server) is removed from the repo:

https://tracker.debian.org/pkg/pygopherd

Is it just for lack of a maintainer? Does it have to do with the Python 3
migration?

-- 
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."

Re: Kernel global lock in sr.c slows down parallel operations to multiple drive

[The Wanderer]

On 2020-11-17 at 07:00, Thomas Schmitt wrote:

>> I will try to apply a similar patch and possibly report another
>> bug.
> 
> What is that other bug ?

FWIW, I parsed this as "and possibly file a(nother) bug report[ about
this bug, since the one I thought I remembered having filed before seems
to have disappeared, if it ever existed in the first place]".

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Kernel global lock in sr.c slows down parallel operations to multiple drive

[Thomas Schmitt]

Hi,

> In jessie, the kernel had a very annoying bug: if you did I/O on
> multiple sr devices, the global lock in sr.c would slow down
> to a crawl.

I dedicated a little temple to that bug.

  https://dev.lovelyhq.com/libburnia/web/wiki/ConcurrentLinuxSr

In short:

- It is gone since about kernel 5.6 or 5.7. The mutex is now per drive.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=51a858817dcd

- On older kernels use /dev/sg and be free of the global sr mutex.

- Or change the kernel to perform the mutex in sr_block_ioctl() only if
  cmd != SG_IO. I tested that with kernel 4.19 of Debian 10.
  But above committed fix is better, as it also eases fixing of the
  automatic tray loading bug.


> I will try to apply a similar patch and possibly report another bug.

What is that other bug ?

I know of and have patches for:
- Automatic tray loading quickly reporting no medium.
- I/O error at the end of data CDs written by Track-At-Once.
- Non-zero size of empty drive or empty medim.
- Wrong buffers, medium state and size after burning until tray reloading.
- No mount(8) option session= with DVD.
- Some fs/isofs bugs, too.

-

I try to submit a fix for the tray bug since more than two months.
So if you want to help improving sr and have a drive with motorized tray,
then consider to test whether you suffer from it and whether my proposed
patches fix it for data reading:

  
https://lore.kernel.org/linux-scsi/20201006094026.1730-1-scdbac...@gmx.net/T/#u

If it works for you, please send a reply mail with a "Tested-by:".
Full mail headers can be seen at
  https://lore.kernel.org/linux-scsi/20201006094026.1730-1-scdbac...@gmx.net/raw


Have a nice day :)

Thomas

Re: Le ransomware RansomEXX s'attaque maintenant aux systèmes Linux

[Gabriel Moreau]

PS: j'ai eu l'occasion de bosser sur un système dérivé d'un Unix où tous
les exécutables étaient signés par une clef locale. C'était chiant
(parce que la clef privée n'était forcément pas sur la machine en
question), mais ça évite l'exécution de programmes récupérés ici ou là.


Avec SElinux, tu peux faire cela...

gaby
--
Gabriel Moreau - IR CNRShttp://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France
mailto:gabriel.mor...@legi.grenoble-inp.fr  tel:+33.476.825.015



smime.p7s
Description: Signature cryptographique S/MIME

Kernel global lock in sr.c slows down parallel operations to multiple drive

[Marc SCHAEFER]

Hello,

In jessie, the kernel had a very annoying bug: if you did I/O on
multiple sr devices, the global lock in sr.c would slow down
to a crawl.

E.g. 5 DVD-R written to in parallel gave the same performance as
one writing; and ejecting the DVD in parallel was completely
sequential.

Based on this:
   
https://unix.stackexchange.com/questions/411735/why-does-linux-kernel-driver-sr-c-sr-block-ioctl-do-mutex-lock
and this:
   https://www.spinics.net/lists/linux-scsi/msg63706.html

I patched my kernel, and the performance augmented drastically,
you can watch the video here:

   https://www.youtube.com/watch?v=siDMzkRCTpQ=youtu.be

or here:
   
https://peertube.gaialabs.ch/videos/watch/7ad190bd-43d9-42dc-9336-984822db7cc3

I even think I reported that bug, but can't find it anymore.

However, it seems the kernel used by buster has the same issue. I am now
writing with BR drives (two of them) and I get abyssal performance.

Anyone can confirm ?

I will try to apply a similar patch and possibly report another bug.

LibreOffice 6.5.1 Bug

[Vrajarāja Govinda Dāsa]

Dear developer,

I use Debian GNU/Linux Buster 10.6 XFCE (amd64) edition.

LibreOffice 6.1.5 was installed by default..

In Writer, colouring of the text cannot be done.

In Calc, colouring can be done, but becomes 'black text' when the cell 
which contains the cell is not in focus.


In Impress, colouring can be done, but is manifest only when the text 
box is not in focus (opposite to the situation in Calc).



Please look into the matter.


Thanks & Regards,

Vrajaraja Govinda Das.

Re: Le ransomware RansomEXX s'attaque maintenant aux systèmes Linux

[BERTRAND Joël]

Bureau LxVx a écrit :
> SaluX !
> 
> *Le ransomware RansomEXX s'attaque maintenant aux systèmes Linux :
> *https://www.lemondeinformatique.fr/actualites/lire-le-ransomware-ransomexx-s-attaque-maintenant-aux-systemes-linux-80969.html?utm_source=ActiveCampaign_medium=email_campaign=NL+LMI+Selection+15112020_ee=93a54153fccd51d8123d50ee9c178ae270c63fcc_ee=Qk9kvX42OTXT0ijFpE0OJ%2BhteTmyolKtig6scymBiX8%3D*
> *
> Bon dimanche,

Bonjour à tous,

Deux informations, une bonne et une moins bonne. La bonne, c'est que
les serveurs Linux sont un peu partout, qu'il y a des données
importantes dessus et que si les pirates en question ciblent maintenant
ces serveurs, c'est qu'il y a de l'argent à se faire dessus.

La moins bonne, c'est que le développement de Linux est devenu
tellement anarchique qu'il n'y a plus aucune réelle revue de code (pour
s'en convaincre, regarder la gestion des modules dans le noyau à grands
coups de pointeurs nuls et ce qu'un individu mal intentionné peut en
faire). On se retrouve avec des failles non corrigées depuis trop
longtemps, des concepts pas trop secs avec des effets de bord bizarres
et la sensation de toujours essuyer les plâtres avec une brique. Je
n'avais pas cette sensation il y a vingt ans où je pouvais redémarrer
des serveurs à distance sans me poser de question. Aujourd'hui, je ne
prends plus ce risque sans avoir un système me permettant de reprendre
la main sur la console ! Je ne parle même pas de l'éditeur de liens
dynamiques qui est un poème (et un problème) à lui tout seul. Bon,
j'avoue, le problème de ld nécessite d'avoir accès à un shell local.
Mais il suffit d'une autre faille ailleurs pour avoir un tel accès.

Linux est maintenant à la mode mais je considère qu'il faut être fou
pour avoir des données critiques sur un tel système _aujourd'hui_,
surtout sans un sérieux système de sauvegarde ou d'archivage permettant
de repartir vite. Si des postes clients sont sous Windows et requièrent
des droits d'administrateurs locaux, c'est encore pire parce que c'est
généralement open bar côté serveur.

Bref, il va être temps de penser réellement à la sécurité (donc pas
avec des machines ouvertes à tous les vents grâce à une installation de
base). Ce point est trop souvent ignoré des distributions et des
développeurs. Il est aussi trop souvent ignoré par les administrateurs
et les utilisateurs.

Bien cordialement,

JKB

PS: j'ai eu l'occasion de bosser sur un système dérivé d'un Unix où tous
les exécutables étaient signés par une clef locale. C'était chiant
(parce que la clef privée n'était forcément pas sur la machine en
question), mais ça évite l'exécution de programmes récupérés ici ou là.

Re: Je n'arrive toujours pas à envoyer mes courriel à "debian-user-french@lists.debian.org"

[Daniel Caillibaud]

Le 16/11/20 à 20h15, Étienne Mollier  a écrit :
> L'ID d'un message est visible dans les en-têtes des messages
> envoyés

Pas vraiment, il n'est visible qu'une fois que le mail a transité par le
smtp (c'est lui qui fixe cet id), en général le mail que tu retrouves dans
tes messages envoyés est celui qui a été soumis au smtp (avant qu'il le
traite, donc sans cet id).

On peut tenter de récupérer l'id en se mettant en copie du mail pour
récupérer l'id dans la copie reçue (à vérifier, pas sûr que le smtp mette
toujours le même id pour un mail envoyé à deux destinataires ≠).

Mais ici il y a un bounce (le message d'erreur retourné à l'expéditeur),
toutes les infos sont dedans (dont l'id).

-- 
Daniel

C'est vrai que je ne plais pas à tout le monde. Mais quand je vois à qui je
ne plais pas, je me demande si ça me dérange vraiment . J'en suis même très 
souvent content.
Coluche

Re: Je n'arrive toujours pas à envoyer mes courriel à "debian-user-french@lists.debian.org"

[Daniel Caillibaud]

Le 16/11/20 à 18h53, Martin Vézina  a écrit :
> J'ai écrit as "Support du site:
> debian-l10n-fre...@lists.debian.org"
> pour signaler le problème et avec videotron.ca, il me sont revenus avec
> le même message...

C'est ce message d'erreur (complet) qu'il faudrait faire parvenir à
"listmas...@lists.debian.org", ici on ne pourra pas t'aider.

-- 
Daniel

L'urgent est fait. L'impossible est en cours. Pour les miracles, prévoir un
délai.

Re: Je n'arrive toujours pas à envoyer mes courriel à "debian-user-french@lists.debian.org"

[Daniel Caillibaud]

Le 16/11/20 à 19h35, Pierre Malard  a écrit :
> >> Ce serait bien plus simple pour diagnostiquer le problème d’avoir des
> >> logs des tentatives d’envoi. Ne pourrait-on l’avoir ?
> >> 
> >> En général c’est un fichier « /var/log/mail.xxx » pour Postfix.  
> > 
> > Ce serait effectivement plus simple, mai je doute qu'il puisse accéder
> > aux logs de ses fournisseurs de mail (ici hotmail ou videotron.ca) ;-)  
> 
> Sauf s’il envoie ses mail depuis son poste local et pas d’un Webmail…

J'avais compris que le pb ne se posait que pour 
  hotmail => lists.debian.org
  videotron.ca => lists.debian.org

> Si c’est du Webmail il faut se retourner uniquement sur son fournisseur
> d’accès alors et pas essayer de résoudre son problème à sa place !

Certes…

-- 
Daniel

Si on ne peut plus tricher avec ses amis,
ce n'est plus la peine de jouer aux cartes.
Marcel Pagnol.