CONTROL.CTL(5) InterNetNews Documentation CONTROL.CTL(5)

control.ctl - تعیین نحوه رسیدگی به پیام‌های کنترلی یوزنت

پرونده pathetc/control.ctl برای تعیین اقداماتی که هنگام دریافت یک پیام کنترلی انجام می‌شود به کار می‌رود. این پرونده توسط controlchan خوانده می‌شود که معمولاً به عنوان یک برنامه کانال توسط innd فراخوانی می‌گردد. هنگامی که control.ctl تغییر می‌کند، controlchan به صورت خودکار متوجه آن شده و آن را مجدداً بارگذاری می‌نماید.

اگر یک پرونده control.ctl.local در pathetc وجود داشته باشد، پس از control.ctl توسط controlchan خوانده می‌شود (رفتار حاصل به‌گونه‌ای است که گویی محتویات control.ctl.local در انتهای control.ctl قرار دارد). این پرونده محلی همانند control.ctl قالب‌بندی شده و هدف از آن نگهداری سفارشی‌سازی‌های محلی است. همچنین این پرونده در صورت تغییر، به صورت خودکار مجدداً بارگذاری می‌شود.

خطوط خالی و خطوطی که با علامت هش ("#") آغاز می‌شوند نادیده گرفته خواهند شد. تمامی خطوط دیگر باید شامل چهار فیلد باشند که با دو‌نقطه از هم جدا شده‌اند:

<type>:<from>:<newsgroups>:<action>

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

فیلد نخست، <type>، نوع پیام کنترلی است که این خط برای آن معتبر است. این فیلد یا باید نام یک پیام کنترلی باشد یا کلمه "all" تا مشخص کند که برای تمامی پیام‌های کنترلی اعمال می‌شود. علاوه بر این، انواع ویژه زیر نیز پشتیبانی می‌شوند:

/encoding/
این نوع، کدگذاری پیام‌های کنترلی newgroup و checkgroups را مشخص می‌کند تا توضیحات جدید به شیوه صحیح رمزگشایی شوند. 
/encoding/:*:cn.*:gb18030

بدین معناست که توضیحات مربوط به یک گروه خبری در سلسله‌مراتب چینی cn.* به‌گونه‌ای رمزگشایی می‌شود که گویی در GB18030 کدگذاری شده است، مگر اینکه یک مجموعه نویسه در پیام کنترلی مشخص شده باشد (در چنین حالتی، مجموعه نویسه ذکرشده در پیام استفاده خواهد شد). با این حال، اگر "=force" به انتهای کدگذاری پیوست شود، امکان بازنویسی مجموعه نویسه ذکرشده وجود دارد. برای نمونه،

/encoding/:*:scout.forum.chinese:big5=force

بدین معناست که توضیحات مربوط به scout.forum.chinese همیشه به گونه‌ای رمزگشایی خواهد شد که گویی با Big5 کدگذاری شده است، بدون توجه به اینکه مجموعه نویسه پیام کنترلی مربوطه چه باشد.

مقدار پیش‌فرض در زمانی که هیچ کدگذاری ذکر نشده باشد (یا زمانی که کدگذاری مشخص‌شده ناشناخته باشد) "CP1252" است.

آخرین خط منطبق برای یک نام گروه خبری مشخص در control.ctl مورد استفاده قرار خواهد گرفت.

/localencoding/
هنگامی که این نوع استفاده می‌شود، خط تنها شامل دو فیلد خواهد بود. مقدار پیش‌فرض در زمانی که این نوع در control.ctl ظاهر نشود (یا هنگامی که مجموعه نویسه مشخص‌شده ناشناخته باشد) معادل موارد زیر است: 
/localencoding/:utf-8

این بدان معناست که توضیحات جدید در پرونده newsgroups با استفاده از UTF-8 نوشته خواهند شد. و controlchan سعی خواهد کرد تا توضیحات موجود را به گونه‌ای بخواند که گویی با UTF-8 کدگذاری شده‌اند تا مشخص شود آیا باید به‌روزرسانی شوند یا خیر.

