SLAPD-RELAY(5) فایلهای پیکربندی SLAPD-RELAY(5)

slapd-relay - بکاند بازپخش و ارجاع داخلی برای دیمن slapd

/etc/ldap/slapd.conf

بکاند slapd-relay امکان ارجاع و نگاشت درخواستهای یک بخش از پایگاهداده دایرکتوری به بخش دیگر را ایجاد میکند. هدف اصلی این بکاند slapd(8) نگاشت یک بافت نام‌گذاری (naming context) تعریف‌شده در یک پایگاه‌داده در حال اجرا در همان نمونه slapd(8) به یک بافت نام‌گذاری مجازی است، به همراه دستکاری attributeType و objectClass در صورت نیاز. این بکاند نیازمند لایه همپوشان slapo-rwm(5) می‌باشد.

این بکاند و لایه همپوشان نام‌برده آزمایشی (experimental) هستند.

دستورالعمل‌های زیر در slapd.conf برای پایگاه‌داده بکاند relay اعمال می‌شوند. به این معنا که آن‌ها باید پس از خط "database relay" و پیش از هر خط "backend" یا "database" بعدی بیایند. سایر گزینه‌های پایگاه‌داده در صفحه راهنمای slapd.conf(5) شرح داده شده‌اند؛ تنها دستورالعمل suffix توسط بکاند relay مجاز است.

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

پایگاه‌داده relay به‌طور خودکار بافت نام‌گذاری درخواست‌ها و پاسخ‌ها را بازنویسی نمی‌کند. برای این منظور، لایه همپوشان slapo-rwm(5) باید به‌صراحت نمونه‌سازی و بر اساس نیاز پیکربندی شود. معمولاً، اگر فقط بازنویسی بافت نام‌گذاری نیاز باشد، دستورالعمل rwm-suffixmassage کفایت می‌کند.

یک مسئله مهم این است که قوانین دسترسی بر اساس هویتی است که عملیات را صادر کرده است. پس از بازنویسی (massaging) از بافت نام‌گذاری مجازی به واقعی، فرانت‌اند عملیات را طوری می‌بیند که گویی توسط هویت موجود در بافت نام‌گذاری واقعی انجام شده است. علاوه بر این، از آنجا که back-relay عملیات فرانت‌اند پایگاه‌داده واقعی را با میان‌بر زدن عملیات از طریق API بکاند داخلی دور می‌زند، قوانین دسترسی پایگاه‌داده اصلی اعمال نمی‌شوند مگر در موارد خاص، یعنی زمانی که خود بکاند کنترل دسترسی را اعمال کند. در نتیجه، نمونه‌های پایگاه‌داده relay باید قوانین دسترسی مخصوص به خود را ارائه دهند که با قوانین پایگاه‌داده اصلی همخوانی داشته باشند و در صورت نیاز محدودیت‌های خاص بیشتری را نیز اضافه کنند. بنابراین، قوانین دسترسی در پایگاه‌داده relay باید به هویت‌های موجود در بافت نام‌گذاری واقعی ارجاع دهند. نمونه‌ها در بخش «مثال‌ها» آورده شده‌اند.

اگر هیچ دستورالعمل relay داده نشود، پایگاه‌داده relay به هیچ پایگاه‌داده خاصی ارجاع نمی‌دهد، بلکه مناسب‌ترین پایگاه‌داده پس از بازنویسی DN درخواست برای عملیاتی که در حال پردازش است، جستجو و پیدا می‌شود.

این امر امکان نوشتن قوانین بازنویسی دقیق و حساب‌شده‌ای را فراهم می‌کند که باعث می‌شود برخی از درخواست‌ها به یک پایگاه‌داده و برخی به دیگری هدایت شوند؛ برای نمونه، اعتبارسنجی می‌تواند به یک پایگاه‌داده و جستجوها به پایگاه‌داده دیگر نگاشت شوند، یا پایگاه‌داده‌های هدف متفاوتی بر اساس DN درخواست انتخاب شوند و غیره.

