نام (NAME)

lloadd.conf - فایل پیکربندی دیمن متعادل‌کننده بار LDAP (lloadd)

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

/etc/openldap/lloadd.conf

توضیحات (DESCRIPTION)

فایل /etc/openldap/lloadd.conf حاوی اطلاعات پیکربندی برای دیمن lloadd(8) است.

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

قالب کلی lloadd.conf به شرح زیر است:

# دو خط زیر تنها زمانی باید وجود داشته باشند که به عنوان
# ماژول slapd پیکربندی شده باشد:
backend lload
listen <URIs to be managed by lloadd>
# توضیح - این گزینه‌ها برای کل سرور اعمال می‌شوند
<global configuration options>
# اولین تعریف لایه
tier <strategy>
# اولین تعریف بک‌اند
backend-server <backend 1 definition>
# تعاریف بعدی بک‌اند/لایه
...

می‌توان هر تعداد لایه (tier) و سرور بک‌اند را که لازم است پیکربندی کرد.

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

خطوط خالی و خطوط توضیحات که با نویسه `#' آغاز می‌شوند نادیده گرفته می‌شوند. توجه: خطوط ادامه قبل از پردازش توضیحات باز می‌شوند (unwrap می‌شوند).

آرگومان‌ها در خطوط پیکربندی با فاصله از هم جدا می‌شوند. اگر یک آرگومان حاوی فاصله باشد، آرگومان باید درون علامت نقل‌قول دوتایی قرار گیرد. اگر آرگومان حاوی یک علامت نقل‌قول دوتایی (`"') یا نویسه بک‌اسلش (`\') باشد، باید پیش از آن نویسه یک بک‌اسلش قرار داده شود.

گزینه‌های پیکربندی خاصِ موجود، در ادامه در بخش‌های گزینه‌های پیکربندی سراسری و گزینه‌های عمومی بک‌اند مورد بحث قرار گرفته‌اند. برای جزئیات بیشتر در مورد فایل پیکربندی lloadd به «راهنمای مدیر OpenLDAP» مراجعه کنید.

یکپارچه‌سازی با SLAPD (SLAPD INTEGRATION)

توجه داشته باشید هنگامی که lloadd به عنوان یک ماژول slapd پیکربندی شده است، هر گزینه‌ای که نام یکسانی با یک گزینه در slapd.conf(5) داشته باشد، تفسیر slapd اولویت دارد و گزینه lloadd ذکرشده مستقیماً از طریق slapd.conf(5) در دسترس نخواهد بود؛ در عوض، باید از طریق یک مشخصه اختصاصی در cn=config پیکربندی شود. به‌ویژه، مگر اینکه گزینه TLSShareSlapdCTX تنظیم شده باشد، lloadd زمینه (context) مربوط به TLS اختصاصی خود را حفظ می‌کند که جز از طریق پیکربندی پویا نمی‌توان آن را پیکربندی کرد.

گزینه اضافی دیگری هنگام اجرا به عنوان ماژول slapd در دسترس است:

listen <listen URIs>

شناسه‌های یکنواخت منبع (URIها) که ماژول متعادل‌کننده بار باید روی آن‌ها گوش فرا دهد. این شناسه‌ها نباید با مواردی که slapd برای سوکت‌های شنونده خود استفاده می‌کند هم‌پوشانی داشته باشند. مشخصه مربوطه در cn=config مشخصه olcBkLloadListen است که هر URI به عنوان یک مقدار جداگانه ارائه می‌شود. هیچ تغییری در این مشخصه که پس از راه‌اندازی سرور ایجاد شود، تا زمانی که سرور راه‌اندازی مجدد نشود، اعمال نخواهد شد.

دستورالعمل‌های عمومی (GLOBAL DIRECTIVES)

گزینه‌های شرح‌داده‌شده در این بخش برای تمام بک‌اندها اعمال می‌شوند. آرگومان‌هایی که باید با متن واقعی جایگزین شوند داخل علامت‌های <> نشان داده شده‌اند.

argsfile <filename>

نام (مطلق) فایلی که خط فرمان سرور lloadd (نام برنامه و گزینه‌ها) را در خود نگهداری می‌کند.

concurrency <integer>

سطح همزمانی مورد نظر را مشخص می‌کند. به عنوان یک پیشنهاد (hint) به سیستم نخ‌های زیربنایی ارائه می‌شود. پیش‌فرض این است که هیچ پیشنهادی ارائه نشود.

