Надо тут было одному клиенту установить сайт на тестирование. Причем сайт такой, что на свой хостинг положить было нельзя по некоторым причинам, надо было ставить в офисе. Кроме того, надо было не только поставить, но еще и периодически обновлять там код.
По ходу дела начались всякие сетевые трудности (файрволы там, и все такое), и в процессе их обхода родилась совершенно мозголомная конфигурация, которая меня очень забавляет.
Изначальная идея была очень простая. Поскольку весь код проекта лежит в Subversion у меня на softwaremaniacs.org, достаточно заходить на клиентский сервер ssh'ем и обновлять из этого репозитория код.
Но этот вариант не прошел, потому что сервер у клиента стоит за файрволом и просто так зайти на него не получится. После недолгих совещаний с тамошним админом мне сделали ssh'ный вход на машину gateway'я, видную из сети, с которой я уже должен был попадать внутрь. Но не тут-то было! Гейт этот видимо как-то умно настроен, что не принимает ssh'ных коннектов от машин без своего публичного имени хоста. А это как раз мой случай, потому что сижу я на диалапном соединении (в силу причин историко-политического характера).
Но эта проблема разрешилась просто, двойной вход превратился в тройной: я сначала захожу на свой сервер в сети, с него на гейт, а с него — на машину с проектом.
Все было замечательно до тех пор, пока у клиента не поменялась политика в сети, и с проектовой машины перестал видится интернет. То есть не только на нее не попасть, но и с нее теперь тоже. Причем, произошло это как-то тихо, без всяких предупреждений, поэтому это открытие я сделал тогда, когда админ, который мог бы это как-то снова открыть, был недоступен, а мне зачем-то (сейчас уже не помню) надо было обновить код прямо сейчас!
После обязательно в таких стрессовых ситуациях стаканчика чая я вспомнил, что протокол ssh, которым я через хм... тернии захожу на проектную машину, умеет такую замечательную вещь, как туннель.
Туннель — это способность ssh соединять две машины, которые друг-друга напрямую не видят, через третью, причем по любому протоколу. Происходит это так, что клиент соединяется с промежуточной машиной по ssh и передает ей адрес нужного удаленного сервера и номер порта на нем, после чего ssh-сервер на промежуточной машине начинает передавать через себя данные, приходящие от клиента на указанный порт сервера, и возвращать клиенту то, что ответил сервер. А природа этих данных его не интересует.
Фактически человек, знающий пароль на промежуточный сервер, может создать себе эдакую временную обходную дырку на сервер за файрволом.
А это как раз то, что мне надо: проектная машина не видит softwaremaniacs.org, но видит гейт в своей внутренней сети. А гейт видит softwaremaniacs.org. А на гейт у меня есть ssh-вход.
Итак, зайдя через свое тройное соединение на проектную машину, я делаю еще одно ssh-соединение на гейт, но теперь уже снабжаю его туннелем, который позволит видеть проектной машине softwaremaniacs.org по протоколу subversion'а.
Но тут возникает загвоздка. После всех этих соединений у меня открытый shell оказывается на машине гейта, а мне там совершенно нечего делать. Мне надо быть на проектной машине, где я буду писать всякие командочки для апдейта кода и перезапуска апача. Поэтому прямо с гейта я делаю еще один вход обратно на проектную машину.
Честно скажу, когда я пытаюсь представить по какому маршруту до моего ноутбука доходят буковки, которые печатает subversion на softwaremaniacs.org, у меня начинает слегка кружиться голова :-). Но самый ураган, это когда я на проектной машине обновляю не свой код, а Django. Из-за того, что на их сервере репозиторий доступен только по HTTP на 80 порту, мне приходится еще там в середине процесса sudo делать, потому что туннели на маленьких портах только root'у разрешается делать :-).
Из всего этого я сделал пару примечательных выводов:
- любому специалисту неплохо обладать навыками в смежных областях: программисту быть чуть-чуть админом, чуть-чуть дизайнером, чуть-чуть хакером, архитектором, менеджером...
- древние текстовые юниксовые протоколы придумывали не дураки, и по чистой функциональности они еще очень долго будут впереди удаленных графических клиентов
И есть у меня один небольшой вопрос: не знает ли кто, как автоматизировать ввод паролей на всех этих шеллных подключениях? А то там в разных местах и логины разные, и пароли, жутко муторно ради одного апдейта все это руками вбивать.
Комментарии: 7 (особо ценных: 1)
действително твистер %)
Автоматизировать ввод паролей - можно на каждой машине сгенерировать по паре public/private rsa ключей и скормить их ssh. Если ключ генерировать без passphrase то пароль она спрашивать не будет.
А вообще наверное надо не не в твистер с серверами играть а попросить админа настроить нат и файервол нормально. Даже с точки зрения политики безопасности это будет правильнее, чем прокладывать тунели.
Забавно :)
Я бы сделал это все немного по другому. Если гейт - машина, с которой видно все остальное, то я бы запустил ssh к ней с ключиком -D 8989 и поигрался таким образом, чтобы соединения к какому-либо локальному порту перебрасывались на порт 8989 гейта - это будет socks proxy, а ssh на локальной машине запускать из-под sockscap в винде или socksify в unix (с последним придется повозиться)
ssh-keygen -t rsa
cat ~/.ssh/id_rsa.pub | ssh user@host "mkdir .ssh; cat >>