subject:"clavier"




Le 08/05/2024 à 17:00, Gaëtan Perrier a écrit :

Le mercredi 08 mai 2024 à 15:11 +0200, Gaëtan Perrier a écrit :

Bonjour,

J'ai aussi ce problème sous sid/gnome.
Ca semble être ce bug :

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

A+

Gaëtan


Le bug est marqué résolu. Y a plus qu'a attendre que les paquets arrivent dans
les depots ...


Pour sid ça devrait arriver dans quelques heures, cinq jours dans 
testing normalement. à moins qu'il y ait une procédure accélérée que je 
ne connaisse pas pour ce genre de chose dans testing.
C'est moins prévisible pour stable, il faut que l'équipe en charge de 
bookworm-security accepte une nouvelle version qui corrige cette régression.
En attendant, de mon côté j'ai créé un fichier 
/etc/apt/preferences.d/glib.pref avec le contenu suivant :
package: libglib2.0-dev-bin libglib2.0-bin libglib2.0-dev 
libglib2.0-data libglib2.0-0

Pin: version 2.74.6-2+deb12u1
Pin-Priority: -1

Ce qui empêche la mise à jour vers la version cassé tout en permettant à 
la future mise à jour corrective de s'installer si j'ai bien compris ce 
qui m'a été expliqué au moment de la mise en place de cette config :-)


--
Patrick ZAJDA

Re: perte de la touche morte du clavier pour saisir les accents circonflexes depuis une mise à jour système

2024-05-08 Par sujet Gaëtan Perrier

Le mercredi 08 mai 2024 à 15:11 +0200, Gaëtan Perrier a écrit :
> Bonjour,
> 
> J'ai aussi ce problème sous sid/gnome.
> Ca semble être ce bug :
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070736
> 
> A+
> 
> Gaëtan
> 

Le bug est marqué résolu. Y a plus qu'a attendre que les paquets arrivent dans
les depots ...

Gaëtan


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

[résolu, au moins provisoirement] Re: perte de la touche morte du clavier pour saisir les accents circonflexes depuis une mise à jour système

2024-05-08 Par sujet Frédéric Baldit



Pour ma part, en revenant comme indiqué par Patrick ZADJA à la version
antérieure des 5 paquets concernés:

ibglib2.0-dev-bin
libglib2.0-bin
libglib2.0-dev
libglib2.0-data
libglib2.0-0

le problème est effectivement résolu (touche mortes fonctionnelles).

Merci beaucoup pour votre aide!

Je suppose, comme lu quelque part, qu'une version 2.74.6-2+deb12u2 de
ces paquets va arriver bientÔÔt et corrigera ce bug.

Bien cordialement, 

--
  Frédéric Baldit

Le mer. 08 mai 2024 à 15:11:12 +0200
Gaëtan Perrier  a écrit:

> Bonjour,
> 
> J'ai aussi ce problème sous sid/gnome.
> Ca semble être ce bug :
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070736
> 
> A+
> 
> Gaëtan
> 
> Le mercredi 08 mai 2024 à 10:12 +0200, Txo a écrit :
> > Le 08/05/2024 à 05:42, Frédéric Baldit a écrit :  
> > > 
> > > Bonjour,  
> > 
> > Bonjour,
> >   
> > > 
> > > depuis la dernière mise à jour de mon système (Bookworm sous
> > > Gnome), je n'ai plus accès avec mon clavier à la saisie des
> > > accents circonflexes avec la touche morte de mon clavier (qui
> > > utilise le layout «Français, obsolete, variante»).
> > > 
> > > Le phénomène est visible par exemple dans un terminal, dans emacs
> > > ou depuis claws-mail. J'ai tenté un
> > >   
> > 
> > Pareil ici avec Sid.  
> > > 
> > > ...sans succès. Curieusement, dans la zone de saisie d'un
> > > navigateur cette touche fonctionne, ainsi que dans le terminal
> > > zutty. Si je me connecte Aussi, si je me connecte sur tty3 (après
> > > Ctrl-Alt-F3), j'ai bien l'usage de cette touche. Je sèche...
> > >   
> > 
> > Par contre je n'ai mème pas cela, c'est partout qu'il me manque les 
> > accents. Merci au correcteur... Tout aussi sec.
> > 
> >   
>

Re: perte de la touche morte du clavier pour saisir les accents circonflexes depuis une mise à jour système

2024-05-08 Par sujet Charles Plessy

Le Wed, May 08, 2024 at 03:21:24PM +0200, Frédéric Baldit a écrit :
> 
>  Je suppose qu'il vaut mieux m'abstenir...qu'en pensez-vous?

Le bug 1070730 suggère d'essayer les paquets de 
https://people.debian.org/~smcv/bug1070730/
en attendant le correctif officiel, et de mon côté ça a réglé le
problème après avoir redémarré Firefox.

Bonne chance,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: perte de la touche morte du clavier pour saisir les accents circonflexes depuis une mise à jour système

 paquets suivants seront installés :
   policykit-1-gnome
Les paquets suivants seront mis à une VERSION INFÉRIEURE :
   libglib2.0-0
0 mis à jour, 1 nouvellement installés, 1 remis à une version
inférieure, 59 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 1 463 ko dans les archives.
Après cette opération, 130 Mo d'espace disque seront libérés.
Souhaitez-vous continuer ? [O/n] n
Annulation.

###  fin copie 

  Je suppose qu'il vaut mieux m'abstenir...qu'en pensez-vous?
--
   Frédéric Baldit

Le mer. 08 mai 2024 à 12:41:18 +0200
Patrick ZAJDA  a écrit:


Bonjour,

JE suis sous Bookworm et il semble que ça soit la version
2.74.6-2+deb12u1 de libglib2.0-0 (et autres paquets libglib)
disponibles dans bookworm-security qui pose problème.
Après downgrade de tous ces paquets vers la version 2.74.6-2 de
bookworm, je peux à nouveau utiliser la touche accent circonflexe.
Il semble donc que cette mise à jour de sécurité entraîne une
régression pour nos claviers.
Pour information, j'utilise Mate comme environnement de bureau.

Patrick


Le 08/05/2024 à 10:12, Txo a écrit :

Le 08/05/2024 à 05:42, Frédéric Baldit a écrit :

Bonjour,

Bonjour,


depuis la dernière mise à jour de mon système (Bookworm sous
Gnome), je n'ai plus accès avec mon clavier à la saisie des
accents circonflexes avec la touche morte de mon clavier (qui
utilise le layout «Français, obsolete, variante»).

Le phénomène est visible par exemple dans un terminal, dans emacs
ou depuis claws-mail. J'ai tenté un


Pareil ici avec Sid.

...sans succès. Curieusement, dans la zone de saisie d'un
navigateur cette touche fonctionne, ainsi que dans le terminal
zutty. Si je me connecte Aussi, si je me connecte sur tty3 (après
Ctrl-Alt-F3), j'ai bien l'usage de cette touche. Je sèche...


Par contre je n'ai mème pas cela, c'est partout qu'il me manque les
accents. Merci au correcteur... Tout aussi sec.






--
Patrick ZAJDA

Re: perte de la touche morte du clavier pour saisir les accents circonflexes depuis une mise à jour système

 seront libérés.
Souhaitez-vous continuer ? [O/n] n
Annulation.

###  fin copie 

  Je suppose qu'il vaut mieux m'abstenir...qu'en pensez-vous?
--
   Frédéric Baldit

Le mer. 08 mai 2024 à 12:41:18 +0200
Patrick ZAJDA  a écrit:


Bonjour,

JE suis sous Bookworm et il semble que ça soit la version
2.74.6-2+deb12u1 de libglib2.0-0 (et autres paquets libglib)
disponibles dans bookworm-security qui pose problème.
Après downgrade de tous ces paquets vers la version 2.74.6-2 de
bookworm, je peux à nouveau utiliser la touche accent circonflexe.
Il semble donc que cette mise à jour de sécurité entraîne une
régression pour nos claviers.
Pour information, j'utilise Mate comme environnement de bureau.

Patrick


Le 08/05/2024 à 10:12, Txo a écrit :

Le 08/05/2024 à 05:42, Frédéric Baldit a écrit :

Bonjour,

Bonjour,


depuis la dernière mise à jour de mon système (Bookworm sous
Gnome), je n'ai plus accès avec mon clavier à la saisie des
accents circonflexes avec la touche morte de mon clavier (qui
utilise le layout «Français, obsolete, variante»).

Le phénomène est visible par exemple dans un terminal, dans emacs
ou depuis claws-mail. J'ai tenté un


Pareil ici avec Sid.

...sans succès. Curieusement, dans la zone de saisie d'un
navigateur cette touche fonctionne, ainsi que dans le terminal
zutty. Si je me connecte Aussi, si je me connecte sur tty3 (après
Ctrl-Alt-F3), j'ai bien l'usage de cette touche. Je sèche...


Par contre je n'ai mème pas cela, c'est partout qu'il me manque les
accents. Merci au correcteur... Tout aussi sec.




--
Patrick ZAJDA

Re: perte de la touche morte du clavier pour saisir les accents circonflexes depuis une mise à jour système

2024-05-08 Par sujet Frédéric Baldit

oblème.
> Après downgrade de tous ces paquets vers la version 2.74.6-2 de 
> bookworm, je peux à nouveau utiliser la touche accent circonflexe.
> Il semble donc que cette mise à jour de sécurité entraîne une
> régression pour nos claviers.
> Pour information, j'utilise Mate comme environnement de bureau.
> 
> Patrick
> 
> 
> Le 08/05/2024 à 10:12, Txo a écrit :
> > Le 08/05/2024 à 05:42, Frédéric Baldit a écrit :
> >>
> >> Bonjour,
> >
> > Bonjour,
> >
> >>
> >> depuis la dernière mise à jour de mon système (Bookworm sous
> >> Gnome), je n'ai plus accès avec mon clavier à la saisie des
> >> accents circonflexes avec la touche morte de mon clavier (qui
> >> utilise le layout «Français, obsolete, variante»).
> >>
> >> Le phénomène est visible par exemple dans un terminal, dans emacs
> >> ou depuis claws-mail. J'ai tenté un
> >>
> >
> > Pareil ici avec Sid.
> >>
> >> ...sans succès. Curieusement, dans la zone de saisie d'un
> >> navigateur cette touche fonctionne, ainsi que dans le terminal
> >> zutty. Si je me connecte Aussi, si je me connecte sur tty3 (après
> >> Ctrl-Alt-F3), j'ai bien l'usage de cette touche. Je sèche...
> >>
> >
> > Par contre je n'ai mème pas cela, c'est partout qu'il me manque les 
> > accents. Merci au correcteur... Tout aussi sec.
> >
> >
>

Re: perte de la touche morte du clavier pour saisir les accents circonflexes depuis une mise à jour système

2024-05-08 Par sujet Gaëtan Perrier

Bonjour,

J'ai aussi ce problème sous sid/gnome.
Ca semble être ce bug :

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

A+

Gaëtan

Le mercredi 08 mai 2024 à 10:12 +0200, Txo a écrit :
> Le 08/05/2024 à 05:42, Frédéric Baldit a écrit :
> > 
> > Bonjour,
> 
> Bonjour,
> 
> > 
> > depuis la dernière mise à jour de mon système (Bookworm sous Gnome), je
> > n'ai plus accès avec mon clavier à la saisie des accents circonflexes
> > avec la touche morte de mon clavier (qui utilise le layout «Français,
> > obsolete, variante»).
> > 
> > Le phénomène est visible par exemple dans un terminal, dans emacs ou
> > depuis claws-mail. J'ai tenté un
> > 
> 
> Pareil ici avec Sid.
> > 
> > ...sans succès. Curieusement, dans la zone de saisie d'un navigateur
> > cette touche fonctionne, ainsi que dans le terminal zutty. Si je me
> > connecte Aussi, si je me connecte sur tty3 (après Ctrl-Alt-F3), j'ai
> > bien l'usage de cette touche. Je sèche...
> > 
> 
> Par contre je n'ai mème pas cela, c'est partout qu'il me manque les 
> accents. Merci au correcteur... Tout aussi sec.
> 
> 



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

Re: perte de la touche morte du clavier pour saisir les accents circonflexes depuis une mise à jour système


Bonjour,

JE suis sous Bookworm et il semble que ça soit la version 
2.74.6-2+deb12u1 de libglib2.0-0 (et autres paquets libglib) disponibles 
dans bookworm-security qui pose problème.
Après downgrade de tous ces paquets vers la version 2.74.6-2 de 
bookworm, je peux à nouveau utiliser la touche accent circonflexe.
Il semble donc que cette mise à jour de sécurité entraîne une régression 
pour nos claviers.

Pour information, j'utilise Mate comme environnement de bureau.

Patrick


Le 08/05/2024 à 10:12, Txo a écrit :

Le 08/05/2024 à 05:42, Frédéric Baldit a écrit :


Bonjour,


Bonjour,



depuis la dernière mise à jour de mon système (Bookworm sous Gnome), je
n'ai plus accès avec mon clavier à la saisie des accents circonflexes
avec la touche morte de mon clavier (qui utilise le layout «Français,
obsolete, variante»).

Le phénomène est visible par exemple dans un terminal, dans emacs ou
depuis claws-mail. J'ai tenté un



Pareil ici avec Sid.


...sans succès. Curieusement, dans la zone de saisie d'un navigateur
cette touche fonctionne, ainsi que dans le terminal zutty. Si je me
connecte Aussi, si je me connecte sur tty3 (après Ctrl-Alt-F3), j'ai
bien l'usage de cette touche. Je sèche...



Par contre je n'ai mème pas cela, c'est partout qu'il me manque les 
accents. Merci au correcteur... Tout aussi sec.





--
Patrick ZAJDA

Re : perte de la touche morte du clavier pour saisir les accents circonflexes depuis une mise à jour système

2024-05-08 Par sujet nicolas . patrois

On 08/05/2024 10:52:47, Michel Nakache wrote:

> Bonjour, je n'ai pas ce problème, je suis sous Bookworm avec Xfce, 
> peut-être un problème sous Gnome ?

Moi, c’est justement avec XFCE, mais dans Sid.
Pas avec Balsa, pas avec un terminal X, pas avec Python, pas avec Kate…

Pour information, voici ce que j’ai mis à jour ce matin :
# apt full-upgrade
Upgrading:  
  gimplibcdio-cdda2 libglib2.0-doc   
libtss2-tcti-spi-helper0t64
  gimp-data   libcdio-paranoia2 libtss2-esys-3.0.2-0t64  
libtss2-tcti-swtpm0t64
  gir1.2-glib-2.0 libgimp2.0t64 libtss2-mu-4.0.1-0t64
libtss2-tctildr0t64
  gir1.2-glib-2.0-dev libgirepository-2.0-0 libtss2-rc0t64   
mercurial
  gnome-shell libglib2.0-0t64   libtss2-sys1t64  
mercurial-common
  gnome-shell-common  libglib2.0-binlibtss2-tcti-cmd0t64 
xfsprogs
  gnome-shell-extension-prefs libglib2.0-data   libtss2-tcti-device0t64
  liballegro4.4t64libglib2.0-devlibtss2-tcti-libtpms0t64
  libass9 libglib2.0-dev-binlibtss2-tcti-mssim0t64

Installing dependencies:
  libunibreak6

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 : perte de la touche morte du clavier pour saisir les accents circonflexes depuis une mise à jour système

2024-05-08 Par sujet nicolas . patrois

On 08/05/2024 11:06:24, MERLIN Philippe wrote:

> Bonjour,
> Je réponds peut être complètement à coté de la plaque.
> Mais le problème indiqué ressemble à celui que j'ai eu avec les
> consoles ouvertes par Ctrl 
> +Alt +Fn le clavier se trouvant en Qwerty au lieu d'Azerty et que j'ai
> posté récemment sur la 
> liste avec la solution trouvée  et intitulé:
> " clavier console [Résolu Vraiment] "
> Existence du paquet *console-setup* dans votre système
> Amicalement.
> Philippe Merlin

Ce n’est pas le même problème puisque je ne l’ai que depuis ce matin dans 
Firefox, que j’ai redémarré après la mise à jour de ce matin.
Les autres applications ont les accents (en fait, les caractères dont le code 
est supérieur à 128).

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: perte de la touche morte du clavier pour saisir les accents circonflexes depuis une mise à jour système

2024-05-08 Par sujet Michel Nakache

Bonjour, je n'ai pas ce problème, je suis sous Bookworm avec Xfce, 
peut-être un problème sous Gnome ?


Le 08/05/2024 à 10:12, Txo a écrit :

Le 08/05/2024 à 05:42, Frédéric Baldit a écrit :


Bonjour,


Bonjour,



depuis la dernière mise à jour de mon système (Bookworm sous Gnome), je
n'ai plus accès avec mon clavier à la saisie des accents circonflexes
avec la touche morte de mon clavier (qui utilise le layout «Français,
obsolete, variante»).

Le phénomène est visible par exemple dans un terminal, dans emacs ou
depuis claws-mail. J'ai tenté un



Pareil ici avec Sid.


...sans succès. Curieusement, dans la zone de saisie d'un navigateur
cette touche fonctionne, ainsi que dans le terminal zutty. Si je me
connecte Aussi, si je me connecte sur tty3 (après Ctrl-Alt-F3), j'ai
bien l'usage de cette touche. Je sèche...



