نام (NAME)

newsfeeds - تعیین مقصد ارسال مقاله‌های یوزنت (Usenet)

در یک نگاه (IN A NUTSHELL)

فایل newsfeeds تعیین می‌کند که innd با مقاله‌های پذیرفته‌شدهٔ ورودی چه کار کند.

یک فایل مینیمال newsfeeds که یک فید خروجی NNTP از تمام مقاله‌های دریافتی شما را به مقصد "news.server.com" با شناسه مسیر "server" (همان‌طور که در فیلدهای سرآیند Path ظاهر می‌شود) پیکربندی می‌کند، به صورت زیر است:

# خط الزامی، بدون تعریف الگوهای استثنا.
ME:::
# یک فید بی‌درنگ از طریق innfeed برای همه مقاله‌های شما.
news.server.com/server\
    :*\
    :Tm:innfeed!
# مدخل فید کانال برای innfeed.
# مقدار "/usr/lib/news/bin" را به مسیر دایرکتوری
# برنامه innfeed تغییر دهید.
innfeed!:!*:Tc,Wnm*:/usr/lib/news/bin/innfeed

به منظور یافتن یک فید خارجی، می‌توانید در گروه خبری news.admin.peering درخواست دهید. چندین مدیر سرور خبر مطمئناً پاسخ خواهند داد و با روی خوش یک فید خبری در اختیارتان خواهند گذاشت.

مدخل‌های دیگری نیز بسته به نیاز شما می‌توانند به newsfeeds اضافه شوند. برای پرکاربردترین موارد به مثال‌های زیر و همچنین صفحات راهنمای archive(8)، controlchan(8)، news2mail(8)، ninpaths(8) و perl-nocem(8) مراجعه کنید.

اگر سلسله‌مراتب‌ها یا گروه‌های خبری محلی را از فید استثنا می‌کنید، اطمینان حاصل کنید که "!control,!control.*" را اضافه کنید تا مقاله‌های لغو (cancel) یا هر نوع مقاله کنترلی مرتبط با سلسله‌مراتب‌ها یا گروه‌های استثناشده به کارگزار راه دور منتشر نشوند. در این حالت مدخل newsfeeds آن شبیه به این خواهد بود:

news.server.com/server\
    :*,!local.*,@*bina*,!control,!control.*\
    :Tm:innfeed!

پس از اعمال هرگونه تغییر، دستور "inncheck" را برای بررسی‌های نحوی پایه اجرا کنید و این فایل پیکربندی را با دستور زیر مجدداً بارگذاری نمایید:

ctlinnd reload newsfeeds 'new peer'

توضیحات (DESCRIPTION)

فایل pathetc/newsfeeds نحوهٔ توزیع مقاله‌های ورودی به سایر برنامه‌ها و فایل‌های روی سرور را مشخص می‌کند. این فایل توسط سرور InterNetNews یعنی innd(8) در هنگام راه‌اندازی یا زمانی که توسط ctlinnd(8) دستور داده شود، پردازش و خوانده می‌شود. innd خودش مقاله‌ها را مستقیماً به سایت‌های راه دور ارسال نمی‌کند، بنابراین newsfeeds مستقیماً تعیین نمی‌کند که مقاله‌ها به کدام سرورهای خبری دوردست فرستاده شوند. در عوض، مشخص می‌کند که چه فایل‌های دسته‌ای (batch) باید ساخته شوند یا چه برنامه‌هایی باید اجرا شوند (و چه اطلاعاتی باید به آن‌ها ارسال گردد)، و سپس این اطلاعات توسط برنامه‌هایی مانند innxmit(8) و innfeed(8) برای ارسال مقاله‌ها به سایت‌های دوردست به کار گرفته می‌شوند.

در صورت استفاده به همراه delayer(8) در پیکربندی فید قیفی (funnel) مربوطه، innfeed حتی می‌تواند فید دارای تأخیر را به همتایان دوردست یا به نمونه محلی دیگری از innd ارسال کند، به‌ویژه برای آنکه امکان رد هرزنامه‌ها قبل از رسیدن واقعی آن‌ها فراهم گردد.

فایل newsfeeds نه تنها برای تنظیم ارسال مقاله‌های پذیرفته‌شده به سایت‌های راه دور، بلکه برای ارسال آن‌ها (یا بخش‌هایی از اطلاعات دربارهٔ آن‌ها) به هر برنامه یا فایل محلی متقاضی آن داده‌ها استفاده می‌شود. برای نمونه، controlchan(8)، دیمونی که پیام‌های کنترلی ورودی را پردازش می‌کند، از طریق newsfeeds اجرا می‌شود، همان‌طور که یک درگاه خبر به ایمیل (news to mail gateway) می‌تواند اجرا شود.

این فایل به صورت مجموعه‌ای از خطوط تفسیر می‌شود که طبق قوانین زیر پردازش می‌گردند: اگر خطی با یک بک‌اسلش پایان یابد، بک‌اسلش، کاراکتر خط جدید و هرگونه فاصله خالی در ابتدای خط بعد حذف می‌شوند. این کار تا زمانی که کل خط «منطقی» جمع‌آوری شود تکرار می‌گردد. اگر خط منطقی خالی باشد یا با علامت هش ("#") آغاز شود، نادیده گرفته می‌شود.

