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

slapd-asyncmeta - بکاند متا دایرکتوری ناهمگام (Asynchronous Metadirectory) برای slapd

/etc/openldap/slapd.conf

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

داشتن دانش کافی از قابلیت‌های بکاند slapd-meta(5) توصیه می‌شود. این بکاند به عنوان نسخه‌ای ناهمگام (asynchronous) از بکاند meta طراحی شده است. بر خلاف meta، ریسمان‌های مدیریت عملیات دیگر در انتظار پاسخ از سرور راه دور متوقف نمی‌مانند، بنابراین تعداد ریسمان‌های لازم برای مدیریت همان بار کاری کاهش می‌یابد. در حالی که asyncmeta قابلیت‌های meta را حفظ کرده و پایگاه‌کد تا حد زیادی مشابهی دارد، برخی تغییرات در عملکرد و چند دستورالعمل پیکربندی جدید اضافه شده است. برخی گزینه‌های پیکربندی، مانند conn-pool-max، conn-ttl، single-conn و use-temporary-conn حذف شده‌اند، زیرا دیگر مرتبط و کاربردی نیستند.

مدیریت اتصالات جدید:

بر خلاف meta که اتصالات متصل‌شده (bound) را کش می‌کند، asyncmeta با حداکثر تعداد اتصالات پیکربندی‌شده به ازای هر مقصد کار می‌کند. برای هر درخواستی که به یک مقصد بازهدایت می‌شود، اتصال متفاوتی انتخاب می‌گردد. هر اتصال دارای یک صف است که درخواست قبل از ارسال به سرور راه دور به آن اضافه شده و پس از دریافت آخرین پاسخ برای آن درخواست، از صف حذف می‌شود. برای هر درخواست جدید، اتصال جدیدی با استفاده از زمان‌بندی نوبت‌گردشی (round-robin) انتخاب می‌شود.

لایه‌های پوششی (Overlays):

به دلیل ویژگی‌های خاص پیاده‌سازی، هیچ تضمینی وجود ندارد که هیچ‌یک از لایه‌های پوششی موجود در OpenLDAP با بکاند asyncmeta کار کنند.

برای نمونه‌های پیکربندی به slapd-meta(5) مراجعه کنید.

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

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

