DUMMY-UPS(8) راهنمای NUT DUMMY-UPS(8)

dummy-ups - درایور برای شبیه‌سازی یا بازپخش چندمنظوره یوپی‌اس (UPS)

dummy-ups -h

dummy-ups -a UPS_NAME [OPTIONS]


نکته

این صفحه راهنما تنها قابلیت‌های ویژه درایور dummy-ups را مستند می‌کند. برای اطلاعات درباره درایور اصلی، به nutupsdrv(8) مراجعه کنید.

این برنامه ابزاری چندمنظوره برای شبیه‌سازی یوپی‌اس (UPS) است. رفتار کلی آن به حالت اجرایی بستگی دارد: "dummy" ("dummy-once" یا "dummy-loop")، یا "repeater".

در این حالت، dummy-ups برای upsd(8) مانند یک درایور استاندارد دستگاه NUT عمل کرده و اجازه می‌دهد هر مقداری را برای مقاصد آزمایشی تغییر دهید.

این ابزار هم تعاملی است، و از طریق دستورات upsrw(8) و upscmd(8) (یا ابزار گرافیکی معادل) قابل کنترل است، و هم از طریق فایل‌های اسکریپت به‌صورت دسته‌ای (batch) قابل استفاده است.

می‌توان آن را همانند هر درایور «واقعی» دیگر NUT پیکربندی، اجرا و استفاده کرد. این حالت بیشتر برای مقاصد توسعه و آزمایش مفید است.


نکته

برای تفاوت‌های حالت‌های dummy-once در برابر dummy-loop بخش‌های زیر را ببینید — حالت اول ممکن است برای کاربردها و آزمایش‌های «تعاملی» مناسب‌تر باشد.

در این حالت، dummy-ups به‌عنوان یک کلاینت NUT عمل کرده و صرفاً داده‌ها را فوروارد (هدایت) می‌کند.

این حالت می‌تواند برای مقاصد نظارتی مفید باشد. همچنین این حالت می‌تواند امکان توزیع بار (load sharing) بین چندین نمونه upsd را که با کلاینت‌های نهایی NUT ارتباط دارند فراهم کند، به این صورت که نمونه «مرکزی» از یک ارتباط نقطه‌به‌نقطه با دستگاه یوپی‌اس یا ePDU واقعی استفاده می‌کند.

این چیدمان همچنین می‌تواند برای یوپی‌اس‌های متصل به شبکه که کارت مدیریت شبکه آن‌ها ممکن است با نظرسنجی مستقیم یک مزرعه از سرورها از طریق SNMP یا سایر پروتکل‌های شبکه‌ای در هر چند ثانیه دچار بار اضافی شود، مفید باشد.

تعریف port در ups.conf به حالت اجرایی بستگی دارد و به درایور اجازه می‌دهد حالت عملیاتی مناسب را انتخاب کند.

از نسخه NUT v2.8.0 به بعد، پارامتر mode در ups.conf به کاربران امکان می‌دهد حالت کاری را که در غیر این صورت توسط درایور حدس زده می‌شد، بازنویسی (override) کنند.

در این چارچوب، port در بلوک ups.conf نام یک «فایل تعریف» (definition file) را مشخص می‌کند که dummy-ups داده‌ها را از آن می‌خواند. این مسیر می‌تواند یک مسیر مطلق یا نسبی باشد. در حالت دوم، دایرکتوری sysconfig در NUT (مانند /etc/nut، /usr/local/ups/etc و ...) به ابتدای آن افزوده می‌شود.


نکته

مسیر "sysconfig" بر اساس آرگومان‌های اسکریپت configure به صورت توکار تعریف شده است، اما در زمان اجرا می‌تواند با متغیر محیطی NUT_CONFPATH تغییر یابد. برای مثال‌های بیشتر، اسکریپت tests/NIT/nit.sh را در سورس‌های NUT که به شدت به این درایور وابسته است ببینید.

از نسخه NUT v2.8.0 به بعد، دو جنبه از این حالت تفکیک شده‌اند:

•dummy-once فایل مشخص‌شده را یک‌بار تا انتها می‌خواند (با وقفه برای خطوط TIMER و غیره) و آن را مجدداً پردازش نمی‌کند مگر اینکه برچسب زمان (timestamp) فایل داده در سیستم فایل تغییر کند؛ این کار در صورتی که با دستگاه‌های dummy زیادی تست کنید فشار زمان اجرا را کاهش می‌دهد، و به سناریوهای کاربرد/آزمایش اجازه می‌دهد متغیرها را با upsrw در نمونه درایور مقداردهی کنند — و متغیرها در حافظه باقی می‌مانند تا زمانی که درایور ری‌استارت شود (یا فایل touch شده یا ویرایش گردد)؛

