MEMCACHE_TABLE(5) File Formats Manual MEMCACHE_TABLE(5)

memcache_table - پیکربندی کلاینت memcache در Postfix

postmap -q "string" memcache:/etc/postfix/filename
postmap -q - memcache:/etc/postfix/filename <inputfile


سیستم ایمیل Postfix از جدول‌های اختیاری برای بازنویسی آدرس یا مسیریابی ایمیل استفاده می‌کند. این جدول‌ها معمولاً در قالب‌های lmdb:، cdb:، hash: یا dbm: هستند.

به عنوان جایگزین، جدول‌های جستجو می‌توانند به صورت نمونه‌های memcache مشخص شوند. برای استفاده از جستجوهای memcache، یک منبع memcache را به عنوان جدول جستجو در main.cf تعریف کنید؛ برای مثال:

virtual_alias_maps = memcache:/etc/postfix/memcache-aliases.cf

فایل /etc/postfix/memcache-aliases.cf ساختاری مشابه با فایل main.cf در Postfix دارد و پارامترهای شرح داده‌شده در ادامه را مشخص می‌کند.

کلاینت memcache در Postfix از عملیات‌های جستجو (lookup)، به‌روزرسانی (update)، حذف (delete) و توالی (sequence یا first/next) پشتیبانی می‌کند. عملیات توالی نیازمند یک پایگاه‌داده پشتیبان است که از این عملیات پشتیبانی کند.

سرور memcache (توجه: به صورت مفرد) که Postfix تلاش می‌کند به آن متصل شود. برای یک سرور TCP، مقدار "inet:" و به دنبال آن یک نام میزبان یا آدرس، ":"، و نام یا شماره پورت را مشخص کنید. آدرس IPv6 را درون "[]" مشخص کنید. برای یک سرور در دامنه یونیکس (UNIX-domain) مقدار "unix:" و به دنبال آن مسیر سوکت را مشخص کنید. مثال‌ها: 
memcache = inet:memcache.example.com:11211
memcache = inet:127.0.0.1:11211
memcache = inet:[fc00:8d00:189::3]:11211
memcache = unix:/path/to/socket

نکته: برای دسترسی به یک سوکت UNIX-domain با سرور proxymap(8)، سوکت باید توسط کاربر غیرممتاز postfix قابل دسترسی باشد.

یک پایگاه‌داده اختیاری در Postfix که پشتیبان پایداری برای پایگاه‌داده memcache فراهم می‌کند. کلاینت memcache در Postfix هر زمان که اطلاعاتی را در پایگاه‌داده پایدار جستجو کرده یا تغییر دهد، پایگاه‌داده memcache را نیز به‌روزرسانی می‌کند. یک پایگاه‌داده Postfix از نوع "type:table" را مشخص کنید. مثال‌ها: 
# کش postscreen غیرمشترک.
backup = btree:/var/lib/postfix/postscreen_cache_map
# کش postscreen مشترک برای فرآیندهای روی همان میزبان.
backup = proxy:btree:/var/lib/postfix/postscreen_cache_map

دسترسی به سرورهای راه دور proxymap در حال توسعه است.

نکته ۱: هنگام به اشتراک گذاشتن کش پایدار postscreen(8) یا verify(8)، پاکسازی خودکار کش را غیرفعال کنید (تنظیم *_cache_cleanup_interval = 0 را اعمال کنید)، مگر با یک نمونه از Postfix که مسئول پاکسازی کش خواهد بود.

نکته ۲: هنگامی که چندین جدول از یک پایگاه‌داده memcache مشترک استفاده می‌کنند، هر جدول باید از قابلیت key_format (در ادامه ببینید) برای افزودن رشته یکتای خود به ابتدای کلید جستجو استفاده کند. در غیر این صورت، پاکسازی خودکار کش postscreen(8) یا verify(8) ممکن است کار نکند.

نکته ۳: هنگامی که به پایگاه‌داده پشتیبان با جستجوهای "proxy:" دسترسی پیدا می‌شود، نام کامل پایگاه‌داده پشتیبان (شامل پیشوند "proxy:") باید در تنظیمات proxy_read_maps یا proxy_write_maps سرور proxymap مشخص شود (بسته به این‌که دسترسی فقط‌خواندنی است یا خواندنی-نوشتنی).

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

نکته ۱: هنگام استفاده از جدول memcache به عنوان کش postscreen(8) یا verify(8) بدون پشتیبان پایدار، مقدار صفر را برای *_cache_cleanup_interval در تمام نمونه‌های Postfix که از memcache استفاده می‌کنند مشخص کرده، و بزرگترین مقدار *_ttl در postscreen(8) یا مقدار *_expire_time در verify(8) را به عنوان مقدار ttl جدول memcache تعیین کنید.

نکته ۲: بر اساس مستندات پروتکل memcache، مقداری بزرگتر از ۳۰ روز (۲۵۹۲۰۰۰ ثانیه) بیانگر زمان مطلق یونیکس (UNIX time) است. مقادیر کوچکتر نسبت به زمان به‌روزرسانی سنجیده می‌شوند.

پس از پردازش تنظیمات key_format و پیش از ارسال درخواست به سرور memcache، کلید را از طریق الگوریتم خلاصه پیام (message digest) مشخص‌شده پردازش کرده و نتیجه را به حروف هگزادسیمال کوچک تبدیل می‌کند. این کار از خطای دسترسی به پایگاه‌داده در مواقعی که ممکن است طول کلیدها از محدودیت طول کلید در سرور memcache (معمولاً ۲۵۰ بایت) فراتر رود، جلوگیری می‌کند. نام الگوریتم خلاصه پیامی را که توسط OpenSSL پشتیبانی می‌شود، به عنوان مثال sha256، مشخص کنید.

