dhcpd(8) System Manager's Manual dhcpd(8)

dhcpd - دیمون پروتکل پیکربندی پویای میزبان (DHCP)

dhcpd [ -p port ] [ -f ] [ -d ] [ -q ] [ -t | -T ] [ -4 | -6 ] [ -4o6 port ] [ -s server ] [ -cf config-file ] [ -lf lease-file ] [ -pf pid-file ] [ --no-pid ] [ -user user ] [ -group group ] [ -chroot dir ] [ -tf trace-output-file ] [ -play trace-playback-file ] [ if0 [ ...ifN ] ]

dhcpd --version

سرور DHCP کنسرسیوم سامانه‌های اینترنتی (ISC)، یعنی dhcpd، «پروتکل پیکربندی پویای میزبان» (DHCP) و «پروتکل راه‌اندازی اینترنتی» (BOOTP) را پیاده‌سازی می‌کند. پروتکل DHCP به میزبان‌های موجود در یک شبکه TCP/IP امکان می‌دهد تا درخواست دریافت آدرس‌های IP داده و آدرس به آن‌ها اختصاص یابد، و همچنین اطلاعاتی را درباره شبکه‌ای که به آن متصل هستند کشف کنند. پروتکل BOOTP عملکردهای مشابهی را با محدودیت‌های مشخصی ارائه می‌دهد.

پروتکل DHCP به میزبان ناشناخته برای مدیر شبکه اجازه می‌دهد تا به صورت خودکار یک آدرس IP جدید از استخر (pool) آدرس‌های IP مربوط به شبکه‌اش دریافت کند. برای این که این سازوکار کار کند، مدیر شبکه استخرهای آدرس را در هر زیرشبکه تخصیص داده و آن‌ها را در فایل dhcpd.conf(5) وارد می‌کند.

دو نسخه از پروتکل DHCP وجود دارد: DHCPv4 و DHCPv6. هنگام راه‌اندازی، سرور ممکن است برای یکی از این دو با استفاده از آرگومان‌های -4 یا -6 اجرا شود.

هنگام راه‌اندازی، dhcpd فایل dhcpd.conf را می‌خواند و فهرستی از آدرس‌های دردسترس در هر زیرشبکه را در حافظه ذخیره می‌کند. هنگامی که یک کلاینت با استفاده از پروتکل DHCP درخواستی برای آدرس ارسال می‌کند، dhcpd یک آدرس را به آن اختصاص می‌دهد. به هر کلاینت یک اجاره (lease) اختصاص داده می‌شود که پس از مدت‌زمانی تعیین‌شده توسط مدیر شبکه (به‌طور پیش‌فرض، یک روز) منقضی می‌شود. پیش از انقضای اجاره‌ها، انتظار می‌رود کلاینت‌هایی که اجاره به آن‌ها تخصیص یافته است، برای ادامه استفاده از آدرس‌ها آن‌ها را تمدید کنند. پس از انقضای یک اجاره، کلاینتی که آن اجاره به آن اختصاص یافته بود دیگر مجاز به استفاده از آدرس IP اجاره‌شده نیست.

برای پیگیری اجاره‌ها پس از راه‌اندازی مجدد سیستم یا راه‌اندازی مجدد سرور، dhcpd فهرستی از اجاره‌های اختصاص‌داده‌شده را در فایل dhcpd.leases(5) نگهداری می‌کند. پیش از این که dhcpd اجاره‌ای را به میزبانی اعطا کند، آن را در این فایل ثبت کرده و اطمینان حاصل می‌کند که محتویات فایل روی دیسک تخلیه (flush) شده است. این امر تضمین می‌کند که حتی در صورت خرابی سیستم (crash)، dhcpd اجاره‌ای را که اختصاص داده است فراموش نکند. هنگام راه‌اندازی، پس از خواندن فایل dhcpd.conf، برنامه dhcpd فایل dhcpd.leases را می‌خواند تا حافظه خود را در مورد اجاره‌های تخصیص‌یافته تازه‌سازی کند.

اجاره‌های جدید به انتهای فایل dhcpd.leases اضافه می‌شوند. به منظور جلوگیری از بزرگ شدن بی‌رویه فایل، گاه‌به‌گاه dhcpd یک فایل dhcpd.leases جدید از پایگاه داده اجاره‌های موجود در حافظه (in-core) ایجاد می‌کند. پس از نوشته شدن این فایل روی دیسک، فایل قدیمی به dhcpd.leases~ تغییر نام می‌دهد و فایل جدید به dhcpd.leases تغییر نام می‌یابد. اگر سیستم در میانه این فرآیند دچار خرابی شود، هر کدام از فایل‌های dhcpd.leases که باقی بماند حاوی تمام اطلاعات اجاره خواهد بود؛ بنابراین نیازی به فرآیند بازیابی پس از خرابی خاصی نیست.

