نام (NAME)

slapd-meta - بکاند متادایرکتوری برای slapd

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

/etc/openldap/slapd.conf

توضیحات (DESCRIPTION)

بکاند meta برای slapd(8) پروکسی کردن پایه‌ای LDAP را نسبت به مجموعه‌ای از سرورهای LDAP راه دور که «مقصدها» (targets) نامیده می‌شوند، انجام می‌دهد. اطلاعات موجود در این سرورها می‌تواند به گونه‌ای ارائه شود که گویی متعلق به یک درخت اطلاعات دایرکتوری (DIT) واحد هستند.

داشتن دانش پایه‌ای از قابلیت‌های بکاند slapd-ldap(5) توصیه می‌شود. این بکاند به عنوان بهبودی بر بکاند ldap طراحی شده است. این دو بکاند ویژگی‌های مشترک فراوانی دارند (در واقع بخش‌هایی از کد آن‌ها نیز مشترک است). در حالی که بکاند ldap برای پروکسی کردن عملیات هدایت‌شده به یک سرور واحد در نظر گرفته شده است، بکاند meta عمدتاً برای پروکسی کردن چندین سرور و احتمالاً نقاب‌گذاری بافت نام‌گذاری (naming context masquerading) کاربرد دارد. این ویژگی‌ها اگرچه در بسیاری از سناریوها مفید هستند، ممکن است برای برخی کاربردها منجر به سربار اضافی شوند؛ بنابراین استفاده از آن باید به دقت ارزیابی شود. در بخش مثال‌ها، برخی از سناریوهای معمول مورد بحث قرار خواهند گرفت.

نمونه پروکسی slapd(8) باید حاوی اطلاعات طرحواره (schema) برای ویژگی‌ها و کلاس‌های شیء (objectClasses) مورد استفاده در فیلترها، DNهای درخواست و به طور کلی داده‌های مرتبط با درخواست باشد. همچنین باید شامل اطلاعات طرحواره برای داده‌های بازگردانده‌شده توسط سرور پروکسی‌شده باشد. مسئولیت هماهنگ نگه‌داشتن طرحواره پروکسی با سرور پروکسی‌شده بر عهده مدیر پروکسی است.

نکته: هنگام ارجاع حلقه‌ای (looping back) به همان نمونه slapd(8)، هر اتصال به یک ریسه (thread) جدید نیاز دارد؛ در نتیجه، ممکن است پارامتر threads در slapd(8) نیاز به تنظیم دقیق داشته باشد. در این موارد، مگر اینکه ویژگی چندمقصدی مورد نیاز باشد، می‌توان از slapd-relay(5) استفاده کرد که عملیات بازپخش‌شده را به صورت داخلی انجام داده و بنابراین از همان اتصال مجدداً استفاده می‌کند.

مثال‌ها (EXAMPLES)

مثال‌هایی در بخش‌های مختلف این سند و همچنین در شاخه slapd/back-meta/data/ در درخت سورس‌کد OpenLDAP موجود است.

پیکربندی (CONFIGURATION)

این گزینه‌های slapd.conf برای پایگاه‌داده بکاند META اعمال می‌شوند. یعنی باید پس از خط "database meta" و پیش از هر خط بعدی "backend" یا "database" قرار گیرند. سایر گزینه‌های پایگاه‌داده در صفحه راهنمای slapd.conf(5) شرح داده شده‌اند.

نکته: در نسخه‌های اولیه back-ldap و back-meta توصیه می‌شد همیشه

lastmod  off

را برای پایگاه‌های داده ldap و meta تنظیم کنید. این امر به این دلیل لازم بود که ویژگی‌های عملیاتی مربوط به ایجاد و تغییر مدخل نباید پروکسی می‌شدند، زیرا ممکن بود اشتباهاً روی سرور(های) مقصد نوشته شوند و خطایی ایجاد کنند. پیاده‌سازی فعلی به طور خودکار lastmod را روی off قرار می‌دهد، بنابراین استفاده از آن زاید است و باید حذف شود.

دستورالعمل‌های پیکربندی ویژه (SPECIAL CONFIGURATION DIRECTIVES)

پیکربندی مقصدها با دستورالعمل "uri" آغاز می‌شود. تمام دستورالعمل‌های پیکربندی که مختص یک مقصد خاص نیستند باید برای شفافیت در ابتدا تعریف شوند، از جمله دستورالعمل‌هایی که برای همه بکاندها مشترک هستند. آن‌ها عبارتند از:

conn-pool-max <int>

این دستورالعمل حداکثر اندازه مخزن اتصالات ممتاز (privileged connections pool) را تعیین می‌کند.

conn-ttl <time>

این دستورالعمل باعث می‌شود که یک اتصال کَش‌شده پس از مدت‌زمان ttl مشخص‌شده، بدون توجه به اینکه بی‌کار (idle) بوده یا نه، قطع شده و مجدداً ایجاد شود.

default-target none

این دستورالعمل بکاند را ملزم می‌کند در صورتی که هیچ مقصدی یا چندین مقصد انتخاب شده باشند، تمام عملیاتی را که باید به یک مقصد واحد تفکیک شوند، رد کند. این عملیات شامل: add، delete، modify، modrdn است؛ عملیات compare و همچنین bind شامل این مورد نمی‌شوند، زیرا مدخل‌ها را تغییر نمی‌دهند و در صورت تطابق‌های متعدد، تلاشی برای انجام عملیات روی هر مقصد نامزد صورت می‌گیرد، با این شرط که حداکثر یکی از آن‌ها باید موفق شود. از این دستورالعمل می‌توان هنگام پردازش مقصدها نیز برای علامت‌گذاری یک مقصد خاص به عنوان پیش‌فرض استفاده کرد.

dncache-ttl {DISABLED|forever|<ttl>}

این دستورالعمل طول عمر (time-to-live) کَش DN را تنظیم می‌کند. این قابلیت مقصدی را که یک DN معین را نگهداری می‌کند کَش می‌کند تا انتخاب مقصد در مواردی که یک جستجوی بدون کَش منجر به چندین مقصد می‌شود، تسریع یابد؛ forever به این معنی است که کَش هرگز منقضی نمی‌شود؛ disabled به معنی عدم کَش کردن DN است؛ در غیر این صورت یک ttl معتبر (بزرگتر از صفر) در قالبی که برای دستورالعمل idle-timeout شرح داده شده، لازم است.

onerr {CONTINUE|report|stop}

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

norefs <NO|yes>

اگر yes باشد، پاسخ‌های ارجاع جستجو (search reference) را بازنمی‌گرداند. به‌طور پیش‌فرض، این پاسخ‌ها بازگردانده می‌شوند مگر اینکه درخواست از نوع LDAPv2 باشد. اگر پیش از هرگونه مشخصات مقصد تنظیم شود، بر همه مقصدها اثر می‌گذارد، مگر اینکه توسط یک دستورالعمل مختص هر مقصد بازنویسی شود.

