Re: openvpn privatvpn

[Daniel Caillibaud]

Le 11/07/19 à 18h50, MERLIN Philippe  a
écrit :
> Une analyse par Wireshark indique seulement que les DNS ne
> fonctionnent pas.

Je ne connais pas l'origine du pb, mais tu peux installer un resolver
local, c'est très léger et ça rend pas mal de services (ça évite les dns
parfois menteurs des FAI, mais surtout ça marche toujours alors que
suivant les FAI la résolution dns laisse parfois à désirer, et en prime tu
va gagner un poil en perfs).

apt install unbound

et dans /etc/resolv.conf mettre
nameserver 127.0.0.1

(ou bien l'indiquer dans le network manager, ou ton système de gestion de
la résolution locale)



-- 
Daniel

La mode est ce que l’on porte. 
Ce qui est démodé, c’est ce que portent les autres.
Oscar Wilde

Re: blocage du système USB

[Kohler Gerard]

merci,
je testerai cela dès mon retour
Gerard


Le 11/07/2019 à 13:07, Guillaume Clercin a écrit :

Bonjour,

Sur un macbook, le clavier et le touchpad sont branchés sur le même bus
usb. Et il arrivé que le touchpad s'arrête de fonctionner. Et je le
redémarre avec un petit script shell.

---
#! /bin/bash
echo "Reset keyboard"

echo -n "Disable keyboard... "
echo 0 > /sys/bus/usb/devices/3-6/authorized && echo ok || echo failed

sleep 1

echo -n "Re-esable keyboard... "
echo 1 > /sys/bus/usb/devices/3-6/authorized && echo ok || echo failed
---

Ça peut servir de base mais il faut remplacer 3-6 par le bon périphérique.
Pour trouver la bonne valeur, il faut utiliser "lsusb", ensuite il faut
remplacer le 3 par le numéro du bus usb et le 6 par le numéro du
"device" usb.

Cordialement,

On Thu, 11 Jul 2019 11:32:40 +0200
Kohler Gerard  wrote:


bonjour,

voici mon problème :

j'utilise une tablette graphique Wacom, et j'ai un bug au niveau du
mountage USB : lorsque je branche ma tablette en USB, je ne peux plus
mounter des clés USB ou des cartes mémoires, et je suis obligé de
redémarrer la machine pour que cela fonctionne de nouveau. Le simple
fait de me connecter et de me reconnecter ne marche pas. d’où plusieurs
questions :

- comment relancer le système udev sans relancer la machine ?

- lorsque je me déconnecte il reste des processus actifs dont je suis
l'utilisateur entre autre udev est-ce normal ?

|$ps aux |grep gerard|

|gerard    2072  0.0  0.0  21516  9572 ?    Ss juil.10   0:09
/lib/systemd/systemd --user|

/- /quelle démarche diagnostique pour comprendre ce bug (problème au
niveau  des modules Wacom ?)

voici mon système :

Debian GNU/Linux 10 (buster)

Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux

KDE 5.14.5

Qt 5.11.3


merci de votre aide

gerard

Re: openvpn privatvpn

[MERLIN Philippe]

Le jeudi 11 juillet 2019, 19:20:06 CEST Daniel Huhardeaux a écrit :
> Le 11/07/2019 à 18:50, MERLIN Philippe a écrit :
> > Bonsoir,
> 
> Bonsoir
> 
> > Je suis confronté à un problème surprenant et j'ai besoin d'aides pour
> > essayer de  le résoudre.
> > Sur mon ordinateur système Debian AMD 64 je lance un script en étant root
> > pour activer un VPN privatVPN cette procédure fonctionne parfaitement à
> > Paris ou je suis connecté à une Freebox Mini 4K mais par contre ne
> > fonctionne pas aux environs de Royan connecté à une Freebox V5. Aucun
> > message d'erreur au lancement de la procédure mais je me retrouve sans
> > réseau. Une analyse par Wireshark indique seulement que les DNS ne
> > fonctionnent pas.
> > Le script lancé est simple : openvpn /xx/xx/privatvpn.conf
> > A l'avance merci pour votre aide.
> > Philippe Merlin
> 
> Mettre le mode verbose 8 par ex. et regarder les logs. Loguer également
> le status.
Merci pour ta réponse, malheureusement je n'arrive pas à les interpréter à vue 
de nez je ne vois pas d'erreur, n'étant pas un spécialiste réseau . Si 
quelqu'un peut se pencher sur les petits fichiers qui ont été créés à cette 
occasion, je ne peux les mettre en pj car elles ne seront pas acceptées par la 
liste. Je les enverrai personnellement.
Philippe Merlin

Re: Répertoire source de Linux

[Étienne Mollier]

