INND(8) InterNetNews Documentation INND(8)

innd - دیمن سامانه اخبار InterNetNews

innd [-adfNrsSu] [-4 address] [-6 address] [-c days] [-H count] [-i count] [-l size] [-m mode] [-n flag] [-o count] [-P port] [-t timeout] [-T count] [-X seconds]

برنامه innd، دیمن سامانه اخبار InterNetNews، تمامی فیدهای ورودی NNTP را مدیریت می‌کند، ذخیره‌سازی، ارسال مجدد و تولید نمای کلی (overview) را برای همه مقالات پذیرفته‌شده هماهنگ می‌سازد، و پایگاه‌های داده active(5) و history(5) را اداره می‌کند. این برنامه به اتصال‌های ورودی روی درگاه NNTP رسیدگی می‌کند و همچنین یک سوکت محلی استریم در دامنه یونیکس ایجاد کرده و به آن گوش می‌دهد تا مقالات را از فرآیندهای محلی مانند nnrpd(8) و rnews(1) دریافت کند.

به‌عنوان دیمن اصلی، innd عموماً باید هنگام راه‌اندازی سیستم شروع به کار کرده و همیشه در حال اجرا باشد. این دیمن به یک سوکت دیتاگرام دامنه یونیکس برای دریافت دستورهای کنترلی گوش می‌دهد؛ دستورهایی که می‌توان با استفاده از ctlinnd(8) آن‌ها را ارسال کرد. وضعیت کنونی innd را می‌توان با اجرای دستور "ctlinnd mode" یا برای خروجی دقیق‌تر با اجرای innstat(8) به دست آورد.

برنامه innd می‌تواند در یکی از سه حالت کاری باشد: در حال اجرا (running)، متوقف‌شده (paused) یا محدودشده (throttled). حالت عادی، در حال اجرا است؛ هنگامی که سرور محدود شده باشد، اتصال‌ها را می‌بندد و اتصال‌های جدید را رد می‌کند. حالت متوقف‌شده مانند یک محدودسازی موقت است که فعالیت‌های innd را به حالت تعلیق درمی‌آورد، اما اتصال‌های موجود سرور را قطع نمی‌کند. این حالت معمولاً از طریق ctlinnd(8) تغییر داده می‌شود، خواه توسط فرآیندهای خودکار گوناگون (مانند انقضای شبانه مقالات) و خواه به‌صورت دستی توسط مدیر اخبار؛ اما innd همچنین در صورت مواجهه با خطاهای ENOSPC در نوشتن داده‌ها یا تعداد بیش از حد خطاهای ورودی/خروجی (در میان سایر مشکلات)، خودبه‌خود به حالت محدودشده تغییر وضعیت می‌دهد.

برنامه innd به‌طور معمول وظیفه اجرای nnrpd(8) را برای مدیریت اتصال‌های کارخواه‌های خواننده اخبار بر عهده دارد، اما می‌تواند روی درگاهی جداگانه از nnrpd(8) نیز اجرا شود تا اتصال‌های فید و اتصال‌های خواندن اخبار به‌صورت جداگانه مدیریت شوند (این روش اغلب می‌تواند سریع‌تر باشد). به‌طور معمول، innd به درگاه ۱۱۹ که درگاه اختصاصی NNTP است گوش می‌دهد؛ چنانچه اجرای innd و nnrpd(8) روی درگاه‌های جداگانه مطلوب باشد، توصیه می‌شود به nnrpd(8) درگاه ۱۱۹ اختصاص داده شود (زیرا بسیاری از کارخواه‌های خواننده اخبار تنها به این درگاه متصل می‌شوند) و درگاه ۴۳۳ برای innd به کار رود.

فایل‌های پیکربندی اصلی که فعالیت‌های innd را کنترل می‌کنند عبارتند از: incoming.conf که پایگاه‌های دوردستی را که innd اتصال آن‌ها را می‌پذیرد مشخص می‌کند؛ newsfeeds که مشخص می‌کند علاوه بر ذخیره‌سازی، چه اقدامی باید روی مقالات ورودی انجام شود؛ و inn.conf که طیف گسترده‌ای از پارامترهای پیکربندی را تعیین می‌کند. برخی از پارامترها در inn.conf(5) را می‌توان با فلگ‌های خط فرمان نیز تعیین کرد؛ برای این موارد، فلگ‌های خط فرمان در صورت استفاده اولویت خواهند داشت.