امکان دیگر، نگاشت همان عملیات به پایگاه‌داده‌های مختلف بر اساس جزئیات بافت نام‌گذاری مجازی است، مانند گروه‌ها در یک پایگاه‌داده و اشخاص در پایگاه‌داده دیگر.

برای پیاده‌سازی یک نگاشت بافت نام‌گذاری مجازی ساده که به یک پایگاه‌داده واحد ارجاع می‌دهد، استفاده کنید از:

database                relay
suffix                  "dc=virtual,dc=naming,dc=context"
relay                   "dc=real,dc=naming,dc=context"
overlay                 rwm
rwm-suffixmassage       "dc=real,dc=naming,dc=context"

برای پیاده‌سازی یک نگاشت بافت نام‌گذاری مجازی ساده که بافت نام‌گذاری واقعی را برای هر عملیات جستجو می‌کند، استفاده کنید از:

database                relay
suffix                  "dc=virtual,dc=naming,dc=context"
overlay                 rwm
rwm-suffixmassage       "dc=real,dc=naming,dc=context"

این برای نمونه جهت بازپخش پایگاه‌داده‌های مختلفی که در بخش انتهایی بافت نام‌گذاری (بخشی که بازنویسی می‌شود) مشترک هستند، کاربرد دارد.

برای پیاده‌سازی suffixalias سنتی، مثلاً نگاشت بافت نام‌گذاری مجازی به واقعی، اما بدون بازگرداندن نتایج از بافت نام‌گذاری واقعی به مجازی، استفاده کنید از:

database                relay
suffix                  "dc=virtual,dc=naming,dc=context"
relay                   "dc=real,dc=naming,dc=context"
overlay                 rwm
rwm-rewriteEngine       on
rwm-rewriteContext      default
rwm-rewriteRule         "dc=virtual,dc=naming,dc=context"
                        "dc=real,dc=naming,dc=context" ":@"
rwm-rewriteContext      searchFilter
rwm-rewriteContext      searchEntryDN
rwm-rewriteContext      searchAttrDN
rwm-rewriteContext      matchedDN

توجه داشته باشید که لایه همپوشان slapo-rwm(5) نمونه‌سازی شده است، اما قوانین بازنویسی به جای اینکه مانند عبارت rwm-suffixmassage به‌طور خودکار باشند، به‌صراحت نوشته شده‌اند تا تمام جریان داده از بافت نام‌گذاری مجازی به واقعی نگاشت شود، اما هیچ داده‌ای از واقعی به مجازی برنگردد.

قوانین دسترسی:

database                mdb
suffix                  "dc=example,dc=com"
# skip...
access to dn.subtree="dc=example,dc=com"
        by dn.exact="cn=Supervisor,dc=example,dc=com" write
        by * read
database                relay
suffix                  "o=Example,c=US"
relay                   "dc=example,dc=com"
overlay                 rwm
rwm-suffixmassage       "dc=example,dc=com"
# skip ...
access to dn.subtree="o=Example,c=US"
        by dn.exact="cn=Supervisor,dc=example,dc=com" write
        by dn.exact="cn=Relay Supervisor,dc=example,dc=com" write
        by * read

توجه داشته باشید که در هر دو پایگاه‌داده، هویت‌ها (بند <who>) در بافت نام‌گذاری واقعی قرار دارند، یعنی `dc=example,dc=com'، در حالی که اهداف (بند <what>) به‌ترتیب در بافت‌های نام‌گذاری واقعی و مجازی می‌باشند.

بکاند relay از هیچ‌یک از مفاهیم کنترل دسترسی شرح داده‌شده در slapd.access(5) پیروی نمی‌کند؛ تمام کنترل دسترسی به پایگاه‌داده(های) بازپخش‌شده محول می‌شود. تنها دسترسی خواندن (=r) به شبه‌ویژگی entry و به مقادیر سایر ویژگی‌های ورودی‌های بازگردانده‌شده توسط عملیات search، که توسط فرانت‌اند انجام می‌شود، رعایت می‌گردد.

/etc/ldap/slapd.conf
فایل پیکربندی پیش‌فرض slapd

slapd.conf(5), slapd-config(5), slapo-rwm(5), slapd(8).

مه ۲۰۲۵ OpenLDAP