Jean Bernon, au 2019-07-11 :
> Pour compléter notre échange, je crois comprendre ceci. Le
> paquet linux-image-4-19... officiel est signé. Buster utilise
> l'option "secure boot" du bios (si elle est choisie) et
> vérifie la signature de l'image chargée au boot. Si on
> applique le patch du module bluetooth, le linux-image-4-19-...
> chargé au boot n'est plus exactement l'officiel, mais une
> variante qui doit avoir une autre signature (si option "secure
> boot") ou qui peut rester sans signature (si l'on n'utilise
> pas l'option bios "secure boot"). Ai-je bien compris ?

Bonsoir,

Buster supporte le démarrage en UEFI Secure Boot qui,
effectivement, procède à la vérification du noyau chargé au
démarrage de la machine.  Sans faire autorité en la matière, je
dirais que c'est l'idée.  Le détail de ce qui est vérifié, et à
quel moment, entre le chargeur de démarrage Grub, le RAM FS
initial, et finalement le chargement du noyau, m'échappe encore,
pour être honnête avec vous.

Si vous souhaitez signer vos propre noyaux, Greg Kroah Hartman a
eu l'occasion de travailler avec le groupe UEFI.org pour définir
la procédure qu'il a publié sur son blog :


http://www.kroah.com/log/blog/2013/09/02/booting-a-self-signed-linux-kernel/

Ça date de 2013, et c'est en Anglais, mais c'est peut-être
encore valable, si le sujet vous intéresse.  Je n'ai pas trop
l'occasion de vérifier, mon matériel personnel est trop ancien
pour supporter le démarrage UEFI.

Bien à vous,
-- 
Étienne Mollier 
   5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D




signature.asc
Description: OpenPGP digital signature

Re: fail2ban : sshd jail ne fonctionne pas (encore)

[Pierre Malard]

Ok, logique.

Regarde quand même le /var/log/syslog quand tu démarre Fail2Ban…

> Le 11 juil. 2019 à 19:11, Belaïd  a écrit :
> 
> Salut,
> 
> Comme les serveurs sont identiques,  pourquoi ne pas mettre la config des 
> jails dans le même dossier ?  À ta place Je ferai ça dans 
> /etc/fail2ban/jail.d/
> 
> Le jeu. 11 juil. 2019 17:06, fab  > a écrit :
> salut la liste,
> 
> Soient 2 serveurs quasi-identiques sur stretch à jour. fail2ban
> fonctionne correctement sur le serveur B mais pas sur le serveur A. Pour
> l'instant je n'ai paramétré qu'une seule prison sshd.
> 
> 
> serveur A:
> # cat defaults-debian.conf
> [sshd]
> port = 
> enabled = true
> maxretry = 2
> 
> serveur B:
> # cat ../jail.local
> [sshd]
> port = 
> enabled = true
> maxretry = 2
> 
> Les /etc/ssh/ssd_confid des 2 serveurs sont identiques.
> 
> Serveur A et B:
> # iptables -S
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N f2b-sshd
> -A INPUT -p tcp -m multiport --dports  -j f2b-sshd
> -A f2b-sshd -j RETURN
> 
> 
> /var/log/fail2ban.log des Serveurs A et B sont identiques:
> 
>   Stopping all jails
>   Jail 'sshd' stopped
>   Exiting Fail2ban
>   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.6
>   Connected to fail2ban persistent database
> '/var/lib/fail2ban/fail2ban.sqlite3'
>   Creating new jail 'sshd'
>   Jail 'sshd' uses pyinotify {}
>   Initiated 'pyinotify' backend
>   Set jail log file encoding to UTF-8
>   Set maxRetry = 2
>   Added logfile = /var/log/auth.log
>   Set findtime = 600
>   Set banTime = 600
>   Set maxlines = 10
>   Jail sshd is not a JournalFilter instance
>   Jail 'sshd' started
> 
> /etc/hosts.allow sur les 2 serveurs sont les même.
> 
> Bref, c'est tout pareil (à priori).
> 
> Quand je fais un ssh toto@serveurB: et que je rentre un mauvais mot
> de passe, fail2ban me bannit: OK.
> 
> Dans le auth.log du serveur B, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 40664 ssh2
> 
> Quand je fais un ssh toto@serveurA: et que je rentre un mauvais mot
> de passe, fail2ban ne me bannit pas et je n'ai rien dans fail2ban.log.
> 
> Dans le auth.log du serveur A, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Connection closed by 11.22.33.44 port 41342 [preauth]
> PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=11.22.33.44  user=toto
> 
> Tout se passe comme si je n'avais pas démarré fail2an sur le serveur A.
> 
> Si vous avez une piste ou une idée, une vanne ou un bon mot je prends!
> 
> merki,
> 
> f.
> 
> 

--
Pierre Malard

  « on ne risque rien à livrer le secret professionnel car
 on ne livre pas la façon de s’en servir »
  Jean Cocteau - « Le secret professionnel » - 1922

   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,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: openvpn privatvpn

[Daniel Huhardeaux]

Le 11/07/2019 à 18:50, MERLIN Philippe a écrit :

Bonsoir,


Bonsoir


Je suis confronté à un problème surprenant et j'ai besoin d'aides pour essayer
de  le résoudre.
Sur mon ordinateur système Debian AMD 64 je lance un script en étant root pour
activer un VPN privatVPN cette procédure fonctionne parfaitement à Paris ou je
suis connecté à une Freebox Mini 4K mais par contre ne fonctionne pas aux
environs de Royan connecté à une Freebox V5. Aucun message d'erreur au
lancement de la procédure mais je me retrouve sans réseau. Une analyse par
Wireshark indique seulement que les DNS ne fonctionnent pas.
Le script lancé est simple : openvpn /xx/xx/privatvpn.conf
A l'avance merci pour votre aide.
Philippe Merlin



Mettre le mode verbose 8 par ex. et regarder les logs. Loguer également 
le status.


--
Daniel

Re: fail2ban : sshd jail ne fonctionne pas (encore)

[Belaïd]

Salut,

Comme les serveurs sont identiques,  pourquoi ne pas mettre la config des
jails dans le même dossier ?  À ta place Je ferai ça dans
/etc/fail2ban/jail.d/

Le jeu. 11 juil. 2019 17:06, fab  a écrit :

> salut la liste,
>
> Soient 2 serveurs quasi-identiques sur stretch à jour. fail2ban
> fonctionne correctement sur le serveur B mais pas sur le serveur A. Pour
> l'instant je n'ai paramétré qu'une seule prison sshd.
>
>
> serveur A:
> # cat defaults-debian.conf
> [sshd]
> port = 
> enabled = true
> maxretry = 2
>
> serveur B:
> # cat ../jail.local
> [sshd]
> port = 
> enabled = true
> maxretry = 2
>
> Les /etc/ssh/ssd_confid des 2 serveurs sont identiques.
>
> Serveur A et B:
> # iptables -S
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N f2b-sshd
> -A INPUT -p tcp -m multiport --dports  -j f2b-sshd
> -A f2b-sshd -j RETURN
>
>
> /var/log/fail2ban.log des Serveurs A et B sont identiques:
>
>   Stopping all jails
>   Jail 'sshd' stopped
>   Exiting Fail2ban
>   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.6
>   Connected to fail2ban persistent database
> '/var/lib/fail2ban/fail2ban.sqlite3'
>   Creating new jail 'sshd'
>   Jail 'sshd' uses pyinotify {}
>   Initiated 'pyinotify' backend
>   Set jail log file encoding to UTF-8
>   Set maxRetry = 2
>   Added logfile = /var/log/auth.log
>   Set findtime = 600
>   Set banTime = 600
>   Set maxlines = 10
>   Jail sshd is not a JournalFilter instance
>   Jail 'sshd' started
>
> /etc/hosts.allow sur les 2 serveurs sont les même.
>
> Bref, c'est tout pareil (à priori).
>
> Quand je fais un ssh toto@serveurB: et que je rentre un mauvais mot
> de passe, fail2ban me bannit: OK.
>
> Dans le auth.log du serveur B, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 40664 ssh2
>
> Quand je fais un ssh toto@serveurA: et que je rentre un mauvais mot
> de passe, fail2ban ne me bannit pas et je n'ai rien dans fail2ban.log.
>
> Dans le auth.log du serveur A, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Connection closed by 11.22.33.44 port 41342 [preauth]
> PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=11.22.33.44  user=toto
>
> Tout se passe comme si je n'avais pas démarré fail2an sur le serveur A.
>
> Si vous avez une piste ou une idée, une vanne ou un bon mot je prends!
>
> merki,
>
> f.
>
>
>

openvpn privatvpn

[MERLIN Philippe]

Bonsoir,
Je suis confronté à un problème surprenant et j'ai besoin d'aides pour essayer 
de  le résoudre. 
Sur mon ordinateur système Debian AMD 64 je lance un script en étant root pour 
activer un VPN privatVPN cette procédure fonctionne parfaitement à Paris ou je 
suis connecté à une Freebox Mini 4K mais par contre ne fonctionne pas aux 
environs de Royan connecté à une Freebox V5. Aucun message d'erreur au 
lancement de la procédure mais je me retrouve sans réseau. Une analyse par 
Wireshark indique seulement que les DNS ne fonctionnent pas.
Le script lancé est simple : openvpn /xx/xx/privatvpn.conf
A l'avance merci pour votre aide.
Philippe Merlin

Re: fail2ban : sshd jail ne fonctionne pas (encore)

[Pierre Malard]

Salut,

En supposant bien entendu que tu as installé le paquet Fail2Ban de Debian et 
pas un source venant du site du développeur…

Ça n’a peut-être rien à voir mais « Fail2Ban » préfère maintenant la 
déclaration des déclarations de taules (« jail ») dans un répertoire spécifique 
(« /etc/fail2ban/jail.d »). SI tu as déclaré une configuration dans le 
/etc/fail2ban/jail.local et qu’il en existe une spécifique à SSH dans le 
/etc/fail2ban/jail.d/, je ne sais pas lequel « aura raison ».

Une autre piste pour suivre le lancement de Fail2Ban c’est de suivre son 
lancement dans le fichier log /var/log/syslog. Avant de voir le comportement 
une fois lancé, il est bon de savoir s’il n’y a pas eu un problème … au 
lancement. C’est là que le lancement est suivit. Avant de voir le comportement 
une fois lancé, il est bon de savoir s’il n’y a pas eu un problème … au 
lancement.
À ce jeu, je me suis rendu compte que certains services n’écrivent pas par 
défaut leurs logs dans les fichiers déclarés par défaut dans Fail2Ban. Tout ça 
se trouve dans les fichiers « /etc/fail2ban/path-….conf ».

Sinon, pour savoir si Fail2Ban tourne, un simple :
# ps -ef | grep fail2ban
suffit.

> Le 11 juil. 2019 à 17:06, fab  a écrit :
> 
> salut la liste,
> 
> Soient 2 serveurs quasi-identiques sur stretch à jour. fail2ban
> fonctionne correctement sur le serveur B mais pas sur le serveur A. Pour 
> l'instant je n'ai paramétré qu'une seule prison sshd.
> 
> 
> serveur A:
> # cat defaults-debian.conf
> [sshd]
> port = 
> enabled = true
> maxretry = 2
> 
> serveur B:
> # cat ../jail.local
> [sshd]
> port = 
> enabled = true
> maxretry = 2
> 
> Les /etc/ssh/ssd_confid des 2 serveurs sont identiques.
> 
> Serveur A et B:
> # iptables -S
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N f2b-sshd
> -A INPUT -p tcp -m multiport --dports  -j f2b-sshd
> -A f2b-sshd -j RETURN
> 
> 
> /var/log/fail2ban.log des Serveurs A et B sont identiques:
> 
> Stopping all jails
> Jail 'sshd' stopped
> Exiting Fail2ban
> Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.6
> Connected to fail2ban persistent database
> '/var/lib/fail2ban/fail2ban.sqlite3'
> Creating new jail 'sshd'
> Jail 'sshd' uses pyinotify {}
> Initiated 'pyinotify' backend
> Set jail log file encoding to UTF-8
> Set maxRetry = 2
> Added logfile = /var/log/auth.log
> Set findtime = 600
> Set banTime = 600
> Set maxlines = 10
> Jail sshd is not a JournalFilter instance
> Jail 'sshd' started
> 
> /etc/hosts.allow sur les 2 serveurs sont les même.
> 
> Bref, c'est tout pareil (à priori).
> 
> Quand je fais un ssh toto@serveurB: et que je rentre un mauvais mot
> de passe, fail2ban me bannit: OK.
> 
> Dans le auth.log du serveur B, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 40664 ssh2
> 
> Quand je fais un ssh toto@serveurA: et que je rentre un mauvais mot
> de passe, fail2ban ne me bannit pas et je n'ai rien dans fail2ban.log.
> 
> Dans le auth.log du serveur A, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Connection closed by 11.22.33.44 port 41342 [preauth]
> PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=11.22.33.44  user=toto
> 
> Tout se passe comme si je n'avais pas démarré fail2an sur le serveur A.
> 
> Si vous avez une piste ou une idée, une vanne ou un bon mot je prends!
> 
> merki,
> 
> f.
> 
> 

--
Pierre Malard

À propos de nos chers économistes :
«Les habiles, dans notre siècle, se sont décernés a eux-mêmes la
qualification d’homme d’état. [...] ces politiques, ingénieux
a mettre aux fictions profitables un masque de nécessité.»
 Victor Hugo : “Les misérables”, La pléiade, Gallimard, P. 843

   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,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

fail2ban : sshd jail ne fonctionne pas (encore)

[fab]

salut la liste,

Soient 2 serveurs quasi-identiques sur stretch à jour. fail2ban
fonctionne correctement sur le serveur B mais pas sur le serveur A. Pour 
l'instant je n'ai paramétré qu'une seule prison sshd.



serveur A:
# cat defaults-debian.conf
[sshd]
port = 
enabled = true
maxretry = 2

serveur B:
# cat ../jail.local
[sshd]
port = 
enabled = true
maxretry = 2

Les /etc/ssh/ssd_confid des 2 serveurs sont identiques.

Serveur A et B:
# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N f2b-sshd
-A INPUT -p tcp -m multiport --dports  -j f2b-sshd
-A f2b-sshd -j RETURN


/var/log/fail2ban.log des Serveurs A et B sont identiques:

 Stopping all jails
 Jail 'sshd' stopped
 Exiting Fail2ban
 Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.6
 Connected to fail2ban persistent database
'/var/lib/fail2ban/fail2ban.sqlite3'
 Creating new jail 'sshd'
 Jail 'sshd' uses pyinotify {}
 Initiated 'pyinotify' backend
 Set jail log file encoding to UTF-8
 Set maxRetry = 2
 Added logfile = /var/log/auth.log
 Set findtime = 600
 Set banTime = 600
 Set maxlines = 10
 Jail sshd is not a JournalFilter instance
 Jail 'sshd' started

/etc/hosts.allow sur les 2 serveurs sont les même.

Bref, c'est tout pareil (à priori).

Quand je fais un ssh toto@serveurB: et que je rentre un mauvais mot
de passe, fail2ban me bannit: OK.

Dans le auth.log du serveur B, j'ai :
pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
tty=ssh ruser= rhost=11.22.33.44  user=toto
Failed password for toto from 11.22.33.44 port 40664 ssh2

Quand je fais un ssh toto@serveurA: et que je rentre un mauvais mot
de passe, fail2ban ne me bannit pas et je n'ai rien dans fail2ban.log.

Dans le auth.log du serveur A, j'ai :
pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
tty=ssh ruser= rhost=11.22.33.44  user=toto
Failed password for toto from 11.22.33.44 port 41342 ssh2
Failed password for toto from 11.22.33.44 port 41342 ssh2
Failed password for toto from 11.22.33.44 port 41342 ssh2
Connection closed by 11.22.33.44 port 41342 [preauth]
PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser=
rhost=11.22.33.44  user=toto

Tout se passe comme si je n'avais pas démarré fail2an sur le serveur A.

Si vous avez une piste ou une idée, une vanne ou un bon mot je prends!

merki,

f.

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

[Eric Degenetais]

Le jeu. 11 juil. 2019 à 16:10, Christian Quentin
 a écrit :
>
> Bonjour,
>

Bonjour,

> Je viens de refaire une install avec Debian 10 Stable.
>
> Le comportement reste le même : Linux semble bien s'arrêter, l'écran s'éteint 
> mais le PC ne s'éteint pas.
>
> Faut-il remonter le problème ?
>
Oui ! Peut-être serait-il pertinent si c'est possible de faire une
comparaison rapide si possible : par exemple la machine fonctionne
t'elle avec un live stretch ? (pour voir si c'est une régression ou si
ça n'a jamais marché). A t'elle eu un autre OS avec lequel
l'extinction se passait bien ? (pour essayer d'exclure un problème de
matériel / de bios)

