Docker

یک نمونهٔ خوب، کنسول یا کانال ورودی/خروجی استانداردی است که به یک کانتینر یا سیستم مجازی‌سازی منتهی می‌شود. Docker نمونه‌ای آشناست. اگر بخواهید یک کانتینر Docker را راه‌اندازی کرده و یک پوسته را مستقیماً درون آن اجرا کنید، ممکن است دستوری مانند زیر بنویسید:

docker run -i -t some:image

که به شما اجازه می‌دهد یک نشست پوستهٔ منفرد را درون کانتینر، در همان ترمینالی که Docker را از آن اجرا کرده‌اید، به کار بیندازید.

فرض کنید ترجیح می‌دهید چندین نشست پوسته را به‌طور هم‌زمان در همان کانتینر اجرا کنید (شاید برای اینکه یکی از آن‌ها بتواند از ابزارهای اشکال‌زدایی برای بررسی کار دیگری استفاده کند). همچنین شاید بخواهید برنامه‌ای را داخل کانتینر اجرا کنید که به دسترسی کامل آن به شبکه‌تان اعتماد ندارید، اما حاضرید اجازه دهید یک یا دو اتصال شبکهٔ مشخص را برقرار کند، درست مانند اتصالی که با فوروارد پورت SSH راه‌اندازی می‌کنید.

در این حالت، می‌توانید گزینهٔ -t را از خط فرمان Docker حذف کنید (که به معنی «تخصیص یک دستگاه ترمینال» است)، و به آن بگویید که psusan را درون کانتینر اجرا کند:

docker run -i some:image /some/path/to/psusan

(البته باید مطمئن شوید که psusan در جایی درون ایمیج کانتینر نصب شده باشد.)

اگر این کار را از خط فرمان پوسته انجام دهید، خط اعلانی (banner) شبیه به این خواهید دید:

SSHCONNECTION@putty.projects.tartarus.org-2.0-PSUSAN_Release_0.75

که فایدهٔ چندانی ندارد، جز اینکه نشان می‌دهد psusan با موفقیت راه‌اندازی شده است.

برای برقراری ارتباط مفید و کاربردی با این سرور، می‌توانید یک نشست ذخیره‌شدهٔ PuTTY را به صورت زیر تنظیم کنید:

•

پروتکل را روی «Bare ssh-connection» (پروتکل psusan) قرار دهید.

•

در کادر hostname چیزی بنویسید. این عبارت در عنوان پنجرهٔ PuTTY (در صورت اجرای گرافیکی PuTTY) نمایش داده می‌شود، بنابراین شاید بخواهید چیزی بنویسید که ماهیت پنجره را به شما یادآوری کند. اگر نظر خاصی ندارید، عبارتی عمومی مانند «dummy» کفایت می‌کند.

•

در برگهٔ پیکربندی «Proxy»، نوع پراکسی را روی «Local» تنظیم کرده و دستور «docker run» بالا را در کادر متنی «Telnet command, or local proxy command» وارد نمایید.

•

در برگهٔ پیکربندی «SSH»، به احتمال زیاد مایل خواهید بود قابلیت اشتراک اتصال (connection sharing) را فعال کنید. (به ادامه مراجعه نمایید.)

این کار ترتیبی می‌دهد که PuTTY هنگام راه‌اندازی، به جای برقراری یک اتصال شبکه‌ای، دستور Docker بالا را اجرا کند و با استفاده از پروتکل شبیه به SSH در psusan، با آن دستور ارتباط برقرار نماید.

نتیجه این است که همچنان یک نشست پوسته در بستر کانتینر Docker خواهید داشت، اما این بار با تمام امکانات رفاهی SSH همراه است. اگر اشتراک اتصال را نیز در برگهٔ پیکربندی «SSH» فعال کرده باشید، گزینهٔ «Duplicate Session» یک پوستهٔ دوم در همان کانتینر Docker به شما می‌دهد (به جای یک پوستهٔ اصلی در نمونه‌ای جداگانه). می‌توانید در حین اجرای کانتینر، با استفاده از PSCP یا PSFTP فایل‌ها را به داخل و خارج آن منتقل کنید؛ پورت‌های شبکه، برنامه‌های گرافیکی X11 یا کارگزار SSH را به داخل کانتینر فوروارد نمایید.