noundeffilter <NO|yes>

اگر yes باشد، در صورتی که فیلتر تعریف‌نشده باشد یا شامل بخش‌های تعریف‌نشده باشد، به جای جستجو، وضعیت موفقیت بازگردانده می‌شود. به‌طور پیش‌فرض، جستجو پس از جایگزینی بخش‌های تعریف‌نشده با (!(objectClass=*)) که متناظر با مجموعه نتایج خالی است، انتشار می‌یابد. اگر پیش از هرگونه مشخصات مقصد تنظیم شود، بر همه مقصدها اثر می‌گذارد، مگر اینکه توسط یک دستورالعمل مختص هر مقصد بازنویسی شود.

protocol-version {0,2,3}

این دستورالعمل مشخص می‌کند که چه نسخه پروتکلی باید برای تماس با سرور راه دور استفاده شود. اگر روی 0 (پیش‌فرض) تنظیم شود، پروکسی از همان نسخه پروتکل استفاده‌شده توسط کلاینت استفاده می‌کند؛ در غیر این صورت از پروتکل درخواستی استفاده می‌شود. اگر عملیاتی ناسازگار با پروتکل درخواستی انجام شود، پروکسی خطای unwillingToPerform را بازمی‌گرداند. اگر پیش از هرگونه مشخصات مقصد تنظیم شود، بر همه مقصدها اثر می‌گذارد، مگر اینکه توسط یک دستورالعمل مختص هر مقصد بازنویسی شود.

pseudoroot-bind-defer {YES|no}

این دستورالعمل، هنگامی که روی yes تنظیم شود، باعث می‌شود احرازهویت با سرورهای راه دور با هویت ریشه کاذب (هویت تعریف‌شده در هر دستورالعمل idassert-bind) تا زمانی که واقعاً توسط عملیات بعدی مورد نیاز باشد، به تعویق بیفتد. در غیر این صورت، تمام Bindها با هویت rootdn به مقصدها منتشر می‌شوند.

quarantine <interval>,<num>[;<interval>,<num>[...]]

قرنطینه کردن URIهایی را که وضعیت LDAP_UNAVAILABLE بازگردانده‌اند فعال می‌کند، به طوری که تلاش برای اتصال مجدد فقط در فواصل زمانی مشخص رخ می‌دهد، نه هر باری که کلاینت درخواستی ارسال می‌کند. الگو به این صورت است: تلاش مجدد فقط پس از گذشت حداقل interval ثانیه از آخرین تلاش، دقیقاً به تعداد num بار؛ سپس از الگوی بعدی استفاده می‌شود. اگر مقدار num برای آخرین الگو برابر با «+» باشد، تلاش تا ابد ادامه می‌یابد؛ در غیر این صورت، دیگر تلاشی صورت نمی‌گیرد. این دستورالعمل باید پیش از هرگونه مشخصات مقصد قرار گیرد؛ این دستور با الگوی یکسان بر همه مقصدها اعمال می‌شود.

rebind-as-user {NO|yes}

در صورت تعیین این گزینه، مشخصات احرازهویت Bind کلاینت برای اتصال‌های مجدد، در هنگام تلاش برای برقراری مجدد اتصال قطع‌شده، یا هنگام دنبال کردن ارجاع (در صورتی که chase-referrals روی yes تنظیم شده باشد)، به خاطر سپرده می‌شود.

session-tracking-request {NO|yes}

کنترل ردیابی نشست (session tracking) را برای تمام درخواست‌ها اضافه می‌کند. نشانی IP و نام میزبان کلاینت، و هویت مرتبط با هر درخواست، در صورت مشخص بودن، برای مقاصد اطلاعاتی به سرور راه دور ارسال می‌شود. این دستورالعمل با تنظیم protocol-version روی 2 ناسازگار است. اگر پیش از هرگونه مشخصات مقصد تنظیم شود، بر همه مقصدها اثر می‌گذارد، مگر اینکه توسط دستورالعمل‌های مختص هر مقصد بازنویسی شود.

single-conn {NO|yes}

هنگامی که کلاینت مجدداً متصل (rebind) می‌شود، اتصال کَش‌شده فعلی را دور می‌اندازد.

use-temporary-conn {NO|yes}

هنگامی که روی yes تنظیم شود، هر زمان که رقابتی با سایر ریسه‌ها برای یک اتصال مشترک وجود داشته باشد، یک اتصال موقت ایجاد می‌کند؛ در غیر این صورت، تا زمان در دسترس قرار گرفتن اتصال مشترک منتظر می‌ماند.

مشخصات مقصد (TARGET SPECIFICATION)

مشخصات مقصد با دستورالعمل "uri" آغاز می‌شود:

uri <protocol>://[<host>]/<naming context> [...]

بخش <protocol> می‌تواند هر مقداری باشد که ldap_initialize(3) می‌پذیرد ({ldap|ldaps|ldapi} و اشکال مختلف آن)؛ بخش <host> را می‌توان حذف کرد که در این صورت پیش‌فرض آن هر چیزی خواهد بود که در ldap.conf(5) تنظیم شده است. بخش <naming context> برای اولین URI اجباری است، اما برای URIهای بعدی، در صورت وجود، باید حذف شود. بخش بافت نام‌گذاری باید در محدوده بافت نام‌گذاری تعریف‌شده برای بکاند باشد، به عنوان مثال:

suffix "dc=foo,dc=com"
uri    "ldap://x.foo.com/dc=x,dc=foo,dc=com"

suffix "dc=foo,dc=com"
uri    "ldap://l1.foo.com/dc=foo,dc=com" "ldap://l2.foo.com/"

acl-authcDN <administrative DN for access control purposes>

شناسه DN که برای ارسال پرس‌وجو به سرور مقصد جهت بررسی acl استفاده می‌شود، همانند بکاند LDAP؛ فرض بر این است که این شناسه در سرور مقصد دسترسی خواندن به ویژگی‌های مورد استفاده در پروکسی برای بررسی acl را دارد. هیچ خطری در افشای چنین مقادیری وجود ندارد؛ آن‌ها فقط برای بررسی مجوزها استفاده می‌شوند. هویت acl-authcDN به هیچ وجه زمانی که کلاینت به صورت ناشناس متصل می‌شود، به صورت ضمنی توسط پروکسی استفاده نمی‌شود.

acl-passwd <password>

گذرواژه مورد استفاده همراه با acl-authcDN فوق.

bind-timeout <microseconds>

