نشر جيف فورسير ( bitprophet ):

(الوصف المعدل بحيث تم وضع مسافة بادئة لمقاطع التعليمات البرمجية :))

في 2009-11-02 الساعة 09:35 صباحًا بتوقيت شرق الولايات المتحدة

سيكون من الرائع أن يدعم النفق أيضًا العكس. بمعنى الاستماع على جهاز التحكم عن بُعد وإعادة توجيهه إلى مضيف محلي / مضيف محلي آخر متاح : المنفذ.

munhitsu لست متأكدًا من كيفية استخدام هذه الحالة لـ Fabric على وجه التحديد. هل يمكنك التفصيل؟

تخيل إعداد DMZ الذي لا يحتوي على وصول http / وكيل صادر.
النشر كله يمر من خلال النسيج.

في مثل هذه الحالة ، يمكننا استخدام النسيج لنقل الوكيل المحلي عبر ssh ، ليكون متاحًا مؤقتًا للمضيف الذي يتم توفيره للتو في DMZ. أقوم الآن بفتح نفق ssh منفصل على وحدة التحكم الثانية ، بحيث يعمل النسيج ضمن "سياق" هذا النفق.

مثال على الاستخدام:

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

حسنًا ، لذلك فهو إعداد نفق عكسي قياسي إلى حد ما بعد كل ما أعتقده ، ورغبتك هي: النسيج هو من أجل التعامل مع النفق مقابل الاضطرار إلى التشغيل على سبيل المثال local(ssh -R ...) .

ذهبت ذهابًا وإيابًا بشأن ما إذا كان هذا يستحق حقًا الدخول في جوهره ، ولكن من المنطقي حقًا أن يتم دعمه في Fabric المناسب ؛ الحلول الأخرى متطرفة (على سبيل المثال ، بعض سلاسل المحادثات أو العمليات الفرعية التي تعمل ssh - كيفية القيام بذلك بشكل جيد ، تأكد من إيقاف تشغيله عندما يقوم Fab بذلك ، وما إلى ذلك) وأنا أرى صلاحية حالة الاستخدام (المشاركة المحلية الموارد مع الطرف البعيد أثناء التنفيذ.)

العقبة الرئيسية هي أنني لست متأكدًا من أن SSH lib يدعم هذا حتى الآن ؛ سيتعين علينا معرفة ذلك وسيتعين على شخص ما تنفيذه إذا لم يحدث ذلك. (أعتقد أن هذا سيكون إضافة جيدة للمكتبة المذكورة ، مع ذلك ، مقابل ترسيخ الحل المذكور أعلاه ssh -R .)

تحرير: # 38 يناقش التنفيذ والترقيع وما شابه. قد يكون من الأفضل إغلاق هذا بالفعل ولاحظ ببساطة أنه عند التنفيذ ، يجب أن يكون من الممكن بدء التشغيل مع مدير السياق إن أمكن.

أوافق تمامًا على أن تطبيقه بحيث ندخل أو نغادر السياقات أو حتى مستويات متعددة من السياقات أسوأ أمر صعب.

فيما يتعلق بالتحرير: أي شيء يجعلنا أقرب إلى الحصول على هذه الوظيفة فكرة جيدة.

في الوقت الحالي سأترك هذا مفتوحًا ، فقط لإبقاء الأشياء محببة. عيّنه إلى 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 في سجل التغيير.)