feature <feature> [...]

ویژگی‌های اضافی پشتیبانی‌شده توسط متعادل‌کننده بار LDAP را فعال می‌کند. ویژگی‌های پشتیبانی‌شده عبارتند از:

include <filename>

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

io-threads <integer>

تعداد نخ‌هایی (threads) را که باید برای مدیر اتصال استفاده شود مشخص می‌کند. پیش‌فرض ۱ است و این مقدار معمولاً برای حداکثر ۱۶ هسته CPU کافی است. این مقدار باید توانی از ۲ تنظیم شود.

در صورت تغییر پس از راه‌اندازی سرور، تغییر این گزینه تا زمانی که سرور مجدداً راه‌اندازی نشود اعمال نخواهد شد.

logfile <filename>

فایلی را برای ثبت پیام‌های اشکال‌زدایی lloadd مشخص می‌کند. به‌طور پیش‌فرض این پیام‌ها تنها به stderr ارسال می‌شوند، در هیچ جای دیگری ثبت نمی‌شوند و ارتباطی با پیام‌های مشخص‌شده توسط پارامتر پیکربندی

logfile-format debug | syslog-utc | syslog-localtime

قالب پیشوند پیام‌های نوشته‌شده در فایل لاگ را مشخص می‌کند. قالب debug همان قالب عادی مورد استفاده برای پیام‌های اشکال‌زدایی slapd است، با یک برچسب زمانی در مبنای شانزده، که پس از آن یک شناسه نخ می‌آید. گزینه‌های دیگر شامل استفاده از پیشوندهای سبک syslog(3) با برچسب‌های زمانی بر حسب UTC یا منطقه زمانی محلی هستند. پیش‌فرض قالب debug است. loglevel ندارند. مشخص کردن یک logfile پیام‌ها را هم به stderr و هم به فایل لاگ کپی می‌کند.

logfile-only on | off

مشخص می‌کند که پیام‌های اشکال‌زدایی تنها به فایل لاگ پیکربندی‌شده ارسال شوند و به stderr نروند.

logfile-rotate <max> <Mbytes> <hours>

چرخش خودکار را برای فایل لاگ پیکربندی‌شده به‌صورت حداکثر تعداد فایل‌های لاگ قدیمی برای نگهداری، حداکثر اندازه بر حسب مگابایت برای رشد فایل لاگ پیش از چرخش، و حداکثر عمر بر حسب ساعت برای استفاده از یک فایل لاگ پیش از چرخش مشخص می‌کند. حداکثر تعداد باید در محدوده ۱ تا ۹۹ باشد. تنظیم Mbytes یا hours روی صفر، به ترتیب بررسی اندازه یا سن فایل را غیرفعال می‌کند. حداقل یکی از مقادیر Mbytes یا hours باید غیرصفر باشد. به‌طور پیش‌فرض هیچ چرخش خودکاری انجام نخواهد شد.

loglevel <integer> [...]

سطحی را مشخص می‌کند که در آن عبارات اشکال‌زدایی و آمار عملیات باید از طریق syslog ثبت شوند (در حال حاضر در تسهیلات LOG_LOCAL4 مربوط به syslogd(8) ثبت می‌شود). این‌ها را باید بیشتر به عنوان زیرسیستم‌ها در نظر گرفت تا سطوح لاگ‌گیری که به تدریج پرحرف‌تر می‌شوند. برخی از پیام‌های با اولویت بالاتر، به محض اینکه هر گونه ثبت لاگی پیکربندی شود، بدون در نظر گرفتن loglevel پیکربندی‌شده ثبت می‌شوند. سطوح لاگ جمع‌پذیر هستند، و سطوح موجود عبارتند از:

loglevel 513
loglevel 0x201
loglevel 512 1
loglevel 0x200 0x1
loglevel stats trace

pidfile <filename>

نام (مطلق) فایلی که شناسه فرآیند سرور lloadd را در خود نگهداری می‌کند (نگاه کنید به getpid(2)).

sockbuf_max_incoming_client <integer>

حداکثر اندازه PDU ورودی LDAP پذیرفته‌شده از سوی کلاینت‌ها را مشخص می‌کند. پیش‌فرض ۲۶۲۱۴۳ است.

sockbuf_max_incoming_upstream <integer>

