دستورهای سطح سرور (Server-Level Commands)

اکثر دستورهای ovsdb-client با یک پایگاه‌دادهٔ منفرد کار می‌کنند، اما این دستورها بر کل یک سرور پایگاه‌داده اعمال می‌شوند.

list-dbs [server]

به server متصل می‌شود، فهرست پایگاه‌های دادهٔ شناخته‌شده را دریافت کرده و آن‌ها را در هر خط یکی چاپ می‌کند. این نام‌های پایگاه‌داده مواردی هستند که سایر دستورها می‌توانند برای database استفاده کنند.

دستورهای شمای پایگاه‌داده (Database Schema Commands)

این دستورها شما (schema) را از یک پایگاه‌داده دریافت کرده و آن یا بخشی از آن را چاپ می‌کنند.

get-schema [server] [database]

به server متصل می‌شود، شمای مربوط به database را دریافت کرده و آن را در قالب JSON چاپ می‌کند.

list-tables [server] [database]

به server متصل می‌شود، شمای مربوط به database را دریافت کرده و جدولی شامل نام هر جدول درون پایگاه‌داده را چاپ می‌کند.

list-columns [server] [database] table

به server متصل می‌شود، شمای مربوط به database را دریافت کرده و جدولی شامل نام و نوع هر ستون را چاپ می‌کند. اگر table مشخص شده باشد، تنها ستون‌های آن جدول فهرست می‌شوند؛ در غیر این صورت، جدول‌ها شامل ستون‌های تمام جدول‌ها خواهند بود.

دستورهای مدیریت نسخهٔ پایگاه‌داده (Database Version Management Commands)

یک شمای OVSDB دارای یک شماره نسخهٔ شما است، و یک پایگاه‌دادهٔ OVSDB نسخهٔ خاصی از یک شمای OVSDB را در خود جای داده است. این شماره‌های نسخه به صورت x.y.z هستند، مانند 1.2.3. پیاده‌سازی OVSDB طرح شماره‌گذاری نسخهٔ خاصی را تحمیل نمی‌کند، اما شماهایی که در پروژهٔ Open vSwitch مدیریت می‌شوند از رویکرد زیر استفاده می‌کنند. هرگاه شمای پایگاه‌داده به گونه‌ای تغییر کند که با نسخه‌های پیشین سازگار نباشد (مانند حذف یک ستون یا یک جدول)، x افزایش می‌یابد (و y و z به 0 بازنشانی می‌شوند). هنگامی که شمای پایگاه‌داده به روشی سازگار با نسخه‌های پیشین تغییر کند (مانند افزودن یک ستون جدید)، y افزایش می‌یابد (و z به 0 بازنشانی می‌شود). هنگامی که شمای پایگاه‌داده تغییر ظاهری داشته باشد (مانند تغییر تورفتگی نحو آن)، z افزایش می‌یابد.

برخی پایگاه‌های داده و شماهای OVSDB، به ویژه موارد بسیار قدیمی، شماره نسخه ندارند.

شماره‌های نسخهٔ شما و شماره‌های نسخهٔ Open vSwitch مستقل از یکدیگر هستند.

این دستورها با نسخه‌های مختلف شماها و پایگاه‌های دادهٔ OVSDB کار می‌کنند.

convert [server] schema

یک شمای OVSDB را در قالب JSON، طبق آنچه در مشخصات OVSDB تعریف شده، از schema می‌خواند، سپس به server متصل شده و از سرور درخواست می‌کند پایگاه‌داده‌ای را که نام آن در schema مشخص شده است به شمایی که آن نیز در schema تعیین شده تبدیل کند.

عملیات تبدیل اتمیک، سازگار، مجزا و پایا (ACID) است. پس از تغییر شما، سرور به کلاینت‌هایی که از RPC مربوط به set_db_change_aware (معرفی‌شده در Open vSwitch 2.9) استفاده می‌کنند اطلاع داده و تراکنش‌ها و پایش‌های (monitors) معلق آن‌ها را لغو می‌کند. سرور سایر کلاینت‌ها را قطع می‌کند تا بتوانند هنگام اتصال مجدد، متوجه این تغییر شوند.

