پیکربندی 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 است که هرگز استاندارد نشد.

امید است که در نهایت نرم‌افزارها و دستگاه‌های SNMP بیشتری از SNMP روی (D)TLS یا SSH پشتیبانی کنند، اما احتمالاً دستگاه‌هایی با پشتیبانی اولیه از SNMP فقط شامل پشتیبانی از کاربران USM خواهند بود. اگر مدیر شبکه شما از SNMP روی (D)TLS یا SNMP روی SSH پشتیبانی می‌کند، پیشنهاد می‌کنیم به جای استفاده از USM از یکی از این سازوکارها استفاده کنید، اما مثل همیشه با Net-SNMP گزینه‌هایی برای انتخاب در اختیار شما قرار می‌گیرد تا بتوانید انتخابی را که برای شما مناسب‌تر است انجام دهید.

پارامترهای عمومی SNMPv3 (SNMPv3 generic parameters)

این پارامترها برای تمام شکل‌های SNMPv3 عمومی هستند. پروتکل SNMPv3 شناسه «engineID» را تعریف می‌کند که یک کارگزار را به طور یکتا مشخص می‌سازد. این رشته باید در طول زمان پایدار باشد و نباید هرگز تغییر کند یا با engineID کارگزار دیگری تداخل داشته باشد. به صورت داخلی، Net-SNMP به طور پیش‌فرض یک engineID یکتا بر اساس زمان جاری سیستم و یک عدد تصادفی ایجاد می‌کند. این مقدار باید برای بیشتر کاربران کافی باشد، مگر اینکه کارگزار ما را در دستگاهی جاسازی کنید که در آن این اعداد هنگام راه‌اندازی اولیه بین دستگاه‌ها تغییر نکنند.

شناسه‌های engineID هم به عنوان یک «زمینه» (context) برای انتخاب اطلاعات از دستگاه استفاده می‌شوند و هم SNMPv3 با USM از آن برای ایجاد مدخل‌های یکتا برای کاربران در جدول کاربران خود استفاده می‌کند.

کارگزار Net-SNMP سازوکارهای زیر را برای تنظیم engineID ارائه می‌دهد، اما باز هم فقط در صورتی باید از آن‌ها استفاده کنید که بدانید چه کاری انجام می‌دهید:

engineID STRING

مشخص می‌کند که engineID باید از رشته متنی داده‌شده STRING ساخته شود.

engineIDType 1|2|3

مشخص می‌کند که engineID باید از نشانی IPv4 (1)، نشانی IPv6 (2) یا نشانی MAC (3) ساخته شود. توجه داشته باشید که تغییر نشانی IP (یا تعویض کارت شبکه) ممکن است مشکلاتی ایجاد کند.

engineIDNic INTERFACE

مشخص می‌کند هنگام تعیین نشانی MAC از کدام رابط استفاده شود. اگر engineIDType 3 مشخص نشده باشد، این دستورالعمل هیچ تأثیری ندارد.

پیش‌فرض استفاده از eth0 است.

SNMPv3 بر بستر TLS

پروتکل SNMPv3 می‌تواند بر بستر TLS و DTLS تونل شود. TLS بر روی TCP اجرا می‌شود و DTLS معادل UDP آن است. Wes Hardaker (بنیان‌گذار Net-SNMP) مطالعه‌ای انجام داد و آن را در یک نشست IETF ارائه کرد که نشان داد پروتکل‌های مبتنی بر TCP برای شبکه‌های پایدار کافی هستند، اما در شبکه‌های ناپایدار حتی با سطوح متوسطی از اتلاف بسته (حدود ۲۰-۳۰٪) به‌سرعت دچار مشکل می‌شوند. اگر قصد استفاده از TLS یا DTLS را دارید، باید موردی را که متناسب با محیط شبکه شماست به کار ببرید. ترجیحاً می‌توانید هر دو را فعال کنید تا سامانه مدیریتی شما بتواند در صورت نیاز به پورت UDP یا TCP دسترسی داشته باشد.

بسیاری از نشانه‌های پیکربندی شرح داده شده در زیر دارای پیشوند برچسب '[snmp]' هستند. اگر این نشانه‌ها را در فایل snmpd.conf خود قرار دهید، این برچسب الزامی است. برای آگاهی از مفهوم این تغییر زمینه، صفحه راهنمای snmp_config(5) را ببینید.

[snmp] localCert <specifier>

این نشانه کلید عمومی پیش‌فرض X.509 را برای استفاده به‌عنوان هویت سرور تعریف می‌کند. این مقدار باید اثرانگشت یا نام یک فایل باشد. برای ایجاد یک کلید عمومی جهت استفاده، لطفاً ابزار "net-snmp-cert" را اجرا کنید که در ایجاد گواهی لازم به شما کمک خواهد کرد.

مقدار پیش‌فرض برای این مورد، گواهی موجود در فایل گواهی با نام "snmpd" است.

[snmp] tlsAlgorithms <algorithms>

این رشته الگوریتم‌های مورد استفاده هنگام مذاکره امنیتی در زمان برقراری نشست (D)TLS را تعیین می‌کند. برای جزئیات مربوط به قالب، به صفحه راهنمای openssl برای ciphers(1) مراجعه کنید. نمونه رشته‌ها عبارتند از:

DEFAULT
ALL
HIGH
HIGH:!AES128-SHA

مقدار پیش‌فرض همان مقداری است که خود openssl با آن پیکربندی شده است.

[snmp] x509CRLFile

اگر از یک مرجع صدور گواهی (CA) استفاده می‌کنید که فهرست ابطال گواهی (CRL) را منتشر می‌کند، می‌توان از این نشانه برای مشخص کردن مکان نسخه‌ای از فایل CRL در فایل‌سیستم استفاده کرد. توجه داشته باشید که Net-SNMP فایل CRL را از طریق http دریافت نخواهد کرد و این مقدار حتماً باید یک فایل باشد، نه یک URL. علاوه بر این، OpenSSL هنگام تغییر فایل CRL آن را بازخوانی نمی‌کند، بنابراین اصلاحات یا به‌روزرسانی‌های فایل تنها پس از راه‌اندازی مجدد عامل snmpd اعمال خواهند شد.

certSecName PRIORITY FINGERPRINT OPTIONS

مقدار OPTIONS می‌تواند یکی از <--sn SECNAME | --rfc822 | --dns | --ip | --cn | --any> باشد.

نشانه 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 که در ادامه این صفحه راهنما بررسی می‌شوند، به آن مجوز دسترسی داده شود.

برای دستورالعمل‌های دقیق‌تر پیرامون برپایی (D)TLS، صفحه وب http://www.net-snmp.org/wiki/index.php/Using_DTLS را مشاهده کنید.

trustCert <specifier>

برای اینکه X509 بتواند گواهی را به‌درستی اعتبارسنجی کند، گواهی باید تا لنگر اعتماد (trust anchor) مربوط به آن قابل تأیید باشد. این لنگر اعتماد معمولاً گواهی CA است، اما می‌تواند یک گواهی خودامضا نیز باشد. نشانه "trustCert" باید برای بارگذاری لنگرهای اعتماد مشخص در موتور اعتبارسنجی استفاده شود.

اجرای SNMP بر بستر (D)TLS نیازمند استفاده از مدل امنیت انتقال (TSM) است، بنابراین بخش مربوط به استفاده از Transport Security Model را نیز مطالعه کنید. هنگام پیکربندی VACM برای پذیرش اتصالات از (D)TLS، اطمینان حاصل کنید که از مدل امنیتی "tsm" استفاده می‌کنید؛ به عنوان مثال:

rwuser -s tsm hardaker@net-snmp.org

پشتیبانی از SNMPv3 بر بستر SSH

برای استفاده از SSH، باید sshd را برای فراخوانی برنامه sshtosnmp پیکربندی کنید و همچنین تنظیمات کنترل دسترسی را پیکربندی نمایید تا امکان دسترسی از طریق مدل امنیتی tsm با استفاده از نام کاربری ارائه‌شده به snmpd توسط انتقال ssh فراهم شود.

SNMPv3 با مدل امنیت انتقال (TSM)

مدل امنیت انتقال [RFC5591] یک سامانه امنیتی SNMPv3 را برای استفاده با پروتکل‌های امنیتی «تونل‌شده» مانند TLS، DTLS و SSH تعریف می‌کند. این مدل، یک مدل امنیتی بسیار ساده است که صرفاً به بسته‌هایی که به‌درستی محافظت شده‌اند اجازه می‌دهد وارد برنامه snmp شوند. لایه انتقال موظف است یک securityName را برای استفاده به TSM تحویل دهد و TSM می‌تواند به‌صورت اختیاری یک رشته مربوط به لایه انتقال را به عنوان پیشوند به آن اضافه کند (به زیر مراجعه کنید).

tsmUseTransportPrefix (1|yes|true|0|no|false)

اگر روی true تنظیم شود، ماژول TSM هر securityName ارسالی از لایه‌های انتقال زیرین را دریافت کرده و رشته‌ای را که مشخصاً تعیین‌کننده لایه انتقال مبدأ است، پیشوند آن قرار می‌دهد. این ویژگی برای جلوگیری از تداخل securityNameها در لایه‌های انتقالی که نام‌های امنیتی یکسان تولید می‌کنند مفید است. به عنوان مثال، اگر انتقال امنیتی ssh نام امنیتی "hardaker" را برای یک اتصال SSH تحویل دهد و انتقال امنیتی TLS نیز نام امنیتی "hardaker" را برای یک اتصال TLS ارائه دهد، تفکیک این دو کاربر برای ارائه حقوق کنترل دسترسی مجزا غیرممکن خواهد بود. با این حال، با تنظیم tsmUseTransportPrefix روی true، نام‌های امنیتی به‌طور مناسب با یکی از پیشوندهای "tls:"، "dtls:" یا "ssh:" مشخص می‌شوند.

SNMPv3 با مدل امنیت مبتنی بر کاربر (USM)

پروتکل SNMPv3 در ابتدا با استفاده از مدل امنیت مبتنی بر کاربر (USM) تعریف شد که شامل فهرستی خصوصی از کاربران و کلیدهای مختص پروتکل SNMPv3 است. با این حال، جامعه عملیاتی مدیریت یک پایگاه داده دیگر را دشوار دانست و ترجیح داد از زیرساخت‌های موجود استفاده کند. بدین منظور، IETF کارگروه ISMS را برای مقابله با این مشکل تشکیل داد و کارگروه ISMS تصمیم گرفت SNMP را بر بستر SSH و DTLS تونل کند تا از زیرساخت‌های کاربری و احراز هویت موجود بهره ببرد.

کاربران USM در SNMPv3