این دستورالعمل بکاند را وادار می‌کند تا در صورتی که هیچ مقصدی یا چندین مقصد انتخاب شده باشند، تمام عملیاتی را که باید به یک مقصد واحد ختم شوند، رد کند. این عملیات شامل موارد زیر است: add، delete، modify، modrdn؛ عملیات compare و همچنین bind شامل این مورد نمی‌شوند، زیرا مدخل‌ها را تغییر نمی‌دهند و در صورت تطابق‌های متعدد، تلاشی برای انجام عملیات روی هر مقصد کاندید با این شرط که حداکثر یکی از آن‌ها باید موفق شود، صورت می‌گیرد. این دستورالعمل همچنین می‌تواند هنگام پردازش مقصدها برای علامت‌گذاری یک مقصد خاص به عنوان پیش‌فرض استفاده شود.
این دستورالعمل زمان حیات (time-to-live) کش DN را تعیین می‌کند. این مورد، مقصدی را که دارای یک DN مشخص است کش می‌کند تا در صورتی که یک جستجوی بدون کش منجر به چندین مقصد شود، انتخاب مقصد تسریع یابد؛ forever یعنی کش هرگز منقضی نمی‌شود؛ disabled یعنی عدم کش کردن DN؛ در غیر این صورت یک ttl معتبر ( > 0 ) به فرمتی که برای دستورالعمل idle-timeout نشان داده شده، مورد نیاز است.
این دستورالعمل امکان انتخاب رفتار در صورت بازگردانده شدن خطا توسط یک مقصد در حین جستجو را فراهم می‌کند. حالت پیش‌فرض، continue، شامل ادامه عملیات و تلاش برای بازگرداندن بیشترین داده ممکن است. اگر مقدار روی stop تنظیم شود، به محض این‌که خطایی از سوی یک مقصد بازگردانده شود جستجو خاتمه می‌یابد و خطا فوراً به کلاینت منتقل می‌شود. اگر مقدار روی report تنظیم شود، جستجو تا انتها ادامه می‌یابد اما در صورتی که حداقل یک مقصد کد خطا بازگردانده باشد، اولین کد خطای غیرموفق بازگردانده می‌شود.
تعداد درخواست‌های متوالی دارای وقفه زمانی (timed out) را مشخص می‌کند که پس از آن اتصال معیوب در نظر گرفته شده و قطع می‌شود.
حداکثر تعداد درخواست‌های در حال انتظار ذخیره‌شده در صف یک اتصال. مقدار پیش‌فرض 128 است. هنگامی که از این تعداد فراتر رود، LDAP_BUSY به کلاینت بازگردانده خواهد شد.
حداکثر تعداد اتصالات به ازای هر مقصد. بر خلاف slapd-meta(5)، پس از رسیدن به این تعداد، هیچ اتصال جدیدی ایجاد نخواهد شد. مقدار پیش‌فرض 255 است.
اگر yes باشد، پاسخ‌های ارجاع جستجو (search reference responses) را بازنمی‌گرداند. به‌طور پیش‌فرض، آن‌ها بازگردانده می‌شوند مگر اینکه درخواست LDAPv2 باشد. اگر پیش از هرگونه مشخصات مقصد تنظیم شود، بر همه مقصدها اعمال می‌شود، مگر اینکه توسط دستورالعمل‌های خاص هر مقصد بازنویسی شود.
اگر yes باشد، در صورتی که فیلتر تعریف‌نشده باشد یا شامل بخش‌های تعریف‌نشده باشد، به جای جستجو موفقیت را بازمی‌گرداند. به‌طور پیش‌فرض، جستجو پس از جایگزینی بخش‌های تعریف‌نشده با (!(objectClass=*)) که متناظر با مجموعه نتایج خالی است، ارسال می‌شود. اگر پیش از هرگونه مشخصات مقصد تنظیم شود، بر همه مقصدها اعمال می‌شود، مگر اینکه توسط دستورالعمل‌های خاص هر مقصد بازنویسی شود.
این دستورالعمل مشخص می‌کند که چه نسخه‌ای از پروتکل باید برای تماس با سرور راه دور استفاده شود. اگر روی 0 (پیش‌فرض) تنظیم شود، پروکسی از همان نسخه پروتکل استفاده‌شده توسط کلاینت استفاده می‌کند، در غیر این صورت پروتکل درخواستی استفاده خواهد شد. اگر عملیاتی انجام شود که با پروتکل درخواستی ناسازگار باشد، پروکسی unwillingToPerform را بازمی‌گرداند. اگر پیش از هرگونه مشخصات مقصد تنظیم شود، بر همه مقصدها اعمال می‌شود، مگر اینکه توسط دستورالعمل‌های خاص هر مقصد بازنویسی شود.
این دستورالعمل، هنگامی که روی yes تنظیم شود، باعث می‌شود احراز هویت در سرورهای راه دور با هویت ریشه کاذب (pseudo-root) (هویت تعریف‌شده در هر دستورالعمل idassert-bind) تا زمانی که واقعاً توسط عملیات بعدی مورد نیاز باشد، به تعویق بیفتد. در غیر این صورت، تمام bindها با هویت rootdn به مقصدها ارسال می‌شوند.
قرنطینه کردن URIهایی را که LDAP_UNAVAILABLE بازگردانده‌اند فعال می‌کند، به طوری که تلاش برای اتصال مجدد فقط در فواصل زمانی مشخص رخ می‌دهد، نه هر باری که کلاینت درخواستی ارسال می‌کند. الگو به این صورت است: تلاش مجدد فقط پس از گذشت حداقل interval ثانیه از آخرین تلاش، دقیقاً به تعداد num بار؛ سپس از الگوی بعدی استفاده می‌شود. اگر مقدار num برای آخرین الگو برابر با «+» باشد، تلاش تا ابد ادامه می‌یابد؛ در غیر این صورت، دیگر تلاشی صورت نمی‌گیرد. این دستورالعمل باید پیش از هرگونه مشخصات مقصد قرار گیرد؛ این دستور با الگوی یکسان بر همه مقصدها اعمال می‌شود.
در صورت تعیین این گزینه، مشخصات احراز هویت bind کلاینت برای اتصال‌های مجدد، در هنگام تلاش برای برقراری مجدد یک اتصال قطع‌شده، یا هنگام تعقیب ارجاع (در صورتی که chase-referrals روی yes تنظیم شده باشد)، به خاطر سپرده می‌شود.
کنترل ردگیری نشست (session tracking) را برای تمام درخواست‌ها اضافه می‌کند. نشانی IP و نام هاست کلاینت، و هویت مرتبط با هر درخواست، در صورت مشخص بودن، برای مقاصد اطلاعاتی به سرور راه دور ارسال می‌شود. این دستورالعمل با تنظیم protocol-version روی 2 ناسازگار است. اگر پیش از هرگونه مشخصات مقصد تنظیم شود، بر همه مقصدها اعمال می‌شود، مگر اینکه توسط دستورالعمل‌های خاص هر مقصد بازنویسی شود.

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