تمام خطوط دیگر به عنوان مدخل‌های فید تفسیر می‌شوند. هر مدخل باید شامل چهار فیلد باشد که با دونقطه (:) از هم جدا شده‌اند؛ دو مورد از فیلدها می‌توانند زیرفیلدهای اختیاری داشته باشند که با اسلش (/) جدا می‌شوند. فیلدها یا زیرفیلدهایی که چندین پارامتر می‌پذیرند باید با کاما جدا شوند. فاصله‌های خالی اضافی می‌توانند باعث بروز مشکل شوند و باید از آن‌ها اجتناب کرد. به جز نام سایت‌ها، بزرگی و کوچکی حروف اهمیت دارد (case-sensitive است). قالب یک مدخل به صورت زیر است:

sitename[/exclude,exclude,...]\
    :pattern,pattern...[/distribution,distribution...]\
    :flag,flag...\
    :parameter

هر فیلد در زیر توضیح داده شده است.

فیلد sitename نام سایتی است که مقاله خبری می‌تواند به آن ارسال شود. این فیلد برای نوشتن لاگ‌ها و تعیین اینکه آیا یک مقاله باید به یک سایت فوروارد شود یا خیر استفاده می‌شود. («سایت» یک اصطلاح عمومی برای مقصدی از داده‌های newsfeed است؛ این مفهوم اغلب به یک همتای خبری راه دور اشاره دارد، اما الزاماً این‌طور نیست. به عنوان مثال، یک برنامه بایگانی محلی که از طریق newsfeeds اجرا می‌شود نیز یک «سایت» است.) اگر sitename از قبل در بدنه فیلد سرآیند Path مقاله وجود داشته باشد، مقاله به آن سایت فرستاده نخواهد شد. این نام معمولاً همان چیزی است که سایت راه دور برای شناسایی خود در بدنه فیلد سرآیند Path استفاده می‌کند، اما می‌تواند تقریباً هر کلمه‌ای باشد.

با این حال مراقب باشید که sitename به طور ناخواسته با یک شناسه مسیر در فیلد سرآیند Path مطابقت پیدا نکند. به همین دلیل، مدخل‌های محلی خاص (مانند بایگانی‌کننده‌ها یا درگاه‌ها) احتمالاً باید با یک علامت تعجب ختم شوند تا اطمینان حاصل شود که نامی یکسان با هیچ سایت واقعی ندارند. به عنوان مثال، "gateway" نامی بدیهی برای یک مدخل محلی است که مقاله‌ها را به یک لیست پستی فوروارد می‌کند. اگر سایتی با نام "gateway" مقاله‌ای ارسال کند، زمانی که سایت محلی آن مقاله را دریافت می‌کند، نام را در فیلد سرآیند Path خواهد دید و مقاله را به مدخل "gateway" خود ارسال نخواهد کرد. از آنجا که "gateway!" نمی‌تواند به عنوان یک شناسه مسیر جداگانه در فیلد سرآیند Path ظاهر شود (چرا که "!" جداکننده است)، استفاده از آن برای sitename گزینهٔ بهتری است.

(روش دیگر برای جلوگیری از این مشکل استفاده از پرچم "Ap" است؛ توضیحات زیر را ببینید.)

اگر یک مدخل دارای زیرفیلد استثنا (exclusion) باشد، در صورتی که هر یک از مقادیر exclude در بدنه فیلد سرآیند Path ظاهر شوند، مقاله به آن سایت فرستاده نخواهد شد. (گاهی راحت‌تر است که sitename شکل کوتاه‌شده‌ای از نام سایت راه دور باشد، زیرا تمام مقادیر sitename که مقاله به آن‌ها ارسال می‌شود در لاگ نوشته می‌شوند و بنابراین استفاده از نام‌های کوتاه‌تر می‌تواند کارایی سرورهای بزرگ را بهبود بخشد. در این حالت، شناسه‌های مسیر آن سایت‌ها باید به عنوان مدخل‌های exclude داده شوند و پرچم "Ap" استفاده شود تا sitename کوتاه به طور تصادفی با شناسه‌های مسیر دیگر در فیلدهای سرآیند Path مطابقت پیدا نکند.)

یک sitename یکسان می‌تواند بیش از یک بار استفاده شود و اقدام مناسب برای هر مدخلی که باید مقاله را دریافت کند انجام خواهد شد، اما این کار فقط برای فیدهای برنامه‌ای توصیه می‌شود تا از سردرگمی جلوگیری شود. بزرگی و کوچکی حروف در نام سایت‌ها بی‌تأثیر است.

الگوی pattern جداشده با کاما مشخص می‌کند که کدام گروه‌ها به سایت فرستاده شوند؛ این الگو برای ایجاد یک «لیست اشتراک» (subscription list) برای سایت تفسیر می‌شود. اشتراک پیش‌فرض دریافت تمام گروه‌های موجود در سرور است. این یک الگوی uwildmat است که از نویسه‌های عمومی مسموم ("@") پشتیبانی می‌کند؛ برای جزئیات کامل درباره زبان تطبیق الگو به صفحه راهنمای libinn_uwildmat مراجعه کنید. الگوی pattern با تک‌تک گروه‌های خبری ارائه‌شده توسط سرور تطبیق داده می‌شود و تمام گروه‌هایی که مطابقت داشته باشند به لیست اشتراک سایت اضافه خواهند شد.