حداکثر اندازه PDU ورودی LDAP پذیرفته‌شده از اتصالات بالادست را مشخص می‌کند. پیش‌فرض ۴۱۹۴۳۰۳ است.

tcp-buffer [listener=<URL>] [{read|write}=]<size>

اندازه بافر TCP را مشخص می‌کند. یک مقدار سراسری برای هر دو بافر خواندن و نوشتن TCP مربوط به هر شنونده تعریف می‌شود، مگر اینکه شنونده به‌صراحت مشخص شده باشد، یا از توصیف‌کننده‌های read یا write استفاده شود. برای جزئیات tcp(7) را ببینید. توجه داشته باشید که برخی سیستم‌های عامل تنظیم خودکار بافر TCP را پیاده‌سازی کرده‌اند.

threads <integer>

حداکثر اندازه استخر نخ (thread pool) اصلی را مشخص می‌کند. پیش‌فرض ۱۶ است؛ حداقل مقدار ۲ است.

threadqueues <integer>

تعداد صف‌های کاری را برای استفاده در استخر نخ اصلی مشخص می‌کند. پیش‌فرض ۱ است و این مقدار معمولاً برای حداکثر ۸ هسته CPU کافی است. این مقدار نباید از تعداد CPUهای سیستم تجاوز کند.

max_pdus_per_cycle <integer>

اگر روی 0 تنظیم شود، PDUها مستقیماً توسط نخ‌های I/O پردازش می‌شوند، در غیر این صورت وظیفه‌ای در صف قرار می‌گیرد تا توسط استخر نخ برداشته شود. این وظیفه PDUها را از اتصال پردازش می‌کند تا زمانی که داده دیگری برای خواندن وجود نداشته باشد یا این حد نصاب حاصل شود که در این صورت نخ I/O می‌تواند دوباره آن را بردارد. مقادیر بسیار بالا پتانسیل این را دارند که باعث محرومیت برخی اتصالات در یک محیط با پهنای باند بسیار بالا شوند. پیش‌فرض ۱۰۰۰ است.

client_max_pending <integer>

باعث می‌شود متعادل‌کننده بار تعداد عملیات‌های ناتمام را برای هر اتصال کلاینت محدود کند. پیش‌فرض 0 یعنی نامحدود است.

iotimeout <integer>

تعداد میلی‌ثانیه‌ها برای انتظار پیش از بستن اجباری یک اتصال با عملیات نوشتن معلق را مشخص می‌کند. این امر امکان بازیابی سریع‌تر از شرایط مختلف هنگ کردن شبکه را فراهم می‌کند. مقدار iotimeout برابر 0 این ویژگی را غیرفعال می‌کند. پیش‌فرض ۱۰۰۰۰ است.

write_coherence <integer>

تعداد ثانیه‌ها پس از اتمام یک عملیات نوشتن را مشخص می‌کند که lloadd طی آن عملیات‌ها را منحصراً به آخرین بک‌اند انتخاب‌شده هدایت خواهد کرد. یک عملیات نوشتن هر چیزی است که به صورت داخلی مدیریت نشود (برخی exopها، abandon)، به جز عملیات‌های جستجو (search)، مقایسه (compare) و بایند (bind). عملیات‌های بایند نیز این محدودیت را بازنشانی می‌کنند. پیش‌فرض 0 است؛ عملیات‌های نوشتن انتخاب را محدود نمی‌کنند. در صورت منفی بودن، محدودیت دارای بازه زمانی نخواهد بود و تا بایند بعدی ادامه می‌یابد.

restrict_exop <OID> <action>

به lloadd اعلام می‌کند که عملیات توسعه‌یافته با OID مشخص‌شده باید به روش خاصی مدیریت شود. شناسه OID با مقدار 1.1 خاص است و یک پیش‌فرض تعیین می‌کند (تنها برای عملیات‌هایی که به صورت داخلی مدیریت نمی‌شوند). معنای آرگومان <action> همانند گزینه restrict_control در زیر است.

restrict_control <OID> <action>

به lloadd اعلام می‌کند که کنترل با OID مشخص‌شده که به هر عملیاتی پیوست شده است، باید مطابق با آرگومان <action> به روش خاصی مدیریت شود. در حال حاضر، تنها عملیات‌هایی که دست‌نخورده منتقل می‌شوند به این روش بازرسی می‌گردند؛ به‌ویژه، کنترل‌های روی عملیات‌های bind و عملیات‌های توسعه‌یافته بررسی نمی‌شوند.