utiliser reportbug si possible pour avoir la collecte automatique du
maximum d'informations sur le matériel et les versions logicielles
diverses.

> Christian
>
>

Éric Dégenètais

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

[Christian Quentin]

Bonjour, 

Je viens de refaire une install avec Debian 10 Stable. 

Le comportement reste le même : Linux semble bien s'arrêter, l'écran
s'éteint mais le PC ne s'éteint pas. 

Faut-il remonter le problème ? 

Christian

Re: Quel test unitaire illustre le problème que corrige "-j TCPMSS --clamp-mss-to-pmtu" ?

[Olivier]

Le jeu. 11 juil. 2019 à 14:04, Bernard Schoenacker <
bernard.schoenac...@free.fr> a écrit :

>
> bonjour,
>
> serait il possible de régler le mtu à 1492 sur la passerelle ?
>
>
Sauf erreur, le MTU était déjà réglé à 1492 sur le lien ppp0, si j'en crois
la sortie d' "ip link" .
En commentant-décommentant ma commande iptables, l'accès au site web marche
ou non.

Par ailleurs, j'ai :
ping -M do -s 1492 192.168.4.254
PING 192.168.4.254 (192.168.4.254) 1492(1520) bytes of data.
ping: local error: Message too long, mtu=1492

où 192.168.4.254 est l'IP de mon serveur PPPoE (sur lequel le MTU est aussi
valorisé à 1492).