برای استفاده از کاربران مبتنی بر USM مختص SNMPv3، لازم است آن‌ها را بسازید. توصیه می‌شود از دستور net-snmp-config استفاده کنید تا این کار انجام شود، اما می‌توانید خودتان نیز با مشخص کردن مستقیم دستورالعمل‌های createUser این کار را انجام دهید:

createUser [-e ENGINEID] username (MD5|SHA|SHA-512|SHA-384|SHA-256|SHA-224) authpassphrase [DES|AES] [privpassphrase]

موارد MD5|SHA|SHA-512|SHA-384|SHA-256|SHA-224 انواع احراز هویت مورد استفاده هستند. DES و AES پروتکل‌های حریم خصوصی مورد استفاده می‌باشند. اگر عبارت عبور حریم خصوصی مشخص نشود، همان عبارت عبور احراز هویت در نظر گرفته می‌شود. توجه داشته باشید کاربران ایجادشده بی‌استفاده خواهند بود مگر اینکه به جدول‌های کنترل دسترسی VACM که پیش‌تر شرح داده شد نیز افزوده شوند.

احراز هویت SHA|SHA-512|SHA-384|SHA-256|SHA-224 و حریم خصوصی DES/AES نیازمند نصب بودن OpenSSL و کامپایل عامل با پشتیبانی از OpenSSL هستند. احراز هویت MD5 می‌تواند بدون OpenSSL استفاده شود.

هشدار: حداقل طول عبارت عبور ۸ نویسه است.

کاربران SNMPv3 را می‌توان در زمان اجرا با استفاده از دستور snmpusm(1) ایجاد کرد.

به جای تلاش برای درک چگونگی استفاده از این دستورالعمل و محل قرار دادن آن (به زیر مراجعه کنید)، فقط کافی است "net-snmp-config --create-snmpv3-user" را اجرا کنید که یکی از این خطوط را در مکان مناسب اضافه خواهد کرد.

این دستورالعمل باید به جای سایر مکان‌های معمول، در فایل /var/net-snmp/snmpd.conf قرار گیرد. دلیل این است که اطلاعات از فایل خوانده شده و سپس این خط حذف می‌شود (تا از ذخیره‌سازی گذرواژه اصلی برای آن کاربر جلوگیری شود) و کلید مشتق‌شده از آن جایگزین می‌گردد. این کلید، یک کلید بومی‌سازی‌شده (localized) است؛ بنابراین در صورت به سرقت رفتن، نمی‌توان از آن برای دسترسی به سایر عامل‌ها استفاده کرد. با این حال، در صورت سرقت گذرواژه، چنین دسترسی‌ای ممکن خواهد بود.

اگر لازم است کاربر را برای یک EngineID خاص بومی‌سازی کنید (این امر بیشتر در فایل مشابه snmptrapd.conf کاربرد دارد)، می‌توانید از آرگومان -e برای تعیین یک EngineID به صورت مقدار هگزادسیمال (مانند "0x01020304") استفاده کنید.

اگر می‌خواهید کلیدهای اصلی یا بومی‌سازی‌شده خود را مستقیماً تولید کنید، گذرواژه داده‌شده را با یک رشته هگزادسیمال (با پیشوند "0x") جایگزین کرده و به ترتیب یک نشانه -m یا -l را قبل از رشته هگزادسیمال قرار دهید. به عنوان مثال:

[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

به دلیل نحوه انجام بومی‌سازی، انتظار می‌رود کلیدهای حریم خصوصی بومی‌سازی‌شده دارای طولی باشند که الگوریتم نیاز دارد (۱۲۸ بیت برای تمام الگوریتم‌های پشتیبانی‌شده). با این حال، کلیدهای رمزنگاری اصلی باید به اندازه طول مورد نیاز الگوریتم احراز هویت باشند، نه طول مورد نیاز الگوریتم رمزنگاری (در MD5 برابر ۱۶ بایت، در SHA برابر ۲۰ بایت).

کنترل دسترسی سنتی (Traditional Access Control)

بیشتر نیازمندی‌های سادهٔ کنترل دسترسی را می‌توان با استفاده از دستورالعمل‌های rouser/rwuser (برای SNMPv3) یا rocommunity/rwcommunity (برای SNMPv1 یا SNMPv2c) مشخص کرد.

rouser [-s SECMODEL] USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]

rwuser [-s SECMODEL] USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]

کاربری SNMPv3 را مشخص می‌کنند که به ترتیب دسترسی فقط‌خواندنی (GET و GETNEXT) یا خواندنی-نوشتنی (GET، GETNEXT و SET) خواهد داشت. به‌طور پیش‌فرض، این دستور امکان دسترسی به کل درخت OID را برای درخواست‌های احراز هویت‌شدهٔ SNMPv3 (شامل رمزگذاری‌شده)، با استفاده از زمینه پیش‌فرض فراهم می‌کند. سطح امنیتی حداقلِ جایگزین را می‌توان با استفاده از noauth (برای مجاز کردن درخواست‌های بدون احراز هویت) یا priv (برای اجبار به استفاده از رمزگذاری) مشخص کرد. فیلد OID دسترسی این کاربر را به زیردرخت ریشه‌دار در OID داده‌شده یا نمای نام‌گذاری‌شده محدود می‌کند. همچنین می‌توان یک زمینه اختیاری یا "context*" را برای نشان دادن پیشوند زمینه مشخص کرد. اگر هیچ فیلد زمینه‌ای مشخص نشده باشد (یا از نشانه "*" استفاده شود)، دستورالعمل با تمام زمینه‌های ممکن مطابقت خواهد داشت.

اگر SECMODEL مشخص شده باشد، مدل امنیتی مورد نیاز برای آن کاربر خواهد بود (توجه داشته باشید که نام‌های کاربری یکسان ممکن است از طریق مدل‌های امنیتی متفاوتی وارد شوند و از طریق تنظیمات کنترل دسترسی به‌طور مناسب تفکیک خواهند شد). مدل امنیتی پیش‌فرض "usm" است و سایر مدل‌های امنیتی متداول احتمالاً در صورت استفاده از پشتیبانی (D)TLS یا SSH برابر با "tsm"، و در صورت کامپایل شدن پشتیبانی Kerberos برابر با "ksm" هستند.

rocommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]

rwcommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]

یک کامیونیتی SNMPv1 یا SNMPv2c را مشخص می‌کنند که به ترتیب دسترسی فقط‌خواندنی (GET و GETNEXT) یا خواندنی-نوشتنی (GET، GETNEXT و SET) خواهد داشت. به‌طور پیش‌فرض، این گزینه دسترسی به کل درخت OID را برای چنین درخواست‌هایی، صرف‌نظر از این‌که از کجا ارسال شده‌اند، فراهم می‌کند. توکن SOURCE می‌تواند برای محدود کردن دسترسی به درخواست‌های سیستم(های) مشخص‌شده به کار رود - برای جزئیات کامل com2sec را ببینید. فیلد OID دسترسی آن کامیونیتی را به زیردرخت ریشه‌دار در OID داده‌شده یا نمای نام‌گذاری‌شده محدود می‌کند. زمینه‌ها معمولاً در نسخه‌های مبتنی بر کامیونیتی SNMP کاربرد کمتری دارند، اما همین رفتار در اینجا نیز اعمال می‌شود.

rocommunity6 COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]

rwcommunity6 COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]

دستورالعمل‌های مربوط به درخواست‌های دریافتی با استفاده از IPv6 هستند (اگر عامل از چنین دامنه‌های انتقالی پشتیبانی کند). تفسیر توکن‌های SOURCE، OID، VIEW و CONTEXT دقیقاً همانند نسخه‌های IPv4 است.

در هر مورد، تنها باید یک دستورالعمل برای کاربر مشخص SNMPv3 یا رشته کامیونیتی تعیین شود. مشخص کردن هم‌زمان هر دو دستورالعمل rouser و rwuser با اشاره به یک کاربر SNMPv3 یکسان (یا تنظیمات کامیونیتی معادل) مناسب نیست. دستورالعمل rwuser تمامی دسترسی‌های rouser را فراهم می‌کند (و علاوه بر آن پشتیبانی از SET را نیز مجاز می‌سازد). همین امر برای دستورالعمل‌های مبتنی بر کامیونیتی نیز صدق می‌کند.

نیازمندی‌های دسترسی پیچیده‌تر (مانند دسترسی به دو یا چند زیردرخت مجزای OID، یا نماهای متفاوت برای درخواست‌های GET و SET) باید از یکی از سازوکارهای دیگر کنترل دسترسی استفاده کنند. توجه داشته باشید که اگر چندین کامیونیتی یا کاربر SNMPv3 مجزا نیاز به سطح دسترسی یکسانی داشته باشند، استفاده از دستورالعمل‌های پیکربندی اصلی VACM کارآمدتر خواهد بود.

پیکربندی VACM (VACM Configuration)

انعطاف‌پذیری کامل VACM با استفاده از چهار دستورالعمل پیکربندی در دسترس است - com2sec، group، view و access. این دستورالعمل‌ها پیکربندی مستقیم جدول‌های زیرین VACM را امکان‌پذیر می‌سازند.

com2sec [-Cn CONTEXT] SECNAME SOURCE COMMUNITY

com2sec6 [-Cn CONTEXT] SECNAME SOURCE COMMUNITY

یک رشته کامیونیتی SNMPv1 یا SNMPv2c را به یک نام امنیتی نگاشت می‌کنند - خواه از محدودهٔ خاصی از آدرس‌های مبدأ، یا به‌طور سراسری ("default"). مبدأ محدودشده می‌تواند یک نام میزبان خاص (یا آدرس) یا یک زیرشبکه باشد - که به صورت 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 مجاز می‌کند:

دسترسی از خارج از 10.0.0.0/8 همچنان رد خواهد شد.

یک رشته کامیونیتی یکسان می‌تواند در چندین دستورالعمل جداگانه (احتمالاً با توکن‌های مبدأ متفاوت) مشخص شود و اولین ترکیب مبدأ/کامیونیتی که با درخواست ورودی مطابقت داشته باشد، انتخاب خواهد شد. ترکیب‌های گوناگون مبدأ/کامیونیتی همچنین می‌توانند به یک نام امنیتی یکسان نگاشت شوند.

اگر CONTEXT (با استفاده از -Cn) مشخص شود، رشته کامیونیتی به یک نام امنیتی در زمینه مشخص‌شدهٔ SNMPv3 نگاشت می‌شود. در غیر این صورت، از زمینه پیش‌فرض ("") استفاده خواهد شد.

com2secunix [-Cn CONTEXT] SECNAME SOCKPATH COMMUNITY

نسخهٔ سوکت‌های دامنه یونیکس از دستور com2sec است.

group GROUP {v1|v2c|usm|tsm|ksm} SECNAME