برنامه innd باید با کاربر news و گروه news اجرا شود. این برنامه در هنگام شروع به کار این موضوع را بررسی کرده و در صورت عدم اجرای صحیح، متوقف می‌شود. این دیمن به‌طور معمول باید از طریق rc.news(8) به‌عنوان بخشی از فرآیند بوت سیستم راه‌اندازی شود. همچنین برای گوش دادن به درگاه‌های ممتاز (۱۱۹، ۴۳۳ یا ۵۶۳) به برنامه کمکی innbind(8) با دسترسی setuid root متکی است.

برای گزینه‌های زیر که تنظیمات inn.conf را لغو می‌کنند، در صورتی که نه تنظیم inn.conf و نه گزینه خط فرمان مشخص نشده باشند، مقادیر پیش‌فرض را در inn.conf(5) مشاهده کنید.

-4 address
به‌طور معمول، innd به تمام نشانی‌های IP محلی متصل می‌شود (مگر اینکه bindaddress در inn.conf تنظیم شده باشد). اگر این گزینه مشخص شود، نشانی IP مورد نظر برای اتصال INN را تعیین می‌کند. این ویژگی تنها برای سرورهایی که دارای چندین نشانی IP محلی هستند کاربرد دارد. نشانی IP باید در قالب چهاربخشی نقطه‌دار ("nnn.nnn.nnn.nnn") باشد.

مشخص کردن این گزینه معادل تنظیم bindaddress در inn.conf است و ممکن است بر اتصال INN به یک نشانی IPv6 نیز تأثیر بگذارد. برای جزئیات بیشتر به inn.conf(5) و همچنین فلگ -6 برای innd مراجعه کنید.

این گزینه هنگام استفاده از فعال‌سازی سوکت توسط systemd هیچ اثری ندارد.

-6 address
تنها هنگامی اعمال می‌شود که INN با پشتیبانی از IPv6 ساخته شده باشد. به‌طور معمول innd به تمام نشانی‌های IP محلی متصل می‌شود (مگر اینکه bindaddress6 در inn.conf تنظیم شده باشد). اگر این گزینه داده شود، نشانی IPv6 مورد نظر برای اتصال INN را تعیین می‌کند. نشانی IPv6 باید در قالب تفکیک‌شده با دونقطه بر طبق RFC 4291 ("n:n:n:n:n:n:n:n") باشد.

مشخص کردن این گزینه معادل تنظیم bindaddress6 در inn.conf است و ممکن است بر اتصال INN به یک نشانی IPv4 نیز تأثیر بگذارد. برای جزئیات بیشتر به inn.conf(5) و همچنین فلگ -4 برای innd مراجعه کنید.

این گزینه هنگام استفاده از فعال‌سازی سوکت توسط systemd هیچ اثری ندارد.

به‌طور پیش‌فرض، اگر میزبانی به innd متصل شود اما نام آن در incoming.conf فهرست نشده باشد، اتصال به nnrpd واگذار می‌شود (یا در صورت تنظیم noreader در inn.conf، رد می‌شود). اگر -a مشخص شود، فایل incoming.conf نادیده گرفته شده و هر میزبانی می‌تواند متصل شود و مقالات را انتقال دهد. این فلگ هرگز نباید در سرورهای قابل دسترسی و متصل به یوزنت (Usenet) استفاده شود؛ زیرا سرور را در معرض انواع سوءاستفاده‌ها قرار می‌دهد.
برنامه innd به‌طور معمول مقالاتی را که قدیمی‌تر (بر حسب روز) از مقدار artcutoff در inn.conf باشند رد می‌کند. این گزینه در صورت تعیین، مقدار آن تنظیم را لغو می‌کند. اگر days برابر با 0 باشد، این بررسی انجام نمی‌شود و innd مقالات را صرف‌نظر از قدمت آن‌ها می‌پذیرد.