La valeur la plus grande pour laquelle le ping ci-dessus réussit est 1464
(le hack iptables ne change rien à cet égard).
ping -M do -s 1464 192.168.4.254
PING 192.168.4.254 (192.168.4.254) 1464(1492) bytes of data.
1472 bytes from 192.168.4.254: icmp_seq=1 ttl=64 time=1.21 ms

Re: Cups collecte toutes les imprimantes

[Bertrand Orvoine]

On Wed, Jul 10, 2019 at 10:35:53PM +0200, C. Mourad Jaber wrote:
> Bonsoir,

Bonjour,

> 
> J'ai une question concernant CUPS... Je constate qu'il enregistre toutes les
> imprimantes de tous les réseaux sur lequel je me connecte...
> 
> C'est très problématique puisque je me retrouve avec plusieurs 100aines
> d'imprimantes dont je n'ai aucune utilité...
> 
> Est-il possible d'eviter cet enregistrement automatique ?

oui, il faut enlever le paquet "cups-browsed" :

Description-fr: filtres CUPS OpenPrinting — cups-browsed
 Ce paquet fournit cups-browsed, un démon qui parcourt les transmissions
 Bonjour d'imprimantes partagées distantes et rend ces dernières disponibles
 localement en remplaçant la transmission/navigation de CUPS
 abandonnée dans sa version 1.6.x. De cette façon, l'ancien comportement
 consistant à avoir les imprimantes distantes immédiatement disponibles est
 de nouveau mise en œuvre avec Bonjour.

