англійськафранцузькийіспанська

Запуск серверів | Ubuntu > | Fedora > |


Значок OnWorks

xrsh - онлайн у хмарі

Запустіть xrsh у постачальника безкоштовного хостингу OnWorks через Ubuntu Online, Fedora Online, онлайн-емулятор Windows або онлайн-емулятор MAC OS

Це команда xrsh, яку можна запустити в постачальнику безкоштовного хостингу OnWorks за допомогою однієї з наших численних безкоштовних робочих станцій, таких як Ubuntu Online, Fedora Online, онлайн-емулятор Windows або онлайн-емулятор MAC OS

ПРОГРАМА:

ІМ'Я


xrsh - запуск програми X на віддаленій машині

СИНТАКСИС


xrsh [ -допомога ] [ -версія ] [ -l ім'я користувача ] [ -e rshprog ] [ -авт тип аутентифікації ] [ -екран
екран-# ] [ - пройти envlist ] [ -відлагоджувати ] [ -debug2 ] віддалений хост [ X-команда [ аргументація
... ] ]

ОПИС


Xrsh запускає задану команду X на віддаленому хості. Це створює середовище для цього
команду таким чином, щоб вона відображала свої вікна на екрані поточного сервера
поширення змінної середовища $DISPLAY. Якщо не вказано, клієнтом за замовчуванням є
xterm. Xrsh вибирає автоматично SSH(1) рш(1) remsh(1) або rcmd(1) для віддаленого виконання
команд, залежно від того, що доступне в середовищі O/S.

Xrsh автоматично обробляє аутентифікацію, тому віддаленому клієнту буде дозволено це зробити
відкрити вікна на сервері. Це робиться кількома різними способами залежно від значення
змінної середовища $XRSH_AUTH_TYPE або аргументу -auth.

За замовчуванням xrsh використовуватиме xhost, щоб дозволити віддаленому клієнту відкрити підключення до сервера.
Також можна вказати використовувати xauth для об’єднання локальних ключів у віддалений файл авторизації.
Або він може передати змінну середовища $XAUTHORITY віддаленому хосту, щоб поділитися а
звичайний файл повноважень, змонтований NFS. Також можна наказати нічого не робити у справі
де немає необхідності в явному дозволі.

Користувачі, які просто хочуть відкрити вікно віддаленого терміналу, можуть подивитися на додаткову команду xrsh,
xrlogin(1). Xrlogin використовує локально запущений xterm, щоб відкрити з’єднання rlogin з віддаленим
господар. Рішення про те, чи використовувати "xrsh host xterm" або "xrlogin host" має бути засноване
за кількома факторами. Якщо X недоступний на віддаленому хості або емуляторі локального терміналу
має кращі можливості, використовуйте xrlogin. Загалом, автор рекомендує використовувати xrsh over
xrlogin у більшості ситуацій.

Якщо командою для виконання на віддаленому хості є xterm, xrsh автоматично передає
-name аргумент для xterm зі значенням "xterm-hostname", де ім'я хоста є ім'ям
віддалений хост. Це дозволяє користувачеві вказувати ресурси в диспетчері ресурсів свого сервера
які є специфічними для xterms із даного хоста. Наприклад, цю функцію можна використовувати для
зробіть усі вікна xterm із даного віддаленого хоста одного кольору або використовуйте певний шрифт
або запустити в певному місці на екрані. Xrlogin передає той самий рядок, тому вони є
сумісні в цьому плані. Цю функцію можна змінити, вказавши власне -name
аргумент у командному рядку xterm.

Якщо команда для виконання на віддаленому хості є xterm, xrsh вказує, що це значення за замовчуванням
заголовком нового xterm буде "xterm@hostname", де ім'я хоста - це ім'я віддаленого пристрою
господар. Це також можна змінити, вказавши свій власний аргумент -title у xterm
command line.