به طور معمول، اگر هر یک از گروه‌های خبری که مقاله در آن‌ها ارسال شده است در لیست اشتراک آن سایت باشد، مقاله مربوطه (یا اطلاعات آن) به سایت فرستاده می‌شود. اگر یک گروه خبری با الگوی "@" در pattern مطابقت داشته باشد، نه تنها به لیست اشتراک اضافه نمی‌شود، بلکه هر مقاله‌ای که به صورت اشتراکی در آن گروه خبری ارسال شده باشد (crossposted)، حتی اگر سایر گروه‌های مشترک آن در لیست اشتراک سایت باشند نیز به آن سایت فرستاده نخواهد شد. به این یک الگوی مسموم (poison pattern) گفته می‌شود (زیرا گروه‌های مطابقت‌یافته «مسموم» می‌شوند).

به عنوان مثال، برای دریافت تمام گروه‌های comp.*، اما فقط comp.sources.unix در میان گروه‌های خبری sources، می‌توان از pattern زیر استفاده کرد:

comp.*,!comp.sources.*,comp.sources.unix

توجه داشته باشید که ".*" انتهایی الزامی است؛ الگو باید با کل نام گروه خبری مطابقت داشته باشد. عبارت "comp.sources.*" می‌تواند به صورت "comp.sources*" نوشته شود و گروه خبری comp.sources (در صورت وجود) و همچنین گروه‌های سلسله‌مراتب comp.sources.* را مستثنا کند، اما دقت کنید که این کار گروه خبری به نام comp.sources-only را نیز مستثنا می‌کند (در حالی که الگوی بالا آن گروه را به لیست اشتراک سایت اضافه می‌کند زیرا با "comp.*" مطابقت دارد و با هیچ‌یک از الگوهای دیگر همخوانی ندارد).

برای مثالی دیگر، به منظور ارسال alt.* و misc.* به یک سایت معین اما بدون ارسال مقاله‌های فرستاده‌شده به alt.binaries.warez (حتی اگر در سایر گروه‌های alt.* یا misc.* هم اشتراک‌گذاری شده باشند)، می‌توان از الگوی زیر استفاده کرد:

alt.*,@alt.binaries.warez,misc.*

با این حال توجه داشته باشید که اگر جای مدخل‌های "alt.*" و "@alt.binaries.warez" را جابه‌جا کنید، این الگو معادل "alt.*,misc.*" خواهد بود، زیرا آخرین الگوی منطبق تعیین می‌کند که آیا یک گروه خبری مطابقت دارد یا خیر، و منطق مسموم‌سازی تنها در صورتی اعمال می‌شود که مدخل مسموم آخرین مدخل منطبق باشد.

پیام‌های کنترلی از قوانین انتشاری کمی متفاوت نسبت به مقاله‌های عادی پیروی می‌کنند؛ برای جزئیات به innd(8) مراجعه فرمایید. توجه داشته باشید که اکثر اشتراک‌ها باید به دلیل این قوانین انتشار، عبارت "!junk,!control,!control.*" را در لیست الگوی خود داشته باشند (و از آنجا که "junk" یک گروه خبری داخلی ویژه است؛ برای جزئیات بیشتر در مورد کاربرد آن به wanttrash در inn.conf(5) مراجعه کنید) و بهترین راه برای محلی نگه داشتن پیام‌های کنترلی در یک سایت، استفاده از توزیع (distribution) است.

یک اشتراک را می‌توان با مشخص کردن توزیع‌هایی (distributions) که سایت باید دریافت کند یا نکند، بیشتر سفارشی‌سازی کرد. پیش‌فرض این است که تمام مقاله‌ها به همه سایت‌هایی که مشترک هر یک از گروه‌های ارسالی آن هستند ارسال شوند، اما اگر مقاله‌ای دارای فیلد سرآیند Distribution باشد و هرگونه distribution مشخص شده باشد، طبق قوانین زیر بررسی می‌شوند:

1.

اگر فیلد سرآیند Distribution با هر یک از مقادیر موجود در زیرفیلد مطابقت داشته باشد، مقاله ارسال می‌شود.

2.

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

3.

اگر فیلد سرآیند Distribution با هیچ distribution در مدخل سایت مطابقت نداشته باشد و هیچ نفی (علامت تعجب) استفاده نشده باشد، مقاله ارسال نمی‌شود.

4.

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

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

تقریباً قطعاً اشتباه است که در یک فید منفرد، توزیع‌هایی که با علامت تعجب شروع می‌شوند در کنار توزیع‌هایی که بدون آن هستند استفاده شوند.

توزیع‌ها کلمات متنی هستند، نه الگو؛ مدخل‌هایی مانند "*" یا "all" هیچ معنای خاصی ندارند.

فیلد flag در بخش «مقادیر پرچم‌ها (FLAG VALUES)» شرح داده شده است. تفسیر فیلد parameter به نوع فید بستگی دارد و در بخش «انواع فید (FEED TYPES)» با جزئیات بیشتر توضیح داده شده است. این فیلد را می‌توان برای برخی انواع فید حذف کرد.

