نام (NAME)

slapo-dds - لایه روکش خدمات دایرکتوری پویا (DDS) برای slapd

خلاصه دستور (SYNOPSIS)

/etc/openldap/slapd.conf

توضیحات (DESCRIPTION)

روکش dds برای slapd(8) اشیاء پویا (dynamic objects) را مطابق با RFC 2589 پیاده‌سازی می‌کند. نام dds مخفف Dynamic Directory Services (خدمات دایرکتوری پویا) است. این روکش امکان تعریف اشیاء پویا را که با کلاس شیء dynamicObject مشخص می‌شوند، فراهم می‌کند.

اشیاء پویا دارای طول عمر محدودی هستند که بر اساس یک زمان ماندگاری (TTL یا Time-To-Live) تعیین می‌شود و می‌تواند از طریق یک عملیات گسترش‌یافته خاص به نام refresh (تازه‌سازی) تجدید شود. این عملیات امکان تنظیم دوره زمانی تازه‌سازی کلاینت (CRP یا Client Refresh Period) را می‌دهد، به این معنی که فاصله زمانی میان دفعات تازه‌سازی لازم است تا از منقضی شدن شیء پویا جلوگیری شود. زمان انقضا با افزودن مقدار TTL درخواستی به زمان جاری محاسبه می‌گردد. هنگامی که اشیاء پویا به پایان طول عمر خود برسند بدون آنکه مجدداً تازه‌سازی شوند، به‌طور خودکار حذف خواهند شد. هیچ تضمینی برای حذف فوری وجود ندارد، بنابراین کلاینت‌ها نباید روی حذف بلافاصله حساب کنند.

اشیاء پویا می‌توانند دارای اشیاء زیرمجموعه (subordinates) باشند، به شرط آنکه این زیرمجموعه‌ها نیز شیء پویا باشند. استاندارد RFC 2589 رفتار یک سرویس دایرکتوری پویا را هنگام منقضی شدن یک شیء پویا که دارای زیرمجموعه‌های (پویا) است، مشخص نکرده است. در این پیاده‌سازی، طول عمر اشیاء پویای دارای زیرمجموعه تا زمانی که تمام زیرمجموعه‌های پویای آن‌ها منقضی شوند، تمدید می‌گردد.

این دستورالعمل slapd.conf(5) روکش dds را به پایگاه داده فعلی اضافه می‌کند:

overlay dds

پایگاه داده حتماً باید یک rootdn مشخص‌شده داشته باشد، در غیر این صورت روکش dds قادر به حذف اشیاء منقضی‌شده نخواهد بود. روکش dds می‌تواند همراه با هر بک‌اندی که عملیات‌های add، modify، search و delete را پیاده‌سازی می‌کند به کار گرفته شود. از آنجا که استفاده از آن ممکن است منجر به جستجوها، افزودن‌ها و حذف‌های داخلی متعددی برای مدخل‌ها شود، بهتر است همراه با بک‌اندهایی استفاده شود که عملکرد نوشتن مناسب و مطلوبی دارند.

دستورالعمل‌های پیکربندی که مختص روکش dds هستند، با پیشوند dds- مشخص می‌شوند تا از تداخل‌های احتمالی با دستورالعمل‌های مربوط به پایگاه داده زیرین یا سایر روکش‌های پشته‌شده جلوگیری به عمل آید.

dds-max-ttl <time>

حداکثر مقدار TTL را مشخص می‌کند. همچنین این مقدار، TTL پیش‌فرضی است که اشیاء پویای تازه ایجادشده دریافت می‌کنند، مگر اینکه dds-default-ttl تنظیم شده باشد. هنگامی که کلاینت با یک عملیات گسترش‌یافته تازه‌سازی (refresh)، مقداری بیشتر از این حد را درخواست کند، خطای sizeLimitExceeded بازگردانده می‌شود. این مقدار باید بین 86400 (یک روز، مقدار پیش‌فرض) و 31557600 (یک سال به علاوه ۶ ساعت، طبق RFC 2589) باشد.

dds-min-ttl <time>

حداقل مقدار TTL را تعیین می‌کند؛ کلاینت‌هایی که با عملیات گسترش‌یافته تازه‌سازی، مقدار TTL کمتری درخواست کنند، عملاً این مقدار را به عنوان CRP به دست خواهند آورد. اگر روی 0 (پیش‌فرض) تنظیم شود، هیچ حد پایینی تعیین نمی‌گردد.

dds-default-ttl <time>

مقدار پیش‌فرض TTL را که به اشیاء پویای تازه‌ساخته‌شده اختصاص می‌یابد، مشخص می‌کند. اگر روی 0 (پیش‌فرض) تنظیم شود، از مقدار dds-max-ttl استفاده می‌شود.

dds-interval <time>

فاصله زمانی میان بررسی‌های انقضا را مشخص می‌کند؛ مقدار پیش‌فرض ۱ ساعت است.

dds-tolerance <time>

زمان اضافی را مشخص می‌کند که به تایمر بیدارکننده نخی (thread) که شیء پویای منقضی‌شده را حذف خواهد کرد، اضافه می‌شود. بنابراین طول عمر اسمی مدخل همان مقداری است که در ویژگی entryTtl مشخص شده است، اما طول عمر واقعی آن برابر با entryTtl + tolerance خواهد بود. توجه داشته باشید که هیچ تضمینی وجود ندارد که طول عمر یک شیء پویا دقیقاً برابر با TTL درخواستی باشد؛ به دلیل جزئیات پیاده‌سازی ممکن است طولانی‌تر باشد، که این مورد طبق RFC 2589 مجاز است. به طور پیش‌فرض، مقدار tolerance برابر با 0 است.