مسلماً راه دیگر برای انجام همهٔ این کارها، اجرای پروتکل کامل SSH روی همان کانال است. اما این روش نیازمند پیکربندی بیشتری است: باید یک کلید میزبان SSH برای کانتینر بسازید، آن را در کلاینت بپذیرید، و با باقی ماندن آن در حافظهٔ موقت کلیدهای میزبان کلاینت پس از دور انداخته شدن کانتینر سر و کله بزنید. همچنین باید اطلاعات ورود به سیستم را در کانتینر تنظیم کنید: یا گذرواژه‌ای تعیین کرده و آن را در کلاینت وارد کنید، یا کلید عمومی SSH موجود خود را در آن کپی نمایید. تمام این دردسرها غیرضروری است، زیرا این‌ها اقدامات احتیاطی‌ای هستند که هنگام عبور اتصال بین دو سیستم از یک شبکهٔ ناامن و متخاصم الزامی می‌شوند. در این حالت، اتصال تنها از طریق کانال IPC هسته عبور می‌کند که رسیدن آن به مقصد درست تضمین‌شده است؛ بنابراین چنین اقدامات ایمنی مضاعف و زائد بوده و تنها موجب دشواری کار می‌شوند.

User-mode Linux

User-mode Linux (یا UML) نوع دیگری از کانتینر است که می‌توانید به همین شیوه با آن ارتباط برقرار کنید. در ادامه یک مثال عملی کوچک آورده شده است.

ساده‌ترین روش برای اجرای UML استفاده از نوع سیستم فایل «hostfs» آن است تا به هستهٔ مهمان دسترسی به همان سیستم فایل مجازیِ موجود در میزبان داده شود. برای نمونه، خط فرمانی مانند این یک اعلان پوسته در نمونه‌ای از UML در اختیارتان می‌گذارد که از سیستم فایل فعلی شما استفاده می‌کند:

linux mem=512M rootfstype=hostfs rootflags=/ rw init=/bin/bash

اگر این دستور را در خط فرمان اجرا کنید (با فرض اینکه هستهٔ UML در مسیر شما با نام «linux» در دسترس باشد)، باید پیام‌های متعدد آغاز به کار هسته را مشاهده کنید که به دنبال آن یک اعلان پوسته شبیه به زیر ظاهر می‌شود:

root@(none):/#

برای تبدیل این مورد به یک نشست UML مبتنی بر psusan، باید خط فرمان را طوری ویرایش کنیم که به جای اجرای bash، برنامهٔ psusan را اجرا کند. اما اجرای مستقیم psusan به تنهایی کافی نیست، زیرا psusan به مقدار کمی پیکربندی اولیه، نظیر سوار بودن /proc نیاز دارد. بنابراین به جای آن، فرایند init را روی یک اسکریپت پوسته تنظیم می‌کنیم که کارهای لازم را انجام داده و سپس psusan را فراخوانی کند.

همچنین اجرای مستقیم psusan روی دستگاه کنسول UML ایدهٔ مناسبی نیست، زیرا در این صورت پروتکل دودویی psusan با پیام‌های متنی کنسول آمیخته می‌شود. بنابراین راه‌حل بهتر این است که کنسول UML را به خروجی خطای استاندارد فرایند linux هدایت کرده و ورودی و خروجی استاندارد آن را به یک درگاه سریال نگاشت کنیم. بدین ترتیب خط فرمان جایگزین UML ممکن است شبیه به این باشد:

linux mem=512M rootfstype=hostfs rootflags=/ rw \
    con=fd:2,fd:2 ssl0=fd:0,fd:1 init=/some/path/to/uml-psusan.sh

و اسکریپت راه‌اندازی uml-psusan.sh می‌تواند به این شکل باشد:

#!/bin/bash
# Set up vital pseudo-filesystems
mount -t proc none /proc
mount -t devpts none /dev/pts
# Redirect I/O to the serial port, but stderr to the console
exec 0<>/dev/ttyS0 1>&0 2>/dev/console
# Set the serial port into raw mode, to run a binary protocol
stty raw -echo
# Choose what shell you want to run inside psusan
export SHELL=/bin/bash
# Set up a default path
export PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
# And now run psusan over the serial port
exec /home/simon/src/putty/misc/psusan