Par contre je n'ai mème pas cela, c'est partout qu'il me manque les 
accents. Merci au correcteur... Tout aussi sec.

Re: perte de la touche morte du clavier pour saisir les accents circonflexes depuis une mise à jour système

2024-05-08 Par sujet MERLIN Philippe

Bonjour,
Je réponds peut être complètement à coté de la plaque.
Mais le problème indiqué ressemble à celui que j'ai eu avec les consoles 
ouvertes par Ctrl 
+Alt +Fn le clavier se trouvant en Qwerty au lieu d'Azerty et que j'ai posté 
récemment sur la 
liste avec la solution trouvée  et intitulé:
" clavier console [Résolu Vraiment] "
Existence du paquet *console-setup* dans votre système
Amicalement.
Philippe Merlin


Le mercredi 8 mai 2024, 10:12:45 CEST Txo a écrit :
> Le 08/05/2024 à 05:42, Frédéric Baldit a écrit :
> > Bonjour,
> 
> Bonjour,
> 
> > depuis la dernière mise à jour de mon système (Bookworm sous Gnome), je
> > n'ai plus accès avec mon clavier à la saisie des accents circonflexes
> > avec la touche morte de mon clavier (qui utilise le layout «Français,
> > obsolete, variante»).
> > 
> > Le phénomène est visible par exemple dans un terminal, dans emacs ou
> > depuis claws-mail. J'ai tenté un
> 
> Pareil ici avec Sid.
> 
> > ...sans succès. Curieusement, dans la zone de saisie d'un navigateur
> > cette touche fonctionne, ainsi que dans le terminal zutty. Si je me
> > connecte Aussi, si je me connecte sur tty3 (après Ctrl-Alt-F3), j'ai
> > bien l'usage de cette touche. Je sèche...
> 
> Par contre je n'ai mème pas cela, c'est partout qu'il me manque les
> accents. Merci au correcteur... Tout aussi sec.

Re: perte de la touche morte du clavier pour saisir les accents circonflexes depuis une mise à jour système

2024-05-08 Par sujet Txo


Le 08/05/2024 à 05:42, Frédéric Baldit a écrit :


Bonjour,


Bonjour,



depuis la dernière mise à jour de mon système (Bookworm sous Gnome), je
n'ai plus accès avec mon clavier à la saisie des accents circonflexes
avec la touche morte de mon clavier (qui utilise le layout «Français,
obsolete, variante»).

Le phénomène est visible par exemple dans un terminal, dans emacs ou
depuis claws-mail. J'ai tenté un



Pareil ici avec Sid.


...sans succès. Curieusement, dans la zone de saisie d'un navigateur
cette touche fonctionne, ainsi que dans le terminal zutty. Si je me
connecte Aussi, si je me connecte sur tty3 (après Ctrl-Alt-F3), j'ai
bien l'usage de cette touche. Je sèche...



Par contre je n'ai mème pas cela, c'est partout qu'il me manque les 
accents. Merci au correcteur... Tout aussi sec.



--
-⚓- Dominique Marin http://txodom.free.fr  -⚓-
 «Aux raisons de l'amour que les fous te proposent
 Au rien qui te fait toi quand tu ne crois en rien»
-⚓-Léo Ferré Mister the wind   -⚓-

perte de la touche morte du clavier pour saisir les accents circonflexes depuis une mise à jour système

2024-05-07 Par sujet Frédéric Baldit



Bonjour,

depuis la dernière mise à jour de mon système (Bookworm sous Gnome), je
n'ai plus accès avec mon clavier à la saisie des accents circonflexes
avec la touche morte de mon clavier (qui utilise le layout «Français,
obsolete, variante»).

Le phénomène est visible par exemple dans un terminal, dans emacs ou
depuis claws-mail. J'ai tenté un

sudo dpkg-reconfigure keyboard-configuration

...sans succès. Curieusement, dans la zone de saisie d'un navigateur
cette touche fonctionne, ainsi que dans le terminal zutty. Si je me
connecte Aussi, si je me connecte sur tty3 (après Ctrl-Alt-F3), j'ai
bien l'usage de cette touche. Je sèche...

Merci d'avance pour toute aide.
Cordialement,

--
  Frédéric Baldit

Re: clavier console [Résolu Vraiment]

2024-05-01 Par sujet MERLIN Philippe

Bonjour,
Mon dernier message indiquait que le problème était résolu ce que je croyaiscar 
en fait 
après reboot les consoles générées par Ctrl Alt Fn avaient toujours le clavier 
en *Qwerty* 
et non *Azerty*.
En désespoir de cause j'étais prêt à créer un rapport de Bug concernant le 
paquet 
*keyboard-configuration * le logiciel générant les rapports de Bug indique tous 
le Bugs 
concernant ce paquet et aussi un autre paquet console-setup.
Après examen des paquets installés *console-setup* était absent les 
fonctionnalités de ce 
paquet sont de mettre en harmonie la configuration *X *et *TTY*.
installation du paquet *console-setup*
j'ai fait dpkg-reconfigure *console-setup* peut être non nécessaire.
Toujours que maintenant le problème est résolu vraiment.
Dois je faire un rapport de Bug concernant *keyboard-configuration *car pour 
moi 
l'installation de ces deux paquets devraient être liés impérativement.
Surtout que cette mésaventure est arrivée après une MAJ avant cette MAJ je 
n'avais jamais 
ce problème.

>
> > MERLIN Philippe  a écrit :
> > > Une question que je me pose pourquoi la commande dpkg-reconfigure
> > > keyboard- configuration...
> > > qui gère ce fichier /etc/vconsole.conf n'ajoute pascette ligne es ce
> > > normal ou c'est un bug ?
> > 
> > Sous Debian Sid, le fichier /etc/vconsole.conf est un lien symbolique
> > vers /etc/default/keyboard et ne devrait donc pas être édité
> > manuellement.
> > 
> > Le mieux serait de :
> > - Sauvegarder /etc/default/keyboard et /etc/vconsole.conf
> > - Supprimer /etc/vconsole.conf
> > - Créer un lien symbolique :
> > # ln -s /etc/default/keyboard /etc/vconsole.conf
> > - Reconfigurer le clavier :
> > # dpkg-reconfigure keyboard-configuration
> > - Appliquer les modifications sans redémarrer :
> > # udevadm trigger --subsystem-match=input --action=change
> 
> le lien existait déjà et quand j'ai modifié /etc/vconsole.conf cela a
> modifié /etc/default/keyboard .
> D'autre part je signalais que le dpkg-reconfigure n'a pas ajoutéau fichier
> la ligne KEYMAP=fr qui solutionne le problème du clavier AZERTY en mode
> console sans serveur X.

Re: clavier console [Résolu]

2024-04-21 Par sujet Pierre Tomon

Le Sun, 21 Apr 2024 07:45:58 +0200,
"jacques.briquet"  a écrit :

> Envoyé depuis mon appareil Galaxy. Merci de retirer m. Briquet de la
> liste ...
Pour se désabonner de la liste :
https://www.debian.org/MailingLists/unsubscribe

Ou envoyer un message à : 
debian-user-french-requ...@lists.debian.org
Avec le mot "unsubscribe" comme objet.

FW: Re: clavier console [Résolu]

2024-04-20 Par sujet jacques.briquet

Envoyé depuis mon appareil GalaxyMerci de retirer m. Briquet de la liste il esr 
décédé 
 Message d'origine De : Pierre Tomon  Date 
: 20/04/2024  19:21  (GMT+01:00) À : debian-user-french@lists.debian.org Objet 
: Re: clavier console [Résolu] Le Sat, 20 Apr 2024 18:21:46 +0200,MERLIN 
Philippe  a écrit :> le lien existait déjà et 
quand j'ai modifié /etc/vconsole.conf cela a> modifié /etc/default/keyboard 
.Ok, tu peux aussi modifier directement /etc/default/keyboard.> D'autre part je 
signalais que le dpkg-reconfigure n'a pas ajoutéau> fichier la ligne KEYMAP=fr 
qui solutionne le problème du clavier> AZERTY en mode console sans serveur X.Je 
ne connais pas l'option KEYMAP, cela cela n'apparaît pas dans lapage de manuel. 
Par contre il y a KMAP, qui permet de spécififier descartes de clavier (keymap) 
alternatives.

Re: clavier console [Résolu]

2024-04-20 Par sujet Pierre Tomon

Le Sat, 20 Apr 2024 18:21:46 +0200,
MERLIN Philippe  a écrit :

> le lien existait déjà et quand j'ai modifié /etc/vconsole.conf cela a
> modifié /etc/default/keyboard .
Ok, tu peux aussi modifier directement /etc/default/keyboard.

> D'autre part je signalais que le dpkg-reconfigure n'a pas ajoutéau
> fichier la ligne KEYMAP=fr qui solutionne le problème du clavier
> AZERTY en mode console sans serveur X.
Je ne connais pas l'option KEYMAP, cela cela n'apparaît pas dans la
page de manuel. Par contre il y a KMAP, qui permet de spécififier des
cartes de clavier (keymap) alternatives.

Re: clavier console [Résolu]

2024-04-20 Par sujet MERLIN Philippe

Le samedi 20 avril 2024, 17:41:36 CEST Pierre Tomon a écrit :
> Le Sat, 20 Apr 2024 14:09:30 +0200,
> 
> MERLIN Philippe  a écrit :
> > Une question que je me pose pourquoi la commande dpkg-reconfigure
> > keyboard- configuration...
> > qui gère ce fichier /etc/vconsole.conf n'ajoute pascette ligne es ce
> > normal ou c'est un bug ?
> 
> Sous Debian Sid, le fichier /etc/vconsole.conf est un lien symbolique
> vers /etc/default/keyboard et ne devrait donc pas être édité
> manuellement.
> 
> Le mieux serait de :
> - Sauvegarder /etc/default/keyboard et /etc/vconsole.conf
> - Supprimer /etc/vconsole.conf
> - Créer un lien symbolique :
>   # ln -s /etc/default/keyboard /etc/vconsole.conf
> - Reconfigurer le clavier :
>   # dpkg-reconfigure keyboard-configuration
> - Appliquer les modifications sans redémarrer :
>   # udevadm trigger --subsystem-match=input --action=change
le lien existait déjà et quand j'ai modifié /etc/vconsole.conf cela a modifié 
/etc/default/keyboard .
D'autre part je signalais que le dpkg-reconfigure n'a pas ajoutéau fichier la 
ligne KEYMAP=fr qui solutionne le problème du clavier AZERTY en mode console 
sans serveur X.

Re: clavier console [Résolu]

2024-04-20 Par sujet Pierre Tomon

Le Sat, 20 Apr 2024 14:09:30 +0200,
MERLIN Philippe  a écrit :

> Une question que je me pose pourquoi la commande dpkg-reconfigure
> keyboard- configuration...
> qui gère ce fichier /etc/vconsole.conf n'ajoute pascette ligne es ce
> normal ou c'est un bug ?

Sous Debian Sid, le fichier /etc/vconsole.conf est un lien symbolique
vers /etc/default/keyboard et ne devrait donc pas être édité
manuellement.

Le mieux serait de :
- Sauvegarder /etc/default/keyboard et /etc/vconsole.conf
- Supprimer /etc/vconsole.conf
- Créer un lien symbolique : 
  # ln -s /etc/default/keyboard /etc/vconsole.conf
- Reconfigurer le clavier :
  # dpkg-reconfigure keyboard-configuration
- Appliquer les modifications sans redémarrer :
  # udevadm trigger --subsystem-match=input --action=change

Re: clavier console [Résolu]

2024-04-20 Par sujet MERLIN Philippe

Le jeudi 18 avril 2024, 13:53:57 CEST Sébastien NOBILI a écrit :
> Bonjour,
> 
> Le 2024-04-18 12:34, MERLIN Philippe a écrit :
Merci Sébastien et Pierre
> 
> dpkg-reconfigure keyboard-configuration
Pour moi cette commande n'a rien résolu.
Après quelques essais je me suis rendu compte que le clavier émulé lorsqu'on 
ouvre une console par Ctrl ALT Fn n> 2 est QWERTY une fois la session ouverte 
en tenant compte de la disposition d'un clavier QWERTY la commande :
loadkeys fr
me rendait mon clavier AZERTY
Ce n'était pas satisfaisant car non pérenne en cherchant sur le net j'ai 
trouvé dans un archwiki la solution.
ajouter dans /etc/vconsole.conf la ligne KEYMAP=fr
Maintenant je peux dire c'est résolu.
Une question que je me pose pourquoi la commande dpkg-reconfigure keyboard-
configuration...
qui gère ce fichier /etc/vconsole.conf n'ajoute pascette ligne es ce normal ou 
c'est un bug ?
Amicalement.
Philippe Merlin

Re: clavier console

2024-04-18 Par sujet Michel MOUNIER




Le 18/04/2024 à 14:45, Erwann Le Bras a écrit :



Le 18/04/2024 à 13:53, Sébastien NOBILI a écrit :
P.S. autre surprise pour moi la session Kde ouverte se trouve en F2 
dans le

temps elle était en F7

Ça fait quelques versions que ça a changé.


Pas tant que ça, j'ai toujours l'environnement graphique (LXDE) sur 
"F7" en Debian Stable


Erwann


+1

--

Michel Mounier
N 44°55'37"   E 004°53'51"

"Arion IV"
N 44°02'23"   E 001°06'45"

arionavigue.legtux.org

Re: clavier console

2024-04-18 Par sujet Sébastien NOBILI


Le 2024-04-18 14:45, Erwann Le Bras a écrit :

Pas tant que ça, j'ai toujours l'environnement graphique (LXDE) sur
"F7" en Debian Stable


En stable aussi, et sur F2 :)

J'ai remarqué ça sur des nouvelles installations, mais je n'ai jamais
regardé si ça avait changé sur mon système que je mets à jour depuis
des générations… C'est peut-être là l'explication ?

Sébastien

Re: clavier console

2024-04-18 Par sujet Erwann Le Bras



Le 18/04/2024 à 13:53, Sébastien NOBILI a écrit :
P.S. autre surprise pour moi la session Kde ouverte se trouve en F2 
dans le

temps elle était en F7

Ça fait quelques versions que ça a changé.


Pas tant que ça, j'ai toujours l'environnement graphique (LXDE) sur "F7" 
en Debian Stable


Erwann

Re: clavier console

2024-04-18 Par sujet Sébastien NOBILI


Bonjour,

Le 2024-04-18 12:34, MERLIN Philippe a écrit :

Auriez vous une piste pour solutionner ce problème ?


Avec cette commande ?

dpkg-reconfigure keyboard-configuration

P.S. autre surprise pour moi la session Kde ouverte se trouve en F2 
dans le

temps elle était en F7


Ça fait quelques versions que ça a changé.

Sébastien

Re: clavier console

2024-04-18 Par sujet Pierre Tomon



Tu peux essayer de redémarrer le système d'entrée du noyau avec udev:
# udevadm trigger --subsystem-match=input --action=change
Pas besoin de redémarrer le système en principe.

clavier console

2024-04-18 Par sujet MERLIN Philippe

Bonjour,
Le contexte Sid AMD64 Kde. Depuis une mise à jour je rencontre un problème de 
clavier. Dans l'univers Kde et Konsole pas de problème le clavier Azerty est 
bien  reconnu et fonctionne parfaitement. Par contre si j'ouvre une console 
par CTRL Alt F3 mon clavier AZERTY  n'est certainement plus reconnu et 
impossibilité de lui fournir le mdp de root .
C'est très gênant , le clavier est certainement en Qwerty. 
J'ai beau cherché Google m'a été d'aucune aide ou bien je ne dois pas posé les 
bons termes dans ma recherche.
Auriez vous une piste pour solutionner ce problème ?
A l'avance Merci.
Philippe Merlin
P.S. autre surprise pour moi la session Kde ouverte se trouve en F2 dans le 
temps elle était en F7

Re: Coordonnées graphiques du focus clavier

2024-03-25 Par sujet Pierre ESTREm

Bonjour,

Le but serait de récupérer le texte d'une info-bulle d'une icone du bureau.
Pour ce faire j'aurais besoin de mener (moveTo) le pointeur de souris
jusque ce focus clavier et ensuite à bosser car je ne sais pas pour
l'heure lire cette info-bulle.

Il s'agit d'un script qui serait un daemon pour pallier au bug de Orca
de sorte de savoir sur quelle icone le focus clavier se trouve.

A propos de ce bug signalé par Kiril j'avoue ne pas savoir faire quoi de
ce fichier :

https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-desktop-icons-ng/+bug/2048390/+attachment/5736866/+files/add-accessibility-support.diff
Après son downoad un :
$ patch add-accessibility-support.diff
Je comprends qu'il faudrait le comparer, mais à quoi ?

pierre estrem

Le 25/03/2024 à 08:10, Basile Starynkevitch a écrit :

On 3/24/24 19:50, Pierre ESTREm wrote:

Bonjour,

Je ne parviens pas à trouver comment récupérer les coordonnées X et Y
où se situe le focus clavier dans un écran.

Ca doit se faire...

La question me parait bizarre. Dans mon souvenir des règles de codage
des applications graphiques, un tel comportement est explicitement
proscrit ou déconseillé. Quel est le cas d'usage? En plus le focus
clavier appartient à une fenêtre (zone rectangulaire de X11) pas à un
point. Et il peut être redirigé, et peut-être même dans des cas
pathologiques multiples.