این دستور می‌تواند «ارتقاها» و «تنزل‌های» ساده‌ای را روی شمای یک پایگاه‌داده انجام دهد. داده‌های درون پایگاه‌داده باید هنگام تفسیر تحت schema معتبر باشند، تنها با یک استثنا: داده‌های مربوط به جدول‌ها و ستون‌هایی که در schema وجود ندارند نادیده گرفته می‌شوند. ستون‌هایی که در schema وجود دارند اما در پایگاه‌داده نیستند، به مقادیر پیش‌فرض خود تنظیم می‌شوند. تمام محدودیت‌های schema به طور کامل اعمال می‌شوند.

برخی استفاده‌ها از این دستور می‌تواند باعث از دست رفتن غیرقابل‌بازگشت داده‌ها شود. برای مثال، تبدیل یک پایگاه‌داده از شمایی که دارای یک ستون یا جدول مشخص است به شمایی که فاقد آن است، تمام داده‌های موجود در آن ستون یا جدول را حذف خواهد کرد. قبل از تبدیل پایگاه‌های دادهٔ حیاتی، از آن‌ها نسخهٔ پشتیبان تهیه کنید.

این دستور با پایگاه‌های دادهٔ خوشه‌ای (clustered) و مستقل (standalone) کار می‌کند. پایگاه‌های دادهٔ مستقل را می‌توان به‌صورت برون‌خط (offline) با دستور convert از ovsdb-tool نیز تبدیل کرد.

needs-conversion [server] schema

شما را از schema می‌خواند، سپس به server متصل شده و شمای پایگاه‌داده‌ای را که نام آن در schema مشخص شده درخواست می‌کند. اگر هر دو شما یکسان باشند، no را در خروجی استاندارد (stdout) چاپ می‌کند؛ اگر متفاوت باشند، yes را چاپ می‌کند.

get-schema-version [server] [database]

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

get-schema-cksum [server] [database]

به server متصل می‌شود، شمای مربوط به database را دریافت کرده و چکسام (checksum) آن را در خروجی استاندارد (stdout) چاپ می‌کند. اگر database فاقد چکسام باشد، یک خط خالی چاپ می‌کند.

این دستورها داده‌ها را در یک پایگاه داده می‌خوانند یا تغییر می‌دهند.

transact [server] transaction

به server متصل می‌شود، transaction مشخص‌شده را که باید یک آرایهٔ JSON مناسب برای استفاده به عنوان params در یک درخواست JSON-RPC transact باشد به آن ارسال می‌کند، و پاسخ دریافتی را در stdout چاپ می‌کند.

query [server] transaction

این دستور مانند یک نسخهٔ فقط‌خواندنی از transact عمل می‌کند. به server متصل می‌شود، transaction مشخص‌شده را که باید یک آرایهٔ JSON مناسب برای استفاده به عنوان params در یک درخواست JSON-RPC transact باشد به آن ارسال می‌کند، و پاسخ دریافتی را در stdout چاپ می‌کند. برای اطمینان از اینکه تراکنش پایگاه داده را تغییر نمی‌دهد، این دستور یک عملیات abort را قبل از ارسال به پایگاه داده به مجموعه عملیات موجود در transaction می‌افزاید و سپس نتیجهٔ abort را از پاسخ (در صورت وجود) حذف می‌کند.

dump [server] [database] [table [column...]]

به server متصل می‌شود، تمام داده‌های موجود در database را دریافت کرده و آن را به صورت مجموعه‌ای از جدول‌ها در stdout چاپ می‌کند. اگر table مشخص شده باشد، تنها همان جدول دریافت می‌شود. اگر حداقل یک column مشخص شده باشد، تنها همان ستون‌ها دریافت می‌شوند.

backup [server] [database] > snapshot

به server متصل می‌شود، یک تصویر لحظه‌ای (snapshot) از طرح‌واره (schema) و داده‌های موجود در database را دریافت کرده و آن را در قالب مورد استفاده برای پایگاه‌های دادهٔ standalone و active-backup در OVSDB در stdout چاپ می‌کند. این روشی مناسب برای پشتیبان‌گیری از هر پایگاه دادهٔ راه دور است. تصویر لحظه‌ای پایگاه داده که در خروجی تولید می‌شود، برای سرویس‌دهی مستقیم توسط ovsdb-server یا استفاده به عنوان ورودی برای ovsdb-client restore مناسب است.

