| SLAPO-PCACHE(5) | فایلهای پیکربندی | SLAPO-PCACHE(5) |
نام (NAME)
slapo-pcache - افزونه کشگذاری پروکسی برای دیمن slapd
خلاصه (SYNOPSIS)
/etc/ldap/slapd.conf
توضیحات (DESCRIPTION)
افزونه روکش slapo-pcache پاسخهای پرسوجوهای LDAP را در سطح پروکسی کشگذاری میکند تا سرعت پاسخدهی به کلاینتها بهبود یابد.
روکش pcache برای slapd(8) امکان کشگذاری درخواستهای جستجوی LDAP (پرسوجوها) را در یک پایگاه داده محلی فراهم میکند. برای یک پرسوجوی ورودی، کش پروکسی الگوی متناظر (template) با آن را مشخص میکند. اگر الگو با استفاده از دستور pcacheTemplate به عنوان قابل کشگذاری تعیین شده باشد و درخواست درون یک درخواست کششده قرار داشته باشد، پاسخ از طریق کش پروکسی داده میشود. در غیر این صورت، جستجو مانند روال معمول انجام شده و نتایج جستجوی قابل کشگذاری برای استفاده در پرسوجوهای آینده در کش ذخیره میشوند.
یک الگو توسط یک رشته فیلتر و یک نمایه که مجموعهای از ویژگیها را مشخص میکند تعریف میشود. رشته الگو برای یک پرسوجو را میتوان با حذف مقادیر گزاره از نمایش RFC 4515 فیلتر جستجوی آن به دست آورد. یک پرسوجو زمانی به یک الگو تعلق دارد که رشته الگو و مجموعه ویژگیهای پیشبینیشده آن با یک الگوی قابل کشگذاری مطابقت داشته باشد. نمونههایی از رشتههای الگو عبارتند از (mail=)، (|(sn=)(cn=)) و (&(sn=)(givenName=)).
دستورهای پیکربندی که مختص روکش pcache هستند را میتوان با پیشوند pcache- مشخص کرد تا از تداخل با دستورهای مختص پایگاه داده زیرین یا سایر روکشهای روی هم قرارگرفته جلوگیری شود. این امر بهویژه برای دستورهایی که به بخش بکاند مورد استفاده برای ذخیرهسازی محلی اشاره دارند مفید است. دستورهای اختصاصی زیر را میتوان برای پیکربندی کش پروکسی استفاده کرد:
- overlay pcache
- این دستور روکش کش پروکسی را به بکاند فعلی اضافه میکند. روکش کش پروکسی میتواند با هر بکاَندی استفاده شود اما برای استفاده با بکاندهای ldap، meta و sql طراحی شده است. لطفاً توجه داشته باشید که بکاند زیرین باید یک rootdn پیکربندیشده داشته باشد.
- pcache <database> <max_entries> <numattrsets> <entry_limit> <cc_period>
- این دستور کش پروکسی را در بکاند فعلی فعال کرده و پارامترهای عمومی کش را تنظیم میکند. یک بکاند <database> بهصورت داخلی برای نگهداری مدخلهای کششده استفاده خواهد شد. پایگاه داده انتخابی نیز همانطور که در زیر نشان داده شده است باید پیکربندی شود. زمانی که اندازه کش به <max_entries> مدخل برسد، فرایند جایگزینی کش فراخوانی میشود و تا زمانی که اندازه کش به زیر این مقدار کاهش یابد ادامه مییابد. مقدار <numattrsets> باید برابر با تعداد دستورهای pcacheAttrset بعدی باشد. پرسوجوها تنها در صورتی کش میشوند که با یک الگوی قابل کشگذاری (مشخصشده توسط دستور pcacheTemplate) مطابقت داشته باشند و تعداد مدخلهای بازگرداندهشده کمتر از <entry_limit> باشد. بررسی سازگاری در هر دوره زمانی <cc_period> (به ثانیه) انجام میشود. در هر چرخه، پرسوجوهایی که «طول عمر (TTL)» آنها منقضی شده حذف میشوند. یک نمونه پیکربندی کش به این صورت است:
- pcacheAttrset <index> <attrs...>
- برای پیوند دادن مجموعهای از ویژگیها <attrs..> با یک نمایه <index> استفاده میشود. هر مجموعه ویژگی با یک عدد صحیح از 0 تا <numattrsets>-1 مرتبط است. این نمایهها توسط دستور pcacheTemplate برای تعریف الگوهای قابل کشگذاری استفاده میشوند. یک مجموعه از ویژگیها نمیتواند خالی باشد. یک مجموعه ویژگی میتواند حاوی ویژگیهای خاص "*" (تمام ویژگیهای کاربر)، "+" (تمام ویژگیهای عملیاتی) یا هر دو باشد؛ در حالت دوم، هر ویژگی دیگر اضافی است و برای وضوح باید از آن اجتناب شود. یک مجموعه ویژگی میتواند "1.1" را به عنوان تنها ویژگی داشته باشد؛ در این حالت، فقط حضور مدخلها کش میشود. ویژگیهایی که با "undef:" پیشوند دارند نیازی نیست در طرحواره (schema) وجود داشته باشند. کلمه کلیدی "undef" نمیتواند با بکاند slapd-mdb(5) استفاده شود زیرا این بکاند نیازمند آن است که تمامی عناصر طرحواره بهطور کامل تعریف شده باشند.
- pcacheMaxQueries <queries>
- حداکثر تعداد پرسوجوهایی که باید کش شوند را مشخص میکند. مقدار پیشفرض 10000 است.
- pcacheValidate { TRUE | FALSE }
- بررسی میکند که آیا نتایج یک پرسوجوی در حال کش شدن واقعاً میتوانند توسط DSA پروکسی از کش بازگردانده شوند یا خیر. در صورت فعال بودن، مدخلهایی که هنگام کشگذاری نتایج پرسوجو بازگردانده میشوند بررسی میشوند تا از سازگاری آنها با طرحواره شناختهشده برای DSA پروکسی اطمینان حاصل شود. در صورت عدم موفقیت، پرسوجو کش نمیشود. بهطور پیشفرض، این بررسی غیرفعال است.
- pcacheOffline { TRUE | FALSE }
- کش را در حالت برونخط (آفلاین) قرار میدهد. در حالت آفلاین، بررسیکننده سازگاری متوقف شده و هیچ انقضایی رخ نخواهد داد. این به محتویات کش اجازه میدهد تا زمانی که دسترسی شبکه پروکسی به DSA راه دور قطع است، بهطور نامحدود مورد استفاده قرار گیرند. مقدار پیشفرض FALSE است، یعنی بررسیهای سازگاری و انقضا انجام خواهند شد.
- pcachePersist { TRUE | FALSE }
- مشخص
میکند که
آیا
پرسوجوهای
کششده
باید در
هنگام
راهاندازیهای
مجدد
پروکسی
ذخیره شوند
تا
راهاندازی
سریع (hot startup) کش
فراهم گردد.
فقط
پرسوجوهای
منقضینشده
دوباره
بارگذاری
میشوند.
مقدار
پیشفرض FALSE
است.
هشدار: البته، پیکربندی کش پروکسی نباید در هنگام راهاندازیهای مجدد تغییر کند؛ روکش pcache هیچ بررسی سازگاری در این خصوص انجام نمیدهد. بهطور خاص، این گزینه باید غیرفعال بماند مگر اینکه دستورهای pcacheAttrset و pcacheTemplate موجود نه در ترتیب و نه در محتوا تغییر نکرده باشند. اگر مجموعهها و الگوهای جدیدی اضافه شوند یا سایر جزئیات پیکربندی روکش pcache تغییر کند، این ویژگی نباید تحت تأثیر قرار گیرد.
- pcacheTemplate <template_string> <attrset_index> <ttl> [<negttl> [<limitttl> [<ttr>]]]
- یک الگوی قابل کشگذاری و «طول عمر» <ttl> پرسوجوهای متعلق به آن الگو را مشخص میکند. پارامتر اختیاری <negttl> میتواند برای تعیین این مورد استفاده شود که نتایج منفی (یعنی پرسوجوهایی که صفر مدخل بازگرداندهاند) نیز باید برای مدت زمان مشخصشده کش شوند. نتایج منفی بهطور پیشفرض کش نمیشوند (مقدار <negttl> روی 0 تنظیم است). پارامتر اختیاری <limitttl> میتواند برای تعیین این مورد استفاده شود که نتایجی که به محدودیت اندازه (sizelimit) برخورد میکنند نیز باید برای مدت زمان مشخصشده کش شوند. نتایجی که به محدودیت اندازه برخورد میکنند بهطور پیشفرض کش نمیشوند (مقدار <limitttl> روی 0 تنظیم است). پارامتر اختیاری <ttr> یا «زمان تازهسازی» میتواند برای تعیین این مورد استفاده شود که مدخلهای کششده باید پس از زمان معینی بهطور خودکار تازهسازی شوند. مدخلها تنها تا زمانی که منقضی نشده باشند تازهسازی میشوند، بنابراین برای اینکه این گزینه مفید باشد مقدار <ttl> باید بزرگتر از <ttr> باشد. مدخلها بهطور پیشفرض تازهسازی نمیشوند (مقدار <ttr> روی 0 تنظیم است).
- pcacheBind <filter_template> <attrset_index> <ttr> <scope> <base>
- یک الگو برای کشگذاری اعتبارسنجی Simple Bind بر اساس یک pcacheTemplate از پیش تعریفشده مشخص میکند. پارامتر <filter_template> مشابه <template_string> است، به جز اینکه ممکن است مقادیری در آن وجود داشته باشد. هدف آن این است که به روکش اجازه دهد فیلترهایی مشابه آنچه برنامههای دیگر بلافاصله قبل از Bind هنگام جستجو تولید میکنند، ایجاد کند. برای مثال، اگر کلاینتی مانند nss_ldap برای جستجوی یک کاربر با فیلتر "(&(objectClass=posixAccount)(uid=<username>))" پیکربندی شده باشد، الگوی متناظر "(&(objectClass=posixAccount)(uid=))" باید در اینجا استفاده شود. زمانی که به یک الگوی معمولی تبدیل میشود مانند "(&(objectClass=)(uid=))"، این الگو و <attrset_index> باید با یک عبارت pcacheTemplate تعریفشده مطابقت داشته باشند. «زمان تازهسازی» <ttr> فاصله زمانی را تعیین میکند که پس از آن اطلاعات اعتبارسنجی کششده ممکن است تازهسازی شوند. اولین درخواست Bind که پس از آن زمان رخ دهد، تلاش برای تازهسازی را آغاز میکند. زمانی که روکش در حالت آفلاین است، تازهسازی انجام نمیشود. هیچ پارامتر «طول عمر» برای اطلاعات اعتبارسنجی Bind وجود ندارد؛ اطلاعات اعتبارسنجی بر اساس ttl مربوط به pcacheTemplate منقضی میشوند. پارامترهای <scope> و <base> باید با محدوده جستجو و پایهای که توسط کلاینتهای احراز هویت استفاده میشود مطابقت داشته باشند. اطلاعات اعتبارسنجی کششده به صورت متن خام ذخیره نمیشوند، بلکه با استفاده از درهمساز پیشفرض گذرواژه هش میشوند. بهطور پیشفرض کشگذاری Bind فعال نیست.
- pcachePosition { head | tail }
- مشخص میکند که آیا فراخوانی بازگشتی پاسخ باید در tail (پیشفرض) یا در head (در واقع، هر جا که توالی چیدمان پشته آن را قرار دهد) از فهرست فراخوانیهای بازگشتی قرار گیرد. این بر نحوه تعامل روکش با سایر روکشها تأثیر میگذارد، زیرا روکش proxycache باید تا حد امکان زود اجرا شود (و بنابراین تا حد امکان دیر پیکربندی شود) تا شانس بازگرداندن نتایج کششده را داشته باشد؛ با این حال، اگر در پاسخ زودهنگام اجرا شود، مدخلهایی را کش میکند که ممکن است بعداً توسط سایر پایگاههای داده تغییر یابند و بنابراین در اولین بار پس از پردازش و هنگام کش شدن قبل از پردازش بازگردانده شوند.
- چند محدودیت وجود دارد:
-
تمام مقادیر باید مثبت باشند؛
<entry_limit> باید کمتر یا مساوی با <max_entries> باشد؛
باید تعداد <numattrsets> مجموعه ویژگی با استفاده از دستور pcacheAttrset تعریف شده باشد؛
تمام مجموعههای ویژگی باید حداقل توسط یک دستور pcacheTemplate مورد ارجاع قرار گرفته باشند؛
مثال زیر یک الگو با رشته فیلتر (&(sn=)(givenName=)) و ویژگیهای mail، postaladdress، telephonenumber و TTL یک ساعت اضافه میکند:
pcacheAttrset 0 mail postaladdress telephonenumber pcacheTemplate (&(sn=)(givenName=)) 0 3600
دستورهای پیکربندی پایگاه داده زیرین نیز باید همانند نمونه زیر مشخص شوند:
directory /var/tmp/cache maxsize 1073741824
میتوان از هر دستور معتبری برای نوع پایگاه داده انتخابشده استفاده کرد. نمایهسازی باید متناسب با پرسوجوهای در حال انجام اعمال شود. علاوه بر این، یک نمایه برابری (equality index) روی ویژگی pcacheQueryid باید پیکربندی شود تا به حذف دادههای پرسوجوی منقضیشده کمک کند.
سازگاری با نسخههای پیشین (BACKWARD COMPATIBILITY)
کلمات کلیدی پیکربندی تغییر نام یافتهاند و شکل قدیمیتر منسوخ شده است. این کلمات کلیدی قدیمی همچنان شناسایی میشوند اما ممکن است در نسخههای بعدی حذف شوند.
- proxycache
- استفاده از pcache
- proxyattrset
- استفاده از pcacheAttrset
- proxycachequeries
- استفاده از pcacheMaxQueries
- proxycheckcacheability
- استفاده از pcacheValidate
- proxysavequeries
- استفاده از pcachePersist
- proxytemplate
- استفاده از pcacheTemplate
- response-callback
- استفاده از pcachePosition
هشدارها (CAVEATS)
کشگذاری دادهها مستعد ناسازگاری است زیرا بهروزرسانیهای روی سرور راه دور، حداقل (و حداکثر) به مدت زمان TTL دستور pcacheTemplate در پاسخ کش منعکس نخواهند شد. این ناسازگاریها را میتوان با استفاده دقیق از TTR به حداقل رساند.
روکش کش پروکسی برای عملکرد صحیح به یک مجموعه کامل از نتایج دادهها نیاز دارد. بنابراین، اگر کنترل نتایج صفحهبندیشده (paged results control) توسط کلاینت درخواست شود، آن را حذف خواهد کرد.
سرور راه دور باید ویژگی objectClass را در دسترس قرار دهد زیرا پایگاه داده زیرین که در واقع مدخلها را کش میکند ممکن است برای پردازش محلی بهینه پرسوجوها به آن نیاز داشته باشد.
سرور پروکسی باید شامل تمام اطلاعات طرحواره مورد نیاز برای کشگذاری باشد. بهطور خاص، به طرحواره ویژگیهای مورد استفاده در الگوهای پرسوجو نیاز دارد. اگر ویژگی objectClass در یک الگوی پرسوجو استفاده شده باشد، به تعریف objectClassهای مدخلهایی که قرار است کش کند نیاز دارد. مسئولیت هماهنگ نگه داشتن طرحواره پروکسی با سرور پروکسیشده بر عهده مدیر پروکسی است.
ناسازگاری بالقوه (و ظریف) دیگری ممکن است زمانی رخ دهد که دادهها با هویتهای متفاوتی واکشی شوند و کنترل دسترسی خاص به ازای هر هویت توسط سرور راه دور اعمال شود. اگر دادهها با هویتی بازیابی شده باشند که به دلیل اعمال قوانین دسترسی در سرور راه دور تنها نتایج جزئی را جمعآوری کرده است، سایر کاربران با امتیازات دسترسی متفاوت در سرور راه دور، نتایج متفاوتی را از سرور راه دور و از کش دریافت خواهند کرد. اگر آن کاربران دارای امتیازات دسترسی بالاتری در سرور راه دور باشند، تنها زیرمجموعهای از نتایجی را که مستقیماً از سرور راه دور دریافت میکردند از کش دریافت خواهند کرد؛ اما اگر امتیازات دسترسی پایینتری داشته باشند، فرامجموعهای از نتایجی را که مستقیماً از سرور راه دور میگرفتند از کش دریافت خواهند کرد. هر دو حالت بسته به سیاست امنیتی کش و سرور راه دور ممکن است قابل قبول یا غیرقابل قبول باشند. مهم است توجه داشته باشید که در این حالت پروکسی با افشای دادههایی که توسط یک هویت دیگر جمعآوری شده است به یک هویت، امنیت سرور راه دور را نقض میکند. به همین دلیل، پیشنهاد میشود هنگام استفاده از back-ldap، کشگذاری پروکسی همراه با ویژگی identity assertion در slapd-ldap(5) (دستورهای idassert-bind و idassert-authz را ببینید) استفاده شود، تا پرسوجوی سرور راه دور با یک هویت پایه انجام شود که دارای امتیازات دسترسی نسبتاً بالای search و read است و کنترل دسترسی «واقعی» به ACLهای پروکسی واگذار شود. توجه داشته باشید که از آنجا که تنها بخش کششده از دادههای واقعی در دسترس کش قرار دارد، ممکن است امکان اعمال همان قوانین دسترسی که روی سرور راه دور تعریف شدهاند وجود نداشته باشد. هنگامی که امنیت مطرح است، دسترسی پروکسی کششده باید با دقت تنظیم شود.
فایلها (FILES)
- /etc/ldap/slapd.conf
- فایل پیکربندی پیشفرض slapd
همچنین ببینید (SEE ALSO)
slapd.conf(5)، slapd-config(5)، slapd-ldap(5)، slapd-meta(5)، slapd-sql(5)، slapd(8).
نویسندگان (AUTHORS)
در ابتدا توسط Apurva Kumar به عنوان افزونهای برای back-meta پیادهسازی شد؛ سپس توسط Howard Chu به یک روکش تبدیل گردید.
| مه ۲۰۲۵ | OpenLDAP |