سایت با نام "ME" خاص است. باید دقیقاً یک چنین مدخلی وجود داشته باشد، و باید اولین مدخل در فایل باشد. اگر مدخل "ME" دارای زیرفیلد استثنا باشد، در صورتی که هر یک از نام‌های مشخص‌شده در آن زیرفیلد در بدنه فیلد سرآیند Path مقاله‌های ورودی ظاهر شود، آن مقاله‌ها کاملاً رد می‌شوند. اگر مدخل "ME" لیست اشتراک داشته باشد، آن لیست به ابتدای لیست اشتراک تمام مدخل‌های دیگر اضافه (prepend) می‌شود. به عنوان مثال، "*,!control,!control.*,!junk,!foo.*" می‌تواند برای تعیین لیست اشتراک پیش‌فرض تمام فیدهای دیگر استفاده شود تا پست‌های محلی منتشر نشوند مگر اینکه "foo.*" صریحاً در لیست اشتراک آن سایت ظاهر شود. این قابلیت تا حدی گیج‌کننده است زیرا اشتراک پیش‌فرض در ابتدا قرار می‌گیرد و می‌تواند توسط الگوهای دیگر بازنویسی شود.

اگر مدخل "ME" زیرفیلد توزیع داشته باشد، تنها مقالاتی که با آن لیست توزیع مطابقت دارند پذیرفته می‌شوند و تمام مقالات دیگر دارای توزیع رد خواهند شد. یک کاربرد رایج برای این کار، قرار دادن چیزی مانند "/!local" در مدخل "ME" است تا پست‌های محلی از سایر سایت‌های دارای پیکربندی اشتباه رد شوند. زیرفیلد توزیع "ME" هیچ تأثیری در پذیرش یا رد مقالاتی که فاقد فیلد سرآیند Distribution هستند ندارد.

یک مدخل خالی "ME" امکان‌پذیر است، که در این صورت هیچ الگوی استثنایی تعریف نخواهد شد.

در نهایت، امکان تعریف متغیرها در newsfeeds و استفاده از آن‌ها در ادامه فایل نیز وجود دارد. خطی که با "$" شروع شود یک متغیر را مقداردهی می‌کند. برای مثال:

$LOCALGROUPS=local.*,example.*
$CONTROLGROUPS=control,control.*

این خط متغیر "LOCALGROUPS" را به "local.*,example.*" و متغیر "CONTROLGROUPS" را به "control,control.*" تنظیم می‌کند. سپس می‌توان از آن‌ها در سایر بخش‌های فایل استفاده کرد، مانند مدخل سایتی شبیه به:

news.example.com:$LOCALGROUPS:Tf,Wnm:

که کاملاً معادل است با:

news.example.com:local.*,example.*:Tf,Wnm:

متغیرها صرفاً یک جایگزینی ساده نیستند. اگر کاراکتر "!" یا "@" بلافاصله قبل از متغیر بیاید و مقدار متغیر حاوی کاما باشد، آن کاراکتر قبل از هر کاما تکرار خواهد شد. این رفتار که تا حدی عجیب به نظر می‌رسد، به این منظور طراحی شده است تا استفاده از متغیرها برای ساخت الگوهای فید آسان‌تر شود. کاربرد این موضوع زمانی واضح‌تر می‌شود که ببینید خط:

news.example.net:*,@$LOCALGROUPS,!$CONTROLGROUPS:Tf,Wnm:

بنابراین معادل است با:

news.example.net:*,@local.*,@example.*,!control,!control.*:Tf,Wnm:

که (همان‌طور که در زیر توضیح داده شده است) تمام گروه‌های موجود در LOCALGROUPS$ و مقاله‌های کنترلی ناخواسته را از فید ارسالی به آن سایت مستثنا می‌کند.

مقادیر پرچم‌ها (FLAG VALUES)

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

< size

یک مقاله تنها در صورتی به این سایت ارسال می‌شود که طول آن کمتر از size بایت باشد. حالت پیش‌فرض بدون محدودیت است.

> size

یک مقاله تنها در صورتی به این سایت ارسال می‌شود که طول آن بیشتر از size بایت باشد. حالت پیش‌فرض بدون محدودیت است.

A checks

یک مقاله تنها در صورتی به این سایت ارسال می‌شود که شرایط مشخص‌شده در checks را داشته باشد؛ این شرایط باید از مجموعه زیر انتخاب شوند. checks در صورت لزوم می‌تواند شامل چندین حرف باشد. توجه داشته باشید که این پرچم روی مقصدهای قیفی (funnel targets) مؤثر نیست؛ باید روی هر مدخل قیف استفاده شود (برای نمونه، Af روی مقصد قیفی innfeed! بی‌اثر است و بنابراین باید روی تک‌تک سایت‌های خبری قیف‌شده مشخص شود).

B high/low

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

C count

در صورت تعیین این پرچم، یک مقاله تنها در صورتی به این سایت ارسال می‌شود که تعداد گروه‌هایی که مقاله در آن‌ها پست شده، به علاوه مربع (توان دو) تعداد گروه‌هایی که پیگیری‌ها (followups) در آن‌ها ظاهر می‌شوند، بیشتر از count نباشد. مقدار "30" یک مقدار مناسب برای این پرچم است که به عنوان مثال موارد زیر را مجاز می‌داند:

F name

نام فایلی را مشخص می‌کند که در صورت لزوم برای آغاز صف‌بندی (spooling) برای سایت باید استفاده شود (به بخش زیر مراجعه کنید). اگر name یک مسیر مطلق نباشد، نسبت به pathoutgoing در inn.conf در نظر گرفته می‌شود. اگر name یک دایرکتوری باشد، فایل togo در آن دایرکتوری به عنوان نام فایل استفاده خواهد شد.

G count