روش دیگر برای پشتیبان‌گیری از یک پایگاه دادهٔ standalone یا active-backup، کپی کردن فایل پایگاه دادهٔ آن است، مثلاً با cp. این روش حتی در صورت در حال استفاده بودن پایگاه داده نیز امن است.

خروجی شامل ستون‌های زودگذر (ephemeral) نمی‌شود، چرا که این ستون‌ها طبق طراحی، پس از راه‌اندازی مجدد ovsdb-server باقی نمی‌مانند.

[--force] restore [server] [database] < snapshot

فایل snapshot را می‌خواند که باید یک پایگاه دادهٔ standalone یا active-backup در OVSDB باشد (که احتمالاً اما نه لزوماً توسط ovsdb-client backup ایجاد شده است). سپس به server متصل می‌شود، تأیید می‌کند که database و snapshot طرح‌وارهٔ یکسانی دارند، و سپس تمام داده‌های موجود در database را پاک کرده و snapshot را جایگزین آن می‌کند. این جایگزینی به صورت تجزیه‌ناپذیر (atomically) و در قالب یک تراکنش واحد انجام می‌شود.

شناسه‌های یکتا (UUID) برای سطرها در پایگاه دادهٔ بازیابی‌شده با موارد موجود در snapshot متفاوت خواهد بود، زیرا پروتکل OVSDB به کلاینت‌ها اجازه نمی‌دهد UUID سطرها را مشخص کنند. روش دیگر برای بازیابی یک پایگاه دادهٔ standalone یا active-backup که UUID سطرها را نیز بازیابی می‌کند، متوقف کردن سرور یا سرورها، جایگزینی فایل پایگاه داده با snapshot، و سپس راه‌اندازی مجدد پایگاه داده است. در هر دو حالت، ستون‌های زودگذر بازیابی نمی‌شوند، چرا که طبق طراحی پس از راه‌اندازی‌های مجدد ovsdb-server باقی نمی‌مانند.

به‌طور معمول اگر طرح‌واره‌های snapshot و پایگاه دادهٔ سرور متفاوت باشند، restore با شکست مواجه شده و خارج می‌شود. در چنین حالتی، بهتر است پایگاه داده پیش از بازیابی به طرح‌وارهٔ جدید تبدیل شود، مثلاً با ovsdb-client convert. برای ادامه دادن صرف‌نظر از تفاوت‌های طرح‌واره از --force استفاده کنید، اگرچه ممکن است بازیابی با خطا مواجه شود یا با نتایج غیرمنتظره‌ای با موفقیت به پایان برسد.

monitor [server] [database] table [column[,column]...]...

monitor-cond [server] [database] conditions table [column[,column]...]...

monitor-cond-since [server] [database] [last-id] conditions table [column[,column]...]...

به server متصل می‌شود و محتویات سطرهایی را که با شرایط در table در database مطابقت دارند، نظارت می‌کند. به‌طور پیش‌فرض، محتویات اولیهٔ table چاپ می‌شود و به دنبال آن هر تغییر به محض وقوع نمایش داده می‌شود. اگر شرایط خالی باشد، تمام سطرها نظارت خواهند شد. اگر حداقل یک column مشخص شده باشد، تنها همان ستون‌ها نظارت می‌شوند. نام‌های column زیر دارای معانی ویژه‌ای هستند:

می‌توان چندین گروه از [column[,column]...] را به صورت آرگومان‌های جداگانه مشخص کرد، به عنوان مثال برای اعمال پارامترهای گزارش‌دهی متفاوت به هر گروه. چه چندین گروه و چه تنها یک گروه مشخص شده باشد، هر ستون معین فقط یک بار می‌تواند در خط فرمان ذکر شود.

مقدار conditions یک آرایهٔ JSON از <condition> است، طبق تعریف در بخش 5.1 از RFC 7047 با تغییر زیر: یک شرط می‌تواند یک آرایهٔ JSON سه عضوی به صورت شرح داده شده در RFC یا یک مقدار بولی (boolean) باشد.

اگر --detach همراه با monitor، monitor-cond یا monitor-cond-since استفاده شود، ovsdb-client پس از اینکه محتویات اولیهٔ table را با موفقیت دریافت و چاپ کرد، جدا می‌شود (در پس‌زمینه قرار می‌گیرد).