A+

> 
> Est-il possible de les reconnaitres dans la configuration de CUPS et de les
> supprimer en bloc ?
> 
> Merci beaucoup
> 
> Mourad
> 

-- 
Bertrand Orvoine

Re: Quel test unitaire illustre le problème que corrige "-j TCPMSS --clamp-mss-to-pmtu" ?

[Bernard Schoenacker]

- Mail original - 

> De: "Olivier" 
> À: "ML Debian User French" 
> Envoyé: Jeudi 11 Juillet 2019 12:53:26
> Objet: Quel test unitaire illustre le problème que corrige "-j TCPMSS
> --clamp-mss-to-pmtu" ?

> Bonjour,

> Dans mon labo, j'ai mis en place un environnement qui simule une
> connexion d'Orange s'appuyant sur PPPoE.

> Tout à fait par hasard, en jouant le rôle d'utilisateur se connectant
> avec son terminal à cet environnement, je me suis rendu compte que
> pouvais surfer sur de multiples sites web ( lemonde.fr , ...) et que
> j'échouais systématiquement sur l'un d'eux.

> Poutant, en me connectant à ce site, via un autre réseau local, la
> connexion s'établissait normalement.

> Avec des captures Wireshark, j'ai vu que dans l'environnement en
> défaut, un message "ICMP Don't Fragment" était émis. Ce message m'a
> fait penser à un problème de MTU.
> En me documentant sur des problèmes de MTU, j'ai découvert dans [1]
> le MSS Clamping.
> En ajoutant à un firewall la règle ci-après, j'ai pu me connecter au
> site web qui posait problème.

> iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o
> ppp0 -j TCPMSS --clamp-mss-to-pmtu

> Cette anomalie découverte par hasard me donne envie d'avoir une
> méthode plus rationnelle pour vérifier le bon fonctionnement d'un
> service réseau.

> Plus spécifiquement, j'aimerai a minima, savoir quelle commande
> permet de détecter le problème corrigé par la cible -j TCPMSS
> --clamp-mss-to-pmtu de mes règles iptables ?

> [1] https://inetdoc.net/guides/iptables-tutorial/tcpmsstarget.html

> Slts


bonjour,

serait il possible de régler le mtu à 1492 sur la passerelle ?
doc à peut près correcte :
https://askubuntu.com/questions/826525/how-do-i-increase-pppoe-mtu

https://samuel.kadolph.com/2015/02/mtu-and-tcp-mss-when-using-pppoe-2/

exemple de conf :
https://blog.confirm.ch/using-pppoe-on-linux/

remarque: je le fait d'après mes souvenirs lorsqu'il fallait utiliser
rpppoe 

merci

slt
bernard

Re: blocage du système USB

[Guillaume Clercin]

Bonjour,

Sur un macbook, le clavier et le touchpad sont branchés sur le même bus
usb. Et il arrivé que le touchpad s'arrête de fonctionner. Et je le
redémarre avec un petit script shell.

---
#! /bin/bash
echo "Reset keyboard"

echo -n "Disable keyboard... "
echo 0 > /sys/bus/usb/devices/3-6/authorized && echo ok || echo failed

sleep 1

echo -n "Re-esable keyboard... "
echo 1 > /sys/bus/usb/devices/3-6/authorized && echo ok || echo failed
---

Ça peut servir de base mais il faut remplacer 3-6 par le bon périphérique.
Pour trouver la bonne valeur, il faut utiliser "lsusb", ensuite il faut
remplacer le 3 par le numéro du bus usb et le 6 par le numéro du
"device" usb.

Cordialement,

On Thu, 11 Jul 2019 11:32:40 +0200
Kohler Gerard  wrote:

> bonjour,
> 
> voici mon problème :
> 
> j'utilise une tablette graphique Wacom, et j'ai un bug au niveau du 
> mountage USB : lorsque je branche ma tablette en USB, je ne peux plus 
> mounter des clés USB ou des cartes mémoires, et je suis obligé de 
> redémarrer la machine pour que cela fonctionne de nouveau. Le simple 
> fait de me connecter et de me reconnecter ne marche pas. d’où plusieurs 
> questions :
> 
> - comment relancer le système udev sans relancer la machine ?
> 
> - lorsque je me déconnecte il reste des processus actifs dont je suis 
> l'utilisateur entre autre udev est-ce normal ?
> 
> |$ps aux |grep gerard|
> 
> |gerard    2072  0.0  0.0  21516  9572 ?    Ss juil.10   0:09 
> /lib/systemd/systemd --user|
> 
> /- /quelle démarche diagnostique pour comprendre ce bug (problème au 
> niveau  des modules Wacom ?)
> 
> voici mon système :
> 
> Debian GNU/Linux 10 (buster)
> 
> Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux
> 
> KDE 5.14.5
> 
> Qt 5.11.3
> 
> 
> merci de votre aide
> 
> gerard
> 
> 

-- 
Guillaume Clercin


pgpvLSiKtt56F.pgp
Description: Signature digitale OpenPGP

Quel test unitaire illustre le problème que corrige "-j TCPMSS --clamp-mss-to-pmtu" ?

[Olivier]

Bonjour,

Dans mon labo, j'ai mis en place un environnement qui simule une connexion
d'Orange s'appuyant sur PPPoE.

Tout à fait par hasard, en jouant le rôle d'utilisateur se connectant avec
son terminal à cet environnement, je me suis rendu compte que pouvais
surfer sur de multiples sites web (lemonde.fr, ...) et que j'échouais
systématiquement sur l'un d'eux.

Poutant, en me connectant à ce site, via un autre réseau local, la
connexion s'établissait normalement.

Avec des captures Wireshark, j'ai vu que dans l'environnement en défaut, un
message "ICMP Don't Fragment" était émis. Ce message m'a fait penser à un
problème de MTU.
En me documentant sur des problèmes de MTU, j'ai découvert dans [1] le MSS
Clamping.
En ajoutant à un firewall la règle ci-après, j'ai pu me connecter au site
web qui posait problème.

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ppp0 -j
TCPMSS --clamp-mss-to-pmtu

Cette anomalie découverte par hasard me donne envie d'avoir une méthode
plus rationnelle pour vérifier le bon fonctionnement d'un service réseau.

Plus spécifiquement, j'aimerai a minima, savoir quelle commande permet de
détecter le problème corrigé par la cible -j TCPMSS --clamp-mss-to-pmtu de
mes règles iptables ?

[1] https://inetdoc.net/guides/iptables-tutorial/tcpmsstarget.html

Slts

blocage du système USB

[Kohler Gerard]

bonjour,

voici mon problème :