یک نام امنیتی (در مدل امنیتی مشخص‌شده) را به یک گروه نام‌گذاری‌شده نگاشت می‌کند. چندین دستورالعمل group می‌توانند نام گروه یکسانی را مشخص کنند و به یک تنظیم دسترسی منفرد اجازه می‌دهند بر روی چندین کاربر و/یا رشته کامیونیتی اعمال شود.

توجه داشته باشید که گروه‌ها باید برای دو مدل مبتنی بر کامیونیتی به‌طور جداگانه تنظیم شوند - معمولاً یک دستورالعمل منفرد com2sec (یا معادل آن) با دو دستورالعمل group همراه خواهد بود.

view VNAME TYPE OID [MASK]

یک «نما» نام‌گذاری‌شده را تعریف می‌کند - زیرمجموعه‌ای از کل درخت OID. این معمولاً یک زیردرخت تکی است، اما چندین دستورالعمل view را می‌توان با یک نام نمای یکسان (VNAME) ارائه کرد تا مجموعهٔ پیچیده‌تری از OIDها ساخته شود. شناسه TYPE می‌تواند included یا excluded باشد که باز هم می‌تواند نمای پیچیده‌تری را تعریف کند (برای مثال با مستثنا کردن اشیاء حساس خاص از زیردرختی که در غیر این صورت قابل دسترسی است).

شناسه MASK فهرستی از بایت‌های هگزادسیمال (اختیاری با تفکیک '.' یا ':') است که بیت‌های فعال نشان می‌دهند کدام شناسه‌های فرعی در OID نما برای تطبیق مقایسه شوند. در صورت عدم تعیین، مقدار پیش‌فرض تطبیق دقیق OID (تمام بیت‌ها فعال) است و بدین ترتیب یک زیردرخت OID ساده را تعریف می‌کند. بنابراین:

همگی یک نمای یکسان را تعریف می‌کنند که کل زیردرخت 'iso(1)' را پوشش می‌دهد (با این تفاوت که مثال سوم شناسه‌های فرعی را که توسط ماسک پوشش داده نشده‌اند نادیده می‌گیرد).

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

توجه داشته باشید که ماسک طولانی‌تر از ۸ بیت باید از ':' برای تفکیک بایت‌ها استفاده کند.

access GROUP CONTEXT {any|v1|v2c|usm|tsm|ksm} LEVEL PREFX READ WRITE NOTIFY

نگاشتی از یک گروهِ کاربران/کامیونیتی‌ها (با مدل امنیتی خاص و حداقل سطح امنیتی، و در یک زمینه مشخص) به یکی از سه نما، بسته به درخواستی که پردازش می‌شود، انجام می‌دهد.

شناسه LEVEL یکی از مقادیر noauth، auth، یا priv است. شناسه PREFX مشخص می‌کند که CONTEXT چگونه با زمینه درخواست ورودی مطابقت داده شود؛ یا exact یا prefix. شناسه‌های READ، WRITE و NOTIFY نمایی را مشخص می‌کنند که باید برای درخواست‌های *GET، SET و TRAP/INFORM استفاده شود (اگرچه نمای NOTIFY در حال حاضر استفاده نمی‌شود). برای دسترسی v1 یا v2c، مقدار LEVEL باید noauth باشد.

پیکربندی نمای نوع‌دار (Typed-View Configuration)

گروه پایانی دستورالعمل‌ها، رویکرد VACM را به سازوکاری انعطاف‌پذیرتر گسترش می‌دهند که می‌تواند برای سایر نیازمندی‌های کنترل دسترسی به کار رود. به جای سه نمای ثابت در سازوکار استاندارد VACM، این روش می‌تواند برای پیکربندی انواع مختلف نماها استفاده شود. تا جایی که به عامل اصلی SNMP مربوط است، دو نوع نمای اصلی read و write هستند که با نماهای READ و WRITE در دستورالعمل اصلی access مطابقت دارند. برای بررسی سایر انواع نما، صفحه راهنمای

authcommunity TYPES COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]

جایگزینی برای دستورالعمل‌های rocommunity/rwcommunity است. شناسه TYPES معمولاً به ترتیب read یا read,write خواهد بود. مشخصات نما برای انعطاف‌پذیری بیشتر می‌تواند یک زیردرخت OID (مانند قبل) یا یک نمای نام‌گذاری‌شده (تعریف‌شده با دستورالعمل view) باشد. اگر این مقدار حذف شود، دسترسی به کل درخت OID مجاز خواهد بود. اگر CONTEXT مشخص شود، دسترسی در این زمینه SNMPv3 پیکربندی می‌شود. در غیر این صورت از زمینه پیش‌فرض ("") استفاده می‌شود.

authuser TYPES [-s MODEL] USER [LEVEL [OID | -V VIEW [CONTEXT]]]

جایگزینی برای دستورالعمل‌های rouser/rwuser است. فیلدهای TYPES، OID، VIEW و CONTEXT همان معنای موجود در authcommunity را دارند.

authgroup TYPES [-s MODEL] GROUP [LEVEL [OID | -V VIEW [CONTEXT]]]

مکملی برای دستورالعمل authuser است که دسترسی را برای یک گروه خاص (تعریف‌شده با استفاده از دستورالعمل معمول group) مشخص می‌کند. هر دو دستور authuser و authgroup به‌طور پیش‌فرض برای درخواست‌های احراز هویت‌شده هستند - شناسه LEVEL همچنین می‌تواند به صورت noauth یا priv مشخص شود تا به ترتیب درخواست‌های بدون احراز هویت را مجاز کند یا به رمزگذاری نیاز داشته باشد. هر دو دستورالعمل authuser و authgroup همچنین به‌طور پیش‌فرض دسترسی را برای درخواست‌های SNMPv3/USM پیکربندی می‌کنند - از فلگ '-s' برای تعیین مدل امنیتی جایگزین (با استفاده از مقادیر مشابه access در بالا) استفاده کنید.

authaccess TYPES [-s MODEL] GROUP VIEW [LEVEL [CONTEXT]]

همچنین دسترسی را برای یک گروه خاص، با مشخص کردن نام و نوع نمای اعمالی، پیکربندی می‌کند. فیلدهای MODEL و LEVEL به همان شیوهٔ authgroup تفسیر می‌شوند. اگر CONTEXT مشخص شده باشد، دسترسی درون این زمینه SNMPv3 (یا زمینه‌های دارای این پیشوند اگر فیلد CONTEXT با '*' خاتمه یابد) پیکربندی می‌شود. در غیر این صورت، از زمینه پیش‌فرض ("") استفاده خواهد شد.

setaccess GROUP CONTEXT MODEL LEVEL PREFIX VIEW TYPES

معادل مستقیم دستورالعمل اصلی access است که معمولاً انواع نما را بر حسب مورد به صورت read یا read,write فهرست می‌کند (یا برای سایر حالت‌ها 'snmptrapd.conf(5)' را ببینید). تمام فیلدهای دیگر تفسیر یکسانی با access دارند.

گروه سیستم (System Group)

بیشتر اشیاء اسکالر در گروه 'system' را می‌توان به این روش پیکربندی کرد:

sysLocation STRING

sysContact STRING

sysName STRING

به ترتیب مکان سیستم، رابط تماس سیستم یا نام سیستم (sysLocation.0، sysContact.0 و sysName.0) را برای عامل تنظیم می‌کنند. به‌طور معمول این اشیاء از طریق درخواست‌های مجاز SNMP SET قابل نوشتن هستند. با این وجود، مشخص کردن یکی از این دستورالعمل‌ها شیء مربوطه را فقط‌خواندنی می‌کند و تلاش برای اجرای SET روی آن به خطای notWritable منجر خواهد شد.

sysServices NUMBER

مقدار شیء sysServices.0 را تنظیم می‌کند. برای یک سیستم میزبان، مقدار مناسب 72 (لایه‌های کاربرد + سرتاسر / application + end-to-end) است. اگر این دستورالعمل مشخص نشود، هیچ مقداری برای شیء sysServices.0 گزارش نخواهد شد.

sysDescr STRING

sysObjectID OID

توضیحات سیستم یا شناسه شیء (OID) را برای عامل تنظیم می‌کنند. اگرچه این اشیاء MIB از طریق SNMP قابل نوشتن نیستند، مدیر شبکه می‌تواند از این دستورالعمل‌ها برای پیکربندی مقادیر مناسب برای آن‌ها استفاده کند.

گروه رابط‌ها (Interfaces Group)

interface NAME TYPE SPEED

می‌تواند برای ارائه تنظیمات نوع و سرعت مناسب برای رابط‌هایی که عامل در تشخیص صحیح اطلاعات آن‌ها ناموفق است، استفاده شود. TYPE مقداری از نوع ارائه‌شده در IANAifType-MIB است و می‌توان آن را به‌صورت عددی یا با نام مشخص کرد (به شرطی که این MIB بارگذاری شده باشد).

interface_fadeout TIMEOUT

مشخص می‌کند عامل تا چه مدت پس از حذف رابط‌های مربوطه از سیستم (معمولاً رابط‌های گوناگون ppp، tap یا tun)، ورودی‌های آن‌ها را در ifTable نگه می‌دارد. مقدار وقفه زمانی به ثانیه است. مقدار پیش‌فرض 300 (=5 دقیقه) است.

interface_replace_old yes

می‌تواند برای حذف ورودی‌های موجود در ifTable هنگام ظاهر شدن رابطی با همان نام در سیستم استفاده شود. به عنوان مثال، هنگامی که رابط ppp0 حذف می‌شود، همچنان به مدت interface_fadeout ثانیه در جدول فهرست می‌شود. این گزینه تضمین می‌کند که با ظاهر شدن ppp0 جدید (با ifIndex متفاوت)، رابط قبلی ppp0 حتی پیش از پایان مهلت زمانی interface_fadeout حذف گردد.

گروه منابع میزبان (Host Resources Group)

این نیازمند آن است که عامل با پشتیبانی از ماژول host ساخته شده باشد (که اکنون بخشی از پیکربندی ساخت پیش‌فرض در پلتفرم‌های اصلی پشتیبانی‌شده است).

ignoreDisk STRING

کنترل می‌کند کدام دستگاه‌های دیسک به عنوان بخشی از پر کردن hrDiskStorageTable (و hrDeviceTable) پویش شوند. کد پیاده‌سازی HostRes شامل فهرستی از الگوهای دستگاه‌های دیسک مناسب برای سیستم‌عامل فعلی است، که برخی از آن‌ها ممکن است هنگام تلاش عامل برای باز کردن دستگاه‌های دیسک مربوطه باعث مسدود شدن آن شوند. این امر ممکن است منجر به اتمام مهلت زمانی (timeout) هنگام پیمایش این جدول‌ها شده و احتمالاً رفتاری متناقض به همراه داشته باشد. از این دستورالعمل می‌توان برای مشخص کردن دستگاه‌های خاص (به صورت تکی یا با الگوهای wildcard) که نباید بررسی شوند، استفاده کرد.