دستور monitor از متد "monitor" در RFC 7047 برای باز کردن یک نشست نظارت با سرور استفاده می‌کند. دستورهای monitor-cond و monitor-cond-since از متدهای افزونهٔ RFC 7047 به نام‌های "monitor_cond" و "monitor_cond_since" استفاده می‌کنند. برای جزئیات بیشتر به ovsdb-server(1) مراجعه کنید.

monitor [server] [database] ALL

به server متصل می‌شود و محتویات تمام جدول‌ها در database را نظارت می‌کند. مقادیر اولیه و همه نوع تغییرات را برای تمام ستون‌های پایگاه داده چاپ می‌کند. گزینهٔ --detach باعث می‌شود ovsdb-client پس از دریافت و چاپ موفقیت‌آمیز محتویات اولیهٔ پایگاه داده جدا شود (در پس‌زمینه قرار گیرد).

دستور monitor از متد "monitor" در RFC 7047 برای باز کردن یک نشست نظارت با سرور استفاده می‌کند.

wait [server] database state

منتظر می‌ماند تا database روی server وارد یک state دلخواه شود، که می‌تواند یکی از موارد زیر باشد:

مشخص کردن database برای این دستور الزامی است، زیرا اغلب برای بررسی پایگاه‌های داده‌ای استفاده می‌شود که هنوز به سرور اضافه نشده‌اند، به طوری که رفتار معنایی معمول ovsdb-client برای عمل بر روی یک پایگاه دادهٔ پیش‌فرض کارایی ندارد.

این دستور روی یک سرور پایگاه دادهٔ مشخص عمل می‌کند نه روی یک خوشه، بنابراین server باید نام یک سرور واحد باشد، نه فهرستی از سرورها که با کاما از هم جدا شده‌اند..SS "دستورهای آزمایش" این دستورها بیشتر برای سنجش درستی سرور OVSDB کاربرد دارند.

lock [server] lock

steal [server] lock

unlock [server] lock

به server متصل شده و عملیات قفل‌گذاری مربوط به RFC 7047 را روی lock اجرا می‌کند. پاسخ json یا پیام‌های به‌روزرسانی بعدی را چاپ می‌کند. گزینهٔ --detach باعث می‌شود ovsdb-client پس از دریافت و چاپ موفقیت‌آمیز پاسخ اولیه، به پس‌زمینه برود (جدا شود).

هنگام اجرا با گزینهٔ --detach، دستورهای lock، steal، unlock و exit را می‌توان با استفاده از ovs-appctl صادر کرد. دستور exit باعث می‌شود ovsdb-client پیش از خروج، اتصال ovsdb-server خود را ببندد. دستورهای lock، steal و unlock را می‌توان برای صدور عملیات قفل‌گذاریِ بیشتر روی همان اتصال ovsdb-server به کار برد. همهٔ دستورهای بالا یک تک‌آرگومان lock دریافت می‌کنند که لزومی ندارد همان lock باشد که ovsdb-client با آن آغاز به کار کرده است.

گزینه‌های قالب‌بندی خروجی

بخش عمده‌ای از خروجیِ ovsdb-client به شکل جدول است. گزینه‌های زیر قالب‌بندی خروجی را کنترل می‌کنند:

-f format

--format=format

نوع قالب‌بندی جدول را تعیین می‌کند. انواع format زیر در دسترس هستند:

-d format

--data=format

قالب‌بندی سلول‌ها را درون جدول‌های خروجی تعیین می‌کند، مگر اینکه قالب جدول روی json تنظیم شده باشد که در این صورت هنگام قالب‌بندی سلول‌ها، همواره قالب‌بندی json به کار می‌رود. انواع format زیر در دسترس هستند:

--no-headings

این گزینه سطر سرستون را که در حالت عادی در اولین سطر خروجی جدول ظاهر می‌شود، حذف می‌کند.

--pretty

به‌طور پیش‌فرض، JSON در خروجی تا حد امکان فشرده چاپ می‌شود. این گزینه باعث می‌شود JSON در خروجی به شیوه‌ای خواناتر چاپ شود. اعضای اشیاء و عناصر آرایه‌ها، هر کدام در یک خط و با تورفتگی چاپ می‌شوند.

این گزینه بر JSON درون جدول‌ها تأثیری ندارد؛ این موارد همواره به‌صورت فشرده چاپ می‌شوند.

--bare

معادل با --format=list --data=bare --no-headings.

--max-column-width=n

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

--timestamp