Xrsh дуже обережний, щоб не залишити зайвих процесів ні на локальному, ні на віддаленому
машина чекає на вихід клієнта. У деяких віддалених середовищах (зокрема
деякі реалізації Sys V csh і rsh), це неможливо, і xrsh слід запускати як a
фонова команда.

ВАРІАНТИ


Зауважте, що параметри xrsh передують даній команді X та її аргументам.

-авт тип аутентифікації
Виберіть, який тип авторизації X (або контролю доступу) буде використовуватися.
Authtype може бути одним із "xhost", "xauth", "xhost-xterminal", "середовище" або
"жоден". За замовчуванням є xhost, але значення за замовчуванням можна встановити, встановивши значення
змінна середовища $XRSH_AUTH_TYPE.

Якщо вказано xhost і X-сервер запущено на локальній машині, xhost буде
запускатися локально, щоб дозволити віддаленому хосту відкрити з’єднання X. Якщо сервер є
на третьому хості (не на тому, де працює xrsh, і не на тому, де ви хочете
щоб запустити команду), rsh буде використовуватися для запуску xhost на хості сервера для авторизації
хост, на якому буде виконуватися команда.

Якщо вказано xauth, то xrsh об’єднає записи для сервера з файлу
локальний файл $XAUTHORITY у файл віддаленого хоста за допомогою rsh.

Тип аутентифікації xhost-xterminal призначений для використання людьми, які використовують термінали X. Якщо
використовується xhost-xterminal, то під час першого запуску xrsh він запускає xhost локально для
увімкнути віддалений хост для доступу. Це повинно працювати, оскільки (теоретично)
Перший раз він запускається на хості XDMCP для терміналу X. Відтоді
поширює ім’я цього хоста на всі віддалені хости через змінну середовища
$XHOST. У наступних викликах з віддалених хостів xrsh використовує rsh для підключення
хост $XHOST і запустіть xhost, щоб увімкнути нові віддалені хости.

Authtype "none" не виконує явної роботи для контролю доступу. Використовуйте це, якщо ви цього не робите
увімкнути контроль доступу або якщо ви використовуєте інший механізм контролю доступу.

Нарешті, тип authtype "середовище" автоматично поширює змінну середовища
$XAUTHORITY на віддалені хости, припускаючи, що це змонтоване розташування NFS
доступні з усіх хостів.

-відлагоджувати Зазвичай xrsh перенаправляє стандартний вхід і стандартний вихід на /dev/null у файлі an
намагання викликати вихід непотрібних процесів rshd і оболонки. В результаті користувач
зазвичай не бачить жодних помилок, які можуть виникнути (наприклад, "Дозвол відмовлено".
rsh). Якщо у вас виникли проблеми з тим, щоб xrsh працював із віддаленим хостом, спробуйте
за допомогою перемикача -debug, щоб перевірити, чи не генеруються якісь помилки.

-debug2
Цей перемикач змушує xrsh вмикати параметр -x в оболонці, щоб користувач міг
побачити кожну команду оболонки, яку виконує xrsh. Використовуйте цей сценарій лише в тому випадку
налагодження самого коду xrsh.

-допомога Роздрукуйте список аргументів на стандартний вихід.

-l ім'я користувача
Використовуйте перемикач -l, щоб указати інше ім’я користувача для входу через rsh on
віддалений хост.

-e rshprog
Перемикач -e можна використовувати для встановлення іншої програми віддаленої оболонки, наприклад ssh. The
за замовчуванням – remsh або rsh, залежно від вашої системи. Цей прапор замінює $XRSH_RSH.

- пройти envlist
Envlist — це рядок, розділений лапками, що називає довільний набір середовища
змінні для передачі в середовище оболонки на віддаленому хості. Якби хтось хотів
встановити $XRSH_AUTH_TYPE і $XAUTHORITY на віддалений хост, можна використовувати: -pass
"XRSH_AUTH_TYPE XAUTHORITY". Набір змінних середовища для передачі за замовчуванням може бути
встановити за допомогою змінної середовища $XRSH_ENVS_TO_PASS.