الگو می‌تواند شامل یک یا چند عبارت عمومی (wildcard) باشد. برای مشاهده ساختار عبارات عمومی به snmpd.examples(5) مراجعه کنید.

ignoremount [-r] STRING

کنترل می‌کند کدام اتصالات (mounts) باید از hrStorageTable حذف شوند. اگر عامل Net-SNMP هنگام دسترسی به یک سیستم فایل متوقف (hang) شود، یا سیستم فایل همیشه تقریباً پر باشد (و بنابراین به هشدارهای کاذب منجر گردد)، می‌توانید با ذکر مسیر کامل در این دستورالعمل، آن را حذف کنید.

اگر گزینه "-r" ارائه شود، الگو می‌تواند شامل یک یا چند عبارت باقاعده (regular expression) باشد.

skipNFSInHostResources true

کنترل می‌کند که آیا سیستم‌های فایل NFS و مشابه NFS باید از hrStorageTable حذف شوند (true یا 1) یا خیر (false یا 0، که پیش‌فرض است). اگر عامل Net-SNMP روی سیستم‌های فایل متصل‌شده از طریق NFS متوقف شود، می‌توانید تنظیم آن روی '1' را امتحان کنید.

به عنوان روشی جایگزین، کنترل دقیق‌تر بر اینکه کدام اتصالات باید از hrStorageTable حذف شوند از طریق دستورالعمل ignoremount قابل دستیابی است.

storageUseNFS [1|2]

نحوه گزارش سیستم‌های فایل NFS و مشابه NFS در hrStorageTable را کنترل می‌کند: به عنوان 'Network Disks' (1) یا 'Fixed Disks' (2). از نظر تاریخی، عامل Net-SNMP چنین سیستم‌های فایلی را به عنوان 'Fixed Disks' گزارش می‌کرد و این همچنان رفتار پیش‌فرض است. تنظیم این دستورالعمل روی '1' این سیستم‌های فایل را طبق نیازمندی‌های Host Resources MIB به عنوان 'Network Disks' گزارش می‌کند.

realStorageUnits

نحوه گزارش hrStorageAllocationUnits ،hrStorageSize و hrStorageUsed در hrStorageTable توسط عامل را کنترل می‌کند. برای فضاهای ذخیره‌سازی بزرگ با واحدهای تخصیص کوچک، عامل این مقادیر را مجدداً محاسبه می‌کند تا همگی در Integer32 بگنجند و hrStorageAllocationUnits x hrStorageSize اندازه واقعی فضای ذخیره‌سازی را ارائه دهد.

تنظیم این دستورالعمل روی '1' این محاسبه را غیرفعال می‌کند و عامل مقدار واقعی hrStorageAllocationUnits را گزارش می‌دهد، اما ممکن است برای درایوهای بزرگ مقدار hrStorageSize نادرستی گزارش دهد زیرا این مقدار در Integer32 نمی‌گنجد. در این حالت، hrStorageAllocationUnits x hrStorageSize اندازه واقعی فضای ذخیره‌سازی را ارائه نخواهد داد.

نظارت بر فرآیندها (Process Monitoring)

گروه hrSWRun از Host Resources MIB اطلاعاتی درباره تک‌تک فرآیندهای در حال اجرا روی سیستم محلی ارائه می‌دهد. جدول prTable از UCD-SNMP-MIB با گزارش درباره سرویس‌های انتخاب‌شده (که ممکن است شامل چندین فرآیند باشند) این را تکمیل می‌کند. این نیازمند آن است که عامل با پشتیبانی از ماژول ucd-snmp/proc ساخته شده باشد (که به عنوان بخشی از پیکربندی ساخت پیش‌فرض گنجانده شده است).

proc NAME [MAX [MIN]]

تعداد فرآیندهایی به نام NAME (طبق گزارش " -acx") را که روی سیستم محلی در حال اجرا هستند، پایش می‌کند.

اگر تعداد فرآیندهای NAME کمتر از MIN یا بیشتر از MAX باشد، نمونه prErrorFlag مربوطه روی 1 تنظیم شده و پیام توصیفی مناسبی از طریق نمونه prErrMessage گزارش می‌شود.

اگر نه MAX و نه MIN مشخص نشده باشند، به ترتیب به infinity و 1 پیش‌فرض می‌شوند ("حداقل یکی"). اگر فقط MAX مشخص شده باشد، MIN به 0 پیش‌فرض می‌شود ("نه بیشتر از MAX"). اگر MAX برابر با 0 باشد (و MIN نباشد)، این نشان‌دهنده بی‌نهایت است ("حداقل MIN"). اگر هر دو مقدار MAX و MIN برابر با 0 باشند، این نشان‌دهنده فرآیندی است که نباید در حال اجرا باشد.

procfix NAME PROG ARGS

دستوری را ثبت می‌کند که می‌تواند برای رفع خطاهای فرآیند با NAME داده‌شده اجرا شود. این دستور زمانی فراخوانی می‌شود که نمونه prErrFix مربوطه روی 1 تنظیم شود.

دستورالعمل procfix باید بعد از دستورالعمل proc متناظر مشخص شود، و نمی‌توان آن را به تنهایی استفاده کرد.

اگر هیچ دستورالعمل proc تعریف نشده باشد، پیمایش prTable با شکست مواجه خواهد شد (noSuchObject).

پایش مصرف دیسک (Disk Usage Monitoring)

این ویژگی مستلزم آن است که عامل با پشتیبانی از ماژول ucd-snmp/disk ساخته شده باشد (که به عنوان بخشی از پیکربندی پیش‌فرض ساخت گنجانده شده است).

disk PATH [ MINSPACE | MINPERCENT% ]

دیسک سوارشده در PATH را برای فضای دیسک موجود پایش می‌کند. دیسک‌هایی که پس از شروع به کار عامل سوار شده‌اند پایش نخواهند شد، مگر اینکه گزینه includeAllDisks مشخص شده باشد.

حداقل آستانه را می‌توان بر حسب کیلوبایت (MINSPACE) یا به صورت درصدی از کل دیسک (MINPERCENT% همراه با نویسه '%') تعیین کرد؛ در صورتی که هیچ‌کدام مشخص نشوند، مقدار پیش‌فرض 100kB خواهد بود. اگر فضای خالی دیسک به زیر این آستانه کاهش یابد، نمونه dskErrorFlag متناظر برابر با 1 قرار می‌گیرد و پیام توصیفی مناسبی از طریق نمونه dskErrorMsg گزارش می‌شود.

includeAllDisks MINPERCENT%

پایش تمام دیسک‌های یافت‌شده در سیستم را با استفاده از آستانه مشخص‌شده (درصدی) پیکربندی می‌کند. جدول dskTable به‌صورت پویا به‌روزرسانی می‌شود؛ دیسک‌های پیاده‌شده از جدول حذف شده و دیسک‌های تازه سوارشده به جدول اضافه می‌شوند. آستانه مربوط به دیسک‌های جداگانه را می‌توان با استفاده از دستورالعمل‌های مناسب disk (که می‌توانند قبل یا بعد از دستورالعمل includeAllDisks بیایند) تنظیم کرد.

تنها باید یک دستورالعمل includeAllDisks مشخص شود - هرگونه نسخه‌های بعدی نادیده گرفته خواهند شد.

فهرست دیسک‌های سوارشده از HOST-RESOURCES-MIB::hrFSTable تعیین خواهد شد.

اگر هیچ‌کدام از دستورالعمل‌های disk یا includeAllDisks تعریف نشده باشند، پیمایش جدول dskTable با شکست مواجه خواهد شد (noSuchObject).

پایش ورودی/خروجی دیسک (Disk I/O Monitoring)

این ویژگی مستلزم آن است که عامل با پشتیبانی از ماژول ucd-snmp/diskio ساخته شده باشد (که به عنوان بخشی از پیکربندی پیش‌فرض ساخت گنجانده نشده است).

به‌طور پیش‌فرض، تمام دستگاه‌های بلوکی شناخته‌شده برای سیستم‌عامل در diskIOTable گنجانده می‌شوند. در پلتفرم‌هایی غیر از Linux، این ماژول هیچ دستورالعمل پیکربندی ندارد.

در سیستم‌های Linux، امکان مستثنی کردن چندین رده از دستگاه‌های بلوکی از diskIOTable وجود دارد تا از شلوغ شدن جدول با آمارهای صفر بی‌فایده برای شبه‌دستگاه‌هایی که اغلب استفاده نمی‌شوند اما به‌طور پیش‌فرض در اکثر توزیع‌های اخیر Linux وجود دارند، جلوگیری شود.

diskio_exclude_fd yes

تمام دستگاه‌های بلوکی فلاپی‌دیسک Linux را که نامشان با "fd" شروع می‌شود، مانند "fd0"، مستثنی می‌کند.

diskio_exclude_loop yes

تمام دستگاه‌های بلوکی loopback در Linux را که نامشان با "loop" شروع می‌شود، مانند "loop0"، مستثنی می‌کند.

diskio_exclude_ram yes

تمام دستگاه‌های بلوکی ramdisk در Linux را که نامشان با "ram" شروع می‌شود، مانند "ram0"، مستثنی می‌کند.

diskio_exclude_md yes

تمام دستگاه‌های بلوکی RAID در Linux را که نامشان با "md" شروع می‌شود، مانند "md0"، مستثنی می‌کند.

در سیستم‌های Linux، همچنین این امکان وجود دارد که گزارش‌گیری صرفاً به دستگاه‌های موجود در لیست مجاز صریح محدود شود. پردازش داده‌های diskIOTable در سیستم‌هایی با ده‌ها هزار دستگاه بلوکی ممکن است زمان قابل‌توجهی ببرد و قرار دادن تنها دستگاه‌های مهم در لیست مجاز از مصرف بالای CPU جلوگیری می‌کند.

diskio <device>

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

پایش بار سیستم (System Load Monitoring)

این ویژگی مستلزم آن است که عامل به ترتیب با پشتیبانی از ماژول ucd-snmp/loadave یا ماژول ucd-snmp/memory ساخته شده باشد (که هر دو به عنوان بخشی از پیکربندی پیش‌فرض ساخت گنجانده شده‌اند).

load MAX1 [MAX5 [MAX15]]

میانگین بار (load average) سیستم محلی را پایش می‌کند و آستانه‌هایی را برای میانگین‌های ۱ دقیقه، ۵ دقیقه و ۱۵ دقیقه مشخص می‌سازد. اگر هر یک از این بارها از مقدار حداکثر مربوطه فراتر رود، نمونه laErrorFlag متناظر برابر با 1 قرار می‌گیرد و پیام توصیفی مناسبی از طریق نمونه laErrMessage گزارش می‌شود.