مشابه با meta. برای جزئیات به slapd-meta(5) مراجعه کنید.
شناسه DN که برای ارسال پرس‌وجو به سرور مقصد جهت بررسی acl استفاده می‌شود، همانند بکاند LDAP؛ فرض بر این است که این شناسه در سرور مقصد دسترسی خواندن به ویژگی‌های مورد استفاده در پروکسی برای بررسی acl را دارد. هیچ خطری در افشای چنین مقادیری وجود ندارد؛ آن‌ها فقط برای بررسی مجوزها استفاده می‌شوند. هویت acl-authcDN به هیچ وجه زمانی که کلاینت به صورت ناشناس متصل می‌شود، به صورت ضمنی توسط پروکسی استفاده نمی‌شود.
گذرواژه مورد استفاده همراه با acl-authcDN فوق.
این دستورالعمل وقفه زمانی (بر حسب میکروثانیه) مورد استفاده هنگام سرکشی (polling) برای پاسخ پس از یک اتصال bind ناهمگام را تعیین می‌کند. برای جزئیات به slapd-meta(5) مراجعه کنید.
فعال/غیرفعال کردن تعقیب خودکار ارجاعات، که به کتابخانه libldap زیربنایی واگذار شده است و در صورت استفاده از دستورالعمل rebind-as-user، اتصال مجدد در نهایت انجام می‌گیرد. حالت پیش‌فرض، تعقیب ارجاعات است. اگر پیش از هرگونه مشخصات مقصد تنظیم شود، بر همه مقصدها اعمال می‌شود، مگر اینکه توسط دستورالعمل‌های خاص هر مقصد بازنویسی شود.
این ویژگی امکان استفاده از کنترل RFC 2696 Paged Results را هنگام انجام عملیات جستجو با یک مقصد خاص، صرف‌نظر از درخواست کلاینت فراهم می‌کند. برای جزئیات به slapd-meta(5) مراجعه کنید.
دستورالعمل "default-target" می‌تواند در حین تعیین مشخصات مقصد نیز استفاده شود. بدون آرگومان، مقصد فعلی را به عنوان پیش‌فرض علامت‌گذاری می‌کند. عدد اختیاری، مقصد <target> را به عنوان مقصد پیش‌فرض مشخص می‌کند که شمارش آن از 1 شروع می‌شود. مقصد <target> باید تعریف شده باشد.
این دستورالعمل امکان تعیین یک الگوی regex(5) را فراهم می‌کند تا نشان دهد چه عبارت‌های فیلتر جستجویی واقعاً توسط یک مقصد سرویس‌دهی می‌شوند.

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

در صورت تعریف، مشخص می‌کند کدام هویت‌های محلی مجاز به بهره‌برداری از ویژگی تأیید هویت (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=<names>] [tls_protocol_min=<major>[.<minor>]] [tls_crlcheck=none|peer|all] امکان تعریف پارامترهای روش احراز هویتی را فراهم می‌کند که به صورت داخلی توسط پروکسی برای صدور مجوز اتصال‌هایی که توسط پایگاه‌های داده دیگر احراز هویت شده‌اند، استفاده می‌شود. برای جزئیات به slapd-meta(5) مراجعه کنید.

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

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

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