اکنون یک نشست ذخیره‌شدهٔ PuTTY را مانند مثال Docker بالا تنظیم کنید. اساساً می‌خواهید از دستور linux بالا به عنوان دستور پراکسی محلی استفاده کنید. با این حال، ارزش دارد آن را درون setsid(1) قرار دهید؛ زیرا هنگام بسته شدن UML، تمام گروه فرایندی خود را می‌کشد. بنابراین بهتر است PuTTY جزئی از آن گروه نباشد تا فرصت داشته باشد خودش به‌طور تمیز بسته شود. در نتیجه احتمالاً در نهایت دستور پراکسی را چیزی شبیه به این تنظیم خواهید کرد:

setsid linux mem=512M rootfstype=hostfs rootflags=/ rw \
    con=fd:2,fd:2 ssl0=fd:0,fd:1 init=/some/path/to/uml-psusan.sh

همچنین ممکن است متوجه شوید که باید ترفند دور زدن باگی را که نشان می‌دهد سرور «داده‌های ارسال‌شده پیش از پیام خوشامدگویی‌اش را دور می‌اندازد» (Discards data sent before its greeting) فعال کنید، زیرا در غیر این صورت پیام آغازین پروتکل ارسالی PuTTY ممکن است در طول راه‌اندازی UML تصادفاً از بین برود. (باگ دبیان شمارهٔ ۹۹۱۹۵۸ را ببینید.)

پس از انجام این کار، یک نشست PuTTY خواهید داشت که با اجرای آن یک نمونهٔ تمیز از UML راه‌اندازی می‌شود و (در صورت فعال بودن اشتراک اتصال) نمونه‌های بعدی از همان نشست مجدداً به همان نمونه متصل خواهند شد.

Windows Subsystem for Linux

در ویندوز، روش پیش‌فرض برای استفاده از WSL اجرای برنامهٔ wsl یا یکی از نام‌های مستعار آن در کنسول ویندوز است؛ چه با اجرای آن از یک خط فرمان موجود، و چه با استفاده از میانبری که آن را در یک کنسول جدید باز می‌کند. این کار یک محیط ترمینال لینوکس اما درون پنجرهٔ کنسول ویندوز در اختیارتان می‌گذارد.

اگر ترجیح می‌دهید با استفاده از PuTTY به عنوان ترمینال با همان محیط تعامل داشته باشید (مثلاً اگر میانبرهای موشواره در PuTTY برای کپی و جای‌گذاری را ترجیح می‌دهید)، می‌توانید با نصب psusan در محیط لینوکس و سپس ایجاد یک نشست ذخیره‌شدهٔ PuTTY که با آن ارتباط برقرار می‌کند، این کار را انجام دهید. یک راه جالب برای این کار، استفاده از نام توزیع WSL به عنوان «نام میزبان» (host name) است:

•

دستور پراکسی محلی را روی «wsl -d %host /usr/local/bin/psusan» (یا هر جا که psusan را در سیستم لینوکس نصب کرده‌اید) تنظیم کنید

•

نام یک توزیع خاص WSL را در کادر نام میزبان (host name) وارد کنید. (برای مثال، اگر دبیان WSL را به روش استاندارد از فروشگاه ویندوز نصب کرده‌اید، این نام صرفاً «Debian» خواهد بود.)

•

مانند معمول، پروتکل را روی «Bare ssh-connection» قرار دهید.

مانند تمامی مثال‌های دیگر در اینجا، این روش نیز به شما اجازه می‌دهد پورت‌ها را به داخل و خارج محیط WSL فوروارد کنید (مثلاً در دسترس قرار دادن یک سرویس شبکه در WSL2 از طریق NAT داخلی هایپروایزر)، Pageant را به درون آن فوروارد نمایید، و موارد دیگر.

Cygwin