توجه داشته باشید که مقالات ردشده به مدت تعداد روزهای تعیین‌شده در خط "/remember/" در expire.ctl(5) به خاطر سپرده می‌شوند. برای تزریق مجدد مقاله‌ای با همان شناسه پیام (Message-ID) قبلاً ردشده، باید به اندازه آن تعداد روز منتظر بمانید.

چنانچه نیاز به تزریق مجدد مقالات پیش از پایان این بازه زمانی داشته باشید، باید مقدار "/remember/" را در expire.ctl برابر با "0" قرار دهید، فرآیند expire را اجرا کنید (مثلاً از طریق news.daily با همان پارامترهای crontab به همراه "notdaily") و سپس تغییر اعمال‌شده در expire.ctl را لغو کنید. پس از آن، در صورت ارائه مجدد شناسه پیام، تمامی مقالات ردشده یا حذف‌شده قبلی دیگر تکراری تلقی نخواهند شد.

برنامه innd به‌طور معمول خود را به پس‌زمینه می‌برد، خروجی استاندارد و خطای استاندارد را به فایل‌های گزارش هدایت می‌کند و از ترمینال جدا می‌شود. استفاده از -d از تمامی این موارد جلوگیری کرده و باعث می‌شود پیام‌های گزارش در خروجی استاندارد نوشته شوند؛ این قابلیت معمولاً تنها برای اشکال‌زدایی کاربرد دارد. استفاده از -f مانع رفتن به پس‌زمینه و جدا شدن از ترمینال می‌شود اما همچنان خروجی را تغییر مسیر می‌دهد؛ این گزینه زمانی مفید است که بخواهید innd را توسط برنامه‌ای نظارت کنید که با انشعاب‌های فرآیند (forks) دچار سردرگمی می‌شود.
این فلگ‌ها تعداد اتصال‌های مجاز در هر seconds ثانیه را کنترل می‌کنند. این بخش از کد با هدف محافظت از سرور شما در برابر کارخواه‌های خواننده خبری طراحی شده است که اتصال‌های بسیار زیادی در هر دقیقه برقرار می‌کنند (بنابراین این فلگ‌ها احتمالاً تنها زمانی مفید خواهند بود که innd در حال راه‌اندازی nnrpd باشد). بهتر است از این گزینه‌ها استفاده نکنید مگر اینکه دچار مشکل شده باشید. جدول مورداستفاده برای این بررسی با ظرفیت ۱۲۸ مدخل ثابت بوده و به‌صورت حلقوی استفاده می‌شود؛ این اندازه به این منظور انتخاب شده که محاسبه شاخص آسان باشد و اطمینان حاصل شود که فضا تمام نخواهد شد. در عمل، بعید است که در هر لحظه حتی نیمی از این جدول استفاده شود.

فلگ -H تعداد دفعاتی را که یک میزبان مجاز است در بازه زمانی ارائه‌شده با -X به سرور متصل شود محدود می‌کند. مقدار پیش‌فرض "2" است.

فلگ -T تعداد کل اتصال‌های ورودی در بازه زمانی ارائه‌شده با -X را محدود می‌کند. بیشینه مقدار "128" و مقدار پیش‌فرض "60" است.

توجه داشته باشید که بازه زمانی تعیین‌شده با -X به‌طور پیش‌فرض برابر با "0" تنظیم شده است؛ به این معنی که هیچ کنترلی روی تعداد اتصال‌ها اعمال نمی‌شود.

