.TH SNMPD.CONF 5 "30 Jun 2010" V5.9.5.2 "Net-SNMP" .SH "نام (NAME)" snmpd.conf \- فایل پیکربندی کارگزار Net-SNMP SNMP .SH "توضیحات (DESCRIPTION)" کارگزار Net-SNMP از یک یا چند فایل پیکربندی برای کنترل عملکرد خود و اطلاعات مدیریتی ارائه‌شده استفاده می‌کند. این فایل‌ها (\fBsnmpd.conf\fR و \fBsnmpd.local.conf\fR) می‌توانند در یکی از چندین مکان، همان‌طور که در صفحه راهنمای .I snmp_config(5) شرح داده شده است، قرار گیرند. .PP برنامه (perl) با نام .B snmpconf می‌تواند برای تولید فایل‌های پیکربندی برای رایج‌ترین نیازهای کارگزار استفاده شود. برای اطلاعات بیشتر صفحه راهنمای .I snmpconf(1) را ببینید، یا اجرای دستور زیر را امتحان کنید: .RS .IP "snmpconf \-g basic_setup" .RE .PP دستورالعمل‌های متعددی وجود دارد که می‌توان مشخص کرد، اما این موارد عمدتاً در چهار دسته مجزا قرار می‌گیرند: .IP \(bu آن‌هایی که کنترل می‌کنند چه کسی می‌تواند به کارگزار دسترسی داشته باشد .IP \(bu آن‌هایی که اطلاعات ارائه‌شده توسط کارگزار را پیکربندی می‌کنند .IP \(bu آن‌هایی که پایش فعال سیستم محلی را کنترل می‌کنند .IP \(bu آن‌هایی که به گسترش قابلیت‌های کارگزار مربوط می‌شوند. .PP برخی دستورالعمل‌ها به طور طبیعی در هیچ‌یک از این چهار دسته قرار نمی‌گیرند، اما این دسته‌ها بخش عمده‌ای از محتوای یک فایل .B snmpd.conf معمولی را پوشش می‌دهند. فهرست کاملی از دستورالعمل‌های شناخته‌شده را می‌توان با اجرای دستور زیر به دست آورد: .RS .IP "snmpd \-H" .RE .SH "رفتار کارگزار (AGENT BEHAVIOUR)" اگرچه اکثر دستورالعمل‌های پیکربندی به اطلاعات MIB ارائه‌شده توسط کارگزار مربوط می‌شوند، تعداد اندکی دستورالعمل وجود دارد که رفتار \fIsnmpd\fR را صرفاً به عنوان یک دیمن ارائه‌دهنده سرویس شبکه کنترل می‌کنند. .IP "agentaddress [:][,...]" فهرستی از نشانی‌های شنود را برای دریافت درخواست‌های ورودی SNMP تعریف می‌کند. برای اطلاعات بیشتر در مورد قالب نشانی‌های شنود، بخش .B LISTENING ADDRESSES را در صفحه راهنمای .I snmpd(8) ببینید. .IP رفتار پیش‌فرض، شنود روی پورت UDP شماره 161 در تمام رابط‌های IPv4 است. .IP "agentgroup {GROUP|#GID}" پس از باز کردن پورت(های) شنود، به گروه مشخص‌شده تغییر وضعیت می‌دهد. این مقدار می‌تواند به نام گروه (GROUP) یا شناسه عددی گروه که با '#' شروع می‌شود (#GID) اشاره کند. .IP "agentuser {USER|#UID}" پس از باز کردن پورت(های) شنود، به کاربر مشخص‌شده تغییر وضعیت می‌دهد. این مقدار می‌تواند به نام کاربر (USER) یا شناسه عددی کاربر که با '#' شروع می‌شود (#UID) اشاره کند. .IP "leave_pidfile yes" به کارگزار دستور می‌دهد که هنگام خاموش شدن، فایل pid خود را حذف نکند. معادل مشخص کردن "\-U" در خط فرمان است. .IP "maxGetbulkRepeats NUM" حداکثر تعداد پاسخ‌های مجاز برای یک متغیر واحد در یک درخواست getbulk را تعیین می‌کند. برای فعال‌سازی حالت پیش‌فرض آن را روی 0 و برای نامحدود کردن روی \-1 تنظیم کنید. به دلیل اینکه حافظه از پیش تخصیص داده می‌شود، در صورتی که نتوان به کاربران اعتماد کرد، تنظیم این مقدار روی نامحدود ایمن در نظر گرفته نمی‌شود. هر تعداد تکرار بزرگ‌تر از این مقدار، به این مقدار بریده خواهد شد. .IP این مقدار به طور پیش‌فرض روی \-1 تنظیم شده است. .IP "maxGetbulkResponses NUM" حداکثر تعداد پاسخ‌های مجاز برای یک درخواست getbulk را تعیین می‌کند. این مقدار به طور پیش‌فرض 100 است. برای فعال‌سازی مقدار پیش‌فرض آن را روی 0 و برای نامحدود کردن روی \-1 قرار دهید. به دلیل اینکه حافظه از پیش تخصیص می‌یابد، در صورتی که نتوان به کاربران اعتماد کرد، تنظیم این مقدار روی نامحدود ایمن در نظر گرفته نمی‌شود. .IP به طور کلی، مجموع تعداد پاسخ‌ها مجاز نخواهد بود از مقدار maxGetbulkResponses تجاوز کند، و تعداد کل بازگردانده شده مضرب صحیحی از تعداد متغیرهای درخواست‌شده ضرب‌در تعداد تکرارهای محاسبه‌شده مجاز برای قرار گرفتن زیر این عدد خواهد بود. .IP همچنین توجه داشته باشید که پردازش maxGetbulkRepeats در ابتدا انجام می‌شود. .IP "ifmib_max_num_ifaces NUM" حداکثر تعداد رابط‌های گنجانده‌شده در جمع‌آوری داده‌های IF-MIB را تعیین می‌کند. برای سرورهایی با تعداد زیادی رابط (ppp، dummy، bridge و غیره)، پردازش IF-MIB بخش بزرگی از CPU را برای فراخوانی‌های ioctl (در لینوکس) مصرف می‌کند. تنظیم یک حداکثر معقول برای مصرف CPU، بار پردازشی را برای IF-MIB کاهش می‌دهد. به عنوان مثال، پیکربندی "ifmib_max_num_ifaces 500" فقط 500 رابط اول را بر اساس ifindex شامل می‌شود و سایر رابط‌ها را برای پردازش IF-MIB نادیده می‌گیرد. .IP حالت پیش‌فرض (بدون پیکربندی این مورد)، شامل شدن تمام رابط‌ها است. .IP "include_ifmib_iface_prefix PREFIX1 PREFIX2 ..." پیشوندهای نام رابط را برای گنجاندن در جمع‌آوری داده‌های IF-MIB تعیین می‌کند. برای سرورهایی با تعداد زیادی رابط (ppp، dummy، bridge و غیره)، پردازش IF-MIB بخش بزرگی از CPU را برای فراخوانی‌های ioctl (در لینوکس) مصرف خواهد کرد. مجموعه‌ای از پیشوندهای نام رابط که با فاصله جدا شده‌اند، بار CPU را برای پردازش IF-MIB کاهش می‌دهد. برای مثال، پیکربندی "include_ifmib_iface_prefix eth dummy lo" فقط رابط‌های دارای این پیشوندها را شامل می‌شود و سایر رابط‌ها را برای پردازش IF-MIB نادیده می‌گیرد. اگر پشتیبانی از regex کامپایل شده باشد، هر یک از پیشوندها یک عبارت باقاعده است (که مجاز به داشتن نویسه فاصله یا تب نیست). .IP حالت پیش‌فرض (بدون پیکربندی این مورد)، شامل شدن تمام رابط‌ها است. .SS "پیکربندی SNMPv3 \- امنیت واقعی (SNMPv3 Configuration - Real Security)" SNMPv3 مدل‌های امنیتی انعطاف‌پذیری را به ساختار بسته SNMP اضافه کرده است تا بتوان از راه‌حل‌های امنیتی متعددی استفاده کرد. SNMPv3 در ابتدا با یک «مدل امنیتی مبتنی بر کاربر» (USM) [RFC3414] تعریف شد که نیازمند نگهداری یک پایگاه داده کاربران مخصوص SNMP بود. بعدها مشخص شد که نگهداری آن دردسرساز است و مشکلات امنیتی جزئی دارد. IETF از آن زمان مدل‌های امنیتی بیشتری را برای تونل کردن SNMP روی SSH [RFC5592] و DTLS/TLS [RFC-to-be] اضافه کرده است. Net-SNMP شامل پشتیبانی قدرتمند از SNMPv3/USM، SNMPv3/TLS و SNMPv3/DTLS است. همچنین شامل پشتیبانی جزئی از SNMPv3/SSH است اما به طور گسترده آزمایش نشده است. این برنامه همچنین شامل کدهایی برای پشتیبانی از یک نسخه آزمایشی SNMPv3 مبتنی بر Kerberos است که هرگز استاندارد نشد. .PP امید است که در نهایت نرم‌افزارها و دستگاه‌های SNMP بیشتری از SNMP روی (D)TLS یا SSH پشتیبانی کنند، اما احتمالاً دستگاه‌هایی با پشتیبانی اولیه از SNMP فقط شامل پشتیبانی از کاربران USM خواهند بود. اگر مدیر شبکه شما از SNMP روی (D)TLS یا SNMP روی SSH پشتیبانی می‌کند، پیشنهاد می‌کنیم به جای استفاده از USM از یکی از این سازوکارها استفاده کنید، اما مثل همیشه با Net-SNMP گزینه‌هایی برای انتخاب در اختیار شما قرار می‌گیرد تا بتوانید انتخابی را که برای شما مناسب‌تر است انجام دهید. .SS "پارامترهای عمومی SNMPv3 (SNMPv3 generic parameters)" این پارامترها برای تمام شکل‌های SNMPv3 عمومی هستند. پروتکل SNMPv3 شناسه «engineID» را تعریف می‌کند که یک کارگزار را به طور یکتا مشخص می‌سازد. این رشته باید در طول زمان پایدار باشد و نباید هرگز تغییر کند یا با engineID کارگزار دیگری تداخل داشته باشد. به صورت داخلی، Net-SNMP به طور پیش‌فرض یک engineID یکتا بر اساس زمان جاری سیستم و یک عدد تصادفی ایجاد می‌کند. این مقدار باید برای بیشتر کاربران کافی باشد، مگر اینکه کارگزار ما را در دستگاهی جاسازی کنید که در آن این اعداد هنگام راه‌اندازی اولیه بین دستگاه‌ها تغییر نکنند. .IP شناسه‌های engineID هم به عنوان یک «زمینه» (context) برای انتخاب اطلاعات از دستگاه استفاده می‌شوند و هم SNMPv3 با USM از آن برای ایجاد مدخل‌های یکتا برای کاربران در جدول کاربران خود استفاده می‌کند. .IP کارگزار Net-SNMP سازوکارهای زیر را برای تنظیم engineID ارائه می‌دهد، اما باز هم فقط در صورتی باید از آن‌ها استفاده کنید که بدانید چه کاری انجام می‌دهید: .IP "engineID STRING" مشخص می‌کند که engineID باید از رشته متنی داده‌شده STRING ساخته شود. .IP "engineIDType 1|2|3" مشخص می‌کند که engineID باید از نشانی IPv4 (1)، نشانی IPv6 (2) یا نشانی MAC (3) ساخته شود. توجه داشته باشید که تغییر نشانی IP (یا تعویض کارت شبکه) ممکن است مشکلاتی ایجاد کند. .IP "engineIDNic INTERFACE" مشخص می‌کند هنگام تعیین نشانی MAC از کدام رابط استفاده شود. اگر \fIengineIDType 3\fR مشخص نشده باشد، این دستورالعمل هیچ تأثیری ندارد. .IP پیش‌فرض استفاده از eth0 است. .\" .\" What if this doesn't exist ? .\" .SS SNMPv3 بر بستر TLS پروتکل SNMPv3 می‌تواند بر بستر TLS و DTLS تونل شود. TLS بر روی TCP اجرا می‌شود و DTLS معادل UDP آن است. Wes Hardaker (بنیان‌گذار Net-SNMP) مطالعه‌ای انجام داد و آن را در یک نشست IETF ارائه کرد که نشان داد پروتکل‌های مبتنی بر TCP برای شبکه‌های پایدار کافی هستند، اما در شبکه‌های ناپایدار حتی با سطوح متوسطی از اتلاف بسته (حدود ۲۰\-۳۰٪) به‌سرعت دچار مشکل می‌شوند. اگر قصد استفاده از TLS یا DTLS را دارید، باید موردی را که متناسب با محیط شبکه شماست به کار ببرید. ترجیحاً می‌توانید هر دو را فعال کنید تا سامانه مدیریتی شما بتواند در صورت نیاز به پورت UDP یا TCP دسترسی داشته باشد. .PP بسیاری از نشانه‌های پیکربندی شرح داده شده در زیر دارای پیشوند برچسب '[snmp]' هستند. اگر این نشانه‌ها را در فایل snmpd.conf خود قرار دهید، این برچسب الزامی است. برای آگاهی از مفهوم این تغییر زمینه، صفحه راهنمای snmp_config(5) را ببینید. .IP "[snmp] localCert " این نشانه کلید عمومی پیش‌فرض X.509 را برای استفاده به‌عنوان هویت سرور تعریف می‌کند. این مقدار باید اثرانگشت یا نام یک فایل باشد. برای ایجاد یک کلید عمومی جهت استفاده، لطفاً ابزار "net\-snmp\-cert" را اجرا کنید که در ایجاد گواهی لازم به شما کمک خواهد کرد. .IP مقدار پیش‌فرض برای این مورد، گواهی موجود در فایل گواهی با نام "snmpd" است. .IP "[snmp] tlsAlgorithms " این رشته الگوریتم‌های مورد استفاده هنگام مذاکره امنیتی در زمان برقراری نشست (D)TLS را تعیین می‌کند. برای جزئیات مربوط به قالب، به صفحه راهنمای openssl برای ciphers(1) مراجعه کنید. نمونه رشته‌ها عبارتند از: .RS .nf DEFAULT ALL HIGH HIGH:!AES128\-SHA .fi .RE .IP مقدار پیش‌فرض همان مقداری است که خود openssl با آن پیکربندی شده است. .IP "[snmp] x509CRLFile" اگر از یک مرجع صدور گواهی (CA) استفاده می‌کنید که فهرست ابطال گواهی (CRL) را منتشر می‌کند، می‌توان از این نشانه برای مشخص کردن مکان نسخه‌ای از فایل CRL در فایل‌سیستم استفاده کرد. توجه داشته باشید که Net-SNMP فایل CRL را از طریق http دریافت نخواهد کرد و این مقدار حتماً باید یک فایل باشد، نه یک URL. علاوه بر این، OpenSSL هنگام تغییر فایل CRL آن را بازخوانی نمی‌کند، بنابراین اصلاحات یا به‌روزرسانی‌های فایل تنها پس از راه‌اندازی مجدد عامل snmpd اعمال خواهند شد. .IP "certSecName PRIORITY FINGERPRINT OPTIONS" مقدار OPTIONS می‌تواند یکی از <\-\-sn SECNAME | \-\-rfc822 | \-\-dns | \-\-ip | \-\-cn | \-\-any> باشد. .IP نشانه certSecName نحوه نگاشت یک فیلد از گواهی X.509 کلاینت به یک نام کاربری SNMPv3 را مشخص می‌کند. از پرچم \-\-sn SECNAME برای تعیین مستقیم یک securityName برای گواهی داده‌شده استفاده کنید. سایر پرچم‌ها مؤلفه خاصی از گواهی را برای استفاده به‌عنوان securityName در snmpv3 استخراج می‌کنند. این فیلدها یکی از این مواردند: یک SubjectAltName شامل مقدار rfc822 (مانند hardaker@net\-snmp.org)، یک SubjectAltName شامل یک مقدار نام dns (مانند foo.net\-snmp.org)، یک آدرس IP (مانند 192.0.2.1) یا یک نام معمول (common name) مانند "Wes Hardaker". پرچم \-\-any مشخص می‌کند که هر یک از فیلدهای subjecAltName قابل استفاده است. اطمینان حاصل کنید پس از انتخاب securityName، از طریق کنترل‌های VACM که در ادامه این صفحه راهنما بررسی می‌شوند، به آن مجوز دسترسی داده شود. .IP برای دستورالعمل‌های دقیق‌تر پیرامون برپایی (D)TLS، صفحه وب http://www.net\-snmp.org/wiki/index.php/Using_DTLS را مشاهده کنید. .IP "trustCert " برای اینکه X509 بتواند گواهی را به‌درستی اعتبارسنجی کند، گواهی باید تا لنگر اعتماد (trust anchor) مربوط به آن قابل تأیید باشد. این لنگر اعتماد معمولاً گواهی CA است، اما می‌تواند یک گواهی خودامضا نیز باشد. نشانه "trustCert" باید برای بارگذاری لنگرهای اعتماد مشخص در موتور اعتبارسنجی استفاده شود. .PP اجرای SNMP بر بستر (D)TLS نیازمند استفاده از مدل امنیت انتقال (TSM) است، بنابراین بخش مربوط به استفاده از Transport Security Model را نیز مطالعه کنید. هنگام پیکربندی VACM برای پذیرش اتصالات از (D)TLS، اطمینان حاصل کنید که از مدل امنیتی "tsm" استفاده می‌کنید؛ به عنوان مثال: .fi rwuser \-s tsm hardaker@net\-snmp.org .fi .SS پشتیبانی از SNMPv3 بر بستر SSH برای استفاده از SSH، باید sshd را برای فراخوانی برنامه sshtosnmp پیکربندی کنید و همچنین تنظیمات کنترل دسترسی را پیکربندی نمایید تا امکان دسترسی از طریق مدل امنیتی tsm با استفاده از نام کاربری ارائه‌شده به snmpd توسط انتقال ssh فراهم شود. .SS SNMPv3 با مدل امنیت انتقال (TSM) مدل امنیت انتقال [RFC5591] یک سامانه امنیتی SNMPv3 را برای استفاده با پروتکل‌های امنیتی «تونل‌شده» مانند TLS، DTLS و SSH تعریف می‌کند. این مدل، یک مدل امنیتی بسیار ساده است که صرفاً به بسته‌هایی که به‌درستی محافظت شده‌اند اجازه می‌دهد وارد برنامه snmp شوند. لایه انتقال موظف است یک securityName را برای استفاده به TSM تحویل دهد و TSM می‌تواند به‌صورت اختیاری یک رشته مربوط به لایه انتقال را به عنوان پیشوند به آن اضافه کند (به زیر مراجعه کنید). .IP "tsmUseTransportPrefix (1|yes|true|0|no|false)" اگر روی true تنظیم شود، ماژول TSM هر securityName ارسالی از لایه‌های انتقال زیرین را دریافت کرده و رشته‌ای را که مشخصاً تعیین‌کننده لایه انتقال مبدأ است، پیشوند آن قرار می‌دهد. این ویژگی برای جلوگیری از تداخل securityNameها در لایه‌های انتقالی که نام‌های امنیتی یکسان تولید می‌کنند مفید است. به عنوان مثال، اگر انتقال امنیتی ssh نام امنیتی "hardaker" را برای یک اتصال SSH تحویل دهد و انتقال امنیتی TLS نیز نام امنیتی "hardaker" را برای یک اتصال TLS ارائه دهد، تفکیک این دو کاربر برای ارائه حقوق کنترل دسترسی مجزا غیرممکن خواهد بود. با این حال، با تنظیم tsmUseTransportPrefix روی true، نام‌های امنیتی به‌طور مناسب با یکی از پیشوندهای "tls:"، "dtls:" یا "ssh:" مشخص می‌شوند. .SS SNMPv3 با مدل امنیت مبتنی بر کاربر (USM) پروتکل SNMPv3 در ابتدا با استفاده از مدل امنیت مبتنی بر کاربر (USM) تعریف شد که شامل فهرستی خصوصی از کاربران و کلیدهای مختص پروتکل SNMPv3 است. با این حال، جامعه عملیاتی مدیریت یک پایگاه داده دیگر را دشوار دانست و ترجیح داد از زیرساخت‌های موجود استفاده کند. بدین منظور، IETF کارگروه ISMS را برای مقابله با این مشکل تشکیل داد و کارگروه ISMS تصمیم گرفت SNMP را بر بستر SSH و DTLS تونل کند تا از زیرساخت‌های کاربری و احراز هویت موجود بهره ببرد. .SS کاربران USM در SNMPv3 برای استفاده از کاربران مبتنی بر USM مختص SNMPv3، لازم است آن‌ها را بسازید. توصیه می‌شود .B "از دستور net\-snmp\-config استفاده کنید" تا این کار انجام شود، اما می‌توانید خودتان نیز با مشخص کردن مستقیم دستورالعمل‌های createUser این کار را انجام دهید: .IP "createUser [\-e ENGINEID] username (MD5|SHA|SHA-512|SHA-384|SHA-256|SHA-224) authpassphrase [DES|AES] [privpassphrase]" .IP موارد MD5|SHA|SHA-512|SHA-384|SHA-256|SHA-224 انواع احراز هویت مورد استفاده هستند. DES و AES پروتکل‌های حریم خصوصی مورد استفاده می‌باشند. اگر عبارت عبور حریم خصوصی مشخص نشود، همان عبارت عبور احراز هویت در نظر گرفته می‌شود. توجه داشته باشید کاربران ایجادشده بی‌استفاده خواهند بود مگر اینکه به جدول‌های کنترل دسترسی VACM که پیش‌تر شرح داده شد نیز افزوده شوند. .IP احراز هویت SHA|SHA-512|SHA-384|SHA-256|SHA-224 و حریم خصوصی DES/AES نیازمند نصب بودن OpenSSL و کامپایل عامل با پشتیبانی از OpenSSL هستند. احراز هویت MD5 می‌تواند بدون OpenSSL استفاده شود. .IP هشدار: حداقل طول عبارت عبور ۸ نویسه است. .IP کاربران SNMPv3 را می‌توان در زمان اجرا با استفاده از دستور .I snmpusm(1) ایجاد کرد. .IP به جای تلاش برای درک چگونگی استفاده از این دستورالعمل و محل قرار دادن آن (به زیر مراجعه کنید)، فقط کافی است "net\-snmp\-config \-\-create\-snmpv3\-user" را اجرا کنید که یکی از این خطوط را در مکان مناسب اضافه خواهد کرد. .IP این دستورالعمل باید به جای سایر مکان‌های معمول، در فایل /var/net-snmp/snmpd.conf قرار گیرد. دلیل این است که اطلاعات از فایل خوانده شده و سپس این خط حذف می‌شود (تا از ذخیره‌سازی گذرواژه اصلی برای آن کاربر جلوگیری شود) و کلید مشتق‌شده از آن جایگزین می‌گردد. این کلید، یک کلید بومی‌سازی‌شده (localized) است؛ بنابراین در صورت به سرقت رفتن، نمی‌توان از آن برای دسترسی به سایر عامل‌ها استفاده کرد. با این حال، در صورت سرقت گذرواژه، چنین دسترسی‌ای ممکن خواهد بود. .IP اگر لازم است کاربر را برای یک EngineID خاص بومی‌سازی کنید (این امر بیشتر در فایل مشابه snmptrapd.conf کاربرد دارد)، می‌توانید از آرگومان \-e برای تعیین یک EngineID به صورت مقدار هگزادسیمال (مانند "0x01020304") استفاده کنید. .IP اگر می‌خواهید کلیدهای اصلی یا بومی‌سازی‌شده خود را مستقیماً تولید کنید، گذرواژه داده‌شده را با یک رشته هگزادسیمال (با پیشوند "0x") جایگزین کرده و به ترتیب یک نشانه \-m یا \-l را قبل از رشته هگزادسیمال قرار دهید. به عنوان مثال: .IP .RS .nf [these keys are *not* secure but are easy to visually parse for counting purposes. Please generate random keys instead of using these examples] createUser myuser SHA \-l 0x0001020304050607080900010203040506070809 AES \-l 0x00010203040506070809000102030405 createUser myuser SHA \-m 0x0001020304050607080900010203040506070809 AES \-m 0x0001020304050607080900010203040506070809 .fi .RE .IP به دلیل نحوه انجام بومی‌سازی، انتظار می‌رود کلیدهای حریم خصوصی بومی‌سازی‌شده دارای طولی باشند که الگوریتم نیاز دارد (۱۲۸ بیت برای تمام الگوریتم‌های پشتیبانی‌شده). با این حال، کلیدهای رمزنگاری اصلی باید به اندازه طول مورد نیاز الگوریتم احراز هویت باشند، نه طول مورد نیاز الگوریتم رمزنگاری (در MD5 برابر ۱۶ بایت، در SHA برابر ۲۰ بایت). .SH "کنترل دسترسی (ACCESS CONTROL)" .B snmpd از مدل کنترل دسترسی مبتنی بر نما (VACM) همان‌طور که در RFC 2575 تعریف شده است، برای کنترل این‌که چه کسی می‌تواند اطلاعات را بازیابی یا به‌روزرسانی کند، پشتیبانی می‌کند. برای این منظور، دستورالعمل‌های گوناگونی را در رابطه با کنترل دسترسی شناسایی می‌کند. .SS "کنترل دسترسی سنتی (Traditional Access Control)" بیشتر نیازمندی‌های سادهٔ کنترل دسترسی را می‌توان با استفاده از دستورالعمل‌های \fIrouser\fR/\fIrwuser\fR (برای SNMPv3) یا \fIrocommunity\fR/\fIrwcommunity\fR (برای SNMPv1 یا SNMPv2c) مشخص کرد. .IP "rouser [\-s SECMODEL] USER [noauth|auth|priv [OID | \-V VIEW [CONTEXT]]]" .IP "rwuser [\-s SECMODEL] USER [noauth|auth|priv [OID | \-V VIEW [CONTEXT]]]" کاربری SNMPv3 را مشخص می‌کنند که به ترتیب دسترسی فقط‌خواندنی (GET و GETNEXT) یا خواندنی-نوشتنی (GET، GETNEXT و SET) خواهد داشت. به‌طور پیش‌فرض، این دستور امکان دسترسی به کل درخت OID را برای درخواست‌های احراز هویت‌شدهٔ SNMPv3 (شامل رمزگذاری‌شده)، با استفاده از زمینه پیش‌فرض فراهم می‌کند. سطح امنیتی حداقلِ جایگزین را می‌توان با استفاده از \fInoauth\fR (برای مجاز کردن درخواست‌های بدون احراز هویت) یا \fIpriv\fR (برای اجبار به استفاده از رمزگذاری) مشخص کرد. فیلد OID دسترسی این کاربر را به زیردرخت ریشه‌دار در OID داده‌شده یا نمای نام‌گذاری‌شده محدود می‌کند. همچنین می‌توان یک زمینه اختیاری یا "context*" را برای نشان دادن پیشوند زمینه مشخص کرد. اگر هیچ فیلد زمینه‌ای مشخص نشده باشد (یا از نشانه "*" استفاده شود)، دستورالعمل با تمام زمینه‌های ممکن مطابقت خواهد داشت. .IP اگر SECMODEL مشخص شده باشد، مدل امنیتی مورد نیاز برای آن کاربر خواهد بود (توجه داشته باشید که نام‌های کاربری یکسان ممکن است از طریق مدل‌های امنیتی متفاوتی وارد شوند و از طریق تنظیمات کنترل دسترسی به‌طور مناسب تفکیک خواهند شد). مدل امنیتی پیش‌فرض "usm" است و سایر مدل‌های امنیتی متداول احتمالاً در صورت استفاده از پشتیبانی (D)TLS یا SSH برابر با "tsm"، و در صورت کامپایل شدن پشتیبانی Kerberos برابر با "ksm" هستند. .IP "rocommunity COMMUNITY [SOURCE [OID | \-V VIEW [CONTEXT]]]" .IP "rwcommunity COMMUNITY [SOURCE [OID | \-V VIEW [CONTEXT]]]" یک کامیونیتی SNMPv1 یا SNMPv2c را مشخص می‌کنند که به ترتیب دسترسی فقط‌خواندنی (GET و GETNEXT) یا خواندنی-نوشتنی (GET، GETNEXT و SET) خواهد داشت. به‌طور پیش‌فرض، این گزینه دسترسی به کل درخت OID را برای چنین درخواست‌هایی، صرف‌نظر از این‌که از کجا ارسال شده‌اند، فراهم می‌کند. توکن SOURCE می‌تواند برای محدود کردن دسترسی به درخواست‌های سیستم(های) مشخص‌شده به کار رود - برای جزئیات کامل \fIcom2sec\fR را ببینید. فیلد OID دسترسی آن کامیونیتی را به زیردرخت ریشه‌دار در OID داده‌شده یا نمای نام‌گذاری‌شده محدود می‌کند. زمینه‌ها معمولاً در نسخه‌های مبتنی بر کامیونیتی SNMP کاربرد کمتری دارند، اما همین رفتار در اینجا نیز اعمال می‌شود. .IP "rocommunity6 COMMUNITY [SOURCE [OID | \-V VIEW [CONTEXT]]]" .IP "rwcommunity6 COMMUNITY [SOURCE [OID | \-V VIEW [CONTEXT]]]" دستورالعمل‌های مربوط به درخواست‌های دریافتی با استفاده از IPv6 هستند (اگر عامل از چنین دامنه‌های انتقالی پشتیبانی کند). تفسیر توکن‌های SOURCE، OID، VIEW و CONTEXT دقیقاً همانند نسخه‌های IPv4 است. .PP در هر مورد، تنها باید یک دستورالعمل برای کاربر مشخص SNMPv3 یا رشته کامیونیتی تعیین شود. مشخص کردن هم‌زمان هر دو دستورالعمل \fIrouser\fR و \fIrwuser\fR با اشاره به یک کاربر SNMPv3 یکسان (یا تنظیمات کامیونیتی معادل) مناسب \fBنیست\fR. دستورالعمل \fIrwuser\fR تمامی دسترسی‌های \fIrouser\fR را فراهم می‌کند (و علاوه بر آن پشتیبانی از SET را نیز مجاز می‌سازد). همین امر برای دستورالعمل‌های مبتنی بر کامیونیتی نیز صدق می‌کند. .PP نیازمندی‌های دسترسی پیچیده‌تر (مانند دسترسی به دو یا چند زیردرخت مجزای OID، یا نماهای متفاوت برای درخواست‌های GET و SET) باید از یکی از سازوکارهای دیگر کنترل دسترسی استفاده کنند. توجه داشته باشید که اگر چندین کامیونیتی یا کاربر SNMPv3 مجزا نیاز به سطح دسترسی یکسانی داشته باشند، استفاده از دستورالعمل‌های پیکربندی اصلی VACM کارآمدتر خواهد بود. .SS "پیکربندی VACM (VACM Configuration)" انعطاف‌پذیری کامل VACM با استفاده از چهار دستورالعمل پیکربندی در دسترس است \- \fIcom2sec\fR، \fIgroup\fR، \fIview\fR و \fIaccess\fR. این دستورالعمل‌ها پیکربندی مستقیم جدول‌های زیرین VACM را امکان‌پذیر می‌سازند. .IP "com2sec [\-Cn CONTEXT] SECNAME SOURCE COMMUNITY" .IP "com2sec6 [\-Cn CONTEXT] SECNAME SOURCE COMMUNITY" یک رشته کامیونیتی SNMPv1 یا SNMPv2c را به یک نام امنیتی نگاشت می‌کنند - خواه از محدودهٔ خاصی از آدرس‌های مبدأ، یا به‌طور سراسری (\fI"default"\fR). مبدأ محدودشده می‌تواند یک نام میزبان خاص (یا آدرس) یا یک زیرشبکه باشد - که به صورت IP/MASK (مانند 10.10.10.0/255.255.255.0) یا IP/BITS (مانند 10.10.10.0/24) یا معادل‌های IPv6 نمایش داده می‌شود. محدودیتی که قبل از آن علامت تعجب (!) آمده باشد، دسترسی از آن آدرس یا زیرشبکه را رد می‌کند؛ برای مثال، ‎!10.10.10.0/24 درخواست‌ها را از مبدأهای آن زیرشبکه رد می‌کند. محدودیت‌های رد باید پیش از مجوزها قرار گیرند. برای نمونه، مثال زیر دسترسی از تمام 10.0.0.0/8 را به جز 10.10.10.0/24 مجاز می‌کند: .RS .RS com2sec sec1 !10.10.10.0/24 public .br com2sec sec1 10.0.0.0/8 public .RE .RE .IP دسترسی از خارج از 10.0.0.0/8 همچنان رد خواهد شد. .IP یک رشته کامیونیتی یکسان می‌تواند در چندین دستورالعمل جداگانه (احتمالاً با توکن‌های مبدأ متفاوت) مشخص شود و اولین ترکیب مبدأ/کامیونیتی که با درخواست ورودی مطابقت داشته باشد، انتخاب خواهد شد. ترکیب‌های گوناگون مبدأ/کامیونیتی همچنین می‌توانند به یک نام امنیتی یکسان نگاشت شوند. .IP اگر CONTEXT (با استفاده از \fI\-Cn\fR) مشخص شود، رشته کامیونیتی به یک نام امنیتی در زمینه مشخص‌شدهٔ SNMPv3 نگاشت می‌شود. در غیر این صورت، از زمینه پیش‌فرض ("") استفاده خواهد شد. .IP "com2secunix [\-Cn CONTEXT] SECNAME SOCKPATH COMMUNITY" نسخهٔ سوکت‌های دامنه یونیکس از دستور \fIcom2sec\fR است. .IP "group GROUP {v1|v2c|usm|tsm|ksm} SECNAME" یک نام امنیتی (در مدل امنیتی مشخص‌شده) را به یک گروه نام‌گذاری‌شده نگاشت می‌کند. چندین دستورالعمل \fIgroup\fR می‌توانند نام گروه یکسانی را مشخص کنند و به یک تنظیم دسترسی منفرد اجازه می‌دهند بر روی چندین کاربر و/یا رشته کامیونیتی اعمال شود. .IP توجه داشته باشید که گروه‌ها باید برای دو مدل مبتنی بر کامیونیتی به‌طور جداگانه تنظیم شوند - معمولاً یک دستورالعمل منفرد \fIcom2sec\fR (یا معادل آن) با \fBدو\fR دستورالعمل \fIgroup\fR همراه خواهد بود. .IP "view VNAME TYPE OID [MASK]" یک «نما» نام‌گذاری‌شده را تعریف می‌کند - زیرمجموعه‌ای از کل درخت OID. این معمولاً یک زیردرخت تکی است، اما چندین دستورالعمل \fIview\fR را می‌توان با یک نام نمای یکسان (VNAME) ارائه کرد تا مجموعهٔ پیچیده‌تری از OIDها ساخته شود. شناسه TYPE می‌تواند \fIincluded\fR یا \fIexcluded\fR باشد که باز هم می‌تواند نمای پیچیده‌تری را تعریف کند (برای مثال با مستثنا کردن اشیاء حساس خاص از زیردرختی که در غیر این صورت قابل دسترسی است). .IP شناسه MASK فهرستی از بایت‌های هگزادسیمال (اختیاری با تفکیک '.' یا ':') است که بیت‌های فعال نشان می‌دهند کدام شناسه‌های فرعی در OID نما برای تطبیق مقایسه شوند. در صورت عدم تعیین، مقدار پیش‌فرض تطبیق دقیق OID (تمام بیت‌ها فعال) است و بدین ترتیب یک زیردرخت OID ساده را تعریف می‌کند. بنابراین: .RS .RS view iso1 included .iso 0xf0 .br view iso2 included .iso .br view iso3 included .iso.org.dod.mgmt 0xf0 .RE .RE .IP همگی یک نمای یکسان را تعریف می‌کنند که کل زیردرخت 'iso(1)' را پوشش می‌دهد (با این تفاوت که مثال سوم شناسه‌های فرعی را که توسط ماسک پوشش داده نشده‌اند نادیده می‌گیرد). .IP به شکل کاربردی‌تر، می‌توان از ماسک برای تعریف نمایی استفاده کرد که یک سطر خاص (یا سطرهایی) از جدول را با تطبیق با مقدار شاخص مناسب جدول، اما نادیده گرفتن شناسهٔ فرعی ستون، پوشش دهد: .RS .RS .IP "view ifRow4 included .1.3.6.1.2.1.2.2.1.0.4 0xff:a0" .RE .RE .IP توجه داشته باشید که ماسک طولانی‌تر از ۸ بیت باید از ':' برای تفکیک بایت‌ها استفاده کند. .IP "access GROUP CONTEXT {any|v1|v2c|usm|tsm|ksm} LEVEL PREFX READ WRITE NOTIFY" نگاشتی از یک گروهِ کاربران/کامیونیتی‌ها (با مدل امنیتی خاص و حداقل سطح امنیتی، و در یک زمینه مشخص) به یکی از سه نما، بسته به درخواستی که پردازش می‌شود، انجام می‌دهد. .IP شناسه LEVEL یکی از مقادیر \fInoauth\fR، \fIauth\fR، یا \fIpriv\fR است. شناسه PREFX مشخص می‌کند که CONTEXT چگونه با زمینه درخواست ورودی مطابقت داده شود؛ یا \fIexact\fR یا \fIprefix\fR. شناسه‌های READ، WRITE و NOTIFY نمایی را مشخص می‌کنند که باید برای درخواست‌های *GET، SET و TRAP/INFORM استفاده شود (اگرچه نمای NOTIFY در حال حاضر استفاده نمی‌شود). برای دسترسی v1 یا v2c، مقدار LEVEL باید \fInoauth\fR باشد. .SS "پیکربندی نمای نوع‌دار (Typed-View Configuration)" گروه پایانی دستورالعمل‌ها، رویکرد VACM را به سازوکاری انعطاف‌پذیرتر گسترش می‌دهند که می‌تواند برای سایر نیازمندی‌های کنترل دسترسی به کار رود. به جای سه نمای ثابت در سازوکار استاندارد VACM، این روش می‌تواند برای پیکربندی انواع مختلف نماها استفاده شود. تا جایی که به عامل اصلی SNMP مربوط است، دو نوع نمای اصلی \fIread\fR و \fIwrite\fR هستند که با نماهای READ و WRITE در دستورالعمل اصلی \fIaccess\fR مطابقت دارند. برای بررسی سایر انواع نما، صفحه راهنمای 'snmptrapd.conf(5)' را ببینید. .IP "authcommunity TYPES COMMUNITY [SOURCE [OID | \-V VIEW [CONTEXT]]]" جایگزینی برای دستورالعمل‌های \fIrocommunity\fR/\fIrwcommunity\fR است. شناسه TYPES معمولاً به ترتیب \fIread\fR یا \fIread,write\fR خواهد بود. مشخصات نما برای انعطاف‌پذیری بیشتر می‌تواند یک زیردرخت OID (مانند قبل) یا یک نمای نام‌گذاری‌شده (تعریف‌شده با دستورالعمل \fIview\fR) باشد. اگر این مقدار حذف شود، دسترسی به کل درخت OID مجاز خواهد بود. اگر CONTEXT مشخص شود، دسترسی در این زمینه SNMPv3 پیکربندی می‌شود. در غیر این صورت از زمینه پیش‌فرض ("") استفاده می‌شود. .IP "authuser TYPES [\-s MODEL] USER [LEVEL [OID | \-V VIEW [CONTEXT]]]" جایگزینی برای دستورالعمل‌های \fIrouser\fR/\fIrwuser\fR است. فیلدهای TYPES، OID، VIEW و CONTEXT همان معنای موجود در \fIauthcommunity\fR را دارند. .IP "authgroup TYPES [\-s MODEL] GROUP [LEVEL [OID | \-V VIEW [CONTEXT]]]" مکملی برای دستورالعمل \fIauthuser\fR است که دسترسی را برای یک گروه خاص (تعریف‌شده با استفاده از دستورالعمل معمول \fIgroup\fR) مشخص می‌کند. هر دو دستور \fIauthuser\fR و \fIauthgroup\fR به‌طور پیش‌فرض برای درخواست‌های احراز هویت‌شده هستند - شناسه LEVEL همچنین می‌تواند به صورت \fInoauth\fR یا \fIpriv\fR مشخص شود تا به ترتیب درخواست‌های بدون احراز هویت را مجاز کند یا به رمزگذاری نیاز داشته باشد. هر دو دستورالعمل \fIauthuser\fR و \fIauthgroup\fR همچنین به‌طور پیش‌فرض دسترسی را برای درخواست‌های SNMPv3/USM پیکربندی می‌کنند - از فلگ '\-s' برای تعیین مدل امنیتی جایگزین (با استفاده از مقادیر مشابه \fIaccess\fR در بالا) استفاده کنید. .IP "authaccess TYPES [\-s MODEL] GROUP VIEW [LEVEL [CONTEXT]]" همچنین دسترسی را برای یک گروه خاص، با مشخص کردن نام و نوع نمای اعمالی، پیکربندی می‌کند. فیلدهای MODEL و LEVEL به همان شیوهٔ \fIauthgroup\fR تفسیر می‌شوند. اگر CONTEXT مشخص شده باشد، دسترسی درون این زمینه SNMPv3 (یا زمینه‌های دارای این پیشوند اگر فیلد CONTEXT با '*' خاتمه یابد) پیکربندی می‌شود. در غیر این صورت، از زمینه پیش‌فرض ("") استفاده خواهد شد. .IP "setaccess GROUP CONTEXT MODEL LEVEL PREFIX VIEW TYPES" معادل مستقیم دستورالعمل اصلی \fIaccess\fR است که معمولاً انواع نما را بر حسب مورد به صورت \fIread\fR یا \fIread,write\fR فهرست می‌کند (یا برای سایر حالت‌ها 'snmptrapd.conf(5)' را ببینید). تمام فیلدهای دیگر تفسیر یکسانی با \fIaccess\fR دارند. .SH "اطلاعات سیستم (SYSTEM INFORMATION)" بیشتر اطلاعات گزارش‌شده توسط عامل Net-SNMP از سیستم زیرین بازیابی می‌شود، یا به صورت پویا از طریق درخواست‌های SNMP SET پیکربندی می‌گردد (و از یک اجرای عامل تا اجرای بعدی حفظ می‌شود). با این حال، برخی از اشیاء MIB را می‌توان از طریق فایل \fIsnmpd.conf(5)\fR پیکربندی یا کنترل کرد. .SS "گروه سیستم (System Group)" بیشتر اشیاء اسکالر در گروه 'system' را می‌توان به این روش پیکربندی کرد: .IP "sysLocation STRING" .IP "sysContact STRING" .IP "sysName STRING" به ترتیب مکان سیستم، رابط تماس سیستم یا نام سیستم (\fCsysLocation.0\fR، \fCsysContact.0\fR و \fCsysName.0\fR) را برای عامل تنظیم می‌کنند. به‌طور معمول این اشیاء از طریق درخواست‌های مجاز SNMP SET قابل نوشتن هستند. با این وجود، مشخص کردن یکی از این دستورالعمل‌ها شیء مربوطه را فقط‌خواندنی می‌کند و تلاش برای اجرای SET روی آن به خطای \fInotWritable\fR منجر خواهد شد. .IP "sysServices NUMBER" مقدار شیء \fCsysServices.0\fR را تنظیم می‌کند. برای یک سیستم میزبان، مقدار مناسب 72 (لایه‌های کاربرد + سرتاسر / application + end-to-end) است. اگر این دستورالعمل مشخص نشود، هیچ مقداری برای شیء \fCsysServices.0\fR گزارش نخواهد شد. .IP "sysDescr STRING" .IP "sysObjectID OID" توضیحات سیستم یا شناسه شیء (OID) را برای عامل تنظیم می‌کنند. اگرچه این اشیاء MIB از طریق SNMP قابل نوشتن نیستند، مدیر شبکه می‌تواند از این دستورالعمل‌ها برای پیکربندی مقادیر مناسب برای آن‌ها استفاده کند. .SS "گروه رابط‌ها (Interfaces Group)" .IP "interface NAME TYPE SPEED" می‌تواند برای ارائه تنظیمات نوع و سرعت مناسب برای رابط‌هایی که عامل در تشخیص صحیح اطلاعات آن‌ها ناموفق است، استفاده شود. TYPE مقداری از نوع ارائه‌شده در IANAifType\-MIB است و می‌توان آن را به‌صورت عددی یا با نام مشخص کرد (به شرطی که این MIB بارگذاری شده باشد). .IP "interface_fadeout TIMEOUT" مشخص می‌کند عامل تا چه مدت پس از حذف رابط‌های مربوطه از سیستم (معمولاً رابط‌های گوناگون ppp، tap یا tun)، ورودی‌های آن‌ها را در \fCifTable\fR نگه می‌دارد. مقدار وقفه زمانی به ثانیه است. مقدار پیش‌فرض 300 (=5 دقیقه) است. .IP "interface_replace_old yes" می‌تواند برای حذف ورودی‌های موجود در \fCifTable\fR هنگام ظاهر شدن رابطی با همان نام در سیستم استفاده شود. به عنوان مثال، هنگامی که رابط ppp0 حذف می‌شود، همچنان به مدت \fIinterface_fadeout\fR ثانیه در جدول فهرست می‌شود. این گزینه تضمین می‌کند که با ظاهر شدن ppp0 جدید (با \fCifIndex\fR متفاوت)، رابط قبلی ppp0 حتی پیش از پایان مهلت زمانی \fIinterface_fadeout\fR حذف گردد. .SS "گروه منابع میزبان (Host Resources Group)" این نیازمند آن است که عامل با پشتیبانی از ماژول \fIhost\fR ساخته شده باشد (که اکنون بخشی از پیکربندی ساخت پیش‌فرض در پلتفرم‌های اصلی پشتیبانی‌شده است). .\" .\" XXX - .IP "scandisk STRING" .\" .IP "ignoreDisk STRING" کنترل می‌کند کدام دستگاه‌های دیسک به عنوان بخشی از پر کردن \fChrDiskStorageTable\fR (و \fChrDeviceTable\fR) پویش شوند. کد پیاده‌سازی HostRes شامل فهرستی از الگوهای دستگاه‌های دیسک مناسب برای سیستم‌عامل فعلی است، که برخی از آن‌ها ممکن است هنگام تلاش عامل برای باز کردن دستگاه‌های دیسک مربوطه باعث مسدود شدن آن شوند. این امر ممکن است منجر به اتمام مهلت زمانی (timeout) هنگام پیمایش این جدول‌ها شده و احتمالاً رفتاری متناقض به همراه داشته باشد. از این دستورالعمل می‌توان برای مشخص کردن دستگاه‌های خاص (به صورت تکی یا با الگوهای wildcard) که نباید بررسی شوند، استفاده کرد. .RS .IP "نکته:" لطفاً به سورس‌کد (\fIhost/hr_disk.c\fR) مراجعه کرده و فراخوانی‌های \fIAdd_HR_Disk_entry\fR مرتبط با یک سیستم‌عامل خاص را برای تعیین فهرست دستگاه‌هایی که پویش می‌شوند بررسی کنید. .RE .IP الگو می‌تواند شامل یک یا چند عبارت عمومی (wildcard) باشد. برای مشاهده ساختار عبارات عمومی به \fIsnmpd.examples(5)\fR مراجعه کنید. .IP "ignoremount [-r] STRING" کنترل می‌کند کدام اتصالات (mounts) باید از hrStorageTable حذف شوند. اگر عامل Net-SNMP هنگام دسترسی به یک سیستم فایل متوقف (hang) شود، یا سیستم فایل همیشه تقریباً پر باشد (و بنابراین به هشدارهای کاذب منجر گردد)، می‌توانید با ذکر مسیر کامل در این دستورالعمل، آن را حذف کنید. .RE .IP اگر گزینه "-r" ارائه شود، الگو می‌تواند شامل یک یا چند عبارت باقاعده (regular expression) باشد. .IP "skipNFSInHostResources true" کنترل می‌کند که آیا سیستم‌های فایل NFS و مشابه NFS باید از hrStorageTable حذف شوند (true یا 1) یا خیر (false یا 0، که پیش‌فرض است). اگر عامل Net-SNMP روی سیستم‌های فایل متصل‌شده از طریق NFS متوقف شود، می‌توانید تنظیم آن روی '1' را امتحان کنید. .RE .IP به عنوان روشی جایگزین، کنترل دقیق‌تر بر اینکه کدام اتصالات باید از hrStorageTable حذف شوند از طریق دستورالعمل \fIignoremount\fR قابل دستیابی است. .IP "storageUseNFS [1|2]" نحوه گزارش سیستم‌های فایل NFS و مشابه NFS در hrStorageTable را کنترل می‌کند: به عنوان 'Network Disks' (1) یا 'Fixed Disks' (2). از نظر تاریخی، عامل Net-SNMP چنین سیستم‌های فایلی را به عنوان 'Fixed Disks' گزارش می‌کرد و این همچنان رفتار پیش‌فرض است. تنظیم این دستورالعمل روی '1' این سیستم‌های فایل را طبق نیازمندی‌های Host Resources MIB به عنوان 'Network Disks' گزارش می‌کند. .IP "realStorageUnits" نحوه گزارش hrStorageAllocationUnits ،hrStorageSize و hrStorageUsed در hrStorageTable توسط عامل را کنترل می‌کند. برای فضاهای ذخیره‌سازی بزرگ با واحدهای تخصیص کوچک، عامل این مقادیر را مجدداً محاسبه می‌کند تا همگی در Integer32 بگنجند و hrStorageAllocationUnits x hrStorageSize اندازه واقعی فضای ذخیره‌سازی را ارائه دهد. .RS .IP "مثال:" یک سیستم فایل xfs لینوکس 16TB با بلوک‌های بزرگ 4096 بایتی به صورت hrStorageAllocationUnits = 8192 و hrStorageSize = 2147483647 گزارش خواهد شد، بنابراین 8192 x 2147483647 اندازه واقعی سیستم فایل (=16 TB) را به دست می‌دهد. .RE .IP تنظیم این دستورالعمل روی '1' این محاسبه را غیرفعال می‌کند و عامل مقدار واقعی hrStorageAllocationUnits را گزارش می‌دهد، اما ممکن است برای درایوهای بزرگ مقدار hrStorageSize نادرستی گزارش دهد زیرا این مقدار در Integer32 نمی‌گنجد. در این حالت، hrStorageAllocationUnits x hrStorageSize اندازه واقعی فضای ذخیره‌سازی را ارائه نخواهد داد. .SS "نظارت بر فرآیندها (Process Monitoring)" گروه \fChrSWRun\fR از Host Resources MIB اطلاعاتی درباره تک‌تک فرآیندهای در حال اجرا روی سیستم محلی ارائه می‌دهد. جدول \fCprTable\fR از UCD\-SNMP\-MIB با گزارش درباره سرویس‌های انتخاب‌شده (که ممکن است شامل چندین فرآیند باشند) این را تکمیل می‌کند. این نیازمند آن است که عامل با پشتیبانی از ماژول \fIucd\-snmp/proc\fR ساخته شده باشد (که به عنوان بخشی از پیکربندی ساخت پیش‌فرض گنجانده شده است). .IP "proc NAME [MAX [MIN]]" تعداد فرآیندهایی به نام NAME (طبق گزارش " -acx") را که روی سیستم محلی در حال اجرا هستند، پایش می‌کند. .IP اگر تعداد فرآیندهای NAME کمتر از MIN یا بیشتر از MAX باشد، نمونه \fCprErrorFlag\fR مربوطه روی 1 تنظیم شده و پیام توصیفی مناسبی از طریق نمونه \fCprErrMessage\fR گزارش می‌شود. .RS .IP "نکته:" این وضعیت به طور خودکار تله‌ای (trap) را برای گزارش مشکل ایجاد \fBنمی‌کند\fR - به بخش DisMan Event MIB در ادامه مراجعه کنید. .RE .IP اگر نه MAX و نه MIN مشخص نشده باشند، به ترتیب به \fBinfinity\fR و 1 پیش‌فرض می‌شوند ("حداقل یکی"). اگر فقط MAX مشخص شده باشد، MIN به 0 پیش‌فرض می‌شود ("نه بیشتر از MAX"). اگر MAX برابر با 0 باشد (و MIN نباشد)، این نشان‌دهنده بی‌نهایت است ("حداقل MIN"). اگر هر دو مقدار MAX و MIN برابر با 0 باشند، این نشان‌دهنده فرآیندی است که \fBنباید\fP در حال اجرا باشد. .IP "procfix NAME PROG ARGS" دستوری را ثبت می‌کند که می‌تواند برای رفع خطاهای فرآیند با NAME داده‌شده اجرا شود. این دستور زمانی فراخوانی می‌شود که نمونه \fCprErrFix\fR مربوطه روی 1 تنظیم شود. .RS .IP "نکته:" این دستور به طور خودکار فراخوانی \fBنخواهد شد\fR. .\" XXX - but see the DisMan Event MIB section later ??? .RE .IP دستورالعمل \fIprocfix\fR باید \fBبعد از\fR دستورالعمل \fIproc\fR متناظر مشخص شود، و نمی‌توان آن را به تنهایی استفاده کرد. .PP اگر هیچ دستورالعمل \fIproc\fR تعریف نشده باشد، پیمایش \fCprTable\fR با شکست مواجه خواهد شد (\fInoSuchObject\fI). .SS پایش مصرف دیسک (Disk Usage Monitoring) این ویژگی مستلزم آن است که عامل با پشتیبانی از ماژول \fIucd\-snmp/disk\fR ساخته شده باشد (که به عنوان بخشی از پیکربندی پیش‌فرض ساخت گنجانده شده است). .IP "disk PATH [ MINSPACE | MINPERCENT% ]" دیسک سوارشده در PATH را برای فضای دیسک موجود پایش می‌کند. دیسک‌هایی که پس از شروع به کار عامل سوار شده‌اند پایش نخواهند شد، مگر اینکه گزینه \fIincludeAllDisks\fR مشخص شده باشد. .IP حداقل آستانه را می‌توان بر حسب کیلوبایت (MINSPACE) یا به صورت درصدی از کل دیسک (MINPERCENT% همراه با نویسه '%') تعیین کرد؛ در صورتی که هیچ‌کدام مشخص نشوند، مقدار پیش‌فرض 100kB خواهد بود. اگر فضای خالی دیسک به زیر این آستانه کاهش یابد، نمونه \fCdskErrorFlag\fR متناظر برابر با 1 قرار می‌گیرد و پیام توصیفی مناسبی از طریق نمونه \fCdskErrorMsg\fR گزارش می‌شود. .RS .IP "نکته:" این وضعیت به طور خودکار تله‌ای (\fBtrap\fR) برای گزارش مشکل ارسال \fBنمی‌کند\fR - بعداً بخش DisMan Event MIB را ببینید. .RE .IP "includeAllDisks MINPERCENT%" پایش تمام دیسک‌های یافت‌شده در سیستم را با استفاده از آستانه مشخص‌شده (درصدی) پیکربندی می‌کند. جدول \fCdskTable\fR به‌صورت پویا به‌روزرسانی می‌شود؛ دیسک‌های پیاده‌شده از جدول حذف شده و دیسک‌های تازه سوارشده به جدول اضافه می‌شوند. آستانه مربوط به دیسک‌های جداگانه را می‌توان با استفاده از دستورالعمل‌های مناسب \fIdisk\fR (که می‌توانند قبل یا بعد از دستورالعمل \fIincludeAllDisks\fR بیایند) تنظیم کرد. .RS .IP "نکته:" اینکه دستورالعمل‌های \fIdisk\fR قبل یا بعد از \fIincludeAllDisks\fR بیایند، ممکن است بر نمایه‌سازی (indexing) جدول \fCdskTable\fR تأثیر بگذارد. .RE .IP تنها باید یک دستورالعمل \fIincludeAllDisks\fR مشخص شود - هرگونه نسخه‌های بعدی نادیده گرفته خواهند شد. .IP فهرست دیسک‌های سوارشده از HOST-RESOURCES-MIB::hrFSTable تعیین خواهد شد. .\" .\" XXX - unless the config is re-read ?? .\" .PP اگر هیچ‌کدام از دستورالعمل‌های \fIdisk\fR یا \fIincludeAllDisks\fR تعریف نشده باشند، پیمایش جدول \fCdskTable\fR با شکست مواجه خواهد شد (\fInoSuchObject\fI). .SS پایش ورودی/خروجی دیسک (Disk I/O Monitoring) این ویژگی مستلزم آن است که عامل با پشتیبانی از ماژول \fIucd\-snmp/diskio\fR ساخته شده باشد (که به عنوان بخشی از پیکربندی پیش‌فرض ساخت گنجانده نشده است). .PP به‌طور پیش‌فرض، تمام دستگاه‌های بلوکی شناخته‌شده برای سیستم‌عامل در diskIOTable گنجانده می‌شوند. در پلتفرم‌هایی غیر از Linux، این ماژول هیچ دستورالعمل پیکربندی ندارد. .PP در سیستم‌های Linux، امکان مستثنی کردن چندین رده از دستگاه‌های بلوکی از diskIOTable وجود دارد تا از شلوغ شدن جدول با آمارهای صفر بی‌فایده برای شبه‌دستگاه‌هایی که اغلب استفاده نمی‌شوند اما به‌طور پیش‌فرض در اکثر توزیع‌های اخیر Linux وجود دارند، جلوگیری شود. .IP "diskio_exclude_fd yes" تمام دستگاه‌های بلوکی فلاپی‌دیسک Linux را که نامشان با "fd" شروع می‌شود، مانند "fd0"، مستثنی می‌کند. .IP "diskio_exclude_loop yes" تمام دستگاه‌های بلوکی loopback در Linux را که نامشان با "loop" شروع می‌شود، مانند "loop0"، مستثنی می‌کند. .IP "diskio_exclude_ram yes" تمام دستگاه‌های بلوکی ramdisk در Linux را که نامشان با "ram" شروع می‌شود، مانند "ram0"، مستثنی می‌کند. .IP "diskio_exclude_md yes" تمام دستگاه‌های بلوکی RAID در Linux را که نامشان با "md" شروع می‌شود، مانند "md0"، مستثنی می‌کند. .PP در سیستم‌های Linux، همچنین این امکان وجود دارد که گزارش‌گیری صرفاً به دستگاه‌های موجود در لیست مجاز صریح محدود شود. پردازش داده‌های diskIOTable در سیستم‌هایی با ده‌ها هزار دستگاه بلوکی ممکن است زمان قابل‌توجهی ببرد و قرار دادن تنها دستگاه‌های مهم در لیست مجاز از مصرف بالای CPU جلوگیری می‌کند. .IP "diskio " لیست مجاز (acceptlist) دستگاه‌ها را فعال کرده و دستگاه مورد نظر را به آن اضافه می‌کند. تنها دستگاه‌هایی گزارش خواهند شد که به‌طور صریح در لیست مجاز باشند. این گزینه را می‌توان چندین بار استفاده کرد. .SS پایش بار سیستم (System Load Monitoring) این ویژگی مستلزم آن است که عامل به ترتیب با پشتیبانی از ماژول \fIucd\-snmp/loadave\fR یا ماژول \fIucd\-snmp/memory\fR ساخته شده باشد (که هر دو به عنوان بخشی از پیکربندی پیش‌فرض ساخت گنجانده شده‌اند). .IP "load MAX1 [MAX5 [MAX15]]" میانگین بار (load average) سیستم محلی را پایش می‌کند و آستانه‌هایی را برای میانگین‌های ۱ دقیقه، ۵ دقیقه و ۱۵ دقیقه مشخص می‌سازد. اگر هر یک از این بارها از مقدار حداکثر مربوطه فراتر رود، نمونه \fClaErrorFlag\fR متناظر برابر با 1 قرار می‌گیرد و پیام توصیفی مناسبی از طریق نمونه \fClaErrMessage\fR گزارش می‌شود. .RS .IP "نکته:" این وضعیت به طور خودکار تله‌ای (\fBtrap\fR) برای گزارش مشکل ارسال \fBنمی‌کند\fR - بعداً بخش DisMan Event MIB را ببینید. .RE .IP اگر آستانه MAX15 حذف شود، مقدار پیش‌فرض آن برابر با مقدار MAX5 خواهد بود. اگر هر دو مقدار MAX5 و MAX15 حذف شوند، پیش‌فرض آن‌ها برابر با مقدار MAX1 خواهد بود. اگر این دستورالعمل مشخص نشود، هر سه آستانه به مقدار DEFMAXLOADAVE پیش‌فرض می‌شوند. .IP اگر مقدار آستانه 0 تعیین شود، عامل صرف‌نظر از بار فعلی، خطاها را از طریق نمونه‌های مربوطه \fClaErrorFlag\fR یا \fClaErrMessage\fR گزارش نخواهد کرد. .PP بر خلاف دستورالعمل‌های \fIproc\fR و \fIdisk\fR، پیمایش جدول \fClaTable\fR با موفقیت انجام خواهد شد (با این فرض که ماژول \fIucd\-snmp/loadave\fR در عامل پیکربندی شده باشد)، حتی اگر دستورالعمل \fIload\fR وجود نداشته باشد. .IP "swap MIN " میزان فضای swap موجود در سیستم محلی را پایش می‌کند. اگر این مقدار به زیر آستانه مشخص‌شده (MIN کیلوبایت) کاهش یابد، شیء \fImemErrorSwap\fR برابر با 1 قرار می‌گیرد و پیام توصیفی مناسبی از طریق \fImemSwapErrorMsg\fR گزارش می‌شود. .RS .IP "نکته:" این وضعیت به طور خودکار تله‌ای (\fBtrap\fR) برای گزارش مشکل ارسال \fBنمی‌کند\fR - بعداً بخش DisMan Event MIB را ببینید. .RE اگر این دستورالعمل مشخص نشود، آستانه پیش‌فرض 16 مگابایت خواهد بود. .SS پایش فایل لاگ (Log File Monitoring) این ویژگی مستلزم آن است که عامل به ترتیب با پشتیبانی از ماژول‌های \fIucd\-snmp/file\fR یا \fIucd\-snmp/logmatch\fR ساخته شده باشد (که هر دو به عنوان بخشی از پیکربندی پیش‌فرض ساخت گنجانده شده‌اند). .IP "file FILE [MAXSIZE]" اندازه فایل مشخص‌شده را (بر حسب کیلوبایت) پایش می‌کند. اگر MAXSIZE مشخص شود و اندازه فایل از این آستانه فراتر رود، نمونه \fCfileErrorFlag\fR متناظر برابر با 1 قرار می‌گیرد و پیام توصیفی مناسبی از طریق نمونه \fCfileErrorMsg\fR گزارش خواهد شد. .RS .IP "نکته:" این وضعیت به طور خودکار تله‌ای (\fBtrap\fR) برای گزارش مشکل ارسال \fBنمی‌کند\fR - بعداً بخش DisMan Event MIB را ببینید. .RE .IP نکته: حداکثر ۲۰ فایل را می‌توان پایش کرد. .IP نکته: اگر هیچ دستورالعمل \fIfile\fR تعریف نشده باشد، پیمایش \fCfileTable\fR با شکست مواجه خواهد شد (\fInoSuchObject\fR). .IP "logmatch NAME FILE CYCLETIME REGEX" فایل مشخص‌شده را برای موارد وقوع الگوی REGEX تعیین‌شده پایش می‌کند. موقعیت فایل به‌صورت داخلی ذخیره می‌شود تا کل فایل تنها در ابتدا خوانده شود؛ هر بررسی بعدی تنها خطوط جدیدی را که از زمان خواندن قبلی به فایل اضافه شده‌اند، می‌خواند. .RS .IP NAME نام نمونه logmatch (به صورت logMatchName در مسیر logMatch/logMatchTable/logMatchEntry/logMatchName در درخت MIB مربوط به ucd\-snmp نمایش داده خواهد شد) .IP FILE مسیر مطلق به فایل لاگ مورد نظر برای پایش. توجه داشته باشید که این مسیر می‌تواند حاوی دستورالعمل‌های تاریخ/زمان باشد (مانند دستور 'date' در UNIX). برای دستورالعمل‌های مختلف پذیرفته‌شده، صفحه راهنمای 'strftime' را ببینید. .IP CYCLETIME بازه زمانی برای هر بار خواندن فایل لاگ و به‌روزرسانی متغیرهای داخلی بر حسب ثانیه. نکته: یک عملیات SNMPGET* نیز باعث خواندن فوری فایل لاگ و به‌روزرسانی متغیرها خواهد شد. .IP REGEX عبارت باقاعده (regular expression) مورد استفاده. نکته: عبارت باقاعده را حتی اگر دارای فاصله باشد داخل گیومه قرار ندهید، زیرا گیومه‌ها نیز بخشی از الگوی مورد تطبیق خواهند شد! .RE .IP مثال: .RS .IP logmatch apache\-GETs /usr/local/apache/logs/access.log\-%Y\-%m\-%d 60 GET.*HTTP.* .IP این نمونه logmatch با نام 'apache\-GETs' نام‌گذاری شده، از 'GET.*HTTP.*' به عنوان عبارت باقاعده خود استفاده می‌کند و فایلی با این نام را پایش خواهد کرد (با فرض اینکه امروز ۶ می ۲۰۰۹ است): '/usr/local/apache/logs/access.log\-2009\-05\-06'؛ فردا به دنبال 'access.log\-2009\-05\-07' خواهد گشت. فایل لاگ هر ۶۰ ثانیه یک بار خوانده می‌شود. .RE .IP نکته: حداکثر ۲۵۰ دستورالعمل logmatch می‌توانند مشخص شوند. .IP نکته: اگر هیچ دستورالعمل \fIlogmatch\fR تعریف نشده باشد، پیمایش \fClogMatchTable\fR با شکست مواجه خواهد شد (\fInoSuchObject\fI). .SH "نظارت فعال (ACTIVE MONITORING)" رفتار معمول یک کارگزار SNMP، انتظار برای درخواست‌های ورودی SNMP و پاسخ به آن‌ها است \- اگر درخواستی دریافت نشود، کارگزار معمولاً هیچ عملی را آغاز نمی‌کند. این بخش دستورالعمل‌های گوناگونی را شرح می‌دهد که می‌توانند \fIsnmpd\fR را برای بر عهده گرفتن نقشی فعال‌تر پیکربندی کنند. .SS "مدیریت اعلان‌ها (Notification Handling)" .IP "trapcommunity STRING" رشته انجمن (community string) پیش‌فرضی را که باید هنگام ارسال trapها استفاده شود، مشخص می‌کند. توجه داشته باشید این دستورالعمل باید قبل از هر دستورالعمل مقصد trap مبتنی بر انجمنی که نیاز به استفاده از آن دارد، قرار گیرد. .IP "trapsink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]" .IP "trap2sink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]" .IP "informsink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]" به ترتیب آدرس دریافت‌کننده اعلانی را مشخص می‌کنند که باید اعلان‌های SNMPv1 TRAP، SNMPv2c TRAP2 یا SNMPv2 INFORM برای آن ارسال شود. برای اطلاعات بیشتر درباره قالب نشانی‌های شنود، بخش .B LISTENING ADDRESSES را در صفحه راهنمای .I snmpd(8) ببینید. اگر COMMUNITY مشخص نشده باشد، آخرین رشته \fItrapcommunity\fR استفاده خواهد شد. .IP اگر نشانی انتقال شامل پورت صریح نباشد، از PORT استفاده خواهد شد. در صورت عدم تعیین آن، پورت شناخته‌شده اعلان SNMP (شماره ۱۶۲) استفاده می‌شود. .RS .IP "نکته:" این سازوکار منسوخ شده است و پورت شنود باید به جای آن از طریق مشخصات انتقال HOST تعیین شود. .RE .IP پارامترهای اختیاری name و tag نام یا برچسبی را که برای ورودی‌های جدول SNMP-NOTIFICATION-MIB استفاده خواهد شد، مشخص می‌کنند. profile مشخص می‌کند کدام ورودی نمایه فیلتر اعلان برای فیلتر کردن اعلان‌های خروجی استفاده می‌شود. (ببینید: \fInotificationFilter\fR) .IP پارامتر اختیاری src نشانی مبدأیی را که هنگام ارسال بسته trap به این مقصد (sink) استفاده می‌شود، مشخص می‌کند. این پارامتر به صورت یک با استفاده از همان به عنوان HOST مقصد تعیین می‌شود. برای اطلاعات بیشتر در مورد قالب، بخش .B LISTENING ADDRESSES را در صفحه راهنمای .I snmpd(8) ببینید. .IP اگر چندین دستورالعمل sink تعیین شوند، نسخه‌های متعددی از هر اعلان (در قالب‌های مناسب) تولید خواهد شد. .RS .IP "نکته:" معمولاً تعریف دو (یا هر سه) دستورالعمل sink با یک مقصد یکسان کار درستی \fBنیست\fR. .RE .IP "trapsess [-profile p] [-name n] [-tag t] [-s src] [SNMPCMD_ARGS] HOST" سازوکار عمومی‌تری برای تعریف مقصدهای اعلان فراهم می‌کند. \fISNMPCMD_ARGS\fR باید گزینه‌های خط فرمانی باشند که برای دستور معادل \fIsnmptrap\fR (یا \fIsnmpinform\fR) جهت ارسال اعلان مورد نظر نیاز است. گزینه \fI\-Ci\fR می‌تواند (همراه با \fI\-v2c\fR یا \fI\-v3\fR) برای تولید یک اعلان INFORM به جای یک TRAP تأییدنشده استفاده شود. .IP پارامترهای اختیاری name و tag نام یا برچسبی را که برای ورودی‌های جدول SNMP-NOTIFICATION-MIB استفاده خواهد شد، مشخص می‌کنند. profile مشخص می‌کند کدام ورودی نمایه فیلتر اعلان برای فیلتر کردن اعلان‌های خروجی استفاده می‌شود. (ببینید: \fInotificationFilter\fR) .IP این دستورالعمل مناسب برای تعریف دریافت‌کننده‌های trap در SNMPv3 است. برای اطلاعات بیشتر درباره رفتار اعلان‌های SNMPv3 به نشانی زیر مراجعه کنید: http://www.net\-snmp.org/tutorial/tutorial\-5/commands/snmptrap\-v3.html .IP "notificationFilter NAME OID MASK TYPE" یک نمایه فیلتر اعلان SNMP-NOTIFICATION-MIB را مشخص می‌کند که می‌تواند برای فیلتر کردن trapها به کار رود. TYPE باید included یا excluded باشد. چند مثال: .RS .IP .nf notificationFilter all_ok .1.3 0x00 included notificationFilter no_coldstart .1.3 0x00 included notificationFilter no_coldstart .1.3.6.1.6.3.1.1.5.1 0x00 excluded trapsink -profile no_coldstart 192.168.1.3:3162 secret3 .fi .RE .IP "authtrapenable {1|2}" تعیین می‌کند که آیا trapهای شکست احراز هویت تولید شوند (\fIenabled(1)\fR) یا خیر (\fIdisabled(2)\fR \- حالت پیش‌فرض). به طور معمول شیء MIB متناظر (\fCsnmpEnableAuthenTraps.0\fR) به صورت خواندنی-نوشتنی است، اما مشخص کردن این دستورالعمل این شیء را فقط‌خواندنی می‌کند و تلاش برای تنظیم مقدار از طریق درخواست‌های SET به پاسخ خطای \fInotWritable\fR منجر خواهد شد. .RE .IP "v1trapaddress HOST" نشانی کارگزار را که در SNMPv1 TRAPها درج می‌شود، تعریف می‌کند. در صورت حذف این گزینه، یک نشانی IPv4 محلی دلخواه انتخاب می‌شود. این گزینه عمدتاً زمانی مفید است که کارگزار از دنیای بیرون تنها با یک نشانی خاص قابل مشاهده باشد (برای مثال به دلیل ترجمه نشانی شبکه یا فایروال). .SS "DisMan Event MIB" دستورالعمل‌های قبلی می‌توانند برای پیکربندی محل ارسال trapها استفاده شوند، اما به \fIزمان\fR ارسال چنین trapهایی (یا اینکه چه trapهایی باید تولید شوند) کاری ندارند. این حوزه مربوط به Event MIB است \- که توسط گروه کاری مدیریت توزیع‌شده (DisMan) در IETF توسعه یافته است. .PP این نیازمند ساخته شدن کارگزار با پشتیبانی از ماژول \fIdisman/event\fR است (که اکنون به عنوان بخشی از پیکربندی ساخت پیش‌فرض برای جدیدترین توزیع گنجانده شده است). .RS .IP "نکته:" رفتار جدیدترین پیاده‌سازی در برخی موارد جزئی با کد قبلی تفاوت دارد \- تفاوت چندان چشمگیری نیست، اما ممکن است اسکریپت‌های موجود به تنظیمات جزئی نیاز داشته باشند. .RE .IP "iquerySecName NAME" .IP "agentSecName NAME" نام کاربری پیش‌فرض SNMPv3 را برای استفاده در پرس‌وجوهای داخلی جهت بازیابی اطلاعات لازم (چه برای ارزیابی عبارت نظارت‌شده یا ساخت محموله اعلان) تعیین می‌کند. این پرس‌وجوهای داخلی همیشه از SNMPv3 استفاده می‌کنند، حتی اگر پرس‌وجوی معمول از کارگزار با استفاده از SNMPv1 یا SNMPv2c انجام شود. .IP توجه داشته باشید که این کاربر باید صراحتاً ایجاد شود (\fIcreateUser\fR) و حقوق دسترسی مناسب (مثلاً \fIrouser\fR) به آن داده شود. این دستورالعمل صرفاً به تعیین اینکه \fIکدام\fR کاربر باید استفاده شود مربوط است \- نه ایجاد و راه‌اندازی واقعی این کاربر. .\" .\" XXX - Should it create the user as well? .\" .\" .IP "iqueryVersion " .\" .IP "iquerySecLevel " .\" .IP "monitor [OPTIONS] NAME EXPRESSION" یک شیء MIB را برای نظارت تعریف می‌کند. اگر شرط EXPRESSION برقرار باشد (پایین را ببینید)، رویداد مربوطه برانگیخته خواهد شد و اعلانی ارسال می‌کند یا انتساب SET را اعمال می‌کند (یا هر دو). توجه داشته باشید رویداد فقط یک بار، هنگامی که عبارت برای بار نخست تطبیق می‌یابد، فعال می‌شود. این ورودی نظارتی دوباره فعال نخواهد شد مگر آنکه وضعیت نظارت‌شده ابتدا نادرست شده و سپس مجدداً تطبیق یابد. NAME یک نام مدیریتی برای این عبارت است و برای نمایه‌سازی \fCmteTriggerTable\fR (و جدول‌های مرتبط) به کار می‌رود. هر خط monitor باید یک NAME منحصر‌به‌فرد داشته باشد. خطوط monitor با نام تکراری نادیده گرفته شده و باعث می‌شوند snmpd پیام خطای نمایه تکراری را ثبت کند. همچنین توجه داشته باشید چنین ناظرانی از یک درخواست داخلی SNMPv3 برای بازیابی مقادیر تحت نظارت استفاده می‌کنند (حتی اگر پرس‌وجوهای معمول کارگزار عموماً از SNMPv1 یا SNMPv2c استفاده کنند). نشانه \fIiquerySecName\fP شرح داده شده در بالا را ببینید. .IP "\fIEXPRESSION\fR" سه نوع عبارت نظارتی توسط Event MIB پشتیبانی می‌شود \- آزمون‌های وجود، بولی و آستانه. .RS .IP "OID | ! OID | != OID" یک آزمون نظارتی \fIexistence(0)\fR را تعریف می‌کند. یک OID تنها، یک آزمون \fIpresent(0)\fR را مشخص می‌کند که با ایجاد (یک نمونه از) OID تحت نظارت فعال خواهد شد. عبارتی به شکل \fI! OID\fR یک آزمون \fIabsent(1)\fR را مشخص می‌کند که هنگام شناسایی OID تحت نظارت فعال می‌شود. عبارتی به شکل \fI!= OID\fR یک آزمون \fIchanged(2)\fR را مشخص می‌کند که با هر بار تغییر مقدار(های) تحت نظارت فعال می‌شود. توجه داشته باشید که \fBباید\fP قبل از نشانه OID فاصله وجود داشته باشد. .IP "OID OP VALUE" یک آزمون نظارتی \fIboolean(1)\fR را تعریف می‌کند. OP باید یکی از عملگرهای مقایسه‌ای تعریف‌شده (!=, ==, <, <=, >, >=) باشد و VALUE باید مقداری عدد صحیح برای مقایسه باشد. توجه داشته باشید که \fBباید\fP در دو طرف نشانه OP فاصله وجود داشته باشد. مقایسه‌ای مانند \fCOID !=0\fP به درستی مدیریت نخواهد شد. .IP "OID MIN MAX [DMIN DMAX]" یک آزمون نظارتی \fIthreshold(2)\fR را تعریف می‌کند. MIN و MAX مقادیری عدد صحیح هستند که آستانه‌های پایین و بالا را مشخص می‌کنند. اگر مقدار OID تحت نظارت به زیر آستانه پایین (MIN) افت کند یا از آستانه بالا (MAX) فراتر رود، ورودی ناظر رویداد مربوطه را برمی‌انگیزد. .IP توجه داشته باشید که رویداد آستانه افزایشی تنها زمانی مجدداً فعال می‌شود که مقدار تحت نظارت به زیر آستانه \fBپایین\fR (MIN) افت کند. به همین ترتیب، رویداد آستانه کاهشی توسط آستانه بالا (MAX) مجدداً آماده خواهد شد. .IP پارامترهای اختیاری DMIN و DMAX جفتی از آزمون‌های آستانه مشابه را پیکربندی می‌کنند، اما با تفاضل‌های دلتا بین مقادیر نمونه‌برداری پی‌درپی کار می‌کنند. .RE .IP "\fIOPTIONS\fR" گزینه‌های گوناگونی برای کنترل رفتار عبارت تحت نظارت وجود دارد، از جمله: .RS .IP "\-D" نشان می‌دهد که عبارت باید با استفاده از تفاضل‌های دلتا بین مقادیر نمونه‌برداری (به جای خود مقادیر) ارزیابی شود. .IP "\-d OID" .IP "\-di OID" یک نشانگر ناپیوستگی برای اعتبارسنجی تفاضل‌های دلتا تعیین می‌کند. نمونه شیء \fI\-di\fR دقیقاً همان‌طور که داده شده استفاده خواهد شد. به شیء \fI\-d\fR زیرشناسه‌های نمونه از شیء عبارت مربوطه (الگو/wildcarded) پیوست خواهد شد. اگر فلگ \fI\-I\fR مشخص شود، تفاوتی میان این دو گزینه وجود نخواهد داشت. .IP این گزینه همچنین به طور ضمنی شامل \fI\-D\fR نیز می‌شود. .IP "\-e EVENT" رویدادی را مشخص می‌کند که باید هنگام برانگیخته شدن این ورودی نظارتی فراخوانی شود. اگر این گزینه داده نشود، ورودی ناظر یکی از اعلان‌های استاندارد تعریف‌شده در DISMAN\-EVENT\-MIB را تولید خواهد کرد. .IP "\-I" نشان می‌دهد که عبارت نظارت‌شده باید بر روی OID مشخص‌شده به عنوان یک تک‌نمونه اعمال شود. به طور پیش‌فرض، با OID به عنوان یک شیء عام برخورد می‌شود و ناظر برای پوشش دادن همه نمونه‌های منطبق گسترش می‌یابد. .IP "\-i OID" .IP "\-o OID" varbindهای اضافی را برای افزوده شدن به محموله اعلان هنگام برانگیخته شدن این محرک نظارتی تعریف می‌کنند. برای یک عبارت عام، پسوند نمونه منطبق به هر یک از OIDهای تعیین‌شده با \fI\-o\fR افزوده می‌شود، در حالی که با OIDهای تعیین‌شده با \fI\-i\fR به عنوان نمونه‌های دقیق برخورد خواهد شد. اگر فلگ \fI\-I\fR مشخص شود، تفاوتی میان این دو گزینه وجود نخواهد داشت. .IP برای جزئیات ترتیب بار داده‌های (payload) اعلان، \fIstrictDisman\fR را ببینید. .IP "\-r FREQUENCY" عبارت داده‌شده را در هر FREQUENCY پایش می‌کند، که در آن FREQUENCY برحسب ثانیه است یا می‌تواند با یکی از پسوندهای s (برای ثانیه)، m (برای دقیقه)، h (برای ساعت)، d (برای روز)، یا w (برای هفته) مشخص شود. به‌طور پیش‌فرض، عبارت هر ۶۰۰ ثانیه (۱۰ دقیقه) ارزیابی خواهد شد. .IP "\-S" مشخص می‌کند که عبارت پایش هنگام شروع اولیه کارگزار \fIنباید\fR ارزیابی شود. نخستین ارزیابی پس از سپری شدن اولین بازه تکرار انجام خواهد شد. .IP "\-s" مشخص می‌کند که عبارت پایش \fIباید\fR هنگام شروع اولیه کارگزار ارزیابی شود. این رفتار پیش‌فرض است. .RS .IP "نکته:" اعلان‌های ایجادشده توسط این ارزیابی اولیه، \fIپیش از\fR ترپ \fCcoldStart\fR ارسال خواهند شد. .RE .IP "\-u SECNAME" یک نام امنیتی را برای استفاده جهت پویش میزبان محلی، به‌جای \fIiquerySecName\fR پیش‌فرض تعیین می‌کند. مجدداً، این کاربر باید به‌صورت صریح ایجاد شده و دسترسی‌های مناسب به او داده شود. .RE .IP "notificationEvent ENAME NOTIFICATION [\-m] [\-i OID | \-o OID ]*" یک رویداد اعلان با نام ENAME تعریف می‌کند. این مورد را می‌توان با مشخص کردن گزینه \fI\-e ENAME\fR از یک ورودی \fImonitor\fR داده‌شده فراخوانی کرد (بالا را ببینید). NOTIFICATION باید OID مربوط به تعریف NOTIFICATION\-TYPE برای اعلانی باشد که قرار است تولید شود. .IP اگر گزینه \fI\-m\fR داده شود، بار داده اعلان شامل varbindهای استانداردی خواهد بود که در بند OBJECTS از تعریف MIB اعلان مشخص شده‌اند. این گزینه باید \fBپس از\fR NOTIFICATION OID بیاید (و فایل MIB مربوطه باید در دسترس بوده و توسط کارگزار بارگذاری شده باشد). در غیر این صورت، این varbindها باید به‌طور صریح فهرست شوند (چه در اینجا و چه در دستورالعمل \fImonitor\fR متناظر). .IP گزینه‌های \fI\-i OID\fR و \fI\-o OID\fR مشخص‌کننده varbindهای اضافی هستند که باید پس از فهرست استاندارد، به بار داده اعلان افزوده شوند. اگر ورودی پایش که این رویداد را برانگیخته شامل یک عبارت عامه‌نویسه (wildcarded) باشد، پسوند نمونه تطبیق‌یافته به تمام OIDهای مشخص‌شده با \fI\-o\fR اضافه خواهد شد، در حالی که OIDهای مشخص‌شده با \fI\-i\fR به عنوان نمونه‌های دقیق در نظر گرفته می‌شوند. اگر فلگ \fI\-I\fR برای دستورالعمل \fImonitor\fR مشخص شده باشد، تفاوتی میان این دو گزینه وجود ندارد. .IP "setEvent ENAME [\-I] OID = VALUE " یک رویداد تنظیم (set event) به نام ENAME تعریف می‌کند که مقدار (صحیح) VALUE را به OID مشخص‌شده انتساب می‌دهد. این می‌تواند از یک ورودی \fImonitor\fR داده‌شده با مشخص کردن گزینه \fI\-e ENAME\fR فعال شود (بالا را ببینید). .IP اگر ورودی پایشی که این رویداد را برانگیخته شامل یک عبارت عامه‌نویسه باشد، پسوند نمونه منطبق‌شده معمولاً به OID اضافه می‌شود. اگر فلگ \fI\-I\fR در هر یک از دستورالعمل‌های \fImonitor\fR یا \fIsetEvent\fR مشخص شده باشد، OID تعیین‌شده به عنوان یک نمونه دقیق واحد در نظر گرفته خواهد شد. .IP "strictDisman yes" تعریف اعلان‌های SNMP بیان می‌کند که varbindهای تعریف‌شده در بند OBJECT باید در ابتدا (به ترتیب مشخص‌شده) قرار گیرند، و پس از آن هرگونه varbind «اضافی» که تولیدکننده اعلان مفید تشخیص می‌دهد بیاید. طبیعی‌ترین رویکرد این است که این varbindهای اجباری با ورودی \fInotificationEvent\fR مرتبط شده و هرگونه varbind مرتبط با ورودی پایش که اعلان را فعال کرده است به انتهای این فهرست افزوده شود. این رفتار پیش‌فرض پیاده‌سازی Event MIB در Net-SNMP است. .IP متأسفانه، مشخصات DisMan Event MIB در واقع بیان می‌کند که varbindهای مربوط به محرک باید در \fBابتدا\fR بیایند، و پس از آن موارد مربوط به رویداد قرار گیرند. این دستورالعمل می‌تواند برای بازگرداندن این رفتار دقیقاً صحیح (اما نامناسب) استفاده شود. .RS .IP "نکته:" ترتیب‌بندی سخت‌گیرانه DisMan ممکن است در صورت استفاده از فلگ \fInotificationEvent \-n\fR همراه با گزینه‌های varbind مربوط به \fImonitor \-o\fR (یا \fI\-i\fR) منجر به تولید فهرست‌های بار داده اعلان نامعتبر شود. .RE .IP اگر هیچ ورودی \fImonitor\fR بار داده varbindها را مشخص نکند، مقدار این دستورالعمل بی‌اثر خواهد بود. .IP "linkUpDownNotifications yes" جدول‌های Event MIB را برای پایش \fCifTable\fR جهت بررسی فعال یا غیرفعال شدن رابط‌های شبکه پیکربندی می‌کند و بر حسب مورد یک اعلان \fIlinkUp\fR یا \fIlinkDown\fR ایجاد می‌نماید. .IP این پیکربندی دقیقاً معادل با موارد زیر است: .RS .IP .nf notificationEvent linkUpTrap linkUp ifIndex ifAdminStatus ifOperStatus notificationEvent linkDownTrap linkDown ifIndex ifAdminStatus ifOperStatus monitor \-r 60 \-e linkUpTrap "Generate linkUp" ifOperStatus != 2 monitor \-r 60 \-e linkDownTrap "Generate linkDown" ifOperStatus == 2 .fi .RE .IP "defaultMonitors yes" جدول‌های Event MIB را برای پایش جدول‌های مختلف \fCUCD\-SNMP\-MIB\fR از نظر مشکلات (همان‌طور که توسط اشیاء ستونی \fCxxErrFlag\fR مربوطه مشخص می‌شود) پیکربندی می‌کند. .IP این پیکربندی دقیقاً معادل با موارد زیر است: .RS .IP .nf monitor \-o prNames \-o prErrMessage "process table" prErrorFlag != 0 monitor \-o memErrorName \-o memSwapErrorMsg "memory" memSwapError != 0 monitor \-o extNames \-o extOutput "extTable" extResult != 0 monitor \-o dskPath \-o dskErrorMsg "dskTable" dskErrorFlag != 0 monitor \-o laNames \-o laErrMessage "laTable" laErrorFlag != 0 monitor \-o fileName \-o fileErrorMsg "fileTable" fileErrorFlag != 0 .fi .RE .PP در هر دوی این موارد اخیر، snmpd.conf باید همچنین حاوی یک دستورالعمل \fIiquerySecName\fR، همراه با ورودی متناظر \fIcreateUser\fR و پیکربندی کنترل دسترسی مناسب باشد. .SS "DisMan Schedule MIB" گروه کاری DisMan همچنین سازوکاری را برای زمان‌بندی اقدامات خاص (یک انتساب SET مشخص‌شده) در زمان‌های تعیین‌شده ارائه کرده است. این امر نیازمند آن است که کارگزار با پشتیبانی از ماژول \fIdisman/schedule\fR ساخته شده باشد (که به عنوان بخشی از پیکربندی ساخت پیش‌فرض برای جدیدترین توزیع گنجانده شده است). .PP سه روش برای تعیین اقدام زمان‌بندی‌شده وجود دارد: .IP "repeat FREQUENCY OID = VALUE" یک انتساب SET از مقدار (صحیح) VALUE به نمونه MIB به نام OID را پیکربندی می‌کند تا هر FREQUENCY ثانیه اجرا شود، که در آن FREQUENCY برحسب ثانیه است یا می‌تواند با یکی از پسوندهای s (برای ثانیه)، m (برای دقیقه)، h (برای ساعت)، d (برای روز)، یا w (برای هفته) مشخص شود. .IP "cron MINUTE HOUR DAY MONTH WEEKDAY OID = VALUE" یک انتساب SET از مقدار (صحیح) VALUE به نمونه MIB به نام OID را پیکربندی می‌کند تا در زمان‌های مشخص‌شده توسط فیلدهای MINUTE تا WEEKDAY اجرا شود. این فیلدها از الگویی مشابه فیلدهای معادل در \fIcrontab(5)\fR پیروی می‌کنند. .RS .IP "نکته:" این فیلدها باید به صورت فهرستی (جداشده با کاما) از مقادیر عددی مشخص شوند. مقادیر نام‌گذاری‌شده برای فیلدهای MONTH و WEEKDAY پشتیبانی نمی‌شوند و بازه‌های مقادیر نیز معتبر نیستند. تطبیق عامه‌نویسه را می‌توان با '*' مشخص کرد. .RE .IP فیلد DAY همچنین می‌تواند مقادیر منفی بپذیرد تا روزهایی را نشان دهد که از انتهای ماه به عقب شمارش می‌شوند. .IP "at MINUTE HOUR DAY MONTH WEEKDAY OID = VALUE" یک انتساب SET یک‌باره را پیکربندی می‌کند تا در نخستین زمان منطبق مشخص‌شده توسط فیلدهای MINUTE تا WEEKDAY اجرا شود. تفسیر این فیلدها دقیقاً مانند دستورالعمل \fIcron\fR است. .SS "تحویل داده از طریق اعلان‌ها (Data Delivery via Notifications)" نکته: این قابلیت تنها زمانی در دسترس است که ماژول MIB به نام \fIdeliver/deliverByNotify\fR در کارگزار کامپایل شده باشد. .PP در برخی شرایط ممکن است تحویل داده‌های SNMP از طریق اعلان‌های SNMP (مانند TRAPها و INFORMها) نسبت به روش معمول که در آن مدیر درخواست‌ها را برای داده ارسال می‌کند (از طریق GETها و GETNEXTها)، مزیت داشته باشد. دلایل این کار بسیارند اما اغلب در موارد خاص و نادر مطرح می‌شوند. متداول‌ترین دلیل برای نیاز به چنین رفتاری، پایش دستگاه‌هایی است که پشت NAT یا فایروال‌هایی قرار دارند که مانع از ورود ترافیک SNMP می‌شوند. .PP باید توجه داشت که هرچند اکثر نرم‌افزارهای مدیریتی قادر به ثبت اعلان‌ها در لاگ هستند، اما تعداد بسیار کمی از آن‌ها (در صورت وجود) «پایگاه دانش» خود را بر اساس محتوای اعلان‌های SNMP به‌روزرسانی می‌کنند؛ به عنوان مثال، تاریخچه شمارنده ترافیک رابط را که برای رسم نمودارها استفاده می‌شود به‌روز نخواهند کرد. بیشتر بسته‌های مدیریت شبکه بزرگ‌تر پایگاه داده جداگانه‌ای برای ذخیره داده‌های دریافتی از طریق درخواست‌های SNMP (مانند GETها و GETNEXTها) در مقایسه با داده‌های دریافتی از اعلان‌ها دارند. پیش از آنکه فرض کنید این قابلیت نیازهای تحویل داده شما را برطرف می‌کند، تحقیق درباره توانمندی‌های نرم‌افزار ایستگاه مدیریتی الزامی است. .PP اعلان‌های تولیدشده از طریق این سازوکار به مجموعه استاندارد مقاصد اعلان پیکربندی‌شده ارسال خواهند شد. برای اطلاعات بیشتر بخش «Notification Handling» در این سند را ببینید. .IP "deliverByNotify [\-p] [\-m] [\-s MAXSIZE] FREQUENCY OID" این دستورالعمل به کارگزار SNMP اعلام می‌کند که \fIOID\fR را به‌طور خودکار پیمایش (self-walk) کرده، تمام داده‌ها را جمع‌آوری کند و هر \fIFREQUENCY\fR ثانیه به بیرون ارسال نماید؛ که در آن FREQUENCY برحسب ثانیه است یا می‌تواند با یکی از پسوندهای s (برای ثانیه)، m (برای دقیقه)، h (برای ساعت)، d (برای روز)، یا w (برای هفته) مشخص شود. به‌طور پیش‌فرض، مقادیر اسکالر در اعلان گنجانده می‌شوند که دوره ارسال اعلان (مگر اینکه گزینه \fI\-p\fR مشخص شده باشد) و شماره پیام یک اعلان خاص از کل تعداد پیام‌ها را تعیین می‌کنند (مگر اینکه \fI\-m\fR مشخص شده باشد). برای تقسیم اعلان‌ها به اندازه‌های بسته قابل مدیریت، از فلگ \fI\-s\fR استفاده کنید تا حداکثر تعداد بایت‌های تقریبی مجاز برای یک پیام اعلان را مشخص نمایید. اگر بیش از \fIMAXSIZE\fR بایت نیاز باشد، اعلان‌های متعددی برای تحویل داده ارسال خواهند شد. توجه داشته باشید که محاسبات برای تضمین رعایت حداکثر اندازه تقریبی هستند و بنابراین تضمین قطعی وجود ندارد که همیشه کمتر از آن اندازه باشند؛ پس اگر جلوگیری از تکه‌تکه شدن (fragmentation) حیاتی است، مقداری بافر حاشیه در نظر بگیرید. مقدار ۱\- نشان‌دهنده قرار دادن اجباری همه‌چیز در یک پیام واحد است، صرف‌نظر از اینکه چقدر بزرگ باشد. .IP نمونه کاربرد: موارد زیر محتویات ifTable را هر ساعت یک‌بار و محتویات گروه system را هر ۲ ساعت یک‌بار تحویل می‌دهند: .RS .nf deliverByNotify 3600 ifTable deliverByNotify 7200 system .fi .RE .IP "deliverByNotifyMaxPacketSize SIZEINBYTES" محدودیت پیش‌فرض اندازه اعلان را تنظیم می‌کند (فلگ \fI\-s\fR در بالا را ببینید). .IP "deliverByNotifyOid OID" .IP "deliverByNotifyFrequencyOid OID" .IP "deliverByNotifyMessageNumberOid OID" .IP "deliverByNotifyMaxMessageNumberOid OID" این گزینه‌ها OID داده‌ای را که اعلان تحت آن ارسال می‌شود، OID اسکالر، OID شماره پیام، و OID حداکثر شماره پیام را تنظیم می‌کنند. مقادیر پیش‌فرض این‌ها اشیائی در NET\-SNMP\-PERIODIC\-NOTIFY\-MIB هستند. .SH "گسترش قابلیت‌های کارگزار (EXTENDING AGENT FUNCTIONALITY)" یکی از نخستین ویژگی‌های شاخص مجموعه اصلی UCD، توانایی گسترش قابلیت‌های کارگزار بود \- نه تنها از طریق کامپایل مجدد با کدهای مربوط به ماژول‌های جدید MIB، بلکه با پیکربندی کارگزار در حال اجرا جهت گزارش اطلاعات اضافی. روش‌های متعددی برای پشتیبانی از این قابلیت وجود دارد، از جمله: .IP \(bu اجرای دستورهای خارجی (\fIexec\fR، \fIextend\fR، \fIpass\fR) .IP \(bu بارگذاری پویای کدهای جدید (embedded perl، \fIdlmod\fR) .IP \(bu ارتباط با سایر کارگزارها (\fIproxy\fR، SMUX، AgentX) .SS "دستورهای دلخواه گسترش (Arbitrary Extension Commands)" نخستین سازوکار گسترش، قابلیت اجرای دستورهای دلخواه یا اسکریپت‌های شل بود. این دستورها نیازی به آگاهی از عملیات SNMP یا تطابق با رفتار خاصی ندارند \- ساختارهای MIB طوری طراحی شده‌اند که با هر شکلی از خروجی دستور سازگار باشند. استفاده از این سازوکار نیازمند آن است که کارگزار با پشتیبانی از ماژول‌های \fIucd\-snmp/extensible\fR و/یا \fIagent/extend\fR (که هر دو در پیکربندی پیش‌فرض ساخت گنجانده شده‌اند) کامپایل شده باشد. .IP "exec [MIBOID] NAME PROG ARGS" .IP "sh [MIBOID] NAME PROG ARGS" برنامه تعیین‌شده در PROG را با آرگومان‌های ARGS فراخوانی می‌کند. به‌طور پیش‌فرض وضعیت خروج و نخستین خط خروجی دستور از طریق \fCextTable\fR گزارش شده و خروجی‌های اضافی نادیده گرفته می‌شوند. .RS .IP "نکته:" مدخل‌های این جدول به همان ترتیبی که از فایل پیکربندی خوانده می‌شوند نمایش می‌یابند. این بدان معناست که افزودن دستورالعمل‌های جدید \fIexec\fR (یا \fIsh\fR) و راه‌اندازی مجدد کارگزار، ممکن است بر نمایه‌سازی سایر مدخل‌ها اثر بگذارد. .RE .IP آرگومان PROG در دستورالعمل‌های \fIexec\fR باید مسیر کاملی به یک فایل اجرایی واقعی باشد، زیرا از طریق فراخوانی سیستمی exec() اجرا می‌شود. برای فراخوانی یک اسکریپت شل، در عوض از دستورالعمل \fIsh\fR استفاده کنید. .IP در صورت تعیین MIBOID، نتایج در این نقطه از درخت OID ریشه می‌گیرند و وضعیت خروج را به‌صورت MIBOID.100.0 و کل خروجی دستور را در یک شبه‌جدول مستقر در MIBNUM.101 \- با یک «ردیف» برای هر خط خروجی \- بازمی‌گردانند. .RS .IP "نکته:" ساختار این قالب «قابل جابه‌جایی» (relocatable) خروجی \fIexec\fR (یا \fIsh\fR) دقیقاً یک ساختار MIB معتبر تشکیل نمی‌دهد. این سازوکار در حال منسوخ شدن است \- لطفاً در عوض از دستورالعمل \fIextend\fR (توضیح داده شده در زیر) استفاده کنید. .RE .IP کارگزار وضعیت خروج یا خروجی برنامه اجرا شده را کش نمی‌کند. .\" .\" XXX - Is this still true ?? .\" .IP "execfix NAME PROG ARGS" دستوری را ثبت می‌کند که در صورت نیاز قابل فراخوانی است \- معمولاً برای پاسخ به خطاها یا رفع خطاهای مربوط به مدخل \fIexec\fR یا \fIsh\fR متناظر. هنگامی که نمونه \fIextErrFix\fR برای یک مدخل با NAME مشخص به مقدار عدد صحیح 1 تنظیم شود، این دستور فراخوانی خواهد شد. .RS .IP "نکته:" این دستورالعمل تنها در ترکیب با یک دستورالعمل \fIexec\fR یا \fIsh\fR متناظر قابل استفاده است که باید ابتدا تعریف شده باشد. تلاش برای تعریف یک دستورالعمل \fIexecfix\fR بدون مدخل متناظر با شکست مواجه خواهد شد. .RE .PP افزونه‌های \fIexec\fR و \fIsh\fR تنها از طریق فایل snmpd.conf قابل پیکربندی هستند. امکان تنظیم آن‌ها از طریق درخواست‌های SNMP SET وجود ندارد. .IP "extend [-cacheTime TIME] [-execType TYPE] [MIBOID] NAME PROG ARGS" مشابه دستورالعمل \fIexec\fR عمل می‌کند، اما با چندین بهبود. جدول‌های MIB (مانند \fInsExtendConfigTable\fR و غیره) با شناسه NAME نمایه‌سازی می‌شوند، بنابراین از ترتیبی که مدخل‌ها از فایل‌های پیکربندی خوانده می‌شوند تأثیر نمی‌پذیرند. \fIدو\fR جدول نتایج وجود دارد \- یکی (\fInsExtendOutput1Table\fR) شامل وضعیت خروج، خط نخست و خروجی کامل (به‌صورت یک رشته منفرد) برای هر مدخل \fIextend\fR، و دیگری (\fInsExtendOutput2Table\fR) شامل خروجی کامل به‌صورت مجموعه‌ای از خطوط مجزا. .IP در صورت تعیین \-cacheTime، آرگومان آن به‌عنوان زمان انقضای کش (برحسب ثانیه کامل) برای این مدخل \fIextend\fR استفاده می‌شود. این سازوکار روشی ماندگار برای تعیین زمان انقضای کش فراهم می‌سازد. .IP در صورت تعیین \-execType و داشتن مقدار \fIsh\fR، این مدخل \fIextend\fR در یک شل اجرا خواهد شد. در غیر این صورت به روش پیش‌فرض \fIexec\fR اجرا می‌شود. این سازوکار روشی ماندگار برای تعیین نوع اجرا فراهم می‌سازد. .IP در صورت تعیین MIBOID، جدول‌های پیکربندی و نتایج در این نقطه از درخت OID ریشه می‌گیرند، اما ساختار آن‌ها در سایر جهات دقیقاً یکسان است. این بدین معناست که چندین دستورالعمل مجزای \fIextend\fR می‌توانند بدون تداخل، ریشه MIBOID یکسانی را مشخص کنند. .IP وضعیت خروج و خروجی برای هر مدخل به‌طور مجزا کش می‌شود، و می‌توان آن را با استفاده از \fCnsCacheTable\fR پاک کرد (و رفتار کش‌گذاری را پیکربندی نمود). .IP "extendfix NAME PROG ARGS" دستوری را ثبت می‌کند که در صورت نیاز، با تنظیم نمونه مناسب \fInsExtendRunType\fR روی مقدار \fIrun-command(3)\fR فراخوانی می‌شود. بر خلاف دستور معادل \fIexecfix\fR، این دستورالعمل نیازی به جفت شدن با یک مدخل متناظر \fIextend\fR ندارد و می‌تواند به‌تنهایی استفاده شود. .PP هر دو دستورالعمل \fIextend\fR و \fIextendfix\fR را می‌توان به‌صورت پویا با استفاده از درخواست‌های SNMP SET در NET\-SNMP\-EXTEND\-MIB پیکربندی کرد. .SS "دستورهای گسترش ویژه MIB (MIB-Specific Extension Commands)" گروه نخست دستورالعمل‌های گسترش، دستورهای دلخواه را فراخوانی کرده و وابسته به انعطاف‌پذیری ساختار MIB (و برنامه‌های مدیریتی) برای پذیرش و تفسیر خروجی هستند. این روشی مناسب برای در دسترس قرار دادن سریع و ساده اطلاعات است، اما هنگام پیاده‌سازی اشیاء خاص MIB که در آن‌ها افزونه باید با ساختار MIB مطابقت داشته باشد (و نه برعکس)، کاربردی ندارد. سازوکارهای باقی‌مانده گسترش همگی به چنین موقعیت‌های ویژه MIB مربوط می‌شوند \- که با اسکریپت‌های «گذر مستقیم» (pass-through) آغاز می‌شوند. استفاده از این سازوکار نیازمند آن است که کارگزار با پشتیبانی از ماژول‌های \fIucd\-snmp/pass\fR و \fIucd\-snmp/pass_persist\fR (که هر دو در پیکربندی پیش‌فرض ساخت گنجانده شده‌اند) کامپایل شده باشد. .IP "pass [\-p priority] MIBOID PROG" کنترل زیردرخت ریشه‌گرفته از MIBOID را به دستور PROG مشخص‌شده واگذار می‌کند. درخواست‌های GET و GETNEXT برای شناسه‌های OID درون این درخت، این دستور را فراخوانی می‌کنند که به‌صورت زیر اجرا می‌شود: .RS .IP PROG \-g OID .IP PROG \-n OID .RE .IP به‌ترتیب، که در آن OID همان OID درخواست‌شده است. دستور PROG باید پاسخ varbind را به‌صورت سه خط مجزا در stdout چاپ کند \- خط اول باید OID مقدار بازگشتی باشد، خط دوم باید TYPE آن باشد (یکی از رشته‌های متنی .B integer, gauge, counter, timeticks, ipaddress, objectid, octet, یا .B string )، و خط سوم باید خود مقدار باشد. (نکته: مقادیر octet به‌صورت رشته‌های هگزادسیمال متنی ASCII و جداشده با فاصله ارسال می‌شوند، مانند "00 3f dd 00 c6 be"). .IP اگر دستور نتواند یک varbind مناسب بازگرداند \- برای نمونه OID مشخص‌شده با یک نمونه معتبر برای درخواست GET مطابقت نداشته باشد، یا نمونه بعدی برای GETNEXT وجود نداشته باشد \- باید بدون تولید هیچ خروجی خارج شود. این وضعیت منجر به خطای SNMP با عنوان \fInoSuchName\fR یا استثنای \fInoSuchInstance\fR خواهد شد. .RS .RS .IP "نکته:" نوع SMIv2 با عنوان \fBcounter64\fR و استثنای SNMPv2 با عنوان \fInoSuchObject\fR پشتیبانی نمی‌شوند. .RE .RE .IP یک درخواست SET منجر به فراخوانی دستور به‌صورت زیر خواهد شد: .RS .IP PROG \-s OID TYPE VALUE .RE .IP که در آن TYPE یکی از نشانه‌های فهرست‌شده در بالا است و نوع مقدار ارسال‌شده به‌عنوان پارامتر سوم را مشخص می‌کند. .\".RS .\".RS .\".IP "Note:" .\".B counter .\"(and .\".B counter64 .\") syntax objects are not valid for SETs .\".RE .\".RE .IP در صورت موفقیت‌آمیز بودن انتساب، دستور PROG باید بدون تولید هیچ خروجی خارج شود. خطاها باید با نوشتن یکی از رشته‌های .B not-writable, یا .B wrong-type در stdout مشخص شوند، و کارگزار پاسخ خطای مناسب را تولید خواهد کرد. .RS .RS .IP "نکته:" سایر خطاهای SNMPv2 پشتیبانی نمی‌شوند. .RE .RE .IP در هر دو حالت، دستور پس از پایان پردازش باید خارج شود. هر درخواست (و هر varbind درون یک درخواست منفرد) موجب فراخوانی مجزایی از دستور خواهد شد. .IP اولویت پیش‌فرض ثبت ۱۲۷ است. این مقدار را می‌توان با ارائه فلگ اختیاری \-p تغییر داد؛ ثبت‌های دارای اولویت پایین‌تر نسبت به مقادیر اولویت بالاتر در ارجحیت قرار می‌گیرند. .IP "pass_persist [\-p priority] MIBOID PROG" همچنین کنترل زیردرخت ریشه‌گرفته از MIBOID را به دستور PROG مشخص‌شده واگذار می‌کند. با این حال، این دستور پس از پاسخ‌گویی به درخواست اولیه همچنان در حال اجرا باقی می‌ماند، بنابراین درخواست‌های بعدی بدون سربار راه‌اندازی پردازش می‌شوند. .IP هنگام مقداردهی اولیه، رشته «PING\\n» در stdin به PROG ارسال می‌شود و این دستور باید با چاپ «PONG\\n» در stdout پاسخ دهد. .IP برای درخواست‌های GET و GETNEXT، دو خط در stdin به PROG ارسال می‌شود: دستور (\fIget\fR یا \fIgetnext\fR) و OID درخواست‌شده. این برنامه باید با چاپ سه خط در stdout پاسخ دهد \- OID برای varbind نتیجه، TYPE و خود VALUE \- دقیقاً مشابه دستورالعمل \fIpass\fR در بالا. اگر دستور نتواند یک varbind مناسب بازگرداند، باید «NONE\\n» را در stdout چاپ کند (اما به اجرا ادامه دهد). .IP برای درخواست‌های SET، سه خط در stdin به PROG ارسال می‌شود: دستور (\fIset\fR) و OID درخواست‌شده، به‌همراه نوع و مقدار (هر دو در یک خط). در صورت موفقیت‌آمیز بودن انتساب، دستور باید عبارت «DONE\\n» را در stdout چاپ کند. خطاها باید با نوشتن یکی از رشته‌های .B not\-writable, .B wrong\-type, .B wrong\-length, .B wrong\-value یا .B inconsistent\-value در stdout مشخص شوند، و کارگزار پاسخ خطای مناسب را ایجاد خواهد کرد. در هر دو حالت، دستور باید به اجرای خود ادامه دهد. .IP اولویت ثبت را می‌توان با استفاده از فلگ اختیاری \-p تغییر داد، دقیقاً مانند دستورالعمل \fIpass\fR. .PP افزونه‌های \fIpass\fR و \fIpass_persist\fR تنها از طریق فایل snmpd.conf قابل پیکربندی هستند. امکان تنظیم آن‌ها از طریق درخواست‌های SNMP SET وجود ندارد. .\" .\" XXX - caching ?? .\" .SS "پشتیبانی از Perl توکار" برنامه‌هایی که از سازوکارهای توسعه قبلی استفاده می‌کنند می‌توانند با هر زبان برنامه‌نویسی مناسبی نوشته شوند \- از جمله perl، که به ویژه برای توسعه‌های عبوری (pass-through) یک انتخاب رایج است. با این حال عامل Net-SNMP همچنین شامل پشتیبانی از فناوری perl توکار (مشابه \fImod_perl\fR برای وب‌سرور Apache) است. این قابلیت به عامل اجازه می‌دهد تا اسکریپت‌های perl را مستقیماً تفسیر کند، و در نتیجه از بار اضافی ایجاد فرآیندها و مقداردهی اولیه سیستم perl هنگام دریافت درخواست جلوگیری می‌نماید. .PP استفاده از این سازوکار مستلزم آن است که عامل با پشتیبانی از سازوکار perl توکار ساخته شده باشد، که بخشی از محیط ساخت پیش‌فرض نیست. این گزینه باید هنگام ساخت اولیه بسته، با مشخص کردن گزینه '\-\-enable\-embedded\-perl' برای اسکریپت configure صراحتاً گنجانده شود. .PP در صورت فعال بودن، دستورالعمل‌های زیر شناخته خواهند شد: .IP "disablePerl true" پشتیبانی از perl توکار را کاملاً غیرفعال می‌کند (مثلاً اگر در نصب perl مشکلاتی وجود داشته باشد). .IP "perlInitFile FILE" فایل مقداردهی اولیه مشخص‌شده را (در صورت وجود) بلافاصله پیش از تجزیه اولین دستورالعمل \fIperl\fR بارگذاری می‌کند. اگر صراحتاً مشخص نشود، عامل به دنبال فایل مقداردهی اولیه پیش‌فرض /usr/share/snmp/snmp_perl.pl خواهد گشت. .IP فایل مقداردهی اولیه پیش‌فرض یک نمونه از شیء \fCNetSNMP::agent\fR ایجاد می‌کند \- متغیر \fC$agent\fR که می‌تواند برای ثبت روتین‌های گرداننده MIB مبتنی بر perl استفاده شود. .IP "perl EXPRESSION" عبارت داده‌شده را ارزیابی می‌کند. این کار معمولاً یک روتین گرداننده (handler) را ثبت می‌کند تا هنگام درخواست بخشی از درخت OID فراخوانی شود: .RS .RS .nf \fCperl use Data::Dumper; perl sub myroutine { print "got called: ",Dumper(@_),"\\n"; } perl $agent\->register('mylink', '.1.3.6.1.8765', \\&myroutine);\fR .fi .RE .RE .IP این عبارت همچنین می‌تواند یک فایل خارجی را فراخوانی کند: .RS .RS \fCperl 'do /path/to/file.pl';\fR .RE .RE .IP یا هر پردازش مبتنی بر perl دیگری را که ممکن است لازم باشد انجام دهد. .\" .\" Link to more examples .\" .SS "ماژول‌های با قابلیت بارگذاری پویا" بیشتر MIBهای پشتیبانی‌شده توسط عامل Net-SNMP به عنوان ماژول‌های کد C پیاده‌سازی شده‌اند، که هنگام ساخت اولیه مجموعه کامپایل شده و با کتابخانه‌های عامل پیوند داده شده‌اند (link شده‌اند). چنین ماژول‌های پیاده‌سازی را می‌توان به طور مستقل نیز کامپایل کرد و پس از شروع به کار عامل، درون آن بارگذاری نمود. استفاده از این سازوکار مستلزم آن است که عامل با پشتیبانی از ماژول \fIucd\-snmp/dlmod\fR (که به عنوان بخشی از پیکربندی ساخت پیش‌فرض گنجانده شده است) ساخته شده باشد. .IP "dlmod NAME PATH" ماژول شیء اشتراکی (shared object) را از فایل PATH (یک نام فایل مطلق) بارگذاری می‌کند، و روتین مقداردهی اولیه \fIinit_NAME\fR را فراخوانی می‌نماید. .RS .IP "نکته:" اگر PATH مشخص‌شده یک نام فایل کامل و مطلق نباشد، نسبت به /usr/lib/snmp/dlmod تفسیر خواهد شد، و پسوند \fC.so\fR به نام فایل اضافه می‌شود. .RE .PP این قابلیت را می‌توان با استفاده از درخواست‌های SNMP SET به UCD\-DLMOD\-MIB نیز پیکربندی کرد. .SS "پشتیبانی از پروکسی" سازوکار دیگری برای گسترش قابلیت‌های عامل، انتقال درخواست‌های انتخاب‌شده (یا varbindهای انتخاب‌شده) به یک عامل SNMP دیگر است، که می‌تواند روی همان میزبان (احتمالاً در حال گوش دادن روی یک درگاه متفاوت) یا روی یک سیستم دوردست اجرا شود. این قابلیت را می‌توان هم به عنوان واگذاری درخواست‌ها از سوی عامل اصلی به عامل دوردست، و هم عمل کردن به عنوان یک پروکسی برای آن در نظر گرفت. استفاده از این سازوکار مستلزم آن است که عامل با پشتیبانی از ماژول \fIucd\-snmp/proxy\fR ساخته شده باشد (که به عنوان بخشی از پیکربندی ساخت پیش‌فرض گنجانده شده است). .IP "proxy [\-Cn CONTEXTNAME] [SNMPCMD_ARGS] HOST OID [REMOTEOID]" هرگونه درخواست ورودی ذیل OID را به عاملی که روی درگاه مشخص‌شده با آدرس انتقال HOST گوش می‌دهد، ارسال می‌کند. برای اطلاعات بیشتر درباره قالب آدرس‌های شنود، بخش .B آدرس‌های شنود (LISTENING ADDRESSES) را در صفحه راهنمای .I snmpd(8) ببینید. .RS .IP "نکته:" برای پروکسی کردن کل درخت MIB، از OID به صورت .1.3 استفاده کنید (\fBنه\fR سطح بالای .1). .RE .PP پارامتر \fISNMPCMD_ARGS\fR باید اطلاعات نسخه و مشخصات مدیریتی کافی را برای تولید یک درخواست معتبر SNMP فراهم کند (به \fIsnmpcmd(1)\fR مراجعه کنید). .IP "نکته:" درخواست پروکسی‌شده از تنظیمات مدیریتی درخواست اصلی استفاده \fIنخواهد کرد\fR. .RE .PP اگر یک CONTEXTNAME مشخص شده باشد، این کار واگذاری پروکسی را در بستر (context) نام‌گذاری‌شده در عامل محلی ثبت می‌کند. تعریف چندین دستورالعمل \fIproxy\fR برای یک OID یکسان اما contextهای متفاوت می‌تواند برای پرس‌وجو از چندین عامل دوردست از طریق یک پروکسی منفرد، با مشخص کردن context مناسب SNMPv3 در درخواست ورودی (یا با استفاده از رشته‌های انجمن پیکربندی‌شده مناسب \- دستورالعمل \fIcom2sec\fR را ببینید) استفاده شود. .PP مشخص کردن پارامتر REMOID، درخت MIB محلی ریشه‌دار در OID را به زیردرخت معادل ریشه‌دار در REMOID روی عامل دوردست نگاشت می‌کند. .SS "زیرعامل‌های SMUX" عامل Net-SNMP از پروتکل SMUX (RFC 1227) برای برقراری ارتباط با زیرعامل‌های مبتنی بر SMUX (مانند \fIgated\fR، \fIzebra\fR یا \fIquagga\fR) پشتیبانی می‌کند. استفاده از این سازوکار مستلزم آن است که عامل با پشتیبانی از ماژول \fIsmux\fR ساخته شده باشد، که بخشی از محیط ساخت پیش‌فرض نیست، و باید هنگام ساخت اولیه بسته، با تعیین گزینه '\-\-with\-mib\-modules=smux' در اسکریپت configure صراحتاً گنجانده شود. .RS .IP "نکته:" این پروتکل توسعه رسماً به نفع AgentX منسوخ شده است (زیر را ببینید). .RE .IP "smuxpeer OID PASS" یک زیردرخت را برای پردازش مبتنی بر SMUX ثبت می‌کند، تا با استفاده از گذرواژه PASS احراز هویت شود. اگر یک زیرعامل (یا «همتا») به عامل متصل شود و این زیردرخت را ثبت کند .\" .\" Or a subtree of this subtree ?? .\" آن‌گاه درخواست‌ها برای OIDهای درون آن جهت پردازش به آن زیرعامل SMUX ارسال خواهد شد. .IP یک ورودی مناسب برای دیمن مسیریابی OSPF (مانند \fIgated\fR، \fIzebra\fR یا \fIquagga\fR) می‌تواند چیزی شبیه به این باشد: .RS .RS .I smuxpeer .1.3.6.1.2.1.14 ospf_pass .RE .RE .IP "smuxsocket " آدرس IPv4 را برای ارتباط همتاهای SMUX با عامل Net-SNMP تعیین می‌کند. حالت پیش‌فرض شنود روی تمام رابط‌های IPv4‏ ("0.0.0.0") است، مگر اینکه بسته در زمان ساخت با "\-\-enable\-local\-smux" پیکربندی شده باشد، که باعث می‌شود به‌طور پیش‌فرض تنها روی 127.0.0.1 شنود کند. پروتکل SMUX از درگاه TCP شناخته‌شده ۱۹۹ استفاده می‌کند. .PP توجه داشته باشید که عامل Net-SNMP تنها به عنوان یک عامل \fIاصلی\fR (master) در SMUX عمل خواهد کرد. این عامل از ایفای نقش به عنوان زیرعامل SMUX پشتیبانی نمی‌کند. .SS "زیرعامل‌های AgentX" عامل Net-SNMP از پروتکل AgentX (RFC 2741) در هر دو نقش عامل اصلی و زیرعامل پشتیبانی می‌کند. استفاده از این سازوکار مستلزم آن است که عامل با پشتیبانی از ماژول \fIagentx\fR ساخته شده باشد (که به عنوان بخشی از پیکربندی ساخت پیش‌فرض گنجانده شده است)، و همچنین این پشتیبانی صراحتاً فعال شده باشد (مثلاً از طریق فایل \fIsnmpd.conf\fR). .PP دو دستورالعمل به‌طور خاص مربوط به اجرا به عنوان یک عامل اصلی AgentX هستند: .IP "master agentx" قابلیت AgentX را فعال می‌کند و باعث می‌شود که عامل شنود را برای ثبت‌نام‌های ورودی AgentX آغاز کند. این مورد همچنین می‌تواند با مشخص کردن گزینه خط فرمان '\-x' (برای تعیین یک سوکت شنود جایگزین) فعال شود. .IP "agentXPerms SOCKPERMS [DIRPERMS [USER|UID [GROUP|GID]]]" مجوزها و مالکیت سوکت یونیکس دامین AgentX و پوشه‌های والد این سوکت را تعیین می‌کند. SOCKPERMS و DIRPERMS باید ارقام هشت‌هشتی باشند (ببینید: .I chmod(1) ). به‌طور پیش‌فرض، این سوکت فقط برای زیرعامل‌هایی قابل دسترسی خواهد بود که دارای شناسه‌ی کاربری (userid) یکسانی با عامل هستند. .PP یک دستورالعمل به‌طور خاص مربوط به اجرا به عنوان یک زیرعامل AgentX است: .IP "agentXPingInterval NUM" باعث می‌شود که زیرعامل در صورت قطع ارتباط (یا شروع به کار در حالت قطع)، هر NUM ثانیه یک بار تلاش کند تا مجدداً به عامل اصلی متصل شود. .PP سایر دستورالعمل‌ها مربوط به هر دو نقش عامل اصلی و زیرعامل‌های AgentX هستند: .IP "agentXSocket [:][,...]" آدرسی را مشخص می‌کند که عامل اصلی روی آن شنود می‌کند یا زیرعامل باید به آن متصل شود. حالت پیش‌فرض، سوکت یونیکس دامین \fC"/var/agentx/master"\fR است. یک جایگزین رایج دیگر \fCtcp:localhost:705\fR است. برای اطلاعات بیشتر درباره قالب آدرس‌ها، بخش .B آدرس‌های شنود (LISTENING ADDRESSES) را در صفحه راهنمای .I snmpd(8) ببینید. .RS .IP "نکته:" مشخص کردن سوکت AgentX به‌طور خودکار قابلیت AgentX را فعال \fBنمی‌کند\fR (برخلاف گزینه خط فرمان '\-x'). .RE .IP "agentXTimeout NUM" مدت زمان مهلت زمانی (NUM ثانیه) را برای یک درخواست AgentX تعیین می‌کند. پیش‌فرض ۱ ثانیه است. NUM همچنین می‌تواند با پسوند یکی از حروف s (برای ثانیه)، m (برای دقیقه)، h (برای ساعت)، d (برای روز)، یا w (برای هفته) مشخص شود. .IP "agentXRetries NUM" تعداد تلاش‌های مجدد را برای یک درخواست AgentX تعیین می‌کند. پیش‌فرض ۵ بار تلاش مجدد است. .PP بسته net-snmp به همراه هر دو واسط برنامه‌نویسی C و Perl برای توسعه زیرعامل AgentX سفارشی شما ارائه می‌شود. .SH "سایر پیکربندی‌ها (OTHER CONFIGURATION)" .IP "override [\-rw] OID TYPE VALUE" این دایرکتیو به شما اجازه می‌دهد یک OID مشخص را با مقداری متفاوت (و احتمالاً با نوع داده‌ای متفاوت) بازنویسی (override) کنید. فلگ \-rw امکان تغییر مقدار آن را توسط دستورات SET در SNMP نیز فراهم می‌سازد. (توجه داشته باشید در صورتی که عملکرد اصلی را بازنویسی کنید، آن عملکرد کاملاً از دست خواهد رفت. بنابراین، درخواست‌های SET کاری فراتر از تغییر مقدار بازنویسی‌شدهٔ داخلی انجام نخواهند داد و هیچ‌یک از عملکردهای اصلی در نظر گرفته‌شده برای آن شیء MIB را اجرا نخواهند کرد؛ این قابلیت تنها یک شبیه‌سازی است.) یک مثال: .RS .IP \fCoverride sysDescr.0 octet_str "my own sysDescr"\fR .RE .IP خط بالا مقدار sysDescr.0 را برابر با "my own sysDescr" قرار داده و همچنین امکان تغییر آن با دستورات SET در SNMP را فراهم می‌سازد (که در واقع بر اساس مشخصات MIB غیرمجاز است). .IP توجه داشته باشید که هنگام استفاده از این قابلیت باید احتیاط کرد. برای نمونه، اگر تلاش کنید ویژگی سومین رابط (interface) در ifTable را با مقداری تازه بازنویسی کنید و بعداً شماره‌گذاری و ترتیب ایندکس‌ها در ifTable تغییر یابد، با مشکل روبه‌رو خواهید شد و مقدار تغییریافته شما در جای درست در جدول نشان داده نخواهد شد. .IP انواع مجاز TYPE عبارتند از: integer، uinteger، octet_str، object_id، counter، null (برای gaugeها از "uinteger" و برای bit stringها از "octet_str" استفاده کنید). دقت کنید که تنظیم یک شیء روی "null" عملاً قابلیت دسترسی به آن را حذف می‌کند. در صورتی که نوع شیء null باشد، نیازی به وارد کردن VALUE نیست. .IP انواع بیشتری در آینده در دسترس قرار خواهند گرفت. .PP اگر تلاش می‌کنید ابعاد گوناگون ماژول‌های مختلف mib را بررسی کنید (احتمالاً مواردی که خودتان اضافه کرده‌اید)، موارد زیر ممکن است در ارائه اطلاعات اشکال‌زدایی مفید به شما کمک کنند. ابتدا لطفاً صفحه راهنمای snmpd را درباره فلگ \-D مطالعه کنید. سپس نشانه پیکربندی snmpd.conf زیر در ترکیب با فلگ \-D می‌تواند خروجی مفیدی تولید کند: .IP "injectHandler HANDLER modulename [beforeThis]" این دستور هندلرهای تازه را به بخشی از درخت mib که توسط "modulename" ارجاع داده شده، تزریق می‌کند. اگر "beforeThis" تعیین شده باشد، ماژول پیش از ماژول نام‌برده تزریق خواهد شد. این قابلیت برای قرار دادن یک هندلر در موقعیت دقیق درون زنجیره بسیار کاربردی است. .IP انواع هندلرهای موجود برای تزریق عبارتند از: .RS .IP stash_cache اطلاعات دریافت‌شده از سطح پایین‌تر را کَش می‌کند. این ویژگی کارایی agent را به‌شدت بهبود می‌بخشد، اما به این هزینه که داده‌ها دیگر برای ۳۰ ثانیه «زنده» نیستند (در آینده این مقدار قابل پیکربندی خواهد بود). توجه داشته باشید این به این معنی است که snmpd در زمان کش شدن داده‌ها حافظه بیشتری مصرف خواهد کرد. در حال حاضر این قابلیت تنها برای هندلرهایی کار می‌کند که با پشتیبانی table_iterator ثبت شده‌اند، که تنها شامل تعداد کمی از جدول‌های mib است. برای به‌کارگیری آن، باید اطمینان حاصل کنید که پیش از نقطه table_iterator در زنجیره نصب شده است: \fCinjectHandler stash_cache NAME table_iterator\fR اگر جدولی برای آزمایش می‌خواهید، پیمایش (walk) جدول \fCnsModuleTable\fR را با و بدون این هندلر تزریق‌شده امتحان کنید. .IP debug هنگامی که فلگ \-Dhelper:debug به برنامه snmpd فرستاده شود، اطلاعات اشکال‌زدایی فراوانی را در خروجی چاپ می‌کند. .IP read_only غیرفعال کردن اجباری پشتیبانی از نوشتن را برای ماژول مربوطه اعمال می‌کند. .IP serialize اگر یک ماژول نتواند چندین درخواست هم‌زمان را به‌درستی مدیریت کند (با استفاده از API جدید ماژول در نسخه 5.0)، این هندلر ماژول را مجبور می‌سازد که در هر لحظه تنها یک درخواست را بپذیرد. .IP bulk_to_next اگر ماژولی برای پشتیبانی از getbulk ثبت شده باشد اما به دلایلی نتواند آن را به‌درستی پیاده‌سازی کند، این هندلر تمام درخواست‌های getbulk را پیش از دریافت توسط ماژول نهایی، به درخواست‌های getnext تبدیل می‌کند. .RE .IP "dontLogTCPWrappersConnects" اگر \fBsnmpd\fR همراه با پشتیبانی از TCP Wrapper کامپایل شده باشد، تمام اتصال‌های برقرارشده با عامل را لاگ می‌کند. این تنظیم پیام‌های لاگ مربوط به اتصال‌های پذیرفته‌شده را غیرفعال می‌سازد. اتصال‌های ردشده همچنان لاگ خواهند شد. .IP "تشخیص نام ماژول‌ها (Figuring out module names)" برای بررسی این موضوع که به کدام ماژول‌ها می‌توانید مواردی را تزریق کنید، دستور \fBsnmpwalk\fR را روی \fCnsModuleTable\fR اجرا کنید تا فهرستی از تمام ماژول‌های نام‌گذاری‌شده و ثبت‌شده در عامل را دریافت کنید. .SS "جدول‌های داده‌های داخلی (Internal Data tables)" .IP "table NAME" .\" XXX: To Document .IP "add_row NAME INDEX(ES) VALUE(S)" .\" XXX: To Document .SH "نکات (NOTES)" .IP o به عامل Net-SNMP می‌توان دستور داد تا فایل‌های پیکربندی گوناگون را دوباره بخواند؛ خواه با انتساب مقدار integer(1) به \fCUCD\-SNMP\-MIB::versionUpdateConfig.0\fR (.1.3.6.1.4.1.2021.100.11.0) از طریق دستور \fBsnmpset\fR، یا با فرستادن سیگنال \fBkill \-HUP\fR به پردازش عامل. .IP o تمامی دایرکتیوهایی که با مقدار "yes" فهرست شده‌اند، در عمل دامنه‌ای از مقادیر بولی (boolean) را می‌پذیرند. این دستورات مقادیر \fI1\fR، \fIyes\fR یا \fItrue\fR را برای فعال‌سازی رفتار مربوطه، و مقادیر \fI0\fR، \fIno\fR یا \fIfalse\fR را برای غیرفعال‌سازی آن می‌پذیرند. حالت پیش‌فرض در تمام موارد غیرفعال بودن ویژگی است، بنابراین این دایرکتیوها معمولاً تنها برای فعال کردن رفتار موردنظر استفاده می‌شوند. .SH "فایل نمونه پیکربندی (EXAMPLE CONFIGURATION FILE)" برای دیدن نمونه‌ای دقیق‌تر از نحوه به‌کارگیری اطلاعات بالا در سناریوهای واقعی، فایل EXAMPLE.CONF را در دایرکتوری ریشه سورس‌کد ببینید. .SH "فایل‌ها (FILES)" /etc/snmp/snmpd.conf .SH "همچنین ببینید (SEE ALSO)" snmpconf(1), snmpusm(1), snmp.conf(5), snmp_config(5), snmpd(8), EXAMPLE.conf, netsnmp_config_api(3). .\" Local Variables: .\" mode: nroff .\" End: