xrsh - Online na nuvem

PROGRAMA:

NOME

xrsh - inicia um programa X em uma máquina remota

SINOPSE

xrsh [ -Socorro ] [ -versão ] [ -l nome de usuário ] [ -e rshprog ] [ -auth tipo de autenticação ] [ -tela
tela-# ] [ -passar lista de envlist ] [ -depurar ] [ -debug2 ] hospedeiro remoto [ Comando X [ argumentos
... ] ]

DESCRIÇÃO

Xrsh executa o comando X fornecido em um host remoto. Ele configura o ambiente para isso
comando de modo que ele irá exibir suas janelas na tela do servidor atual por
propagando a variável de ambiente $ DISPLAY. Se não for especificado, o cliente padrão é
xterm. Xrsh seleciona automaticamente ssh(1) rsh(1) remsh(1) ou rcmd(1) para executar remotamente
comandos, dependendo do que está disponível no ambiente O / S.

O Xrsh lida automaticamente com a autenticação para que o cliente remoto tenha permissão para
abrir janelas no servidor. Ele faz isso de várias maneiras diferentes, dependendo do valor
da variável de ambiente $ XRSH_AUTH_TYPE ou do argumento -auth.

Por padrão, o xrsh usará o xhost para permitir que o cliente remoto abra uma conexão com o servidor.
Ele também pode ser instruído a usar o xauth para mesclar as chaves locais em um arquivo de autorização remota.
Ou pode passar a variável de ambiente $ XAUTHORITY para o host remoto para compartilhar um
arquivo de autoridade montado por NFS comum. Ele também pode ser direcionado para não fazer nada no caso
onde nenhuma autorização explícita é necessária.

Os usuários que desejam apenas uma janela de terminal remoto podem olhar para o comando irmão do xrsh,
xrlog(1). Xrlogin usa um xterm executado localmente para abrir uma conexão de rlogin para um remoto
hospedeiro. A decisão de usar "xrsh host xterm" ou "xrlogin host" deve ser baseada
em vários fatores. Se o X não estiver disponível no host remoto ou no emulador de terminal local
tem melhores recursos, use o xrlogin. Em geral, o autor recomenda usar xrsh em vez de
xrlogin na maioria das situações.

Se o comando a ser executado no host remoto for um xterm, o xrsh passa automaticamente o
-name argumento para xterm com um valor de "xterm-hostname" onde hostname é o nome do
hospedeiro remoto. Isso permite que o usuário especifique recursos no gerenciador de recursos de seu servidor
que são específicos para xterms de um determinado host. Por exemplo, este recurso pode ser usado para
faça com que todas as janelas xterm de um determinado host remoto tenham a mesma cor ou use uma fonte específica
ou inicie em um local específico da tela. Xrlogin passa a mesma string para que eles sejam
compatível a este respeito. Este recurso pode ser sobrescrito especificando seu próprio -name
argumento na linha de comando xterm.

Se o comando a ser executado no host remoto for um xterm, xrsh especifica que o padrão
o título do novo xterm será "xterm @ hostname" onde hostname é o nome do controle remoto
hospedeiro. Isso também pode ser sobrescrito especificando seu próprio argumento -title no xterm
linha de comando.

O Xrsh é muito cuidadoso para não deixar nenhum processo extra no local ou remoto
máquina esperando o cliente sair. Em alguns ambientes remotos (particularmente
algumas implementações Sys V de csh e rsh), isso é impossível e xrsh deve ser executado como um
comando de fundo.

OPÇÕES

Observe que as opções xrsh precedem o comando X fornecido e seus argumentos.

-auth tipo de autenticação
Escolha que tipo de autorização X (ou controle de acesso) será usado.
Authtype pode ser "xhost", "xauth", "xhost-xterminal", "environment" ou
"Nenhum". O padrão é xhost, mas o padrão pode ser definido definindo o valor de
a variável de ambiente $ XRSH_AUTH_TYPE.

Se xhost for especificado e o servidor X estiver rodando na máquina local, xhost irá
ser executado localmente para permitir que o host remoto abra uma conexão X. Se o servidor for
em um terceiro host (não aquele onde o xrsh está rodando e não aquele onde você deseja
para executar o comando), rsh será usado para executar xhost no host do servidor para autorizar
o host onde o comando será executado.

Se xauth for especificado, o xrsh irá mesclar as entradas para o servidor do
arquivo $ XAUTHORITY local no host remoto usando rsh.

O authtype xhost-xterminal deve ser usado por pessoas que usam terminais X. Se
xhost-xterminal é usado, então a primeira vez que o xrsh é executado, ele executa o xhost localmente para
habilite o host remoto para acesso. Isso deve funcionar, pois (teoricamente) o
a primeira vez que é executado no host XDMCP para o terminal X. A partir de então
propaga o nome desse host para todos os hosts remotos por meio da variável de ambiente
$ XHOST. Em invocações subsequentes de hosts remotos, xrsh usa rsh para se conectar
o host $ XHOST e execute o xhost para habilitar novos hosts remotos.

Authtype "nenhum" não faz nenhum trabalho explícito para controle de acesso. Use isto se você não
habilite o controle de acesso ou se você usar outro mecanismo para controle de acesso.