به ترتیب اولویت نزولی (کنترل دارای بالاترین اقدام اولویت‌دار برنده می‌شود)، اقدام صورت‌گرفته به شرح زیر است:

گزینه‌های TLS (TLS OPTIONS)

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

TLSShareSlapdCTX { on | off }

اگر روی no تنظیم شود (پیش‌فرض)، lloadd از زمینه TLS اختصاصی خود استفاده خواهد کرد (مگر اینکه lloadd به عنوان یک دیمن مستقل اجرا شود، باید از طریق cn=config پیکربندی گردد). در صورت فعال بودن، گزینه‌های مربوط به slapd اعمال خواهند شد، زیرا در این حالت از زمینه TLS متعلق به slapd استفاده می‌شود.

گزینه‌های زیر تنها زمانی در دسترس هستند که به صورت یک دیمن مستقل کامپایل شده باشد. هنگامی که به عنوان ماژول slapd(8) کامپایل شده باشد، در صورتی که به زمینه TLS مجزا برای ماژول نیاز باشد باید از معادل‌های cn=config استفاده شود، در غیر این صورت از گزینه TLSShareSlapdCTX استفاده کنید.

TLSCipherSuite <cipher-suite-spec>

امکان پیکربندی رمزهایی که پذیرفته می‌شوند و ترتیب اولویت آن‌ها را فراهم می‌کند. <cipher-suite-spec> باید یک مشخصه رمز برای کتابخانه TLS مورد استفاده (OpenSSL، GnuTLS یا Mozilla NSS) باشد. مثال:

openssl ciphers -v <cipher-suite-spec>

gnutls-cli -l

static const SSLCipherSuiteInfo suiteInfo[]

TLSCACertificateFile <filename>

فایلی را مشخص می‌کند که حاوی گواهی‌های تمام مراجع صدور گواهی (CA) است که lloadd آن‌ها را به رسمیت می‌شناسد. گواهی مرجع صدور گواهی که گواهی سرور را امضا کرده است باید در میان این گواهی‌ها گنجانده شود. اگر CA امضاکننده یک مرجع صدور گواهی سطح بالا (ریشه) نبود، باید گواهی‌های کل دنباله CAها از CA امضاکننده تا CA سطح بالا وجود داشته باشد. گواهی‌های متعدد صرفاً به فایل اضافه می‌شوند؛ ترتیب آن‌ها اهمیتی ندارد.

TLSCACertificatePath <path>

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

هنگام استفاده از Mozilla NSS، مقدار <path> ممکن است حاوی یک پایگاه‌داده گواهی/کلید Mozilla NSS باشد. اگر <path> حاوی پایگاه‌داده گواهی/کلید Mozilla NSS و فایل‌های گواهی CA باشد، OpenLDAP از پایگاه‌داده گواهی/کلید استفاده خواهد کرد و فایل‌های گواهی CA را نادیده می‌گیرد.

TLSCertificateFile <filename>

فایلی را مشخص می‌کند که حاوی گواهی سرور lloadd است.

هنگام استفاده از Mozilla NSS، در صورت استفاده از پایگاه‌داده گواهی/کلید (مشخص‌شده با TLSCACertificatePath)، گزینه TLSCertificateFile نام گواهی مورد استفاده را مشخص می‌کند:

TLSCertificateFile Server-Cert

در صورت استفاده از توکنی غیر از توکن داخلی توکار، ابتدا نام توکن را مشخص کرده و به دنبال آن یک دونقطه قرار دهید:

TLSCertificateFile my hardware device:Server-Cert

از certutil -L برای فهرست کردن گواهی‌ها بر اساس نام استفاده کنید:

certutil -d /path/to/certdbdir -L

TLSCertificateKeyFile <filename>

فایلی را مشخص می‌کند که حاوی کلید خصوصی سرور lloadd منطبق با گواهی ذخیره‌شده در فایل TLSCertificateFile است. در حال حاضر، کلید خصوصی نباید با گذرواژه محافظت شود، بنابراین بسیار حیاتی است که با دقت از آن محافظت گردد.

هنگام استفاده از Mozilla NSS، گزینه TLSCertificateKeyFile نام فایلی را مشخص می‌کند که حاوی گذرواژه کلید مربوط به گواهی مشخص‌شده با TLSCertificateFile است. دستور modutil را می‌توان برای غیرفعال کردن حفاظت گذرواژه در پایگاه‌داده گواهی/کلید استفاده کرد. برای مثال، اگر TLSCACertificatePath مسیر /etc/openldap/certdb را به عنوان مکان پایگاه‌داده گواهی/کلید مشخص کند، از modutil برای تغییر گذرواژه به رشته خالی استفاده کنید:

modutil -dbdir /etc/openldap/certdb -changepw 'NSS Certificate DB'

شما باید گذرواژه قدیمی (در صورت وجود) را داشته باشید. هشدار مربوط به اجرای مرورگر را نادیده بگیرید. برای گذرواژه جدید کلید 'Enter' را فشار دهید.

TLSDHParamFile <filename>

این دستورالعمل فایلی را مشخص می‌کند که حاوی پارامترهایی برای تبادل کلید موقت دیفی-هلمن (Diffie-Hellman ephemeral) است. این برای استفاده از یک گواهی DSA روی سرور یا یک گواهی RSA که فاقد کاربرد کلید "key encipherment" است الزامی می‌باشد. توجه داشته باشید که تنظیم این گزینه ممکن است تبادل کلید دیفی-هلمن ناشناس را نیز در برخی از مجموعه‌های رمز غیرپیش‌فرض فعال کند. به‌طور کلی باید از تبادلات کلید ناشناس اجتناب شود زیرا هیچ احراز هویت واقعی کلاینت یا سرور را فراهم نمی‌کنند و هیچ حفاظتی در برابر حملات مرد میانی ارائه نمی‌دهند. شما باید "!ADH" را به مجموعه‌های رمز خود اضافه کنید تا مطمئن شوید از این مجموعه‌ها استفاده نمی‌شود. هنگام استفاده از Mozilla NSS این پارامترها همیشه به صورت تصادفی تولید می‌شوند، بنابراین این دستورالعمل نادیده گرفته می‌شود.

TLSECName <name>

نام یک منحنی را برای استفاده در تبادل کلید موقت دیفی-هلمن منحنی بیضوی (ECDHE) مشخص می‌کند. این برای فعال کردن الگوریتم‌های ECDHE در OpenSSL الزامی است. این گزینه با GnuTLS استفاده نمی‌شود؛ منحنی‌ها ممکن است در مشخصات ciphersuite مربوط به GnuTLS انتخاب شوند. این گزینه برای Mozilla NSS نیز نادیده گرفته می‌شود.

TLSProtocolMin <major>[.<minor>]

حداقل نسخه پروتکل SSL/TLS را که مذاکره خواهد شد مشخص می‌کند. اگر سرور حداقل از آن نسخه پشتیبانی نکند، دست‌تکانی SSL شکست خواهد خورد. برای الزامی کردن TLS 1.x یا بالاتر، این گزینه را روی 3.(x+1) تنظیم کنید، مثلاً:

TLSProtocolMin 3.2

به TLS 1.1 نیاز خواهد داشت. مشخص کردن حداقل نسخه‌ای بالاتر از آنچه توسط پیاده‌سازی OpenLDAP پشتیبانی می‌شود، باعث می‌شود بالاترین سطحی که پشتیبانی می‌کند الزامی شود. این دستورالعمل در GnuTLS نادیده گرفته می‌شود.

TLSRandFile <filename>

فایلی را برای به دست آوردن بیت‌های تصادفی در زمانی که /dev/[u]random در دسترس نیست مشخص می‌کند. معمولاً روی نام سوکت EGD/PRNGD تنظیم می‌شود. متغیر محیطی RANDFILE نیز می‌تواند برای تعیین نام فایل استفاده شود. این دستورالعمل در GnuTLS و Mozilla NSS نادیده گرفته می‌شود.

TLSVerifyClient <level>

مشخص می‌کند که چه بررسی‌هایی (در صورت وجود) باید روی گواهی‌های کلاینت در یک نشست ورودی TLS انجام شود. مقدار <level> می‌تواند به‌عنوان یکی از کلیدواژه‌های زیر مشخص شود:

پیکربندی سرویس‌دهنده (BACKEND CONFIGURATION)

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

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

bindconf

[bindmethod=simple|sasl] [binddn=<dn>] [saslmech=<mech>] [authcid=<identity>] [authzid=<identity>] [credentials=<passwd>] [realm=<realm>] [secprops=<properties>] [timeout=<seconds>] [network-timeout=<seconds>] [keepalive=<idle>:<probes>:<interval>] [tcp-user-timeout=<milliseconds>] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_crlcheck=none|peer|all] [tls_protocol_min=<major>[.<minor>]]

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