پارامتر keepalive مقادیر idle، probes و interval را تنظیم می‌کند که برای بررسی فعال بودن سوکت استفاده می‌شوند؛ idle تعداد ثانیه‌هایی است که اتصال باید پیش از شروع ارسال کاوش‌های keepalive توسط TCP بیکار بماند؛ probes حداکثر تعداد کاوش‌های keepalive است که TCP باید پیش از قطع اتصال ارسال کند؛ interval فاصله زمانی بر حسب ثانیه بین کاوش‌های keepalive جداگانه است. فقط برخی سیستم‌ها از سفارشی‌سازی این مقادیر پشتیبانی می‌کنند؛ در غیر این صورت، پارامتر keepalive نادیده گرفته شده و از تنظیمات سراسری سیستم استفاده می‌شود.
اگر غیرصفر باشد، متناظر با TCP_USER_TIMEOUT تنظیم‌شده روی اتصالات مقصد است و تنظیمات سیستم‌عامل را بازنویسی می‌کند. تنها برخی از سیستم‌ها از سفارشی‌سازی این پارامتر پشتیبانی می‌کنند، در غیر این صورت نادیده گرفته شده و از تنظیمات سراسری سیستم استفاده می‌شود.
این گزینه کلاس‌های شیء و ویژگی‌ها را مشابه با بکاند LDAP نگاشت می‌کند. به slapd-ldap(5) مراجعه کنید.
مقدار وقفه زمانی شبکه را تنظیم می‌کند که پس از آن poll(2)/select(2) پس از یک connect(2) در صورت عدم فعالیت هنگام ارسال یک عملیات به مقصد راه دور، بازمی‌گردد. مقدار بر حسب میلی‌ثانیه است و می‌تواند همانند idle-timeout مشخص شود. اگر پیش از هرگونه مشخصات مقصد تنظیم شود، بر همه مقصدها اعمال می‌شود، مگر اینکه توسط دستورالعمل‌های خاص هر مقصد بازنویسی شود.
این دستورالعمل مشخص می‌کند که در صورت بروز شکست موقت در تماس با یک مقصد، ارسال مجدد یک عملیات چند بار باید تکرار شود. تعداد تلاش‌های مجدد به ازای هر عملیات است، بنابراین اگر ابتدا یک bind به مقصد لازم باشد، از تعداد باقیمانده کسر می‌شود. اگر پیش از هر مشخصات مقصدی تعریف شود، برای همه مقصدها اعمال می‌شود (به‌طور پیش‌فرض، 3 بار)؛ مقدار سراسری را می‌توان با بازتعریف در داخل مشخصات هر مقصد بازنویسی کرد.
این دستورالعمل امکان نشان دادن این‌که کدام زیردرخت‌ها واقعاً توسط یک مقصد سرویس‌دهی می‌شوند را فراهم می‌کند. برای جزئیات به slapd-meta(5) مراجعه کنید.
دستور slapd-asyncmeta از موتور بازنویسی (rewrite engine) مورد استفاده توسط باکاندهای LDAP و META پشتیبانی نمی‌کند. از suffixmassage می‌توان برای انجام بازنویسی پسوند DN استفاده کرد، دقیقاً به همان شیوه‌ای که دستورالعمل منسوخ‌شده suffixmassage که پیش‌تر توسط بکاند LDAP استفاده می‌شد، عمل می‌کرد.
در صورتی که سرور راه دور از فیلترهای مطلق (absolute filters) پشتیبانی کند فعال می‌شود (برای جزئیات به RFC 4526 مراجعه کنید). اگر روی discover تنظیم شود، پشتیبانی با خواندن DSE ریشه سرور راه دور شناسایی می‌شود. اگر پیش از هرگونه مشخصات مقصد تنظیم شود، بر همه مقصدها اعمال می‌شود، مگر اینکه توسط دستورالعمل‌های خاص هر مقصد بازنویسی شود.
این دستورالعمل امکان تنظیم مهلت زمانی به ازای هر عملیات را فراهم می‌کند. عملیات‌ها می‌توانند موارد زیر باشند:

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

به‌طور پیش‌فرض، مهلت زمانی برای تمام عملیات‌ها ۲ ثانیه است.

برای جزئیات به slapd-meta(5) مراجعه کنید.

[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]
تنظیمات TLS را برای اتصالات عادی مشخص می‌کند.

اگر پارامتر اول "none" نباشد، این بخش تنظیمات TLS را برای استفاده در اتصالات عادی پیکربندی می‌کند. عملیات توسعه‌یافته StartTLS هنگام برقراری اتصال استفاده خواهد شد، مگر اینکه طرح پروتکل دستورالعمل URI برابر با ldaps:// باشد. در آن صورت این کلیدواژه تنها می‌تواند روی "ldaps" تنظیم شود و از عملیات StartTLS استفاده نخواهد شد.

با propagate، پروکسی عملیات StartTLS را تنها در صورتی صادر می‌کند که اتصال اصلی یک لایه TLS راه‌اندازی کرده باشد. پیشوند try- به پروکسی دستور می‌دهد تا در صورت ناموفق بودن عملیات StartTLS، به عملیات ادامه دهد؛ استفاده از آن توصیه نمی‌شود.

تنظیمات TLS به‌طور پیش‌فرض همانند تنظیمات اصلی TLS در slapd است، به جز tls_reqcert که پیش‌فرض آن "demand" است، tls_reqsan که پیش‌فرض آن "allow" است، و starttls که تحت‌الشعاع کلیدواژه اول قرار گرفته و در نتیجه نادیده گرفته می‌شود.

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

برای سناریوهای پیکربندی به slapd-meta(5) مراجعه کنید.

رفتار ACL مشابه meta است. به slapd-meta(5) مراجعه کنید.

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

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

slapd.conf(5), slapd-ldap(5), slapd-meta(5), slapo-pcache(5), slapd(8), regex(7), re_format(7).

Nadezhda Ivanova، بر اساس back-meta توسط Pierangelo Masarati.

2026/03/09 OpenLDAP 2.6.13