پشتیبانی از BOOTP نیز توسط این سرور ارائه می‌شود. برخلاف DHCP، پروتکل BOOTP پروتکلی برای پس‌گرفتن آدرس‌های تخصیص‌یافته به صورت پویا در زمانی که دیگر نیازی به آن‌ها نیست ارائه نمی‌دهد. هنوز هم امکان تخصیص پویای آدرس‌ها به کلاینت‌های BOOTP وجود دارد، اما به فرآیندی مدیریتی برای بازپس‌گیری آدرس‌ها نیاز است. به‌طور پیش‌فرض، اجاره‌ها به کلاینت‌های BOOTP به صورت نامحدود و دائمی اعطا می‌شوند، اگرچه مدیر شبکه در صورت تمایل می‌تواند تاریخ انقضای زودهنگام‌تر یا طول اجاره کوتاه‌تری را برای اجاره‌های BOOTP تنظیم کند.

همچنین می‌توان به کلاینت‌های BOOTP به روش استاندارد و قدیمی سرویس داد؛ به این صورت که برای هر کلاینت BOOTP به سادگی تعریفی در فایل dhcpd.conf ارائه شود و آدرسی به صورت دائمی به هر کلاینت اختصاص یابد.

هر زمان که تغییراتی در فایل dhcpd.conf ایجاد شود، dhcpd باید مجدداً راه‌اندازی شود. برای راه‌اندازی مجدد dhcpd، یک سیگنال SIGTERM (سیگنال ۱۵) به شناسه فرآیند (PID) موجود در RUNDIR/dhcpd.pid ارسال کرده و سپس dhcpd را مجدداً اجرا کنید. از آنجا که پایگاه داده سرور DHCP مانند پایگاه داده BOOTP سبک نیست، dhcpd با مشاهده تغییر در فایل dhcpd.conf به‌طور خودکار خودش را مجدداً راه‌اندازی نمی‌کند.

نکته: ما شکایت‌های زیادی در این مورد دریافت می‌کنیم. می‌دانیم که بسیار خوب می‌شد اگر می‌توانستیم با ارسال یک SIGHUP به سرور، پایگاه داده را بازخوانی کنیم. این کار از نظر فنی غیرممکن نیست، اما نیازمند حجم کار بسیار زیادی است، منابع ما بسیار محدود هستند و بهتر است در جای دیگری صرف شوند. بنابراین لطفاً در این رابطه در فهرست پستی (mailing list) شکایت نکنید، مگر این که حاضر باشید بودجه پروژه‌ای را برای پیاده‌سازی این قابلیت تأمین کنید، یا خودتان اقدام به انجام آن نمایید.

نام رابط‌های شبکه‌ای که dhcpd باید روی آن‌ها برای دریافت برودکست‌ها گوش فرا دهد، می‌تواند در خط فرمان مشخص شود. این کار باید در سیستم‌هایی انجام شود که در آن‌ها dhcpd قادر به شناسایی رابط‌های بدون قابلیت برودکست نیست، اما در سیستم‌های دیگر نباید نیازی به این کار باشد. اگر نام هیچ رابطی در خط فرمان مشخص نشود، dhcpd تمام رابط‌های شبکه‌ای را که فعال (up) هستند شناسایی کرده، در صورت امکان رابط‌های غیربرودکست را حذف نموده و روی هر رابط برای برودکست‌های DHCP گوش فرا می‌دهد.