Tout ce que je sais faire est de récupérer celles du pointeur souris
(avec les modules pyxhook ou pyautogui).

Une idée en Python ? Sinon en Bash, xprop etc

Je ne connais pas l'API en détails, mais en C et avec un serveur
d'affichage Xorg (pas Wayland) il faudrait se plonger dans les détails
de IM.
https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html
- comptez plusieurs jours de lecture (et ensuite quelques semaines de
codage).

Peut-être qu'il pourrait être utile de se limiter à un seul
gestionnaire de fenêtres (sans viser la généralité) par exemple
choisir entre https://www.fvwm.org/ et https://ice-wm.org/ et ensuite
en modifier le code pour que votre logiciel puisse interroger
directement ce gestionnaire de fenêtres.

Mais la question me surprend, et me parait contraire aux attendus des
utilisateurs et aux usages.

Librement

Re: Coordonnées graphiques du focus clavier

2024-03-25 Par sujet Basile Starynkevitch




On 3/24/24 19:50, Pierre ESTREm wrote:

Bonjour,

Je ne parviens pas à trouver comment récupérer les coordonnées X et Y 
où se situe le focus clavier dans un écran.

Ca doit se faire...


La question me parait bizarre. Dans mon souvenir des règles de codage 
des applications graphiques, un tel comportement est explicitement 
proscrit ou déconseillé. Quel est le cas d'usage? En plus le focus 
clavier appartient à une fenêtre (zone rectangulaire de X11) pas à un 
point. Et il peut être redirigé, et peut-être même dans des cas 
pathologiques multiples.




Tout ce que je sais faire est de récupérer celles du pointeur souris 
(avec les modules pyxhook ou pyautogui).


Une idée en Python ? Sinon en Bash, xprop etc



Je ne connais pas l'API en détails, mais en C et avec un serveur 
d'affichage Xorg (pas Wayland) il faudrait se plonger dans les détails 
de IM. 
https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html 
- comptez plusieurs jours de lecture (et ensuite quelques semaines de 
codage).



Peut-être qu'il pourrait être utile de se limiter à un seul gestionnaire 
de fenêtres (sans viser la généralité) par exemple choisir entre 
https://www.fvwm.org/ et https://ice-wm.org/ et ensuite en modifier le 
code pour que votre logiciel puisse interroger directement ce 
gestionnaire de fenêtres.



Mais la question me surprend, et me parait contraire aux attendus des 
utilisateurs et aux usages.


Librement

--
Basile Starynkevitch 
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Coordonnées graphiques du focus clavier

2024-03-24 Par sujet Pierre ESTREm


Bonjour,

Je ne parviens pas à trouver comment récupérer les coordonnées X et Y où 
se situe le focus clavier dans un écran.

Ca doit se faire...

Tout ce que je sais faire est de récupérer celles du pointeur souris 
(avec les modules pyxhook ou pyautogui).


Une idée en Python ? Sinon en Bash, xprop etc

Merci
pierre estrem

Re: perte clavier suite à retour de veille depuis bookworm-12.5

2024-02-17 Par sujet Étienne Mollier

Jacques, on 2024-02-16:
> Je viens de faire un rapport de bug, il porte le numéro 1064041.
> 
> Encore un grand merci pour tes conseils,

Super, merci d'avoir pris le temps rédiger le rapport, espérons
qu'il donne quelque chose incessamment sous peu.

Bon dimanche,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Re: perte clavier suite à retour de veille depuis bookworm-12.5

2024-02-16 Par sujet Jacques


Bonjour Étienne,

Le 15/02/2024 à 20:25, Étienne Mollier a écrit :

Le comportement ne me paraît pas plus normal, quoiqu'il soit un
peu différent.  Je pense que ça vaudrait toujours le coup de le
signaler aux développeurs noyau.  Par ailleurs, la mitigation
appliquée pourrait les intéresser :


Je viens de faire un rapport de bug, il porte le numéro 1064041.

Encore un grand merci pour tes conseils,

Jacques

Re: perte clavier suite à retour de veille depuis bookworm-12.5

2024-02-15 Par sujet Étienne Mollier

Bonjour Jacques,
> Le 14/02/2024 à 21:51, Étienne Mollier a écrit :
> > Bonjour Jacques,
> > > Depuis la mise à jour bookworm du week-end dernier (12.5) , le
> > > clavier de mon PC portable (dell latitude 3340) ne fonctionne
> > > plus après un retour de veille.
> > […]
> > > Est-ce que quelqu'un parmi vous est également confronté à ce
> > > problème et si oui a-t-il su contourner la difficulté
> > > (paramétrage du noyau au boot ou ...)? ou s'agit-il selon vous
> > > d'un bug du noyau 6.1.0-18-amd64 ?
> > 
> > Le symptôme ressemble furieusement à celui décrit dans une
> > rustine apparue dans Linux 6.1.74 pour éviter ce problème sur
> > Acer P459-G2-M [1].  Linux a vu des mises à jour du pilote input
> > en versions 6.1.70, 6.1.74 et 6.1.75.  On n'est pas à l'abri que
> > l'un de ces changements ait introduit ce bug.  J'aurais donc
> > tendance à penser que c'est un bug du noyau 6.1.0-18-amd64.
> > 
> > [1] : 
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y=626b0c0ab3a06d02e32700de026c0c3f828f8492
> 
> Merci Étienne pour ta réponse: je ne suis pas sur d'être tout à fait dans le
> même cas que ce que tu évoques:
> au retour de veille l'écran s'affiche correctement, le "touchpad" fonctionne
> , les "magic SysRq keys" fonctionnent (Fn+Impécran+b reboote la machine).
> Penses-tu qu'il soit utile de remonter un rapport de bug debian pour le
> paquet linux-image-6.1.0-18-amd64 ?

Le comportement ne me paraît pas plus normal, quoiqu'il soit un
peu différent.  Je pense que ça vaudrait toujours le coup de le
signaler aux développeurs noyau.  Par ailleurs, la mitigation
appliquée pourrait les intéresser :
> En parcourant internet j'ai finalement trouvé une rustine qui permet à mon
> ordinateur de fonctionner correctement après un retour de veille:
> - rajouter "atkbd.reset" à la ligne GRUB_CMDLINE_LINUX_DEFAULT du fichier
> /etc/default/grub
> - lancer la commande: update-grub

> Bonne journée

Bonne soirée,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-


signature.asc
Description: PGP signature

Re: perte clavier suite à retour de veille depuis bookworm-12.5

2024-02-14 Par sujet Jacques


Bonjour à tous ,

Le 14/02/2024 à 21:51, Étienne Mollier a écrit :

Bonjour Jacques,

Depuis la mise à jour bookworm du week-end dernier (12.5) , le
clavier de mon PC portable (dell latitude 3340) ne fonctionne
plus après un retour de veille.

[…]

Est-ce que quelqu'un parmi vous est également confronté à ce
problème et si oui a-t-il su contourner la difficulté
(paramétrage du noyau au boot ou ...)? ou s'agit-il selon vous
d'un bug du noyau 6.1.0-18-amd64 ?


Le symptôme ressemble furieusement à celui décrit dans une
rustine apparue dans Linux 6.1.74 pour éviter ce problème sur
Acer P459-G2-M [1].  Linux a vu des mises à jour du pilote input
en versions 6.1.70, 6.1.74 et 6.1.75.  On n'est pas à l'abri que
l'un de ces changements ait introduit ce bug.  J'aurais donc
tendance à penser que c'est un bug du noyau 6.1.0-18-amd64.

[1] : 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y=626b0c0ab3a06d02e32700de026c0c3f828f8492


Merci Étienne pour ta réponse: je ne suis pas sur d'être tout à fait 
dans le même cas que ce que tu évoques:
au retour de veille l'écran s'affiche correctement, le "touchpad" 
fonctionne , les "magic SysRq keys" fonctionnent (Fn+Impécran+b reboote 
la machine).
Penses-tu qu'il soit utile de remonter un rapport de bug debian pour le 
paquet linux-image-6.1.0-18-amd64 ?


En parcourant internet j'ai finalement trouvé une rustine qui permet à 
mon ordinateur de fonctionner correctement après un retour de veille:
- rajouter "atkbd.reset" à la ligne GRUB_CMDLINE_LINUX_DEFAULT du 
fichier /etc/default/grub

- lancer la commande: update-grub

Bonne journée

Re: perte clavier suite à retour de veille depuis bookworm-12.5

2024-02-14 Par sujet Étienne Mollier

Bonjour Jacques,
> Depuis la mise à jour bookworm du week-end dernier (12.5) , le
> clavier de mon PC portable (dell latitude 3340) ne fonctionne
> plus après un retour de veille.
[…]
> Est-ce que quelqu'un parmi vous est également confronté à ce
> problème et si oui a-t-il su contourner la difficulté
> (paramétrage du noyau au boot ou ...)? ou s'agit-il selon vous
> d'un bug du noyau 6.1.0-18-amd64 ?

Le symptôme ressemble furieusement à celui décrit dans une
rustine apparue dans Linux 6.1.74 pour éviter ce problème sur
Acer P459-G2-M [1].  Linux a vu des mises à jour du pilote input
en versions 6.1.70, 6.1.74 et 6.1.75.  On n'est pas à l'abri que
l'un de ces changements ait introduit ce bug.  J'aurais donc
tendance à penser que c'est un bug du noyau 6.1.0-18-amd64.

[1] : 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y=626b0c0ab3a06d02e32700de026c0c3f828f8492