در صورت تعیین این پرچم، مقاله تنها در صورتی به این سایت ارسال می‌شود که حداکثر در count گروه خبری پست شده باشد. این مورد مشکل فیلتر کردن بسیاری از FAQها و همچنین پست‌های ایجاد گروه خبری و اطلاعیه‌های مدیریتی مشابه را دارد. هر یک از پرچم‌های C یا U راه‌حل بهتری هستند.

H count

در صورت تعیین این پرچم، یک مقاله تنها در صورتی به این سایت ارسال می‌شود که تعداد سایت‌ها در بدنه فیلد سرآیند Path آن حداکثر count باشد. این پرچم به دلیل تفسیر آزادانه فیلد سرآیند Path تنها باید به عنوان یک راهنمای تقریبی استفاده شود؛ برخی سایت‌ها نام ارسال‌کننده را در بدنه فیلد سرآیند قرار می‌دهند و برخی سایت‌ها که منطقاً یک گام (hop) محسوب می‌شوند به دو گام تبدیل می‌شوند زیرا نام ایستگاه کاری ارسال‌کننده را در بدنه فیلد سرآیند درج می‌کنند. مقدار پیش‌فرض برای count در صورت عدم تعیین، یک است. (همچنین پرچم O را ببینید که گاهی برای برخی کاربردهای این پرچم مناسب‌تر است.)

I size

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

N status

مقالات ارسالی به این سایت را به مقالاتی در گروه‌های خبری با وضعیت نظارت (moderation) ارائه‌شده توسط status محدود می‌کند. اگر status برابر "m" باشد، تنها مقالات موجود در گروه‌های تحت نظارت (moderated) ارسال می‌شوند؛ اگر status برابر "u" باشد، تنها مقالات موجود در گروه‌های بدون نظارت (unmoderated) ارسال خواهند شد.

O originator

در صورت تعیین این پرچم، یک مقاله تنها در صورتی به این سایت ارسال می‌شود که حاوی یک فیلد سرآیند Injection-Info باشد (یا یک فیلد سرآیند X-Trace در صورتی که سرآیند Injection-Info یافت نشود) و فیلد اول این سرآیند با originator مطابقت داشته باشد. عبارت originator یک عبارت uwildmat بدون کاما یا لیستی از چنین عباراتی است که با "/" جدا شده‌اند. اگر اولین کاراکتر الگو با "@" آغاز شود و بقیه الگو مطابقت داشته باشد، مقاله هرگز ارسال نمی‌شود. یک کاربرد این پرچم، محدود کردن فید به پست‌های تولیدشده محلی با استفاده از یک الگوی originator است که با فیلد سرآیند Injection-Info اضافه‌شده توسط سرور محلی مطابقت دارد.

P priority

اولویت nice که این کانال یا فید برنامه‌ای باید دریافت کند. این مقدار باید یک عدد مثبت بین ۰ تا ۲۰ باشد و اولویتی است که فرآیند جدید با آن اجرا خواهد شد. این پرچم می‌تواند برای بالا بردن اولویت به حد عادی در صورتی که از پارامتر nicekids در inn.conf استفاده می‌کنید، به کار رود.

Q hashfeed

عبارت تطبیق hashfeed را برای این سایت مشخص می‌کند. این عبارت باید به فرم "value/mod" یا "start-end/mod" باشد. مقدار Message-ID مقاله با استفاده از MD5 هش می‌شود که یک هش ۱۲۸ بیتی ایجاد می‌کند. ۳۲ بیت پایین‌تر به طور پیش‌فرض به عنوان مقدار hashfeed (که یک عدد صحیح است) در نظر گرفته می‌شود. اگر باقیمانده مقدار hashfeed بر "mod" به اضافه یک برابر با "value" باشد یا بین "start" و "end" قرار گیرد، مقاله به این سایت فید خواهد شد. تمام این اعداد باید اعداد صحیح باشند.

این روش یک راه قطعی برای کنترل جریان مقالات و تقسیم یک فید است. به عنوان مثال:

Q1/2      حدود ۵۰٪ از تمام مقالات را به این سایت فید می‌کند.
Q2/2      ۵۰٪ دیگر مقالات را فید می‌کند.

مثال دیگر با سه سایت:

Q1-3/10   حدود ۳۰٪ از تمام مقالات را فید می‌کند.
Q4-5/10   حدود ۲۰٪ از تمام مقالات را فید می‌کند.
Q6-10/10  حدود ۵۰٪ از تمام مقالات را فید می‌کند.

اگر این پرچم چندین بار مشخص شود، محتویات به صورت منطقی با هم "OR" می‌شوند (تنها یک تطابق کافی است).

می‌توانید از ساختار گسترش‌یافته‌ای به فرم "value/mod_offset" یا "start-end/mod_offset" استفاده کنید. از آنجا که MD5 یک مقدار خروجی ۱۲۸ بیتی تولید می‌کند، امکان تعیین این موضوع وجود دارد که عدد صحیح ۳۲ بیتی مورد استفاده توسط hashfeed از کدام افست بایتی شروع شود. مقدار پیش‌فرض برای "offset" برابر "_0" است و سیزده مقدار هم‌پوشان از "_0" تا "_12" می‌توانند استفاده شوند. تنها حداکثر چهار مقدار کاملاً مستقل وجود دارند: "_0"، "_4"، "_8" و "_12".

بنابراین، این امکان ایجاد یک سطح دوم از توزیع قطعی را فراهم می‌کند. در واقع، اگر به یک سرور خبری فید "Q1/2" داده شود، می‌تواند به عنوان مثال به کمک "Q1-3/9_4" به تقسیم کردن ادامه دهد. تا چهار سطح از توزیع قطعی قابل استفاده است.