-4
اجرا به عنوان سرور DHCP. این حالت پیش‌فرض است و نمی‌تواند با -6 ترکیب شود.
-6
اجرا به عنوان سرور DHCPv6. این گزینه نمی‌تواند با -4 ترکیب شود.
-4o6 port
مشارکت در پروتکل DHCPv4 over DHCPv6 مشخص‌شده در RFC 7341. این گزینه یک سرور DHCPv4 و یک سرور DHCPv6 را به یکدیگر پیوند می‌دهد تا به سرور v4 امکان دریافت درخواست‌های v4 را که درون بسته v6 کپسوله‌سازی شده‌اند بدهد. ارتباط میان دو سرور روی یک جفت سوکت UDP متصل به ::1 port و port + 1 انجام می‌شود. هر دو سرور باید با همان آرگومان port یکسان اجرا شوند.
شماره پورت UDP که dhcpd باید روی آن گوش فرا دهد. در صورت عدم تعیین، dhcpd از پورت پیش‌فرض ۶۷ استفاده می‌کند. این گزینه بیشتر برای اهداف اشکال‌زدایی مفید است.
تعیین آدرس یا نام میزبانی که dhcpd باید به جای آدرس برودکست (255.255.255.255) پاسخ‌ها را به آن ارسال کند. این گزینه فقط در IPv4 پشتیبانی می‌شود.
اجبار dhcpd به اجرا در پیش‌زمینه (foreground) به جای اجرا به عنوان یک دیمون در پس‌زمینه. این گزینه هنگام اجرای dhcpd زیر نظر یک دیباگر، یا هنگام اجرای آن از طریق inittab در سیستم‌های System V مفید است.
ارسال پیام‌های گزارش (log) به توصیف‌گر خطای استاندارد (stderr). این می‌تواند برای اشکال‌زدایی و همچنین در مکان‌هایی که گزارش کاملی از تمام فعالیت‌های DHCP باید نگهداری شود اما syslogd قابل اعتماد نبوده یا به دلایلی قابل استفاده نیست، مفید باشد. در حالت عادی، dhcpd تمامی خروجی‌ها را با استفاده از تابع syslog(3) با شناسه تسهیلات تنظیم‌شده روی LOG_DAEMON ثبت می‌کند. توجه داشته باشید که -d متضمن -f است (دیمون خود را به پس‌زمینه فورک نخواهد کرد).
حالت بی‌صدا هنگام راه‌اندازی. این گزینه چاپ کل پیام حق نشر (کپی‌رایت) را در حین راه‌اندازی سرکوب می‌کند. این امر ممکن است هنگام راه‌اندازی dhcpd از طریق یک اسکریپت راه‌اندازی سیستم (مانند ‎/etc/rc‎) مطلوب باشد.
آزمودن فایل پیکربندی. سرور نحو (سینتکس) درست فایل پیکربندی را بررسی می‌کند، اما برای انجام هیچ عملیات شبکه‌ای تلاش نخواهد کرد. از این گزینه می‌توان برای آزمایش خودکار یک فایل پیکربندی جدید پیش از نصب آن استفاده کرد.
آزمودن فایل اجاره‌ها. سرور نحو درست فایل اجاره را بررسی می‌کند، اما تلاشی برای انجام عملیات شبکه‌ای نخواهد کرد. علاوه بر خواندن فایل اجاره، سرور اجاره‌ها را در یک فایل اجاره موقت نیز می‌نویسد. فایل اجاره فعلی دستکاری نخواهد شد و فایل اجاره موقت پس از اتمام آزمون حذف می‌شود. این گزینه می‌تواند برای بررسی خودکار فایل اجاره جدید پیش از نصب آن به کار رود.
تغییر شناسه کاربری (setuid) به user پس از تکمیل عملیات ممتاز، مانند ساخت سوکت‌هایی که روی پورت‌های ممتاز گوش فرا می‌دهند. این گزینه همچنین باعث می‌شود مالکیت فایل اجاره به user تغییر یابد. این گزینه تنها در صورتی دردسترس است که کد با پچ PARANOIA کامپایل شده باشد (‎./configure --enable-paranoia‎).
تغییر شناسه گروهی (setgid) به group پس از تکمیل عملیات ممتاز، مانند ساخت سوکت‌هایی که روی پورت‌های ممتاز گوش فرا می‌دهند. این گزینه همچنین باعث می‌شود فایل اجاره از گروه group استفاده کند. این گزینه تنها در صورتی دردسترس است که کد با پچ PARANOIA کامپایل شده باشد (‎./configure --enable-paranoia‎).
انتقال ریشه (chroot) به دایرکتوری dir. بسته به این که کد با گزینه فعال EARLY_CHROOT کامپایل شده باشد یا خیر (‎./configure --enable-early-chroot‎)، این کار ممکن است قبل یا بعد از خواندن فایل‌های پیکربندی رخ دهد. این گزینه تنها در صورتی دردسترس است که کد با پچ PARANOIA کامپایل شده باشد (‎./configure --enable-paranoia‎).
تعیین فایلی که در آن تمام وضعیت راه‌اندازی سرور و کلیه تراکنش‌هایی که پردازش می‌کند ثبت شود. این می‌تواند در ارسال گزارش باگ مفید باشد — اگر هر از گاهی با خرابی و تخلیه حافظه (core dump) مواجه می‌شوید، می‌توانید سرور را با گزینه -tf راه‌اندازی کنید و سپس، زمانی که سرور دچار core dump شد، فایل ردگیری حاوی تمامی تراکنش‌هایی خواهد بود که به تخلیه حافظه منجر شده است، به طوری که مشکل بتواند به راحتی با -play اشکال‌زدایی شود.
تعیین فایلی که تمام وضعیت راه‌اندازی سرور و تمام تراکنش‌های پردازش‌شده از آن خوانده شود. گزینه -play باید همراه با یک فایل اجاره جایگزین، با استفاده از سوییچ -lf مشخص شود تا سرور DHCP فایل اجاره موجود شما را با داده‌های آزمایشی خود پاک نکند. سرور DHCP از فعالیت در حالت بازپخش (playback) خودداری خواهد کرد مگر این که یک فایل اجاره جایگزین مشخص کرده باشید.
چاپ شماره نسخه و خروج.