برنامه innd به‌طور معمول حداکثر تعداد اتصال‌های هم‌زمان NNTP را مطابق با مقدار maxconnections در inn.conf مجاز می‌داند. این گزینه در صورت تعیین، مقدار آن تنظیم را لغو می‌کند. اگر count برابر با "0" باشد، این بررسی غیرفعال می‌شود.
برنامه innd به‌طور معمول هر مقاله‌ای را که بزرگ‌تر از مقدار maxartsize در inn.conf باشد رد می‌کند. این گزینه در صورت تعیین، مقدار آن تنظیم را لغو کرده و بیشینه اندازه مجاز مقاله را به size تعیین می‌کند. اگر size برابر با "0" باشد، این بررسی غیرفعال می‌شود.
به‌طور معمول، innd در حالت "running" آغاز به کار می‌کند. اگر این گزینه مشخص شود، تعیین می‌کند که innd باید در چه حالتی شروع به کار کند. مقدار mode باید با یکی از حروف "g"، "p" یا "t" شروع شود، و حالت شروع بر پایه آن حرف اول به‌ترتیب روی "running"، "paused" یا "throttled" تنظیم خواهد شد. ("g" مخفف "go" است).
در صورت تعیین این گزینه، هر فیلتری (Perl یا Python) پیش از شروع innd غیرفعال می‌شود (به‌طور معمول، فیلترها به‌صورت پیش‌فرض فعال هستند). این فیلترها را می‌توان پس از شروع innd با استفاده از ctlinnd(8) فعال کرد.
اینکه آیا innd در زمان توقف یا محدودیت اجازه برقراری اتصال‌های خواننده را می‌دهد (و آن‌ها را به nnrpd می‌سپارد) یا خیر، به‌طور معمول بر اساس مقدار readerswhenstopped در inn.conf تعیین می‌شود. این گزینه در صورت تعیین، مقدار یادشده را لغو می‌کند. اگر flag برابر با "n" باشد، innd در صورت متوقف یا محدود بودن، به خوانندگان اجازه دسترسی نخواهد داد. اگر flag برابر با "y" باشد، خوانندگان صرف‌نظر از حالت کاری innd مجاز خواهند بود.
این فلگ تعداد توصیف‌کننده‌های فایل موجود برای فیدهای فایلی خروجی را محدود می‌کند. مقدار پیش‌فرض برابر با تعداد توصیف‌کننده‌های فایل در دسترس منهای مقداری ذخیره‌شده برای استفاده‌های داخلی است (که در غیر این صورت ممکن است innd را از توصیف‌کننده‌های موردنیاز برای پذیرش اتصال‌های جدید محروم سازد). اگر innd تعداد فیدهای فایلی بیشتری از count داشته باشد، برخی از آن‌ها بافر شده و تنها به‌صورت دوره‌ای نوشته می‌شوند.

به‌طور معمول هرگز نیازی به استفاده از این گزینه ندارید، زیرا تعداد فیدهای خروجی ثابت بوده و همان تعداد فیدهای فایلی پیکربندی‌شده در newsfeeds است که معمولاً اندک می‌باشد (به‌ویژه با توجه به اینکه امروزه در پایگاه‌های بزرگ، innfeed(8) برای اکثر فیدهای خروجی به کار می‌رود).

درگاهی که innd باید به آن گوش دهد به‌طور معمول توسط مقدار port در inn.conf مشخص می‌شود. این گزینه در صورت تعیین، آن مقدار را لغو کرده و درگاهی را که innd باید به آن متصل شود مشخص می‌کند.
به innd دستور می‌دهد که پس از شروع، فایل active را دوباره شماره‌گذاری کند، درست مانند اینکه دستور "ctlinnd renumber" ارسال شده باشد.
تنها صحت ساختار نحوی فایل newsfeeds را بررسی می‌کند و خارج می‌شود. در صورت یافت شدن هرگونه خطا، innd با وضعیتی غیرصفر خارج خواهد شد؛ خطاهای واقعی از طریق syslog(3) گزارش می‌شوند.
خطاهای یافت‌شده در incoming.conf را از طریق syslog(3) گزارش می‌دهد و به‌صورت عادی خارج می‌شود. (بله، این گزینه کمتر از آنچه که باید سودمند است.)
به‌طور معمول، innd پس از ۳۰۰ ثانیه عدم فعالیت، هرگونه تغییر اعمال‌شده در تاریخچه و فایل active را تخلیه (flush) می‌کند. این گزینه مهلت زمانی یادشده را به seconds تغییر می‌دهد.
گزارش اخبار (اطلاعات ردگیری برای هر مقاله‌ای که توسط innd پذیرفته می‌شود) به‌طور معمول بافر می‌شود. این گزینه گزارش را به حالت بدون بافر تغییر می‌دهد.

مقالاتی که دارای یک فیلد سرآیند Control هستند «پیام‌های کنترلی» نامیده می‌شوند. به‌جز پیام‌های لغو (cancel)، این پیام‌ها توسط controlchan(8) از طریق فیدی که در newsfeeds تنظیم شده است پردازش می‌شوند.

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