این قابلیت در Postfix نسخه 3.11 و بالاتر در دسترس است و مستلزم آن است که Postfix با پشتیبانی از TLS ساخته شده باشد.

قالب کلیدهای جستجو و به‌روزرسانی که کلاینت memcache در Postfix به سرور memcache ارسال می‌کند. به طور پیش‌فرض، این کلیدها با کلیدهای جستجو و به‌روزرسانی که کلاینت memcache از برنامه‌های Postfix دریافت می‌کند یکسان هستند.

نکته ۱: قابلیت key_format برای درخواست‌های پایگاه‌داده backup استفاده نمی‌شود.

نکته ۲: هنگامی که چندین جدول از یک پایگاه‌داده memcache مشترک استفاده می‌کنند، هر جدول باید رشته یکتای خود را به ابتدای کلید جستجو اضافه کند. در غیر این صورت، پاکسازی خودکار کش postscreen(8) یا verify(8) ممکن است کار نکند.

مثال‌ها:

key_format = aliases:%s
key_format = verify:%s
key_format = postscreen:%s

پارامتر key_format از بسط‌های '%' زیر پشتیبانی می‌کند:

%%
با یک نویسه '%' واقعی جایگزین می‌شود.
%s
با کلید ورودی کلاینت memcache جایگزین می‌شود.
%u
هنگامی که کلید ورودی آدرسی به فرم user@domain باشد، %u با بخش محلی (localpart) آدرس که طبق قواعد SQL نقل‌قول شده است جایگزین می‌شود. در غیر این صورت، %u با کل رشته جستجو جایگزین می‌شود. اگر بخش محلی خالی باشد، جستجو بدون هیچ پیامی نادیده گرفته شده و نتیجه‌ای برنمی‌گرداند (به‌روزرسانی با یک هشدار نادیده گرفته می‌شود).
%d
هنگامی که کلید ورودی آدرسی به فرم user@domain باشد، %d با بخش دامنه آدرس جایگزین می‌شود. در غیر این صورت، جستجو بدون هیچ پیامی نادیده گرفته شده و نتیجه‌ای برنمی‌گرداند (به‌روزرسانی با یک هشدار نادیده گرفته می‌شود).
%[SUD]
معادل‌های حروف بزرگ بسط‌های فوق در پارامتر key_format رفتاری دقیقاً مشابه با همتایان حروف کوچک خود دارند.
%[1-9]
الگوهای %1، %2، ... %9 با مؤلفه بااهمیت‌تر مربوطه از دامنه کلید ورودی جایگزین می‌شوند. اگر کلید ورودی user@mail.example.com باشد، آن‌گاه %1 برابر با com، %2 برابر با example و %3 برابر با mail خواهد بود. اگر کلید ورودی فاقد صلاحیت باشد یا مؤلفه‌های دامنه کافی برای برآورده کردن تمام الگوهای مشخص‌شده نداشته باشد، جستجو بدون هیچ پیامی نادیده گرفته شده و نتیجه‌ای برنمی‌گرداند (به‌روزرسانی با یک هشدار نادیده گرفته می‌شود).
این قابلیت می‌تواند بار سرور پایگاه‌داده را به طور چشمگیری کاهش دهد. فهرستی از نام‌های دامنه، مسیر فایل‌ها یا پایگاه‌های داده "type:table" را مشخص کنید. در صورت تعیین، تنها کلیدهای جستجوی کاملاً واجد شرایط با یک بخش محلی *غیرخالی* و یک دامنه منطبق، واجد شرایط جستجو یا به‌روزرسانی خواهند بود: جستجوهای صرف 'user'، جستجوهای صرف دامنه و جستجوهای "@domain" بدون هیچ پیامی نادیده گرفته می‌شوند (به‌روزرسانی‌ها با یک هشدار نادیده گرفته می‌شوند). مثال: 
domain = example.com, hash:/etc/postfix/searchdomains

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


کلاینت memcache در Postfix نمی‌تواند برای جدول‌های حساس از نظر امنیتی مانند alias_maps (که ممکن است حاوی مقصدهای "|command" و "/file/name" باشند)، یا virtual_uid_maps، virtual_gid_maps و virtual_mailbox_maps (که امتیازات فرآیند یونیکس را برای مقصدهای "/file/name" تعیین می‌کنند) استفاده شود. در یک پیاده‌سازی معمول، پایگاه‌داده memcache توسط هر فرآیندی که بتواند با سرور memcache ارتباط برقرار کند قابل نوشتن است؛ در مقابل، جدول‌های حساس امنیتی هرگز نباید توسط کاربر غیرممتاز Postfix قابل نوشتن باشند.

کلاینت memcache در Postfix هنگام استفاده به عنوان کش postscreen(8) یا verify(8) به پیکربندی اضافی نیاز دارد. برای جزئیات بیشتر به توضیحات پارامترهای backup و ttl در بخش «پارامترهای اصلی MEMCACHE (MEMCACHE MAIN PARAMETERS)» در بالا مراجعه کنید.

postmap(1)، مدیر جدول‌های جستجوی Postfix
postconf(5)، پارامترهای پیکربندی

برای یافتن این اطلاعات از "postconf readme_directory" یا "postconf html_directory" استفاده کنید.

DATABASE_README، بررسی اجمالی جدول‌های جستجوی Postfix
MEMCACHE_README، راهنمای کلاینت memcache در Postfix

مجوز Secure Mailer باید همراه با این نرم‌افزار توزیع شود.



پشتیبانی از memcache در نسخه 2.9 پُست‌فیکس (Postfix) معرفی شد.

Wietse Venema
IBM T.J. Watson Research
P.O. Box 704
Yorktown Heights, NY 10598, USA
Wietse Venema
Google, Inc.
111 8th Avenue
New York, NY 10011, USA