j'utilise une tablette graphique Wacom, et j'ai un bug au niveau du 
mountage USB : lorsque je branche ma tablette en USB, je ne peux plus 
mounter des clés USB ou des cartes mémoires, et je suis obligé de 
redémarrer la machine pour que cela fonctionne de nouveau. Le simple 
fait de me connecter et de me reconnecter ne marche pas. d’où plusieurs 
questions :


- comment relancer le système udev sans relancer la machine ?

- lorsque je me déconnecte il reste des processus actifs dont je suis 
l'utilisateur entre autre udev est-ce normal ?


|$ps aux |grep gerard|

|gerard    2072  0.0  0.0  21516  9572 ?    Ss juil.10   0:09 
/lib/systemd/systemd --user|


/- /quelle démarche diagnostique pour comprendre ce bug (problème au 
niveau  des modules Wacom ?)


voici mon système :

Debian GNU/Linux 10 (buster)

Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux

KDE 5.14.5

Qt 5.11.3


merci de votre aide

gerard

Re: Re : Re: [HS] Re : Lumière bleue des moniteurs led ?

[hamster]

Le 11/07/2019 à 08:47, Eric Degenetais a écrit :
> Il va falloir que je retourne à mes références, mais de mémoire le
> circuit nerveux qui ajuste les biorythmes en fonction de la
> photopériode n'est alimenté que par les bâtonnets

Non, par des recepteurs spécifiques (ni les cones ni les batonnets) qui
ne sont sensibles qu'au bleu. C'est d'ailleurs pourquoi certains
aveugles sont quand même calés sur la photoperiode malgré qu'ils ne
voient pas.

Re: Répertoire source de Linux

[Jean Bernon]

Pour compléter notre échange, je crois comprendre ceci. Le paquet 
linux-image-4-19... officiel est signé. Buster utilise l'option "secure boot" 
du bios (si elle est choisie) et vérifie la signature de l'image chargée au 
boot. Si on applique le patch du module bluetooth, le linux-image-4-19-... 
chargé au boot n'est plus exactement l'officiel, mais une variante qui doit 
avoir une autre signature (si option "secure boot") ou qui peut rester sans 
signature (si l'on n'utilise pas l'option bios "secure boot"). Ai-je bien 
compris ? 


- Mail original - 

> De: "Jean Bernon" 
> À: "Étienne Mollier" 
> Cc: debian-user-french@lists.debian.org
> Envoyé: Mardi 9 Juillet 2019 22:57:01
> Objet: Re: Répertoire source de Linux

> - Mail original -

> > De: "Étienne Mollier" 
> > À: debian-user-french@lists.debian.org
> > Envoyé: Mardi 9 Juillet 2019 20:18:38
> > Objet: Re: Répertoire source de Linux

> > Jean Bernon, au 2019-07-09 :
> > > Je viens de migrer sans problème de Stretch à Buster. Mais
> > > j'utilise un driver wifi/bluetooth spécial (mt7630e) que je
> > > dois réinstaller à chaque changement de version Linux. Les
> > > scripts d'installation ont fonctionné sans problème depuis 5
> > > ans. Avec Buster le script d'installation du wifi a bien
> > > fonctionné. En revanche côté bluetooth, le script qui patche
> > > btusb.c et génére un btusb.ko modifié, bute sur la création
> > > d'un répertoire source de Linux. Il y a un problème inédit de
> > > source signé et non signé que je comprends mal. En tout cas le
> > > script veut désinstaller linux-image-4.19 et installer à la
> > > place une version non signée. Voir ci-dessous.
> > >
> > > Si je réponds OK, j'obtiens un ferme avertissement de ne pas
> > > continuer...
> > >
> > > Qui aurait une suggestion pour en sortir sans tout casser ?

> > Bonsoir,

> > Les paquets linux signés et non-signés le sont au sens du « UEFI
> > Secure Boot », dont le support est apparu en Debian 10. En
> > utilisant un paquet non-signé, le boot UEFI Secure Boot ne sera
> > plus possible. Étant donné que vous avez migré depuis Debian
> > Stretch, je suppose que vous n'avez pas activé cette option de
> > sécurité entre temps.

> > À mon sens, il n'y a pas de risque majeur de casse.

> > Bien à vous,
> > --
> > Étienne Mollier 
> > 5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D

> Merci pour l'explication. Je vais piocher ça un peu plus, avant de
> relancer le script. Le bluetooth n'est pas immédiatement
> indispensable. Je donnerai un retour à ce moment.

firefox 67

[Gérard Sarram]

Bonjour,
mes excuses pour ce retard: pb de trasmission du message avec gmail.
@Alexandre Goetals
Merci pour cette précision, je vais essayer votre proposition et alacarete

gesar


-- 
Amicalement

Gérard

Re: Re : Re: [HS] Re : Lumière bleue des moniteurs led ?

[Pierre L.]

Joliment dit :)

Le 11/07/2019 à 07:29, cont...@billard-francois-marie.eu a écrit :
> dans le domaine de l'éclairagisme il existe des règles très claires




signature.asc
Description: OpenPGP digital signature

Re: Re : Re: [HS] Re : Lumière bleue des moniteurs led ?

[Eric Degenetais]