توزیع پیام‌های کنترلی با مقالات معمولی متفاوت است. پیام‌های کنترلی معمولاً صرف‌نظر از اینکه به چه گروه خبری ارسال شده باشند، در شبه‌گروه خبری به نام "control" ذخیره می‌شوند. با این حال، اگر گروه خبری منطبق با دستور کنترلی به‌صورت "control."command وجود داشته باشد، پیام کنترلی در آن گروه ذخیره می‌شود. برای مثال، یک پیام کنترلی newgroup در صورت وجود گروه "control.newgroup" در آن گروه بایگانی می‌شود؛ در غیر این صورت در "control" ذخیره خواهد شد.

چنانچه مایلید تمامی پیام‌های کنترلی را به‌طور مشخص برای یک پایگاه معین ارسال کنید، صرف‌نظر از اینکه این پیام‌های کنترلی بر گروه‌های خبری ارسالی به آن پایگاه تأثیر بگذارند یا خیر، می‌توانید گروه خبری کنترلی مناسب را در فهرست اشتراک آن قرار دهید. برای نمونه، برای ارسال تمامی پیام‌های لغو به یک پایگاه دوردست معین (که معمولاً ایده مناسبی نیست)، "control.cancel" را به فهرست اشتراک آن بیفزایید. معمولاً بهتر است گروه‌های خبری کنترلی از فیدها مستثنی شوند تا از ارسال پیام‌های کنترلی بیشتر از میزان مورد نیاز برای همتایانتان جلوگیری شود. به همین دلیل است که الگوی "!control,!control.*" در newsfeeds بسیار به کار می‌رود (افزودن این الگو مانع از ارسال پیام‌های کنترلی که بر گروه‌های خبری ارسال‌شده به آن پایگاه تأثیر می‌گذارند نمی‌شود).

پیام‌های کنترلی checkgroups، newgroup و rmgroup تحت رفتارهای ویژه دیگری قرار می‌گیرند. اگر یکی از این پیام‌های کنترلی تأیید شده و به گروه خبری در حال ایجاد یا حذف (یا به گروه مدیریتی که checkgroups به آن فرستاده می‌شود) ارسال شود، پیام برای تمامی پایگاه‌هایی که الگوهای اشتراک آن‌ها موجب دریافت مقالات فرستاده‌شده به آن گروه می‌شود، ارسال خواهد شد. برای مثال، اگر یک پیام کنترلی newgroup برای گروه خبری ناموجود "news.admin.meow" دریافت شود، به هر پایگاهی که الگوی اشتراک آن در صورت وجود داشتن این گروه خبری باعث دریافت "news.admin.meow" می‌شد (مانند الگوی "news.admin.*") ارسال خواهد شد. به همین دلیل، ارسال پیام‌های newgroup به گروه خبری که قرار است توسط پیام کنترلی ایجاد شود صحیح است. اما ارسال پیام‌های newgroup به‌صورت هم‌زمان (crosspost) به یک گروه خبری «با انتشار گسترده» عموماً درست نیست؛ این کار نه‌تنها انتشار آن‌ها را به پایگاه‌هایی که خواهان چنین پیام‌های کنترلی هستند بهبود نمی‌بخشد، بلکه باعث می‌شود پایگاه‌هایی نیز که تمایلی به این پیام‌های کنترلی ندارند آن‌ها را دریافت کنند. بنابراین، با این فرض که یک پیام کنترلی newgroup به‌منظور ایجاد گروه "news.admin.meow" به گروه "news.admin.meow" (مشخص‌شده در بدنه فیلد سرآیند Newsgroups) ارسال شده باشد، پایگاه‌هایی با الگوهای اشتراک زیر آن را دریافت خواهند کرد:

*,@news.*
news.*
news.*,!control,!control.*
control,control.*

در واقع برای الگوی نخست، "control.newgroup" (یا "control") در "*" گنجانده شده است. با این حال، پایگاه‌هایی با الگوهای اشتراک زیر آن را دریافت نخواهند کرد:

*,@news.*,!control,!control.*
comp.*,@news.*