برای دستورهای monitor، monitor-cond و monitor-cond-since، یک برچسب زمانی به هر به‌روزرسانی جدول می‌افزاید. بیشتر قالب‌های خروجی، برچسب زمانی را در خطی جداگانه درست بالای جدول درج می‌کنند. قالب خروجی JSON برچسب زمانی را درون عضوی از شیء سطح بالای JSON به نام time قرار می‌دهد.

-t

--timeout=secs

زمان اجرای ovsdb-client را به تقریباً secs ثانیه محدود می‌کند. اگر مهلت زمانی به پایان برسد، ovsdb-client با سیگنال SIGALRM خارج خواهد شد. گزینه‌های دیمن تنها برای دستورهای monitor، monitor-cond و monitor-cond-since اعمال می‌شوند. در صورت استفاده با هر دستور دیگری، هیچ اثری نخواهند داشت.

گزینه‌های زیر در پلتفرم‌های مبتنی بر POSIX معتبر هستند.

--pidfile[=pidfile]

باعث ایجاد فایلی (به‌طور پیش‌فرض، ovsdb-client.pid) می‌شود که نشان‌دهنده PID فرآیند در حال اجرا است. اگر آرگومان pidfile مشخص نشده باشد، یا اگر با / آغاز نشود، در مسیر /run/openvswitch ایجاد می‌شود.

اگر --pidfile مشخص نشود، هیچ فایل pid ایجاد نمی‌شود.

--overwrite-pidfile

به‌طور پیش‌فرض، هنگامی که --pidfile مشخص شده باشد و فایل pid مشخص‌شده از قبل وجود داشته و توسط یک فرآیند در حال اجرا قفل شده باشد، ovsdb-client از شروع به کار خودداری می‌کند. تعیین --overwrite-pidfile باعث می‌شود تا به‌جای آن، روی فایل pid بازنویسی شود.

هنگامی که --pidfile مشخص نشده باشد، این گزینه هیچ اثری ندارد.

--detach

فرآیند ovsdb-client را در پس‌زمینه اجرا می‌کند. فرآیند فورک می‌شود، و در فرآیند فرزند، یک نشست (session) جدید را آغاز می‌کند، توصیف‌کننده‌های فایل استاندارد را می‌بندد (که اثر جانبی آن غیرفعال شدن ثبت وقایع در کنسول است)، و دایرکتوری کاری جاری خود را به ریشه تغییر می‌دهد (مگر اینکه --no-chdir مشخص شده باشد). پس از اینکه فرآیند فرزند مقداردهی اولیه خود را به پایان رساند، فرآیند والد خارج می‌شود.

--monitor

فرآیند اضافه‌ای را برای پایش دیمن ovsdb-client ایجاد می‌کند. اگر دیمن به دلیل سیگنالی که نشان‌دهنده یک خطای برنامه‌نویسی است (SIGABRT، SIGALRM، SIGBUS، SIGFPE، SIGILL، SIGPIPE، SIGSEGV، SIGXCPU یا SIGXFSZ) خاتمه یابد، فرآیند ناظر یک نسخه جدید از آن را راه‌اندازی می‌کند. اگر دیمن به دلیل دیگری متوقف شود یا خارج گردد، فرآیند ناظر نیز خارج می‌شود.

این گزینه معمولاً همراه با --detach استفاده می‌شود، اما بدون آن نیز کار می‌کند.

--no-chdir

به‌طور پیش‌فرض، هنگامی که --detach مشخص شده باشد، ovsdb-client پس از جدا شدن (detach)، دایرکتوری کاری جاری خود را به دایرکتوری ریشه تغییر می‌دهد. در غیر این صورت، اجرای ovsdb-client از یک دایرکتوری نامناسب می‌تواند مانع از unmount کردن سیستم‌فایل حاوی آن دایرکتوری توسط مدیر سیستم شود.

مشخص کردن --no-chdir این رفتار را مهار کرده و از تغییر دایرکتوری کاری جاری توسط ovsdb-client جلوگیری می‌کند. این امر ممکن است برای جمع‌آوری فایل‌های core مفید باشد، زیرا نوشتن core dumpها در دایرکتوری کاری جاری یک رفتار معمول بوده و دایرکتوری ریشه مکان مناسبی برای این کار نیست.

این گزینه هنگامی که --detach مشخص نشده باشد، هیچ اثری ندارد.

--no-self-confinement