این دستورالعمل مهلت زمانی (timeout) برحسب میکروثانیه را تعریف می‌کند که هنگام نظرسنجی (polling) برای پاسخ پس از یک اتصال ناهمگام bind استفاده می‌شود. فراخوانی اولیه به ldap_result(3) با مهلت زمانی مصالحه‌ای ۱۰۰۰۰۰ میکروثانیه انجام می‌شود؛ اگر این فراخوانی منجر به اتمام مهلت زمانی شود، فراخوانی‌های بعدی از مقدار ارائه‌شده در bind-timeout استفاده می‌کنند. در صورتی که bind-timeout مشخص نشده باشد، مقدار پیش‌فرض برای فراخوانی‌های بعدی نیز استفاده می‌شود. اگر پیش از هرگونه مشخصات مقصد تنظیم شود، بر همه مقصدها اثر می‌گذارد، مگر اینکه توسط یک دستورالعمل مختص هر مقصد بازنویسی شود.

chase-referrals {YES|no}

فعال/غیرفعال کردن دنبال کردن خودکار ارجاعات، که به کتابخانه libldap زیرین واگذار می‌شود و در صورت استفاده از دستورالعمل rebind-as-user، اتصال مجدد (rebind) در نهایت انجام می‌گیرد. حالت پیش‌فرض، دنبال کردن ارجاعات است. اگر پیش از هرگونه مشخصات مقصد تنظیم شود، بر همه مقصدها اثر می‌گذارد، مگر اینکه توسط یک دستورالعمل مختص هر مقصد بازنویسی شود.

client-pr {accept-unsolicited|DISABLE|<size>}

این ویژگی امکان استفاده از کنترل نتایج صفحه‌بندی‌شده (Paged Results control) طبق RFC 2696 را هنگام انجام عملیات جستجو با یک مقصد مشخص، صرف‌نظر از درخواست کلاینت فراهم می‌کند. هنگامی که روی یک مقدار عددی تنظیم شود، کنترل نتایج صفحه‌بندی‌شده همیشه با size به عنوان اندازه صفحه استفاده می‌شود. هنگامی که روی accept-unsolicited تنظیم شود، پاسخ‌های ناخواسته کنترل نتایج صفحه‌بندی‌شده برای سازگاری با DSAهای راه دور معیوب پذیرفته شده و رعایت می‌شوند. کلاینت در معرض مدیریت نتایج صفحه‌بندی‌شده بین slapd-meta(5) و سرورهای راه دور قرار نمی‌گیرد. به‌طور پیش‌فرض (غیرفعال)، از کنترل نتایج صفحه‌بندی‌شده استفاده نمی‌شود و پاسخ‌ها پذیرفته نمی‌شوند. اگر پیش از هرگونه مشخصات مقصد تنظیم شود، بر همه مقصدها اثر می‌گذارد، مگر اینکه توسط یک دستورالعمل مختص هر مقصد بازنویسی شود.

default-target [<target>]

دستورالعمل "default-target" را می‌توان در طول مشخصات مقصد نیز استفاده کرد. بدون آرگومان، مقصد فعلی را به عنوان پیش‌فرض علامت‌گذاری می‌کند. شماره اختیاری، مقصد <target> را به عنوان پیش‌فرض مشخص می‌کند که از 1 شروع می‌شود. مقصد <target> باید تعریف شده باشد.

filter <pattern>

این دستورالعمل امکان تعیین یک الگوی regex(5) را فراهم می‌کند تا نشان دهد چه عبارات فیلتر جستجویی واقعاً توسط یک مقصد ارائه می‌شوند.

در یک درخواست جستجو، اگر فیلتر جستجو با pattern مطابقت داشته باشد، هنگام انجام درخواست، مقصد مد نظر قرار می‌گیرد؛ در غیر این صورت مقصد نادیده گرفته می‌شود. ممکن است چندین نمونه از دستورالعمل filter برای هر مقصد وجود داشته باشد.

idassert-authzFrom <authz-regexp>

در صورت تعریف، انتخاب می‌کند که کدام هویت‌های محلی مجاز به بهره‌برداری از ویژگی اثبات هویت (identity assertion) هستند. رشته <authz-regexp> از قواعد تعریف‌شده برای ویژگی authzFrom پیروی می‌کند. برای جزئیات درباره نحو این فیلد، به slapd.conf(5)، بخش مربوط به authz-policy مراجعه کنید.

idassert-bind bindmethod=none|simple|sasl [binddn=<simple DN>] [credentials=<simple password>] [saslmech=<SASL mech>] [secprops=<properties>] [realm=<realm>] [authcId=<authentication ID>] [authzId=<authorization ID>] [authz={native|proxyauthz}] [mode=<mode>] [flags=<flags>] [starttls=no|yes|critical] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_reqsan=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_ecname=<ciphers>] [tls_protocol_min=<major>[.<minor>]] [tls_crlcheck=none|peer|all]

idle-timeout <time>

این دستورالعمل باعث می‌شود که یک اتصال کَش‌شده پس از اینکه برای مدت‌زمان مشخص‌شده بی‌کار (idle) ماند، قطع شده و مجدداً ایجاد شود. مقدار را می‌توان به صورت زیر تعیین کرد:

[<d>d][<h>h][<m>m][<s>[s]]

که در آن <d>، <h>، <m> و <s> به ترتیب به عنوان روز، ساعت، دقیقه و ثانیه در نظر گرفته می‌شوند. اگر پیش از هرگونه مشخصات مقصد تنظیم شود، بر همه مقصدها اثر می‌گذارد، مگر اینکه توسط یک دستورالعمل مختص هر مقصد بازنویسی شود.

keepalive <idle>:<probes>:<interval>

پارامتر keepalive مقادیر idle، probes و interval را تنظیم می‌کند که برای بررسی زنده بودن سوکت استفاده می‌شوند؛ idle تعداد ثانیه‌هایی است که اتصال باید پیش از شروع ارسال کاوش‌های زنده ماندن (keepalive probes) توسط TCP بی‌کار بماند؛ probes حداکثر تعداد کاوش‌های زنده ماندن است که TCP باید پیش از قطع اتصال ارسال کند؛ interval فاصله زمانی برحسب ثانیه بین هر کاوش زنده ماندن است. فقط برخی سیستم‌ها از سفارشی‌سازی این مقادیر پشتیبانی می‌کنند؛ در غیر این صورت پارامتر keepalive نادیده گرفته می‌شود و از تنظیمات سراسری سیستم استفاده می‌شود.

tcp-user-timeout <milliseconds>

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

map {attribute|objectclass} [<local name>|*] {<foreign name>|*}

کلاس‌های شیء و ویژگی‌ها را همانند بکاند LDAP نگاشت می‌کند. به slapd-ldap(5) مراجعه کنید.

network-timeout <time>

مقدار مهلت زمانی شبکه را تعیین می‌کند که پس از آن poll(2)/select(2) پس از یک connect(2) در صورت عدم فعالیت بازمی‌گردد. مقدار برحسب ثانیه است و می‌تواند همانند idle-timeout مشخص شود. اگر پیش از هرگونه مشخصات مقصد تنظیم شود، بر همه مقصدها اثر می‌گذارد، مگر اینکه توسط یک دستورالعمل مختص هر مقصد بازنویسی شود.

nretries {forever|never|<nretries>}