اگر یک پیام کنترلی به گروهی ارسال شود که نام آن با چهار نویسه ".ctl" به پایان می‌رسد، این پسوند حذف شده و پیام کنترلی به‌گونه‌ای منتشر می‌شود که گویی به گروه پایه ارسال شده است. برای مثال، یک پیام لغو ارسال‌شده به "news.admin.ctl" به تمامی پایگاه‌هایی که مشترک "control.cancel" (یا در صورت عدم وجود این گروه خبری، "control") یا "news.admin" هستند ارسال خواهد شد. این رفتار به دلایل سازگاری تاریخی باقی مانده است و باید منسوخ تلقی شود؛ ممکن است پشتیبانی از پسوند ".ctl" در نسخه‌های آینده INN برچیده شود.

در نهایت، با مقالات فرستاده‌شده به گروه‌های خبری که با "to." شروع می‌شوند به‌صورت ویژه رفتار می‌شود. به شرطی که آن گروه خبری در فایل active وجود داشته باشد یا mergetogroups در inn.conf تنظیم شده باشد، باقی‌مانده نام گروه خبری به‌عنوان نام پایگاه در نظر گرفته می‌شود (همان‌گونه که در newsfeeds پیکربندی شده است) و مقاله به پایگاه‌های منتشرکننده "to.uunet" ارسال می‌گردد. اگر mergetogroups تنظیم شده باشد، مقاله در گروهی به نام "to" (که باید در فایل active وجود داشته باشد) ذخیره خواهد شد. برای مثال، با فعال بودن mergetogroups، مقاله‌ای که به "to.uunet" ارسال شده در گروه "to" ذخیره شده و برای پایگاه‌های منتشرکننده "to.uunet" ارسال می‌شود.

برنامه innd دستورهای NNTP تعریف‌شده در RFC 3977 (NNTP)، RFC 4643 (احراز هویت NNTP)، RFC 4644 (فیدهای استریم NNTP) و RFC 6048 (افزوده‌های فهرست NNTP) را با تفاوت‌های زیر پیاده‌سازی می‌کند:

1.
یک دستور انتقال دسته‌ای، XBATCH byte-count، ارائه شده است. این دستور byte-count بایت را می‌خواند و آن‌ها را برای پردازش بعدی توسط rnews(1) (که باید جداگانه، احتمالاً توسط cron اجرا شود) ذخیره می‌کند. برای جزئیات بیشتر درباره این افزونه به innxbatch(8) و sendxbatches مراجعه کنید.
2.
از آنجا که INN یک سرور اخبار مبتنی بر تغییر حالت است، innd زیرمجموعه محدودی از پروتکل را که برای انتقال اخبار سودمند است پیاده‌سازی می‌کند. باقی دستورها اغلب فقط برای خوانندگان اخبار کاربرد دارند و توسط nnrpd(8) پیاده‌سازی شده‌اند. استفاده از دستور MODE READER باعث می‌شود که innd اتصال را به nnrpd منتقل کند.
3.
برنامه innd ساختار نحوی گسترده‌تری را برای الگوهای تطبیق (wildmats) مجاز می‌داند.
4.
سه دستور (IHAVE، CHECK و TAKETHIS) به دلایل سازگاری و تعامل‌پذیری، در زمانی که دستور دارای خطای نحوی باشد همچنان یک کد رد (به‌ترتیب "435"، "438" و "439") برمی‌گردانند (در حالی که این موارد به‌طور معمول به کد "501" منجر می‌شوند).

برنامه innd تا حد امکان کمترین تغییرات را در سرآیندهای مقالات اعمال می‌کند، اگرچه می‌توانست در این زمینه بهتر عمل کند.

بدنه‌های خالی فیلدهای سرآیند و بدنه‌هایی از فیلدهای سرآیند که صرفاً شامل نویسه‌های فاصله خالی هستند، دور انداخته می‌شوند.

نام پایگاه محلی (همان‌طور که با پارامتر pathhost در inn.conf تنظیم شده است) به همراه یک علامت تعجب به ابتدای بدنه فیلد سرآیند Path اضافه می‌شود، مشروط بر اینکه نخستین نام پایگاه در بدنه فیلد سرآیند Path با نام پایگاه محلی متفاوت باشد. علاوه بر این، pathalias و pathcluster ممکن است به‌طور مشابه و به‌ترتیب به‌عنوان هویت‌های مسیر، بلافاصله در سمت راست یا چپ pathhost در بدنه فیلد سرآیند Path الحاق شوند؛ برای جزئیات به inn.conf(5) مراجعه کنید.