این الگوریتم با الگوریتم مورداستفاده در Diablo 5.1 و بالاتر سازگار است. اگر می‌خواهید از روش قدیمی هشینگ سریع مورد استفاده در Diablo قبل از 5.1 استفاده کنید، می‌توانید علامت "@" را درست بعد از پرچم Q قرار دهید (مثلاً "Q@1-3/10"، اما توزیع پیام‌ها با این روش قدیمی چندان بی‌نقص نیست و استفاده از آن توصیه نمی‌شود و نمی‌توان برای آن از افست‌ها استفاده کرد).

S size

اگر مقدار داده‌های صف‌بندی‌شده برای سایت بیشتر از size بایت شود، سرور به حالت spooling تغییر وضعیت داده و داده‌ها را به فایل مشخص‌شده با پرچم F، یا در صورت عدم تعیین F به فایل pathoutgoing/sitename ضمیمه می‌کند. عملیات spooling معمولاً تنها برای فیدهای کانال یا اکسپلودر رخ می‌دهد، زمانی که برنامه اجراشده نتواند با ورودی خود همگام بماند.

T type

این پرچم نوع فید را برای این سایت مشخص می‌کند. مقدار type باید حرفی انتخاب‌شده از مجموعه زیر باشد:

c        کانال (Channel)
f        فایل (File)
l        فقط ثبت لاگ (Log entry only)
m        قیف (Funnel - هدایت چندین مدخل به یکی)
p        برنامه (Program)
x        اکسپلودر (Exploder)

هر فید در بخش «انواع فید (FEED TYPES)» در زیر شرح داده شده است. حالت پیش‌فرض Tf برای یک فید فایلی است.

U count

در صورت تعیین این پرچم، یک مقاله تنها در صورتی به این سایت ارسال می‌شود که پیگیری‌ها (followups) به این مقاله حداکثر در count گروه خبری ارسال شوند. (همچنین برای روش پیچیده‌تر مدیریت این موضوع به C مراجعه کنید.)

W items

برای فیدهای فایلی، کانالی یا اکسپلودر، این پرچم اطلاعاتی را که باید به این سایت ارسال شوند کنترل می‌کند. برای فید برنامه‌ای، تنها ستاره ("*") تأثیر دارد. مقادیر items باید از مجموعه زیر انتخاب شوند:

انواع فید (FEED TYPES)

سرور innd چهار نوع فید پایه ارائه می‌دهد: لاگ، فایل، برنامه و کانال. اکسپلودر نوع خاصی از کانال است. علاوه بر این، چندین مدخل می‌توانند به یک فید یکسان هدایت شوند؛ این‌ها فیدهای قیفی (funnel feeds) هستند که به مدخلی از یکی از انواع دیگر اشاره می‌کنند. فیدهای قیفی تا حدی در بالا در توضیحات پرچم W* شرح داده شده‌اند. یک فید قیفی هر مقاله‌ای را که به هر یک از فیدهای واردشونده به آن فرستاده شود دریافت می‌کند و معمولاً پرچم W* را در میان پرچم‌های خود قرار می‌دهد تا برنامه پردازش‌کننده آن فید بداند کدام سایت‌ها کدام مقالات را دریافت کرده‌اند. رایج‌ترین فید قیفی innfeed(8) است.

توجه داشته باشید که اصطلاح «فید» از نظر فنی نام‌گذاری دقیقی نیست، زیرا سرور خودش مقاله‌ها را منتقل نمی‌کند و تنها داده‌ها را در یک فایل، برنامه یا لاگ می‌نویسد و به برنامه دیگری می‌گوید که مقالات را انتقال دهد.

ساده‌ترین فید، فید لاگ (Tl) است. به جز ذکر نام در فایل لاگ خبر، یعنی pathlog/news، هیچ داده‌ای نوشته نمی‌شود. این معادل یک مدخل Tf است که در /dev/null می‌نویسد، با این تفاوت که هیچ فایلی باز نمی‌شود. تخلیه (flush) یک فید لاگ هیچ کاری انجام نمی‌دهد.

فید فایلی (Tf) دومین نوع ساده فید است. هنگامی که سایت باید مقاله‌ای را دریافت کند، داده‌های مشخص‌شده در فایلی که نام آن در فیلد parameter آمده است نوشته می‌شود. اگر parameter یک مسیر مطلق نباشد، نسبت به pathoutgoing در inn.conf در نظر گرفته می‌شود. اگر parameter داده نشود، به طور پیش‌فرض pathoutgoing/sitename خواهد بود. نام فایل باید یکتا باشد (دو فید فایلی هرگز نباید به یک فایل یکسان اشاره کنند).

فیدهای فایلی برای استفاده توسط برنامه‌های خارجی طراحی شده‌اند که به صورت دوره‌ای داده‌های نوشته‌شده را پردازش می‌کنند. برای همکاری صحیح با innd، چنین برنامه‌های خارجی ابتدا باید نام فایل دسته‌ای را تغییر دهند و سپس یک دستور تخلیه (flush) برای آن سایت با استفاده از ctlinnd(8) به innd ارسال کنند. سپس innd هر داده بافرشده‌ای را می‌نویسد، فایل را می‌بندد و آن را (تحت نام اصلی) مجدداً باز می‌کند، و برنامه می‌تواند با خیال راحت داده‌های موجود در فایل تغییرنام‌یافته را پردازش کند. فیدهای فایلی اغلب در ترکیب با nntpsend(8) استفاده می‌شوند.

