Re: [Comm] удалённая поддержка (was: thunar smb support)

[Michael Shigorin <mike@osdn.org.ua>]

On Tue, Dec 08, 2009 at 08:39:09PM +0300, Timur Batyrshin wrote:
> > > Главная проблема не в том, чтоб обеспечить доступ юзеров к
> > > шарам, а в том, чтобы в случае поломки внутри $HOME мне не
> > > пришлось идти/ехать до рабочей станции, что не всегда возможно.
> > > Админы в филиалах не обладают достаточной квалификацией, чтобы
> > > сделать что-то более-менее сложное, если вообще есть.
> > Это совсем другой вопрос, решать его следует вне зависимости
> > от DE -- пробросом localhost:22 на преконфигурированный сервер
> > доступа по кнопке или в режиме аварийной загрузки.
> Подробнее можно?

В последнем внедренческом проекте надеялся наработать
инфраструктуру, но с кризисом он ближе к схлопнулся по части
разработки.

Вот письмо по теме:

--- Date: Fri, 17 Aug 2007 15:49:05 +0300
Есть ряд соображений по мерам, которые может иметь смысл
предпринять для улучшения поддерживаемости **********,
желательно до развёртывания за пределами Киева.

--- 0 ---

Проблемы с текущим состоянием (которое суть пилот по
функциональности, не призванный решить их все сразу):

- возможность недоступности системы удалённо по ssh вследствие
  "серого" или фильтрованного IP-адреса (например, CDMA или
  некоторые локальные сети);
- сложность сопоставления номера *** и IP;
- затруднения с анализом состояния множества развёрнутых систем;
- заметные затраты времени на забивание зависящих от номера
  *** параметров (почта, ключи, доступ на ***...).

Соображения таковы:

+ предлагается создание сервисной инфраструктуры на стороне
  центрального офиса с тем, чтобы было возможно инициировать
  проброс портов для SSH и VNC со стороны клиента (по ssh и
  публичному ключу без открытия шелла на удалённой стороне);

+ предлагается включить номер *** в параметры настройки
  и по возможности стандартизировать использование такового
  в рамках серверной части ******** (как-то почтовые адреса);

+ предлагается автоматизировать настройку принтеров.

--- 1 ---

На базе первого возможно реализовать подобную схему отработки
нештатных ситуаций при работоспособности ОС и наличии связи:

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

- жмёт кнопку "обратиться в техподдержку";

- происходит инициирование ssh-соединения с support-хостом,
  куда пробрасываются нужные порты;
                                   
- на хосте срабатывает сигнализация, предоставляющая каким-либо
  образом персоналу поддержки сведения о том, что получено 
  обращение и для доступа на предположительно проблемную систему
  можно воспльзоваться указанными портами (в идеале -- добавить
  кнопочки "сходить по ssh" и "сходить по vnc" в ростер по
  проблемам некоей программы, которая запущена на десктопе 
  поддержки);

- инженер получает возможность с минимальными затратами времени
  добраться на удалённую систему или в текстовом, или в
  графическом режиме и приступить к диагностике и решению  
  проблемы.

Наверное, возможно интегрироваться и с тикетовыми системамои
вроде Request Tracker.

--- 2 ---

[дальше про другие детали автоматизации развёртывания]

А в предыдущих случаях действительно была "локалка в эквиваленте"
-- либо развесистая, но в одном месте, либо WAN/VPN.
Т.е. проблемы добраться до хоста снаружи не было, поскольку
sshd доступен и спецпользователь с ключиком и sudo разлит.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/