اگر آستانه MAX15 حذف شود، مقدار پیش‌فرض آن برابر با مقدار MAX5 خواهد بود. اگر هر دو مقدار MAX5 و MAX15 حذف شوند، پیش‌فرض آن‌ها برابر با مقدار MAX1 خواهد بود. اگر این دستورالعمل مشخص نشود، هر سه آستانه به مقدار DEFMAXLOADAVE پیش‌فرض می‌شوند.

اگر مقدار آستانه 0 تعیین شود، عامل صرف‌نظر از بار فعلی، خطاها را از طریق نمونه‌های مربوطه laErrorFlag یا laErrMessage گزارش نخواهد کرد.

بر خلاف دستورالعمل‌های proc و disk، پیمایش جدول laTable با موفقیت انجام خواهد شد (با این فرض که ماژول ucd-snmp/loadave در عامل پیکربندی شده باشد)، حتی اگر دستورالعمل load وجود نداشته باشد.

swap MIN

میزان فضای swap موجود در سیستم محلی را پایش می‌کند. اگر این مقدار به زیر آستانه مشخص‌شده (MIN کیلوبایت) کاهش یابد، شیء memErrorSwap برابر با 1 قرار می‌گیرد و پیام توصیفی مناسبی از طریق memSwapErrorMsg گزارش می‌شود.

پایش فایل لاگ (Log File Monitoring)

این ویژگی مستلزم آن است که عامل به ترتیب با پشتیبانی از ماژول‌های ucd-snmp/file یا ucd-snmp/logmatch ساخته شده باشد (که هر دو به عنوان بخشی از پیکربندی پیش‌فرض ساخت گنجانده شده‌اند).

file FILE [MAXSIZE]

اندازه فایل مشخص‌شده را (بر حسب کیلوبایت) پایش می‌کند. اگر MAXSIZE مشخص شود و اندازه فایل از این آستانه فراتر رود، نمونه fileErrorFlag متناظر برابر با 1 قرار می‌گیرد و پیام توصیفی مناسبی از طریق نمونه fileErrorMsg گزارش خواهد شد.

نکته: حداکثر ۲۰ فایل را می‌توان پایش کرد.

نکته: اگر هیچ دستورالعمل file تعریف نشده باشد، پیمایش fileTable با شکست مواجه خواهد شد (noSuchObject).

logmatch NAME FILE CYCLETIME REGEX

فایل مشخص‌شده را برای موارد وقوع الگوی REGEX تعیین‌شده پایش می‌کند. موقعیت فایل به‌صورت داخلی ذخیره می‌شود تا کل فایل تنها در ابتدا خوانده شود؛ هر بررسی بعدی تنها خطوط جدیدی را که از زمان خواندن قبلی به فایل اضافه شده‌اند، می‌خواند.

مثال:

نکته: حداکثر ۲۵۰ دستورالعمل logmatch می‌توانند مشخص شوند.

نکته: اگر هیچ دستورالعمل logmatch تعریف نشده باشد، پیمایش logMatchTable با شکست مواجه خواهد شد (noSuchObject).

مدیریت اعلان‌ها (Notification Handling)

trapcommunity STRING

رشته انجمن (community string) پیش‌فرضی را که باید هنگام ارسال trapها استفاده شود، مشخص می‌کند. توجه داشته باشید این دستورالعمل باید قبل از هر دستورالعمل مقصد trap مبتنی بر انجمنی که نیاز به استفاده از آن دارد، قرار گیرد.

trapsink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]

trap2sink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]

informsink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]

به ترتیب آدرس دریافت‌کننده اعلانی را مشخص می‌کنند که باید اعلان‌های SNMPv1 TRAP، SNMPv2c TRAP2 یا SNMPv2 INFORM برای آن ارسال شود. برای اطلاعات بیشتر درباره قالب نشانی‌های شنود، بخش LISTENING ADDRESSES را در صفحه راهنمای snmpd(8) ببینید. اگر COMMUNITY مشخص نشده باشد، آخرین رشته trapcommunity استفاده خواهد شد.

اگر نشانی انتقال شامل پورت صریح نباشد، از PORT استفاده خواهد شد. در صورت عدم تعیین آن، پورت شناخته‌شده اعلان SNMP (شماره ۱۶۲) استفاده می‌شود.

پارامترهای اختیاری name و tag نام یا برچسبی را که برای ورودی‌های جدول SNMP-NOTIFICATION-MIB استفاده خواهد شد، مشخص می‌کنند. profile مشخص می‌کند کدام ورودی نمایه فیلتر اعلان برای فیلتر کردن اعلان‌های خروجی استفاده می‌شود. (ببینید: notificationFilter)

پارامتر اختیاری src نشانی مبدأیی را که هنگام ارسال بسته trap به این مقصد (sink) استفاده می‌شود، مشخص می‌کند. این پارامتر به صورت یک <transport-address> با استفاده از همان <transport-specifier> به عنوان HOST مقصد تعیین می‌شود. برای اطلاعات بیشتر در مورد قالب، بخش LISTENING ADDRESSES را در صفحه راهنمای snmpd(8) ببینید.

اگر چندین دستورالعمل sink تعیین شوند، نسخه‌های متعددی از هر اعلان (در قالب‌های مناسب) تولید خواهد شد.

trapsess [-profile p] [-name n] [-tag t] [-s src] [SNMPCMD_ARGS] HOST

سازوکار عمومی‌تری برای تعریف مقصدهای اعلان فراهم می‌کند. SNMPCMD_ARGS باید گزینه‌های خط فرمانی باشند که برای دستور معادل snmptrap (یا snmpinform) جهت ارسال اعلان مورد نظر نیاز است. گزینه -Ci می‌تواند (همراه با -v2c یا -v3) برای تولید یک اعلان INFORM به جای یک TRAP تأییدنشده استفاده شود.

پارامترهای اختیاری name و tag نام یا برچسبی را که برای ورودی‌های جدول SNMP-NOTIFICATION-MIB استفاده خواهد شد، مشخص می‌کنند. profile مشخص می‌کند کدام ورودی نمایه فیلتر اعلان برای فیلتر کردن اعلان‌های خروجی استفاده می‌شود. (ببینید: notificationFilter)

این دستورالعمل مناسب برای تعریف دریافت‌کننده‌های trap در SNMPv3 است. برای اطلاعات بیشتر درباره رفتار اعلان‌های SNMPv3 به نشانی زیر مراجعه کنید: http://www.net-snmp.org/tutorial/tutorial-5/commands/snmptrap-v3.html

notificationFilter NAME OID MASK TYPE

یک نمایه فیلتر اعلان SNMP-NOTIFICATION-MIB را مشخص می‌کند که می‌تواند برای فیلتر کردن trapها به کار رود. TYPE باید included یا excluded باشد. چند مثال:

authtrapenable {1|2}

تعیین می‌کند که آیا trapهای شکست احراز هویت تولید شوند (enabled(1)) یا خیر (disabled(2) - حالت پیش‌فرض). به طور معمول شیء MIB متناظر (snmpEnableAuthenTraps.0) به صورت خواندنی-نوشتنی است، اما مشخص کردن این دستورالعمل این شیء را فقط‌خواندنی می‌کند و تلاش برای تنظیم مقدار از طریق درخواست‌های SET به پاسخ خطای notWritable منجر خواهد شد.

v1trapaddress HOST

نشانی کارگزار را که در SNMPv1 TRAPها درج می‌شود، تعریف می‌کند. در صورت حذف این گزینه، یک نشانی IPv4 محلی دلخواه انتخاب می‌شود. این گزینه عمدتاً زمانی مفید است که کارگزار از دنیای بیرون تنها با یک نشانی خاص قابل مشاهده باشد (برای مثال به دلیل ترجمه نشانی شبکه یا فایروال).

DisMan Event MIB

دستورالعمل‌های قبلی می‌توانند برای پیکربندی محل ارسال trapها استفاده شوند، اما به زمان ارسال چنین trapهایی (یا اینکه چه trapهایی باید تولید شوند) کاری ندارند. این حوزه مربوط به Event MIB است - که توسط گروه کاری مدیریت توزیع‌شده (DisMan) در IETF توسعه یافته است.

این نیازمند ساخته شدن کارگزار با پشتیبانی از ماژول disman/event است (که اکنون به عنوان بخشی از پیکربندی ساخت پیش‌فرض برای جدیدترین توزیع گنجانده شده است).

iquerySecName NAME

agentSecName NAME

نام کاربری پیش‌فرض SNMPv3 را برای استفاده در پرس‌وجوهای داخلی جهت بازیابی اطلاعات لازم (چه برای ارزیابی عبارت نظارت‌شده یا ساخت محموله اعلان) تعیین می‌کند. این پرس‌وجوهای داخلی همیشه از SNMPv3 استفاده می‌کنند، حتی اگر پرس‌وجوی معمول از کارگزار با استفاده از SNMPv1 یا SNMPv2c انجام شود.

توجه داشته باشید که این کاربر باید صراحتاً ایجاد شود (createUser) و حقوق دسترسی مناسب (مثلاً rouser) به آن داده شود. این دستورالعمل صرفاً به تعیین اینکه کدام کاربر باید استفاده شود مربوط است - نه ایجاد و راه‌اندازی واقعی این کاربر.

monitor [OPTIONS] NAME EXPRESSION

یک شیء MIB را برای نظارت تعریف می‌کند. اگر شرط EXPRESSION برقرار باشد (پایین را ببینید)، رویداد مربوطه برانگیخته خواهد شد و اعلانی ارسال می‌کند یا انتساب SET را اعمال می‌کند (یا هر دو). توجه داشته باشید رویداد فقط یک بار، هنگامی که عبارت برای بار نخست تطبیق می‌یابد، فعال می‌شود. این ورودی نظارتی دوباره فعال نخواهد شد مگر آنکه وضعیت نظارت‌شده ابتدا نادرست شده و سپس مجدداً تطبیق یابد. NAME یک نام مدیریتی برای این عبارت است و برای نمایه‌سازی mteTriggerTable (و جدول‌های مرتبط) به کار می‌رود. هر خط monitor باید یک NAME منحصر‌به‌فرد داشته باشد. خطوط monitor با نام تکراری نادیده گرفته شده و باعث می‌شوند snmpd پیام خطای نمایه تکراری را ثبت کند. همچنین توجه داشته باشید چنین ناظرانی از یک درخواست داخلی SNMPv3 برای بازیابی مقادیر تحت نظارت استفاده می‌کنند (حتی اگر پرس‌وجوهای معمول کارگزار عموماً از SNMPv1 یا SNMPv2c استفاده کنند). نشانه iquerySecName شرح داده شده در بالا را ببینید.

EXPRESSION

سه نوع عبارت نظارتی توسط Event MIB پشتیبانی می‌شود - آزمون‌های وجود، بولی و آستانه.

OPTIONS

گزینه‌های گوناگونی برای کنترل رفتار عبارت تحت نظارت وجود دارد، از جمله:

notificationEvent ENAME NOTIFICATION [-m] [-i OID | -o OID ]*

یک رویداد اعلان با نام ENAME تعریف می‌کند. این مورد را می‌توان با مشخص کردن گزینه -e ENAME از یک ورودی monitor داده‌شده فراخوانی کرد (بالا را ببینید). NOTIFICATION باید OID مربوط به تعریف NOTIFICATION-TYPE برای اعلانی باشد که قرار است تولید شود.

اگر گزینه -m داده شود، بار داده اعلان شامل varbindهای استانداردی خواهد بود که در بند OBJECTS از تعریف MIB اعلان مشخص شده‌اند. این گزینه باید پس از NOTIFICATION OID بیاید (و فایل MIB مربوطه باید در دسترس بوده و توسط کارگزار بارگذاری شده باشد). در غیر این صورت، این varbindها باید به‌طور صریح فهرست شوند (چه در اینجا و چه در دستورالعمل monitor متناظر).

گزینه‌های -i OID و -o OID مشخص‌کننده varbindهای اضافی هستند که باید پس از فهرست استاندارد، به بار داده اعلان افزوده شوند. اگر ورودی پایش که این رویداد را برانگیخته شامل یک عبارت عامه‌نویسه (wildcarded) باشد، پسوند نمونه تطبیق‌یافته به تمام OIDهای مشخص‌شده با -o اضافه خواهد شد، در حالی که OIDهای مشخص‌شده با -i به عنوان نمونه‌های دقیق در نظر گرفته می‌شوند. اگر فلگ -I برای دستورالعمل monitor مشخص شده باشد، تفاوتی میان این دو گزینه وجود ندارد.

setEvent ENAME [-I] OID = VALUE

یک رویداد تنظیم (set event) به نام ENAME تعریف می‌کند که مقدار (صحیح) VALUE را به OID مشخص‌شده انتساب می‌دهد. این می‌تواند از یک ورودی monitor داده‌شده با مشخص کردن گزینه -e ENAME فعال شود (بالا را ببینید).

اگر ورودی پایشی که این رویداد را برانگیخته شامل یک عبارت عامه‌نویسه باشد، پسوند نمونه منطبق‌شده معمولاً به OID اضافه می‌شود. اگر فلگ -I در هر یک از دستورالعمل‌های monitor یا setEvent مشخص شده باشد، OID تعیین‌شده به عنوان یک نمونه دقیق واحد در نظر گرفته خواهد شد.

strictDisman yes

تعریف اعلان‌های SNMP بیان می‌کند که varbindهای تعریف‌شده در بند OBJECT باید در ابتدا (به ترتیب مشخص‌شده) قرار گیرند، و پس از آن هرگونه varbind «اضافی» که تولیدکننده اعلان مفید تشخیص می‌دهد بیاید. طبیعی‌ترین رویکرد این است که این varbindهای اجباری با ورودی notificationEvent مرتبط شده و هرگونه varbind مرتبط با ورودی پایش که اعلان را فعال کرده است به انتهای این فهرست افزوده شود. این رفتار پیش‌فرض پیاده‌سازی Event MIB در Net-SNMP است.

متأسفانه، مشخصات DisMan Event MIB در واقع بیان می‌کند که varbindهای مربوط به محرک باید در ابتدا بیایند، و پس از آن موارد مربوط به رویداد قرار گیرند. این دستورالعمل می‌تواند برای بازگرداندن این رفتار دقیقاً صحیح (اما نامناسب) استفاده شود.

اگر هیچ ورودی monitor بار داده varbindها را مشخص نکند، مقدار این دستورالعمل بی‌اثر خواهد بود.

linkUpDownNotifications yes

جدول‌های Event MIB را برای پایش ifTable جهت بررسی فعال یا غیرفعال شدن رابط‌های شبکه پیکربندی می‌کند و بر حسب مورد یک اعلان linkUp یا linkDown ایجاد می‌نماید.

این پیکربندی دقیقاً معادل با موارد زیر است:

defaultMonitors yes

جدول‌های Event MIB را برای پایش جدول‌های مختلف UCD-SNMP-MIB از نظر مشکلات (همان‌طور که توسط اشیاء ستونی xxErrFlag مربوطه مشخص می‌شود) پیکربندی می‌کند.

این پیکربندی دقیقاً معادل با موارد زیر است:

در هر دوی این موارد اخیر، snmpd.conf باید همچنین حاوی یک دستورالعمل iquerySecName، همراه با ورودی متناظر createUser و پیکربندی کنترل دسترسی مناسب باشد.

DisMan Schedule MIB

گروه کاری DisMan همچنین سازوکاری را برای زمان‌بندی اقدامات خاص (یک انتساب SET مشخص‌شده) در زمان‌های تعیین‌شده ارائه کرده است. این امر نیازمند آن است که کارگزار با پشتیبانی از ماژول disman/schedule ساخته شده باشد (که به عنوان بخشی از پیکربندی ساخت پیش‌فرض برای جدیدترین توزیع گنجانده شده است).

سه روش برای تعیین اقدام زمان‌بندی‌شده وجود دارد:

repeat FREQUENCY OID = VALUE

یک انتساب SET از مقدار (صحیح) VALUE به نمونه MIB به نام OID را پیکربندی می‌کند تا هر FREQUENCY ثانیه اجرا شود، که در آن FREQUENCY برحسب ثانیه است یا می‌تواند با یکی از پسوندهای s (برای ثانیه)، m (برای دقیقه)، h (برای ساعت)، d (برای روز)، یا w (برای هفته) مشخص شود.

cron MINUTE HOUR DAY MONTH WEEKDAY OID = VALUE

یک انتساب SET از مقدار (صحیح) VALUE به نمونه MIB به نام OID را پیکربندی می‌کند تا در زمان‌های مشخص‌شده توسط فیلدهای MINUTE تا WEEKDAY اجرا شود. این فیلدها از الگویی مشابه فیلدهای معادل در crontab(5) پیروی می‌کنند.

فیلد DAY همچنین می‌تواند مقادیر منفی بپذیرد تا روزهایی را نشان دهد که از انتهای ماه به عقب شمارش می‌شوند.

at MINUTE HOUR DAY MONTH WEEKDAY OID = VALUE

یک انتساب SET یک‌باره را پیکربندی می‌کند تا در نخستین زمان منطبق مشخص‌شده توسط فیلدهای MINUTE تا WEEKDAY اجرا شود. تفسیر این فیلدها دقیقاً مانند دستورالعمل cron است.

تحویل داده از طریق اعلان‌ها (Data Delivery via Notifications)

نکته: این قابلیت تنها زمانی در دسترس است که ماژول MIB به نام deliver/deliverByNotify در کارگزار کامپایل شده باشد.

در برخی شرایط ممکن است تحویل داده‌های SNMP از طریق اعلان‌های SNMP (مانند TRAPها و INFORMها) نسبت به روش معمول که در آن مدیر درخواست‌ها را برای داده ارسال می‌کند (از طریق GETها و GETNEXTها)، مزیت داشته باشد. دلایل این کار بسیارند اما اغلب در موارد خاص و نادر مطرح می‌شوند. متداول‌ترین دلیل برای نیاز به چنین رفتاری، پایش دستگاه‌هایی است که پشت NAT یا فایروال‌هایی قرار دارند که مانع از ورود ترافیک SNMP می‌شوند.

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

اعلان‌های تولیدشده از طریق این سازوکار به مجموعه استاندارد مقاصد اعلان پیکربندی‌شده ارسال خواهند شد. برای اطلاعات بیشتر بخش «Notification Handling» در این سند را ببینید.

deliverByNotify [-p] [-m] [-s MAXSIZE] FREQUENCY OID

این دستورالعمل به کارگزار SNMP اعلام می‌کند که OID را به‌طور خودکار پیمایش (self-walk) کرده، تمام داده‌ها را جمع‌آوری کند و هر FREQUENCY ثانیه به بیرون ارسال نماید؛ که در آن FREQUENCY برحسب ثانیه است یا می‌تواند با یکی از پسوندهای s (برای ثانیه)، m (برای دقیقه)، h (برای ساعت)، d (برای روز)، یا w (برای هفته) مشخص شود. به‌طور پیش‌فرض، مقادیر اسکالر در اعلان گنجانده می‌شوند که دوره ارسال اعلان (مگر اینکه گزینه -p مشخص شده باشد) و شماره پیام یک اعلان خاص از کل تعداد پیام‌ها را تعیین می‌کنند (مگر اینکه -m مشخص شده باشد). برای تقسیم اعلان‌ها به اندازه‌های بسته قابل مدیریت، از فلگ -s استفاده کنید تا حداکثر تعداد بایت‌های تقریبی مجاز برای یک پیام اعلان را مشخص نمایید. اگر بیش از MAXSIZE بایت نیاز باشد، اعلان‌های متعددی برای تحویل داده ارسال خواهند شد. توجه داشته باشید که محاسبات برای تضمین رعایت حداکثر اندازه تقریبی هستند و بنابراین تضمین قطعی وجود ندارد که همیشه کمتر از آن اندازه باشند؛ پس اگر جلوگیری از تکه‌تکه شدن (fragmentation) حیاتی است، مقداری بافر حاشیه در نظر بگیرید. مقدار ۱- نشان‌دهنده قرار دادن اجباری همه‌چیز در یک پیام واحد است، صرف‌نظر از اینکه چقدر بزرگ باشد.

نمونه کاربرد: موارد زیر محتویات ifTable را هر ساعت یک‌بار و محتویات گروه system را هر ۲ ساعت یک‌بار تحویل می‌دهند:

deliverByNotify 3600 ifTable
deliverByNotify 7200 system

deliverByNotifyMaxPacketSize SIZEINBYTES

محدودیت پیش‌فرض اندازه اعلان را تنظیم می‌کند (فلگ -s در بالا را ببینید).

deliverByNotifyOid OID

deliverByNotifyFrequencyOid OID

deliverByNotifyMessageNumberOid OID

deliverByNotifyMaxMessageNumberOid OID

این گزینه‌ها OID داده‌ای را که اعلان تحت آن ارسال می‌شود، OID اسکالر، OID شماره پیام، و OID حداکثر شماره پیام را تنظیم می‌کنند. مقادیر پیش‌فرض این‌ها اشیائی در NET-SNMP-PERIODIC-NOTIFY-MIB هستند.

دستورهای دلخواه گسترش (Arbitrary Extension Commands)

نخستین سازوکار گسترش، قابلیت اجرای دستورهای دلخواه یا اسکریپت‌های شل بود. این دستورها نیازی به آگاهی از عملیات SNMP یا تطابق با رفتار خاصی ندارند - ساختارهای MIB طوری طراحی شده‌اند که با هر شکلی از خروجی دستور سازگار باشند. استفاده از این سازوکار نیازمند آن است که کارگزار با پشتیبانی از ماژول‌های ucd-snmp/extensible و/یا agent/extend (که هر دو در پیکربندی پیش‌فرض ساخت گنجانده شده‌اند) کامپایل شده باشد.