یک محیط یونیکس‌مانند دیگر در ویندوز Cygwin است. این محیط همراه با برنامهٔ ترمینال گرافیکی اختصاصی خود، یعنی mintty (که بر حسب اتفاق، مشتقی از PuTTY است) عرضه می‌شود؛ اما اگر ترجیح می‌دهید از خود PuTTY برای تعامل با نشست‌های ترمینال Cygwin استفاده کنید، psusan می‌تواند کمک کند.

برای این کار، ابتدا باید ابزارهای یونیکسیِ PuTTY را درون Cygwin بسازید (از طریق روش متداول cmake). سپس، فایل اجرایی psusan.exe حاصل را در دایرکتوری /bin در Cygwin کپی کنید. (برای اینکه برنامه‌های غیر-Cygwin بتوانند آن را اجرا کنند، حتماً باید در این دایرکتوری باشد؛ در غیر این صورت هنگام راه‌اندازی قادر به یافتن DLL مربوط به Cygwin نخواهد بود.)

سپس نشست ذخیره‌شدهٔ PuTTY خود را به این صورت تنظیم کنید:

•

دستور پراکسی محلی را طوری تنظیم کنید که psusan.exe را از طریق مسیر واقعی ویندوزی آن اجرا کند. همچنین ممکن است بخواهید گزینهٔ --sessiondir را اضافه کنید تا نشست‌های پوسته در دایرکتوری خانگی Cygwin شما شروع شوند. برای مثال، می‌توانید از دستور «c:\cygwin64\bin\psusan.exe --sessiondir /home/simon» استفاده نمایید (مسیر فایل و نام کاربری را متناسب با سیستم خود تغییر دهید).

•

هر چیزی را که مایلید در کادر host name وارد کنید؛ «Cygwin» احتمالاً انتخاب خوبی است

•

مانند معمول، پروتکل را روی «Bare ssh-connection» قرار دهید.

فوروارد پورت در این حالت کاربرد چندانی ندارد، زیرا Cygwin فضای پورت شبکه را با ماشین میزبان به اشتراک می‌گذارد. اما فعال کردن فوروارد کارگزار (agent forwarding) مفید است، زیرا کلاینت خط فرمانی SSH در Cygwin می‌تواند بدون هیچ پیکربندی اضافی با Pageant ارتباط برقرار کند.

schroot

مثال دیگری از یک محیط کانتینرمانند، چیدمان سیستم فایل جایگزینی است که توسط schroot(1) ایجاد می‌شود.

schroot برنامهٔ دیگری است که به‌طور پیش‌فرض یک نشست پوستهٔ تعاملی را در ترمینالی که از آن اجرا شده به کار می‌اندازد. اما باز هم می‌توانید با راه‌اندازی یک نشست ذخیره‌شدهٔ PuTTY که دستور پراکسی محلی آن شبیه به زیر باشد، اتصالی از طریق psusan به محیط schroot برقرار نمایید:

schroot -c chroot-name /some/path/to/psusan

بسته به اینکه چه مقدار از محیط chroot از محیط اصلی شما کپی شده است، ممکن است متوجه شوید که این کار اموری نظیر اجرای برنامه‌های X11 را درون chroot که پنجره‌هایی روی نمایشگر اصلی X شما باز می‌کنند یا انتقال فایل‌ها به داخل و خارج chroot را ساده‌تر می‌سازد.

بین فضاهای نام شبکه (Between network namespaces)

اگر چندین فضای نام شبکه (network namespaces) را با پیکربندی‌های مختلف TCP/IP روی یک سیستم لینوکس راه‌اندازی کرده‌اید، در صورتی که psusan را به عنوان یک کاربر غیر ریشه (non-root) در فضای نامِ غیرپیش‌فرضِ خود اجرا کنید و به اتصالات روی یک سوکت دامنهٔ یونیکس گوش فرا دهد، می‌تواند یک درگاه ارتباطیِ مناسب و بدون نیاز به دسترسی‌های ویژه میان آن‌ها باشد.