آخرین خط منطبق در control.ctl مورد استفاده قرار خواهد گرفت.

/maxdocheckgroups/
این نوع، حداکثر تعداد تغییراتی را که یک پیام checkgroups می‌تواند پیش از انصراف و ارسال تغییرات به مدیر از طریق ایمیل در صورت عدم تعیین پرونده لاگ به صورت همزمان اعمال کند، مشخص می‌نماید. مقدار پیش‌فرض "10" است. 
/maxdocheckgroups/:*:*:10
/maxdocheckgroups/:*:fr.*:20

چنین پیکربندی‌ای بدین معناست که یک پیام checkgroups حاوی ۱۵ تغییر برای سلسله‌مراتب فرانسوی fr.* (گروه‌های خبری جدید برای افزودن، حذف یا تغییر وضعیت) به طور خودکار پذیرفته و اعمال خواهد شد، در حالی که برای پیام checkgroups حاوی ۱۵ تغییر برای france.*، تغییرات لازم صرفاً ایمیل یا در لاگ ثبت خواهند شد.

آخرین خط منطبق برای یک نام گروه خبری مشخص در control.ctl استفاده خواهد شد.

فیلد دوم، <from>، یک الگوی سبک پوسته است که با نشانی ایمیل فرد ارسال‌کننده پیام مطابقت داده می‌شود (به طوری که نشانی ابتدا به حروف کوچک تبدیل می‌گردد). این تطبیق با قوانینی معادل دستور case در پوسته انجام می‌گیرد؛ برای جزئیات بیشتر به sh(1) مراجعه کنید.

اگر پیام کنترلی از نوع newgroup یا rmgroup باشد، فیلد سوم، <newsgroups>، یک الگوی سبک پوسته است که با گروه خبری تحت تأثیر پیام کنترلی مطابقت داده می‌شود (به‌ویژه "?" دقیقاً با یک نویسه، "*" با صفر یا چند نویسه مطابقت دارد و "|" اجازه تطبیق چندین الگو را در یک خط می‌دهد -- به عنوان مثال "comp.*|humanities.*" با هر گروه خبری که نام آن با "comp." یا "humanities." آغاز شود مطابقت خواهد داشت). اگر پیام کنترلی از نوع checkgroups باشد، فیلد سوم یک الگوی سبک پوسته است که گروه‌های خبری مورد نیاز برای بررسی را مطابقت می‌دهد. اگر پیام کنترلی از هر نوع دیگری باشد، فیلد سوم نادیده گرفته می‌شود.

فیلد چهارم، <action>، مشخص می‌کند که چه اقدامی در رابطه با پیام‌های کنترلی منطبق بر این خط باید انجام شود. اقدامات زیر شناخته‌شده هستند:

اقدام درخواست‌شده توسط پیام کنترلی باید اجرا شود. این بدان معناست که تغییرات به صورت خاموش و بی‌صدا اعمال خواهند شد. برای پیام‌های checkgroups، بسته به مقدار /maxdocheckgroups/، دستورات پوسته‌ای که باید اجرا شوند ممکن است به جای اجرا، برای مدیر اخبار (آرگومان ورودی به --with-news-master در زمان پیکربندی، که به طور پیش‌فرض "usenet" است) ایمیل شوند.

اگر همیشه می‌خواهید از اقدامات انجام‌شده مطلع شوید، به جای آن از "doit=mail" استفاده کنید (به ادامه مراجعه کنید).

اقدام همانند doit انجام می‌شود و علاوه بر آن یک مدخل لاگ در پرونده لاگ مشخص‌شده file نوشته می‌شود. اگر file کلمه "mail" باشد، مدخل لاگ به جای آن برای مدیر اخبار ایمیل می‌شود. یک رشته خالی معادل /dev/null است و بیانگر آن است که چیزی ثبت نشود.