یک فید برنامه‌ای (Tp) به ازای هر مقاله‌ای که سایت دریافت می‌کند، یک برنامه معین را اجرا می‌کند (spawn می‌کند). فیلد parameter باید خط فرمانی باشد که اجرا می‌شود، و باید شامل یک مورد از "%s" باشد که با توکن API ذخیره‌سازی مقاله جایگزین خواهد شد (مقاله واقعی می‌تواند توسط برنامه با استفاده از sm(8) بازیابی شود). برنامه چیزی در ورودی استاندارد خود دریافت نخواهد کرد (برخلاف نسخه‌های قبلی INN که در آن‌ها مقاله روی stdin به برنامه ارسال می‌شد)، و خروجی استاندارد و خطای استاندارد برنامه روی لاگ خطا (pathlog/errlog) تنظیم خواهد شد. اگر دستور فاقد فرانویسه‌های شل (shell meta-characters) باشد، innd سعی می‌کند از اجرای یک شل خودداری کند؛ در صورت نیاز به هر دلیلی می‌توان این ویژگی را با افزودن یک سمی‌کلن (;) به انتهای دستور غیرفعال کرد. مسیر کامل برنامه‌ای که باید اجرا شود باید مشخص گردد مگر اینکه دستور توسط شل اجرا شود (و اکیداً توصیه می‌شود که مسیر کامل همیشه صرف‌نظر از این موضوع مشخص شود).

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

تخلیه (flush) یک فید برنامه‌ای هیچ کاری انجام نمی‌دهد.

برای یک فید کانالی (Tc) یا اکسپلودر (Tx)، فیلد parameter مجدداً فرآیندی را که باید راه‌اندازی شود نام‌گذاری می‌کند. همانند فیدهای برنامه‌ای، مسیر کامل برنامه باید مشخص شود. با این حال، به جای اجرای برنامه برای هر مقاله، برنامه یک بار اجرا می‌شود و سپس هر زمان که سایت مقاله‌ای دریافت کند، داده‌های مشخص‌شده توسط پرچم‌های سایت در ورودی استاندارد برنامه اجراشده نوشته می‌شود. خروجی استاندارد و خطای استاندارد همانند فیدهای برنامه‌ای تنظیم می‌شوند. اگر فرآیند خارج شود، به طور خودکار دوباره راه‌اندازی خواهد شد. اگر فرآیند نتواند راه‌اندازی شود، سرور ورودی را در فایلی به نام pathoutgoing/sitename صف‌بندی (spool) می‌کند و بعداً مجدداً تلاش خواهد کرد تا فرآیند را راه‌اندازی کند.

هنگامی که یک فید کانالی یا اکسپلودر تخلیه (flush) می‌شود، سرور سرِ لوله (pipe) خود به ورودی استاندارد برنامه را می‌بندد. هر دادهٔ معلقی که نوشته نشده باشد صف‌بندی (spool) خواهد شد؛ توضیحات پرچم S در بالا را ببینید. سرور سپس یک نمونه جدید از برنامه را اجرا خواهد کرد. هیچ سیگنالی به برنامه ارسال نمی‌شود؛ این بر عهده برنامه مدیریت‌کننده فید کانالی یا اکسپلودر است که پایان فایل (EOF) را در ورودی استاندارد خود تشخیص دهد و به درستی خارج شود.

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

!newgroup group
!rmgroup group
!flush
!flush site

این دستورات هر زمان که دستور ctlinnd(8) با همان نام توسط سرور دریافت شود، ارسال می‌گردند. علاوه بر این، دستور "send" در ctlinnd(8) می‌تواند برای ارسال یک خط فرمان دلخواه به یک اکسپلودر استفاده شود. اکسپلودر اصلی buffchan(8) است.

در نهایت، فیدهای Tm ورودی یک قیف هستند. فیلد parameter سایت باید نام سایتی را تعیین کند که مقالات را برای تمام ورودی‌های قیف مدیریت می‌کند.

مثال‌ها (EXAMPLES)

نحو فایل newsfeeds بسیار پیچیده است زیرا می‌توانید تنوع شگفت‌انگیزی از فیدها را مشخص کنید. سرور INN قادر به تعامل با برنامه‌های بسیار متنوعی است که کارهای گوناگونی با مقالات خبری انجام می‌دهند. با این حال، با فاصله زیاد دو مدخل رایج در newsfeeds، فیدهای فایلی برای nntpsend(8) و فیدهای قیفی برای innfeed(8) هستند.

نوع اول شبیه به این است:

feed.example.com:*,!control,!control.*,!junk:Tf,Wnm:

که فایلی به نام pathoutgoing/feed.example.com تولید می‌کند که حاوی یک خط به ازای هر مقاله شامل توکن API ذخیره‌سازی، یک فاصله، و شناسه پیام (Message-ID) است.

نوع دوم شبیه به این است:

feed.example.com:*,!control,!control.*,!junk:Tm:innfeed!

بسیار شبیه است، جز اینکه این ورودیِ یک فید قیفی به نام "innfeed!" است. همچنین می‌توان این را به صورت زیر نوشت:

example/feed.example.com:*,!control,!control.*,!junk:Ap,Tm:innfeed!