یک bindmethod از نوع simple نیازمند گزینه‌های binddn و credentials است و تنها زمانی باید استفاده شود که سرویس‌های امنیتی کافی (مانند TLS یا IPSEC) برقرار باشند. به یاد داشته باشید: اطلاعات اعتبارسنجی simple bind باید به صورت متن واضح (cleartext) باشند! یک bindmethod از نوع sasl نیازمند گزینه saslmech است. بسته به مکانیزم، هویت و/یا اطلاعات اعتبارسنجی احراز هویت را می‌توان با استفاده از authcid و credentials مشخص کرد. پارامتر authzid ممکن است برای تعیین یک هویت اعطای مجوز استفاده شود. ویژگی‌های امنیتی خاص (همانند کلیدواژه sasl-secprops در بالا) برای یک bind مربوط به SASL را می‌توان با گزینه secprops تنظیم کرد. یک قلمرو (realm) غیرپیش‌فرض SASL را می‌توان با گزینه realm تنظیم نمود.

پارامتر timeout مشخص می‌کند که یک عملیات تا چند ثانیه می‌تواند در انتظار پاسخ (نتیجه، مدخل جستجو، ...) از سرور بماند. به دلیل نحوه تشخیص مهلت‌های زمانی، ممکن است مهلت زمانی تا timeout ثانیه پس از وقوع آن شناسایی و مدیریت نشود.

پارامتر network-timeout مشخص می‌کند که مصرف‌کننده چه مدت برای برقراری اتصال شبکه با ارائه‌دهنده منتظر خواهد ماند. به محض برقراری اتصال، پارامتر timeout تعیین می‌کند که مصرف‌کننده چه مدت برای تکمیل درخواست Bind اولیه منتظر بماند.

تنظیم Timeout روی 0 به معنای غیرفعال بودن مهلت زمانی است و به‌طور پیش‌فرض، هیچ مهلت زمانی اعمال نمی‌شود.

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

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

گزینه‌های لایه (TIER OPTIONS)

tier

<tier type>

سرورهایی را گروه‌بندی می‌کند که باید در یک تلاش مشابه بررسی شوند. اگر یک اتصال قابل دوام پیدا شود حتی اگر شلوغ باشد، متعادل‌کننده بار به لایه بعدی پیشروی نمی‌کند. فرآیند انتخاب یک اتصال در داخل یک لایه به نوع آن لایه بستگی دارد.

انواع موجود عبارتند از:

roundrobin

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

weighted

سرورهای بک‌اند گزینه جدید weight=<int> را می‌پذیرند که نشان می‌دهد هر چند وقت یک‌بار باید انتخاب شوند. در صورت عدم تعیین، وزن به طور پیش‌فرض 0 است و چنین بک‌آندهایی شانس کمی برای انتخاب شدن دارند حتی زمانی که یک بک‌اند با وزن غیرصفر در لایه پیکربندی شده باشد. فرآیند انتخاب مشابه با RFC2782 است.

bestof

همانند weighted، بک‌اندها گزینه weight=<int> را می‌پذیرند. میانگین تأخیر ضربدر weight در طول زمان اندازه‌گیری می‌شود. فرآیند انتخاب ۲ بک‌اند را به صورت تصادفی انتخاب می‌کند، تأخیرهای وزن‌دار آن‌ها را مقایسه می‌کند و بک‌اندی با امتیاز بهتر (کمتر) امتحان می‌شود. اگر آن بک‌اند در دسترس نباشد (یا شلوغ باشد)، بک‌اند دیگر امتحان می‌شود، سپس بک‌اندها به ترتیب round-robin انتخاب می‌شوند.

توجه داشته باشید که بر خلاف weighted، هرچه وزن بالاتر باشد، تأخیر «مؤثر» بالاتر است و شانس انتخاب یک بک‌اند کمتر می‌شود.

دستورالعمل‌های ویژه سرویس‌دهنده (BACKEND DIRECTIVES)

backend-server

uri=ldap[s]://<hostname>[:port] [retry=<retry interval in ms>] [starttls=yes|critical] [numconns=<conns>] [bindconns=<conns>] [max-pending-ops=<ops>] [conn-max-pending=<ops>]

شروع تعریف یک بک‌اند را مشخص می‌کند.