این دستورالعمل تعیین می‌کند که در صورت بروز خطای موقت در تماس با یک مقصد، عملیات bind چند بار باید دوباره تلاش شود. اگر پیش از هرگونه مشخصات مقصد تعریف شود، برای تمام مقصدها اعمال می‌شود (به‌طور پیش‌فرض، 3 بار)؛ مقدار سراسری را می‌توان با تعریف مجدد در داخل مشخصات هر مقصد بازنویسی کرد.

rewrite* ...

گزینه‌های بازنویسی در بخش «بازنویسی (REWRITING)» شرح داده شده‌اند.

subtree-{exclude|include} <rule>

این دستورالعمل به شخص امکان می‌دهد مشخص کند چه زیردرخت‌هایی (subtrees) واقعاً توسط یک مقصد ارائه می‌شوند. نحو قواعد پشتیبانی‌شده به صورت زیر است:

<rule>: [dn[.<style>]:]<pattern>

<style>: subtree|children|regex

هنگامی که <style> برابر با subtree یا children باشد، <pattern> یک DN است که باید در محدوده بافت نام‌گذاری ارائه‌شده توسط مقصد باشد. هنگامی که <style> برابر با regex باشد، <pattern> یک الگوی regex(5) است. اگر پیشوند dn.<style>: حذف شود، برای سازگاری با گذشته به‌طور ضمنی dn.subtree: فرض می‌شود.

در شکل subtree-exclude اگر request DN حداقل با یک قانون مطابقت داشته باشد، مقصد هنگام انجام درخواست در نظر گرفته نمی‌شود؛ در غیر این صورت، مقصد بر اساس مقدار request DN در نظر گرفته می‌شود. هنگامی که درخواست یک جستجو باشد، scope (محدوده) نیز در نظر گرفته می‌شود.

در شکل subtree-include اگر request DN حداقل با یک قانون مطابقت داشته باشد، مقصد هنگام انجام درخواست در نظر گرفته می‌شود؛ در غیر این صورت مقصد نادیده گرفته می‌شود.

|  match  | exclude |
+---------+---------+-------------------+
|    T    |    T    | not candidate     |
|    F    |    T    | continue checking |
+---------+---------+-------------------+
|    T    |    F    | candidate         |
|    F    |    F    | not candidate     |
+---------+---------+-------------------+

suffixmassage <virtual naming context> <real naming context>

تمام دستورالعمل‌هایی که با "rewrite" شروع می‌شوند به موتور بازنویسی که به slapd اضافه شده است اشاره دارند. دستورالعمل "suffixmassage" در بکاند LDAP برای امکان‌پذیر ساختن اصلاح پسوند (suffix massaging) هنگام پروکسی معرفی شد. این دستورالعمل توسط ابزارهای بازنویسی منسوخ شده است. با این حال، هم برای سازگاری با گذشته و هم برای سهولت در پیکربندی زمانی که به یک اصلاح پسوند ساده نیاز است، حفظ شده است. این دستورالعمل دستورات بازنویسی پایه‌ای را که اصلاح پسوند را انجام می‌دهند در بر می‌گیرد. برای لیست دقیق قوانین بازنویسی که این دستورالعمل ایجاد می‌کند، بخش «بازنویسی (REWRITING)» را ببینید.

t-f-support {NO|yes|discover}

در صورتی که سرور راه دور از فیلترهای مطلق (absolute filters) پشتیبانی می‌کند، این گزینه را فعال کنید (برای جزئیات به RFC 4526 مراجعه کنید). اگر روی discover تنظیم شود، این پشتیبانی با خواندن DSE ریشه سرور راه دور شناسایی می‌شود. اگر پیش از هرگونه مشخصات مقصد تنظیم شود، بر همه مقصدها اثر می‌گذارد، مگر اینکه توسط یک دستورالعمل مختص هر مقصد بازنویسی شود.

timeout [<op>=]<val> [...]

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

<op> ::= bind, add, delete, modrdn, modify, compare, search

مدت‌زمان کلی عملیات search یا با پارامتر timelimit یا با محدودیت‌های زمانی اعمال‌شده از سمت سرور کنترل می‌شود (برای جزئیات به timelimit و limits در slapd.conf(5) مراجعه کنید). این پارامتر timeout کنترل می‌کند که مقصد چه مدت می‌تواند قبل از لغو عملیات بی‌پاسخ بماند. مهلت زمانی برای سایر عملیات، یعنی unbind و abandon که هیچ پاسخی در بر ندارند، بی‌معنی است، در حالی که در عملیات extended که در حال حاضر پشتیبانی می‌شوند هنوز پیاده‌سازی نشده است. اگر هیچ عملیاتی مشخص نشود، مقدار مهلت زمانی val بر تمام عملیات پشتیبانی‌شده اعمال می‌شود. اگر پیش از هرگونه تعریف مقصد مشخص شود، بر تمام مقصدها اعمال می‌شود مگر اینکه توسط دستورالعمل‌های مختص هر مقصد بازنویسی شود.

نکته: اگر مهلت زمانی به پایان برسد، عملیات لغو می‌شود (طبق دستورالعمل cancel)؛ پروتکل هیچ ابزاری برای بازگرداندن (rollback) عملیات فراهم نمی‌کند، بنابراین کلاینت از نتیجه عملیات که ممکن است در نهایت موفق شده باشد یا نه، مطلع نخواهد شد. در صورتی که مهلت زمانی در حین عملیات bind سپری شود، اتصال طبق RFC4511 نابود می‌شود.

tls {none|[try-]start|[try-]propagate|ldaps}

[starttls=no] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_reqsan=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_ecname=<names>] [tls_crlcheck=none|peer|all]

سناریوها (SCENARIOS)

یک موتور بازنویسی قدرتمند (و به نوعی خطرناک) به هر دو بکاند LDAP و Meta اضافه شده است. در حالی که بکاند اول می‌تواند اثرات مفید محدودی از بازنویسی موارد به دست آورد، بکاند دوم می‌تواند به ابزاری شگفت‌آور و قدرتمند تبدیل شود.

ابتدا دو سناریو را در نظر بگیرید.

۱) دو سرور دایرکتوری در دو سطح از بافت نام‌گذاری مشترک هستند؛ برای مثال "dc=a,dc=foo,dc=com" و "dc=b,dc=foo,dc=com". در این حالت، یک پایگاه‌داده بدون ابهام Meta را می‌توان به این صورت پیکربندی کرد:

database meta
suffix   "dc=foo,dc=com"
uri      "ldap://a.foo.com/dc=a,dc=foo,dc=com"
uri      "ldap://b.foo.com/dc=b,dc=foo,dc=com"

عملیات هدایت‌شده به یک مقصد خاص را می‌توان به راحتی تفکیک کرد زیرا هیچ ابهامی وجود ندارد. تنها عملیاتی که ممکن است به چندین مقصد تفکیک شود، یک جستجو با پایه "dc=foo,dc=com" و محدوده حداقل "one" است که منجر به ایجاد دو جستجو به مقصدها می‌شود.