(به Ap توجه کنید تا مقالاتی که فقط حاوی "example" در بدنه فیلد سرآیند Path هستند نیز همچنان ارسال شوند)، که کاملاً معادل است به جز اینکه این مورد در pathlog/news به عنوان ارسال به سایت "example" به جای "feed.example.com" لاگ خواهد شد.

مدخل معمولی فید برای innfeed(8) مثال خوبی از یک فید کانالی است که مقصد فیدهای قیفی گوناگون است (مطمئن شوید که مسیر innfeed به درستی تنظیم شده باشد):

innfeed!:!*:Tc,Wnm*:<pathbin in inn.conf>/innfeed -y

توجه داشته باشید که pattern برای این فید فقط "!*" است تا هیچ مقاله‌ای را مستقیماً دریافت نکند. این فید تنها باید مقالاتی را دریافت کند که به یکی از فیدهای قیفی که به آن وارد می‌شوند می‌روند. برنامه innfeed(8) به ازای هر مقاله یک خط در ورودی استاندارد خود دریافت خواهد کرد که حاوی توکن API ذخیره‌سازی، شناسه پیام، و لیستی از سایت‌هایی که باید آن مقاله را دریافت کنند و با فاصله جدا شده‌اند، می‌باشد.

در اینجا مثالی تخصصی‌تر از یک فید کانالی آورده شده است:

watcher!:*:Tc,Wbnm\
    :exec awk '$1 > 1000000 { print "BIG", $2, $3 }' \
     >> <pathlog>/bigart

این مدخل اندازه بایت هر مقاله را به همراه توکن API ذخیره‌سازی و شناسه پیام دریافت می‌کند و به ازای هر مقاله‌ای که بیش از یک میلیون بایت است، یک خط به فایل لاگ bigart اضافه می‌کند. این در واقع روش عجیبی برای نوشتن این کار است زیرا INN خودش می‌تواند بررسی اندازه را انجام دهد؛ مورد زیر معادل آن است:

watcher!:*:Tc,>1000000,Wbnm\
    :exec awk '{ print "BIG", $2, $3}' >> <pathlog>/bigart

در اینجا یک درگاه خبر به ایمیل (news to mail gateway) جالب و بسیار ساده آورده شده است که به عنوان نمونه‌ای از یک فید برنامه‌ای پیشرفته نیز عمل می‌کند:

mailer!:!*:W*,Tp\
    :sm %s | innmail -s "News article" *

به یاد داشته باشید که "%s" با توکن API ذخیره‌سازی جایگزین می‌شود، بنابراین این دستور مقاله را بازیابی کرده و آن را به innmail (که امن‌تر از برنامه‌هایی مانند Mail(1) است زیرا بدنه را برای دستورات تیلده پردازش نمی‌کند) با موضوع معین پایپ می‌کند. به استفاده از "*" در خط فرمان و W* در پرچم‌ها توجه کنید؛ این مدخل طوری طراحی شده است که به عنوان مقصد فیدهای قیفی مانند زیر استفاده شود:

peter@example.com:news.software.nntp:Tm:mailer!
sue@example.com:news.admin.misc:Tm:mailer!

فرض کنید سرور مقاله‌ای دریافت می‌کند که بین news.admin.misc و news.software.nntp به صورت اشتراکی ارسال شده است. سرور متوجه می‌شود که مقاله باید به سایت "peter@example.com" و سایت "bob@example.com" فرستاده شود که هر دو به "mailer!" قیف می‌شوند، بنابراین به سایت "mailer!" نگاه می‌کند و در نهایت خط فرمان زیر را اجرا می‌نماید:

sm @...@ | innmail -s "News article" \
    peter@example.com sue@example.com

که مقاله را هم برای Peter و هم برای Sue ایمیل می‌کند.

در نهایت، یک مثال بسیار کاربردی دیگر از فید کانالی: مدخل استاندارد برای controlchan(8). مطمئن شوید که مسیر آن به درستی تنظیم شده باشد.

controlchan!\
    :!*,control,control.*,!control.cancel\
    :AC,Tc,Wnsm:<pathbin in inn.conf>/controlchan

این برنامه تنها اطلاعات مربوط به مقاله‌های ارسال‌شده به یک گروه خبری کنترلی غیر از control.cancel را می‌خواهد، که به دلیل مرتب‌سازی پیام‌های کنترلی شرح‌داده‌شده در innd(8)، تمام پیام‌های کنترلی به جز پیام‌های لغو (cancel) را به آن ارسال می‌کند. برنامه controlchan برای هر مقاله، توکن API ذخیره‌سازی، نام سایت فرستنده (برای پردازش پیام‌های کنترلی سنتی ihave و sendme، حتماً درباره logipaddr در controlchan(8) مطالعه کنید) و شناسه پیام را دریافت می‌کند.

برای مثال‌های بسیار دیگر، از جمله مثال‌هایی از مدخل ویژه سایت "ME"، به فایل نمونه newsfeeds توزیع‌شده با INN مراجعه فرمایید. همچنین برای اطلاعات مربوط به راه‌اندازی مدخل‌های استاندارد newsfeeds که توسط اکثر سایت‌ها استفاده می‌شوند، به اسناد نصب ارائه‌شده با INN مراجعه نمایید.

تاریخچه (HISTORY)

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

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

active(5), buffchan(8), controlchan(8), ctlinnd(8), delayer(8), inn.conf(5), innd(8), innfeed(8), innxmit(8), libinn_uwildmat(3), nntpsend(8), sm(8).