به‌طور پیش‌فرض، دیمن تلاش می‌کند خود را برای کار با فایل‌های درون دایرکتوری‌های شناخته‌شده‌ای که در زمان ساخت تعیین شده‌اند محدود (self-confine) کند. بهتر است به این رفتار پیش‌فرض پایبند باشید و از این پرچم استفاده نکنید، مگر اینکه سازوکار کنترل دسترسی (Access Control) دیگری برای محدودسازی دیمن در نظر گرفته شده باشد. توجه داشته باشید که بر خلاف سایر پیاده‌سازی‌های کنترل دسترسی که معمولاً از فضای هسته اعمال می‌شوند (مانند DAC یا MAC)، خود‌محدودسازی از سوی خود دیمن در فضای کاربر تحمیل می‌شود؛ بنابراین نباید به عنوان یک راهبرد محدودسازی کامل تلقی گردد، بلکه باید به عنوان یک لایه امنیتی مضاعف به آن نگریست.

--user

باعث می‌شود ovsdb-client تحت عنوان کاربر متفاوتی که به صورت "user:group" مشخص شده است اجرا شود و در نتیجه بیشتر امتیازات ریشه (root) را رها کند. شکل‌های کوتاه "user" و ":group" نیز مجاز هستند، که به ترتیب به معنای فرض کردن کاربر یا گروه جاری است. تنها دیمن‌هایی که توسط کاربر ریشه راه‌اندازی شده‌اند این آرگومان را می‌پذیرند.

در لینوکس، پیش از رها کردن امتیازات ریشه، قابلیت‌های CAP_IPC_LOCK و CAP_NET_BIND_SERVICES به دیمن‌ها اعطا خواهد شد. دیمن‌هایی که با datapath تعامل دارند، مانند ovs-vswitchd، سه قابلیت اضافی یعنی CAP_NET_ADMIN، CAP_NET_BROADCAST و CAP_NET_RAW را دریافت خواهند کرد. تغییر قابلیت‌ها حتی در صورتی که کاربر جدید root باشد نیز اعمال خواهد شد..SS "گزینه‌های ثبت وقایع (Logging Options)"

-v[spec]

--verbose=[spec]

سطوح ثبت وقایع را تعیین می‌کند. بدون هیچ spec، سطح گزارش را برای هر ماژول و مقصد روی dbg تنظیم می‌کند. در غیر این صورت، spec فهرستی از کلمات است که با فاصله، ویرگول یا دونقطه از هم جدا شده‌اند؛ حداکثر یک مورد از هر یک از دسته‌های زیر:

بزرگی یا کوچکی حروف در spec اهمیتی ندارد.

صرف‌نظر از سطوح گزارش تعیین‌شده برای file، ثبت وقایع در فایل صورت نخواهد گرفت مگر اینکه --log-file نیز مشخص شده باشد (پایین را ببینید).

جهت سازگاری با نسخه‌های قدیمی‌تر OVS، واژه any به عنوان یک کلمه پذیرفته می‌شود اما هیچ اثری ندارد.

-v

--verbose

حداکثر سطح پرگویی (verbosity) ثبت وقایع را تنظیم می‌کند که معادل --verbose=dbg است.

-vPATTERN:destination:pattern

--verbose=PATTERN:destination:pattern

الگوی گزارش را برای destination روی pattern تنظیم می‌کند. برای توضیحات مربوط به ساختار نحو معتبر برای pattern، به ovs-appctl(8) مراجعه کنید.

-vFACILITY:facility

--verbose=FACILITY:facility

تسهیلات (facility) استاندارد RFC5424 را برای پیام گزارش تنظیم می‌کند. facility می‌تواند یکی از مقادیر kern، user، mail، daemon، auth، syslog، lpr، news، uucp، clock، ftp، ntp، audit، alert، clock2، local0، local1، local2، local3، local4، local5، local6 یا local7 باشد. اگر این گزینه مشخص نشود، daemon به عنوان پیش‌فرض برای syslog سیستم محلی استفاده می‌شود و local0 هنگام ارسال پیام به مقصدی که از طریق گزینه --syslog-target ارائه شده است، به کار می‌رود.

--log-file[=file]

ثبت وقایع در یک فایل را فعال می‌کند. اگر file مشخص شده باشد، دقیقاً به عنوان نام فایل گزارش استفاده می‌شود. نام پیش‌فرض فایل گزارش در صورت حذف file برابر /var/log/openvswitch/ovsdb-client.log است.