اگر file با یک اسلش آغاز شود، به عنوان نام پرونده مطلق برای استفاده به عنوان پرونده لاگ در نظر گرفته می‌شود. در غیر این صورت، نام پرونده با افزودن pathlog و یک اسلش در ابتدا و پسوند ".log" در انتها ساخته می‌شود. به عبارت دیگر، اقدام "doit=newgroup" لاگ‌ها را در pathlog/newgroup.log ثبت خواهد کرد.

هیچ اقدامی صورت نمی‌گیرد و پیام نادیده گرفته می‌شود. برای پیام‌های checkgroups، این بدان معناست که گروه‌های خبری ذکرشده، برای پردازش‌های بعدی در checkgroups ناموجود تلقی خواهند شد. 
checkgroups:*:comp.*:doit
checkgroups:*:*binaries*:drop

برای نمونه، هر گروه خبری را که نام آن شامل "binaries" در سلسله‌مراتب comp.* باشد حذف می‌کند، حتی اگر چنین گروه‌هایی در پیام checkgroups ذکر شده باشند. (در این مثال، حذف توسط اقدام doit انجام می‌شود، زیرا drop به خودی خود کاری انجام نمی‌دهد.)

اگر اقدام با رشته "verify-" آغاز شود، مانند: 
verify-news.announce.newgroups

آنگاه اعتبارسنجی PGP روی پیام کنترلی انجام می‌شود و شناسه کاربری (user ID) کلید امضاکننده معتبر در برابر هویت مورد انتظار که توسط ادامه رشته مشخص شده است (در مثال بالا "news.announce.newgroups") بررسی خواهد شد. این اعتبارسنجی از طریق pgpverify صورت می‌پذیرد؛ برای جزئیات بیشتر به pgpverify(1) مراجعه کنید.

اگر ثبت لاگی تعیین نشده باشد (با =file همان‌گونه که در زیر ذکر شده است)، ثبت لاگ همانند doit به روش توصیف‌شده در بالا انجام خواهد شد.

اعتبارسنجی PGP همانند اقدام verify-* توصیف‌شده در بالا انجام می‌شود، و اعلان پیام‌های کنترلی موفق newgroup و rmgroup و خروجی پیام‌های checkgroups برای مدیر اخبار ایمیل خواهد شد. (در مورد پیام‌های checkgroups، این بدان معناست که اسکریپت پوسته‌ای که باید اجرا شود به مدیر اخبار ایمیل می‌گردد. موضوع (subject) ایمیل بسته به مقدار /maxdocheckgroups/، شامل اطلاعاتی مبنی بر این خواهد بود که آیا اسکریپت قبلاً اجرا شده است یا خیر.)
اعتبارسنجی PGP همانند اقدام verify-* توصیف‌شده در بالا انجام می‌شود، و یک مدخل لاگ در پرونده مشخص‌شده مطابق آنچه در doit=file در بالا توصیف شد ثبت می‌گردد. (در مورد پیام‌های checkgroups، بدین معناست که خروجی اسکریپت پوسته از پیام checkgroups در آن پرونده نوشته خواهد شد. خط نخست لاگ شامل اطلاعاتی درباره این خواهد بود که آیا اسکریپت بسته به مقدار /maxdocheckgroups/ قبلاً اجرا شده است یا خیر.)
یک پیام لاگ تک‌خطی به خروجی خطای استاندارد (standard error) ارسال می‌شود. innd معمولاً این پیام را به pathlog/errlog هدایت می‌کند.
یک مدخل لاگ در پرونده لاگ مشخص‌شده ثبت می‌شود، که همانند doit=file توصیف‌شده در بالا تفسیر می‌گردد.
یک پیام ایمیل بدون انجام اقدام دیگری برای مدیر اخبار ارسال می‌شود.

یکی از تفاوت‌های میان اقدام doit یا verify با اقدام mail برای یک پیام کنترلی checkgroups، در ایمیلی است که ارسال می‌شود؛ doit یا verify یک اسکریپت پوسته را (که ممکن است قبلاً اجرا شده باشد) برای ایجاد، حذف یا تغییر گروه‌های خبری جهت انطباق با پیام checkgroups به مدیر اخبار ایمیل می‌کنند، در حالی که mail صرفاً خطوط مربوطه از پیام checkgroups را برای پردازش دستی توسط مدیر اخبار ارسال خواهد کرد.

