Sessions de console RDP et VMWare et ILO imbriquées: répétition des touches et latence

17

Je travaille sur une installation de serveur distant entièrement via ILO (mais cela s'applique également aux sessions de console IPMI et VMWare). En raison de l'application logicielle et de l'environnement, mon accès est limité à un serveur Windows auquel je dois accéder via RDP. Le passage de ce système au serveur cible s'effectue via HP ILO2 ou ILO3.

J'essaie d'exécuter une installation CentOS dans un environnement où je ne peux pas utiliser un système de déploiement entièrement automatisé. Je le fais via le mode texte, mais les frappes se répètent au hasard et il est difficile de sélectionner les options d'installation appropriées. Par exemple:

ks=http://all.yourbase.org/kickstart/ks.cfg

finit par ressembler à:

ks====httttttp://allll..yourbaseee.....org/kicksstart/ks.cccfg

Je fais cela en utilisant le client RDP de Microsoft (sur Mac et Windows). J'ai également remarqué cela avant lors de l'exécution d'installations ou de travaux à distance dans des sessions imbriquées.

entrez la description de l'image ici

Y a-t-il une bonne solution pour cela, ou est-ce simplement une fonction du ou des protocoles?

ewwhite
la source
3
Je m'attendrais à ce que des administrateurs possédant un bon nombre de systèmes distants ou des consultants qui ont besoin de se connecter à distance à une variété de systèmes en aient fait l'expérience.
ewwhite
2
Je déteste dire cela, mais moi aussi j'ai ce problème régulièrement et je n'ai pas encore trouvé de solution, désolé.
Chopper3
3
Cela ne résout pas votre problème, mais si votre point de terminaison distant est une console VMware, ce document de VMware suggère une solution.
larsks
Ce problème de frappe répété ne se produit-il qu'entre la session RDP et la console ilo?
Rqomey
@Rqomey Je ne sais pas à quelle couche le problème fait surface. Le résultat est le même. Supposons quelque chose comme: Mac -> Session Windows RDP exécutant une connexion à la console cliente ILO ou vSphere.
ewwhite

Réponses:

10

Alors qu'une connexion SSH transmet les principaux traits , une connexion HP BIT transmet les principaux états . Chaque fois que vous appuyez sur une touche, le serveur reçoit des événements KeyDown et KeyUp distincts. Les frappes répétées résultent lorsque l'événement KeyUp est reçu en retard.

Les deux raisons les plus probables de la réception tardive de l'événement KeyUp sont les suivantes:

  1. Problèmes de congestion / performances du réseau.
  2. Mauvaise performance du système client initiant la connexion BIT. Si le client est une machine virtuelle, le système hôte sous-jacent est-il surchargé ou la machine virtuelle dispose-t-elle de ressources de mémoire / CPU inadéquates?

Si la cause profonde ne peut être résolue:

  1. Le problème de répétition des touches peut être résolu en désactivant un paramètre ILO2 appelé "Key Up / Down". Cela entraînera l'OIT2 à transmettre des frappes au lieu d'états clés. Malheureusement, ce paramètre a été supprimé de l'OIT3.
  2. Si le système d'exploitation cible est Linux, vous pouvez peut-être contourner le problème en redirigeant la console vers ttyS0et en utilisant une session Virtual Serial Port (VSP) au lieu d'une console virtuelle. Cela éliminera le problème Key Up / Down, car les connexions série transmettent les frappes au lieu des événements Key Up / Down.
  3. Il peut être utile d'ajuster le taux de répétition des touches et / ou de désactiver entièrement la répétition automatique sur le système cible. Je reconnais que cela peut ne pas être facile à réaliser, selon la gravité du problème de répétition clé.
  4. Étant donné que vous utilisez un Mac comme poste de travail local, il peut être utile d'essayer de coller des commandes complètes dans votre client Mac RDP à l'aide de Command-V. Je ne sais pas s'il s'agit d'une solution de contournement viable, mais cela pourrait avoir un effet intéressant. J'ai souvent apprécié de travailler sur des machines Windows distantes à partir d'un poste de travail Mac, notamment parce que les combinaisons commande-raccourci locales continuent de fonctionner de manière prévisible.

Les références:

Skyhawk
la source
Avez-vous une idée du côté de la console distante VMWare? Je vois la même chose là-bas.
ewwhite
2
Il est assez facile de contourner dans VMware simplement en changeant le délai de répétition des clés à 2 secondes, mais il n'y a aucun moyen de le faire globalement (le fichier .vmx doit être changé pour chaque VM): kb.vmware.com/selfservice/microsites /…
Skyhawk
1
Dans le même esprit, il peut être utile d'imbriquer ENCORE UNE AUTRE session Windows. Le RDP sur un serveur sur le même segment de réseau que l'iLO peut réduire suffisamment votre délai entre les touches pour ne pas être un problème.
longneck
5

Cela ressemble à un problème avec le protocole. J'ai quelque peu réduit le problème en utilisant Ericom Blaze comme transport RDP pour le serveur central à partir duquel je me connecte; par exemple "boîte de saut".

Autres choses:

J'essaie d'éviter plusieurs sessions imbriquées.

J'utilise VMWare Fusion avec Windows 7 sur mon Mac pour me permettre d'utiliser le RDP natif de Windows dans certains cas.

C'est à peu près tout ce que je peux voir pour l'instant.

ewwhite
la source
2

vous devez modifier le fichier .vmx pour ajouter la ligne suivante:

keyboard.typematicMinDelay = "2000000"

il enlève le "rebond".

Avec ma version de vmware, je dois faire ce changement lorsque la machine virtuelle est en panne. Je comprends que cela peut être fait à partir d'une fenêtre d'édition, mais je n'ai pas pu trouver cet endroit.

Bob Leder
la source
1

Le problème se produit-il avec votre connexion au rdp (pouvez-vous taper correctement le bloc-notes?) Ou entre le RDP et l'iLO)?

Si entre RDP et iLO (je sais que vous l'avez déjà fait)

  1. L'utilisation de la console distante Java était presque impossible. J'ai trouvé que si j'utilisais la "console distante" (elle peut s'appeler .Net), cela a entraîné une amélioration massive. La latence était moindre, la latence n'était pas nerveuse et les frappes répétées et perdues ne se sont pas produites.

  2. Démarrez le live cd, installez le serveur openssh et utilisez ssh pour vous connecter. Faites notre installation sur ssh (si la connexion est mauvaise, utilisez également l'écran.

Si entre vous et RDP:

Utilisez freenx ou vnc réglé sur une bande passante faible pour votre boîte Windows. Cela devrait au moins nettoyer les frappes. La connexion au RDP est-elle correcte (est-ce là que les problèmes de frappe se produisent?

Si les deux: Écrivez les commandes dans un bloc-notes, puis copiez et collez si vous le pouvez, j'espère que cela fonctionnera mieux que de taper.

Rqomey
la source
J'utilise définitivement la console .NET.
ewwhite
1

La première chose critique à retenir est de désactiver la répétition des touches sur tout le traitement de vos frappes, y compris sur la machine virtuelle ou la session RDP par laquelle vous vous connectez, ainsi que la machine hôte de niveau supérieur. Cela ne fixe pas la machine cible finale, mais cela améliore grandement la situation.

Quant à la machine cible:

Il existe des rapports selon lesquels l'utilisation de ssh pour se connecter au port SSH de HP iLO évite les problèmes de répétition clés, mais je n'ai pas pu utiliser cette méthode car mon hôte (online.net) n'a pas laissé le port 22 traverser son pare-feu iLO. Mais si vous avez accès au port SSH d'iLO (probablement 22), cela semble être l'approche la plus simple.

J'ai essayé d'utiliser une unité systemd pour définir le taux de répétition du clavier et le temps de retard au démarrage:

# Note that kbdrate only affects existing keyboards, and HP iLO attaches a new
# USB keyboard when you connect, so you may have to reboot (with the iLO console
# attached) to get the keyboard delay and repeat rate to take effect.

[Unit]
Description=Set longer delay time for key repeat

[Service]
Type=oneshot
RemainAfterExit=yes
StandardInput=tty
StandardOutput=tty
ExecStart=/sbin/kbdrate -d 1000 -r 2

[Install]
WantedBy=multi-user.target
WantedBy=rescue.target

(Assurez-vous que /sbin/kbdratec'est là que vous avez kbdrate. Écrivez à /etc/systemd/systemd/slower-keyboard-repeat.serviceet systemctl daemon-reload && systemctl enable slower-keyboard-repeat.service)

mais comme mentionné dans le commentaire, ce n'était qu'un succès partiel car il fallait un redémarrage pour définir le taux de répétition sur le nouveau clavier que iLO attache. Mais c'est suffisant si vous êtes d'accord pour redémarrer la machine.

Finalement, j'ai fini par patcher le noyau Linux pour changer le taux de répétition et le temps de retard par défaut sur tous les claviers:

From 78c32f539b89bf385985bea47a7058a540d31da0 Mon Sep 17 00:00:00 2001
From: Ivan Kozik <[email protected]>
Date: Thu, 30 Mar 2017 13:31:17 +0000
Subject: [PATCH] Increase the default keyboard repeat delay from 250ms to
 1000ms and repeat rate from 1000/33 Hz to 1000/500 Hz to avoid unintentional
 repeated keystrokes when using remote consoles such as HP iLO over
 high-latency links.  These consoles (HP iLO included) often transmit key
 states (up/down) instead of keystrokes, making it impossible to even enter a
 password and log in.

Fixing this in the kernel avoids problems with kbdrate where the parameters
passed to kbdrate don't apply to the new keyboards attached by HP iLO.
---
 drivers/input/input.c          | 2 +-
 drivers/input/keyboard/atkbd.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/input/input.c b/drivers/input/input.c
index 880605959aa6..a195af2d062a 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -2126,7 +2126,7 @@ int input_register_device(struct input_dev *dev)
     * is handled by the driver itself and we don't do it in input.c.
     */
    if (!dev->rep[REP_DELAY] && !dev->rep[REP_PERIOD])
-       input_enable_softrepeat(dev, 250, 33);
+       input_enable_softrepeat(dev, 1000, 500);

    if (!dev->getkeycode)
        dev->getkeycode = input_default_getkeycode;
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index ec876b5b1382..9dd04c2215b3 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -1096,8 +1096,8 @@ static void atkbd_set_device_attrs(struct atkbd *atkbd)
            BIT_MASK(LED_MUTE) | BIT_MASK(LED_MISC);

    if (!atkbd->softrepeat) {
-       input_dev->rep[REP_DELAY] = 250;
-       input_dev->rep[REP_PERIOD] = 33;
+       input_dev->rep[REP_DELAY] = 1000;
+       input_dev->rep[REP_PERIOD] = 500;
    }

    input_dev->mscbit[0] = atkbd->softraw ? BIT_MASK(MSC_SCAN) :
-- 
2.11.0

et cela a résolu le problème pour moi.

Ivan Kozik
la source
0

Je sais que vous avez dit que vous étiez limité, mais je ne vois rien de mieux que: installer VNC ou TeamViewer, au moins juste pour faire la partie critique de votre installation.

La deuxième solution consiste à utiliser un proxy de transfert de type Media Center pour les messages d'entrée, vous devez donc connecter un deuxième clavier à votre ordinateur et, à l'aide de HID, transférer uniquement ce clavier via TCP / SOAP au serveur. Mais comme cela implique d'installer des démons logiciels sur le serveur, vous pourriez aussi bien commencer par VNC.

Je n'ai jamais rencontré de frappes répétées, mais j'obtiens un retard de souris important lorsque je travaille avec VMware sur RDP, lorsque le système d'exploitation invité n'a pas VMware Tools chargé.

La dernière option que j'ai, si aucune ci-dessus ne convient, est de contacter le support Microsoft et de signaler la résolution qu'ils vous donnent ici .. comme un ticket open source.

servermanfail
la source
0

D'après mon expérience, cela m'a aidé si j'essaie d'oublier tout ce que j'ai appris sur la frappe tactile et d'essayer de frapper les touches une par une et très, très rapidement. Utilisez de préférence un seul doigt pour ne pas être trop à l'aise et commencer à taper trop vite. Il vous permet également de vous concentrer pour essayer d'appuyer rapidement sur la touche . Tout cela peut ressembler à une blague, mais j'ai constaté que mon majeur droit (je suis droitier) est de loin le plus capable de pousser les touches rapidement.

Et bien sûr, j'essaie de rendre SSH opérationnel le plus rapidement possible après cela. Si elles sont trop restreintes pour être autorisées à le faire ... aïe.

Essayez également d'utiliser les différentes consoles. Normalement, la version Java serait la pire, mais si vous rencontrez des problèmes avec la version .NET, vous voudrez peut-être essayer Java. Soyez juste prêt à ce que le plugin java puisse planter votre navigateur (ce n'est qu'un problème avec iLO 2; iLO 3 est passé d'un plugin à une application de démarrage Web).

chutz
la source
C'est une solution approximative. Une idée pourquoi cela se produit?
ewwhite
1
L'appeler "une solution" est assez généreux. Non, je ne sais pas pourquoi cela se produit, mais j'ai toujours blâmé le protocole de connexion à distance. Maintenant que vous m'y avez fait réfléchir, j'ai eu cette autre idée ... avez-vous déjà essayé de reproduire cela avec le clavier à l'écran à partir des applications Windows Accessibility? J'ai le sentiment persistant que l'application du clavier à l'écran pourrait fonctionner parfaitement.
chutz
J'ai essayé l'approche du clavier à l'écran avec un problème VMWare vCloud cette semaine. La console pop-up était en conflit avec le clavier à l'écran pour la mise au point, ils n'étaient donc pas compatibles.
ewwhite