--syslog-target=host:port

پیام‌های syslog را علاوه بر syslog سیستم، به درگاه UDP مشخص‌شده با port در host ارسال می‌کند. مقدار host باید یک نشانی IP عددی باشد، نه نام میزبان (hostname).

--syslog-method=method

تعیین می‌کند پیام‌های syslog از طریق چه روشی (method) باید به دیمن syslog ارسال شوند. روش‌های زیر پشتیبانی می‌شوند:

مقدار پیش‌فرض از متغیر محیطی OVS_SYSLOG_METHOD گرفته می‌شود؛ اگر این متغیر تنظیم نشده باشد، پیش‌فرض libc است..SS "گزینه‌های زیرساخت کلید عمومی (Public Key Infrastructure Options)"

-p privkey.pem

--private-key=privkey.pem

فایل PEM حاوی کلید خصوصی را مشخص می‌کند که به‌عنوان هویت ovsdb-client برای اتصالات خروجی SSL/TLS استفاده می‌شود.

-c cert.pem

--certificate=cert.pem

فایل PEM حاوی گواهی‌ای را مشخص می‌کند که قابل اعتماد بودن کلید خصوصی تعیین‌شده در -p یا --private-key را تصدیق می‌نماید. این گواهی باید توسط مرجع صدور گواهی (CA) که طرف مقابل در اتصالات SSL/TLS برای اعتبارسنجی آن استفاده خواهد کرد، امضا شده باشد.

-C cacert.pem

--ca-cert=cacert.pem

فایل PEM حاوی گواهی CA را مشخص می‌کند که ovsdb-client باید از آن برای اعتبارسنجی گواهی‌های ارائه‌شده از سوی همتاهای SSL/TLS استفاده کند. (بسته به معماری PKI مورد استفاده، این ممکن است همان گواهی‌ای باشد که همتاهای SSL/TLS برای اعتبارسنجی گواهی مشخص‌شده در -c یا --certificate به کار می‌برند، یا گواهی متفاوتی باشد.)

-C none

--ca-cert=none

اعتبارسنجی گواهی‌های ارائه‌شده توسط همتاهای SSL/TLS را غیرفعال می‌کند. این کار یک مخاطره امنیتی ایجاد می‌کند، چرا که بدین معناست که گواهی‌ها را نمی‌توان به‌عنوان گواهی‌های متعلق به میزبان‌های معتبر و شناخته‌شده تأیید کرد.

--ssl-server-name=servername

نام سرور مورد استفاده برای نشانگر نام سرور (TLS Server Name Indication یا SNI) را مشخص می‌کند. به‌طور پیش‌فرض، نام میزبان برگرفته از رشته اتصال برای SNI استفاده می‌شود. این گزینه امکان بازنویسی نام میزبان SNI را فراهم می‌کند؛ که هنگام اتصال از طریق پروکسی‌ها یا مش‌های سرویس (service meshes) که در آن‌ها نقطه پایانی اتصال با نام سرور مورد نظر متفاوت است، کاربردی است.

--bootstrap-ca-cert=cacert.pem

هنگامی که cacert.pem وجود دارد، این گزینه اثری یکسان با -C یا --ca-cert دارد. اگر این فایل وجود نداشته باشد، آن‌گاه ovsdb-client تلاش می‌کند تا در نخستین اتصال SSL/TLS خود، گواهی CA را از همتای SSL/TLS دریافت کرده و آن را در فایل PEM نام‌برده ذخیره کند. در صورت موفقیت، اتصال بلافاصله قطع شده و مجدداً برقرار می‌شود، و از آن پس همه اتصالات SSL/TLS باید توسط گواهی‌ای که با گواهی CA به‌دست‌آمده امضا شده است احراز هویت شوند.

این گزینه اتصال SSL/TLS را هنگام دریافت گواهی CA اولیه در معرض حمله مرد میانی (man-in-the-middle) قرار می‌دهد، اما ممکن است برای راه‌اندازی اولیه (bootstrapping) مفید باشد.

این گزینه تنها زمانی کارآمد است که همتای SSL/TLS گواهی CA خود را به‌عنوان بخشی از زنجیره گواهی SSL/TLS ارسال کند. پروتکل‌های SSL/TLS سرور را ملزم به ارسال گواهی CA نمی‌کنند.