استفاده از اقدام verify برای پردازش پیام‌های newgroup، rmgroup و checkgroups اکیداً توصیه می‌شود. سوءاستفاده از پیام‌های کنترلی بسیار شایع است، و احراز اصالت از طریق امضای PGP در حال حاضر تنها راه قابل اعتماد برای اطمینان از این است که یک پیام کنترلی واقعاً از سوی همان فردی آمده که ادعا می‌کند. امروزه بیشتر سلسله‌مراتب‌های عمده پیام‌های کنترلی احراز اصالت‌شده با PGP را منتشر می‌کنند.

برای استفاده از اقدامات verify، دسته کلید (keyring) PGP کاربر news باید حاوی کلیدهای PGP نگه‌دارندگان سلسله‌مراتبی باشد که می‌خواهید پیام‌های کنترلی آن‌ها را بپذیرید. برای جزئیات بیشتر در مورد پیام‌های کنترلی احراز اصالت‌شده با PGP و نشانی اینترنتی برای دریافت کلیدهای PGP سلسله‌مراتب‌های اصلی، به pgpverify(1) مراجعه کنید.

پیام‌های کنترلی از نوع cancel به صورت داخلی توسط innd مدیریت می‌شوند و هیچ‌کدام از سازوکارهای شرح داده‌شده در اینجا نمی‌توانند بر آن‌ها تأثیر بگذارند.

با وجود سه خط زیر در control.ctl:

newgroup:*:*:drop
newgroup:group-admin@isc.org:comp.*:verify-news.announce.newgroups
newgroup:kre@munnari.oz.au:aus.*:mail

یک newgroup ارسالی از سوی "group-admin@isc.org" در صورتی پذیرفته می‌شود که برای یک گروه خبری در سلسله‌مراتب comp.* باشد و امضای معتبری متناظر با کلید PGP با شناسه کاربری "news.announce.newgroups" داشته باشد. اگر هرگونه newgroup که ادعا می‌کند از طرف "kre@munnari.oz.au" برای یک گروه خبری در سلسله‌مراتب aus.* است دریافت شود، آن نیز پذیرفته خواهد شد. تمامی پیام‌های newgroup دیگر نادیده گرفته می‌شوند.

علاوه بر این، اگر پرونده‌ای به نام control.ctl.local وجود داشته باشد و شامل موارد زیر باشد:

newgroup:*:comp.lang.*:drop

آنگاه یک مقاله کنترلی newgroup برای comp.lang.awk پذیرفته نخواهد شد حتی اگر از سوی "group-admin@isc.org" همراه با یک امضای معتبر ارسال شده باشد.

در خصوص checkgroups، فرض کنید سرور اخبار شما شامل این گروه‌ها برای foo.* باشد، که همگی آن‌ها غیرمدیریت‌شده هستند (وضعیت "y" در پرونده active):

foo.bar1
foo.bar2.first
foo.bar2.second
foo.bar2.third
foo.bar3
foo.bar3.first
foo.bar3.second
foo.bar5

و شما پیام checkgroups زیر را از طرف <foo@bar.com> برای foo.* دریافت می‌کنید:

foo.bar1          A valid newsgroup.
foo.bar3.first    Only one newsgroup in foo.bar3.*.
foo.bar4          A newsgroup you want.
foo.bar5          A newsgroup you do not want.
foo.bar5.first    Another newsgroup you do not want.

با ورودی‌های زیر در control.ctl:

/maxdocheckgroups/:*:foo.*:2
checkgroups:foo@bar.com:foo.*:verify-key-foo
checkgroups:foo@bar.com:foo.bar2.*:doit
checkgroups:foo@bar.com:foo.bar3.*:mail
checkgroups:foo@bar.com:foo.bar4|foo.bar4.*:doit
checkgroups:foo@bar.com:foo.bar5|foo.bar5.*:drop

