xrsh - En ligne dans le Cloud

PROGRAMME:

Nom

xrsh - démarre un programme X sur une machine distante

SYNOPSIS

xrsh [ -Aide ] [ -version ] [ -l Nom d'utilisateur ] [ -e rshprog ] [ -auth type d'autorisation ] [ -écran
filtrer-# ] [ -passer liste d'env ] [ -déboguer ] [ -debug2 ] hôte-distant [ X-commande [ arguments
] ]

DESCRIPTION

Xrsh exécute la commande X donnée sur un hôte distant. Il crée l'environnement pour cela
commande telle qu'elle affichera ses fenêtres sur l'écran du serveur courant en
propageant la variable d'environnement $DISPLAY. S'il n'est pas spécifié, le client par défaut est
xterm. Xrsh sélectionne automatiquement ssh(1), rsh(1), remuer(1) ou cmd(1) pour exécuter à distance
commandes, en fonction de ce qui est disponible dans l'environnement du système d'exploitation.

Xrsh gère automatiquement l'authentification afin que le client distant soit autorisé à
ouvrir des fenêtres sur le serveur. Il le fait de plusieurs manières différentes selon la valeur
de la variable d'environnement $XRSH_AUTH_TYPE ou de l'argument -auth.

Par défaut, xrsh utilisera xhost pour permettre au client distant d'ouvrir une connexion serveur.
Il peut également être dit d'utiliser xauth pour fusionner les clés locales dans un fichier d'autorisation distant.
Ou il peut passer la variable d'environnement $XAUTHORITY à l'hôte distant afin de partager un
fichier d'autorité commun monté NFS. Il peut également être ordonné de ne rien faire dans le cas
où aucune autorisation explicite n'est nécessaire.

Les utilisateurs qui veulent juste une fenêtre de terminal distant peuvent regarder la commande sœur de xrsh,
connexion xr(1). Xrlogin utilise un xterm exécuté localement pour ouvrir une connexion rlogin à une télécommande
hôte. La décision d'utiliser "xrsh host xterm" ou "xrlogin host" doit être basée
sur plusieurs facteurs. Si X n'est pas disponible sur l'hôte distant ou l'émulateur de terminal local
a de meilleures fonctionnalités, utilisez xrlogin. En général, l'auteur recommande d'utiliser xrsh plutôt que
xrlogin dans la plupart des situations.

Si la commande à exécuter sur l'hôte distant est un xterm, xrsh passe automatiquement le
-name argument à xterm avec une valeur de "xterm-hostname" où hostname est le nom du
hôte distant. Cela permet à l'utilisateur de spécifier des ressources dans le gestionnaire de ressources de leur serveur
qui sont spécifiques aux xterms d'un hôte donné. Par exemple, cette fonction peut être utilisée pour
faire en sorte que toutes les fenêtres xterm d'un hôte distant donné soient de la même couleur ou utilisent une police spécifique
ou démarrer à un endroit précis de l'écran. Xrlogin passe la même chaîne donc ils sont
compatibles à cet égard. Cette fonctionnalité peut être remplacée en spécifiant votre propre nom
argument sur la ligne de commande xterm.

Si la commande à exécuter sur l'hôte distant est un xterm, xrsh spécifie que la valeur par défaut
le titre du nouveau xterm sera "xterm@hostname" où hostname est le nom de la télécommande
hôte. Cela peut également être remplacé en spécifiant votre propre argument -title sur le xterm
ligne de commande.

Xrsh fait très attention à ne laisser aucun processus supplémentaire sur le local ou à distance
machine attendant que le client sorte. Dans certains environnements éloignés (en particulier
certaines implémentations Sys V de csh et rsh), c'est impossible et xrsh doit être exécuté en tant que
commande d'arrière-plan.

OPTIONS

Notez que les options xrsh précèdent la commande X donnée et ses arguments.