Si ça peut aider,
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/5, please excuse my verbosity
   `-on air: Spock's Beard - 4th Of July


signature.asc
Description: PGP signature

perte clavier suite à retour de veille depuis bookworm-12.5

2024-02-14 Par sujet Jacques


Bonjour à tous,

Depuis la mise à jour bookworm du week-end dernier (12.5) , le clavier 
de mon PC portable (dell latitude 3340) ne fonctionne plus après un 
retour de veille. Je suis actuellement contraint de rebooter pour en 
retrouver l'usage :-(


Cette erreur est systématique avec le noyau linux-image-6.1.0-18-amd64. 
Par contre si je boote sur un noyau linux-image-6.1.0-17-amd64 , je ne 
constate pas ce problème.


Est-ce que quelqu'un parmi vous est également confronté à ce problème et 
si oui a-t-il su contourner la difficulté (paramétrage du noyau au boot 
ou ... )? ou s'agit-il selon vous d'un bug du noyau 6.1.0-18-amd64 ?


Merci pour vos réponses et bonne journée

Re: Re : Re : Re: Clavier/souris Cherry DM 9100 bluetooth

2023-08-18 Par sujet David BERCOT


Bonjour à tous,

Pour information, j'ai réussi à connecter mon clavier et ma souris par 
une procédure un peu particulière que je vous synthétise ci-dessous.


En effet, via Gnome, impossible de voir ces périphériques.

En root, j'ai donc lancé bluetoothctl et, dans son invite de commande, 
j'ai vu "miraculeusement" arriver ma souris et mon clavier (via leurs 
adresse MAC).

Et là, j'ai pu les appairer correctement.

Au cas où ça pourrait servir à quelqu'un (même si ça ne me donne pas 
l'explication totale).


Bonne soirée et bon week-end.

David.

Le 17/08/2023 à 20:48, David BERCOT a écrit :

Qu'est-ce que tu veux dire par là ? As-tu une liste "exhaustive" ?
Après, c'est quand même surprenant que tous les périphériques 
bluetooth (des TV, des téléphones, ma souris précédente, etc.) soient 
reconnus, à l'exception de mon nouveau clavier et ma nouvelle souris...


David.

Le 17/08/2023 à 16:41, michel.debian a écrit :

Une question bête, tout les paquets concernant le BT sont installés?

Le 17/08/2023 à 14:36, David BERCOT a écrit :
Je me suis posé la question mais je ne vois pas comment "facilement" 
trouver ce qui est différent.
Ce n'est pas le bluetooth qui ne marche pas mais juste la découverte 
de ma nouvelle souris (et clavier).


Côté noyau, en SID, je suis au plus récent...

Bref, ça ne me paraît pas simple.

David.

Le 17/08/2023 à 13:09, nicolas.patr...@gmail.com a écrit :

On 17/08/2023 11:49:42, David BERCOT wrote:


C'est confirmé : ça fonctionne aussi avec un Debian live.
Ça vient donc de mon installation et je vais devoir repartir de
zéro...
Avant de réinstaller, regarde ce qui est installé dans la version 
Live, regarde la liste des paquets, le noyau, les modules, etc.


nicolas patrois : pts noir asocial

Re: Re : Re : Re: Clavier/souris Cherry DM 9100 bluetooth


Qu'est-ce que tu veux dire par là ? As-tu une liste "exhaustive" ?
Après, c'est quand même surprenant que tous les périphériques bluetooth 
(des TV, des téléphones, ma souris précédente, etc.) soient reconnus, à 
l'exception de mon nouveau clavier et ma nouvelle souris...


David.

Le 17/08/2023 à 16:41, michel.debian a écrit :

Une question bête, tout les paquets concernant le BT sont installés?

Le 17/08/2023 à 14:36, David BERCOT a écrit :
Je me suis posé la question mais je ne vois pas comment "facilement" 
trouver ce qui est différent.
Ce n'est pas le bluetooth qui ne marche pas mais juste la découverte 
de ma nouvelle souris (et clavier).


Côté noyau, en SID, je suis au plus récent...

Bref, ça ne me paraît pas simple.

David.

Le 17/08/2023 à 13:09, nicolas.patr...@gmail.com a écrit :

On 17/08/2023 11:49:42, David BERCOT wrote:


C'est confirmé : ça fonctionne aussi avec un Debian live.
Ça vient donc de mon installation et je vais devoir repartir de
zéro...
Avant de réinstaller, regarde ce qui est installé dans la version 
Live, regarde la liste des paquets, le noyau, les modules, etc.


nicolas patrois : pts noir asocial

Re: Re : Re : Re: Clavier/souris Cherry DM 9100 bluetooth

2023-08-17 Par sujet michel.debian


Une question bête, tout les paquets concernant le BT sont installés?

Le 17/08/2023 à 14:36, David BERCOT a écrit :
Je me suis posé la question mais je ne vois pas comment "facilement" 
trouver ce qui est différent.
Ce n'est pas le bluetooth qui ne marche pas mais juste la découverte 
de ma nouvelle souris (et clavier).


Côté noyau, en SID, je suis au plus récent...

Bref, ça ne me paraît pas simple.

David.

Le 17/08/2023 à 13:09, nicolas.patr...@gmail.com a écrit :

On 17/08/2023 11:49:42, David BERCOT wrote:


C'est confirmé : ça fonctionne aussi avec un Debian live.
Ça vient donc de mon installation et je vais devoir repartir de
zéro...

Avant de réinstaller, regarde ce qui est installé dans la version Live, regarde 
la liste des paquets, le noyau, les modules, etc.

nicolas patrois : pts noir asocial

Re : Re : Re : Re: Clavier/souris Cherry DM 9100 bluetooth

2023-08-17 Par sujet nicolas . patrois

On 17/08/2023 14:36:15, David BERCOT wrote:

> Je me suis posé la question mais je ne vois pas comment "facilement" 
> trouver ce qui est différent.
> Ce n'est pas le bluetooth qui ne marche pas mais juste la découverte
> de ma nouvelle souris (et clavier).

> Côté noyau, en SID, je suis au plus récent...

Regarde les journaux (sudo journalctl -f) de l’un et de l’autre quand tu 
branches et débranches le clavier.

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 : Re : Re: Clavier/souris Cherry DM 9100 bluetooth

Je me suis posé la question mais je ne vois pas comment "facilement" 
trouver ce qui est différent.
Ce n'est pas le bluetooth qui ne marche pas mais juste la découverte de 
ma nouvelle souris (et clavier).


Côté noyau, en SID, je suis au plus récent...

Bref, ça ne me paraît pas simple.

David.

Le 17/08/2023 à 13:09, nicolas.patr...@gmail.com a écrit :

On 17/08/2023 11:49:42, David BERCOT wrote:


C'est confirmé : ça fonctionne aussi avec un Debian live.
Ça vient donc de mon installation et je vais devoir repartir de
zéro...

Avant de réinstaller, regarde ce qui est installé dans la version Live, regarde 
la liste des paquets, le noyau, les modules, etc.

nicolas patrois : pts noir asocial

Re : Re : Re: Clavier/souris Cherry DM 9100 bluetooth

2023-08-17 Par sujet nicolas . patrois

On 17/08/2023 11:49:42, David BERCOT wrote:

> C'est confirmé : ça fonctionne aussi avec un Debian live.
> Ça vient donc de mon installation et je vais devoir repartir de
> zéro...

Avant de réinstaller, regarde ce qui est installé dans la version Live, regarde 
la liste des paquets, le noyau, les modules, etc.

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 : Re: Clavier/souris Cherry DM 9100 bluetooth


C'est confirmé : ça fonctionne aussi avec un Debian live.
Ca vient donc de mon installation et je vais devoir repartir de zéro...

Merci pour les pistes.

David.

Le 17/08/2023 à 10:48, David BERCOT a écrit :

Bonjour Didier,

C'est exactement ce que j'allais faire...
Je suis en train de créer ma clé Debian live.

A suivre donc...

David.

Le 17/08/2023 à 10:42, didier gaumet a écrit :

Le 16/08/2023 à 20:50, David BERCOT a écrit :
[...]

Aujourd'hui, j'ai testé avec une clé live "Ubuntu" et... aucun souci...
Ceci élimine donc un problème côté ordinateur portable mais aussi 
sur la souris elle-même.


Mais maintenant, pourquoi est-ce qu'elle fonctionne nativement sur 
Ubuntu et que, sur Debian, tous mes autres périphériques bluetooth 
marchent, sauf ceux-ci ?


Là, j'arrive au bout des différents tests que je peux imaginer.

Si vous avez une autre option, je suis preneur .

[...]

Tu peux éventuellement tester avec une clé live Debian:
https://www.debian.org/CD/live/
- si ça marche ça signifie que c'est ton installation Debian qui est 
en cause
- si ça ne marche pas ça signifie qu'il y a peut-être une 
configuration à effectuer qui est faite par défaut sur Ubuntu mais 
pas Debian, ou que le noyau est plus récenbt sur Ubuntu que sur 
Debian, ou...

Re: Re : Re: Clavier/souris Cherry DM 9100 bluetooth


Bonjour Didier,

C'est exactement ce que j'allais faire...
Je suis en train de créer ma clé Debian live.

A suivre donc...

David.

Le 17/08/2023 à 10:42, didier gaumet a écrit :

Le 16/08/2023 à 20:50, David BERCOT a écrit :
[...]

Aujourd'hui, j'ai testé avec une clé live "Ubuntu" et... aucun souci...
Ceci élimine donc un problème côté ordinateur portable mais aussi sur 
la souris elle-même.


Mais maintenant, pourquoi est-ce qu'elle fonctionne nativement sur 
Ubuntu et que, sur Debian, tous mes autres périphériques bluetooth 
marchent, sauf ceux-ci ?


Là, j'arrive au bout des différents tests que je peux imaginer.

Si vous avez une autre option, je suis preneur .

[...]

Tu peux éventuellement tester avec une clé live Debian:
https://www.debian.org/CD/live/
- si ça marche ça signifie que c'est ton installation Debian qui est 
en cause
- si ça ne marche pas ça signifie qu'il y a peut-être une 
configuration à effectuer qui est faite par défaut sur Ubuntu mais pas 
Debian, ou que le noyau est plus récenbt sur Ubuntu que sur Debian, ou...

Re: Re : Re: Clavier/souris Cherry DM 9100 bluetooth

2023-08-17 Par sujet didier gaumet


Le 16/08/2023 à 20:50, David BERCOT a écrit :
[...]

Aujourd'hui, j'ai testé avec une clé live "Ubuntu" et... aucun souci...
Ceci élimine donc un problème côté ordinateur portable mais aussi sur la 
souris elle-même.


Mais maintenant, pourquoi est-ce qu'elle fonctionne nativement sur 
Ubuntu et que, sur Debian, tous mes autres périphériques bluetooth 
marchent, sauf ceux-ci ?


Là, j'arrive au bout des différents tests que je peux imaginer.

Si vous avez une autre option, je suis preneur .

[...]

Tu peux éventuellement tester avec une clé live Debian:
https://www.debian.org/CD/live/
- si ça marche ça signifie que c'est ton installation Debian qui est en 
cause
- si ça ne marche pas ça signifie qu'il y a peut-être une configuration 
à effectuer qui est faite par défaut sur Ubuntu mais pas Debian, ou que 
le noyau est plus récenbt sur Ubuntu que sur Debian, ou...

Re: Re : Re: Clavier/souris Cherry DM 9100 bluetooth

2023-08-16 Par sujet David BERCOT


Bonjour,

En complément du message ci-dessous, j'ai également eu des éléments 
complémentaires en privé.


Globalement, l'interrogation était de savoir si le problème venait de 
l'ordinateur (du "récepteur" bluetooth), de Debian ou d'un problème avec 
le clavier et/ou la souris.


Aujourd'hui, j'ai testé avec une clé live "Ubuntu" et... aucun souci...
Ceci élimine donc un problème côté ordinateur portable mais aussi sur la 
souris elle-même.


Mais maintenant, pourquoi est-ce qu'elle fonctionne nativement sur 
Ubuntu et que, sur Debian, tous mes autres périphériques bluetooth 
marchent, sauf ceux-ci ?


Là, j'arrive au bout des différents tests que je peux imaginer.

Si vous avez une autre option, je suis preneur .

Merci.

David.

Le 16/08/2023 à 02:15, k6dedi...@free.fr a écrit :

Bonjour,
À tout hasard, le bluetooth est émis par le PC ou la Box ?
Je pense que le PC doit avoir son émetteur/récepteur.

Bonne continuation.
Cassis



- Mail d'origine -
De: David BERCOT
À:debian-user-french@lists.debian.org
Envoyé: Tue, 15 Aug 2023 12:18:56 +0200 (CEST)
Objet: Re: Clavier/souris Cherry DM 9100 bluetooth

Merci à Didier pour la suggestion mais j'ai déjà suivi les tutos
plusieurs fois sans succès.

Quant à ta question sur le groupe, oui, c'est le cas, et d'ailleurs je
n'avais pas de souci avec ma souris bluetooth précédente.

Là, c'est comme si mon ordinateur (est-ce lié à l'adaptateur matériel ou
à Debian ?) ne "voyait" pas uniquement ce clavier et cette souris...

Le 15/08/2023 à 11:55, Frédéric MASSOT a écrit :

Le 15/08/2023 à 08:28, David BERCOT a écrit :

Bonjour,

Je viens de changer mon clavier et ma souris pour des versions sans
fil Cherry DM 9100 slim.
Cet ensemble peut fonctionner en bluetooth ou en radio (dans ce
dernier cas, avec un petit dongle USB).
Via le dongle, il fonctionne parfaitement.
En revanche, en bluetooth, impossible, non pas de les appairer, mais
même de les découvrir !

J'ai vérifié avec 2 téléphones et là, aucun souci pour les voir et
les connecter.
Cet ensemble est pourtant sensé être compatible Linux.

Auriez-vous une idée pour déterminer la raison de ce problème, voire
le corriger ?

Tu fais bien partie du groupe "bluetooth" ?

Re : Re: Clavier/souris Cherry DM 9100 bluetooth

2023-08-15 Par sujet k6dedijon

Bonjour,
À tout hasard, le bluetooth est émis par le PC ou la Box ?
Je pense que le PC doit avoir son émetteur/récepteur.

Bonne continuation.
Cassis



- Mail d'origine -
De: David BERCOT 
À: debian-user-french@lists.debian.org
Envoyé: Tue, 15 Aug 2023 12:18:56 +0200 (CEST)
Objet: Re: Clavier/souris Cherry DM 9100 bluetooth

Merci à Didier pour la suggestion mais j'ai déjà suivi les tutos 
plusieurs fois sans succès.

Quant à ta question sur le groupe, oui, c'est le cas, et d'ailleurs je 
n'avais pas de souci avec ma souris bluetooth précédente.

Là, c'est comme si mon ordinateur (est-ce lié à l'adaptateur matériel ou 
à Debian ?) ne "voyait" pas uniquement ce clavier et cette souris...

Le 15/08/2023 à 11:55, Frédéric MASSOT a écrit :
> Le 15/08/2023 à 08:28, David BERCOT a écrit :
>> Bonjour,
>>
>> Je viens de changer mon clavier et ma souris pour des versions sans 
>> fil Cherry DM 9100 slim.
>> Cet ensemble peut fonctionner en bluetooth ou en radio (dans ce 
>> dernier cas, avec un petit dongle USB).
>> Via le dongle, il fonctionne parfaitement.
>> En revanche, en bluetooth, impossible, non pas de les appairer, mais 
>> même de les découvrir !
>>
>> J'ai vérifié avec 2 téléphones et là, aucun souci pour les voir et 
>> les connecter.
>> Cet ensemble est pourtant sensé être compatible Linux.
>>
>> Auriez-vous une idée pour déterminer la raison de ce problème, voire 
>> le corriger ?
>
> Tu fais bien partie du groupe "bluetooth" ?

Re: Clavier/souris Cherry DM 9100 bluetooth

2023-08-15 Par sujet David BERCOT

Merci à Didier pour la suggestion mais j'ai déjà suivi les tutos 
plusieurs fois sans succès.


Quant à ta question sur le groupe, oui, c'est le cas, et d'ailleurs je 
n'avais pas de souci avec ma souris bluetooth précédente.


Là, c'est comme si mon ordinateur (est-ce lié à l'adaptateur matériel ou 
à Debian ?) ne "voyait" pas uniquement ce clavier et cette souris...


Le 15/08/2023 à 11:55, Frédéric MASSOT a écrit :

Le 15/08/2023 à 08:28, David BERCOT a écrit :

Bonjour,

Je viens de changer mon clavier et ma souris pour des versions sans 
fil Cherry DM 9100 slim.
Cet ensemble peut fonctionner en bluetooth ou en radio (dans ce 
dernier cas, avec un petit dongle USB).

Via le dongle, il fonctionne parfaitement.
En revanche, en bluetooth, impossible, non pas de les appairer, mais 
même de les découvrir !


J'ai vérifié avec 2 téléphones et là, aucun souci pour les voir et 
les connecter.

Cet ensemble est pourtant sensé être compatible Linux.

Auriez-vous une idée pour déterminer la raison de ce problème, voire 
le corriger ?


Tu fais bien partie du groupe "bluetooth" ?

Re: Clavier/souris Cherry DM 9100 bluetooth

2023-08-15 Par sujet Frédéric MASSOT


Le 15/08/2023 à 08:28, David BERCOT a écrit :

Bonjour,

Je viens de changer mon clavier et ma souris pour des versions sans fil 
Cherry DM 9100 slim.
Cet ensemble peut fonctionner en bluetooth ou en radio (dans ce dernier 
cas, avec un petit dongle USB).

Via le dongle, il fonctionne parfaitement.
En revanche, en bluetooth, impossible, non pas de les appairer, mais 
même de les découvrir !


J'ai vérifié avec 2 téléphones et là, aucun souci pour les voir et les 
connecter.

Cet ensemble est pourtant sensé être compatible Linux.

Auriez-vous une idée pour déterminer la raison de ce problème, voire le 
corriger ?


Tu fais bien partie du groupe "bluetooth" ?


--
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Clavier/souris Cherry DM 9100 bluetooth

2023-08-15 Par sujet didier gaumet




Bonjour,

je ne me suis jamais servi du Bluetooth donc je ne vais t'être d'aucune 
aide, mais tu peux regarder le wiki de Debian

https://wiki.debian.org/BluetoothUser
et si ça ne te fait pas avancer plus, consulter aussi celui d'Archlinux:
https://wiki.archlinux.org/title/Bluetooth_keyboard
https://wiki.archlinux.org/title/Bluetooth_mouse
https://wiki.archlinux.org/title/Bluetooth

Clavier/souris Cherry DM 9100 bluetooth

2023-08-15 Par sujet David BERCOT


Bonjour,

Je viens de changer mon clavier et ma souris pour des versions sans fil 
Cherry DM 9100 slim.
Cet ensemble peut fonctionner en bluetooth ou en radio (dans ce dernier 
cas, avec un petit dongle USB).

Via le dongle, il fonctionne parfaitement.
En revanche, en bluetooth, impossible, non pas de les appairer, mais 
même de les découvrir !


J'ai vérifié avec 2 téléphones et là, aucun souci pour les voir et les 
connecter.

Cet ensemble est pourtant sensé être compatible Linux.

Auriez-vous une idée pour déterminer la raison de ce problème, voire le 
corriger ?


Merci d'avance.

David.

Re: Accès distant graphique performant, sécurisé, écran-clavier-souris

2023-07-16 Par sujet ajh-valmer

On Sunday 16 July 2023 11:27:44 didier gaumet wrote:
> mon but était de souligner les limitations de XDMCP pour du X11 déporté, 
> et je note que LTSP (les clients légers) n'utilise plus XDMCP mais ssh -X:
> 
https://fr.wikipedia.org/wiki/Linux_Terminal_Server_Project#Le_processus_de_d%C3%A9marrage_d'un_client_LTSP

Je répète, désolé,
XDMCP est une ouverture de session sur un ordinateur distant,
à déconseiller en mode internet, uniquement en intranet.
Car ce protocole fait tout transiter en clair sur le réseau, y compris les 
mots de passe !
SSH peut sans doute aider à sécuriser la connexion si elle est internet.
On se retrouve face au système distant en mode X graphique comme 
devant son ordinateur chez soi sur le compte d'un .

Une fois xdmcp configuré, il suffit de taper en mode console :
X -query 
pour déclencher le login graphique du client.

Voici 2 liens explicatifs et du mode opératoire :
https://linux.developpez.com/formation_debian/export-display.html
https://doc.ubuntu-fr.org/tutoriel/comment_creer_un_terminal_x_ou_recycler_une_vieille_machine

Ne pas confondre ces 2 relations :
1) - Clients/Serveur,
et
2) Terminaux/Serveur.

1) c'est ssh, sftp, http(s)...
2) c'est xdmcp...

Pour moi, le sujet est clos.

Bon dimanche.

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

2023-07-16 Par sujet NoSpam

Après Solarwinds il y en a eu pléthore, 3CX par ex. Rappel: teamviewer a
aussi déjà eu ses problèmes. La solution: retire ton câble réseau qui va
à la box ;)

Tu as parlé de VNC ou RDP, c'est bien plus dangereux d'ouvrir ces ports
que d'utiliser une solution tel Meshagent. De plus, tu peux sécuriser en
limitant l'accès sur IP dans les FW, par utilisateur. Et comme déjà
écrit, l'agent sur le client n'est pas forcé de tourner tout le temps.

Pour terminer, monter un VPN et faire passer l'agent par celui ci est
une autre solution, ou même utiliser ce VPN pour démarrer l'agent du
client. Il y a des solutions de sécurisation, à toi de voir si tu veux
les mettre en place ou non.

Le 15/07/2023 à 21:08, roger.tar...@free.fr a écrit :

*De: *"NoSpam"
*À: *"Liste Debian"
*Envoyé: *Samedi 15 Juillet 2023 16:23:53
*Objet: *Re: Accès distant graphique performant et sécurisé /avec
écran-clavier-souris

Le 15/07/2023 à 15:18, RogerT a écrit :

Alors, pourquoi ne pas regarder aussi vers Teleport, que j’ai
aperçu récemment ?
https://goteleport.com/

Pourquoi chercher ailleurs alors que l'on a tout ce qui convient ? ;)
Il existe plein de solutions, j'ai trouvé la mienne après avoir
utiliser Teamviewer/Anydesk/Logmein et tant d'autres

Je decouvre l'existence de MeshCentral à peu près en même temps que
celle de Teleport.

Ça semble équivalent.
Ton expérience de MeshCentral est encourageante. Puisque ça a l'air de
rendre le service attendu sans souci.

Pour Teleport, je n'ai aucun retour d'expérience...

Dans les deux cas, il reste encore à vérifier la sécurité apportée
par ces engins qui ouvrent toutes les portes de l’infrastructure…

Aucune porte n'est ouverte puisqu'il s'agit d'un client serveur tout
comme les logiciels précités ci dessus.

https://www.solarwinds.com/orion-platform
https://www.zdnet.fr/actualites/microsoft-et-fireeye-confirment-la-cyberattaque-de-solarwinds-39914821.htm

Comment peut-on savoir ce que fait exactement l'agent
MeshCentral/MeshAgent installé, ou tout agent qu'on installe comme
avec Teamviewer, etc. ?
Ça me fait penser à SELinux (qui fonctionne bien pour ceux qui le
maîtrise parfaitement... je n'en ai aucune pratique), qui pourrait
peut-être mettre des "verrous unitaires" dans le système. Est-ce qu'un
"monstre" comme SELinux apporterait quelque chose pour sécuriser un
système "percé" par l'implantation d'un agent ?

Re: Accès distant graphique performant, sécurisé, écran-clavier-souris

2023-07-16 Par sujet didier gaumet


Le 16/07/2023 à 08:25, Basile Starynkevitch a écrit :


On 7/15/23 20:09, didier gaumet wrote:

>
Rappel: je suis un quasi-demeuré en réseaux et sécurité donc prendre 
ce qui suit avec réserve


Mais j'ai l'impression que tu rends la situation plus confuse à Roger 
au lieu de l'éclairer


En gros XDMCP est un protocole de login X11 à distance:
- qui nécessite donc un serveur X11 qui tourne sur la machine 
distante, et un gestionnaire d'affichage (DM, Display Manager) 
compatible XDMCP, et que le protocole XDMCP soit autorisé (récemment 
ce n'est plus le cas par défaut)



Un serveur X11 gère une carte graphique, un clavier, une souris. Il 
ccommunique avec des applications clientes selon un protocole assez 
compliqué, mais dont les principes sont expliqués par exemple en 
https://linuxiac.com/xorg-x11-wayland-linux-display-servers-and-protocols-explained/ ou https://fr.wikipedia.org/wiki/X.Org (dans le détail, le protocole X11 se décrit en des centaines de pages).


Conséquemment un serveur X11 tourne sur la machine locale, pas distante. 
Il existe des serveurs X11 pour Linux, OpenBSD, Windows, MacOSX.


Tu as absolument raison: je fais à chaque fois l'erreur de ne pas me 
rappeler que la relation client-serveur est inversée pour X11


Donc merci à toi Basile d'avoir corrigé, c'est important de ne pas 
laisser dire de grosses conn... sans rectifier :-)


[...]
Prenons l'exemple d'un supercalculateur (les machines à plusieurs 
millions d'€), par exemple à meteofrance. Ceux-ci tournent tous sous 
Linux. Mais on n'accède pas à la salle (très bruyante) les contenant. On 
peut avoir un processus de calcul sur un supercalculateur qui utilise 
une bibliothèque cliente X11 (par exemple GTK) pour afficher des 
résultats (des courbes) sur un PC local (qui a un serveur X11) sous 
Windows ou Linux.


mon but était de souligner les limitations de XDMCP pour du X11 déporté, 
et je note que LTSP (les clients légers) n'utilise plus XDMCP mais ssh -X:

https://fr.wikipedia.org/wiki/Linux_Terminal_Server_Project#Le_processus_de_d%C3%A9marrage_d'un_client_LTSP

Re: Accès distant graphique performant, sécurisé, écran-clavier-souris

2023-07-16 Par sujet Basile Starynkevitch




On 7/15/23 20:09, didier gaumet wrote:

Le 15/07/2023 à 18:55, ajh-valmer a écrit :

On Saturday 15 July 2023 18:10:17 RogerT wrote:

Il faut juste TDE sur le serveur. Mais pas forcément sur le client,
puisque ce peut être Mac/Win.
C’est ça ?


Serveur : Linux + TDE + XDMCP.
(on peut avoir un autre système + autre bureau (p. ex. XFCE...),
il faut alors trouver l'outil de configuration).

Client : de préférence TDE ou autres systèmes + bureaux,
Windows = RDP, Mac/Win = pas fait essai.

Il faut faire l'effort de se documenter, taper dans moteur de 
recherche :

XDMCP, RDP, Terminal/Serveur ...


Rappel: je suis un quasi-demeuré en réseaux et sécurité donc prendre 
ce qui suit avec réserve


Mais j'ai l'impression que tu rends la situation plus confuse à Roger 
au lieu de l'éclairer


En gros XDMCP est un protocole de login X11 à distance:
- qui nécessite donc un serveur X11 qui tourne sur la machine 
distante, et un gestionnaire d'affichage (DM, Display Manager) 
compatible XDMCP, et que le protocole XDMCP soit autorisé (récemment 
ce n'est plus le cas par défaut)



Un serveur X11 gère une carte graphique, un clavier, une souris. Il 
ccommunique avec des applications clientes selon un protocole assez 
compliqué, mais dont les principes sont expliqués par exemple en 
https://linuxiac.com/xorg-x11-wayland-linux-display-servers-and-protocols-explained/ 
ou https://fr.wikipedia.org/wiki/X.Org (dans le détail, le protocole X11 
se décrit en des centaines de pages).


Conséquemment un serveur X11 tourne sur la machine locale, pas distante. 
Il existe des serveurs X11 pour Linux, OpenBSD, Windows, MacOSX.


Chaque mouvement de souris correspond à un message binaire envoyé du 
serveur X11 (tournant sur la machine locale) vers une (ou des) 
applications clientes.


Bien sûr, une application cliente X11 (par exemple 
https://gnu.emacs.org/ ) peut tourner sur une machine distante (à 
dix mètres et parfois à dix mille kilomètres).


Les bibliothèques graphiques telles que https://gtk.org/ ou 
https://qt.io/ gère ces protocoles X11



Prenons l'exemple d'un supercalculateur (les machines à plusieurs 
millions d'€), par exemple à meteofrance. Ceux-ci tournent tous sous 
Linux. Mais on n'accède pas à la salle (très bruyante) les contenant. On 
peut avoir un processus de calcul sur un supercalculateur qui utilise 
une bibliothèque cliente X11 (par exemple GTK) pour afficher des 
résultats (des courbes) sur un PC local (qui a un serveur X11) sous 
Windows ou Linux.




--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re : Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

2023-07-15 Par sujet k6dedijon

Bonjour,
J'ai participé à l'université ouverte dans les années 1995-1999 et nous étions 
sous Debian avec le bureau KDE.
Je ne pratique plus cela depuis longtemps, mais je suis resté fidèle à KDE qui 
offre un bureau facile a appréhender par les utilisateurs qu'ils viennent de 
Windows ou de MAC.

L'expérience m'amène à installer KDEfull, puis à désinstaller les méta packages 
et paquets que je n’utilise pas. J'ai moins de problèmes en procédant ainsi 
qu'en installant des bouts à KDEbase.
Je pratique ainsi depuis 2008 et tout se passe sans problèmes de certaines 
dépendances ou compléments manquants.

Actuellement il y a kfrb pour partager les bureaux que ce soit sous Linux, 
Windows, MAC, Android...
https://apps.kde.org/fr/krfb/
Vous pouvez choisir le degré de protection que vous souhaitez. Un PDF en 
français l'explique très bien.

Voyez si cela peut vous convenir.
Bon courage,
Cassis

- Mail d'origine -
De: RogerT 
À: debian-user-french@lists.debian.org
Envoyé: Fri, 14 Jul 2023 15:56:49 +0200 (CEST)
Objet: Re: Accès distant graphique performant et sécurisé /avec 
écran-clavier-souris

> Le 14 juil. 2023 à 15:35, ajh-valmer  a écrit :
> 
> On Friday 14 July 2023 10:34:22 RogerT wrote:
>> J’ai besoin pour un utilisateur ordinaire de lui permettre un accès
>> graphique à un hôte debian 12 sous gnome.  
>> J’ai repensé à x2go, discuté dans ce fil de 2018. 
>> J’ai été embêté par la configuration. Je n’ai pas réussi  
>> Il semble que ce ne soit pas vraiment compatible avec gnome de debian 12. 
>> Et installer un DE léger comme xfce4 va créer un rejet chez l’utilisateur
>> habitué à VNC ou RDP.  
>> Peut-on configurer x2go de manière à conserver un bureau gnome allégé de
>> certains effets graphiques ? Et comment ? 
>> Ou alors KDE qui semble un DE confortable très apprécié sous debian ?
>> PS : Quelle est la situation de x2go par rapport au duo xorg/wayland ?
>> Puisque j’ai compris qu’on migrait progressivement vers wayland, plus
>> sécurisé.  
> 
> Bonjour,
> 
> Pour la partie DE, je conseille le bureau Tde-Trinity,
> il est léger, ergonomique, s'installe bien sur tous GNU/Linux, 
> un vrai bureau !
> C'est un fork de KDE-3 qui n'a pas cessé d'évoluer, car très bien maintenu.
> Aujourd'hui, il est comme un bureau KDE-5 sans ses inconvénients.
> 
> Y a t-il un rapport entre VNC ou RDP et un bureau ?

Merci pour la référence. 
Je voulais tester KDE dont beaucoup parlent en bien par rapport à gnome. 

Si ce DE Tde Trinity convient à l’utilisateur habitué à Gnome, je l’installerai 
et testerai l’accès à distance.  

VNC et RDP sont deux protocoles permettant d’accéder à distance au DE/bureau 
graphique. 
De mon expérience, avec VNC et RDP c’est un partage d’écran (on accède à la 
session ouverte). Avec RDP vers Win, c’est limité par la session unique (sinon, 
acheter Win server). Pour VNC, il est possible d’avoir deux sessions 
concurrentes (voir 
https://superuser.com/questions/363476/is-there-a-way-of-running-two-concurrent-vnc-sessions-one-per-logged-on-user#1408540
 ) 
Tandis que x2go ouvre sa propre session graphique. Ça surprend la première 
fois. 
On doit pouvoir partager une session graphique avec x2go mais je n’ai jamais 
essayé et je ne me souviens pas que la doc x2go en parle.

Re: Accès distant graphique performant, sécurisé, écran-clavier-souris

> Le 15 juil. 2023 à 23:07, ajh-valmer  a écrit :
> On Saturday 15 July 2023 20:09:56 didier gaumet wrote:
>> Enfin bref, c'est peut-être moi qui n'en comprend pas l'intérêt mais 
>> j'ai du mal à envisager XDMCP comme une solution intéressante.
> 
> XDMCP est la solution la plus utilisée pour le mode Terminaux/Serveur,
> à utiliser de préférence en mode intranet (sécurité).
> Elle ne doit pas être comparée à d'autres solutions qui n'ont pas 
> le même objectif, telle celui d'un établissement scolaire.
> 
> SSH, Teamviewer, Anydesk..., c'est pour un autre objectif,
> dépannage à distance, prendre la main sur un ordinateur distant...
> 

L’objectif est « Accès distant graphique performant, sécurisé, 
écran-clavier-souris ». 

Tu n’as pas du tout parlé de sécurité de la connexion. 

Pour assurer la sécurité de la connexion à un serveur via le protocole XDMCP, 
je dois d’abord ouvrir un tunnel ssh, par exemple. 
C’est impératif. 
Voir Warning en rouge dans https://wiki.archlinux.org/title/XDMCP .

C’est comme avec VNC qui n’utilise pas de protocole sécurisé de connexion.
Cf. notamment 
https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-vnc-on-ubuntu-20-04-fr#etape-3-connexion-securisee-au-bureau-vnc
 .

Le client Remmina propose de gérer ce tunnel. Le client java de Tightvnc aussi.

Car l’utilisateur ordinaire habitué à un client utilisable en un clic ne 
saisira jamais, avant d’ouvrir la connexion XDMCP ou VNC, une commande comme :
ssh -L 5901:localhost:5901 REMOTE_IP  

Ensuite, il faut veiller à ce que le port udp 177 soit ouvert sur le réseau 
pour XDMCP.
Ah, non… pas si on utilise un tunnel ssh (port 22). Comme avec VNC qui utilise 
le port 5901.
A ma connaissance, il faut quand même que le fw du serveur accepte les requêtes 
sur le port 22, et 177 ou 5901. 
Mais il faut encore que le routeur du LAN autorise le routage de port depuis 
l’adresse IP publique avec un numéro à définir (pas 22, s’il y a plusieurs 
serveurs ssh sur le LAN) vers le port 22 du serveur considéré. 

Ça marche mais c’est rustique. 

C’est en détaillant tout ça, avec ma connaissance réseau ordinaire, qu’on voit 
que MeshCentral permet de s’affranchir (à la Teamviewer) de toutes ces 
contraintes, selon NoSpam :
> « MeshAgent permet de se désengager de toute 
> installation/configuration/gestion de FW du client. Comme Anydesk ou 
> Teamviewer, une appli à télécharger par le client, peu importe l'OS, et vous 
> avez accès à sa machine soit en Gui soit en console (ou les deux). On peux 
> également se connecter en RDP à un client si l'accès est autorisé sur celui 
> ci. »

PS : Tu as écrit :
> « Chez moi, Teamviewer ne marche pas.
> Par contre, Anydesk marche très bien. »

Peux-tu expliquer pourquoi ?

Re: Accès distant graphique performant, sécurisé, écran-clavier-souris

On Saturday 15 July 2023 20:09:56 didier gaumet wrote:
> Enfin bref, c'est peut-être moi qui n'en comprend pas l'intérêt mais 
> j'ai du mal à envisager XDMCP comme une solution intéressante.

XDMCP est la solution la plus utilisée pour le mode Terminaux/Serveur,
à utiliser de préférence en mode intranet (sécurité).
Elle ne doit pas être comparée à d'autres solutions qui n'ont pas 
le même objectif, telle celui d'un établissement scolaire.

SSH, Teamviewer, Anydesk..., c'est pour un autre objectif,
dépannage à distance, prendre la main sur un ordinateur distant...

> Je m'arrête là, j'ai déjà trop participé à ce fil de messages 
> compte-tenu de mon manque total de connaissances sur le sujet, 
> ça n'apporte rien :-)

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

2023-07-15 Par sujet roger . tarani

De: "NoSpam"
À: "Liste Debian"
Envoyé: Samedi 15 Juillet 2023 16:23:53
Objet: Re: Accès distant graphique performant et sécurisé /avec
écran-clavier-souris

Le 15/07/2023 à 15:18, RogerT a écrit :

BQ_BEGIN

Alors, pourquoi ne pas regarder aussi vers Teleport, que j’ai aperçu récemment
?
[ https://goteleport.com/ | https://goteleport.com/ ]

BQ_END
Pourquoi chercher ailleurs alors que l'on a tout ce qui convient ? ;) Il existe
plein de solutions, j'ai trouvé la mienne après avoir utiliser
Teamviewer/Anydesk/Logmein et tant d'autres

Je decouvre l'existence de MeshCentral à peu près en même temps que celle de
Teleport.
Ça semble équivalent.
Ton expérience de MeshCentral est encourageante. Puisque ça a l'air de rendre
le service attendu sans souci.
Pour Teleport, je n'ai aucun retour d'expérience...

BQ_BEGIN

Dans les deux cas, il reste encore à vérifier la sécurité apportée par ces
engins qui ouvrent toutes les portes de l’infrastructure…

BQ_END
Aucune porte n'est ouverte puisqu'il s'agit d'un client serveur tout comme les
logiciels précités ci dessus.

Je ne suis pas assez calé en sécurité.
Mais "à partir du moment où j'installe un agent sur mon ordi, ce n'est plus
vraiment mon ordi".
En plus, l'outil de centralisation donne accès à tous les serveurs qui ont un
agent installé : ça fait réfléchir s'agissant d'un serveur sensible.
Ça me fait penser à l'attaque de Solarwinds Orion, un outil de suivi d'infra
qui a permis l'attaque que vous savez vers 2020.
[ https://www.solarwinds.com/orion-platform |
https://www.solarwinds.com/orion-platform ]
[
https://www.zdnet.fr/actualites/microsoft-et-fireeye-confirment-la-cyberattaque-de-solarwinds-39914821.htm
|
https://www.zdnet.fr/actualites/microsoft-et-fireeye-confirment-la-cyberattaque-de-solarwinds-39914821.htm
]

Comment peut-on savoir ce que fait exactement l'agent MeshCentral/MeshAgent
installé, ou tout agent qu'on installe comme avec Teamviewer, etc. ?
Ça me fait penser à SELinux (qui fonctionne bien pour ceux qui le maîtrise
parfaitement... je n'en ai aucune pratique), qui pourrait peut-être mettre des
"verrous unitaires" dans le système. Est-ce qu'un "monstre" comme SELinux
apporterait quelque chose pour sécuriser un système "percé" par l'implantation
d'un agent ?

Re: Accès distant graphique performant, sécurisé, écran-clavier-souris

2023-07-15 Par sujet didier gaumet


Le 15/07/2023 à 18:55, ajh-valmer a écrit :

On Saturday 15 July 2023 18:10:17 RogerT wrote:

Il faut juste TDE sur le serveur. Mais pas forcément sur le client,
puisque ce peut être Mac/Win.
C’est ça ?


Serveur : Linux + TDE + XDMCP.
(on peut avoir un autre système + autre bureau (p. ex. XFCE...),
il faut alors trouver l'outil de configuration).

Client : de préférence TDE ou autres systèmes + bureaux,
Windows = RDP, Mac/Win = pas fait essai.

Il faut faire l'effort de se documenter, taper dans moteur de recherche :
XDMCP, RDP, Terminal/Serveur ...


Rappel: je suis un quasi-demeuré en réseaux et sécurité donc prendre ce 
qui suit avec réserve


Mais j'ai l'impression que tu rends la situation plus confuse à Roger au 
lieu de l'éclairer


En gros XDMCP est un protocole de login X11 à distance:
- qui nécessite donc un serveur X11 qui tourne sur la machine distante, 
et un gestionnaire d'affichage (DM, Display Manager) compatible XDMCP, 
et que le protocole XDMCP soit autorisé (récemment ce n'est plus le cas 
par défaut)
- on n'a donc pas besoin d'un OS particulier (X11 peut tourner sur MacOS 
X ou sous Windows) ou d'un DE particulier, mais d'un serveur X11 (Xorg 
pour Linux ou MacOS X, Cygwin pour Windows...) et d'un DM compatible 
XDMCP (tdm, xdm, les autres je ne sais pas si c'est encore compatible) 
XDMCP autorisé
- XDMCP n'est pas compressé (consommation de bande passante) et il est 
déconseillé pour la sécurité de l'utiliser sur internet sans le faire 
passer par un tunnel SSH.
- j'ai jamais utilisé ça mais a priori, ce n'est pas du partage d'écran 
mais de l'affichage déporté: pas question pour l'assistant de montrer 
quelque chose à l'assisté, il ne voit pas ce que fait l'assistant.


Les plus anciens se rappeleront le site TDLP et de ses fameux Howto sur 
Linux. Ici il y a la traduction français du Howto XDMCP, ça date de 
2005, évdidemment faut replacer les choses dans le contexte, Xorg venait 
juste de sortir mais le howto parle de Xfree86...

https://traduc.org/Guides_pratiques/Suivi/XDMCP-HOWTO/Document

Enfin bref, c'est peut-être moi qui n'en comprend pas l'intérêt mais 
j'ai du mal à envisager XDMCP comme une solution intéressante, et plus 
encore de nos jours (même sous Linux, il n'y a parfois plus de X11 (par 
défaut de nos jours, GDM c'est une mini session Gnome Shell sous Wayland 
donc je ne pense pas que ça marche?)


Je m'arrête là, j'ai déjà trop participé à ce fil de messages 
compte-tenu de mon manque total de connaissances sur le sujet, ça 
n'apporte rien :-)

Re: Accès distant graphique performant, sécurisé, écran-clavier-souris

On Saturday 15 July 2023 18:10:17 RogerT wrote:
> Il faut juste TDE sur le serveur. Mais pas forcément sur le client, 
> puisque ce peut être Mac/Win.  
> C’est ça ?

Serveur : Linux + TDE + XDMCP. 
(on peut avoir un autre système + autre bureau (p. ex. XFCE...),
il faut alors trouver l'outil de configuration).

Client : de préférence TDE ou autres systèmes + bureaux,
Windows = RDP, Mac/Win = pas fait essai.

Il faut faire l'effort de se documenter, taper dans moteur de recherche :
XDMCP, RDP, Terminal/Serveur ...

Re: Accès distant graphique performant, sécurisé avec écran-clavier-souris




> Le 15 juil. 2023 à 17:55, ajh-valmer  a écrit :
> 
> On Saturday 15 July 2023 17:40:16 RogerT wrote:
>>> tde-trinity : il a la possibilité d'une connexion distante sur un client 
>>> avec XDMCP. (X Display Manager Control Protocol).
>>> Elle se fait au boot du bureau => Menu =>
>>> Connexion distante : 
>>> On paramètre XDMCP dans le fichier "/etc/trinity/tdm/tdmrc",
>>> rubrique XDMCP.
> 
>> Ça fonctionne entre deux machines linux, équipées de TDE pour 
>> au moins une des deux (le «serveur») ? Ou les deux aussi le «client» ? :
> 
> Oui, bien sûr.

Il faut juste TDE sur le serveur. Mais pas forcément sur le client, puisque ce 
peut être Mac/Win. 
C’est ça ?

> 
>> Est-ce qu’un utilisateur qui tourne sous MacOS ou win pourra se 
>> connecter à l’hôte qui tourne sous (l’excellent) TDE ? 
>> (cad déport de l’environnement graphique vers le «client» non linux)  
>> Et comment ?
> 
> Oui, à condition de faire le nécessaire sous MacOS et Windows.
> Pour ce dernier il y a RDP.  Pas fait d'essai avec MacOS.

Un client RDP suffit donc. C’est ça ?

>

Re: Accès distant graphique performant, sécurisé avec écran-clavier-souris

On Saturday 15 July 2023 17:40:16 RogerT wrote:
> > tde-trinity : il a la possibilité d'une connexion distante sur un client 
> > avec XDMCP. (X Display Manager Control Protocol).
> > Elle se fait au boot du bureau => Menu =>
> > Connexion distante : 
> > On paramètre XDMCP dans le fichier "/etc/trinity/tdm/tdmrc",
> > rubrique XDMCP.

> Ça fonctionne entre deux machines linux, équipées de TDE pour 
> au moins une des deux (le «serveur») ? Ou les deux aussi le «client» ? :

Oui, bien sûr.

> Est-ce qu’un utilisateur qui tourne sous MacOS ou win pourra se 
> connecter à l’hôte qui tourne sous (l’excellent) TDE ? 
> (cad déport de l’environnement graphique vers le «client» non linux)  
> Et comment ?

Oui, à condition de faire le nécessaire sous MacOS et Windows.
Pour ce dernier il y a RDP.  Pas fait d'essai avec MacOS.

Re: Accès distant graphique performant, sécurisé avec écran-clavier-souris




> Le 15 juil. 2023 à 15:13, ajh-valmer  a écrit :
> 
> On Friday 14 July 2023 19:38:05 RogerT wrote:
>> Quelle expérience de connexion à distance partagée, 
>> individuelle à ce DE/bureau as-tu ? 
>> Avec quel client ?
> 
> tde-trinity : il a la possibilité d'une connexion distante sur un client 
> avec XDMCP. (X Display Manager Control Protocol).
> Elle se fait au boot du bureau => Menu =>
> Connexion distante : 
> 
> On paramètre XDMCP dans le fichier "/etc/trinity/tdm/tdmrc",
> rubrique XDMCP.
> 
> Linux, les systèmes à base Unix, sont taillés pour les connexions
> distantes, c'est leur point fort, dont les connexions Terminaux/Serveur,
> Dans un réseau, un seul système, le serveur, et les terminaux s'y connectent
> sans posséder de système selon login + .
> On utilise des vieux ordinateurs comme terminaux, qui deviennent des 
> "bêtes de course" utilisant la puissance du serveur.
> C'est le cas dans plusieurs établissements scolaires,
> à la fin de l'année on supprime les comptes users des élèves qui
> ont quitté l'établissement, quel gain de temps pour l'administrateur.
> Dernier point, pour alléger le serveur, les terminaux peuvent avoir
> leur propre serveur graphique.
> 
> Conclusion : l'accès distant graphique performant et sécurisé +  
> écran-clavier-souris marche parfaitement avec Tde-Trinity.
> 
> A. Valmer
> 
ça fonctionne entre deux machines linux, équipées de TDE pour au moins une des 
deux (le « serveur ») ? Ou les deux aussi le « client » ?

Est-ce qu’un utilisateur qui tourne sous MacOS ou win pourra se connecter à 
l’hôte qui tourne sous (l’excellent) TDE ? (cad déport de l’environnement 
graphique vers le « client » non linux)
Et comment ?

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

2023-07-15 Par sujet NoSpam



Le 15/07/2023 à 15:18, RogerT a écrit :


MeshCentral
Développé par Ylian Saint-Hilaire, ingénieur chez Intel, MeshCentral 
permet la prise de contrôle de machines/serveurs via un agent 
Windows/Linux/MacOS à installer, en exécution seule (type Teamviewer 
QuickSupport) ou via la technologie Intel AMT (Active Management 
Technology). MeshCentral vous fournit, en plus de l’agent, le serveur 
associé qui centralise toutes les connexions des agents.


https://homepages.lcc-toulouse.fr/colombet/meshcentral-solution-libre-pour-remplacer-teamviewer/

Ça va bien au-delà d’un simple partage d’écran.
Utilises-tu la centralisation offerte par MeshCentral ?

Oui, sur une Debian11


Alors, pourquoi ne pas regarder aussi vers Teleport, que j’ai aperçu 
récemment ?

https://goteleport.com/
Pourquoi chercher ailleurs alors que l'on a tout ce qui convient ? ;) Il 
existe plein de solutions, j'ai trouvé la mienne après avoir utiliser 
Teamviewer/Anydesk/Logmein et tant d'autres


Dans les deux cas, il reste encore à vérifier la sécurité apportée par 
ces engins qui ouvrent toutes les portes de l’infrastructure…
Aucune porte n'est ouverte puisqu'il s'agit d'un client serveur tout 
comme les logiciels précités ci dessus.






Le 15 juil. 2023 à 14:20, NoSpam  a écrit :

Tant que l'agent tourne sur le client l'accès est ouvert. Si l'e 
client ne veut pas que le service tourne, il le lance à la main sur 
demande.


Des utilisateurs/groupes d 'utilisateurs peuvent être créés pour la 
gestion des accès.



Le 15/07/2023 à 14:07, RogerT a écrit :

Très bien.
Quelle garantie de sécurité/confidentialité y a-t-il avec MeshAgent 
(ou MeshCentral) ?


https://framalibre.org/content/meshcentral

De ton expérience, est-ce un partage d’écran ou aussi l’ouverture de 
sessions graphiques indépendantes (hôte linux) ?


Les deux, tout comme chat et autre joyeusetés.

https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwix5-732JCAAxXmTKQEHQktCE8QFnoECCEQAQ=https%3A%2F%2Fgithub.com%2FYlianst%2FMeshCentral=AOvVaw3rpgnKF8I_jnse61A52d94=89978449

https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwix5-732JCAAxXmTKQEHQktCE8QtwJ6BAg0EAI=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DpGBIjBGqlfI=AOvVaw247r9520YSVhaEk7Xt5XjQ=89978449

https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwiu5bSc2ZCAAxXcdqQEHWU5Dng4ChAWegQIDRAB=https%3A%2F%2Fhomepages.lcc-toulouse.fr%2Fcolombet%2Fmeshcentral-solution-libre-pour-remplacer-teamviewer%2F=AOvVaw1mT9VaJoEW2i9n6K4nafPY=89978449




Le 15 juil. 2023 à 13:55, NoSpam  a écrit :

J'insiste, mais MeshAgent permet de se désengager de toute 
installation/configuration/gestion de FW du client. Comme Anydesk 
ou Teamviewer, une appli à télécharger par le client, peu importe 
l'OS, et vous avez accès à sa machine soit en Gui soit en console 
(ou les deux). On peux également se connecter en RDP à un client si 
l'accès est autorisé sur celui ci.


Le 15/07/2023 à 13:12, RogerT a écrit :

Merci.

Rustdesk, « sans configuration », avec un serveur relais auto 
hébergé pour éviter la surveillance dénoncée (à vérifier : est-ce 
que ça suffit ?) : ça semble donc une bonne alternative.


Pour ma part, j’ai un bon retour d’expérience avec le client 
Remmina multi protocoles.
Il reste à déterminer les meilleurs serveur et protocole à 
installer sur la machine à laquelle accéder, en tenant compte du 
DE à installer (pas simple avec les DE linux qui posent 
visiblement diverses contraintes - se connecter en RDP à une 
machine win ne pose jamais de problème, sauf l’unicité de la 
session graphique, à ma connaissance, qui amène à utiliser 
Teamviewer pour partager l’écran).




Le 15 juil. 2023 à 12:58, didier gaumet  
a écrit :


Le 14/07/2023 à 12:44, RogerT a écrit :
[...]

Il y a 6 alternatives à TeamViewer :
https://framalibre.org/alternatives?tid=TeamViewer 


[...]

J'ai regardé un peu tout ça.

Perso, vu mon niveau et mon besoin potentiel de pouvoir assister 
des possesseurs de PC Windows que je n'administre pas, je 
privilégie un truc simple sans configuration: ici Hoptodesk ou 
Rustdesk


Hoptodesk:
- j'ai essayé une Appimage officielle, elle s'est vautrée. En 
lançant dans un terminal je vois qu'il manque une bibliothèque 
(pour une Appimage, hein, c'est pas censé arriver...), je 
l'installe à la main, pour voir: ça ne couine plus sur le manque 
d'un bibliothèque, ça se vautre avec une myriade de messages 
d'erreur :-(
- je cherche un peu sur internet et je m'aperçois qu'en fait 
Hoptodesk est un fork de Rustdesk dont l'auteur n'avait à 
l'origine pas compris les termes des licences AGPL/GPL et avait 
supprimé les copyright Rustdesk :-(

=> je ne sais pas pour vous mais pour moi, Hoptodesk est à fuir

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

2023-07-15 Par sujet didier gaumet


Le 15/07/2023 à 13:12, RogerT a écrit :

Merci.

Rustdesk, « sans configuration », avec un serveur relais auto hébergé pour 
éviter la surveillance dénoncée (à vérifier : est-ce que ça suffit ?) : ça 
semble donc une bonne alternative.

[...]

D'abord, une précision, toi et moi ne sommes pas vraiment dans la même 
situation:
- je privilégie une solution techniquement sans tracas dans le cadre 
d'une relation privée d'assistance auprès de proches (et de nos 
compétences limitées, les leurs comme les miennes)
- sauf erreur ta réflexion concerne ton activité professionnelle dans le 
cadre d'une assistance formalisée contractuellement ou de manière moins 
officielle où tu sembles tenu d'apporter une plus-value voire des 
garanties de bonnes pratiques. Donc je suppose que tu dois être prêt à 
supporter plus de contraintes que moi dans la mise en place de la 
solution mais que celle-ci doit t'offrir plus de perspectives de 
pérennité, fiabilité, scalabilité, sécurité, intégration logicielle, etc...


Donc dans ce contexte peut-être que des solutions plus classiques (RDP, 
VNC, X11, etc...) ou plus client-serveur à la Meshcentral proposé par 
NoSpam seraient plus adaptées (c'est une supposition, pas une affirmation)


Donc à la question de savoir si monter un serveur Rustdesk te 
garantirait des risques de fuite d'informations:


*Objectivement*, je ne peux pas te répondre à ce sujet: je ne sais pas, 
je suis une truffe sur le sujet.


*Intuitivement*, mon impression (rappel: j'y connais, je hasarde des 
hypothèses) serait plutôt que le serveur ne sert qu'à la mise en 
relation de l'assistant et de l'assisté de télémaintenance, le reste de 
la session de télémaintenance se faisant en une sorte de liaison 
pair-à-pair entre l'assistant et l'assisté.
Donc on peut se poser la question: si Rustdesk recueille et transmet des 
infos, de quoi s'agit-il:
1) est-ce de l'info technique anonymisée transmise à l'équipe de 
développement de Rustdesk pour amélioration du logiciel et correction 
des bugs (auquel cas je pense que le serveur n'est pas concerné),

2) ou s'agit-il de recueil d'infos dans un but commercial
3) ou alors s'agit-il de collecte d'informations dans un but de 
surveillance dans un autre but?
 Je ne pense pas qu'il s'agisse du 3) car ça me paraît trop gros que ça 
ait passé les contrôles des app stores Apple, Google et F-Droid

 Après, le 1) et le 2), philosophiquement c'est assez différent.
 Et dans les cas 2) et 3) j'imagine (intuition, toujours) que les 
bénéfices retirés seraient moins importants dans la surveillance du 
serveur que de la liaison pair-à-pair

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

Chez moi, Teamviewer ne marche pas.

Par contre, Anydesk marche très bien.

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris


MeshCentral
Développé par Ylian Saint-Hilaire, ingénieur chez Intel, MeshCentral permet la 
prise de contrôle de machines/serveurs via un agent Windows/Linux/MacOS à 
installer, en exécution seule (type Teamviewer QuickSupport) ou via la 
technologie Intel AMT (Active Management Technology). MeshCentral vous fournit, 
en plus de l’agent, le serveur associé qui centralise toutes les connexions des 
agents.

https://homepages.lcc-toulouse.fr/colombet/meshcentral-solution-libre-pour-remplacer-teamviewer/

Ça va bien au-delà d’un simple partage d’écran. 
Utilises-tu la centralisation offerte par MeshCentral ?

Alors, pourquoi ne pas regarder aussi vers Teleport, que j’ai aperçu récemment ?
https://goteleport.com/

Dans les deux cas, il reste encore à vérifier la sécurité apportée par ces 
engins qui ouvrent toutes les portes de l’infrastructure…




> Le 15 juil. 2023 à 14:20, NoSpam  a écrit :
> 
> Tant que l'agent tourne sur le client l'accès est ouvert. Si l'e client ne 
> veut pas que le service tourne, il le lance à la main sur demande.
> 
> Des utilisateurs/groupes d 'utilisateurs peuvent être créés pour la gestion 
> des accès.
> 
> 
>> Le 15/07/2023 à 14:07, RogerT a écrit :
>> Très bien.
>> Quelle garantie de sécurité/confidentialité y a-t-il avec MeshAgent (ou 
>> MeshCentral) ?
>> 
>> https://framalibre.org/content/meshcentral
>> 
>> De ton expérience, est-ce un partage d’écran ou aussi l’ouverture de 
>> sessions graphiques indépendantes (hôte linux) ?
> 
> Les deux, tout comme chat et autre joyeusetés.
> 
> https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwix5-732JCAAxXmTKQEHQktCE8QFnoECCEQAQ=https%3A%2F%2Fgithub.com%2FYlianst%2FMeshCentral=AOvVaw3rpgnKF8I_jnse61A52d94=89978449
> 
> https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwix5-732JCAAxXmTKQEHQktCE8QtwJ6BAg0EAI=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DpGBIjBGqlfI=AOvVaw247r9520YSVhaEk7Xt5XjQ=89978449
> 
> https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwiu5bSc2ZCAAxXcdqQEHWU5Dng4ChAWegQIDRAB=https%3A%2F%2Fhomepages.lcc-toulouse.fr%2Fcolombet%2Fmeshcentral-solution-libre-pour-remplacer-teamviewer%2F=AOvVaw1mT9VaJoEW2i9n6K4nafPY=89978449
> 
>> 
 Le 15 juil. 2023 à 13:55, NoSpam  a écrit :
>>> 
>>> J'insiste, mais MeshAgent permet de se désengager de toute 
>>> installation/configuration/gestion de FW du client. Comme Anydesk ou 
>>> Teamviewer, une appli à télécharger par le client, peu importe l'OS, et 
>>> vous avez accès à sa machine soit en Gui soit en console (ou les deux). On 
>>> peux également se connecter en RDP à un client si l'accès est autorisé sur 
>>> celui ci.
>>> 
>>> Le 15/07/2023 à 13:12, RogerT a écrit :
 Merci.
 
 Rustdesk, « sans configuration », avec un serveur relais auto hébergé pour 
 éviter la surveillance dénoncée (à vérifier : est-ce que ça suffit ?) : ça 
 semble donc une bonne alternative.
 
 Pour ma part, j’ai un bon retour d’expérience avec le client Remmina multi 
 protocoles.
 Il reste à déterminer les meilleurs serveur et protocole à installer sur 
 la machine à laquelle accéder, en tenant compte du DE à installer (pas 
 simple avec les DE linux qui posent visiblement diverses contraintes - se 
 connecter en RDP à une machine win ne pose jamais de problème, sauf 
 l’unicité de la session graphique, à ma connaissance, qui amène à utiliser 
 Teamviewer pour partager l’écran).
 
 
 
> Le 15 juil. 2023 à 12:58, didier gaumet  a écrit 
> :
> 
> Le 14/07/2023 à 12:44, RogerT a écrit :
> [...]
>> Il y a 6 alternatives à TeamViewer :
>> https://framalibre.org/alternatives?tid=TeamViewer 
>> 
> [...]
> 
> J'ai regardé un peu tout ça.
> 
> Perso, vu mon niveau et mon besoin potentiel de pouvoir assister des 
> possesseurs de PC Windows que je n'administre pas, je privilégie un truc 
> simple sans configuration: ici Hoptodesk ou Rustdesk
> 
> Hoptodesk:
> - j'ai essayé une Appimage officielle, elle s'est vautrée. En lançant 
> dans un terminal je vois qu'il manque une bibliothèque (pour une 
> Appimage, hein, c'est pas censé arriver...), je l'installe à la main, 
> pour voir: ça ne couine plus sur le manque d'un bibliothèque, ça se 
> vautre avec une myriade de messages d'erreur :-(
> - je cherche un peu sur internet et je m'aperçois qu'en fait Hoptodesk 
> est un fork de Rustdesk dont l'auteur n'avait à l'origine pas compris les 
> termes des licences AGPL/GPL et avait supprimé les copyright Rustdesk :-(
> => je ne sais pas pour vous mais pour moi, Hoptodesk est à fuir
> 
> 
>>> 
>

Re: Accès distant graphique performant, sécurisé avec écran-clavier-souris

On Friday 14 July 2023 19:38:05 RogerT wrote:
> Quelle expérience de connexion à distance partagée, 
> individuelle à ce DE/bureau as-tu ? 
> Avec quel client ?

tde-trinity : il a la possibilité d'une connexion distante sur un client 
avec XDMCP. (X Display Manager Control Protocol).
Elle se fait au boot du bureau => Menu =>
Connexion distante : 

On paramètre XDMCP dans le fichier "/etc/trinity/tdm/tdmrc",
rubrique XDMCP.

Linux, les systèmes à base Unix, sont taillés pour les connexions
distantes, c'est leur point fort, dont les connexions Terminaux/Serveur,
Dans un réseau, un seul système, le serveur, et les terminaux s'y connectent
sans posséder de système selon login + .
On utilise des vieux ordinateurs comme terminaux, qui deviennent des 
"bêtes de course" utilisant la puissance du serveur.
C'est le cas dans plusieurs établissements scolaires,
à la fin de l'année on supprime les comptes users des élèves qui
ont quitté l'établissement, quel gain de temps pour l'administrateur.
Dernier point, pour alléger le serveur, les terminaux peuvent avoir
leur propre serveur graphique.

Conclusion : l'accès distant graphique performant et sécurisé +  
écran-clavier-souris marche parfaitement avec Tde-Trinity.

A. Valmer

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

2023-07-15 Par sujet NoSpam

Tant que l'agent tourne sur le client l'accès est ouvert. Si l'e client 
ne veut pas que le service tourne, il le lance à la main sur demande.


Des utilisateurs/groupes d 'utilisateurs peuvent être créés pour la 
gestion des accès.



Le 15/07/2023 à 14:07, RogerT a écrit :

Très bien.
Quelle garantie de sécurité/confidentialité y a-t-il avec MeshAgent 
(ou MeshCentral) ?


https://framalibre.org/content/meshcentral

De ton expérience, est-ce un partage d’écran ou aussi l’ouverture de 
sessions graphiques indépendantes (hôte linux) ?


Les deux, tout comme chat et autre joyeusetés.

https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwix5-732JCAAxXmTKQEHQktCE8QFnoECCEQAQ=https%3A%2F%2Fgithub.com%2FYlianst%2FMeshCentral=AOvVaw3rpgnKF8I_jnse61A52d94=89978449

https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwix5-732JCAAxXmTKQEHQktCE8QtwJ6BAg0EAI=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DpGBIjBGqlfI=AOvVaw247r9520YSVhaEk7Xt5XjQ=89978449

https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwiu5bSc2ZCAAxXcdqQEHWU5Dng4ChAWegQIDRAB=https%3A%2F%2Fhomepages.lcc-toulouse.fr%2Fcolombet%2Fmeshcentral-solution-libre-pour-remplacer-teamviewer%2F=AOvVaw1mT9VaJoEW2i9n6K4nafPY=89978449




Le 15 juil. 2023 à 13:55, NoSpam  a écrit :

J'insiste, mais MeshAgent permet de se désengager de toute 
installation/configuration/gestion de FW du client. Comme Anydesk ou 
Teamviewer, une appli à télécharger par le client, peu importe l'OS, 
et vous avez accès à sa machine soit en Gui soit en console (ou les 
deux). On peux également se connecter en RDP à un client si l'accès 
est autorisé sur celui ci.


Le 15/07/2023 à 13:12, RogerT a écrit :

Merci.

Rustdesk, « sans configuration », avec un serveur relais auto 
hébergé pour éviter la surveillance dénoncée (à vérifier : est-ce 
que ça suffit ?) : ça semble donc une bonne alternative.


Pour ma part, j’ai un bon retour d’expérience avec le client Remmina 
multi protocoles.
Il reste à déterminer les meilleurs serveur et protocole à installer 
sur la machine à laquelle accéder, en tenant compte du DE à 
installer (pas simple avec les DE linux qui posent visiblement 
diverses contraintes - se connecter en RDP à une machine win ne pose 
jamais de problème, sauf l’unicité de la session graphique, à ma 
connaissance, qui amène à utiliser Teamviewer pour partager l’écran).




Le 15 juil. 2023 à 12:58, didier gaumet  a 
écrit :


Le 14/07/2023 à 12:44, RogerT a écrit :
[...]

Il y a 6 alternatives à TeamViewer :
https://framalibre.org/alternatives?tid=TeamViewer 


[...]

J'ai regardé un peu tout ça.

Perso, vu mon niveau et mon besoin potentiel de pouvoir assister 
des possesseurs de PC Windows que je n'administre pas, je 
privilégie un truc simple sans configuration: ici Hoptodesk ou Rustdesk


Hoptodesk:
- j'ai essayé une Appimage officielle, elle s'est vautrée. En 
lançant dans un terminal je vois qu'il manque une bibliothèque 
(pour une Appimage, hein, c'est pas censé arriver...), je 
l'installe à la main, pour voir: ça ne couine plus sur le manque 
d'un bibliothèque, ça se vautre avec une myriade de messages 
d'erreur :-(
- je cherche un peu sur internet et je m'aperçois qu'en fait 
Hoptodesk est un fork de Rustdesk dont l'auteur n'avait à l'origine 
pas compris les termes des licences AGPL/GPL et avait supprimé les 
copyright Rustdesk :-(

=> je ne sais pas pour vous mais pour moi, Hoptodesk est à fuir

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

Très bien. 
Quelle garantie de sécurité/confidentialité y a-t-il avec MeshAgent (ou 
MeshCentral) ?

https://framalibre.org/content/meshcentral

De ton expérience, est-ce un partage d’écran ou aussi l’ouverture de sessions 
graphiques indépendantes (hôte linux) ?

> Le 15 juil. 2023 à 13:55, NoSpam  a écrit :
> J'insiste, mais MeshAgent permet de se désengager de toute 
> installation/configuration/gestion de FW du client. Comme Anydesk ou 
> Teamviewer, une appli à télécharger par le client, peu importe l'OS, et vous 
> avez accès à sa machine soit en Gui soit en console (ou les deux). On peux 
> également se connecter en RDP à un client si l'accès est autorisé sur celui 
> ci.
> 
> Le 15/07/2023 à 13:12, RogerT a écrit :
>> Merci.
>> 
>> Rustdesk, « sans configuration », avec un serveur relais auto hébergé pour 
>> éviter la surveillance dénoncée (à vérifier : est-ce que ça suffit ?) : ça 
>> semble donc une bonne alternative.
>> 
>> Pour ma part, j’ai un bon retour d’expérience avec le client Remmina multi 
>> protocoles.
>> Il reste à déterminer les meilleurs serveur et protocole à installer sur la 
>> machine à laquelle accéder, en tenant compte du DE à installer (pas simple 
>> avec les DE linux qui posent visiblement diverses contraintes - se connecter 
>> en RDP à une machine win ne pose jamais de problème, sauf l’unicité de la 
>> session graphique, à ma connaissance, qui amène à utiliser Teamviewer pour 
>> partager l’écran).
>> 
>> 
>> 
>>> Le 15 juil. 2023 à 12:58, didier gaumet  a écrit :
>>> Le 14/07/2023 à 12:44, RogerT a écrit :
>>> [...]
 Il y a 6 alternatives à TeamViewer :
 https://framalibre.org/alternatives?tid=TeamViewer 
 
>>> [...]
>>> J'ai regardé un peu tout ça.
>>> Perso, vu mon niveau et mon besoin potentiel de pouvoir assister des 
>>> possesseurs de PC Windows que je n'administre pas, je privilégie un truc 
>>> simple sans configuration: ici Hoptodesk ou Rustdesk
>>> Hoptodesk:
>>> - j'ai essayé une Appimage officielle, elle s'est vautrée. En lançant dans 
>>> un terminal je vois qu'il manque une bibliothèque (pour une Appimage, hein, 
>>> c'est pas censé arriver...), je l'installe à la main, pour voir: ça ne 
>>> couine plus sur le manque d'un bibliothèque, ça se vautre avec une myriade 
>>> de messages d'erreur :-(
>>> - je cherche un peu sur internet et je m'aperçois qu'en fait Hoptodesk est 
>>> un fork de Rustdesk dont l'auteur n'avait à l'origine pas compris les 
>>> termes des licences AGPL/GPL et avait supprimé les copyright Rustdesk :-(
>>> => je ne sais pas pour vous mais pour moi, Hoptodesk est à fuir

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

2023-07-15 Par sujet NoSpam

J'insiste, mais MeshAgent permet de se désengager de toute 
installation/configuration/gestion de FW du client. Comme Anydesk ou 
Teamviewer, une appli à télécharger par le client, peu importe l'OS, et 
vous avez accès à sa machine soit en Gui soit en console (ou les deux). 
On peux également se connecter en RDP à un client si l'accès est 
autorisé sur celui ci.


Le 15/07/2023 à 13:12, RogerT a écrit :

Merci.

Rustdesk, « sans configuration », avec un serveur relais auto hébergé pour 
éviter la surveillance dénoncée (à vérifier : est-ce que ça suffit ?) : ça 
semble donc une bonne alternative.

Pour ma part, j’ai un bon retour d’expérience avec le client Remmina multi 
protocoles.
Il reste à déterminer les meilleurs serveur et protocole à installer sur la 
machine à laquelle accéder, en tenant compte du DE à installer (pas simple avec 
les DE linux qui posent visiblement diverses contraintes - se connecter en RDP 
à une machine win ne pose jamais de problème, sauf l’unicité de la session 
graphique, à ma connaissance, qui amène à utiliser Teamviewer pour partager 
l’écran).




Le 15 juil. 2023 à 12:58, didier gaumet  a écrit :

Le 14/07/2023 à 12:44, RogerT a écrit :
[...]

Il y a 6 alternatives à TeamViewer :
https://framalibre.org/alternatives?tid=TeamViewer 


[...]

J'ai regardé un peu tout ça.

Perso, vu mon niveau et mon besoin potentiel de pouvoir assister des 
possesseurs de PC Windows que je n'administre pas, je privilégie un truc simple 
sans configuration: ici Hoptodesk ou Rustdesk

Hoptodesk:
- j'ai essayé une Appimage officielle, elle s'est vautrée. En lançant dans un 
terminal je vois qu'il manque une bibliothèque (pour une Appimage, hein, c'est 
pas censé arriver...), je l'installe à la main, pour voir: ça ne couine plus 
sur le manque d'un bibliothèque, ça se vautre avec une myriade de messages 
d'erreur :-(
- je cherche un peu sur internet et je m'aperçois qu'en fait Hoptodesk est un 
fork de Rustdesk dont l'auteur n'avait à l'origine pas compris les termes des 
licences AGPL/GPL et avait supprimé les copyright Rustdesk :-(
=> je ne sais pas pour vous mais pour moi, Hoptodesk est à fuir

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

Merci. 

Rustdesk, « sans configuration », avec un serveur relais auto hébergé pour 
éviter la surveillance dénoncée (à vérifier : est-ce que ça suffit ?) : ça 
semble donc une bonne alternative. 

Pour ma part, j’ai un bon retour d’expérience avec le client Remmina multi 
protocoles.
Il reste à déterminer les meilleurs serveur et protocole à installer sur la 
machine à laquelle accéder, en tenant compte du DE à installer (pas simple avec 
les DE linux qui posent visiblement diverses contraintes - se connecter en RDP 
à une machine win ne pose jamais de problème, sauf l’unicité de la session 
graphique, à ma connaissance, qui amène à utiliser Teamviewer pour partager 
l’écran). 



> Le 15 juil. 2023 à 12:58, didier gaumet  a écrit :
> 
> Le 14/07/2023 à 12:44, RogerT a écrit :
> [...]
>> Il y a 6 alternatives à TeamViewer :
>> https://framalibre.org/alternatives?tid=TeamViewer 
>> 
> [...]
> 
> J'ai regardé un peu tout ça.
> 
> Perso, vu mon niveau et mon besoin potentiel de pouvoir assister des 
> possesseurs de PC Windows que je n'administre pas, je privilégie un truc 
> simple sans configuration: ici Hoptodesk ou Rustdesk
> 
> Hoptodesk:
> - j'ai essayé une Appimage officielle, elle s'est vautrée. En lançant dans un 
> terminal je vois qu'il manque une bibliothèque (pour une Appimage, hein, 
> c'est pas censé arriver...), je l'installe à la main, pour voir: ça ne couine 
> plus sur le manque d'un bibliothèque, ça se vautre avec une myriade de 
> messages d'erreur :-(
> - je cherche un peu sur internet et je m'aperçois qu'en fait Hoptodesk est un 
> fork de Rustdesk dont l'auteur n'avait à l'origine pas compris les termes des 
> licences AGPL/GPL et avait supprimé les copyright Rustdesk :-(
> => je ne sais pas pour vous mais pour moi, Hoptodesk est à fuir
> 
>

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

2023-07-15 Par sujet didier gaumet


Le 14/07/2023 à 12:44, RogerT a écrit :
[...]

Il y a 6 alternatives à TeamViewer :
https://framalibre.org/alternatives?tid=TeamViewer 


[...]

J'ai regardé un peu tout ça.

Perso, vu mon niveau et mon besoin potentiel de pouvoir assister des 
possesseurs de PC Windows que je n'administre pas, je privilégie un truc 
simple sans configuration: ici Hoptodesk ou Rustdesk


Hoptodesk:
- j'ai essayé une Appimage officielle, elle s'est vautrée. En lançant 
dans un terminal je vois qu'il manque une bibliothèque (pour une 
Appimage, hein, c'est pas censé arriver...), je l'installe à la main, 
pour voir: ça ne couine plus sur le manque d'un bibliothèque, ça se 
vautre avec une myriade de messages d'erreur :-(
- je cherche un peu sur internet et je m'aperçois qu'en fait Hoptodesk 
est un fork de Rustdesk dont l'auteur n'avait à l'origine pas compris 
les termes des licences AGPL/GPL et avait supprimé les copyright 
Rustdesk :-(

=> je ne sais pas pour vous mais pour moi, Hoptodesk est à fuir

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

Quelle expérience de connexion à distance partagée, individuelle à ce DE/bureau 
as-tu ?
Avec quel client ?

> Le 14 juil. 2023 à 16:18, ajh-valmer  a écrit :
> 
> On Friday 14 July 2023 15:56:49 RogerT wrote:
 Le 14 juil. 2023 à 15:35, ajh-valmer  a écrit :
>>> 
>>> On Friday 14 July 2023 10:34:22 RogerT wrote:
 Et installer un DE léger comme xfce4 va créer un rejet chez l’utilisateur
 habitué à VNC ou RDP.  
 Peut-on configurer x2go de manière à conserver un bureau gnome allégé de
 certains effets graphiques ? Et comment ? 
 Ou alors KDE qui semble un DE confortable très apprécié sous debian ?
 PS : Quelle est la situation de x2go par rapport au duo xorg/wayland ?
 Puisque j’ai compris qu’on migrait progressivement vers wayland, plus
 sécurisé.  
> 
>>> Pour la partie DE, je conseille le bureau Tde-Trinity :
> 
>> Merci pour la référence. 
>> Je voulais tester KDE dont beaucoup parlent en bien par rapport à gnome. 
>> Si ce DE Tde Trinity convient à l’utilisateur habitué à Gnome, 
>> je l’installerai et testerai l’accès à distance.   
>> VNC et RDP sont deux protocoles permettant d’accéder à distance au DE/bureau
>> graphique.  
>> De mon expérience, avec VNC et RDP c’est un partage d’écran 
>> (on accède à la session ouverte). Avec RDP vers Win, c’est limité par la
>> session unique (sinon, acheter Win server). Pour VNC, il est possible
>> d’avoir deux sessions concurrentes :
>> 
> https://superuser.com/questions/363476/is-there-a-way-of-running-two-concurrent-vnc-sessions-one-per-logged-on-user#1408540
>  ) 
>> Tandis que x2go ouvre sa propre session graphique. Ça surprend la première
>> fois.  
>> On doit pouvoir partager une session graphique avec x2go mais je n’ai jamais
>> essayé et je ne me souviens pas que la doc x2go en parle.  
> 
> Essayer TDE-Trinity c'est l'adopter :-)
> Pour l'installer, souces.list (toute la ligne) (remplacer bookworm par sa 
> distribution) :
> deb http://mirror.ppa.trinitydesktop.org/trinity/deb/trinity-r14.1.x bookworm 
> main deps
> 
> Il y a une ML (en anglais), ce sujet VNC ou RDP a été évoqué.
> Voici ses coordonnées : 
> tde-users mailing list -- us...@trinitydesktop.org
> https://mail.trinitydesktop.org/mailman3/accounts/signup/?next=/mailman3/hyperkitty/list/users%40trinitydesktop.org/
> 
> Hope it helps.
>

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

2023-07-14 Par sujet ajh-valmer

On Friday 14 July 2023 15:56:49 RogerT wrote:
> > Le 14 juil. 2023 à 15:35, ajh-valmer  a écrit :
> > 
> > On Friday 14 July 2023 10:34:22 RogerT wrote:
> >> Et installer un DE léger comme xfce4 va créer un rejet chez l’utilisateur
> >> habitué à VNC ou RDP.  
> >> Peut-on configurer x2go de manière à conserver un bureau gnome allégé de
> >> certains effets graphiques ? Et comment ? 
> >> Ou alors KDE qui semble un DE confortable très apprécié sous debian ?
> >> PS : Quelle est la situation de x2go par rapport au duo xorg/wayland ?
> >> Puisque j’ai compris qu’on migrait progressivement vers wayland, plus
> >> sécurisé.  

> > Pour la partie DE, je conseille le bureau Tde-Trinity :

> Merci pour la référence. 
> Je voulais tester KDE dont beaucoup parlent en bien par rapport à gnome. 
> Si ce DE Tde Trinity convient à l’utilisateur habitué à Gnome, 
> je l’installerai et testerai l’accès à distance.   
> VNC et RDP sont deux protocoles permettant d’accéder à distance au DE/bureau
> graphique.  
> De mon expérience, avec VNC et RDP c’est un partage d’écran 
> (on accède à la session ouverte). Avec RDP vers Win, c’est limité par la
> session unique (sinon, acheter Win server). Pour VNC, il est possible
> d’avoir deux sessions concurrentes :
> 
https://superuser.com/questions/363476/is-there-a-way-of-running-two-concurrent-vnc-sessions-one-per-logged-on-user#1408540
 ) 
> Tandis que x2go ouvre sa propre session graphique. Ça surprend la première
> fois.  
> On doit pouvoir partager une session graphique avec x2go mais je n’ai jamais
> essayé et je ne me souviens pas que la doc x2go en parle.  

Essayer TDE-Trinity c'est l'adopter :-)
Pour l'installer, souces.list (toute la ligne) (remplacer bookworm par sa 
distribution) :
deb http://mirror.ppa.trinitydesktop.org/trinity/deb/trinity-r14.1.x bookworm 
main deps

Il y a une ML (en anglais), ce sujet VNC ou RDP a été évoqué.
Voici ses coordonnées : 
tde-users mailing list -- us...@trinitydesktop.org
https://mail.trinitydesktop.org/mailman3/accounts/signup/?next=/mailman3/hyperkitty/list/users%40trinitydesktop.org/

Hope it helps.

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

> Le 14 juil. 2023 à 15:35, ajh-valmer  a écrit :
> 
> On Friday 14 July 2023 10:34:22 RogerT wrote:
>> J’ai besoin pour un utilisateur ordinaire de lui permettre un accès
>> graphique à un hôte debian 12 sous gnome.  
>> J’ai repensé à x2go, discuté dans ce fil de 2018. 
>> J’ai été embêté par la configuration. Je n’ai pas réussi  
>> Il semble que ce ne soit pas vraiment compatible avec gnome de debian 12. 
>> Et installer un DE léger comme xfce4 va créer un rejet chez l’utilisateur
>> habitué à VNC ou RDP.  
>> Peut-on configurer x2go de manière à conserver un bureau gnome allégé de
>> certains effets graphiques ? Et comment ? 
>> Ou alors KDE qui semble un DE confortable très apprécié sous debian ?
>> PS : Quelle est la situation de x2go par rapport au duo xorg/wayland ?
>> Puisque j’ai compris qu’on migrait progressivement vers wayland, plus
>> sécurisé.  
> 
> Bonjour,
> 
> Pour la partie DE, je conseille le bureau Tde-Trinity,
> il est léger, ergonomique, s'installe bien sur tous GNU/Linux, 
> un vrai bureau !
> C'est un fork de KDE-3 qui n'a pas cessé d'évoluer, car très bien maintenu.
> Aujourd'hui, il est comme un bureau KDE-5 sans ses inconvénients.
> 
> Y a t-il un rapport entre VNC ou RDP et un bureau ?

Merci pour la référence. 
Je voulais tester KDE dont beaucoup parlent en bien par rapport à gnome. 

Si ce DE Tde Trinity convient à l’utilisateur habitué à Gnome, je l’installerai 
et testerai l’accès à distance.  

VNC et RDP sont deux protocoles permettant d’accéder à distance au DE/bureau 
graphique. 
De mon expérience, avec VNC et RDP c’est un partage d’écran (on accède à la 
session ouverte). Avec RDP vers Win, c’est limité par la session unique (sinon, 
acheter Win server). Pour VNC, il est possible d’avoir deux sessions 
concurrentes (voir 
https://superuser.com/questions/363476/is-there-a-way-of-running-two-concurrent-vnc-sessions-one-per-logged-on-user#1408540
 ) 
Tandis que x2go ouvre sa propre session graphique. Ça surprend la première 
fois. 
On doit pouvoir partager une session graphique avec x2go mais je n’ai jamais 
essayé et je ne me souviens pas que la doc x2go en parle.

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

2023-07-14 Par sujet ajh-valmer

On Friday 14 July 2023 10:34:22 RogerT wrote:
> J’ai besoin pour un utilisateur ordinaire de lui permettre un accès
> graphique à un hôte debian 12 sous gnome.  
> J’ai repensé à x2go, discuté dans ce fil de 2018. 
> J’ai été embêté par la configuration. Je n’ai pas réussi  
> Il semble que ce ne soit pas vraiment compatible avec gnome de debian 12. 
> Et installer un DE léger comme xfce4 va créer un rejet chez l’utilisateur
> habitué à VNC ou RDP.  
> Peut-on configurer x2go de manière à conserver un bureau gnome allégé de
> certains effets graphiques ? Et comment ? 
> Ou alors KDE qui semble un DE confortable très apprécié sous debian ?
> PS : Quelle est la situation de x2go par rapport au duo xorg/wayland ?
> Puisque j’ai compris qu’on migrait progressivement vers wayland, plus
> sécurisé.  

Bonjour,

Pour la partie DE, je conseille le bureau Tde-Trinity,
il est léger, ergonomique, s'installe bien sur tous GNU/Linux, 
un vrai bureau !
C'est un fork de KDE-3 qui n'a pas cessé d'évoluer, car très bien maintenu.
Aujourd'hui, il est comme un bureau KDE-5 sans ses inconvénients.

Y a t-il un rapport entre VNC ou RDP et un bureau ?

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

2023-07-14 Par sujet didier gaumet


Le 14/07/2023 à 12:44, RogerT a écrit :
[...]
https://framalibre.org/alternatives?tid=TeamViewer 


[...]

c'est marrant (manière de parler), il y a un certain nombre d'années il 
m'arrivait d'écire des préstentations de logiciels sur Framasoft et puis 
ensuite Framasoft m'est totalement sorti de l'esprit, je ne pense jamais

à aller voir ce qu'ils préconisent comme alternatives...
Donc merci de m'avoir rappelé son existence, je vais regarder ça en 
détail :-)

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

Bonjour 

Merci pour l’avertissement !
Et pour la référence à Rustdesk. 
Je note qu’on peut auto héberger ou écrire son propre serveur relais, si ça 
règle « le problème signalé de tracking dans l’application ». 

Il y a 6 alternatives à TeamViewer :
https://framalibre.org/alternatives?tid=TeamViewer
Rustdesk y apparaît. 
Et le client Remmina. 

Ça me rappelle que j’utilise le client Remmina (RDP, VNC, SPICE, NX, XDMCP, SSH 
et EXEC). Avec satisfaction. 
Juste deux problèmes mineurs :
- la barre du haut est parfois activée quand on approche la souris sans le 
vouloir - il faut voir si la dernière version corrige ça (comme iOS RDP dont la 
barre de contrôle peut être réduite pour ne pas gêner)
- en RDP, la connexion saute, rarement, quand on manipule en édition des pdf, 
ce qui doit générer des séquences de caractères pertubantes (avec Acrobat pro 
sur une machine Win)

A y réfléchir ensemble, la solution que je recherche est peut-être tout 
simplement de garder un client Remmina et de trouver un bon serveur RDP ou VNC 
ou autre protocole pertinent, à déterminer. 

Ce qui ramène au fil que j’ai ouvert hier : « tightvnc vs. tigervnc vs. ? ». 


> Le 14 juil. 2023 à 11:58, didier gaumet  a écrit :
> Le 14/07/2023 à 10:34, RogerT a écrit :
>> Bonjour,
>> Je déterre ce fil.
>> J’ai besoin pour un utilisateur ordinaire de lui permettre un accès 
>> graphique à un hôte debian 12 sous gnome.
>> J’ai repensé à x2go, discuté dans ce fil de 2018.
> [...]
> 
> Avertissemnt désormais habituel: le réseau et la sécurité sont des domaines 
> dans lesquels je suis une vraie tanche, donc prudence
> 
> vu que tu élargis le spectre précédemment cantonné à vnc, si tu recherches 
> une simplicité de mise en oeuvre et d'emploi équivalente à Teamviewer 
> (logiciel et protocole propriétaires), tu peux peut-être regarder du côté de 
> Rustdesk (logiciel libre mais semble avoir créé son propre protocole(?), en 
> tout cas il n'est pas fait état de protocole standard genre vnc ou rdp)
> https://github.com/rustdesk/rustdesk
> 
> Moi qui suis un vrai blaireau pour tout ce genre de choses et qui dois 
> parfois assister une amie sous Windows depuis un Linux, j'utilise d'habitude 
> Teamviewer (simplissime donc à ma portée et à la sienne).
> 
> Je suis en train de tester des OS immuables (Fedora Silverblue et Opensuse 
> Micro-OS/Aeon) pour voir ce que c'est: le but est que le système 
> d'exploitation soit découplé des applications facilement installable par 
> l'utlisateur, prioritairement par flatpak (par l'app store Gnome-Software) 
> même si il y a des alternatives (mais c'est pas vraiment pour l'utilsateur 
> lambda, ces alternatives).
> Donc le but est de ne *pas* installer de paquets traditionnels et d'éviter 
> ces alternatives (Toolbox et autres) rebutantes pour l'utilisateur
> 
> Ben je viens de faire un essai entre mes deux machines virtuelles Silverblue 
> et Aeon où j'ai installé dans chacune un flatpak Rustdesk, ça a l'air de 
> marcher tout seul, sans aucune configuration. J'ai tenté de prendre le 
> contrôle de l'une à partir de l'autre, aucun problème: en termes de 
> fonctionnalités, je suis impressionné (vu que c'est du Flatpak, je 
> m'attendais à ce que ça ne marche pas ou mal à cause du bac à sable (ouais, 
> sur flatpak aussi, je suis une tanche)) .
> 
> En termes de sécurité, je ne sais pas ce que vaut Rustdesk: je suppose que vu 
> que c'est distribué sur les app-stores Google et F-Droid et que ça figure 
> dans des dépôts communautaires AUR (Archlinux) et Opensuse, ça ne doit pas 
> être une vérole totale au niveau sécurité, même si F-Droid semble signaler 
> qu'il y a du tracking dans l'appli, si j'ai bien suivi.

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

2023-07-14 Par sujet didier gaumet


Le 14/07/2023 à 10:34, RogerT a écrit :

Bonjour,

Je déterre ce fil.

J’ai besoin pour un utilisateur ordinaire de lui permettre un accès graphique à 
un hôte debian 12 sous gnome.
J’ai repensé à x2go, discuté dans ce fil de 2018.

[...]

Avertissemnt désormais habituel: le réseau et la sécurité sont des 
domaines dans lesquels je suis une vraie tanche, donc prudence


vu que tu élargis le spectre précédemment cantonné à vnc, si tu 
recherches une simplicité de mise en oeuvre et d'emploi équivalente à 
Teamviewer (logiciel et protocole propriétaires), tu peux peut-être 
regarder du côté de Rustdesk (logiciel libre mais semble avoir créé son 
propre protocole(?), en tout cas il n'est pas fait état de protocole 
standard genre vnc ou rdp)

https://github.com/rustdesk/rustdesk

Moi qui suis un vrai blaireau pour tout ce genre de choses et qui dois 
parfois assister une amie sous Windows depuis un Linux, j'utilise 
d'habitude Teamviewer (simplissime donc à ma portée et à la sienne).


Je suis en train de tester des OS immuables (Fedora Silverblue et 
Opensuse Micro-OS/Aeon) pour voir ce que c'est: le but est que le 
système d'exploitation soit découplé des applications facilement 
installable par l'utlisateur, prioritairement par flatpak (par l'app 
store Gnome-Software) même si il y a des alternatives (mais c'est pas 
vraiment pour l'utilsateur lambda, ces alternatives).
Donc le but est de ne *pas* installer de paquets traditionnels et 
d'éviter ces alternatives (Toolbox et autres) rebutantes pour l'utilisateur


Ben je viens de faire un essai entre mes deux machines virtuelles 
Silverblue et Aeon où j'ai installé dans chacune un flatpak Rustdesk, ça 
a l'air de marcher tout seul, sans aucune configuration. J'ai tenté de 
prendre le contrôle de l'une à partir de l'autre, aucun problème: en 
termes de fonctionnalités, je suis impressionné (vu que c'est du 
Flatpak, je m'attendais à ce que ça ne marche pas ou mal à cause du bac 
à sable (ouais, sur flatpak aussi, je suis une tanche)) .


En termes de sécurité, je ne sais pas ce que vaut Rustdesk: je suppose 
que vu que c'est distribué sur les app-stores Google et F-Droid et que 
ça figure dans des dépôts communautaires AUR (Archlinux) et Opensuse, ça 
ne doit pas être une vérole totale au niveau sécurité, même si F-Droid 
semble signaler qu'il y a du tracking dans l'appli, si j'ai bien suivi.

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris

2023-07-14 Par sujet Basile Starynkevitch




On 7/14/23 10:34, RogerT wrote:

Bonjour,

Je déterre ce fil.

J’ai besoin pour un utilisateur ordinaire de lui permettre un accès graphique à 
un hôte debian 12 sous gnome.
J’ai repensé à x2go, discuté dans ce fil de 2018.

J’ai été embêté par la configuration. Je n’ai pas réussi

Il semble que ce ne soit pas vraiment compatible avec gnome de debian 12.

Et installer un DE léger comme xfce4 va créer un rejet chez l’utilisateur 
habitué à VNC ou RDP.

Peut-on configurer x2go de manière à conserver un bureau gnome allégé de 
certains effets graphiques ? Et comment ?
Ou alors KDE qui semble un DE confortable très apprécié sous debian ?

PS : Quelle est la situation de x2go par rapport au duo xorg/wayland ? Puisque 
j’ai compris qu’on migrait progressivement vers wayland, plus sécurisé.



J'espère bien que non, Xorg n'est pas condamné dans Debian.

Et il peut être bien sécurisé, par une bonne configuration (et xhosts 
-). Ou un iptables. Je cite (en anglais) la page de man de Xorg:



NETWORK CONNECTIONS
   Xorg supports connections made using the following reliable 
byte-streams:


   Local
   On most platforms, the "Local" connection type is a 
UNIX-domain socket.  On  some  System  V  plat‐
   forms,  the "local" connection types also include STREAMS 
pipes, named pipes, and some other mecha‐
   nisms.  See the "LOCAL CONNECTIONS" section of X(7) for 
details.


   TCP/IP
   Xorg listens on port 6000+n, where n is the display 
number.  This connection type is  usually  disabled
   by  default, but may be enabled with the -listen option 
(see the Xserver(1) man page for de‐

   tails).



Enfin, la plupart des boites à outils graphiques actuelles en logiciel 
libre: Qt, GTK, FLTK, fox-toolkit supportent le protocole X11. Et la 
plupart sont faciles à compiler (depuis leur code source). Toutes ont 
des dévelopeurs et des contributions récentes.


Toutes ne vont pas migrer vers wayland.

--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: Accès distant graphique performant et sécurisé /avec écran-clavier-souris