.TH SLAPO-DDS 5 "2026/03/09" "OpenLDAP 2.6.13" "فایل‌های پیکربندی"
.\" Copyright 2005-2026 The OpenLDAP Foundation, All Rights Reserved.
.\" Copying restrictions apply.  See the COPYRIGHT file.
.\" $OpenLDAP$
.SH "نام (NAME)"
slapo-dds \- لایه روکش خدمات دایرکتوری پویا (DDS) برای slapd
.SH "خلاصه دستور (SYNOPSIS)"
/etc/openldap/slapd.conf
.SH "توضیحات (DESCRIPTION)"
روکش
.B dds
برای
.BR slapd (8)
اشیاء پویا (dynamic objects) را مطابق با RFC 2589 پیاده‌سازی می‌کند.
نام
.B dds
مخفف
.I Dynamic Directory Services
(خدمات دایرکتوری پویا) است.
این روکش امکان تعریف اشیاء پویا را که با کلاس شیء
.B dynamicObject
مشخص می‌شوند، فراهم می‌کند.
.PP
اشیاء پویا دارای طول عمر محدودی هستند که بر اساس یک زمان ماندگاری
(TTL یا Time-To-Live) تعیین می‌شود و می‌تواند از طریق یک عملیات گسترش‌یافته خاص به نام
.B refresh
(تازه‌سازی) تجدید شود.
این عملیات امکان تنظیم دوره زمانی تازه‌سازی کلاینت (CRP یا Client Refresh Period) را می‌دهد،
به این معنی که فاصله زمانی میان دفعات تازه‌سازی لازم است تا از منقضی شدن شیء پویا جلوگیری شود.
زمان انقضا با افزودن مقدار TTL درخواستی به زمان جاری محاسبه می‌گردد.
هنگامی که اشیاء پویا به پایان طول عمر خود برسند بدون آنکه مجدداً تازه‌سازی شوند، به‌طور خودکار حذف خواهند شد.
هیچ تضمینی برای حذف فوری وجود ندارد، بنابراین کلاینت‌ها نباید روی حذف بلافاصله حساب کنند.
.PP
اشیاء پویا می‌توانند دارای اشیاء زیرمجموعه (subordinates) باشند، به شرط آنکه این زیرمجموعه‌ها نیز شیء پویا باشند.
استاندارد RFC 2589 رفتار یک سرویس دایرکتوری پویا را هنگام منقضی شدن یک شیء پویا که دارای زیرمجموعه‌های (پویا) است، مشخص نکرده است.
در این پیاده‌سازی، طول عمر اشیاء پویای دارای زیرمجموعه تا زمانی که تمام زیرمجموعه‌های پویای آن‌ها منقضی شوند، تمدید می‌گردد.
.PP
این دستورالعمل
.BR slapd.conf (5)
روکش
.B dds
را به پایگاه داده فعلی اضافه می‌کند:

.TP
.B overlay dds

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

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

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

.TP
.B dds\-min\-ttl <time>
حداقل مقدار TTL را تعیین می‌کند؛ کلاینت‌هایی که با عملیات گسترش‌یافته تازه‌سازی، مقدار TTL کمتری درخواست کنند، عملاً این مقدار را به عنوان CRP به دست خواهند آورد.
اگر روی 0 (پیش‌فرض) تنظیم شود، هیچ حد پایینی تعیین نمی‌گردد.

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

.TP
.B dds\-interval <time>
فاصله زمانی میان بررسی‌های انقضا را مشخص می‌کند؛ مقدار پیش‌فرض ۱ ساعت است.

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

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

.TP
.B dds\-state {TRUE|false}
مشخص می‌کند که قابلیت خدمات دایرکتوری پویا فعال است یا خیر.
به طور پیش‌فرض فعال است؛ با این حال، یک پروکسی نیازی ندارد که خودش رد اشیاء پویا را پیگیری کند، بلکه تنها کافی است به پیشانه اطلاع دهد که پشتیبانی از اشیاء پویا در دسترس است.

