SNMPD.EXAMPLES(5) Net-SNMP SNMPD.EXAMPLES(5) نام (NAME) snmpd.examples - پیکربندی‌های نمونه برای کارگزار Net-SNMP توضیحات (DESCRIPTION) صفحه راهنمای snmpd.conf(5) نحو و رفتار دستورالعمل‌های پیکربندی مختلفی را تعریف می‌کند که می‌توانند برای کنترل عملکرد کارگزار Net-SNMP و اطلاعات مدیریتی ارائه‌شده توسط آن استفاده شوند. این صفحه راهنمای مکمل، این دستورالعمل‌ها را شرح داده و نمونه‌های کاربردی از نحوه استفاده از آن‌ها را نمایش می‌دهد. رفتار کارگزار (AGENT BEHAVIOUR) نشانی‌های شنود (Listening addresses) رفتار پیش‌فرض کارگزار (شنود روی درگاه استاندارد SNMP UDP در تمام واسط‌ها) معادل دستورالعمل زیر است: agentaddress udp:161 یا به سادگی: agentaddress 161 کارگزار را می‌توان به‌گونه‌ای پیکربندی کرد که تنها درخواست‌های ارسال‌شده به واسط محلی loopback را بپذیرد (مجدداً با شنود روی درگاه SNMP UDP)، با استفاده از: agentaddress localhost:161 # (udp implicit) یا: agentaddress 127.0.0.1 # (udp and standard port implicit) می‌توان آن را طوری پیکربندی کرد که هر دو درخواست UDP و TCP را (روی هر دو پروتکل IPv4 و IPv6) بپذیرد، با استفاده از: agentaddress udp:161,tcp:161,udp6:161,tcp6:161 سایر ترکیب‌ها نیز معتبر هستند. امتیازات زمان اجرا (Run-time privileges) کارگزار را می‌توان به‌گونه‌ای پیکربندی کرد که پس از باز کردن درگاه‌های شنود اولیه، هرگونه دسترسی ممتاز (ریشه) خود را رها کند. با در نظر گرفتن یک گروه مناسب "snmp" (تعریف‌شده در /etc/group)، این کار را می‌توان با استفاده از دستورالعمل‌های زیر انجام داد: agentuser nobody agentgroup snmp نتیجه‌ای مشابه را می‌توان با استفاده از مقادیر عددی UID و/یا GID به دست آورد: agentuser #10 agentgroup #10 پیکربندی SNMPv3 (SNMPv3 Configuration) شناسه موتور (engine ID) برای کارگزار به جای این‌که به صورت شبه‌تصادفی تولید شود، می‌تواند بر اساس آدرس MAC واسط شبکه دوم (eth1) با استفاده از دستورالعمل‌های زیر محاسبه شود: engineIDType 3 engineIDNic eth1 یا می‌تواند از روی (اولین) آدرس IP محاسبه شود، با استفاده از: engineIDType 1 یا می‌توان آن را به صراحت مشخص کرد، با استفاده از: engineID "XXX - WHAT FORMAT" کنترل دسترسی (ACCESS CONTROL) کاربران SNMPv3 (SNMPv3 Users) دستورالعمل‌های زیر سه کاربر ایجاد می‌کنند که همگی دقیقاً از تنظیمات احراز هویت و رمزنگاری یکسانی استفاده می‌کنند: createUser me MD5 "single pass phrase" createUser myself MD5 "single pass phrase" DES createUser andI MD5 "single pass phrase" DES "single pass phrase" توجه داشته باشید که این سه کاربر متمایز را تعریف می‌کند که می‌توان به آن‌ها سطوح دسترسی متفاوتی اعطا کرد. تغییر عبارت عبور برای هر یک از آن‌ها تأثیری بر دو کاربر دیگر نخواهد گذاشت. می‌توان عبارت‌های عبور جداگانه‌ای را برای احراز هویت و رمزنگاری مشخص کرد: createUser onering SHA "to rule them all" AES "to bind them" به یاد داشته باشید که این دستورالعمل‌های createUser باید در فایل /var/net-snmp/snmpd.conf تعریف شوند، نه در مکان معمول. کنترل دسترسی سنتی (Traditional Access Control) به کاربران SNMPv3 تعریف‌شده در بالا می‌توان دسترسی به کل درخت MIB را با استفاده از دستورالعمل‌های زیر اعطا کرد: rouser me rwuser onering یا دسترسی انتخابی به زیردرخت‌های مجزا با استفاده از: rouser myself .1.3.6.1.2 rwuser andI system توجه داشته باشید که ترکیبی که یک کاربر یکسان را تکرار می‌کند، مانند: rouser onering rwuser onering نباید استفاده شود. این کار کاربر onering را با دسترسی فقط-خواندنی پیکربندی می‌کند (و مدخل rwuser را به‌طور کلی نادیده می‌گیرد). همین امر برای دستورالعمل‌های مبتنی بر کامیونیتی (community) نیز صادق است. دستورالعمل‌های: rocommunity public rwcommunity private رشته‌های کامیونیتی خواندن و نوشتن رایج را برای درخواست‌های SNMPv1 و SNMPv2c تعریف می‌کنند. این رفتار به‌طور پیش‌فرض پیکربندی نشده است و باید به‌طور صریح تنظیم شود. نکته: همچنین ایده بسیار خوبی است که private را به چیزی با قابلیت پیش‌بینی کمتر تغییر دهید! یک پیکربندی با آسیب‌پذیری کمی کمتر ممکن است اطلاعات قابل بازیابی را محدود کند: rocommunity public default system یا سیستم‌های مدیریتی را که تنظیمات می‌توانند از آن‌ها دستکاری شوند محدود نماید: rwcommunity private 10.10.10.0/24 یا ترکیبی از هر دو. پیکربندی VACM (VACM Configuration) این جفت تنظیمات آخر معادل تعاریف کامل VACM هستند: # sec.name source community com2sec public default public com2sec mynet 10.10.10.0/24 private com2sec6 mynet fec0::/64 private # sec.model sec.name group worldGroup v1 public group worldGroup v2c public group myGroup v1 mynet group myGroup v2c mynet # incl/excl subtree [mask] view all included .1 view sysView included system # context model level prefix read write notify (unused) access worldGroup "" any noauth exact system none none access myGroup "" any noauth exact all all none چندین نکته در این مثال قابل توجه است: دستورالعمل‌های group باید برای هر دو درخواست SNMPv1 و SNMPv2c تکرار شوند. نام امنیتی com2sec متمایز از رشته کامیونیتی است که به آن نگاشت شده است. آن‌ها می‌توانند یکسان ("public") یا متفاوت ("mynet"/"private") باشند - اما آنچه در دستورالعمل group ظاهر می‌شود نام امنیتی است، بدون در نظر گرفتن رشته کامیونیتی اصلی. هر دو دستورالعمل view زیردرخت‌های ساده OID را تعریف می‌کنند، بنابراین هیچ‌کدام نیازی به ماسک صریح ندارند. همین امر برای نمای "زیردرخت ترکیبی" تعریف‌شده در زیر نیز صادق است. در واقع، یک فیلد ماسک تنها هنگام تعریف برش‌های سطری در یک جدول (یا نماهای مشابه) مورد نیاز است و تقریباً همیشه می‌توان آن را حذف کرد. به‌طور کلی، توصیه می‌شود تنظیمات پیکربندی دسترسی سنتی و مبتنی بر VACM را ترکیب نکنید، زیرا این تنظیمات گاهی اوقات می‌توانند به روش‌های غیرمنتظره‌ای با یکدیگر تداخل داشته باشند. یک سبک خاص از پیکربندی دسترسی را انتخاب کرده و به آن پایبند باشید. پیکربندی نمای نوع‌دار (Typed-View Configuration) پیکربندی مشابهی را می‌توان به صورت زیر نیز انجام داد: view sys2View included system view sys2View included .1.3.6.1.2.1.25.1 authcommunity read public default -v sys2View authcommunity read,write private 10.10.10.0/8 این سازوکار اجازه می‌دهد تا نماهای چند زیردرختی (یا سایر نماهای غیرساده) با سبک پیکربندی یک‌خطی rocommunity استفاده شوند. همچنین در صورت نیاز، از پیکربندی دسترسی "فقط-نوشتنی" نیز پشتیبانی می‌کند. اطلاعات سیستم (SYSTEM INFORMATION) گروه سیستم (System Group) محتوای کامل گروه 'system' (به استثنای sysUpTime) را می‌توان به‌طور صریح با استفاده از دستورات زیر پیکربندی کرد: # بازنویسی 'uname -a' و OID سیستم تعبیه‌شده - مقادیر ذاتاً فقط-خواندنی sysDescr Universal Turing Machine mk I sysObjectID .1.3.6.1.4.1.8072.3.2.1066 # بازنویسی مقادیر پیش‌فرض از 'configure' - این اشیا را فقط-خواندنی می‌کند sysContact Alan.Turing@pre-cs.man.ac.uk sysName tortoise.turing.com sysLocation An idea in the mind of AT # رفتار استاندارد میزبان نهایی (end-host) sysServices 72 گروه منابع میزبان (Host Resources Group) فهرست دستگاه‌های بررسی‌شده برای گنجاندن احتمالی در hrDiskStorageTable (و hrDeviceTable) را می‌توان با استفاده از هر یک از دستورالعمل‌های زیر اصلاح کرد: ignoredisk /dev/rdsk/c0t2d0 که از پویش دستگاه /dev/rdsk/c0t2d0 جلوگیری می‌کند، ignoredisk /dev/rdsk/c0t[!6]d0 ignoredisk /dev/rdsk/c0t[0-57-9a-f]d0 که هر کدام از پویش تمام دستگاه‌های /dev/rdsk/c0tXd0 (به جز .../c0t6d0) جلوگیری می‌کنند، ignoredisk /dev/rdsk/c1* که از پویش تمام دستگاه‌هایی که نام آن‌ها با /dev/rdsk/c1 شروع می‌شود جلوگیری می‌کند، یا ignoredisk /dev/rdsk/c?t0d0 که از پویش تمام دستگاه‌های /dev/rdsk/cXt0d0 (که در آن 'X' هر تک‌نویسه‌ای است) جلوگیری می‌کند. پایش فرایندها (Process Monitoring) فهرست سرویس‌های در حال اجرا روی یک سیستم را می‌توان پایش کرد (و تمهیداتی برای اصلاح هرگونه مشکل فراهم نمود)، با استفاده از: # حداقل یک فرایند وب‌سرور باید همیشه در حال اجرا باشد proc httpd procfix httpd /etc/rc.d/init.d/httpd restart # هرگز نباید بیش از ۱۰ فرایند ایمیل در حال اجرا باشد # (تعداد بیشتر نشان‌دهنده طوفان احتمالی ایمیل است، بنابراین سیستم ایمیل را خاموش کنید) proc sendmail 10 procfix sendmail /etc/rc.d/init.d/sendmail stop # باید یک کارگزار مدیریت شبکه منفرد در حال اجرا باشد # ("فقط یکی می‌تواند وجود داشته باشد") proc snmpd 1 1 همچنین بخش "پایگاه داده رخداد DisMan" را در ادامه ببینید. پایش مصرف دیسک (Disk Usage Monitoring) وضعیت فضای ذخیره‌سازی دیسک را می‌توان با استفاده از موارد زیر پایش کرد: includeAllDisks 10% disk /var 20% disk /usr 3% # نگهداری ۱۰۰ مگابایت فضای خالی برای crash dumpها disk /mnt/crash 100000 پایش بار سیستم (System Load Monitoring) یک بررسی ساده برای سیستمی با بار کاری بیش از حد می‌تواند چنین باشد: load 10 یک بررسی دقیق‌تر (برای مجاز دانستن دوره‌های کوتاه استفاده سنگین، اما تشخیص بار مداوم متوسط تا سنگین) می‌تواند چنین باشد: load 30 10 5 پایش فایل‌های گزارش (Log File Monitoring) TODO file FILE [MAXSIZE] logmatch NAME PATH CYCLETIME REGEX پایش فعال (ACTIVE MONITORING) مدیریت اعلان‌ها (Notification Handling) پیکربندی کارگزار برای گزارش تلاش‌های نامعتبر برای دسترسی را می‌توان به صورت زیر انجام داد: authtrapenable 1 trapcommunity public trap2sink localhost به‌عنوان روش جایگزین، دستورالعمل‌های دوم و سوم را می‌توان ترکیب کرد (و درخواست تایید دریافت اعلان نمود) با استفاده از: informsink localhost public پیکربندی با مقصدهای تکراری گیرنده اعلان، مانند: trapsink localhost trap2sink localhost informsink localhost نباید استفاده شود، زیرا باعث می‌شود چندین نسخه از هر تله (trap) به یک گیرنده تله یکسان ارسال شود. TODO - discuss SNMPv3 traps trapsess snmpv3 options localhost:162 TODO - mention trapd access configuration پایگاه داده رخداد DisMan (DisMan Event MIB) ساده‌ترین پیکربندی برای خودپایشی فعال کارگزار، توسط کارگزار، برای کارگزار، احتمالاً چنین است: # تنظیم اطلاعات کاربری برای بازیابی مقادیر پایش‌شده createUser _internal MD5 "the first sign of madness" iquerySecName _internal rouser _internal # فعال‌سازی مدخل‌های پایش استاندارد defaultMonitors yes linkUpDownNotifications yes # اگر مشکلی وجود دارد، به کسی اطلاع بده! trap2sink localhost بلوک اول یک کاربر مناسب را برای بازیابی اطلاعاتی که باید پایش شوند تنظیم می‌کند، در حالی که جفت دستورالعمل‌های بعدی، مدخل‌های مختلف پایش توکار را فعال می‌کنند. توجه داشته باشید که دستورالعمل‌های DisMan به خودی خود برای گزارش فعالانه مشکلات کافی نیستند - همچنین باید یک مقصد مناسب پیکربندی شده باشد تا اعلان‌های حاصل عملاً به آن ارسال شوند. یک مثال مانیتور دقیق‌تر در زیر آورده شده است: monitor -u me -o hrSWRunName "high process memory" hrSWRunPerfMem > 10000 این یک مدخل مانیتور بولی صریح را تعریف می‌کند که به دنبال هر فرایندی است که بیش از ۱۰ مگابایت حافظه فعال استفاده می‌کند. چنین فرایندهایی با استفاده از تله استاندارد DisMan به نام mteTriggerFired گزارش می‌شوند، اما یک varbind اضافی hrSWRunName (با نویسه عمومی) نیز افزوده می‌شود. این مدخل همچنین یک کاربر صریح (me، همان‌طور که قبلاً تعریف شد) را برای بازیابی مقادیر پایش‌شده و ساخت تله مشخص می‌کند. اشیاء یا مقادیری که می‌توانند در حوالی سطح مشخص‌شده نوسان داشته باشند، بهتر است با استفاده از یک مدخل پایش آستانه پایش شوند: monitor -D -r 10 "network traffic" ifInOctets 1000000 5000000 این دستور هر زمان که ترافیک ورودی روی هر واسط شبکه از (تقریباً) ۵۰۰ کیلوبایت بر ثانیه بالاتر برود یک تله mteTriggerRising ارسال می‌کند، و هنگامی که دوباره به زیر ۱۰۰ کیلوبایت بر ثانیه کاهش یابد یک تله متناظر mteTriggerFalling ارسال می‌کند. توجه داشته باشید که این دستور تفاوت‌های بین نمونه‌های متوالی (-D) را پایش می‌کند، نه مقادیر واقعی خود نمونه‌ها را. همین اثر را می‌توان با استفاده از دستور زیر به دست آورد: monitor -r 10 "network traffic" ifInOctets - - 1000000 5000000 دستورالعمل linkUpDownNotifications بالا به‌طور کلی معادل موارد زیر است: 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 این بخش تله‌هایی را که باید ارسال شوند (با استفاده از notificationEvent) تعریف می‌کند و به‌طور صریح به اعلان مربوطه در مدخل مانیتور متناظر ارجاع می‌دهد (به جای استفاده از تله‌های پیش‌فرض DisMan). دستورالعمل defaultMonitors بالا معادل مجموعه‌ای از مدخل‌های مانیتور (بولی) است: monitor -o prNames -o prErrMessage "procTable" 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 و هر زمان که هر یک از این مدخل‌ها نشان‌دهنده یک مشکل باشند، یک تله ارسال خواهد کرد. یک رویکرد جایگزین این است که اقدام "اصلاح" (fix) متناظر به‌طور خودکار فراخوانی شود: setEvent prFixIt prErrFix = 1 monitor -e prFixIt "procTable" prErrorFlag != 0 (و به همین ترتیب برای هر یک از مدخل‌های دیگر defaultMonitor). پایگاه داده زمان‌بندی DisMan (DisMan Schedule MIB) کارگزار را می‌توان به‌گونه‌ای پیکربندی کرد که پیکربندی خود را هر یک ساعت یک بار بازخوانی کند، با استفاده از: repeat 3600 versionUpdateConfig.0 = 1 به‌عنوان روش جایگزین، این را می‌توان برای اجرا در زمان‌های خاصی از روز پیکربندی کرد (شاید پس از چرخش گزارش‌ها): cron 10 0 * * * versionUpdateConfig.0 = 1 سبک زمان‌بندی یک‌باره بسیار کمتر رایج است، اما ویروس مخفی SNMP را می‌توان در رخداد بعدی جمعه سیزدهم فعال کرد با استفاده از: at 13 13 13 * 5 snmpVirus.0 = 1 گسترش قابلیت‌های کارگزار (EXTENDING AGENT FUNCTIONALITY) دستورات گسترش دلخواه (Arbitrary Extension Commands) سبک قدیمی exec [MIBOID] NAME PROG ARGS" sh [MIBOID] NAME PROG ARGS" execfix NAME PROG ARGS" سبک جدید extend [MIBOID] NAME PROG ARGS" extendfix [MIBOID] NAME PROG ARGS" دستورات گسترش مختص MIB (MIB-Specific Extension Commands) یک‌باره (One-Shot) "pass [-p priority] MIBOID PROG" مانا (Persistent) "pass_persist [-p priority] MIBOID PROG" پشتیبانی از پرل تعبیه‌شده (Embedded Perl Support) اگر پشتیبانی از پرل تعبیه‌شده در کارگزار فعال باشد، مقداردهی اولیه پیش‌فرض معادل دستورالعمل‌های زیر است: disablePerl false perlInitFile /usr/share/snmp/snmp_perl.pl سازوکار اصلی برای تعریف اسکریپت‌های پرل تعبیه‌شده، دستورالعمل perl است. یک گرداننده بسیار ساده (هرچند تا حدی بی‌هدف) MIB را می‌توان با استفاده از موارد زیر ثبت کرد: perl use Data::Dumper; perl sub myroutine { print "got called: ",Dumper(@_),"\n"; } perl $agent->register('mylink', '.1.3.6.1.8765', \&myroutine); این به شیء $agent متکی است که در فایل نمونه snmp_perl.pl تعریف شده است. یک گرداننده MIB واقعی‌تر ممکن است چنین باشد: XXX - WHAT ??? به‌عنوان روش جایگزین، این کد می‌تواند در یک فایل خارجی ذخیره شده و با استفاده از دستور زیر بارگذاری شود: perl 'do /usr/share/snmp/perl_example.pl'; ماژول‌های با بارگذاری پویا (Dynamically Loadable Modules) TODO dlmod NAME PATH" پشتیبانی از پروکسی (Proxy Support) یک پیکربندی برای عمل کردن به عنوان یک پروکسی ساده برای دو کارگزار SNMP دیگر (در حال اجرا روی سیستم‌های دوردست) ممکن است چنین باشد: com2sec -Cn rem1context rem1user default remotehost1 com2sec -Cn rem2context rem2user default remotehost2 proxy -Cn rem1context -v 1 -c public remotehost1 .1.3 proxy -Cn rem2context -v 1 -c public remotehost2 .1.3 (به همراه مدخل‌های کنترل دسترسی مناسب). همین دستورالعمل‌های proxy برای درخواست‌های (ورودی) SNMPv3 نیز کار می‌کنند، که می‌توانند مستقیماً یک بافتار (context) را مشخص کنند. احتمالاً منطقی‌تر خواهد بود که از بافتارهای remotehost1 و remotehost2 استفاده شود - نام‌های بالا برای نشان دادن نحوه کارکرد این دستورالعمل‌ها با یکدیگر انتخاب شده‌اند. توجه داشته باشید که تنظیمات مدیریتی برای درخواست پروکسی‌شده به‌طور صریح مشخص می‌شوند و مستقل از تنظیمات درخواست ورودی هستند. کاربرد دیگر دستورالعمل proxy ارسال بخشی از درخت OID به کارگزار دیگر است (خواه روی یک میزبان دوردست یا در حال شنود روی درگاهی متفاوت در همان سیستم)، در حالی که بقیه موارد را به‌طور داخلی مدیریت می‌کند: proxy -v 1 -c public localhost:6161 .1.3.6.1.4.1.99 از این سازوکار می‌توان برای پیوند دادن دو کارگزار SNMP جداگانه به یکدیگر استفاده کرد. یک رویکرد کمتر معمول، نگاشت یک زیردرخت به ناحیه متفاوتی از درخت کلی MIB است (خواه به صورت محلی یا روی یک سیستم دوردست): # uses SNMPv3 to access the MIB tree .1.3.6.1.2.1.1 on 'remotehost' # and maps this to the local tree .1.3.6.1.3.10 proxy -v 3 -l noAuthNoPriv -u user remotehost .1.3.6.1.3.10 .1.3.6.1.2.1.1 زیرکارگزارهای SMUX (SMUX Sub-Agents) smuxsocket 127.0.0.1 smuxpeer .1.3.6.1.2.1.14 ospf_pass زیرکارگزارهای AgentX (AgentX Sub-Agents) کارگزار Net-SNMP را می‌توان به‌گونه‌ای پیکربندی کرد که به عنوان یک کارگزار اصلی AgentX عمل کند (با شنود روی یک سوکت نام‌گذاری‌شده غیراستاندارد، و اجرا با استفاده از امتیازات دسترسی تعریف‌شده در قبل)، با استفاده از: master agentx agentXSocket /tmp/agentx/master agentXPerms 0660 0550 nobody snmp یک زیرکارگزار که مایل به اتصال به این کارگزار اصلی است، به همان دستورالعمل agentXSocket یا کد معادل آن نیاز دارد: netsnmp_ds_set_string(NETSNMP_DS_APPLICATION_ID, NETSNMP_DS_AGENT_X_SOCKET, "/tmp/agentx/master"); پیکربندی AgentX تحت شبکه loopback را می‌توان با استفاده از موارد زیر تنظیم کرد: agentXSocket tcp:localhost:705 agentXTimeout 5 agentXRetries 2 روی سمت اصلی (master)، و: agentXSocket tcp:localhost:705 agentXTimeout 10 agentXRetries 1 agentXPingInterval 600 روی کلاینت. توجه داشته باشید که تنظیمات مهلت زمانی (timeout) و تلاش مجدد (retry) می‌توانند برای دو جهت نامتقارن باشند، و زیرکارگزار می‌تواند کارگزار اصلی را در فواصل منظم (۶۰۰ ثانیه = هر ۱۰ دقیقه) بررسی کند تا از برقراری اتصال اطمینان حاصل نماید. سایر پیکربندی‌ها (OTHER CONFIGURATION) override sysDescr.0 octet_str "my own sysDescr" injectHandler stash_cache NAME table_iterator فایل‌ها (FILES) /etc/snmp/snmpd.conf همچنین ببینید (SEE ALSO) snmpconf(1), snmpd.conf(5), snmp.conf(5), snmp_config(5), snmpd(8), EXAMPLE.conf, netsnmp_config_api(3). V5.9.5.2 13 Oct 2006 SNMPD.EXAMPLES(5)