۲-الف) دو سرور دایرکتوری در هیچ بخشی از بافت نام‌گذاری مشترک نیستند، اما قرار است به عنوان یک DIT واحد ارائه شوند [هشدار: یکتا بودن مدخل‌های (اصلاح‌شده) بین دو سرور فرض شده است؛ بررسی‌های یکپارچگی خطر ایجاد سربار اضافی دارند و پیاده‌سازی نشده‌اند]. فرض کنید "dc=bar,dc=org" و "o=Foo,c=US" را داریم، و می‌خواهیم آن‌ها به عنوان شاخه‌هایی از "dc=foo,dc=com" ظاهر شوند، مثلاً "dc=a,dc=foo,dc=com" و "dc=b,dc=foo,dc=com". سپس باید بکاند Meta خود را به صورت زیر پیکربندی کنیم:

database      meta
suffix        "dc=foo,dc=com"
uri           "ldap://a.bar.com/dc=a,dc=foo,dc=com"
suffixmassage "dc=a,dc=foo,dc=com" "dc=bar,dc=org"
uri           "ldap://b.foo.com/dc=b,dc=foo,dc=com"
suffixmassage "dc=b,dc=foo,dc=com" "o=Foo,c=US"

مجدداً، عملیات را می‌توان بدون ابهام تفکیک کرد، اگرچه به مقداری بازنویسی نیاز است. توجه داشته باشید که بافت نام‌گذاری مجازی هر مقصد شاخه‌ای از بافت نام‌گذاری پایگاه‌داده است؛ این بافت هنگام انجام عملیات به سمت سرورهای مقصد به صورت رفت و برگشت بازنویسی می‌شود. منظور از «رفت و برگشت» بعداً روشن خواهد شد.

هنگامی که جستجویی با پایه "dc=foo,dc=com" انجام شود، اگر محدوده "base" باشد با خطای "no such object" با شکست مواجه می‌شود؛ در واقع، ریشه مشترک دو مقصد (پیش از اصلاح) وجود ندارد. اگر محدوده "one" باشد، با هر دو مقصد تماس گرفته می‌شود و پایه جستجو با پایه هر مقصد جایگزین می‌شود؛ محدوده به "base" تقلیل می‌یابد. به‌طور کلی، جستجو با محدوده "one" رعایت می‌شود و محدوده تقلیل می‌یابد، تنها زمانی که پایه ورودی حداکثر یک سطح پایین‌تر از بافت نام‌گذاری یک مقصد (پیش از اصلاح) باشد.

در نهایت، اگر محدوده "sub" باشد، پایه ورودی با بافت نام‌گذاری اصلاح‌نشده هر مقصد جایگزین می‌شود و محدوده تغییر نمی‌کند.

۲-ب) سناریوی گزارش‌شده در بالا را با دو سروری که بافت نام‌گذاری یکسانی دارند در نظر بگیرید:

database      meta
suffix        "dc=foo,dc=com"
uri           "ldap://a.bar.com/dc=foo,dc=com"
suffixmassage "dc=foo,dc=com" "dc=bar,dc=org"
uri           "ldap://b.foo.com/dc=foo,dc=com"
suffixmassage "dc=foo,dc=com" "o=Foo,c=US"

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

لیست‌های کنترل دسترسی (ACLs)

نکته در مورد ACLها: در حال حاضر شما می‌توانید هر قانون ACL که مایلید به بکاندهای Meta (و LDAP) اضافه کنید. با این حال، مفهوم یک ACL روی یک پروکسی ممکن است نیازمند برخی ملاحظات باشد. دو دیدگاه را می‌توان در نظر گرفت:

الف) سرور راه دور مجوزها را تعیین می‌کند؛ پروکسی صرفاً آنچه را که از سرور راه دور دریافت می‌کند بازمی‌گرداند.

ب) سرور راه دور «همه چیز» را آشکار می‌کند؛ پروکسی مسئول محافظت از داده‌ها در برابر دسترسی‌های غیرمجاز است.