فیلد سرآیند Xref حذف شده و یک فیلد جدید ایجاد می‌گردد.

برنامه innd فیلدهای سرآیند نادرست را بازنویسی نمی‌کند. برای مثال، فیلد سرآیند نادرست Lines را جایگزین نخواهد کرد، هرچند ممکن است بسته به مقدار linecountfuzz در inn.conf چنین مقاله‌ای را رد کند.

به‌منظور اعمال کارآمد شمار زیادی از لغوهای محلی (مانند موارد ناشی از پردازش NoCeMها یا برخی منابع خارجی دیگر)، INN از یک حالت فید ویژه پشتیبانی می‌کند که تنها برای اتصال‌ها به سوکت محلی در دامنه یونیکس در دسترس است (نه برای اتصال‌ها به سوکت‌های شبکه).

برای ورود به این حالت، به سوکت دامنه یونیکس (pathrun/nntpin) متصل شوید و دستور MODE CANCEL را ارسال کنید. پاسخ سرور دارای کد "284" خواهد بود. هر خط بعدی ارسال‌شده روی آن اتصال باید تنها شامل یک شناسه پیام (message-ID) باشد. تلاشی برای لغو آن شناسه پیام صورت خواهد گرفت، و سرور در صورت موفقیت پاسخ "289" و در صورت شکست پاسخ "484" ارائه می‌دهد. (شکست می‌تواند برای نمونه زمانی رخ دهد که سرور متوقف یا محدود شده باشد، یا شناسه پیام مخدوش باشد. اگر مقاله‌ای که باید لغو شود وجود نداشته باشد، شکست رخ نمی‌دهد).

برنامه innd تمامی مقالات ورودی را در فایل گزارش خود (pathlog/news) ثبت می‌کند. این یک فایل متنی با تعداد متغیری از فیلدهای جداشده با فاصله در یکی از قالب‌های زیر است:

mon dd hh:mm:ss.mmm + feed <message-id> site ...
mon dd hh:mm:ss.mmm j feed <message-id> site ...
mon dd hh:mm:ss.mmm c feed <message-id> Cancelling <message-id>
mon dd hh:mm:ss.mmm - feed <message-id> reason
mon dd hh:mm:ss.mmm ? feed <message-id> reason

بسته به تنظیمات nntplinklog و logartsize در inn.conf، ممکن است فیلدهای نام میزبان و/یا اندازه نیز پس از شناسه پیام وجود داشته باشد.

سه فیلد اول تاریخ و زمان را با دقت میلی‌ثانیه نشان می‌دهند. فیلد پنجم سایتی است که مقاله را فرستاده است (بر اساس بدنه فیلد سرآیند Path) و فیلد ششم شناسه پیام (Message-ID) مقاله است؛ در صورتی که اطلاعات موجود نباشد، این فیلدها یک علامت سؤال خواهند بود.

فیلد چهارم نشان می‌دهد که آیا مقاله پذیرفته شده است یا خیر. اگر علامت مثبت (+) باشد، مقاله پذیرفته شده است. اگر حرف "j" باشد، مقاله پذیرفته شده است، به این شرط که تمام گروه‌های خبری که مقاله به آن‌ها فرستاده شده بود در فایل active روی وضعیت "j" تنظیم شده باشند (یا در فایل active فهرست نشده باشند و wanttrash در inn.conf تنظیم شده باشد)، و در این حالت مقاله در گروه خبری "junk" قرار می‌گیرد. در هر دوی این موارد، مقاله پذیرفته شده است و فیلد "site ..." شامل فهرست جداشده با فاصله از پایگاه‌هایی است که مقاله به آن‌ها ارسال می‌شود.

اگر فیلد چهارم حرف "c" باشد، یک پیام لغو پیش از رسیدن مقاله اصلی پذیرفته شده است و یک مدخل تاریخچه برای پیام لغو شده ایجاد گردیده تا innd در صورت رسیدن بعدی آن پیام، آن را رد کند.