تغییر مکان‌های پیش‌فرض فایل‌ها: گزینه‌های زیر می‌توانند برای تغییر مکان‌هایی که dhcpd برای فایل‌های خود استفاده می‌کند، به کار روند. با توجه به اهمیت استفاده از پایگاه داده اجاره یکسان در همه زمان‌ها هنگام اجرای dhcpd در محیط عملیاتی، این گزینه‌ها باید فقط برای آزمودن فایل‌های اجاره یا فایل‌های پایگاه داده در محیط غیرعملیاتی استفاده شوند.

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

در حین کار، سرور ممکن است از چندین پورت UDP و TCP برای ارائه عملکردهای مختلف استفاده کند. این که کدام پورت‌ها باز می‌شوند به نحوه کامپایل کد و همچنین پیکربندی ارائه‌شده بستگی دارد. موارد زیر دیدی از پورت‌هایی که ممکن است در حال استفاده باشند ارائه می‌دهند:

معمولاً یک سرور DHCPv4 یک سوکت خام UDP برای دریافت و ارسال بیشتر بسته‌های DHCPv4 باز می‌کند. همچنین یک سوکت پشتیبان (fallback) UDP برای ارسال بسته‌های تک‌پخشی (unicast) باز می‌کند. به طور معمول هر دوی این‌ها از شماره پورت شناخته‌شده برای BOOTPS استفاده می‌کنند.

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

برای DHCPv6، سرور یک سوکت UDP روی پورت شناخته‌شده dhcpv6-server باز می‌کند.

سرور یک سوکت ICMP برای انجام درخواست‌های پینگ جهت بررسی استفاده شدن آدرس‌ها باز می‌کند.

اگر عبارت omapi-port را در فایل پیکربندی خود گنجانده باشید، سرور یک سوکت TCP روی آن پورت برای گوش دادن به اتصالات OMAPI باز خواهد کرد. وقتی اتصالی برقرار شود، از پورت دیگری برای اتصال ایجادشده استفاده خواهد شد.

هنگامی که DDNS در زمان کامپایل فعال شده باشد (به includes/site.h مراجعه کنید)، سرور یک سوکت UDP نسخه ۴ و یک سوکت UDP نسخه ۶ روی پورت‌های تصادفی باز می‌کند، مگر این که به‌روزرسانی‌های DDNS با تنظیم ddns-update-style روی none در فایل پیکربندی به صورت سراسری غیرفعال شده باشند.

سینتکس فایل dhcpd.conf(5) به طور جداگانه مورد بحث قرار گرفته است. این بخش باید به عنوان یک نمای کلی از فرآیند پیکربندی استفاده شود، و برای اطلاعات مرجع با جزئیات کامل باید به مستندات dhcpd.conf(5) مراجعه شود.

برنامه dhcpd باید شماره زیرشبکه‌ها و ماسک‌های شبکه (netmask) تمام زیرشبکه‌هایی را که به آن‌ها سرویس ارائه می‌دهد بداند. علاوه بر این، به منظور تخصیص پویای آدرس‌ها، باید یک یا چند محدوده از آدرس‌ها در هر زیرشبکه به آن اختصاص یابد تا بتواند آن‌ها را به نوبت هنگام بوت شدن میزبان‌های کلاینت به آن‌ها تخصیص دهد. بنابراین، یک پیکربندی بسیار ساده که پشتیبانی از DHCP را ارائه می‌دهد ممکن است به شکل زیر باشد:

subnet 239.252.197.0 netmask 255.255.255.0 {
  range 239.252.197.10 239.252.197.250;
}

محدوده‌های آدرس چندگانه را می‌توان به این صورت مشخص کرد:

subnet 239.252.197.0 netmask 255.255.255.0 {
  range 239.252.197.10 239.252.197.107;
  range 239.252.197.113 239.252.197.250;
}

اگر برای یک زیرشبکه فقط سرویس BOOTP و بدون تخصیص پویای آدرس ارائه می‌شود، بند range را می‌توان به طور کامل حذف کرد، اما عبارت subnet باید حتماً درج شود.

اجاره‌های DHCP می‌توانند تقریباً هر طولی از صفر ثانیه تا بی‌نهایت داشته باشند. این که چه مدت‌زمانی برای یک زیرشبکه خاص یا یک محیط نصب‌شده منطقی است، بسته به نوع میزبان‌هایی که به آن‌ها سرویس داده می‌شود، متفاوت خواهد بود.