البته دومی نامعقول به نظر می‌رسد، اما این‌طور نیست. می‌توان سناریوهایی را تصور کرد که در آن یک میزبان راه دور داده‌هایی را که در داخل یک اینترانت «عمومی» تلقی می‌شوند افشا می‌کند، و پروکسی‌ای که آن را به اینترنت متصل می‌کند ممکن است محدودیت‌های بیشتری اعمال کند. به این منظور، پروکسی باید بتواند با تمام معیارهای تطبیق ACL که سرور پشتیبانی می‌کند، مطابقت داشته باشد. این امر با توجه به تمام معیارهای پشتیبانی‌شده توسط slapd به جز یک حالت خاص و ظریف محقق شده است (لطفاً اگر استثناهای دیگری پیدا کردید، یک گزارش در سامانه پیگیری خطا ثبت کنید: http://www.openldap.org/its). قانون

access to dn="<dn>" attrs=<attr>
       by dnattr=<dnattr> read
       by * none

نمی‌تواند تطبیق یابد اگر و تنها اگر ویژگی درخواستی، <attr>، ویژگی <dnattr> نباشد و ویژگی تعیین‌کننده عضویت، <dnattr>، درخواست نشده باشد (مثلاً در یک جستجو).

در واقع این ACL توسط slapd با استفاده از بخشی از مدخل که از سرور راه دور بازیابی کرده و بدون نیاز به دخالت بیشتر بکاند تفکیک می‌شود، بنابراین اگر ویژگی <dnattr> واکشی نشده باشد، تطبیق را نمی‌توان ارزیابی کرد زیرا ویژگی موجود نیست، نه به این دلیل که مقداری با شرط مطابقت ندارد!

نکته درباره ACLها و نگاشت ویژگی‌ها: ACLها روی ویژگی‌های نگاشت‌شده اعمال می‌شوند؛ به عنوان مثال، اگر ویژگی‌ای که به صورت محلی "foo" نامیده می‌شود به "bar" در سرور راه دور نگاشت شده باشد، ACLهای محلی روی ویژگی "foo" اعمال می‌شوند و کاملاً از نام راه دور آن بی‌خبر هستند. سرور راه دور مجوزها را برای "bar" بررسی می‌کند و سرور محلی احتمالاً محدودیت‌های بیشتری را برای "foo" اعمال خواهد کرد.

بازنویسی (REWRITING)

یک رشته بر اساس مجموعه‌ای از قوانین به نام «زمینه بازنویسی» (rewrite context) بازنویسی می‌شود. قوانین بر پایه عبارات باقاعده POSIX («توسعه‌یافته» یا extended) با تطبیق زیررشته (substring matching) هستند؛ جایگزینی متغیرهای پایه‌ای و تفکیک نگاشت زیررشته‌ها توسط سازوکارهای خاصی که در ادامه شرح داده شده‌اند، امکان‌پذیر است. رفتار تطبیق الگو/جایگزینی را می‌توان با مجموعه‌ای از پرچم‌ها تغییر داد.

مفهوم زیربنایی، ساخت یک ماژول بازنویسی سبک‌وزن برای سرور slapd است (که در ابتدا به بکاند LDAP اختصاص داشت).

مراحل گذر (Passes)

یک رشته ورودی با مجموعه‌ای از قوانین تطبیق داده می‌شود. قوانین از یک الگوی تطبیق regex، یک الگوی جایگزینی و مجموعه‌ای از اقدامات که توسط مجموعه‌ای از پرچم‌ها توصیف می‌شوند، تشکیل شده‌اند. در صورت تطابق، بازنویسی رشته بر اساس الگوی جایگزینی انجام می‌شود که امکان ارجاع به زیررشته‌های منطبق در رشته ورودی را فراهم می‌کند. اقدامات (در صورت وجود) در نهایت اجرا می‌شوند. الگوی جایگزینی امکان تفکیک نگاشت (map resolution) زیررشته‌ها را فراهم می‌کند. یک نگاشت (map) شیئی عمومی است که یک الگوی جایگزینی را به یک مقدار نگاشت می‌کند. پرچم‌ها به دو دسته «پرچم‌های تطبیق الگو» و «پرچم‌های اقدام» تقسیم می‌شوند؛ دسته اول رفتار الگوی تطبیق regex را تغییر می‌دهند، در حالی که دسته دوم اقدامی را که پس از جایگزینی انجام می‌شود تغییر می‌دهند.

پرچم‌های تطبیق الگو (Pattern Matching Flags)

`C'

حساسیت به بزرگ و کوچکی حروف را در تطبیق رعایت می‌کند (پیش‌فرض، عدم حساسیت به حروف است).

`R'

از عبارات باقاعده «پایه‌ای» (basic) در POSIX استفاده می‌کند (پیش‌فرض «توسعه‌یافته» یا extended است).

`M{n}'

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

پرچم‌های اقدام (Action Flags)

`:'

قانون را فقط یک‌بار اعمال می‌کند (پیش‌فرض، بازگشتی است).

`@'

در صورت تطابق، اعمال قوانین را متوقف می‌کند؛ قانون فعلی همچنان به صورت بازگشتی اعمال می‌شود؛ برای اعمال قانون فعلی تنها برای یک‌بار و سپس توقف، با `:' ترکیب کنید.

`#'

در صورت تطابق قانون، عملیات فعلی را متوقف کرده و خطای `unwilling to perform' صادر می‌کند.

`G{n}'

تعداد n قانون به جلو یا عقب پرش می‌کند (مراقب حلقه‌ها باشید!). توجه داشته باشید که `G{1}' در هر قانون ضمنی است.

`I'

خطاها را در قانون نادیده می‌گیرد؛ به این معنی که در صورت بروز خطا، مثلاً خطایی که توسط یک نگاشت صادر شده، خطا به عنوان عدم تطابق تلقی می‌شود. خطای `unwilling to perform' نادیده گرفته نمی‌شود.

`U{n}'

در صورت تطابق قانون، از n به عنوان کد بازگشتی استفاده می‌کند؛ این پرچم رفتار بازگشتی قانون را تغییر نمی‌دهد، بنابراین برای اینکه فقط یک‌بار اجرا شود، باید در ترکیب با `:' استفاده شود، مثلاً `:U{16}' در صورت تطابق الگو، مقدار `16' را پس از دقیقاً یک‌بار اجرای قانون برمی‌گرداند. در نتیجه، رفتار آن معادل `@' است که کد بازگشتی آن روی n تنظیم شده باشد؛ یا به عبارت دیگر، `@' معادل `U{0}' است. طبق قرارداد، کدهای آزادانه در دسترس، بالای ۱۶ (شامل ۱۶) هستند؛ بقیه رزرو شده‌اند.

ترتیب پرچم‌ها می‌تواند حائز اهمیت باشد. برای نمونه: `IG{2}' به معنای نادیده گرفتن خطاها و پرش دو خط به جلو، هم در صورت تطابق و هم در صورت بروز خطا است، در حالی که `G{2}I' به معنای نادیده گرفتن خطاها، اما پرش دو خط به جلو تنها در صورت تطابق است.

پرچم‌های بیشتری (عمدتاً پرچم‌های اقدام) در صورت نیاز اضافه خواهند شد.

تطبیق الگو (Pattern matching):

به regex(7) و/یا re_format(7) مراجعه کنید.

نحو الگوی جایگزینی (Substitution Pattern Syntax):

هر چیزی که با `%' شروع شود نیاز به جایگزینی دارد؛

تنها استثنای واضح `%%' است که دست‌نخورده باقی می‌ماند؛

جایگزینی پایه‌ای به صورت `%d' است که `d' یک رقم است؛ 0 به معنای کل رشته است، در حالی که 1-9 یک زیرتطابق (submatch) است؛

یک `%' که به دنبال آن `{' بیاید، جایگزینی پیشرفته را فراخوانی می‌کند. الگو به صورت زیر است:

که در آن <name> باید یک نام مجاز برای نگاشت باشد، یعنی:

<name> ::= [a-z][a-z0-9]* (case insensitive)
<op> ::= `>' `|' `&' `&&' `*' `**' `$'

و <substitution> باید یک الگوی جایگزینی مجاز باشد، بدون محدودیت در سطح تو در تو بودن.

عملگرها عبارتند از:

>

فراخوانی زیرزمینه (sub context)؛ <name> باید یک نام زمینه بازنویسی مجاز و از پیش تعریف‌شده باشد.

|

فراخوانی فرمان خارجی؛ <name> باید به یک نام فرمان مجاز و از پیش تعریف‌شده اشاره کند (پیاده‌سازی نشده است).

&

انتساب متغیر؛ <name> متغیری را در ساختار عملیات در حال اجرا تعریف می‌کند که بعداً می‌تواند ارجاع‌زدایی شود؛ عملگر & یک متغیر را در محدوده زمینه بازنویسی منتسب می‌کند؛ عملگر && متغیری را منتسب می‌کند که کل نشست را در بر می‌گیرد، مثلاً مقدار آن بعداً توسط سایر زمینه‌های بازنویسی قابل ارجاع‌زدایی است.

*

ارجاع‌زدایی متغیر؛ <name> باید به متغیری اشاره کند که برای عملیات در حال اجرا تعریف و مقداردهی شده است؛ عملگر * یک متغیر در محدوده زمینه بازنویسی را ارجاع‌زدایی می‌کند؛ عملگر ** متغیری را که کل نشست را در بر می‌گیرد ارجاع‌زدایی می‌کند، یعنی مقدار در طول زمینه‌های بازنویسی منتقل می‌شود.

$

ارجاع‌زدایی پارامتر؛ <name> باید به یک پارامتر موجود اشاره کند؛ ایده این است که برخی پارامترهای زمان اجرا که توسط سیستم تنظیم شده‌اند در دسترس موتور بازنویسی قرار گیرند، مانند نام میزبان کلاینت، DN اتصال (در صورت وجود)، پارامترهای ثابت مقداردهی‌شده در زمان پیکربندی و غیره؛ در حال حاضر هیچ پارامتری توسط back-ldap یا back-meta تنظیم نشده است، اما می‌توان پارامترهای ثابتی را در فایل پیکربندی با استفاده از دستورالعمل rewriteParam تعریف کرد.

گریز دادن جایگزینی به نماد `%' واگذار شده است، که به جای `\' در الگوهای جایگزینی رشته استفاده می‌شود، زیرا `\' قبلاً توسط روال‌های تجزیه سطح پایین slapd گریز داده می‌شود؛ در نتیجه، گریز دادن regex نیازمند دو نماد `\' است، مثلاً `.*\.foo\.bar' باید به صورت `.*\\.foo\\.bar' نوشته شود.

زمینه بازنویسی (Rewrite context):

یک زمینه بازنویسی مجموعه‌ای از قوانین است که به ترتیب اعمال می‌شوند. ایده اصلی این است که یک برنامه یک موتور بازنویسی (مانند mod_rewrite در آپاچی ...) را با مجموعه‌ای از زمینه‌های بازنویسی مقداردهی اولیه کند؛ هنگامی که بازنویسی رشته لازم است، زمینه بازنویسی مناسب را با رشته ورودی فراخوانی کرده و در صورت عدم بروز خطا، رشته بازنویسی‌شده جدید را به دست می‌آورد.

هر عملیات پایه‌ای سرور با یک زمینه بازنویسی مرتبط است؛ آن‌ها به دو گروه اصلی تقسیم می‌شوند: بازنویسی کلاینت -> سرور و سرور -> کلاینت.

کلاینت -> سرور:

(default)            if defined and no specific context 
                     is available
bindDN               bind
searchBase           search
searchFilter         search
searchFilterAttrDN   search
compareDN            compare
compareAttrDN        compare AVA
addDN                add
addAttrDN            add AVA
modifyDN             modify
modifyAttrDN         modify AVA
modrDN               modrdn
newSuperiorDN        modrdn
deleteDN             delete
exopPasswdDN         password modify extended operation DN if proxy

سرور -> کلاینت:

searchResult         search (only if defined; no default;
                     acts on DN and DN-syntax attributes 
                     of search results)
searchAttrDN         search AVA
matchedDN            all ops (only if applicable)

نحو پیکربندی پایه‌ای (Basic configuration syntax)

rewriteEngine { on | off }

اگر `on' باشد، بازنویسی درخواستی انجام می‌شود؛ اگر `off' باشد، هیچ بازنویسی صورت نمی‌گیرد (روشی آسان برای متوقف کردن بازنویسی بدون دستکاری زیاد در فایل پیکربندی).

rewriteContext <context name> [ alias <aliased context name> ]

<Context name> نامی است که زمینه را مشخص می‌کند، یعنی نامی که برنامه برای ارجاع به مجموعه قوانین موجود در آن استفاده می‌کند. همچنین برای ارجاع به زیرزمینه‌ها در بازنویسی رشته استفاده می‌شود. یک زمینه می‌تواند نام مستعاری (alias) برای زمینه دیگری باشد. در این حالت زمینه مستعار هیچ قانونی ندارد و هرگونه ارجاع به آن منجر به دسترسی به زمینه اصلی خواهد شد.

rewriteRule <regex match pattern> <substitution pattern> [ <flags> ]

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

نحو پیکربندی تکمیلی (Additional configuration syntax):

rewriteMap <map type> <map name> [ <map attrs> ]

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

rewriteParam <param name> <param value>

مقداری را با محدوده سراسری تنظیم می‌کند که می‌تواند با دستور `%{$paramName}' ارجاع‌زدایی شود.

rewriteMaxPasses <number of passes> [<number of passes per rule>]

حداکثر تعداد کل گذرهای بازنویسی را که می‌تواند در یک عملیات بازنویسی واحد انجام شود تنظیم می‌کند (برای جلوگیری از حلقه‌ها). یک مقدار پیش‌فرض امن روی 100 تنظیم شده است؛ توجه داشته باشید که رسیدن به این محدودیت همچنان به عنوان موفقیت تلقی می‌شود؛ فراخوانی بازگشتی قوانین صرفاً قطع می‌شود. این شمارش برای کل عملیات بازنویسی اعمال می‌شود، نه برای یک قانون منفرد؛ می‌توان یک محدودیت اختیاری برای هر قانون نیز تنظیم کرد. این محدودیت با تنظیم محدودیت‌های خاص برای هر قانون توسط پرچم `M{n}' نادیده گرفته می‌شود.

مثال‌های پیکربندی (Configuration examples):

# برای غیرفعال‌کردن بازنویسی روی `off' قرار دهید
rewriteEngine on
# قوانینی که دستورالعمل "suffixmassage" اعمال می‌کند
rewriteEngine on
# تمام جریان داده از کلاینت به سرور با ارجاع به DNها
rewriteContext default
rewriteRule "(.*)<virtualnamingcontext>$" "%1<realnamingcontext>" ":"
# قانون فیلتر خالی
rewriteContext searchFilter
# تمام جریان داده از سرور به کلاینت
rewriteContext searchResult
rewriteRule "(.*)<realnamingcontext>$" "%1<virtualnamingcontext>" ":"
rewriteContext searchAttrDN alias searchResult
rewriteContext matchedDN alias searchResult
# هر آنچه در اینجا تعریف شود به زمینه `default' می‌رود.
# این قانون بافت نام‌گذاری هر آنچه را که به `dc=home,dc=net'
# ارسال شده به `dc=OpenLDAP, dc=org' تغییر می‌دهد
rewriteRule "(.*)dc=home,[ ]?dc=net"
            "%1dc=OpenLDAP, dc=org"  ":"
# از آنجا که یک DN نرمال‌شده/مرتب شامل فاصله پس از جداکننده‌های rdn
# مانند `,' نیست، این قانون کفایت می‌کند:
rewriteRule "(.*)dc=home,dc=net"
            "%1dc=OpenLDAP,dc=org"  ":"
# شروع یک زمینه جدید (پایان ورودی زمینه قبلی).
# این قانون در صورت نبود فاصله بین بخش‌های DN، فاصله اضافه می‌کند.
rewriteContext  addBlanks
rewriteRule     "(.*),([^ ].*)" "%1, %2"
# این قانون فاصله‌ها را حذف می‌کند
rewriteContext  eatBlanks
rewriteRule     "(.*),[ ](.*)" "%1,%2"
# در اینجا کنترل به زمینه بازنویسی پیش‌فرض برمی‌گردد؛
# قوانین به قوانین موجود الحاق می‌شوند.
# هر چیزی که به اینجا برسد به قانون `addBlanks' هدایت می‌شود
rewriteContext  default
rewriteRule     ".*" "%{>addBlanks(%0)}" ":"
# بازنویسی پایه جستجو طبق قوانین `default'.
rewriteContext  searchBase alias default
# نتایج جستجو با DN سرور OpenLDAP با بافت نام‌گذاری
# `dc=home,dc=net' و با حذف فاصله‌ها بازنویسی می‌شوند.
rewriteContext  searchResult
rewriteRule     "(.*[^ ]?)[ ]?dc=OpenLDAP,[ ]?dc=org"
                "%{>eatBlanks(%1)}dc=home,dc=net"    ":"
# اتصال با ایمیل به جای DN کامل: ابتدا به یک نگاشت ldap
# نیاز داریم که ویژگی‌ها را به یک DN تبدیل کند (آرگومان مورد استفاده
# هنگام فراخوانی نگاشت به URI الحاق شده و به عنوان بخش فیلتر عمل می‌کند)
rewriteMap ldap attr2dn "ldap://host/dc=my,dc=org?dn?sub"
# سپس باید DN تشکیل‌شده از یک ایمیل واحد را تشخیص دهیم،
# مثلاً `mail=someone@example.com'؛ توجه داشته باشید که این قانون
# در صورت تطابق، بازنویسی را متوقف می‌کند؛ در صورت بروز خطا،
# نادیده گرفته می‌شود. در صورتی که بافت‌های نام‌گذاری مجازی را به
# واقعی نگاشت می‌کنیم، باید DNهای عادی را نیز بازنویسی کنیم، زیرا
# تعریف زمینه بازنویسی bindDn تعریف پیش‌فرض را بازنویسی می‌کند.
rewriteContext bindDN
rewriteRule "^mail=[^,]+@[^,]+$" "%{attr2dn(%0)}" ":@I"
# این یک مثال نسبتاً پیشرفته است. این مثال در صورتی که فرد انجام‌دهنده
# جستجو دارای امتیازات مدیریتی باشد، یک فیلتر جستجو را اصلاح می‌کند.
# ابتدا باید DN اتصال درخواست ورودی را پیگیری کنیم که در متغیری به نام
# `binddn' با محدوده نشست ذخیره شده و برای امکان اتصال عادی در جای خود باقی می‌ماند:
rewriteContext  bindDN
rewriteRule     ".+" "%{&&binddn(%0)}%0" ":"
# فیلتر جستجوی حاوی `uid=' تنها در صورتی بازنویسی می‌شود
# که یک DN مناسب متصل شده باشد.
# برای انجام این کار، در اولین قانون، DN متصل‌شده ارجاع‌زدایی می‌شود،
# در حالی که فیلتر به یک پیشوند، مقدار AVA مربوط به `uid=<arg>' و
# یک پسوند تجزیه می‌شود. یک برچسب `<>' به DN الحاق می‌شود.
# اگر DN به مدخلی در زیردرخت `ou=admin' اشاره داشته باشد،
# فیلتر با OR کردن `uid=<arg>' با `cn=<arg>' بازنویسی می‌شود؛
# در غیر این صورت دست‌نخورده باقی می‌ماند. این می‌تواند برای نمونه
# مفید باشد تا به ماژول auth_ldap-1.4 آپاچی اجازه دهد کاربران را
# با هر دو مقدار `uid' و `cn' احرازهویت کند، اما تنها در صورتی که
# درخواست از سوی یک کاربر محتمل `cn=Web auth,ou=admin,dc=home,dc=net' باشد.
rewriteContext searchFilter
rewriteRule "(.*\\()uid=([a-z0-9_]+)(\\).*)"
  "%{**binddn}<>%{&prefix(%1)}%{&arg(%2)}%{&suffix(%3)}"
  ":I"
rewriteRule "[^,]+,ou=admin,dc=home,dc=net"
  "%{*prefix}|(uid=%{*arg})(cn=%{*arg})%{*suffix}" ":@I"
rewriteRule ".*<>" "%{*prefix}uid=%{*arg}%{*suffix}" ":"
# این مثال نشان می‌دهد که چگونه می‌توان مقادیر ویژگی‌های با مقدار DN ناخواسته را
# از نتیجه جستجو حذف کرد؛ اولین قانون مقادیر DN زیر "ou=People,dc=example,dc=com"
# را تطبیق می‌دهد؛ در صورت تطابق، بازنویسی با موفقیت خاتمه می‌یابد.
# دومین قانون همه چیز دیگر را مطابقت داده و باعث رد شدن مقدار می‌شود.
rewriteContext searchResult
rewriteRule ".*,ou=People,dc=example,dc=com" "%0" ":@"
rewriteRule ".*" "" "#"

تفکیک پروکسی LDAP (یک تکامل ممکن برای slapd-ldap(5)) (LDAP Proxy resolution (a possible evolution of slapd-ldap(5))):

در صورتی که DN بازنویسی‌شده یک URI از نوع LDAP باشد، عملیات به سمت میزبان[:پورت] مشخص‌شده در uri آغاز می‌شود، در صورتی که به سرور محلی اشاره نداشته باشد. به عنوان مثال:

rewriteRule '^cn=root,.*' '%0'                     'G{3}'
rewriteRule '^cn=[a-l].*' 'ldap://ldap1.my.org/%0' ':@'
rewriteRule '^cn=[m-z].*' 'ldap://ldap2.my.org/%0' ':@'
rewriteRule '.*'          'ldap://ldap3.my.org/%0' ':@'

(قانون ۱ صرفاً برای نشان دادن اقدام `G{n}' آورده شده است؛ می‌توانست به این صورت نیز نوشته شود:

rewriteRule '^cn=root,.*' 'ldap://ldap3.my.org/%0' ':@'

با این مزیت که یک مرحله گذر بازنویسی صرفه‌جویی می‌شد ...)

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

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

لایه رونویس کَش پروکسی (PROXY CACHE OVERLAY)

لایه رونویس کَش پروکسی امکان کَش کردن درخواست‌های جستجوی LDAP (پرس‌وجوها) را در یک پایگاه‌داده محلی فراهم می‌کند. برای جزئیات به slapo-pcache(5) مراجعه کنید.

عبارت‌های منسوخ‌شده (DEPRECATED STATEMENTS)

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

pseudorootdn <substitute DN in case of rootdn bind>

به جای آن از idassert-bind استفاده کنید.

pseudorootpw <substitute password in case of rootdn bind>

به جای آن از idassert-bind استفاده کنید.

فایل‌ها (FILES)

/etc/openldap/slapd.conf

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

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

slapd.conf(5)، slapd-asyncmeta(5)، slapd-ldap(5)، slapo-pcache(5)، slapd(8)، regex(7)، re_format(7).

نویسندگان (AUTHORS)

Pierangelo Masarati، بر پایه back-ldap توسط Howard Chu