Il va falloir que je retourne à mes références, mais de mémoire le circuit
nerveux qui ajuste les biorythmes en fonction de la photopériode n'est
alimenté que par les bâtonnets, par conséquent il est peut-être plus
sensible au bleu qu'au reste, mais il se contrefout de la composition
spectrale, puisqu'il n'est pas à même de la mesurer. Qu'un fort éclairage
tard dans la soirée soit néfaste c'est possible mais à mon avis il pourrait
être vert et faire le même effet si l'intensité est assez grande. Et les
écrans éclairent beaucoup moins fort que le soleil.
J'ai eu des endormissements perturbés par des bouquins, étaient ils aussi
surpuissants dans la composante bleue ?

Par contre je pense que le risque d'un problème lié à une trop forte
émission d'UV pourrait exister (l'écran étant souvent à moins d'un
mètre...) mais là bonne chance pour s'en protéger par des réglages...

Éric Dégenètais

Le jeu. 11 juil. 2019 07:30, cont...@billard-francois-marie.eu <
cont...@billard-francois-marie.eu> a écrit :

> Bonjour, dans le domaine de l'éclairagisme il existe des règles très
> claires concernant l'installation des points lumineux. En effet en fonction
> de l'utilisation du lieu, des couleurs des locaux des apports de lumière
> naturelle et du type de luminaire il est aisé de déterminer le nombre à
> installer.
> Il existe un logiciel assez efficace
> https://www.dial.de/en/dialux/
> Qui permet aussi de voir le résultat de l'étude en 3D et exploité un
> nombre impressionnant de luminaires de fabriquants différents.
> F
> Le Jeudi, Juillet 11, 2019 03:06 CEST, k6dedi...@free.fr a écrit:
>
>
> Bonjour Bertrand,
> J'ai de vagues souvenirs concernant l'éclairage des locaux.
> Dans les années 1970, lorsque j'ai eu des locaux à éclairer, nous prenions
> en compte les LUX et la température de couleur en KELVIN.
> Les mesures se faisaient en lumière réfléchie sur le plan de travail.
> Ainsi selon que c'était une salle à manger, une chambre, un atelier, un
> bureau d'études, ... nous n'appliquions pas les mêmes valeurs.
> Pour un bureau d'études il fallait de 300 à 500 LUX avec une température
> de couleur de 4000 à 5000°K
> Pour une chambre 50 à 100 LUX et 2800 à 3200°K, ce qui est suffisant pour
> un éclairage d'ambiance reposant et clair. (Ce n'est pas une veilleuse,
> c'est un éclairage d'ambiance)
> De mémoire, une bougie fait 1 LUX à 2600°K on y voit mais on a du mal à
> lire.
> Selon que l'on doivent lire, voir ce que l'on mange ou bricole,
> l'éclairage doit être adapté.
> Un peintre qui veut choisir ses nuances de couleur avec précision devra
> avoir un éclairage assez puissant avec une température proche des 5000°K
> qui est considérée comme la température de couleur la plus neutre. Pour
> information, un ciel nuageux très clair peut atteindre 11000°K et est
> limite éblouissant.
>
> Or aujourd'hui nous ne trouvons plus la valeur en LUX, les industriels ont
> réussi à imposer la valeur de flux lumineux qui décroît avec le carré de la
> distance et qui ne tient pas compte de la couleur du fond.
> Le public est donc en possession d'éléments ne pouvant lui permettre de
> comprendre, donc de choisir.
> Si vous regardez les professionnels, photographes, cinéastes,
> éclairagistes, ..., ils utilisent tous un luxmètre et non un fluxmètre. Ils
> ont aussi un indicateur de température de couleur qui donne des mesure en
> degré KELVIN.
> Lorsque les spécifications indiquaient la valeur en LUX, cette valeur
> était donnée pour l'éclairage d'une surface blanche à 1 mètre du centre de
> la source lumineuse. Sachant que pour tout mètre supplémentaire la valeur
> diminue du quart, il était facile de calculer la puissance d'éclairage à
> installer.
> Il y a donc un travail à faire dans ce domaine.
>
> Bon courage
> Cassis
>
>
>
> - Mail d'origine -
> De: BERTRAND Joël 
> À: Debian user french 
> Envoyé: Wed, 10 Jul 2019 15:34:13 +0200 (CEST)
> Objet: Re: [HS] Re : Lumière bleue des moniteurs led ?
>
> Christophe Moille a écrit :
> > L'Anses confirme la toxicité de la lumière bleue émises par les lumières
> > led
> > C'est le titre d'un article de batiactu:
> >
> https://www.batiactu.com/edito/anses-confirme-toxicite-lumiere-bleue-emises-par-lumieres-56408.php
> >
> > "Les systèmes utilisant des diodes électroluminescentes (led) ont connu
> > une expansion considérable suite à la Directive européenne sur
> > l'éco-conception (2007) qui a conduit au retrait des lampes
> > traditionnelles, jugées trop énergivores. Depuis, ces dispositifs sont
> > partout,
> > des éclairages domestiques, publics ou encore dans les jouets des
> > enfants. Cependant, la lumière bleue émise par ces systèmes a des effets
> > nocifs sur l'acuité visuelle, le sommeil et l'environnement, selon un
> > avis de l'Agence nationale de sécurité sanitaire (Anses), publié ce
> > mardi 14 mai 2019. "
> >
>
> Il y a tout de même un truc qu'il faudra que l'on m'explique un jour.
> Je suis physicien de formation et, justement, je me suis penché un petit
> peu sur