به عنوان مثال، در یک محیط اداری که سیستم‌ها گهگاه اضافه و حذف می‌شوند اما جابه‌جایی آن‌ها نسبتاً کم است، منطقی است که مدت اجاره‌ها یک ماه یا بیشتر در نظر گرفته شود. در محیط آزمایش نهایی در یک کارخانه تولیدی، منطقی‌تر است که حداکثر طول اجاره ۳۰ دقیقه تعیین شود — زمان کافی برای طی کردن یک فرآیند آزمایشی ساده روی یک دستگاه شبکه پیش از بسته‌بندی آن برای تحویل.

امکان تعیین دو طول اجاره وجود دارد: طول پیش‌فرض که در صورت عدم درخواست کلاینت برای مدت‌زمانی خاص تخصیص می‌یابد، و حداکثر طول اجاره. این‌ها به عنوان بندهایی در دستور subnet مشخص می‌شوند:

subnet 239.252.197.0 netmask 255.255.255.0 {
  range 239.252.197.10 239.252.197.107;
  default-lease-time 600;
  max-lease-time 7200;
}

این تعریف خاص زیرشبکه، زمان اجاره پیش‌فرض ۶۰۰ ثانیه (ده دقیقه) و حداکثر زمان اجاره ۷۲۰۰ ثانیه (دو ساعت) را مشخص می‌کند. مقادیر متداول دیگر ۸۶۴۰۰ (یک روز)، ۶۰۴۸۰۰ (یک هفته) و ۲۵۹۲۰۰۰ (۳۰ روز) هستند.

نیازی نیست که هر زیرشبکه اجاره یکسانی داشته باشد—در مورد یک محیط اداری و یک محیط تولیدی که توسط همان سرور DHCP سرویس‌دهی می‌شوند، ممکن است داشتن مقادیر بسیار متفاوت برای زمان‌های اجاره پیش‌فرض و حداکثر در هر زیرشبکه منطقی باشد.

هر کلاینت BOOTP باید به صورت صریح در فایل dhcpd.conf تعریف شود. یک تعریف بسیار پایه کلاینت، آدرس سخت‌افزاری رابط شبکه کلاینت و آدرس IP اختصاص‌یافته به آن کلاینت را مشخص می‌کند. اگر کلاینت نیاز به بارگیری یک فایل بوت از سرور داشته باشد، نام آن فایل نیز باید تعیین گردد. یک تعریف ساده کلاینت bootp می‌تواند به شکل زیر باشد:

host haagen {
  hardware ethernet 08:00:2b:4c:59:23;
  fixed-address 239.252.197.9;
  filename "/tftpboot/haagen.boot";
}

پروتکل DHCP (و همچنین BOOTP با افزونه‌های سازنده - Vendor Extensions) سازوکاری را ارائه می‌دهد که به وسیله آن سرور می‌تواند اطلاعاتی را در مورد نحوه پیکربندی رابط شبکه کلاینت (مانند ماسک زیرشبکه) و همچنین نحوه دسترسی کلاینت به سرویس‌های گوناگون شبکه (مانند DNS، مسیریاب‌های IP و غیره) در اختیار آن قرار دهد.

این گزینه‌ها می‌توانند بر مبنای هر زیرشبکه و برای کلاینت‌های BOOTP نیز بر مبنای هر کلاینت تعیین شوند. در صورتی که تعریف یک کلاینت BOOTP گزینه‌هایی را مشخص کند که در تعریف زیرشبکه آن نیز قید شده باشند، گزینه‌های مشخص‌شده در تعریف کلاینت اولویت خواهند داشت. یک پیکربندی نسبتاً کامل DHCP ممکن است به شکل زیر باشد:

subnet 239.252.197.0 netmask 255.255.255.0 {
  range 239.252.197.10 239.252.197.250;
  default-lease-time 600;
  max-lease-time 7200;
  option subnet-mask 255.255.255.0;
  option broadcast-address 239.252.197.255;
  option routers 239.252.197.1;
  option domain-name-servers 239.252.197.2, 239.252.197.3;
  option domain-name "isc.org";
}

یک میزبان bootp در آن زیرشبکه که نیاز دارد در دامنه‌ای دیگر باشد و از سرور نام متفاوتی استفاده کند، می‌تواند به این صورت تعریف شود:

host haagen {
  hardware ethernet 08:00:2b:4c:59:23;
  fixed-address 239.252.197.9;
  filename "/tftpboot/haagen.boot";
  option domain-name-servers 192.5.5.1;
  option domain-name "example.com";
}

شرح کامل‌تری از نحو فایل dhcpd.conf در dhcpd.conf(5) ارائه شده است.