-auth type d'autorisation
Choisissez quel type d'autorisation X (ou de contrôle d'accès) va être utilisé.
Le type d'authentification peut être "xhost", "xauth", "xhost-xterminal", "environment" ou
"rien". La valeur par défaut est xhost, mais la valeur par défaut peut être définie en définissant la valeur de
la variable d'environnement $XRSH_AUTH_TYPE.

Si xhost est spécifié et que le serveur X s'exécute sur la machine locale, xhost
être exécuté localement pour permettre à l'hôte distant d'ouvrir une connexion X. Si le serveur est
sur un troisième hôte (pas celui où xrsh s'exécute et pas celui où vous souhaitez
pour exécuter la commande), rsh sera utilisé pour exécuter xhost sur le serveur hôte pour autoriser
l'hôte sur lequel la commande sera exécutée.

Si xauth est spécifié, alors xrsh fusionnera les entrées pour le serveur à partir du
local $XAUTHORITY dans celui de l'hôte distant à l'aide de rsh.

Le authtype xhost-xterminal est destiné à être utilisé par des personnes utilisant des terminaux X. Si
xhost-xterminal est utilisé, puis la première fois que xrsh est exécuté, il exécute xhost localement pour
activer l'hôte distant pour l'accès. Cela devrait fonctionner puisque (théoriquement) le
la première fois qu'il est exécuté, c'est sur l'hôte XDMCP pour le terminal X. A partir de là
propage le nom de cet hôte à tous les hôtes distants via la variable d'environnement
$XHTE. Dans les appels suivants à partir d'hôtes distants, xrsh utilise rsh pour se connecter à
l'hôte $XHOST et exécutez xhost pour activer de nouveaux hôtes distants.

Authtype "aucun" ne fait aucun travail explicite pour le contrôle d'accès. Utilisez ceci si vous ne le faites pas
activer le contrôle d'accès ou si vous utilisez un autre mécanisme de contrôle d'accès.

Enfin, authtype "environment" propage automatiquement la variable d'environnement
$XAUTHORITY aux hôtes distants, en supposant qu'il s'agit d'un emplacement monté NFS qui peut
accessible depuis tous les hôtes.

-déboguer Normalement, xrsh redirige l'entrée standard et la sortie standard vers /dev/null dans un
effort pour provoquer la fermeture des processus rshd et shell inutiles. En conséquence, l'utilisateur
ne peut généralement pas voir les erreurs qui pourraient se produire (comme une "Autorisation refusée." de
rsh). Si vous rencontrez des difficultés pour faire fonctionner xrsh avec un hôte distant, essayez
en donnant le commutateur -debug pour voir si des erreurs sont générées.

-debug2
Ce commutateur force xrsh à activer l'option -x dans le shell afin que l'utilisateur puisse
voir chaque commande shell exécutée par xrsh. N'utilisez ce script que si vous êtes
débogage du code xrsh lui-même.

-Aide Imprimez la liste des arguments sur la sortie standard.

-l Nom d'utilisateur
Utilisez le commutateur -l pour spécifier un nom d'utilisateur différent à utiliser pour la connexion via rsh sur
l'hôte distant.

-e rshprog
Le commutateur -e peut être utilisé pour définir un autre programme shell distant, par exemple ssh. Les
la valeur par défaut est remsh ou rsh, selon votre système. Cet indicateur remplace $XRSH_RSH.

-passer liste d'env
Envlist est une chaîne délimitée par des guillemets nommant un ensemble arbitraire d'environnement
variables à transmettre à l'environnement shell sur l'hôte distant. Si l'on voulait
définissez $XRSH_AUTH_TYPE et $XAUTHORITY sur l'hôte distant, on pourrait utiliser : -pass
"XRSH_AUTH_TYPE XAUTHORITY". Un ensemble par défaut de variables d'environnement à transmettre peut être
défini à l'aide de la variable d'environnement $XRSH_ENVS_TO_PASS.