از نسخه NUT v2.8.0 به بعد، حالت dummy-once به‌صورت پیش‌فرض به فایل‌هایی با الگوی نام‌گذاری *.dev اختصاص می‌یابد.

•dummy-loop فایل مشخص‌شده را بارها و بارها می‌خواند، با وقفه‌ای کوتاه بین چرخه‌های پردازش؛ برای فایل‌های توالی (sequence) که از کلیدواژه TIMER استفاده می‌کنند (پایین را ببینید)، یا برای سناریوهای کاربرد/آزمایش که محتوای فایل را با ابزارهای خارجی ویرایش می‌کنند، این حالت جلوه‌ای از دستگاهی را شبیه‌سازی می‌کند که وضعیت آن در طول زمان تغییر می‌کند.

پیش از نسخه NUT v2.8.0 این تنها جنبه موجود بود، بنابراین مقدار حالت ساده dummy برای حفظ سازگاری عقب‌رو به همین رفتار نگاشت می‌شود.

از نسخه NUT v2.8.0 به بعد، حالت dummy-loop به‌طور پیش‌فرض به فایل‌هایی با الگوی نام‌گذاری *.seq اختصاص داده می‌شود، و حالت dummy به‌طور پیش‌فرض به فایل‌هایی با سایر الگوهای نام‌گذاری که درایور نتوانسته آن‌ها را دسته‌بندی کند اختصاص می‌یابد.


نکته

این پیش‌فرض‌سازی بر اساس الگوی نام فایل می‌تواند اسکریپت‌های آزمایشی شخص ثالث را که پیش‌تر انتظار داشتند فایل‌های *.dev به عنوان توالی تکرارشونده با کلیدواژه‌های TIMER برای تغییر آهسته مقادیر عمل کنند، مختل کند. اکنون چنین فایل‌هایی باید فقط یک‌بار تا انتها پردازش شوند.

برای دریافت رفتار قدیمی، گزینه mode=dummy-loop درایور را مشخص کنید یا نام فایل داده استفاده‌شده در گزینه port را تغییر دهید.

سناریوهای کاربرد/آزمایشی که محتوای چنین فایل‌هایی را از بیرون ویرایش می‌کردند نباید تحت تأثیر قرار گیرند.

برای نمونه:

[dummy1]
        driver = dummy-ups
        port = evolution500.seq
        desc = "dummy-ups in dummy-loop mode"
[dummy2]
        driver = dummy-ups
        port = epdu-managed.dev
        desc = "dummy-ups in dummy-once mode"

این فایل تعریف، که با آرگومان port در مثال بالا مشخص شده است، معمولاً به صورت something.dev یا something.seq نام‌گذاری می‌شود. این فایل شامل فهرستی از تمام متغیرهای معتبر و مقادیر مربوطه است (بعداً می‌توانید از upsrw تنها برای تغییر مقادیر این متغیرها استفاده کنید)، و فرمتی مشابه خروجی دامپ داده upsc(8) دارد (<varname>: <value>). این بدان معناست که می‌توانید به راحتی با استفاده از upsc > file.dev فایل‌های تعریف را از یک یوپی‌اس موجود ایجاد کنید.

توجه داشته باشید که پروژه Network UPS یک کتابخانه جامع تخلیه دستگاه‌ها (DDL - Devices Dumps Library) با فایل‌هایی ارائه می‌دهد که می‌توان از آن‌ها برای مدل‌سازی دستگاه‌های واقعی استفاده کرد. ورودی‌های کتابخانه DDL به جای upsc ساده، بهتر است با اسکریپت tools/nut-ddl-dump.sh از سورس‌های NUT آماده شوند تا نقاط داده اضافی از دیگر کلاینت‌های NUT را نیز ارائه دهند.

این فایل می‌تواند خالی نیز باشد، که در این صورت تنها یک مجموعه پایه از داده‌ها در دسترس خواهد بود: device.*، driver.*، ups.mfr، ups.model، ups.status به همان شکلی که توسط خود درایور پر می‌شوند.

تعدادی فایل تعریف نمونه در دایرکتوری data از درخت سورس NUT، و عموماً در دایرکتوری "sysconfig" یا "share" توزیع سیستم شما در دسترس هستند.

از آنجا که dummy-ups معمولاً این فایل را به صورت چرخه‌ای می‌خواند، می‌توانید آن را به صورت پویا با یک فرایند خارجی تغییر دهید تا با درایور «تعامل» داشته باشید. در صورتی که از پیکربندی پیش‌فرض NUT استفاده می‌کنید، این کار از پر شدن فایل‌های لاگ سیستم با پیام‌های زائد جلوگیری می‌کند.


نکته

