.TH SNMPTRAPD.CONF 5 "13 Mar 2014" V5.9.5.2 "Net-SNMP" .SH "نام (NAME)" snmptrapd.conf \- فایل پیکربندی دیمون دریافت تله‌های SNMP .SH "توضیحات (DESCRIPTION)" گیرنده اعلان Net-SNMP (دیمون دریافت تله) از یک یا چند فایل پیکربندی برای کنترل عملکرد خود و چگونگی پردازش تله‌های ورودی (و درخواست‌های INFORM) استفاده می‌کند. این فایل (\fBsnmptrapd.conf\fR) می‌تواند در یکی از چندین مسیر، به شرح ارائه‌شده در صفحه راهنمای .IR snmp_config (5) قرار گیرد. .SH "مهم (IMPORTANT)" پیش‌تر، .B snmptrapd تمامی اعلان‌های ورودی را می‌پذیرفت و آنها را به صورت خودکار ثبت می‌کرد (حتی اگر هیچ پیکربندی صریحی ارائه نشده بود). از نسخه 5.3 به بعد، بررسی‌های کنترل دسترسی روی اعلان‌های ورودی اعمال خواهد شد. اگر .B snmptrapd بدون یک فایل پیکربندی مناسب (یا تنظیمات معادل کنترل دسترسی) اجرا شود، چنین تله‌هایی پردازش \fBنخواهند شد\fR. برای جزئیات بیشتر بخش \fBکنترل دسترسی (ACCESS CONTROL)\fR را ببینید. .PP مشابه پیکربندی کارگزار، دستورالعمل‌های .I snmptrapd.conf را می‌توان به چهار گروه مجزا تقسیم کرد. .SH "رفتار دیمون تله (TRAPD BEHAVIOUR)" .IP "snmpTrapdAddr [:][,...]" فهرستی از نشانی‌های شنود را برای دریافت اعلان‌های ورودی SNMP تعریف می‌کند. برای اطلاعات بیشتر درباره قالب نشانی‌های شنود، بخش .B LISTENING ADDRESSES را در صفحه راهنمای .IR snmpd (8) ببینید. .IP رفتار پیش‌فرض، شنود روی درگاه UDP شماره 162 در تمام رابط‌های IPv4 است. .IP "doNotRetainNotificationLogs yes" پشتیبانی از NOTIFICATION\-LOG\-MIB را غیرفعال می‌کند. به طور معمول برنامه snmptrapd سوابق تله‌های دریافت‌شده را نگه می‌دارد که می‌توان با پرس‌وجوی جدول‌های \fCnlmLogTable\fR و \fCnlmLogvariableTable\fR آنها را بازیابی کرد. از این دستورالعمل می‌توان برای متوقف کردن این رفتار استفاده کرد. .IP برای جزئیات بیشتر، صفحه راهنمای .IR snmptrapd (8) و سند NOTIFICATION\-LOG\-MIB را ببینید. .IP "doNotLogTraps yes" ثبت وقایع اعلان‌ها را به طور کلی غیرفعال می‌کند. این گزینه زمانی مفید است که برنامه \fBsnmptrapd\fR فقط باید قلاب‌های traphandle را اجرا کند و نباید تله‌ها را در هیچ مکانی ثبت نماید. .IP "doNotFork yes" از شل فراخواننده انشعاب نمی‌گیرد (fork نمی‌کند). .IP "pidFile PATH" فایلی را برای ذخیره شناسه فرایند (PID) گیرنده اعلان تعیین می‌کند. به طور پیش‌فرض، این شناسه ذخیره نمی‌شود. .SH "کنترل دسترسی (ACCESS CONTROL)" از نسخه 5.3 به بعد، لازم است به صراحت مشخص شود چه کسی مجاز به ارسال تله‌ها و informها به گیرنده اعلان است (و این پیام‌ها مجاز به راه‌اندازی چه نوع پردازش‌هایی هستند). این سازوکار از توسعه‌ای در مدل VACM استفاده می‌کند که در کارگزار اصلی SNMP به کار می‌رود. .PP در حال حاضر سه نوع پردازش را می‌توان مشخص کرد: .RS .IP "log" ثبت جزئیات اعلان \- چه در یک فایل مشخص، چه در خروجی استاندارد (یا خطای استاندارد)، یا از طریق \fIsyslog\fR (یا موارد مشابه). .IP "execute" ارسال جزئیات تله به یک برنامه گرداننده مشخص، از جمله پرل توکار (embedded perl). .IP "net" بازارسال (فوروارد) تله به یک گیرنده اعلان دیگر. .RE .PP در دستورالعمل‌های زیر، \fITYPES\fR فهرستی (جداشده با کاما) از یک یا چند مورد از این شناسه‌ها خواهد بود. معمولاً این مقدار به صورت \fIlog,execute,net\fR خواهد بود تا هر نوع پردازشی را برای دسته‌ای خاص از اعلان‌ها پوشش دهد. اما کاملاً امکان‌پذیر (و حتی مطلوب) است که منابع اعلان خاصی تنها به پردازش‌های برگزیده محدود شوند. .IP "authCommunity TYPES COMMUNITY [SOURCE [OID | \-v VIEW ]]" تله‌ها (و درخواست‌های INFORM در SNMPv2c) را با جامعه (community) مشخص‌شده برای راه‌اندازی انواع پردازش‌های فهرست‌شده مجاز می‌کند. به طور پیش‌فرض، این مورد اجازه می‌دهد هر اعلانی که از این جامعه استفاده می‌کند پردازش شود. فیلد SOURCE می‌تواند برای مشخص کردن این به کار رود که پیکربندی فقط برای اعلان‌های دریافت‌شده از منابع خاصی اعمال شود \- برای جزئیات بیشتر صفحه راهنمای .IR snmpd.conf (5) را ببینید. .IP "authUser TYPES [\-s MODEL] USER [LEVEL [OID | \-v VIEW ]]" اعلان‌های SNMPv3 را با کاربر مشخص‌شده برای راه‌اندازی انواع پردازش‌های فهرست‌شده مجاز می‌کند. به طور پیش‌فرض، این گزینه درخواست‌های احرازهویت‌شده (\fIauthNoPriv\fR یا \fIauthPriv\fR) را می‌پذیرد. فیلد LEVEL می‌تواند برای مجاز کردن اعلان‌های احرازهویت‌نشده (\fInoauth\fR)، یا الزام به رمزنگاری (\fIpriv\fR) درست همانند کارگزار SNMP استفاده شود. .IP در هر دوی این دستورالعمل‌ها، فیلد OID (یا \fI\-v VIEW\fR) می‌تواند برای محدود کردن این پیکربندی به پردازش اعلان‌های خاص استفاده شود. .RS .IP "نکته:" برخلاف پردازش VACM که در RFC 3415 توصیف شده است، این نما (view) \fBتنها\fR با مقدار \fCsnmpTrapOID\fR اعلان ورودی مطابقت داده می‌شود و روی پیوندهای متغیر (varbinds) محموله موجود در آن اعلان اعمال نمی‌شود. .RE .IP "authGroup TYPES [\-s MODEL] GROUP [LEVEL [OID | \-v VIEW ]]" .IP "authAccess TYPES [\-s MODEL] GROUP VIEW [LEVEL [CONTEXT]]" .IP "setAccess GROUP CONTEXT MODEL LEVEL PREFIX VIEW TYPES" اعلان‌ها را در گروه (GROUP) مشخص‌شده (پیکربندی‌شده با دستورالعمل \fIgroup\fR) برای راه‌اندازی انواع پردازش‌های فهرست‌شده مجاز می‌کند. برای جزئیات بیشتر صفحه راهنمای .IR snmpd.conf (5) را ببینید. .IP "createUser [-e ENGINEID] username (MD5|SHA|SHA-512|SHA-384|SHA-256|SHA-224) authpassphrase [DES|AES]" برای شرح چگونگی ایجاد کاربران SNMPv3، صفحه راهنمای .IR snmpd.conf (5) را ببینید. این دستورالعمل تقریباً یکسان است، اما نام فایل از snmpd.conf به snmptrapd.conf تغییر می‌کند. .IP "disableAuthorization yes" بررسی‌های کنترل دسترسی بالا را غیرفعال کرده و به رفتار پیشین در پذیرش تمامی اعلان‌های ورودی بازمی‌گردد. .IP .\" XXX - Explain why this is a Bad Idea .\" .SH "ثبت وقایع (LOGGING)" .IP "format1 FORMAT" .IP "format2 FORMAT" به ترتیب قالب مورد استفاده برای نمایش تله‌های SNMPv1 و اعلان‌های SNMPv2 را مشخص می‌کنند. توجه داشته باشید که SNMPv2c و SNMPv3 هر دو از همان قالب SNMPv2 PDU استفاده می‌کنند. .IP "format DESTINATION FORMAT" قالب مورد استفاده برای مقصدهای مختلف را تعیین می‌کند. DESTINATION یکی از موارد زیر است: .IR print ", " print1 ", " print2 ", " .IR syslog ", " syslog1 ", " syslog2 ", " .IR execute ", " execute1 ", " execute2 . مقدار .I print1 برای چاپ تله‌های SNMPv1، و .I print2 برای SNMPv2 استفاده می‌شود. .I print برای هر دو نسخه به کار می‌رود. به همین ترتیب، .I syslog هنگام ارسال تله‌ها به syslog استفاده می‌شود، و .I execute هنگام ارسال تله‌ها به برنامه‌ای مانند .IR traptoemail (1) به کار می‌رود. .IP قالب‌های پیش‌فرض عبارتند از: .br .I format print1 %.4y-%.2m-%.2l %.2h:%.2j:%.2k %B [%b] (via %A [%a]): %N\en\et%W Trap (%q) Uptime: %#T\en%v\en .br .I format print2 %.4y-%.2m-%.2l %.2h:%.2j:%.2k %B [%b]:\en%v\en .br .I format syslog1 %a: %W Trap (%q) Uptime: %#T%#v\en .br .I format syslog2 %B [%b]: Trap %#v\en .br .I format execute %B\en%b\en%V\en%v\en .IP برای نویسه‌های چیدمان موجود، صفحه راهنمای .IR snmptrapd (8) را ببینید. .IP "ignoreAuthFailure yes" به گیرنده دستور می‌دهد تله‌های \fIauthenticationFailure\fR را نادیده بگیرد. .RS .IP "نکته:" این مورد در حال حاضر فقط بر ثبت وقایع چنین اعلان‌هایی تأثیر می‌گذارد. تله‌های \fIauthenticationFailure\fR همچنان به اسکریپت‌های گرداننده تله ارسال می‌شوند و به سایر گیرنده‌های اعلان بازارسال خواهند شد. نباید به این رفتار اتکا کرد، زیرا احتمال دارد در نسخه‌های آینده تغییر کند. .RE .IP "logOption string" مشخص می‌کند که اعلان‌ها کجا باید ثبت شوند \- در خروجی استاندارد، خطای استاندارد، یک فایل مشخص یا از طریق \fIsyslog\fR. برای جزئیات بیشتر بخش LOGGING OPTIONS را در صفحه راهنمای .IR snmpcmd (1) ببینید. .IP "outputOption string" ویژگی‌های گوناگون نحوه نمایش OIDها و سایر مقادیر را تعیین می‌کند. برای جزئیات بیشتر بخش OUTPUT OPTIONS را در صفحه راهنمای .IR snmpcmd (1) ببینید. .SH "ثبت وقایع در MySQL (MySQL Logging)" دو متغیر پیکربندی وجود دارند که همراه با هم زمان ثبت تله‌های در صف را در پایگاه داده MySQL کنترل می‌کنند. برای فعال‌سازی ثبت وقایع در MySQL باید مقداری غیر از صفر برای sqlSaveInterval تعیین شود. .RE .IP "sqlMaxQueue max" حداکثر تعداد تله‌های قرارگیرنده در صف را پیش از تخلیه اجباری به پایگاه داده MySQL مشخص می‌کند. .RE .IP "sqlSaveInterval seconds" تعداد ثانیه‌های بین تخلیه‌های دوره‌ای صف را مشخص می‌کند. مقدار 0 ثبت وقایع در MySQL را غیرفعال خواهد کرد. .SH "پردازش اعلان‌ها (NOTIFICATION PROCESSING)" علاوه بر ثبت اعلان‌های ورودی، می‌توان آنها را به یک گیرنده اعلان دیگر بازارسال کرد یا برای پردازش‌های تخصصی به یک برنامه بیرونی سپرد. .IP "traphandle OID|default PROGRAM [ARGS ...]" هر زمان که اعلانی مطابق با نشانه OID دریافت شود، برنامه مشخص‌شده را (با آرگومان‌های داده‌شده) فراخوانی می‌کند. برای اعلان‌های SNMPv2c و SNMPv3، این نشانه با مقدار \fCsnmpTrapOID\fR استخراج‌شده از اعلان مقایسه خواهد شد. برای تله‌های SNMPv1، مقادیر تله عمومی و اختصاصی و OID سازمانی به OID معادل تبدیل می‌شوند (مطابق RFC 2576). .IP به طور معمول، نشانه OID نام (یا OID عددی) یک شیء NOTIFICATION-TYPE خواهد بود و برنامه مشخص‌شده برای اعلان‌هایی که دقیقاً با این OID مطابقت دارند فراخوانی می‌شود. با این حال این نشانه از شکل ساده‌ای از پسوند نویسه عام نیز پشتیبانی می‌کند. با افزودن نویسه '*' به انتهای نشانه OID، برنامه مربوطه برای هر اعلانی که در زیردرخت با ریشه OID مشخص‌شده قرار دارد فراخوانی می‌شود. به عنوان مثال، نشانه OID به صورت \fC.1.3.6.1.4.1*\fP با هر اعلان اختصاصی سازمانی (از جمله خود OID مشخص‌شده) مطابقت خواهد داشت. یک نشانه OID به صورت \fC.1.3.6.1.4.1.*\fP تقریباً به همان صورت کار می‌کند، اما دقیقاً با این OID مطابقت نخواهد داشت \- تنها با اعلان‌هایی که اکیداً در زیر این ریشه قرار دارند مطابقت دارد. توجه داشته باشید که این نحو از عبارت‌های باقاعده کامل یا نویسه‌های عام پشتیبانی نمی‌کند \- نشانه OID به شکل \fCoid.*.subids\fR معتبر \fBنیست\fC. .IP اگر فیلد OID برابر با نشانه \fIdefault\fR باشد، برنامه برای هر اعلانی که با مدخل دیگر \fItraphandle\fR (که OID خاصی دارد) مطابقت نداشته باشد، فراخوانی می‌شود. .PP جزئیات اعلان از طریق ورودی استاندارد به برنامه داده می‌شود. توجه داشته باشید که این همواره از قالب اعلان سبک SNMPv2 استفاده خواهد کرد و تله‌های SNMPv1 پیش از ارسال به برنامه مطابق با RFC 2576 تبدیل می‌شوند. قالب ورودی، در صورتی که از قالب پیش‌فرض تعیین‌شده توسط "format execute %B\en%b\en%V\en%v\en" استفاده کنید، یک مدخل در هر خط است: .RS .IP HOSTNAME نام میزبانی که اعلان را ارسال کرده است، آن‌طور که توسط .IR gethostbyaddr (3) تعیین شده است. .br .IP ADDRESS نشانی انتقال، مانند: .br "[UDP: [172.16.10.12]:23456->[10.150.0.8]]" .\" .\" XXX - What about non-IPv4 transports? .\" .IP VARBINDS فهرستی از پیوندهای متغیر (variable bindings) که محتوای اعلان را توصیف می‌کنند، یک مورد در هر خط. اولین نشانه در هر خط (تا فاصله) OID پیوند متغیر است و باقی خط مقدار آن می‌باشد. قالب هر دوی این‌ها توسط دستورالعمل \fIoutputOption\fR (یا پیکربندی مشابه) کنترل می‌شود. .IP اولین OID همیشه باید \fCSNMPv2\-MIB::sysUpTime.0\fR، و دومی باید \fCSNMPv2\-MIB::snmpTrapOID.0\fR باشد. خطوط باقی‌مانده شامل فهرست پیوندهای متغیر محموله خواهد بود. برای تله‌های SNMPv1، آخرین OID برابر با \fCSNMPv2\-MIB::snmpTrapEnterprise.0\fR خواهد بود. .br .IP "مثال:" یک اسکریپت \fBtraptoemail\fR در بسته Net-SNMP گنجانده شده است که می‌تواند درون یک دستورالعمل \fItraphandle\fR استفاده شود: .br .RS .P traphandle default /usr/bin/perl /usr/bin/traptoemail \-s mysmtp.somewhere.com \-f admin@somewhere.com me@somewhere.com .RE .RE .IP "forward OID|default DESTINATION" اعلان‌هایی را که با OID مشخص‌شده مطابقت دارند به گیرنده دیگری که در DESTINATION شنود می‌کند فوروارد (بازارسال) می‌کند. تفسیر OID (و \fIdefault\fR) مشابه دستورالعمل \fItraphandle\fR است. .IP برای اطلاعات بیشتر درباره قالب نشانی‌های شنود، بخش .B LISTENING ADDRESSES را در صفحه راهنمای .IR snmpd (8) ببینید. .RE .P addForwarderInfo 1|yes|true|0|no|false .IP هر بار که تله‌ای بازارسال می‌شود، یک OID با نشانی IP سیستمی که تله از آن دریافت شده است اضافه می‌کند. OID زیر اضافه می‌شود: \&.1.3.6.1.6.3.18.1.3.x (SNMP-COMMUNITY-MIB::snmpTrapAddress.x) که در آن x کمترین نمایه‌ای (index >= 0) است که هنوز در محموله تله وجود ندارد. گیرنده نهایی (یعنی سامانه پایش) می‌تواند با بررسی پیوند متغیر با OID snmpTrapAddress.0، نشانی IPv4 فرستنده اصلی را مشخص کند. اگر آن OID مقداردهی نشده باشد، به این معنی است که تله مستقیماً ارسال شده یا به بیان دیگر بازارسال نشده است. .SH "نکات (NOTES)" .IP o دیمون در هنگام اجرای دستورات \fItraphandle\fR متوقف (مسدود) می‌شود. (این مشکل باید در آینده با ترکیب مناسبی از دریافت سیگنال و wait() برطرف شود). .IP o تمام دستورالعمل‌های فهرست‌شده با مقدار "yes" در واقع دامنه‌ای از مقادیر بولی (boolean) را می‌پذیرند. این موارد هر یک از مقادیر \fI1\fR، \fIyes\fR یا \fItrue\fR را برای فعال‌سازی رفتار مربوطه، یا هر یک از مقادیر \fI0\fR، \fIno\fR یا \fIfalse\fR را برای غیرفعال‌سازی آن می‌پذیرند. حالت پیش‌فرض در هر مورد، غیرفعال بودن قابلیت است؛ بنابراین این دستورالعمل‌ها معمولاً تنها برای فعال‌سازی رفتار مربوطه استفاده می‌شوند. .SH "فایل‌ها (FILES)" /etc/snmp/snmptrapd.conf .SH "همچنین ببینید (SEE ALSO)" snmp_config(5), snmptrapd(8), syslog(8), traptoemail(1), variables(5), netsnmp_config_api(3).