.SH "کنترل دسترسی (ACCESS CONTROL)"
روکش
.B dds
عملیات تازه‌سازی را با الزام دسترسی
.B manage
به ویژگی
.B entryTtl
محدود می‌کند (برای جزئیات درباره سطح دسترسی
.B manage
به
.BR slapd.access (5)
مراجعه نمایید).
از آنجا که
.B entryTtl
یک ویژگی عملیاتی و غیرقابل تغییر توسط کاربر (NO-USER-MODIFICATION) است، دسترسی نوشتن مستقیم به آن امکان‌پذیر نیست.
از این رو، روکش
.B dds
عملیات گسترش‌یافته تازه‌سازی را به یک تغییر داخلی بر روی مقدار ویژگی
.B entryTtl
همراه با تنظیم کنترل
.B relax
تبدیل می‌کند.
.PP
استاندارد RFC 2589 توصیه می‌کند که کلاینت‌های ناشناس (anonymous) نباید اجازه تازه‌سازی شیء پویا را داشته باشند.
این امر را می‌توان با تنظیم مناسب کنترل دسترسی برای دستیابی به اثر دلخواه پیاده‌سازی کرد.
.PP
مثال: محدود کردن تازه‌سازی به کاربران احرازهویت‌شده:

.RS
.nf
access to attrs=entryTtl
	by users manage
	by * read

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

.RS
.nf
access to attrs=entryTtl
	by dnattr=creatorsName manage
	by * read

.fi
.RE
.PP
یکی دیگر از کاربردهای پیشنهادی اشیاء پویا، پیاده‌سازی جلسات پویا (dynamic meetings) است؛
در این حالت، به تمامی شرکت‌کنندگان در جلسه اجازه داده می‌شود شیء جلسه را تازه‌سازی کنند، اما تنها سازنده می‌تواند آن را حذف کند (در غیر این صورت، با انقضای TTL حذف خواهد شد).
.PP
مثال: با فرض اینکه \fIparticipant\fP یک ویژگی معتبر با مقدار DN است، به کاربران اجازه آغاز جلسه و پیوستن به آن داده شود؛ تازه‌سازی به شرکت‌کنندگان محدود گردد؛ و حذف به سازنده محدود شود:

.RS
.nf
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

.fi
.RE

.SH "همگام‌سازی و تکثیر (REPLICATION)"
این پیاده‌سازی از RFC 2589 تفسیر محدودی از نحوه تکثیر و همگام‌سازی اشیاء پویا ارائه می‌دهد. تنها تامین‌کننده (provider) مدیریت انقضای شیء پویا را بر عهده می‌گیرد، در حالی که مصرف‌کنندگان (consumers) صرفاً شیء پویا را به عنوان یک شیء معمولی مشاهده می‌کنند.
.PP
هنگام تکثیر این اشیاء، لازم است کلاس
.B dynamicObject
و ویژگی
.B entryTtl
به‌طور صریح مستثنی شوند.
این پیاده‌سازی از RFC 2589 یک ویژگی عملیاتی جدید با نام
.BR entryExpireTimestamp
معرفی می‌کند که شامل برچسب زمانی انقضا است. این ویژگی نیز باید از تکثیر مستثنی شود.
.PP
راهکار سریع و موقت این است که مقدار
.B schemacheck=off
را در پیکربندی syncrepl تنظیم کنید
و در صورت تمایل، ویژگی‌های عملیاتی را با استفاده از دستور زیر از تکثیر مستثنی نمایید:

.RS
.nf
syncrepl ...
	exattrs=entryTtl,entryExpireTimestamp
.fi
.RE
.PP
در هر صورت، روکش باید یا به‌صورت ایستا درون برنامه ساخته شده باشد یا در زمان اجرا توسط مصرف‌کننده بارگذاری شود تا از ویژگی عملیاتی
.B entryExpireTimestamp
مطلع باشد؛ با این حال، نباید در پایگاه داده سایه (shadow database) پیکربندی شود.
در حال حاضر هیچ راهکاری برای حذف کلاس
.B dynamicObject
از مدخل وجود ندارد؛ این موضوع را می‌توان به عنوان یک ویژگی در نظر گرفت، زیرا به فرد امکان می‌دهد ویژگی‌های پویای شیء را مشاهده کند.

.SH "فایل‌ها (FILES)"
.TP
/etc/openldap/slapd.conf
فایل پیکربندی پیش‌فرض slapd
.SH "همچنین ببینید (SEE ALSO)"
.BR slapd.conf (5)،
.BR slapd\-config (5)،
.BR slapd (8).
.SH "نویسنده (AUTHOR)"
پیاده‌سازی شده توسط Pierangelo Masarati.