exec [MIBOID] NAME PROG ARGS

sh [MIBOID] NAME PROG ARGS

برنامه تعیین‌شده در PROG را با آرگومان‌های ARGS فراخوانی می‌کند. به‌طور پیش‌فرض وضعیت خروج و نخستین خط خروجی دستور از طریق extTable گزارش شده و خروجی‌های اضافی نادیده گرفته می‌شوند.

آرگومان PROG در دستورالعمل‌های exec باید مسیر کاملی به یک فایل اجرایی واقعی باشد، زیرا از طریق فراخوانی سیستمی exec() اجرا می‌شود. برای فراخوانی یک اسکریپت شل، در عوض از دستورالعمل sh استفاده کنید.

در صورت تعیین MIBOID، نتایج در این نقطه از درخت OID ریشه می‌گیرند و وضعیت خروج را به‌صورت MIBOID.100.0 و کل خروجی دستور را در یک شبه‌جدول مستقر در MIBNUM.101 - با یک «ردیف» برای هر خط خروجی - بازمی‌گردانند.

کارگزار وضعیت خروج یا خروجی برنامه اجرا شده را کش نمی‌کند.

execfix NAME PROG ARGS

دستوری را ثبت می‌کند که در صورت نیاز قابل فراخوانی است - معمولاً برای پاسخ به خطاها یا رفع خطاهای مربوط به مدخل exec یا sh متناظر. هنگامی که نمونه extErrFix برای یک مدخل با NAME مشخص به مقدار عدد صحیح 1 تنظیم شود، این دستور فراخوانی خواهد شد.

افزونه‌های exec و sh تنها از طریق فایل snmpd.conf قابل پیکربندی هستند. امکان تنظیم آن‌ها از طریق درخواست‌های SNMP SET وجود ندارد.

extend [-cacheTime TIME] [-execType TYPE] [MIBOID] NAME PROG ARGS

مشابه دستورالعمل exec عمل می‌کند، اما با چندین بهبود. جدول‌های MIB (مانند nsExtendConfigTable و غیره) با شناسه NAME نمایه‌سازی می‌شوند، بنابراین از ترتیبی که مدخل‌ها از فایل‌های پیکربندی خوانده می‌شوند تأثیر نمی‌پذیرند. دو جدول نتایج وجود دارد - یکی (nsExtendOutput1Table) شامل وضعیت خروج، خط نخست و خروجی کامل (به‌صورت یک رشته منفرد) برای هر مدخل extend، و دیگری (nsExtendOutput2Table) شامل خروجی کامل به‌صورت مجموعه‌ای از خطوط مجزا.

در صورت تعیین -cacheTime، آرگومان آن به‌عنوان زمان انقضای کش (برحسب ثانیه کامل) برای این مدخل extend استفاده می‌شود. این سازوکار روشی ماندگار برای تعیین زمان انقضای کش فراهم می‌سازد.

در صورت تعیین -execType و داشتن مقدار sh، این مدخل extend در یک شل اجرا خواهد شد. در غیر این صورت به روش پیش‌فرض exec اجرا می‌شود. این سازوکار روشی ماندگار برای تعیین نوع اجرا فراهم می‌سازد.

در صورت تعیین MIBOID، جدول‌های پیکربندی و نتایج در این نقطه از درخت OID ریشه می‌گیرند، اما ساختار آن‌ها در سایر جهات دقیقاً یکسان است. این بدین معناست که چندین دستورالعمل مجزای extend می‌توانند بدون تداخل، ریشه MIBOID یکسانی را مشخص کنند.

وضعیت خروج و خروجی برای هر مدخل به‌طور مجزا کش می‌شود، و می‌توان آن را با استفاده از nsCacheTable پاک کرد (و رفتار کش‌گذاری را پیکربندی نمود).

extendfix NAME PROG ARGS

دستوری را ثبت می‌کند که در صورت نیاز، با تنظیم نمونه مناسب nsExtendRunType روی مقدار run-command(3) فراخوانی می‌شود. بر خلاف دستور معادل execfix، این دستورالعمل نیازی به جفت شدن با یک مدخل متناظر extend ندارد و می‌تواند به‌تنهایی استفاده شود.

هر دو دستورالعمل extend و extendfix را می‌توان به‌صورت پویا با استفاده از درخواست‌های SNMP SET در NET-SNMP-EXTEND-MIB پیکربندی کرد.

دستورهای گسترش ویژه MIB (MIB-Specific Extension Commands)

گروه نخست دستورالعمل‌های گسترش، دستورهای دلخواه را فراخوانی کرده و وابسته به انعطاف‌پذیری ساختار MIB (و برنامه‌های مدیریتی) برای پذیرش و تفسیر خروجی هستند. این روشی مناسب برای در دسترس قرار دادن سریع و ساده اطلاعات است، اما هنگام پیاده‌سازی اشیاء خاص MIB که در آن‌ها افزونه باید با ساختار MIB مطابقت داشته باشد (و نه برعکس)، کاربردی ندارد. سازوکارهای باقی‌مانده گسترش همگی به چنین موقعیت‌های ویژه MIB مربوط می‌شوند - که با اسکریپت‌های «گذر مستقیم» (pass-through) آغاز می‌شوند. استفاده از این سازوکار نیازمند آن است که کارگزار با پشتیبانی از ماژول‌های ucd-snmp/pass و ucd-snmp/pass_persist (که هر دو در پیکربندی پیش‌فرض ساخت گنجانده شده‌اند) کامپایل شده باشد.

pass [-p priority] MIBOID PROG

کنترل زیردرخت ریشه‌گرفته از MIBOID را به دستور PROG مشخص‌شده واگذار می‌کند. درخواست‌های GET و GETNEXT برای شناسه‌های OID درون این درخت، این دستور را فراخوانی می‌کنند که به‌صورت زیر اجرا می‌شود:

به‌ترتیب، که در آن OID همان OID درخواست‌شده است. دستور PROG باید پاسخ varbind را به‌صورت سه خط مجزا در stdout چاپ کند - خط اول باید OID مقدار بازگشتی باشد، خط دوم باید TYPE آن باشد (یکی از رشته‌های متنی integer, gauge, counter, timeticks, ipaddress, objectid, octet, یا string )، و خط سوم باید خود مقدار باشد. (نکته: مقادیر octet به‌صورت رشته‌های هگزادسیمال متنی ASCII و جداشده با فاصله ارسال می‌شوند، مانند "00 3f dd 00 c6 be").

اگر دستور نتواند یک varbind مناسب بازگرداند - برای نمونه OID مشخص‌شده با یک نمونه معتبر برای درخواست GET مطابقت نداشته باشد، یا نمونه بعدی برای GETNEXT وجود نداشته باشد - باید بدون تولید هیچ خروجی خارج شود. این وضعیت منجر به خطای SNMP با عنوان noSuchName یا استثنای noSuchInstance خواهد شد.

یک درخواست SET منجر به فراخوانی دستور به‌صورت زیر خواهد شد:

که در آن TYPE یکی از نشانه‌های فهرست‌شده در بالا است و نوع مقدار ارسال‌شده به‌عنوان پارامتر سوم را مشخص می‌کند.

در صورت موفقیت‌آمیز بودن انتساب، دستور PROG باید بدون تولید هیچ خروجی خارج شود. خطاها باید با نوشتن یکی از رشته‌های not-writable, یا wrong-type در stdout مشخص شوند، و کارگزار پاسخ خطای مناسب را تولید خواهد کرد.

در هر دو حالت، دستور پس از پایان پردازش باید خارج شود. هر درخواست (و هر varbind درون یک درخواست منفرد) موجب فراخوانی مجزایی از دستور خواهد شد.

اولویت پیش‌فرض ثبت ۱۲۷ است. این مقدار را می‌توان با ارائه فلگ اختیاری -p تغییر داد؛ ثبت‌های دارای اولویت پایین‌تر نسبت به مقادیر اولویت بالاتر در ارجحیت قرار می‌گیرند.

pass_persist [-p priority] MIBOID PROG

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

هنگام مقداردهی اولیه، رشته «PING\n» در stdin به PROG ارسال می‌شود و این دستور باید با چاپ «PONG\n» در stdout پاسخ دهد.

برای درخواست‌های GET و GETNEXT، دو خط در stdin به PROG ارسال می‌شود: دستور (get یا getnext) و OID درخواست‌شده. این برنامه باید با چاپ سه خط در stdout پاسخ دهد - OID برای varbind نتیجه، TYPE و خود VALUE - دقیقاً مشابه دستورالعمل pass در بالا. اگر دستور نتواند یک varbind مناسب بازگرداند، باید «NONE\n» را در stdout چاپ کند (اما به اجرا ادامه دهد).

برای درخواست‌های SET، سه خط در stdin به PROG ارسال می‌شود: دستور (set) و OID درخواست‌شده، به‌همراه نوع و مقدار (هر دو در یک خط). در صورت موفقیت‌آمیز بودن انتساب، دستور باید عبارت «DONE\n» را در stdout چاپ کند. خطاها باید با نوشتن یکی از رشته‌های not-writable, wrong-type, wrong-length, wrong-value یا inconsistent-value در stdout مشخص شوند، و کارگزار پاسخ خطای مناسب را ایجاد خواهد کرد. در هر دو حالت، دستور باید به اجرای خود ادامه دهد.

اولویت ثبت را می‌توان با استفاده از فلگ اختیاری -p تغییر داد، دقیقاً مانند دستورالعمل pass.

افزونه‌های pass و pass_persist تنها از طریق فایل snmpd.conf قابل پیکربندی هستند. امکان تنظیم آن‌ها از طریق درخواست‌های SNMP SET وجود ندارد.

پشتیبانی از Perl توکار

برنامه‌هایی که از سازوکارهای توسعه قبلی استفاده می‌کنند می‌توانند با هر زبان برنامه‌نویسی مناسبی نوشته شوند - از جمله perl، که به ویژه برای توسعه‌های عبوری (pass-through) یک انتخاب رایج است. با این حال عامل Net-SNMP همچنین شامل پشتیبانی از فناوری perl توکار (مشابه mod_perl برای وب‌سرور Apache) است. این قابلیت به عامل اجازه می‌دهد تا اسکریپت‌های perl را مستقیماً تفسیر کند، و در نتیجه از بار اضافی ایجاد فرآیندها و مقداردهی اولیه سیستم perl هنگام دریافت درخواست جلوگیری می‌نماید.

