Назад | Перейти на главную страницу

как использовать временный профиль при подключении ssh к удаленному серверу

Я часто вхожу на удаленные серверы с помощью ssh, чтобы выполнять стандартные административные операции. У меня есть локальный bashrc / vimrc и различные другие файлы конфигурации, которые я хотел бы получить удаленно. Часто я вхожу на эти удаленные серверы только один раз, поэтому я не хочу оставлять копию своего профиля на этих ящиках, некоторые из которых находятся на сайтах клиентов.

Я действительно подумал о том, чтобы сделать какой-нибудь хакер, чтобы удаленный сервер смонтировал fusefs webDAV или какой-либо другой способ смонтировать удаленную файловую систему на удаленный сервер на время сеанса. Однако это вызывает проблемы, если удаленная система не имеет необходимых пакетов или отключена от брандмауэра.

Есть ли какие-либо хорошие решения этой проблемы, которые совместимы с кросс-дистрибутивом, ну, например, с самой последней версией Fedora / RHEL / ubuntu / debian / CentOS и не мешают и не замедляют процесс входа в систему?

[РЕДАКТИРОВАТЬ]

Я предполагаю, что одно из других соображений заключается в том, что я могу войти в систему с учетной записью другого пользователя, поэтому я не хочу вносить какие-либо постоянные изменения в профиль. В идеале я бы просто использовал какой-то временный профиль для сеанса, а затем отбросил его при выходе из системы. это могло быть попаданием на Луну на территории палки ;-)

Ты можешь использовать ssh -t для запуска сценариев установки, затем оболочки, затем сценариев очистки. ssh -t позволяет запускать команды, но по-прежнему запускать одну или несколько оболочек посередине и правильно выделять терминал

Ваш сценарий установки может включать wget'ing / curl'ing / scp'ing временного домашнего каталога во что-то вроде $HOME/tmphome, затем запустите такой сценарий, чтобы запустить там оболочку:

#!/bin/sh

HOME="$HOME/tmphome"
cd "$HOME"
bash --login

Это должно довольно хорошо изолировать ваши rc-файлы от tmphome, а ssh -t пропустит пользовательский bashrc. Пока ваша среда легкая, копирование не займет много времени.

Ваша команда может выглядеть примерно так ssh -t user@host 'wget http://server/tmphome.tar.gz && tar -zxvf tmphome.tar.gz && rm tmphome.tar.gz && tmphome/shell.sh'

Почему бы вам не использовать распределенную систему контроля версий, такую ​​как git, для хранения файлов конфигурации? Это то, что я делаю, и это работает как шарм.

Мое решение этой проблемы состояло в том, чтобы научиться чувствовать себя комфортно с общими стандартами и запрограммировать макросы для пальцев на включение (очень немногих) дополнительных функций, без которых я просто не могу жить.

Проблема в том, что для машин, на которые вы попадете только для быстрого решения проблемы, время, необходимое для настройки вашей среды, вероятно, превысит время, необходимое для фактического устранения проблемы. Проблема несколько усугубляется вашим заявленным желанием оставить систему без ваших пользовательских настроек, когда вы закончите - замечательное чувство, так как меня укусил администратор, который не мог жить без режима vi на (общий) корневая оболочка и строка чтения. Было чертовски сложно что-либо сделать, когда вы привыкли к сочетаниям клавиш по умолчанию.

В последнее время мне довольно повезло; всякий раз, когда я отвечал за действия с серверами, они были «моими» в том смысле, что у меня есть постоянная административная ответственность / полномочия, и я просто использовал свой инструмент автоматизации системы, чтобы предварительно настроить машины, как Они мне нравятся.

Для временного доступа, если бы я вернулся к нему и отчаянно нуждался в моем собственном маленьком окружении, я был бы склонен разработать два сценария оболочки:

  • Тот, который я запустил до того, как я вошел на новый сервер, который поместил все мои желаемые файлы конфигурации (сохраняя копию того, что было раньше) и, возможно, установленные пакеты (подходящие для данного дистрибутива) или, по крайней мере, сообщил о чего не хватало, чтобы я знал, к чему меня приставят на удаленном сервере, когда я начал над ним работать;
  • Другой, который очистит все до состояния, которое было до того, как я запустил первый скрипт - удаление пакетов (вам нужно убедиться, что вы знаете, что вы установили, а не то, что уже было там до того, как вы туда попали) , и переместите исходные файлы конфигурации на место.

Для написания и отладки этих сценариев потребовалось бы изрядное количество работы, особенно с учетом недостатков различных дистрибутивов. Вот почему я просто научился ладить с разумными настройками по умолчанию для любой легкой работы - это хорошая привычка, если вы в будущем станете частью команды и вам нужно разделить среду с другими людьми ( Мистер vi mode bash shell, я смотрю на ты).

Многие администраторы unix «старой школы» хранят свои общие настройки в cvs репозиторий. При первом входе в новую систему они cvs checkout этот репозиторий и настройте их .bashrc сделать cvs update чтобы получить текущие настройки, затем позвоните в ~/repo/bin/setup (где repo это где cvs checkout целевой, и setup скрипт, который добавляет /repo/bin к их $PATH устанавливает aliases и т. д.).

Этот метод оставляет ваши настройки в системе, хотя во многих случаях это может не быть большой проблемой.

Вы, конечно, можете заменить svn или git для cvs.