اگر این کار را انجام دهید، کنترلی راحت روی این موضوع خواهید داشت که کدام اتصالات شبکهٔ خروجی شما از کدام پیکربندی TCP/IP استفاده کنند: می‌توانید در صورت نیاز به اجرای دستورهایی مانند ping، از PuTTY برای اجرای یک نشست پوسته در بستر فضای نام دیگر استفاده کنید، یا اینکه فوروارد پورت‌های جداگانه یا حتی یک سرور SOCKS راه‌اندازی نمایید تا فرایندهایی که در یک فضای نام اجرا می‌شوند بتوانند اتصالات شبکهٔ خود را از طریق فضای نام دیگر برقرار کنند.

برای این کاربرد، احتمالاً راحت‌ترین کار استفاده از گزینهٔ --listen در psusan است که باعث می‌شود برنامه به عنوان یک سرور اجرا شده و روی یک سوکت دامنهٔ یونیکس به اتصالات ورودی گوش دهد. سپس می‌توانید آن نام سوکت را در فیلد پیکربندی host name در PuTTY وارد کنید (و همچنان گزینهٔ پروتکل «Bare ssh-connection» را انتخاب نمایید) تا مانند یک کلاینت SSH به آن سوکت متصل شوید.

به شرطی که سوکت دامنهٔ یونیکس داخل دایرکتوری‌ای باشد که تنها کاربر مورد نظر به آن دسترسی دارد، این اطمینان حاصل می‌شود که احراز هویت به‌طور ضمنی توسط هستهٔ لینوکس صورت می‌گیرد.

بین شناسه‌های کاربری از طریق GNU userv (Between user ids, via GNU userv)

اگر از چندین شناسهٔ کاربری روی یک ماشین استفاده می‌کنید، مثلاً برای اهداف جداسازی امتیازات (اجرای برنامه‌ای با قابلیت اطمینان کمتر و با دسترسی‌های محدود به تمام دارایی‌های شما)، در این صورت احتمالاً یک حساب کاربری «پیش‌فرض» یا دارای بالاترین امتیاز دارید که نشست ورود اصلی خود را در آن اجرا می‌کنید، و گاهی نیاز دارید که پوسته‌ای را در حسابی دیگر به کار بیندازید.

برنامهٔ psusan می‌تواند با استفاده از GNU userv(1) به عنوان بستر انتقال، به عنوان کانال دسترسی میان حساب‌ها به کار رود. در حسابی که می‌خواهید به آن دسترسی داشته باشید، یک بند پیکربندی userv شبیه به زیر بنویسید:

if (glob service psusan & glob calling-user my-main-account-name)
   reset
   execute /some/path/to/psusan
fi

این کار به حساب اصلی شما اجازه می‌دهد تا این دستور را اجرا کند:

userv my-sub-account-name psusan

و می‌توانید آن نام دستور را درست مانند بیشتر مثال‌های قبلی، به عنوان یک دستور پراکسی محلی در PuTTY پیکربندی کنید.

البته در حال حاضر راه‌های فراوانی برای دسترسی از یک حساب محلی به حسابی دیگر مانند sudo وجود دارد. یکی از مزایای این روش این است که هنگام تمایل به تغییر کنترل‌های دسترسی (مثلاً تغییر اینکه کدام حساب‌های شما به حسابی دیگر دسترسی داشته باشند) نیازی به دخالت مدیر سیستم ندارید: تا زمانی که از ابتدا روشی برای ورود به هر حساب داشته باشید و userv نصب باشد، می‌توانید بدون نیاز به ایجاد زحمت برای کاربر ریشه (root)، تغییرات پیکربندی بعدی را اعمال کنید.

مزیت دیگر این است که ممکن است انتقال فایل بین حساب‌ها را ساده‌تر کند. اگر از آن دسته افرادی هستید که دایرکتوری‌های خانگی خود را خصوصی نگه می‌دارند، کپی کردن یک فایل از یکی از حساب‌هایتان به دیگری تنها با استفاده از دستور cp دشوار خواهد بود، زیرا مکان مناسبی در یک حساب وجود ندارد که بتوانید فایل را در آن بگذارید تا حساب دیگر بتواند آن را بخواند. اما با psusan روی بستر userv، نیازی به هیچ بخش مشترکی از سیستم فایل ندارید: می‌توانید فایل‌ها را با scp بدون هیچ زحمتی جابه‌جا کنید.