اتصالات SSH في Fabric 2+ عبر وسيط SOCKS

تنتقل أوامر Fabric البعيدة عبر SSH. ولتمرير اتصال SSH هذا عبر خادم SOCKS، امنح Fabric موصلًا يتحدث SOCKS ويعيد تدفق بايتات الوجهة.

تقبل واجهة Connection التي ظهرت في Fabric 2 سلسلة أوامر كقيمة gateway. ويستخدم Fabric تلك السلسلة كـ ProxyCommand. مع وجود nc متوافق مع OpenBSD ويدعم خيارات الوسيط، يمكن أن يكون الإعداد كما يلي:

from fabric import Connection

connection = Connection(
    "app.example.net",
    user="deploy",
    gateway="nc -X 5 -x proxy.example.net:1080 %h %p",
)

يستخدم هذا المثال منفذ SSH المعتاد، 22. يختار -X 5 في الموصل SOCKS5، بينما يحدد -x عنوان الوسيط. ويوفر العنصران البديلان للمضيف والمنفذ وجهة SSH. بالنسبة إلى وجهة SSH عامة، يمكن لنقطة نهاية غير موثقة من قائمة وسطاء SOCKS5 أن تملأ عنوان الوسيط إذا كانت تسمح بتلك الوجهة وذلك المنفذ. اضبط الأمر باستخدام خيارات الموصل الفعلي المثبت على الجهاز؛ فليس كل برنامج يحمل الاسم nc يعرض الواجهة نفسها.

يعمل الموصل محليًا، حيث يعمل Fabric. ولا يحتاج خادم التطبيق إلى تلك الأداة المساعدة لمجرد أنه وجهة SSH. وبعد إنشاء التدفق، لا يزال Fabric يجري تفاوض SSH ويصادق على حساب deploy على app.example.net. وأي مصادقة يطلبها خادم SOCKS تخص الموصل ويجب أن يدعمها.

يمكن لـ Fabric أيضًا قراءة ProxyCommand من إعداد SSH. وقد يكون ذلك مناسبًا عندما تستخدم عدة أدوات SSH المسار نفسه. استخدم تعريف بوابة واحدًا مقصودًا للاتصال، بدلًا من الجمع بين بوابة على شكل أمر وبوابة مضيف قفز منفصلة للوجهة نفسها.

عندما يكون الوسيط خادم SSH

كائن Connection في Fabric عندما يُقدَّم كـ gateway يعني شيئًا مختلفًا: يتصل Fabric ببوابة SSH تلك ويطلب قناة إلى المضيف النهائي. استخدم هذا الشكل لمضيف قفز SSH. فمستمع SOCKS ليس خادم SSH، ولذلك يحتاج إلى الموصل على شكل أمر أعلاه.

لهذا الاختيار في النقل حد واضح أيضًا. فهو يوجّه اتصال SSH الخاص بـ Fabric. أما الأمر الذي يُنفَّذ على المضيف البعيد ثم ينزّل مستودعًا أو حزمة فإنه ينشئ اتصالًا صادرًا جديدًا من ذلك المضيف، وفق إعداد الوسيط الخاص بذلك البرنامج.