Finalmente, authtype "ambiente" propaga automaticamente a variável de ambiente
$ XAUTHORITY para hosts remotos, supondo que seja um local montado por NFS que pode
ser acessado de todos os hosts.

-depurar Normalmente o xrsh redireciona a entrada e a saída padrão para / dev / null em um
esforço para fazer com que os processos rshd e shell desnecessários sejam encerrados. Como resultado, o usuário
geralmente não consegue ver os erros que podem ocorrer (como uma "Permissão negada" de.
rsh). Se você está tendo problemas para fazer o xrsh funcionar com um host remoto, tente
fornecendo a opção -debug para ver se algum erro está sendo gerado.

-debug2
Esta opção faz com que o xrsh ative a opção -x no shell para que o usuário possa
veja cada comando shell executado por xrsh. Só use este script se você for
depurar o próprio código xrsh.

-Socorro Imprima a lista de argumentos na saída padrão.

-l nome de usuário
Use a opção -l para especificar um nome de usuário diferente para usar para fazer o login via rsh on
o host remoto.

-e rshprog
A opção -e pode ser usada para definir um programa de shell remoto diferente, por exemplo, ssh. o
o padrão é remsh ou rsh, dependendo do seu sistema. Este sinalizador substitui $ XRSH_RSH.

-passar lista de envlist
Envlist é uma string delimitada por aspas que nomeia um conjunto arbitrário de ambiente
variáveis ​​para passar para o ambiente do shell no host remoto. Se alguém quisesse
definir $ XRSH_AUTH_TYPE e $ XAUTHORITY para o host remoto, pode-se usar: -pass
"XRSH_AUTH_TYPE XAUTHORITY". Um conjunto padrão de variáveis ​​de ambiente para passar pode ser
definido usando a variável de ambiente $ XRSH_ENVS_TO_PASS.

-tela tela-#
Especifique uma tela diferente no servidor para exibir o cliente remoto.

-versão
Imprima as informações da versão e saia.

MEIO AMBIENTE

As variáveis ​​de ambiente XRSH_AUTH_TYPE e XRSH_ENVS_TO_PASS que podem ser usadas para definir
os padrões da chave são substituídos se a chave equivalente também for especificada.

XAUTORIDADE
A variável de ambiente $ XAUTHORITY é passada para o host remoto se o authtype
especificado por -auth ou $ XRSH_AUTH_TYPE é "ambiente".

XRSH_AUTH_TYPE
Esta variável de ambiente pode ser usada para especificar o tipo padrão de autorização
ou controle de acesso. Os valores para os quais ele pode ser definido são iguais aos valores para o
argumento -auth.

XRSH_RSH
Esta variável pode redefinir o programa de shell remoto a ser usado, por exemplo, ssh.

XRSH_RSH_ERRORS
Se a variável de ambiente XRSH_RSH_ERRORS for definida como o nome de um arquivo, qualquer rsh
erros aparecerão naquele arquivo no host remoto. Se essa variável não estiver definida,
as mensagens de erro serão descartadas, a menos que a opção -debug seja fornecida. (Nota: não
use ~ no nome do arquivo porque ele se expandirá para ~ no host local, mas tente colocar
os erros nesse arquivo no host remoto.)

XRSH_ENVS_TO_PASS

COMUM PROBLEMAS

Certifique-se de que sua variável de ambiente PATH no host remoto esteja definida em seu .cshrc ou
.bashrc para que os programas rsh tenham acesso a ele. (/ Bin / sh e / bin / ksh usuários têm um difícil
time time aqui, já que seus shells não executam nenhum arquivo init sob rsh. Você pode usar o
Variável de ambiente XRSH_ENVS_TO_PASS para passar a variável de ambiente PATH para o remoto
hospedeiro. Opcionalmente, você pode digitar um caminho completo para xrsh nesse caso. (Por exemplo, xrsh remote-
host / usr / bin / X11 / xterm))

Certifique-se de que sua variável de ambiente PATH no host remoto inclui o diretório
contendo os programas X. Geralmente é / usr / bin / X11 ou / usr / local / bin / X11.

Certifique-se de ter o rsh configurado para funcionar no host remoto. Você pode testar isso
digitando: rsh remote-host echo '$ PATH' Isso irá provar que rsh funciona e mostrar o PATH
que será usado no host remoto. Se você receber "Permissão negada". você provavelmente precisa
para atualizar o seu ~ / .rhosts arquivo no host remoto. Ver login(1).

EXEMPLOS

xrsh yoda
Inicie um xterm no host yoda que será exibido no servidor X atual. Use xhost
para controle de acesso.

xrsh -auth xauth azarão emacs
Inicie um emacs no host underdog. Mesclar entradas de autorização xauth para este
servidor no arquivo de autoridade no host remoto.

xrsh -l mjd -auth nenhum -pass XRSH_AUTH_TYPE -debug tigger xterm -fn 5x7
Inicie um xterm no host tigger em uma fonte muito pequena, propague o ambiente
variável $ XRSH_AUTH_TYPE para o host remoto, faça login no host remoto usando o id
"mjd", não faça nenhuma autorização específica e não redirecione a saída padrão / erro
para / dev / null para que eu possa ver os erros.

Use xrsh online usando serviços onworks.net