-écran filtrer-#
Spécifiez un écran différent sur le serveur sur lequel afficher le client distant.

-version
Imprimez les informations de version et quittez.

ENVIRONNEMENT

Les variables d'environnement XRSH_AUTH_TYPE et XRSH_ENVS_TO_PASS qui peuvent être utilisées pour définir
les valeurs par défaut du commutateur sont remplacées si le commutateur équivalent est également spécifié.

XAUTORITÉ
La variable d'environnement $XAUTHORITY est transmise à l'hôte distant si le type d'authentification
spécifié par -auth ou $XRSH_AUTH_TYPE est "environment".

XRSH_AUTH_TYPE
Cette variable d'environnement peut être utilisée pour spécifier le type d'autorisation par défaut
ou contrôle d'accès. Les valeurs auxquelles il peut être défini sont les mêmes que les valeurs pour le
argument -auth.

XRSH_RSH
Cette variable peut redéfinir le programme shell distant à utiliser, par exemple ssh.

XRSH_RSH_ERRORS
Si la variable d'environnement XRSH_RSH_ERRORS est définie sur le nom d'un fichier, tout rsh
des erreurs apparaîtront dans ce fichier sur l'hôte distant. Si cette variable n'est pas définie,
les messages d'erreur seront supprimés à moins que le commutateur -debug ne soit spécifié. (Remarque : ne
utilisez ~ dans le nom de fichier car il se développera en ~ sur l'hôte local, mais essayez de mettre
les erreurs dans ce fichier sur l'hôte distant.)

XRSH_ENVS_TO_PASS

COMMUNE PROBLÈMES

Assurez-vous que votre variable d'environnement PATH sur l'hôte distant est définie dans votre fichier .cshrc ou
.bashrc pour que les programmes rsh y aient accès. (/ Bin / sh et les utilisateurs de /bin/ksh ont du mal
time time ici puisque leurs shells n'exécutent aucun fichier d'initialisation sous rsh. Vous pouvez utiliser le
Variable d'environnement XRSH_ENVS_TO_PASS pour passer la variable d'environnement PATH à la télécommande
hôte. Vous pouvez éventuellement saisir un chemin complet vers xrsh dans ce cas. (Par exemple, télécommande xrsh-
hôte /usr/bin/X11/xterm))

Assurez-vous que votre variable d'environnement PATH sur l'hôte distant inclut le répertoire
contenant les programmes X. Il s'agit souvent de /usr/bin/X11 ou /usr/local/bin/X11.

Assurez-vous que rsh est configuré pour fonctionner sur l'hôte distant. Vous pouvez tester cela en
en tapant : rsh remote-host echo '$PATH' Cela prouvera que rsh fonctionne et vous montrera le PATH
qui sera utilisé sur l'hôte distant. Si vous obtenez « Autorisation refusée ». vous avez probablement besoin
pour mettre à jour votre ~/.rhosts fichier sur l'hôte distant. Voir connexion (1).

EXEMPLES

xrsh yoda
Démarrez un xterm sur le yoda hôte qui s'affiche sur le serveur X actuel. Utiliser xhost
pour le contrôle d'accès.

xrsh -auth xauth outsider emacs
Démarrez un emacs sur l'outsider de l'hôte. Fusionner les entrées d'autorisation xauth pour cela
serveur dans le fichier d'autorité sur l'hôte distant.

xrsh -l mjd -auth aucun -pass XRSH_AUTH_TYPE -debug tigger xterm -fn 5x7
Démarrer un xterm sur l'hôte tigger dans une très petite police, propager l'environnement
variable $XRSH_AUTH_TYPE à l'hôte distant, connectez-vous à l'hôte distant en utilisant l'identifiant
"mjd", ne faites aucune autorisation spécifique et ne redirigez pas la sortie standard/erreur
à /dev/null pour que je puisse voir les erreurs.

Utiliser xrsh en ligne à l'aide des services onworks.net