به صورت پیش‌فرض از نسخه NUT v2.8.0 به بعد، درایور روی فایل‌ها در حالت dummy-once، مانند فایل‌های با پسوند .dev، چرخه‌ای تکرار نمی‌شود مگر اینکه برچسب زمان آن‌ها تغییر کند.

همچنین می‌توانید از دستورالعمل TIMER <seconds> برای ایجاد توالی‌های رویداد زمان‌بندی‌شده استفاده کنید (چنین فایل‌هایی طبق سنت با پسوند .seq نام‌گذاری می‌شوند). برای نمونه، توالی زیر هر یک دقیقه وضعیت ups.status را بین "OL"، "OB" و "OB LB" جابه‌جا می‌کند:

ups.status: OL
TIMER 60
ups.status: OB
TIMER 60
ups.status: OB LB
TIMER 60

عاقلانه است که اسکریپت را برای حالت dummy-loop با یک کلیدواژه TIMER پایان دهید. در غیر این صورت dummy-ups مستقیماً به ابتدای فایل بازمی‌گردد و به‌ویژه، هر مقداری را که ممکن است به تازگی با upsrw تنظیم کرده باشید فراموش می‌کند.

توجه داشته باشید که برای جلوگیری از بار اضافی پردازنده (CPU) به دلیل حلقه بی‌نهایت، درایور بین چرخه‌های خواندن فایل اندکی «درنگ» (sleep) می‌کند (در حال حاضر این تاخیر به صورت ثابت یک ثانیه تنظیم شده است)، مستقل از (و/یا علاوه بر) هر کلیدواژه TIMER و احتمالاً تنظیم معمول pollinterval.

دستورالعمل دیگری که اخیراً معرفی شده ALARM است، که امکان شبیه‌سازی آلارم‌های یوپی‌اس را تقریباً به همان روشی که توسط پیاده‌سازی‌های واقعی درایور ایجاد می‌شوند، فراهم می‌کند. درایورهای مدرن وضعیت‌های آلارم را از متغیر ups.status جدا می‌کنند، و برانگیختن ALARM از طریق تنظیم آن به عنوان یک نشانه (token) در وضعیت منع شده و استفاده از توابع مدرن و مشترک برای ثبت آلارم در کد درایور توصیه می‌شود.

دستورالعمل ALARM به منظور شبیه‌سازی این رفتار تا حد امکان نزدیک به واقعیت طراحی شده است. مقدار پس از دستورالعمل ALARM به عنوان پیام آلارم در نظر گرفته می‌شود و در نهایت به عنوان متغیر ups.alarm منتشر می‌گردد، و نشانه ALARM نیز توسط سازوکارهای داخلی درایور در ups.status تنظیم می‌شود، نه با دستکاری مستقیم متغیر. دستورالعمل‌های متعدد ALARM پیام‌های خود را در متغیر ups.alarm با یکدیگر ترکیب می‌کنند، درست همان‌گونه که در منطق درایور واقعی رخ می‌دهد.

در مقابل، هر دستورالعمل ALARM به تنهایی، وضعیت‌های آلارم فعال را پاک می‌کند. در زیر مثالی از تنظیم و بازنشانی آلارم‌ها آمده است:

ALARM [UPS too warm to charge]
ALARM [UPS circuit is overheating]
TIMER 5
ALARM
TIMER 5
ALARM [UPS too cold to charge]

در این چارچوب، port در بلوک ups.conf نام یوپی‌اس هدف است که از فرمت NUT استفاده می‌کند، یعنی:

<upsname>@<hostname>[:<port>]

برای نمونه:

[repeater]
        driver = dummy-ups
        port = ups1@remotehost
        desc = "dummy-ups in repeater mode"

برخلاف مشخصات یوپی‌اس در سایر بخش‌های NUT، بخش @hostname اختیاری نیست — کاراکتر @ است که حالت بازپخش‌کننده (Repeater Mode) را فعال می‌کند. برای اشاره به یک یوپی‌اس روی همان میزبانی که dummy-ups اجرا می‌شود، از port = upsname@localhost استفاده کنید.

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

توجه داشته باشید که هر خطایی هنگام راه‌اندازی حالت بازپخش‌کننده (به عنوان مثال هنگامی که تمام یوپی‌اس‌های هدف برای بازپخش یا نمونه‌های upsd آن‌ها هنوز قابل اتصال نیستند) به طور پیش‌فرض موجب خروج زودهنگام درایور dummy-ups می‌شود. این رفتار را می‌توان با تنظیم فلگ repeater_disable_strict_start تغییر داد و چنین خطاهایی را غیرکشنده (non-fatal) کرد.