dds-max-dynamicObjects <num>

حداکثر تعداد اشیاء پویایی را که می‌توانند به‌طور همزمان در یک بستر نام‌گذاری (naming context) وجود داشته باشند، مشخص می‌کند. این امر به فرد اجازه می‌دهد تا میزان منابع مصرفی توسط اشیاء پویا را (عمدتاً از نظر اندازه صف اجرا یا run-queue) محدود سازد. به طور پیش‌فرض، هیچ محدودیتی تعیین نشده است.

dds-state {TRUE|false}

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

کنترل دسترسی (ACCESS CONTROL)

روکش dds عملیات تازه‌سازی را با الزام دسترسی manage به ویژگی entryTtl محدود می‌کند (برای جزئیات درباره سطح دسترسی manage به slapd.access(5) مراجعه نمایید). از آنجا که entryTtl یک ویژگی عملیاتی و غیرقابل تغییر توسط کاربر (NO-USER-MODIFICATION) است، دسترسی نوشتن مستقیم به آن امکان‌پذیر نیست. از این رو، روکش dds عملیات گسترش‌یافته تازه‌سازی را به یک تغییر داخلی بر روی مقدار ویژگی entryTtl همراه با تنظیم کنترل relax تبدیل می‌کند.

استاندارد RFC 2589 توصیه می‌کند که کلاینت‌های ناشناس (anonymous) نباید اجازه تازه‌سازی شیء پویا را داشته باشند. این امر را می‌توان با تنظیم مناسب کنترل دسترسی برای دستیابی به اثر دلخواه پیاده‌سازی کرد.

مثال: محدود کردن تازه‌سازی به کاربران احرازهویت‌شده:

access to attrs=entryTtl
	by users manage
	by * read

مثال: محدود کردن تازه‌سازی به سازنده شیء پویا:

access to attrs=entryTtl
	by dnattr=creatorsName manage
	by * read

یکی دیگر از کاربردهای پیشنهادی اشیاء پویا، پیاده‌سازی جلسات پویا (dynamic meetings) است؛ در این حالت، به تمامی شرکت‌کنندگان در جلسه اجازه داده می‌شود شیء جلسه را تازه‌سازی کنند، اما تنها سازنده می‌تواند آن را حذف کند (در غیر این صورت، با انقضای TTL حذف خواهد شد).

مثال: با فرض اینکه participant یک ویژگی معتبر با مقدار DN است، به کاربران اجازه آغاز جلسه و پیوستن به آن داده شود؛ تازه‌سازی به شرکت‌کنندگان محدود گردد؛ و حذف به سازنده محدود شود:

access to dn.base="cn=Meetings"
		attrs=children
	by users write
access to dn.onelevel="cn=Meetings"
		attrs=entry
	by dnattr=creatorsName write
	by * read
access to dn.onelevel="cn=Meetings"
		attrs=participant
	by dnattr=creatorsName write
	by users selfwrite
	by * read
access to dn.onelevel="cn=Meetings"
		attrs=entryTtl
	by dnattr=participant manage
	by * read

همگام‌سازی و تکثیر (REPLICATION)

این پیاده‌سازی از RFC 2589 تفسیر محدودی از نحوه تکثیر و همگام‌سازی اشیاء پویا ارائه می‌دهد. تنها تامین‌کننده (provider) مدیریت انقضای شیء پویا را بر عهده می‌گیرد، در حالی که مصرف‌کنندگان (consumers) صرفاً شیء پویا را به عنوان یک شیء معمولی مشاهده می‌کنند.

هنگام تکثیر این اشیاء، لازم است کلاس dynamicObject و ویژگی entryTtl به‌طور صریح مستثنی شوند. این پیاده‌سازی از RFC 2589 یک ویژگی عملیاتی جدید با نام entryExpireTimestamp معرفی می‌کند که شامل برچسب زمانی انقضا است. این ویژگی نیز باید از تکثیر مستثنی شود.

راهکار سریع و موقت این است که مقدار schemacheck=off را در پیکربندی syncrepl تنظیم کنید و در صورت تمایل، ویژگی‌های عملیاتی را با استفاده از دستور زیر از تکثیر مستثنی نمایید:

syncrepl ...
	exattrs=entryTtl,entryExpireTimestamp

در هر صورت، روکش باید یا به‌صورت ایستا درون برنامه ساخته شده باشد یا در زمان اجرا توسط مصرف‌کننده بارگذاری شود تا از ویژگی عملیاتی entryExpireTimestamp مطلع باشد؛ با این حال، نباید در پایگاه داده سایه (shadow database) پیکربندی شود. در حال حاضر هیچ راهکاری برای حذف کلاس dynamicObject از مدخل وجود ندارد؛ این موضوع را می‌توان به عنوان یک ویژگی در نظر گرفت، زیرا به فرد امکان می‌دهد ویژگی‌های پویای شیء را مشاهده کند.

فایل‌ها (FILES)

/etc/openldap/slapd.conf

فایل پیکربندی پیش‌فرض slapd

همچنین ببینید (SEE ALSO)

slapd.conf(5)، slapd-config(5)، slapd(8).

نویسنده (AUTHOR)

پیاده‌سازی شده توسط Pierangelo Masarati.