سپس، از آنجا که control.ctl از پایین به بالا پردازش می‌شود، آنچه رخ می‌دهد به شرح زیر است:

1.
گروه‌های خبری foo.bar5 و foo.bar5.first به عنوان ناخواسته علامت‌گذاری می‌شوند. اما هنوز کاری انجام نشده است: سایر ورودی‌های control.ctl با یک اقدام واقعی و مجموعه‌ای از گروه‌های خبری حاوی foo.bar5 و foo.bar5.first باید پردازش شوند.
2.
گروه خبری foo.bar4 به صورت بی‌صدا روی سرور اخبار ایجاد می‌شود، و توضیح "A newsgroup you want." به پرونده newsgroups افزوده می‌گردد. در صورت عدم وجود مقادیر کدگذاری (چه در پیام checkgroups و چه در /encoding/ و /localencoding)، پیش‌فرض این است که جمله به عنوان CP1242 رمزگشایی شده و مجدداً با UTF-8 کدگذاری شود.

اگر "doit=mail" استفاده شده بود، ایمیلی به مدیر اخبار فرستاده می‌شد تا به او اطلاع داده شود که foo.bar4 با موفقیت ایجاد شده است.

3.
گروه خبری foo.bar3.second دیگر موجود نیست. ایمیلی حاوی یک اسکریپت پوسته برای اجرا به مدیر اخبار ارسال می‌شود. هنگامی که این اسکریپت به صورت دستی اجرا شود، foo.bar3.second حذف خواهد شد.

توجه داشته باشید که توضیحات به شیوه متفاوتی پردازش می‌شوند و بدون هیچ مداخله دستی قبلاً به‌روزرسانی شده‌اند (foo.bar3.first اکنون دارای توضیح "Only one newsgroup in foo.bar3.*." است و foo.bar3.second دیگر توضیحی ندارد).

4.
گروه‌های خبری foo.bar2.first، foo.bar2.second و foo.bar2.third دیگر حضور ندارند. با این حال، از آنجا که حداکثر تعداد تغییراتی که می‌توانست در یک نوبت توسط یک checkgroups پیش از توقف و ارسال ایمیل تغییرات به مدیر اعمال شود ۲ مورد است، این گروه‌های خبری حذف نمی‌شوند. ایمیلی حاوی یک اسکریپت پوسته ارسال می‌شود تا جهت حذف این گروه‌ها از سرور اخبار به صورت دستی اجرا گردد.

توجه داشته باشید که توضیحات آن‌ها از پرونده newsgroups حذف می‌شوند، همانند هرگونه توضیح احتمالی دیگر برای گروه‌های خبری منسوخ در foo.bar2.*.

5.
ورودی باقی‌مانده در صورتی اجرا می‌شود که اعتبارسنجی PGP پیام checkgroups موفقیت‌آمیز باشد. در غیر این صورت، هیچ اقدامی صورت نمی‌گیرد (به‌ویژه، foo.bar5 روی سرور اخبار باقی می‌ماند).

در صورتی که امضای PGP تأیید شود، foo.bar3 و foo.bar5 از سرور اخبار حذف می‌شوند. این ورودی روی گروه‌های خبری که در دامنه آن به عنوان drop علامت‌گذاری شده‌اند و گروه‌های خبری که پیش‌تر توسط ورودی‌های قبلی control.ctl به آن‌ها رسیدگی نشده است (مانند foo.bar3 زیرا قبلاً تنها foo.bar3.* بررسی شده بود) اعمال اثر می‌کند.

توجه داشته باشید که اگر می‌خواستید foo.bar3 یا foo.bar5 را حفظ کنید، می‌توانستید آن‌ها را به پرونده localgroups در pathetc اضافه کنید.

نوشته شده توسط Rich $alz <rsalz@uunet.uu.net> برای InterNetNews. بازنویسی در POD توسط Russ Allbery <eagle@eyrie.org>.

controlchan(8), inn.conf(5), innd(8), newsfeeds(5), newsgroups(5), pgpverify(1), sh(1).

2022-07-10 INN 2.7.4