پس از بارگیری درایور در حالت dummy، می‌توانید هر متغیری به جز مجموعه‌های driver.* و server.* را تغییر دهید. این کار را می‌توانید با ویرایش فایل تعریف، یا استفاده از دستورات upsrw(8) و upscmd(8) انجام دهید.

توجه داشته باشید که در حالت شبیه‌سازی، متغیرهای جدید را می‌توان در حین اجرا افزود، اما تنها با افزودن آن‌ها به فایل تعریف (و انتظار برای خواندن مجدد آن). به بیان دیگر، درایور نباید اجازه دهد متغیر جدیدی از طریق upsrw تعریف شود.

در مقابل، اگر نیاز به حذف یک متغیر دارید (مانند متغیرهای گذرا نظیر ups.alarm)، به سادگی آن‌ها را با تنظیم یک مقدار خالی به‌روزرسانی کنید. در نتیجه، آن‌ها از داده‌ها حذف خواهند شد.

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

حالت ساختگی (Dummy Mode) در ابتدا در یک عصر برای جایگزینی درایور آزمایشی پیشین dummycons نوشته شد، که بسیار محدود بود و برای تعامل به یک ترمینال نیاز داشت.

درایور dummy-ups برای توسعه کلاینت NUT و سایر اهداف آزمایشی مفید است.

همچنین با خودکارسازی برخی آزمایش‌ها روی چارچوب NUT و NIT (مجموعه آزمون‌های یکپارچگی NUT - NUT Integration Test suite) به تلاش‌های تضمین کیفیت NUT کمک می‌کند. برای مثال‌های بیشتر، اسکریپت tests/NIT/nit.sh در سورس‌های NUT را ببینید که به شدت به این درایور متکی است.

این درایور اکنون حالت بازپخش‌کننده را نیز ارائه می‌دهد. این ویژگی به ساخت رویکرد Meta UPS کمک خواهد کرد، که به فرد امکان می‌دهد یک دستگاه مجازی بسازد متشکل از چندین دستگاه دیگر (چه یوپی‌اس و چه PDU)، یا شاید همان دستگاهی را بازنمایی کند که از چندین پروتکل ارتباطی و رسانه‌های مختلف (سریال، USB، SNMP و ...) پشتیبانی می‌کند.

دستورات آنی هنوز در حالت ساختگی (Dummy Mode) پشتیبانی نمی‌شوند، و داده‌ها نیاز به اعمال اعتبارسنجی نام/مقدار، و همچنین تعیین محدوده‌ها یا تعاریف شمارشی (enumeration) دارند.

اگر از چارچوب‌های مدیریت سرویس مانند systemd یا SMF برای مدیریت وابستگی‌ها بین نمونه‌های درایور و سرور داده استفاده می‌کنید، و برخی از این درایورها dummy-ups در حالت repeater هستند که داده‌های درایور دیگری را که روی همان سیستم اجرا می‌شود نمایش می‌دهند، در این صورت ممکن است مجبور شوید وابستگی‌های ویژه‌ای تنظیم کنید (مثلاً با فایل‌های قطعه‌کد "drop-in" در systemd) تا به nut-server شما اجازه دهد پس از درایورهای دستگاه «واقعی» و قبل از چنین درایورهای بازپخش‌کننده‌ای شروع به کار کند (بدون یک سرور پاسخگو، آن‌ها در هر صورت در شروع ناموفق خواهند بود). این مورد همچنین ممکن است به دقت ویژه‌ای در فایل‌های upsd.conf و/یا ups.conf نیاز داشته باشد تا راه‌اندازی سیستم برای مدت طولانی در حالی که درایور بازپخش‌کننده هنوز شروع نشده مسدود نشود.

Arnaud Quette

upscmd(8), upsrw(8), ups.conf(5), nutupsdrv(8)

حالت «بازپخش‌کننده» (repeater) از درایور dummy-ups از برخی جهات شبیه به درایورهای clone و clone-outlet است، که به صورت محلی روی سوکت درایور دیگری (یا Windows named pipe) قرار می‌گیرند، و به کاربران اجازه می‌دهند کلاینت‌ها را در یک خروجی (outlet) خاص از یک دستگاه گروه‌بندی کنند و با این خروجی مانند یک یوپی‌اس عادی رفتار نمایند. قابل توجه است که در این حالت، درایور dummy-ups یک کلاینت برای پروتکل شبکه‌ای NUT است و می‌تواند اطلاعات دستگاه‌های ارائه‌شده به صورت محلی یا راه دور را بازپخش کند، و برای کار کردن به یک سرور داده NUT در حال اجرا (upsd) برای بازنمایی دستگاه «واقعی» نیاز دارد.

clone(8), clone-outlet(8)

صفحه خانگی NUT (Network UPS Tools): https://www.networkupstools.org/historic/v2.8.5

06/21/2026 Network UPS Tools 2.8.5