-екран екран-#
Вкажіть інший екран на сервері, на якому відображатиметься віддалений клієнт.

-версія
Роздрукуйте інформацію про версію та вийдіть.

НАВКОЛИШНЄ СЕРЕДОВИЩЕ


Змінні середовища XRSH_AUTH_TYPE і XRSH_ENVS_TO_PASS, які можна використовувати для встановлення
Значення перемикача за замовчуванням замінюються, якщо також вказано еквівалентний перемикач.

ВЛАДА
Змінна середовища $XAUTHORITY передається віддаленому хосту, якщо тип аутентифікації
визначений параметром -auth або $XRSH_AUTH_TYPE є "середовищем".

XRSH_AUTH_TYPE
Цю змінну середовища можна використовувати для визначення типу авторизації за замовчуванням
або контроль доступу. Значення, які можна встановити, збігаються зі значеннями для
аргумент -auth.

XRSH_RSH
Ця змінна може перевизначати програму віддаленої оболонки для використання, наприклад, ssh.

XRSH_RSH_ERRORS
Якщо для змінної середовища XRSH_RSH_ERRORS встановлено ім’я файлу, будь-який rsh
помилки з’являться в цьому файлі на віддаленому хості. Якщо ця змінна не встановлена,
повідомлення про помилки будуть відкидані, якщо не вказано перемикач -debug. (Примітка: ні
використовуйте ~ в назві файлу, тому що воно розгорнеться до ~ на локальному хості, але спробуйте помістити
помилки в цьому файлі на віддаленому хості.)

XRSH_ENVS_TO_PASS

ЗАГАЛЬНИЙ ПРОБЛЕМИ


Переконайтеся, що змінна середовища PATH на віддаленому хості встановлена ​​у вашому .cshrc або
.bashrc, щоб програми rsh мали до нього доступ. (/ Бен / ш та /bin/ksh користувачі мають труднощі
час тут, оскільки їхні оболонки не виконують жодних файлів ініціалізації під rsh. Ви можете використовувати
Змінна середовища XRSH_ENVS_TO_PASS для передачі змінної середовища PATH на віддалений
господар. За бажанням, у цьому випадку ви можете ввести повний шлях до xrsh. (Наприклад, віддалений xrsh-
хост /usr/bin/X11/xterm))

Переконайтеся, що ваша змінна середовища PATH на віддаленому хості містить каталог
містить програми X. Часто це /usr/bin/X11 або /usr/local/bin/X11.

Переконайтеся, що rsh налаштовано для роботи на віддаленому хості. Ви можете перевірити це шляхом
введіть: rsh remote-host echo '$PATH' Це підтвердить, що rsh працює, і покаже вам PATH
який буде використовуватися на віддаленому хості. Якщо ви отримаєте "Дозвол відмовлено". вам, мабуть, потрібно
для оновлення ~/.rhosts файл на віддаленому хості. Побачити рлогін(1).

ПРИКЛАДИ


xrsh йода
Запустіть xterm на хості yoda, який відображається на поточному X-сервері. Використовуйте xhost
для контролю доступу.

xrsh -auth xauth недобросовісний emacs
Запустіть emacs на аутсайдері хоста. Для цього об’єднайте записи авторизації xauth
сервера у файл повноважень на віддаленому хості.

xrsh -l mjd -auth none -pass XRSH_AUTH_TYPE -debug tigger xterm -fn 5x7
Запустіть xterm на хості tigger дуже дрібним шрифтом, поширте середовище
змінної $XRSH_AUTH_TYPE на віддалений хост, увійдіть на віддалений хост за допомогою ідентифікатора
"mjd", не виконуйте жодної конкретної авторизації та не перенаправляйте стандартний вихід/вивод помилок
до /dev/null, щоб я міг побачити будь-які помилки.

Використовуйте xrsh онлайн за допомогою служб onworks.net


Ad


Ad