سرور DHCP این قابلیت را فراهم می‌کند که برخی از تنظیمات آن در حین اجرا، بدون نیاز به متوقف کردن، ویرایش فایل‌های پایگاه داده و راه‌اندازی مجدد آن، تغییر یابند. این قابلیت در حال حاضر با استفاده از OMAPI—یک رابط برنامه‌نویسی کاربردی برای دستکاری اشیاء از راه دور—فراهم شده است. کلاینت‌های OMAPI با استفاده از TCP/IP به سرور متصل می‌شوند، احراز هویت می‌نمایند و سپس می‌توانند وضعیت فعلی سرور را بررسی کرده و در آن تغییراتی ایجاد کنند.

برنامه‌های کاربردی به جای پیاده‌سازی مستقیم پروتکل زیربنایی OMAPI، باید از API مربوط به dhcpctl یا خود OMAPI استفاده کنند. برنامه dhcpctl یک بسته‌بند (wrapper) است که برخی کارهای جانبی و مقدماتی را که OMAPI به صورت خودکار انجام نمی‌دهد مدیریت می‌کند. مستندات dhcpctl و OMAPI در dhcpctl(3) و omapi(3) آمده است.

رابط OMAPI اشیایی (objects) را برون‌ریزی می‌کند که می‌توان آن‌ها را بررسی و دستکاری کرد. سرور DHCP اشیاء زیر را صادر می‌کند: lease (اجاره)، host (میزبان)، failover-state (وضعیت فیل‌اور) و group (گروه). برای هر شیء تعدادی متد ارائه شده است: lookup (جستجو)، create (ایجاد)، و destroy (نابود کردن). علاوه بر این، امکان مشاهده ویژگی‌هایی که روی اشیاء ذخیره شده‌اند و در برخی موارد تغییر آن ویژگی‌ها وجود دارد.

اجاره‌ها در حال حاضر نمی‌توانند ایجاد یا حذف شوند، اما می‌توان آن‌ها را جستجو کرد تا وضعیتشان بررسی و تغییر داده شود.

اجاره‌ها دارای ویژگی‌های زیر هستند:

state integer lookup, examine

1 = free
2 = active
3 = expired
4 = released
5 = abandoned
6 = reset
7 = backup
8 = reserved
9 = bootp

ip-address data lookup, examine

آدرس IP مربوط به اجاره.

dhcp-client-identifier data lookup, examine, update

شناسه کلاینت که کلاینت هنگام دریافت اجاره از آن استفاده کرده است. همه کلاینت‌ها شناسه کلاینت ارسال نمی‌کنند، بنابراین این فیلد ممکن است خالی باشد.

client-hostname data examine, update

مقداری که کلاینت در گزینه host-name ارسال کرده است.

host handle examine

تعریف میزبان مرتبط با این اجاره، در صورت وجود.

subnet handle examine

شیء زیرشبکه مرتبط با این اجاره (شیء زیرشبکه در حال حاضر پشتیبانی نمی‌شود).

pool handle examine

شیء استخر (pool) مرتبط با این اجاره (شیء استخر در حال حاضر پشتیبانی نمی‌شود).

billing-class handle examine

هندل مربوط به کلاسی که این اجاره در حال حاضر برای آن محاسبه می‌شود، در صورت وجود (شیء کلاس در حال حاضر پشتیبانی نمی‌شود).

hardware-address data examine, update

فیلد آدرس سخت‌افزاری (chaddr) ارسال‌شده توسط کلاینت هنگام دریافت اجاره‌اش.

hardware-type integer examine, update

نوع رابط شبکه‌ای که کلاینت هنگام دریافت اجاره خود گزارش داده است.

ends time examine

زمانی که وضعیت فعلی اجاره به پایان می‌رسد، طبق درک کلاینت.

tstp time examine

زمانی که وضعیت فعلی اجاره به پایان می‌رسد، طبق درک سرور.
tsfp time examine
زمان تعدیل‌شده‌ای که وضعیت فعلی اجاره به پایان می‌رسد، طبق درک همتای فیل‌اور (اگر همتای فیل‌اور وجود نداشته باشد، این مقدار تعریف‌نشده است). به طور کلی این مقدار فقط برای اجاره‌های منقضی‌شده، رهاشده یا بازنشانی‌شده در زمانی که سرور در وضعیت partner-down کار می‌کند تعدیل می‌شود، و در غیر این صورت صرفاً مقداری است که توسط همتا ارائه شده است.
atsfp time examine
مقدار واقعی tsfp ارسال‌شده از همتا. این مقدار هنگامی که تغییر وضعیت پیوند اجاره رخ می‌دهد، برای تسهیل منطق ارسال مجدد (retransmission) فراموش می‌شود.

cltt time examine

زمان آخرین تراکنش با کلاینت روی این اجاره.