گزینه uri بک‌اند را به عنوان یک LDAP URI مشخص می‌کند. اگر <port> داده نشود، شماره پورت استاندارد LDAP (برابر ۳۸۹ یا ۶۳۶) استفاده می‌شود.

برنامه Lloadd تلاش خواهد کرد numconns اتصال فعال، و همچنین bindconns اتصال فعال اختصاص‌یافته برای پردازش درخواست‌های bind کلاینت را نگهداری کند.

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

عملیات‌ها بین اتصالات بک‌اند (upstreams یا اتصالات بالادست ) توزیع خواهند شد.

پارامتر conn-max-pending مگر اینکه روی 0 (پیش‌فرض) تنظیم شود، تعداد عملیات‌های ناتمام را در هر اتصال بالادست محدود خواهد کرد. به همین ترتیب، max-pending-ops تعداد کل عملیات‌های ناتمام را در تمام اتصالات بک‌اند محدود می‌کند؛ مقدار 0، که پیش‌فرض است، به این معنی است که هیچ محدودیتی برای این بک‌اند اعمال نخواهد شد.

پارامتر starttls استفاده از عملیات توسعه‌یافته StartTLS را برای برقراری یک نشست TLS پیش از اتصال (Binding) به ارائه‌دهنده مشخص می‌کند. اگر آرگومان critical ارائه شود، در صورت شکست درخواست StartTLS، نشست لغو خواهد شد. در غیر این صورت نشست syncrepl بدون TLS ادامه می‌یابد. تنظیم tls_reqcert به طور پیش‌فرض "demand" است و سایر تنظیمات TLS به طور پیش‌فرض همانند تنظیمات اصلی TLS در slapd هستند.

مثال‌ها (EXAMPLES)

در اینجا نمونه کوتاهی از یک فایل پیکربندی آورده شده است:

argsfile  /var/lib/openldap/run/lloadd.args
pidfile   /var/lib/openldap/run/lloadd.pid
# هنوز cancel پشتیبانی نمی‌شود
restrict_exop 1.3.6.1.1.8 reject
# turn پشتیبانی نمی‌شود
restrict_exop 1.3.6.1.1.19 reject
# TXN Exop در صورت تمایل، در غیر این صورت reject
restrict_exop 1.3.6.1.1.21.1 connection
# کنترل Paged results
restrict_control 1.2.840.113556.1.4.319 connection
# کنترل VLV
restrict_control 2.16.840.1.113730.3.4.9 connection
bindconf
    bindmethod=simple
    binddn=cn=test
    credentials=pass
tier weighted
backend-server
    uri=ldap://ldap1.example.com
    numconns=3
    bindconns=2
    retry=5000
    max-pending-ops=5
    conn-max-pending=3
    weight=5
backend-server
    uri=ldap://ldap2.example.com
    numconns=3
    bindconns=2
    retry=5000
    max-pending-ops=5
    conn-max-pending=3
    weight=10

راهنمای «OpenLDAP Administrator's Guide» حاوی نمونه طولانی‌تر و همراه با یادداشت‌های توضیحی از یک فایل پیکربندی است. فایل اصلی /etc/openldap/lloadd.conf نمونه دیگری است.

محدودیت‌ها (LIMITATIONS)

پشتیبانی از پروکسی کردن SASL Binds محدود به مکانیزم EXTERNAL (و تنها برای استخراج DN گواهی TLS کلاینت در صورتی که در آخرین مذاکره مجدد استفاده شده باشد) و مکانیزم‌هایی است که نه به فراداده‌های اتصال متکی هستند (مانند کاری که Kerberos انجام می‌دهد) و نه یک لایه یکپارچگی/محرمانگی SASL برقرار می‌کنند (مجدداً، برخی مکانیزم‌های Kerberos و DIGEST-MD5 می‌توانند این را مذاکره کنند).

فایل‌ها (FILES)

/etc/openldap/lloadd.conf

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

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

ldap(3)، gnutls-cli(1)، slapd.conf(5)، tcp(7)، lloadd(8)، slapd(8).

"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin)

قدردانی‌ها (ACKNOWLEDGEMENTS)

نرم‌افزار OpenLDAP توسط پروژه OpenLDAP در http://www.openldap.org توسعه یافته و نگهداری می‌شود. نرم‌افزار OpenLDAP از انتشار LDAP 3.3 دانشگاه میشیگان برگرفته شده است.