اگر فیلد چهارم علامت منفی (-) باشد، مقاله رد شده است. دلایل رد مقالات که توسط innd تولید می‌شوند عبارتند از:

"%s" header too long
Article exceeds local limit of %s bytes
Article posted in the future -- "%s"
Bad "%s" header field
Can't write history
Duplicate
Duplicate "%s" header field
EOF in headers
Linecount %s != %s +- %s
Missing %s header field
No body
No colon-space in "%s" header field
No matching newsgroups in cancel <%s>
No space
Space before colon in "%s" header field
Too old -- "%s"
Unapproved for "%s"
Unwanted newsgroup "%s"
Unwanted distribution "%s"
Whitespace in "Newsgroups" header field -- "%s"

که در آن "%s" در بالا با اطلاعات دقیق‌تر جایگزین می‌شود. (فیلترهای Perl و Python در صورت استفاده ممکن است مقالات را با دلایل دیگری رد کنند.)

اگر فیلد چهارم حرف "?" باشد، مقاله حاوی رشته‌های نامتعارفی است؛ مانند CR بدون LF یا LF بدون CR. (این نویسه‌ها هرگز نباید به‌صورت مجزا رخ دهند، بلکه تنها باید همراه یکدیگر به‌صورت CRLF برای نشان دادن انتهای یک خط بیایند.) این پیام گزارش صرفاً جنبه اطلاع‌رسانی دارد تا دیدگاهی درباره میزان رواج چنین مقالاتی ارائه دهد؛ innd چنین مقالاتی را رد نمی‌کند.

توجه داشته باشید هنگامی که wanttrash در inn.conf روی true تنظیم شده باشد و مقاله‌ای دریافت شود که به هیچ گروه خبری معتبری ارسال نشده است، پذیرفته شده و با دو خط در گزارش ثبت می‌شود: یک خط "j" و یک خط با علامت منفی؛ مگر اینکه پارامتر logtrash روی false تنظیم شده باشد (که در این صورت فقط خط "j" نوشته می‌شود).

برنامه innd همچنین گزارش‌های گسترده‌ای را از طریق syslog(3) ارائه می‌دهد. اگر مدخل مربوط به پایگاه خاصی باشد (مانند پیام "connected")، کلمه نخست پیام گزارش نام پایگاه خواهد بود. اگر پیام به خود سرور مربوط باشد، مانند زمانی که خطای خواندن رخ می‌دهد، کلمه اول "SERVER" خواهد بود.

اگر کلمه دوم عبارت چهارحرفی "cant" باشد، یک خطا در حال گزارش شدن است. (نبود علامت آپوستروف عمدی است؛ این کار اجرای grep از خط فرمان و یافتن پیام‌های خطا در سوالات متداول با موتور جستجو را آسان‌تر می‌سازد. با این حال، در چند مورد از "can't" نیز استفاده شده است.) در این حالت، دو کلمه بعدی عموماً نام فراخوانی سیستمی یا روال کتابخانه‌ای ناموفق و شیئی را که عملیات روی آن انجام می‌شده مشخص می‌کنند. باقی خط ممکن است شامل اطلاعات دیگری باشد.

در موارد دیگر، کلمه دوم سعی می‌کند تغییری را که صورت گرفته خلاصه کند، در حالی که بقیه خط اطلاعات مشخص‌تری ارائه می‌دهد. کلمه "internal" عموماً نشان‌دهنده یک خطای منطقی داخلی است.

برنامه innd سیگنال‌های SIGTERM و SIGHUP را دریافت کرده و متوقف می‌شود. در صورت استفاده از -d، سیگنال SIGINT نیز دریافت شده و منجر به توقف منظم سیستم خواهد شد.

برنامه innd سیگنال SIGUSR1 را دریافت کرده و کانال کنترلی مورد استفاده توسط ctlinnd(8) را بازسازی می‌کند.

نوشته‌شده توسط Rich $alz <rsalz@uunet.uu.net> برای InterNetNews.

active(5), ctlinnd(8), history(5), incoming.conf(5), inn.conf(5), innbind(8), innfeed(8), innstat(8), libinn_dbz(3), libinn_inndcomm(3), newsfeeds(5), nnrpd(8), rnews(1), syslog(3).

2025-03-29 INN 2.7.4