این گزینه با -C و --ca-cert ناسازگار (مانعة‌الجمع) است.

گزینه‌های اتصال SSL/TLS (SSL/TLS Connection Options)

--ssl-protocols=protocols

محدوده‌ای یا فهرستی جداشده با کاما یا فاصله از پروتکل‌های SSL/TLS را مشخص می‌کند که ovsdb-client برای اتصالات SSL/TLS فعال خواهد کرد. پروتکل‌های (protocols) پشتیبانی‌شده شامل TLSv1.2 و TLSv1.3 هستند. محدوده‌ها می‌توانند به شکل دو نام پروتکل جداشده با یک خط تیره، یا یک نام پروتکل تنها همراه با یک علامت مثبت ارائه شوند. به عنوان مثال، از TLSv1.2-TLSv1.3 برای مجاز کردن TLSv1.2 و TLSv1.3 استفاده کنید. از TLSv1.2+ برای مجاز کردن TLSv1.2 و هر پروتکل پس از آن استفاده کنید. این گزینه فهرستی از پروتکل‌ها یا دقیقاً یک محدوده را می‌پذیرد. تعیین به صورت محدوده روش مرجح برای مشخص کردن پروتکل‌ها است و رفتار این گزینه همواره چنان است که گویی محدوده بین کمترین و بیشترین نسخه مشخص‌شده داده شده است؛ به عنوان مثال اگر گزینه روی TLSv1.X,TLSv1.(X+2) تنظیم شود، پروتکل TLSv1.(X+1) نیز درست مانند یک محدوده فعال خواهد شد. صرف‌نظر از ترتیب، بالاترین پروتکل پشتیبانی‌شده توسط هر دو طرف هنگام برقراری اتصال انتخاب خواهد شد. در صورت عدم تعیین این گزینه، مقدار پیش‌فرض TLSv1.2 یا بالاتر است.

--ssl-ciphers=ciphers

رمزهایی را در قالب رشته رمز OpenSSL مشخص می‌کند که ovsdb-client برای اتصالات SSL/TLS با TLSv1.2 پشتیبانی خواهد کرد. در صورت عدم تعیین این گزینه، مقدار پیش‌فرض DEFAULT:@SECLEVEL=2 است.

--ssl-ciphersuites=ciphersuites

مجموعه‌های رمزنگاری (ciphersuites) را در قالب رشته ciphersuite در OpenSSL مشخص می‌کند که ovsdb-client برای اتصالات SSL/TLS با TLSv1.3 و بالاتر پشتیبانی خواهد کرد. در صورت عدم تعیین این گزینه، مقدار پیش‌فرض OpenSSL استفاده خواهد شد..SS "سایر گزینه‌ها (Other Options)"

--record[=directory]

فرایند را در حالت «ضبط» (recording) قرار می‌دهد که در آن تمام اتصالات، داده‌های جریان‌ها (سوکت‌های دامنه Unix و شبکه) و برخی اطلاعات ضروری مهم دیگر را ضبط می‌کند تا بعداً بتوان آن‌ها را بازپخش کرد. داده‌های ضبط‌شده در فایل‌های بازپخش درون directory مشخص‌شده ذخیره می‌شوند. اگر directory با / آغاز نشود، به‌صورت نسبی نسبت به /run/openvswitch تفسیر می‌شود. اگر directory مشخص نشود، از /run/openvswitch استفاده خواهد شد.

--replay[=directory]

فرایند را در حالت «بازپخش» (replay) قرار می‌دهد که در آن به جای استفاده از سوکت‌های واقعی، اطلاعات مربوط به اتصالات، داده‌های جریان‌ها (سوکت‌های دامنه Unix و شبکه) و برخی اطلاعات ضروری دیگر را مستقیماً از فایل‌های بازپخش می‌خواند. فایل‌های بازپخش موجود در directory استفاده خواهند شد. اگر directory با / آغاز نشود، به‌صورت نسبی نسبت به /run/openvswitch تفسیر می‌شود. اگر directory مشخص نشود، از /run/openvswitch استفاده خواهد شد.

-h

--help

پیام راهنمای کوتاهی را روی کنسول چاپ می‌کند.

-V

--version

اطلاعات نسخه را روی کنسول چاپ می‌کند.