استفاده از این سازوکار مستلزم آن است که عامل با پشتیبانی از سازوکار perl توکار ساخته شده باشد، که بخشی از محیط ساخت پیش‌فرض نیست. این گزینه باید هنگام ساخت اولیه بسته، با مشخص کردن گزینه '--enable-embedded-perl' برای اسکریپت configure صراحتاً گنجانده شود.

در صورت فعال بودن، دستورالعمل‌های زیر شناخته خواهند شد:

disablePerl true

پشتیبانی از perl توکار را کاملاً غیرفعال می‌کند (مثلاً اگر در نصب perl مشکلاتی وجود داشته باشد).

perlInitFile FILE

فایل مقداردهی اولیه مشخص‌شده را (در صورت وجود) بلافاصله پیش از تجزیه اولین دستورالعمل perl بارگذاری می‌کند. اگر صراحتاً مشخص نشود، عامل به دنبال فایل مقداردهی اولیه پیش‌فرض /usr/share/snmp/snmp_perl.pl خواهد گشت.

فایل مقداردهی اولیه پیش‌فرض یک نمونه از شیء NetSNMP::agent ایجاد می‌کند - متغیر $agent که می‌تواند برای ثبت روتین‌های گرداننده MIB مبتنی بر perl استفاده شود.

perl EXPRESSION

عبارت داده‌شده را ارزیابی می‌کند. این کار معمولاً یک روتین گرداننده (handler) را ثبت می‌کند تا هنگام درخواست بخشی از درخت OID فراخوانی شود:

perl use Data::Dumper;
perl sub myroutine  { print "got called: ",Dumper(@_),"\n"; }
perl $agent->register('mylink', '.1.3.6.1.8765', \&myroutine);

این عبارت همچنین می‌تواند یک فایل خارجی را فراخوانی کند:

یا هر پردازش مبتنی بر perl دیگری را که ممکن است لازم باشد انجام دهد.

ماژول‌های با قابلیت بارگذاری پویا

بیشتر MIBهای پشتیبانی‌شده توسط عامل Net-SNMP به عنوان ماژول‌های کد C پیاده‌سازی شده‌اند، که هنگام ساخت اولیه مجموعه کامپایل شده و با کتابخانه‌های عامل پیوند داده شده‌اند (link شده‌اند). چنین ماژول‌های پیاده‌سازی را می‌توان به طور مستقل نیز کامپایل کرد و پس از شروع به کار عامل، درون آن بارگذاری نمود. استفاده از این سازوکار مستلزم آن است که عامل با پشتیبانی از ماژول ucd-snmp/dlmod (که به عنوان بخشی از پیکربندی ساخت پیش‌فرض گنجانده شده است) ساخته شده باشد.

dlmod NAME PATH

ماژول شیء اشتراکی (shared object) را از فایل PATH (یک نام فایل مطلق) بارگذاری می‌کند، و روتین مقداردهی اولیه init_NAME را فراخوانی می‌نماید.

این قابلیت را می‌توان با استفاده از درخواست‌های SNMP SET به UCD-DLMOD-MIB نیز پیکربندی کرد.

پشتیبانی از پروکسی

سازوکار دیگری برای گسترش قابلیت‌های عامل، انتقال درخواست‌های انتخاب‌شده (یا varbindهای انتخاب‌شده) به یک عامل SNMP دیگر است، که می‌تواند روی همان میزبان (احتمالاً در حال گوش دادن روی یک درگاه متفاوت) یا روی یک سیستم دوردست اجرا شود. این قابلیت را می‌توان هم به عنوان واگذاری درخواست‌ها از سوی عامل اصلی به عامل دوردست، و هم عمل کردن به عنوان یک پروکسی برای آن در نظر گرفت. استفاده از این سازوکار مستلزم آن است که عامل با پشتیبانی از ماژول ucd-snmp/proxy ساخته شده باشد (که به عنوان بخشی از پیکربندی ساخت پیش‌فرض گنجانده شده است).

proxy [-Cn CONTEXTNAME] [SNMPCMD_ARGS] HOST OID [REMOTEOID]

هرگونه درخواست ورودی ذیل OID را به عاملی که روی درگاه مشخص‌شده با آدرس انتقال HOST گوش می‌دهد، ارسال می‌کند. برای اطلاعات بیشتر درباره قالب آدرس‌های شنود، بخش آدرس‌های شنود (LISTENING ADDRESSES) را در صفحه راهنمای snmpd(8) ببینید.

پارامتر SNMPCMD_ARGS باید اطلاعات نسخه و مشخصات مدیریتی کافی را برای تولید یک درخواست معتبر SNMP فراهم کند (به snmpcmd(1) مراجعه کنید).

نکته:

درخواست پروکسی‌شده از تنظیمات مدیریتی درخواست اصلی استفاده نخواهد کرد.

اگر یک CONTEXTNAME مشخص شده باشد، این کار واگذاری پروکسی را در بستر (context) نام‌گذاری‌شده در عامل محلی ثبت می‌کند. تعریف چندین دستورالعمل proxy برای یک OID یکسان اما contextهای متفاوت می‌تواند برای پرس‌وجو از چندین عامل دوردست از طریق یک پروکسی منفرد، با مشخص کردن context مناسب SNMPv3 در درخواست ورودی (یا با استفاده از رشته‌های انجمن پیکربندی‌شده مناسب - دستورالعمل com2sec را ببینید) استفاده شود.

مشخص کردن پارامتر REMOID، درخت MIB محلی ریشه‌دار در OID را به زیردرخت معادل ریشه‌دار در REMOID روی عامل دوردست نگاشت می‌کند.

زیرعامل‌های SMUX

عامل Net-SNMP از پروتکل SMUX (RFC 1227) برای برقراری ارتباط با زیرعامل‌های مبتنی بر SMUX (مانند gated، zebra یا quagga) پشتیبانی می‌کند. استفاده از این سازوکار مستلزم آن است که عامل با پشتیبانی از ماژول smux ساخته شده باشد، که بخشی از محیط ساخت پیش‌فرض نیست، و باید هنگام ساخت اولیه بسته، با تعیین گزینه '--with-mib-modules=smux' در اسکریپت configure صراحتاً گنجانده شود.

smuxpeer OID PASS

یک زیردرخت را برای پردازش مبتنی بر SMUX ثبت می‌کند، تا با استفاده از گذرواژه PASS احراز هویت شود. اگر یک زیرعامل (یا «همتا») به عامل متصل شود و این زیردرخت را ثبت کند آن‌گاه درخواست‌ها برای OIDهای درون آن جهت پردازش به آن زیرعامل SMUX ارسال خواهد شد.

یک ورودی مناسب برای دیمن مسیریابی OSPF (مانند gated، zebra یا quagga) می‌تواند چیزی شبیه به این باشد:

smuxsocket <IPv4-address>

آدرس IPv4 را برای ارتباط همتاهای SMUX با عامل Net-SNMP تعیین می‌کند. حالت پیش‌فرض شنود روی تمام رابط‌های IPv4‏ ("0.0.0.0") است، مگر اینکه بسته در زمان ساخت با "--enable-local-smux" پیکربندی شده باشد، که باعث می‌شود به‌طور پیش‌فرض تنها روی 127.0.0.1 شنود کند. پروتکل SMUX از درگاه TCP شناخته‌شده ۱۹۹ استفاده می‌کند.

توجه داشته باشید که عامل Net-SNMP تنها به عنوان یک عامل اصلی (master) در SMUX عمل خواهد کرد. این عامل از ایفای نقش به عنوان زیرعامل SMUX پشتیبانی نمی‌کند.

زیرعامل‌های AgentX

عامل Net-SNMP از پروتکل AgentX (RFC 2741) در هر دو نقش عامل اصلی و زیرعامل پشتیبانی می‌کند. استفاده از این سازوکار مستلزم آن است که عامل با پشتیبانی از ماژول agentx ساخته شده باشد (که به عنوان بخشی از پیکربندی ساخت پیش‌فرض گنجانده شده است)، و همچنین این پشتیبانی صراحتاً فعال شده باشد (مثلاً از طریق فایل snmpd.conf).

دو دستورالعمل به‌طور خاص مربوط به اجرا به عنوان یک عامل اصلی AgentX هستند:

master agentx

قابلیت AgentX را فعال می‌کند و باعث می‌شود که عامل شنود را برای ثبت‌نام‌های ورودی AgentX آغاز کند. این مورد همچنین می‌تواند با مشخص کردن گزینه خط فرمان '-x' (برای تعیین یک سوکت شنود جایگزین) فعال شود.

agentXPerms SOCKPERMS [DIRPERMS [USER|UID [GROUP|GID]]]

مجوزها و مالکیت سوکت یونیکس دامین AgentX و پوشه‌های والد این سوکت را تعیین می‌کند. SOCKPERMS و DIRPERMS باید ارقام هشت‌هشتی باشند (ببینید: chmod(1) ). به‌طور پیش‌فرض، این سوکت فقط برای زیرعامل‌هایی قابل دسترسی خواهد بود که دارای شناسه‌ی کاربری (userid) یکسانی با عامل هستند.

یک دستورالعمل به‌طور خاص مربوط به اجرا به عنوان یک زیرعامل AgentX است:

agentXPingInterval NUM

باعث می‌شود که زیرعامل در صورت قطع ارتباط (یا شروع به کار در حالت قطع)، هر NUM ثانیه یک بار تلاش کند تا مجدداً به عامل اصلی متصل شود.

سایر دستورالعمل‌ها مربوط به هر دو نقش عامل اصلی و زیرعامل‌های AgentX هستند:

agentXSocket [<transport-specifier>:]<transport-address>[,...]

آدرسی را مشخص می‌کند که عامل اصلی روی آن شنود می‌کند یا زیرعامل باید به آن متصل شود. حالت پیش‌فرض، سوکت یونیکس دامین "/var/agentx/master" است. یک جایگزین رایج دیگر tcp:localhost:705 است. برای اطلاعات بیشتر درباره قالب آدرس‌ها، بخش آدرس‌های شنود (LISTENING ADDRESSES) را در صفحه راهنمای snmpd(8) ببینید.

agentXTimeout NUM

مدت زمان مهلت زمانی (NUM ثانیه) را برای یک درخواست AgentX تعیین می‌کند. پیش‌فرض ۱ ثانیه است. NUM همچنین می‌تواند با پسوند یکی از حروف s (برای ثانیه)، m (برای دقیقه)، h (برای ساعت)، d (برای روز)، یا w (برای هفته) مشخص شود.

agentXRetries NUM

تعداد تلاش‌های مجدد را برای یک درخواست AgentX تعیین می‌کند. پیش‌فرض ۵ بار تلاش مجدد است.

بسته net-snmp به همراه هر دو واسط برنامه‌نویسی C و Perl برای توسعه زیرعامل AgentX سفارشی شما ارائه می‌شود.

جدول‌های داده‌های داخلی (Internal Data tables)

table NAME

add_row NAME INDEX(ES) VALUE(S)