میزبان‌ها می‌توانند ایجاد، نابود، جستجو، بررسی و اصلاح شوند. اگر تعریف یک میزبان با استفاده از OMAPI ایجاد یا حذف شود، آن اطلاعات در فایل dhcpd.leases ثبت خواهد شد. حذف تعریف میزبان‌هایی که در فایل dhcpd.conf تعریف شده‌اند، مجاز است.

میزبان‌ها دارای ویژگی‌های زیر هستند:

name data lookup, examine, modify

نام تعریف میزبان. این نام باید در میان تمام تعریف‌های میزبان یکتا باشد.

group handle examine, modify

گروه نام‌گذاری‌شده مرتبط با این تعریف میزبان، در صورت وجود.

hardware-address data lookup, examine, modify

آدرس لایه پیوند (link-layer) که برای تطبیق کلاینت استفاده می‌شود، در صورت وجود. این ویژگی تنها در صورتی معتبر است که hardware-type نیز وجود داشته باشد.

hardware-type integer lookup, examine, modify

نوع رابط شبکه‌ای که برای تطبیق کلاینت استفاده می‌شود، در صورت وجود. این ویژگی تنها در صورتی معتبر است که hardware-address نیز وجود داشته باشد.

dhcp-client-identifier data lookup, examine, modify

گزینه dhcp-client-identifier که برای تطبیق کلاینت استفاده خواهد شد، در صورت وجود.

ip-address data examine, modify

یک آدرس IP ثابت که برای یک کلاینت DHCP منطبق با این تعریف میزبان رزرو شده است. این آدرس IP تنها در صورتی به کلاینت تخصیص می‌یابد که برای بخش شبکه‌ای (network segment) که کلاینت به آن متصل است معتبر باشد.

statements data modify

فهرستی از دستورات در قالب فایل dhcpd.conf که هر زمان پیامی از کلاینت در حال پردازش باشد، اجرا خواهند شد.

known integer examine, modify

اگر غیرصفر باشد، نشان می‌دهد که کلاینت منطبق با این تعریف میزبان در فهرست‌های مجوز استخر (pool permit lists) به عنوان شناخته‌شده (known) در نظر گرفته می‌شود. اگر صفر باشد، کلاینت به عنوان شناخته‌شده در نظر گرفته نخواهد شد.

گروه‌های نام‌گذاری‌شده می‌توانند ایجاد، نابود، جستجو، بررسی و اصلاح شوند. اگر تعریف یک گروه با استفاده از OMAPI ایجاد یا حذف شود، آن اطلاعات در فایل dhcpd.leases ثبت خواهد شد. حذف تعریف گروه‌هایی که در فایل dhcpd.conf تعریف شده‌اند، مجاز است.

گروه‌های نام‌گذاری‌شده در حال حاضر فقط می‌توانند با میزبان‌ها مرتبط شوند—این امر اجازه می‌دهد تا مجموعه‌ای از دستورات به شکلی کارآمد به بیش از یک تعریف میزبان پیوست شود.

گروه‌ها دارای ویژگی‌های زیر هستند:

name data

نام گروه. تمام گروه‌هایی که با استفاده از OMAPI ایجاد می‌شوند باید نام داشته باشند، و این نام‌ها باید در میان تمام گروه‌ها یکتا باشند.

statements data

فهرستی از دستورات در قالب فایل dhcpd.conf که هر زمان پیامی از کلاینتی پردازش شود که تعریف میزبان آن به این گروه ارجاع می‌دهد، اجرا خواهد شد.

شیء کنترل به شما امکان می‌دهد سرور را خاموش کنید. اگر سرور در حال انجام فیل‌اور (failover) با همتای دیگری باشد، گذاری منظم به وضعیت shutdown انجام می‌دهد و به همتای خود اطلاع می‌دهد تا همتا بتواند به وضعیت partner down برود، و سپس وضعیت "recover" را در فایل اجاره ثبت می‌کند تا هنگام راه‌اندازی مجدد سرور، به طور خودکار با همتای خود همگام‌سازی مجدد شود.

هنگام خاموش شدن، سرور همچنین تلاش خواهد کرد تمام اتصالات OMAPI را به طور منظم ببندد. اگر این اتصالات پس از پنج ثانیه به طور منظم بسته نشوند، به صورت پیش‌دستانه قطع می‌شوند. از شروع فرآیند خاموش شدن تا زمانی که سرور عملاً خارج شود، ممکن است تا ۲۵ ثانیه طول بکشد.

برای خاموش کردن سرور، شیء کنترل آن را باز کرده و ویژگی state را روی ۲ تنظیم کنید.

شیء failover-state شیئی است که وضعیت پروتکل فیل‌اور را در حالی که برای یک همتای فیل‌اور معین مدیریت می‌شود، پیگیری می‌کند. شیء فیل‌اور دارای ویژگی‌های زیر است (لطفاً برای توضیحات درباره معنای این ویژگی‌ها به dhcpd.conf(5) مراجعه کنید):

name data examine

نام رابطه همتای فیل‌اور را، همان‌گونه که در فایل dhcpd.conf سرور شرح داده شده است، نشان می‌دهد.

partner-address data examine

آدرس IP شریک فیل‌اور را نشان می‌دهد.

local-address data examine

آدرس IP مورد استفاده سرور DHCP برای این جفت فیل‌اور را نشان می‌دهد.

partner-port data examine

پورت TCP که شریک فیل‌اور روی آن برای اتصالات پروتکل فیل‌اور گوش فرا می‌دهد را نشان می‌دهد.

local-port data examine

پورت TCP که سرور DHCP روی آن برای اتصالات پروتکل فیل‌اور این جفت فیل‌اور گوش فرا می‌دهد را نشان می‌دهد.

max-outstanding-updates integer examine

تعداد به‌روزرسانی‌هایی را نشان می‌دهد که می‌توانند در هر زمان معین در این رابطه فیل‌اور، معلق و تاییدنشده باشند.

mclt integer examine

حداکثر زمان هدایت کلاینت (MCLT) را در این رابطه فیل‌اور نشان می‌دهد.

load-balance-max-secs integer examine

حداکثر مقدار فیلد secs در درخواست کلاینت پیش از دور زدن تعادل بار (load balancing) را نشان می‌دهد.

load-balance-hba data examine

آرایه باکت درهم‌سازی تعادل بار (hash bucket array) را برای این رابطه فیل‌اور نشان می‌دهد.

local-state integer examine, modify

وضعیت فعلی سرور DHCP در این رابطه فیل‌اور را نشان می‌دهد. مقادیر ممکن برای state عبارتند از:
1   - startup
2   - normal
3   - communications interrupted
4   - partner down
5   - potential conflict
6   - recover
7   - paused
8   - shutdown
9   - recover done
10  - resolution interrupted
11  - conflict done
254 - recover wait
(توجه داشته باشید که برخی از مقادیر فوق از زمان DHCP 3.0.x تغییر کرده‌اند.)
به‌طور کلی، تغییر دادن این وضعیت ایده خوبی نیست. با این حال، در صورتی که مشخص شود شریک فیل‌اور از کار افتاده است، تنظیم وضعیت فیل‌اور سرور DHCP روی partner down می‌تواند مفید باشد. در این نقطه، سرور DHCP سرویس‌دهی اجاره‌های شریک فیل‌اور را در اسرع وقت به عهده گرفته و اجاره‌های عادی اعطا می‌کند، نه اجاره‌هایی که توسط MCLT محدود شده‌اند. اگر سرور DHCP را در زمانی که سرور دیگر در وضعیت partner-down نیست، اما در دسترس نیست، در حالت partner-down قرار دهید، تداخل در تخصیص آدرس‌های IP امکان‌پذیر و حتی محتمل است. هنگامی که یک سرور در حالت partner-down قرار گرفت، شریک فیل‌اور آن نباید مجدداً آنلاین شود تا زمانی که برقراری ارتباط بین دو سرور امکان‌پذیر گردد.

partner-state integer examine

وضعیت فعلی شریک فیل‌اور را نشان می‌دهد.

local-stos integer examine

زمانی را نشان می‌دهد که سرور DHCP در این رابطه فیل‌اور وارد وضعیت فعلی خود شده است.

partner-stos integer examine

زمانی را نشان می‌دهد که شریک فیل‌اور وارد وضعیت فعلی خود شده است.

hierarchy integer examine

نشان می‌دهد که سرور DHCP در این رابطه فیل‌اور اصلی (۰) است یا فرعی (۱).

last-packet-sent integer examine

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

last-timestamp-received integer examine

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

skew integer examine

انحراف زمانی (skew) بین ساعت شریک فیل‌اور و ساعت این سرور DHCP را نشان می‌دهد.

max-response-delay integer examine

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

cur-unacked-updates integer examine

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

ETCDIR/dhcpd.conf, DBDIR/dhcpd.leases, RUNDIR/dhcpd.pid, DBDIR/dhcpd.leases~.

dhclient(8), dhcrelay(8), dhcpd.conf(5), dhcpd.leases(5)

dhcpd(8) در ابتدا توسط Ted Lemon تحت قراردادی با Vixie Labs نوشته شد. تأمین مالی این پروژه توسط Internet Systems Consortium انجام شد. نسخه ۳ سرور DHCP توسط Nominum, Inc. تأمین مالی شد. اطلاعات درباره کنسرسیوم سامانه‌های اینترنتی در نشانی زیر موجود است: https://www.isc.org.