Джефф Форсиер ( bitprophet ) написал:

(изменено описание, поэтому блоки кода были с отступом :))

2 ноября 2009 г., 09:35 по восточному поясному времени

Было бы здорово, если бы туннель поддерживал и наоборот. Это означает прослушивание на удаленном компьютере и перенаправление его на локальный хост/другой локально доступный хост: порт.

@munhitsu Я не уверен, что это конкретно для Fabric. Можете ли вы уточнить?

Представьте себе установку DMZ, которая не имеет исходящего доступа http/proxy.
Все развертывание проходит через структуру.

В таком случае мы могли бы использовать ткань для туннелирования локального прокси через ssh, чтобы быть временно доступными для хоста, который только что инициализировался в DMZ. Прямо сейчас я открываю отдельный ssh-туннель на второй консоли, чтобы ткань работала в «контексте» этого туннеля.

пример использования:

with rev_tunnel(local=8080, remote=8080):
    sudo("http_proxy='http://localhost:8080' apt-get install -y puppet")

Итак, я думаю, это довольно стандартная установка обратного туннеля, и ваше желание: Fabric заключается в том, чтобы он справлялся с выполнением туннеля, а вам приходилось запускать, например, local(ssh -R ...) .

Я снова и снова размышлял о том, действительно ли это стоит внедрять в ядро, но на самом деле имело бы приличный смысл поддерживать его в самой Fabric; другие решения являются хакерскими (например, какой-то поток или подпроцесс, выполняющий ssh — как это сделать правильно, убедитесь, что он выключается, когда Fab делает это, и т. д.), и я действительно вижу обоснованность варианта использования (совместное использование локального ресурсы с удаленным концом во время выполнения.)

Основным препятствием является то, что я не уверен, что библиотека SSH еще поддерживает это; нам придется это выяснить, и кто-то должен будет реализовать это, если это не так. (Однако я думаю, что это было бы хорошим дополнением к указанной библиотеке, а не укреплением вышеупомянутого обходного пути ssh -R .)

РЕДАКТИРОВАТЬ: № 38 обсуждает реализацию, исправление и тому подобное. Может быть, лучше всего закрыть это и просто отметить там, что при реализации должна быть возможность запуска с диспетчером контекста, если это возможно.

Я полностью согласен с тем, что реализовать его так, чтобы мы входили в контексты, покидали их или, что еще хуже, несколько уровней контекстов, сложно.

Что касается EDIT: все, что приближает нас к этой функциональности, является хорошей идеей.

Пока я оставлю это открытым, просто чтобы детализировать ситуацию. Назначил 1.4, чтобы не забыть. Скорее всего, я попытаюсь выбить это прямо, как я делаю № 38. Обновлю здесь, когда он будет в мастере, спасибо.

На самом деле это не так связано с № 38, как я думал, поскольку его изменения касаются исключительно шлюзования самого SSH-трафика, а не туннелирования дополнительных портов через SSH-соединение. Это потребует другого (или, по крайней мере, дополнительного) решения. Пока что качаюсь, извините :) (Значение: все еще открыто, просто не появится в 1.5.)

Недавно мне понадобилась эта функциональность для синхронизации с удаленным сервером rsync, чей порт недоступен напрямую, и я обнаружил, что в демо-коде paramiko forward.py есть пример кода, который я мог бы использовать, поэтому я придумал решение, которое хорошо сработало для меня, и я отправил его как патч для forward.py здесь: https://github.com/paramiko/paramiko/pull/504/

Мы могли бы добавить ForwardServer из этого патча и получить local_tunnel() , который просто возвращает экземпляр ForwardServer . Согласно рекомендации @bitprophet по запросу на включение, я буду работать над патчем для Fabric.

Я на самом деле не понял, но уже есть патч для local_tunnel() , хотя я не совсем уверен в его статусе. Что я должен делать?

@haridsv Если вы можете, протестируйте его и упомяните, что вы успешно использовали его в этом патче (# 939), это поможет, в противном случае просто наберитесь терпения :) спасибо!

Есть ли план решения этой проблемы? Есть два невыполненных запроса на вытягивание, которые вместе решают эту проблему, но они не были проверены? Как мы могли бы ускорить это?

939, № 1218

Я использовал код в # 1218 без проблем.

939 все еще находится в выпуске, я просто выкинул его из грядущей версии 1.11, потому что мне нужно было вырезать _некоторые_ вещи, но он получит приоритет для следующего функционального цикла. (И похоже, что № 1218 заменяет № 939, так что я, вероятно, в конечном итоге объединю это и укажу № 939 в журнале изменений.)