AKADEMIA GÓRNICZO- HUTNICZA

AKADEMIA GÓRNICZO- HUTNICZA Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki KATEDRA INFORMATYKI Konfiguracja serwera newsów INN 3.06.2002 Kierunek, rok studiów: Informatyka, IV rok Przedmiot: Administrowanie systemami komputerowymi Prowadzący zajęcia: Rok akad: 2001/2002 mgr inż. Bogusław Juza Semestr: letni Autorzy: Przemysław Musiał feyman@student.uci.agh.edu.pl Marek Wieczorek cage@student.uci.agh.edu.pl Kraków, czerwiec 2002

0. Spis treści 0. Spis treści... 1 1. Wprowadzenie... 2 2. Wcześniejsze oprogramowanie dla Usenetu... 2 2.2. B News... 2 2.3. C News... 3 3. InterNetNews (INN)... 4 4. Różne architektury serwera INN... 5 4.1. Architektura scentralizowana... 5 4.2. Architektura rozproszona ze współdzielonym spool filesystemem... 4.3. Architektura rozproszona z replikacją... 6 7 5. Podstawowe funkcje systemu INN... 8 5.1. Zarządzanie strumieniem danych... 8 5.2. Odbieranie wiadomości od klientów... 9 5.2. Filtrowanie wiadomości... 9 5.3. Tworzenie nowych grup... 9 5.4. Usuwanie przeterminowanych wiadomości i gospodarowanie logami... 10 5.5. Zarząadzanie systemem... 10 6. Rodzaje spool filesystemu... 10 7. Drzewo katalogów systemu INN... 13 8. Opisy ważniejszych plików konfiguracyjnych 8.1. inn.conf 8.2. newsfeeds 8.3. readers.conf 8.4. incoming.conf 8.5. storage.conf 8.6. cycbuff.conf..................... 13 13 16 18 21 22 24 9. Działanie i najważniejsze komendy programu ctlinnd... 25 10. Przykładowa konfiguracja 2 serwerów INN... 30 11. Skrypt wyszukujący 20 najczęściej łączących się klientów... 34 1

1. Wprowadzenie. Usenet jest to rozproszony system dystrybucji wiadomości zbudowany w oparciu o fizyczną strukturę sieci. Wiadomości rozsyłane są za pomocą protokołu NNTP z pakietu TCP/IP (RFC822); format wiadomości Usenetu opisuje dokument RFC1036. Grupy Newsowe jest to hierarchiczny system klasyfikacji wiadomości w Usenecie. W nagłówku każdej wiadomości znajduje się informacja w jakiej grupie Newsowej dana wiadomość powinna się znaleźć. Każdy z serwerów Newsów, w oparciu o które funkcjonuje Usenet, ma możliwość przechwytywania i udostępniania wiadomości należących do dowolnych grup Newsowych. Wiadomości wygenerowane na jakimś hoście są następnie dystrybuowane do najbliższych sąsiadów, którzy z kolei rozsyłają je do swoich sąsiadów etc. A B C D rys.1 Przykładowa topologia Usenetu. Aby uniknąć zapętleń, każdy host dodaje swoją nazwę do nagłówka wiadomości kiedy odebrana zostanie wiadomość w nagłówku której znajduje się nazwa danego hosta zostanie ona usunięta i nie będzie propagowana dalej. Innym zabezpieczeniem przed otrzymywaniem redundantnych wiadomości jest przechowywanie na hostach ID wiadomości które dany host już otrzymał. W sieci o topologii przedstawionej na rys.1, jeżeli host D otrzymał wiadomość W z hosta B to zapamiętuje on jej ID, by w momencie gdy otrzyma ją jeszcze raz z hosta C mógł ją zidentyfikować i automatycznie odrzucić. 2. Wcześniejsze oprogramowanie dla Usenetu. 2.1. B News B News był to historycznie pierwszy pakiet oprogramowania dla Usenetu. Składał się on z pojedyńczego programu rnews który przetwarzał każdy nadchodzący artykuł dopisując go do bazy odebranych wiadomości. W celu zapewnienia, że tylko 1 rnews jednocześnie edytuje bazę stosowany jest mechanizm blokady (ang. locking). Ze względu na dużą ilość przetwarzanych wiadomości (nieraz 15.000 na dzień) blokada często zawodzi i nierzadkie jest występowanie 10 a nawet 100 duplikatów dziennie. Największe niedogodności wynikające z użytkowania B News wynikają z faktu przetwarzania każdej wiadomości przez osobny proces. Szczególnie widoczne jest to podczas propagacji wiadomości do sąsiednich site ów: zakładając, że nasz site odbiera dziennie 15.000 wiadomości i musi je rozdystrybuować do 10 sąsiadów, oznacza to 150.000 operacji I/O co może stanowić wąskie gardło dla pracującego w sieci systemu Newsów. 2

Wszystkie te niedogodności zadecydowały o tym, że B News nie są już rozwijane ani nigdzie wykorzystywane, choć kolejne wersje oprogramowania zapewniają wsteczną kompatybilność z B News. 2.2. C News C News pojawiło się niedługo po B News i w krótkim czasie wyparło go całkowicie. Nowością wprowadzoną w tym pakiecie był oddzielny program relaynews, uruchamiany kilka razy dziennie, którego zadaniem było przetwarzanie wiadomości które nadeszły w czasie od poprzedniego uruchomienia. Ponieważ uruchamiany jest tylko 1 instancja relaynews, nie jest zatem konieczna blokada dostępu do plików. Dodatkową poprawę wydajności uzyskuje się przez to, że przetwarzany jest na raz cały pakiet wiadomości które mogą być buforowane w pamięci. W sumie uzyskuje się przyspieszenie o 1 lub 2 rzędy wielkości. Ze względu na fakt, że wiadomości mogą przychodzić szybciej niż program relaynews jest je w stanie przetwarzać, konieczne stało się zatem buforowanie wiadomości w specjalnej kolejce (ang. spooling). Żeby unikać buforowania wiadomości tylko po to by je później usunąć, w modelu tym wprowadzono specjalny demon msgidd który buforuje w pamięci listę wiadomości otrzymanych w ciągu ostatnich 24 godzin. Pozwala to usunąć większość redundantnych wiadomości zanim w ogóle zostały one umieszczone w kolejce. Implementacja C News również posiada szereg słabych punktów: komunikacja serwera NNTP z innymi hostami odbywa się poprzez demona msgidd do niego kierowane są wszystkie zapytania zanim wiadomość zostanie pobrana; jeżeliby pierwsza kopia artykułu umieszczona w kolejce okazała się być uszkodzona, prawie na pewno nie zostanie ona powtórnie pobrana, nawet gdy wygaśnie już cache msgidd-a; ponieważ wszystkie artykuły są kolejkowane, relaynews nie jest w stanie powiedzieć serwerowi co stało się z danym artykułem, przez co serwer nie jest w stanie przekazać tej wiadomości swojemu sąsiadowi; trudno jest przez to wykryć ewentualne problemy z transmisją artykułów. Wszystkie te problemy spowodowały konieczność stworzenia nowej implementacji oprogramowania zarządzającego Usenetem. 3

3. InterNetNews (INN) Serwer newsów INN jest systemem dużo bardziej rozbudowanej i skomplikowanej od dwóch poprzednich architekturze. W jego skład wchodzi szereg demonów systemowych i innych programów oraz plików pomocniczych. active history spool wiadomości od użytkowników filter_nnrpd nnrpd expire fastrm news.daily scanlogs nadchodzące wiadomości filter_nnrpd innd logs innfeed innreport raport mailowy strumień danych o wysokim natężeniu, replikacja newsów dla odbiorców batch innxmit strumień danych o niskim natężeniu ctlinnd nntpsend rys.2 Architektura serwera INN. strumień wiadomości od użytkowników (klientów) strumień wiadomości nadciągających (z innych serwerów) strumień danych innych niż wiadomości wywołania programów procesy pliki filtry innd - podstawowy serwer newsów odpowiedzialny za przetwarzanie napływających danych (ang. newsfeeds). Nasłuchuje on na porcie 119 i akceptuje połączenia użytkowników. Dla każdego zaakceptowanego połączenia uruchamia oddzielny proces nnrpd w celu dalszej interakcji z użytkownikiem. nnrpd - serwer NNTP odpowiedzialny za obsługę klientów NNTP (ang. newsreaders). innxmit, nntpsend - programy oferujące newsy przetwarzane przez serwer innym site om, z wykorzystaniem plików wsadowych (strumień o niskim natężeniu), innfeed - program wysyłający newsy innym site om z wykorzystaniem specjalnych stworzonych w tym celu kanałów (strumień w wysokim natężeniu), ctlinnd - program odpowiedzialny za wysyłanie poleceń do innd, news.daily - wykonuje szereg istotnych funkcji administracyjnych: usuwanie przeterminowanych wiadomości, tworzenie logów, etc.; wywoływany zwykle za pomocą demona cron, expire, fastrm - programy odpowiedzialne za kasowanie wiadomości z serwera, expire analizuje plik history i wydaje do fastrm polecenia usunięcia przeterminowanych artykułów, 4

active - plik zawierający listę grup które lokalny site otrzymuje, history - plik zawierający informację o przechowywanych oraz ostatnio usuniętych wiadomościach Usenetu, spool - kolejka wiadomości na serwerze, 4. Różne architektury serwera INN Konfiguracje serwera newsów mogą się różnić między sobą jeżeli chodzi o stopień rozproszenia systemu. Możliwe są 3 poziomy rozproszenia: architektura scentralizowana (pojedyńczy serwer), architektura rozproszona ze współdzielonym spool filesystemem, architektura rozproszona z replikacją. 4.1. Architektura scentralizowana Jest to najprostszy sposób konfiguracji serwera newsów, w którym cały serwer umieszczony jest na 1 maszynie (patrz: rys.2). Przeznaczony jest dla małych systemów o niewielkiej wymaganej wydajności. zalety łatwość w utrzymaniu łatwiej zarządzać prostą, scentralizowaną architekturą niż skomplikowaną, rozproszoną niski koszt jeżeli obciążenie generowane przez serwer newsów jest niskie, komputer może służyć również do innych celów wady ograniczona skalowalność możliwa jest jedynie tzw. skalowalność pionowa (ang. vertical scalability), np. dodatkowa pamięć lub CPU pojedyńczy punkt awarii każde uszkodzenie powoduje wyłączenie całego systemu 5

4.2. Architektura rozproszona ze współdzielonym spool filesystemem Rozproszenie serwera newsów polega z grubsza rzecz biorąc na rozdzieleniu części centralnej serwera (ang. feeder) zajmującej się przyjmowaniem i wysyłaniem strumienia wiadomości, oraz klientów czytelników, którzy mogą być przez to lekkimi maszynami o niewielkich wymaganiach na zasoby. Dodatkowo rozproszyć można również sam spool filesystem, w którym przechowywany jest zasób wiadomości newsowych. W modelu rozważanym obecnie, filesystem pozostaje nadal scentralizowany. nadchodzące wiadomości wiadomości od użytkowników feeder news store active history spool czytelnik1 czytelnik2 czytelnik3 użytkownicy rys.3 Architektura rozproszona ze współdzielonym spool filesystemem Czytelnicy odbierają połączenia użytkowników, odczytują artykuły z kolejki i dostarczają je do użytkowników, odbierają wiadomości od użytkowników i dostarczają je do feedera. Feeder odbiera nadchodzący strumień danych z zewnętrznych site ów oraz wiadomości od użytkowników, zapisuje je do kolejki oraz wysyła na zewnątrz. Magazyn danych - może istnieć jako oddzielny host przyłączony poprzez NFS, bądź też być zasobem dyskowym istniejącym jako integralna część jednego z elementów systemu (najczęściej feedera). 6

4.3. Architektura rozproszona z replikacją W tym wariancie architektury serwera newsów istnieje w dalszym ciągu 1 feeder zajmujący się przyjmowaniem i wysyłaniem strumienia wiadomości, rozproszony zostaje jednak zasób dyskowy, w którym przechowywane są przetwarzane dane. Każdy z czytelników posiada w tym modelu swój własny magazyn danych będący repliką magazynu centralnego; replikacją danych zajmuje się feeder, on również dba o synchronizację danych we wszystkich lokalizacjach. news store nadchodzące wiadomości wiadomości od użytkowników active history spool feeder reader1 store active history spool reader1 store active history spool reader1 store active history spool news store active history spool czytelnik1 czytelnik2 czytelnik3 użytkownicy rys.4 Architektura rozproszona z replikacją 7

Czytelnicy odbierają połączenia użytkowników, odczytują artykuły ze swojej lokalnej kolejki i dostarczają je do użytkowników, odbierają wiadomości od użytkowników i dostarczają je do feedera. Czytelnicy NIE aktualizują swoich lokalnych kolejek to zadanie wykonuje feeder w procesie replikacji. Feeder odbiera nadchodzący strumień danych z zewnętrznych site ów oraz wiadomości od użytkowników, zapisuje je do kolejki oraz wysyła na zewnątrz. Dokonuje również replikacji zewnętrznych zasobów danych. 5. Podstawowe funkcje systemu INN Implementacja INN serwera newsów posiada szereg rozbudowanych opcji związanych z odbiorem i dystrybucją wiadomości, subskrypcją grup newsowych, metodami zabezpieczeń ruchu w sieci (przed niepowołanym dostępem lub spamem), etc. Konfiguracja serwera odbywa się przeważnie poprzez szereg plików konfiguracyjnych lub polecenia programu ctlinnd. 5.1. Zarządzanie strumieniem danych Podstawowe funkcje serwera newsów polegające na przetwarzaniu głównego strumienia danych. Akceptacja / odrzucanie przetwarzanego strumienia danych innd może pobierać dane z więcej niż jednego site u w sieci. Konfiguracji site ów z których pobierany jest strumień danych dokonuje się w pliku incoming.conf. Wszystkie napływające artykuły mogą być na wstępnym etapie przefiltrowane przez odpowiedni filtr filter_innd i odrzucone. Konfiguracji użytych filtrów w zależności od użytych wiadomości dokonuje się poprzez plik control.ctl; informacje o rezultatach działania filtrów logowane są w plikach news.log i news. Zaakceptowane wiadomości są następnie przesyłane do demona innd i ewentualnie rozsyłane do kolejnych site ów w sieci bądź to poprzez kanał komunikacji, bądź też poprzez plik wsadowy (ang. batchfile). Konfiguracja przekierowania strumienia wiadomości dokonywana jest przy pomocy pliku newsfeeds. Jeżeli grupa na którą przyszła dana wiadomość jest moderowana, wiadomość ta nie jest przesyłana od razu do innd ale wysyłana jest na specjalnie ustawiony dla niej adres mailowy. Konfiguracji takich adresów dla moderowanych grup dokonuje się w pliku moderators. Przetwarzanie artykułów kontrolnych Istnieje specjalna klasa artykułów służących do zarządzania grupami (t.j. tworzenia i usuwania grup). Artykuły takie, zwane artykułami kontrolnymi są wysyłane na grupy o adresach control.*. Są one przetwarzane są za pomocą programu ctlinnd wywoływanego bądź to ręcznie przez administratora, bądź to automatycznie przez innd. Ponieważ możliwość konfiguracji serwera poprzez artykuły kontrolne są łatwą furtką dla możliwych ataków z zewnątrz, istotne jest właściwe skonfigurowanie systemu pod względem przetwarzania wiadomości kontrolnych, za pomocą pliku control.ctl. Przetwarzanie artykułów anulujących Oprócz artykułów kontrolnych istnieje też druga klasa artykułów specjalnych tzw. artykuły anulujące (ang. cancel articles). Są one wysyłane na grupy o adresach 8

cancel.*, a ich działanie polega na usunięciu odpowiednich artykułów z danego serwera, oraz ze wszystkich innych serwerów na świecie. Gdy innd odbierze taki artykuł, dokonuje on operacji kasowania na swojej kolejce oraz pliku historii, oraz wysyła artykuł anulujący dalej. Wysyłanie na zewnątrz strumienia wiadomości: niskie natężenie Jednym ze sposobów wysyłania danych jest wykorzystanie do tego tzw. metody wsadowej (ang. batch method). Tworzone są tutaj tzw. pliki wsadowe (ang. batch files) zawierające informacje o wiadomościach do wysłania i następnie, w odstępach czasu określonych np. za pomocą demona cron uruchamiany jest skrypt nntpsend który sprawdza wszystkie pliki wsadowe i odpala dla każdego hosta instancję programu innxmit wysyłającego wiadomości. innxmit nawiązuje połączenie, transferuje dane i kończy działanie. Wysyłanie na zewnątrz strumienia wiadomości: wysokie natężenie Kiedy spodziewamy się dużego natężenia wysyłanych wiadomości możemy zastosować przesyłanie danych z wykorzystaniem tzw. kanałów komunikacji. W tym celu wykorzystywany jest na początku program innfeed który nawiązuje połączenia z poszczególnymi hostami. Kiedy innd nadeśle wiadomość, innfeed rozsyła ją do wszystkich zainteresowanych nią hostów, a w przypadku ich niedostępności lub zbyt wolnego przetwarzania danych zapisuje w kolejkach (ang. backlog files) tworzonych oddzielnie dla każdego hosta. Kolejki te mogą być systematycznie przycinane w celu zabezpieczenia przed wyczerpaniem przestrzeni dyskowej. Prędkość transferu danych, ilość otwartych połączeń i gospodarowanie nimi, zarządzanie plikami kolejkowymi oraz wiele innych opcji konfigurowanych jest w pliku konfiguracji innfeed.conf. 5.2. Odbieranie wiadomości od klientów Połączenia od klientów przetwarzane są przez demona nnrpd. Wiadomości które przychodzą tą drogą są najpierw przetwarzane przez filtr filter_nnrpd który jest ładowany w momencie startu nnrpd. Istnieją 2 możliwe konfiguracje: - nnrpd automatycznie przesyła do feedera każdą nadesłaną wiadomość, - wiadomości są najpierw składowane w pliku wsadowym a następnie cyklicznie przesyłane przy pomocy programu rnews; jeżeli rnews nie może w danej chwili przesłać danych do feedera (który na przykład w danym momencie nie działa), pozostawia je w kolejce aby spróbować je przesłać następnym razem; 5.3. Filtrowanie wiadomości Istnieją 2 podstawowe filtry wykorzystywane przez system (np. w celu zabezpieczenia się przed spamem): filter_nnrpd i filter_innd. Pierwszy z nich filtruje wiadomości nadsyłane przez klientów, drugi z nich filtruje cały strumień wiadomości napływający do feedera (w tym również wiadomości od klientów). Informacje o odrzuconych artykułach są umieszczane w logach systemu. 5.4. Tworzenie nowych grup Informacje o grupach odbieranych przez serwer zawarte są w pliku active. Dodawanie grup realizować można na 3 sposoby: ręcznie edytując plik active (nie polecane), wykorzystując istniejący plik active, używając programu ctlinnd. 9

By móc korzystać z programu ctlinnd musi być uruchomiony serwer innd, a ten z kolei wymaga istnienia w pliku active co najmniej 1 już dodanej grupy. Oznacza to, że przy początkowym uruchamianiu systemu musi już istnieć stworzony ręcznie plik active (patrz: 9. Działanie i najważniejsze komendy programu ctlinnd). Grupy moderowane Moderowane grupy jest to specjalny rodzaj grup które nie dopuszczają bezpośredniego wysyłania artykułów przez użytkowników, ale jedynie przez użytkowników specjalnego typu zwanych moderatorami. Każdy artykuł nadesłany przez użytkownika jest wysyłany e-mailem do moderatora i to moderator ma za zadanie zdecydować, czy wiadomość ta powinna się pojawić na grupie, czy też nie. 5.5. Usuwanie przeterminowanych wiadomości i gospodarowanie logami Celem dokonywania cyklicznych zmian w systemowym magazynie wiadomości oraz w systemowych logach, wykonywany jest cyklicznie program news.daily. Jest on odpowiedzialny za uruchamianie programu expire, który po upływie określonego czasu usuwa wiadomości z systemu zaznaczając zmiany w plikach active i history. W przypadku gdy używany jest standardowy spool filesystem, expire uruchamia również fastrm w celu fizycznego usunięcia wiadomości. news.daily odpowiada również za uruchamianie programu scanlog, który z kolei zarządza zbiorem logów systemowych i uruchamia innreport w celu przetwarzania ich i wysyłania odpowiednich komunikatów mailowych do administratora. 5.6. Zarządzanie systemem Istnieją 2 programy których zadaniem jest zarządzanie systemem newsów: - ctlinnd, który umożliwia wydawanie poleceń serwerowi innd (takich jak tworzenie/usuwanie grup, zarządzanie plikami wsadowymi etc.); - innwatch który uruchamiany cyklicznie sprawdza stan serwera (obciążenie, liczbę wolnych inodów), odpowiednio reagując na wykryte ewentualne problemy. 6. Rodzaje spool filesystemu Istnieją 4 różne formy w jakich przechowywana być może główny magazyn (spool) wiadomości w systemie: 1. Tradycyjny spool Jest to najprostsza z metod w jakich umieszczane są w systemie wiadomości: każda wiadomość jest tutaj przechowywana po prostu w osobnym pliku, w specjalnie przeznaczonym do tego celu katalogu (każda grupa w oddzielnym katalogu). Sposób ten ma swoje ograniczenia w starszych systemach w których kilka lub kilkanaście tysięcy artykułów jakie może zawierać magazyn danych dla jakiejś grupy stanowi barierę niemożliwą do pokonania. Większość jednak obecnie stosowanych systemów nie ma problemu z nadmierną ilością plików w katalogu, więc sposób ten jest z powodzeniem stosowany. Ten sposób implementacji filesystemu jest przyjmowany domyślnie. Wymaga jedynie wyspecyfikowania w pliku inn.conf w parametrze patharticles ścieżki do katalogu w której ma być przechowywany spool. 2. Spool hashowany czasowo (timehash) Ta metoda przechowywania wiadomości w systemie stworzona została jako modyfikacja poprzedniej metody w celu poradzenia sobie z problemem zbyt dużej ilości plików w 10

katalogach. Tak jak poprzednio dla każdej grupy przeznaczony jest tutaj oddzielny katalog, dodatkowo jednak artykuły w każdym z tych katalogów podzielone są na podkatalogi tworzone systematycznie w czasie działania systemu. Taki system miał zapewniać, że w żadnym z podkatalogów liczba plików nie przekroczy dopuszczalnego systemowo limitu. Gdy jednak liczba plików w katalogu przestała w obecnych systemach mieć krytyczne znaczenie, spadło znaczenie tego spool filesystemu. Dodatkowo skomplikowany sposób zarządzania systemem katalogów generuje tutaj duży narzut na działanie systemu i utrudnia ręczne szukanie interesującego nas artykułu w systemie. Metoda ta jest implementowana w pliku storage.conf (patrz: 8.5). 3. Buforowany spool hashowany czasowo (timecaf) Jest to metoda analogiczna do poprzedniej, z tą jednak różnicą że zamiast przeznaczać na każdy artykuł oddzielny plik, w oddzielnym pliku umieszczane są wszystkie artykuły należące do każdej z kolejnych, wyznaczonych czasowo grup (czyli każdemu plikowi odpowiada w poprzednim modelu pojedyńczy podkatalog). Zmniejszenie systemowego narzutu związanego z tworzeniem nowych plików zapewnia około 4-krotny wzrost wydajności w porównaniu z poprzednim modelem. Metoda ta jest implementowana w pliku storage.conf (patrz: 8.5). 4. Spool oparty na cyklicznym buforze (CNFS) W tej metodzie wszystkie artykuły umieszczane są w specjalnie skonfigurowanym pliku buforowym. Bufor ten obsługiwany jest cyklicznie, co oznacza że w momencie osiągnięcia końca bufora wszystkie następne wiadomości są nadpisywane w miejsce najstarszych. Stąd też pochodzi nazwa metody Cyclic News FileSystem (CNFS). Metoda ta zapewnia doskonałą wydajność przetwarzania oraz w łatwy sposób zabezpiecza przed wyczerpaniem się przestrzeni dyskowej. Podstawową jej wadą jest jednak fakt, że użytkownik nie posiada żadnej kontroli nad czasem przechowywania artykułów w systemie. Jest więc polecana np. w przypadku szybko rozrastających się grup, dla których nie jest istotne zapewnienie odpowiedniego QoS. Metoda ta jest implementowana w dwóch plikach: storage.conf (8.5) oraz specjalnym pliku cycbuf.conf (8.6) definiującym specjalne parametry bufora. 11

7. Drzewo katalogów systemu INN cron.daily pliki demona cron konfigurujące wysyłanie danych do feedera i usuwanie przeterminowanych artykułów cron.hourly plik demona cron konfigurujący wysyłanie danych na zewnątrz moderators adresy moderowanych grup newsfeeds konfiguruje wysyłanie strumienia danych nnrp.access [przestarzały] plik dostępu dla czytelników news2mail.cf actsync.cfg cycbuff.conf plik konfiguracyjny dla spool filesystemu CNFS incoming.conf nazwy i adresy serwerów dostarczających dane inn.conf główny plik konfiguracyjny dla INN innfeed.conf plik konfiguracyjny dla innfeed etc innreport.conf news storage.conf plik konfigurujący rodzaje spool filesystemów control.ctl specyfikuje obsługę wiadomości kontrolnych expire.ctl reguluje obsługę przeterminowanych artykułów innwatch.ctl kontroluje program nadzorujący innwatch nntpsend.ctl lista site ów zaopatrywanych w dane przez nntpsend overview.ctl overview.fmt format danych w bazie overview actsync.ign motd.news lokalne informacje o czytelnikach newsów passwd.nntp hasła dostępu do zdalnych serwerów NNTP distrib.pats domyślne wartości pól Distribution: nagłówka nnrpd.track plik specyfikujący hosty śledzone przez nnrpd rc.d init.d innd serwer INN rc.news skrypt startowy serwera INN bin skrypty, filtry wiadomości (podkatalog filter) i inne pliki wykonywalne doc usr lib różne skrypty man strony manuala active lista aktywnych grup newsowych distributions history lista obecnych i usuniętych artykułów newsgroups opisy grup newsowych lib news subscriptions.news.daily history.dir history.pag var active.times log news katalog zawierający pliki z logami serwera run news katalog z plikami używanymi gdy serwer jest uruchomiony archive archiwizowany magazyn artykułów articles magazyn artykułów spool news incoming artykuły przychodzące do serwera infeed outgoing artykuły wychodzące z serwera overview baza danych overview uniover zunifikowana baza dannych overview rys.5 Przykładowe drzewo katalogów dla serwera INN 12 <rootdir>

8. Opisy ważniejszych plików konfiguracyjnych 8.1. inn.conf inn.conf Główny plik konfiguracyjny serwera innd. Format wpisu: <parameter>:<whitespace><value> W pliku muszą wystąpić wszystkie dozwolone opcje. fromhost - nazwa hosta używana przy tworzeniu pola From w nagłówku artykułu; jeżeli wyspecyfikowana jest zmienna środowiskowa FROMHOST wartość tego argumentu jest nadpisywana moderatormailer - nazwa domyślnej maszyny która zawiera aliasy wszystkich moderowanych grup; opcja używana w przypadku, gdy nie jest stworzony plik moderators; domyślnie wartość nie jest ustawiona organization - używana przy tworzeniu pola Organization w nagłówku artykułu (jeżeli nie jest ono ustawione); jeżeli wyspecyfikowana jest zmienna środowiskowa ORGANIZATION wartość tego argumentu jest nadpisywana pathhost - specyfikuje nazwę lokalnego hosta używaną przy tworzeniu nagłówka Path artykułu; domyślnie jest używana pełna nazwa hosta server - specyfikuje nazwę domyślnego serwera NNTP; jeżeli wyspecyfikowana jest zmienna środowiskowa NNTPSERVER wartość tego argumentu jest nadpisywana; domyślnie wartość nie jest ustawiona domain - specyfikuje nazwę domenową lokalnego hosta; domyślnie wartość nie jest ustawiona overviewmap - wartość logiczna definiująca czy tablica indeksów overview ma być mapowana w pamięci (polecenie mmap) storageapi - wartość logiczna definiująca czy artykuły mają być składowane przy użyciu zdefiniowanego w pliku storage.conf specjalnego spool filesystemu (storage API) (patrz. 8.5) maxforks - ile instancji programu może zostać odpalonych (poleceniem fork) maxartsize - maksymalny rozmiar artykułów możliwy do zaakceptowania przez serwer (0 - brak ograniczeń, domyślnie 1000000) nicekids - jeżeli przyjmuje wartość różną od 0, wszystkie procesy potomne będą posiadać taką wartość priorytetu nice nicenewnews - jeżeli przyjmuje wartość większą od 0, wszystkie procesy nnrpd wykonujące polecenie 'NEWNEWS' ustawią priorytet na tą wartość; wartość ignorowana, jeżeli jest mniejsza od wartości nicekids mta - specyfikuje agenta mailowego (message transfer agent) używaanego przy wysyłaniu wiadomości do moderatora; możliwa do użycia opcja '%s' zamieniana przy wywołaniu na adres moderatora; domyślnie nieustawiona, co powoduje jednak generowanie błędów systemowych mailcmd - ścieżka do programu mailowego wysyłającego raporty i wiadomości kontrolne; domyślnie ustawiony jest program innmail verifycancels - wartość logiczna specyfikująca czy ma być dokonywana weryfikacja, czy osoba wywołująca 'cancel' jest osobą która wysłała wiadomość; weryfikacja taka nie jest możliwa jeżeli polecenie 'cancel' przyszło zanim dotarła wiadomość logcancelcomm - wartość logiczna specyfikująca, czy mają być logowane informacje o wykonaniu poleceń 'ctlinnd calcel'; domyślnie ustawiona na 'false' wanttrash - wartość logiczna specyfikująca, czy wiadomości nadchodzące na adres nieznanych grup mają być wysyłane na adres grupy 'junk'; domyślnie ustawiona na 'false' remembertrash - wartość logiczna specyfikująca, czy w historii mają być pamiętane wszystkie odrzucone artykuły; pozwala to oszczędzić czas przy ponownym oferowaniu tych samych artykułów linecountfuzz - jeżeli wartość ta jest ustawiona na inną wartość niż 0, wówczas liczba linii w artukule sprawdzana jest z polem Lines: nagłówka artykułu i pole w nagłówku jest korygowane, jeżeli różni się od rzeczywistej liczby linii o więcej niż ta wartość logartsize - wartość logiczna specyfikująca, czy rozmiar artykułu ma być logowany w logach systemowych; domyślnie ustawiona na 'true' logipaddr - wartość logiczna specyfikująca, czy adres hosta ma być logowany zamiast wartości pola Path: nagłówka artykułu; domyślnie ustawiona na 'true' logsitename - wartość logiczna specyfikująca, czy nazwa site'u ma być logowana; domyślnie ustawiona na 'true' overviewname - nazwa pliku w którym mają być umieszczane dane overview; domyślnie '.overview' extendeddbz - wartość logiczna spacyfikująca, czy offset w pliku overview powinien być umieszczany w pliku dbz; może to znacząco poprawić wydajność, ale rozmiar pliku zwiększy się przez to 3 razy nnrpdoversize - wartość logiczna specyfikująca, czy statystyki overview powinny być logowane; standardowo ustawiona na 'false' storeonxref - wartość logiczna specyfikująca, czy storage API powinno składować artykuły bazując na polu Xref: nagłówka (w przeciwnym razie składowanie to odbywa się na podstawie nazwy grupy umieszczonej w nagłówku); standardowo ustawiona na 'true' nnrpdcheckart - wartość logiczna specyfikująca, czy nnrpd powinien sprawdzać czy dana wiadomość istnieje, zanim wykona na niej komendę; opcja może być użyteczna, ponieważ wiadomość może być usunięta, podczas gdy jej dane overview w dalszym ciągu istnieją; standardowo ustawiona na 'true' 13

storemsgid - wartość logiczna specyfikująca, czy pole Message-ID nagłówka powinno być składowane w pliku history; opcja dostępna gdy storageapi jest ustawione na 'false'; standardowo ustawione na 'true' usecontrolchan - wartość logiczna specyfikująca, czy powinno się używać kanałów transmisji dla wiadomości kontrolnych za wyjątkiem 'cancel'; jeżeli opcja jest ustawiona należy skonfigurować controlchan w pliku newsfeeds i zapewnić, że w pliku active znajduje się grupa 'control.cancel'; standardowo ustawiona na 'false' mergetogroups - wartość logiczna specyfikująca, czy grupy 'to.*' powinny być przekierowywane do 'to'; grupa 'to' powinna istnieć w pliku active; opcja standardowo ustawiona na 'false' keywords - wartość logiczna specyfikująca, czy w bazie overview powinny być generowane słowa kluczowe; ustawienie wartości wymaga również zmiany w pliku overview.fmt i usunięcia istniejącej bazy overview; dodatkowo w pliku config.data opcja KEYWORDS powinna być ustawiona na DO; standardowo ustawione na 'false' keylimit - maksymalna liczba bajtów zarezerwowana dla stworzenia słowa kluczowego (standardowo 512) keyartlimit - maksymalny rozmiar artykułu dla którego będą stworzone słowa kluczowe; wartość domyślna wynosi 100000 keymaxwords - maksymalna liczba słów kluczowych które będą wygenerowane dla artukułu (standardowo 250) refusecybercancels - wartość logiczna specyfikująca, czy odrzucać wiadomości których pole Message-ID: w nagłówku zaczyna się od '<cancel.'; odrzucenie to odbywa się przed dokonaniem wpisu do pliku history; standardowo ustawione na 'false' activedevable - jeżeli ta wartość logiczna jest ustawiona, wówczas nnrpd komunikuje się z plikiem active za pomocą protokołu UDP którym porozumiewa się ze specjalnie uruchomionym procesem actived activedupdate - liczba sekund określająca okres po jakim actived aktualizuje przechowywany w pamięci plik active activedport - port UDP na którym odbywa się komunikacja z actived noreader - wartość logiczna ustawiona standardowo na 'false' specyfikująca, czy nnrpd powinien stworzyć proces potomny dla obsłużenia połączenia z hostem nie wymienionym w incoming.conf pathnews - ścieżka do katalogu domowego będącego najczęściej korzeniem hierarchii systemu newsów pathbin - ścieżka do katalogu z programami obsługującymi newsy; standardowo '<pathnews>/bin' pathfilter - ścieżka do filtrów w perlu i TCL; standardowo '<pathnews>/filter' pathcontrol - ścieżka do katalogu z plikami kontrolnymi, uruchamianymi za pomocą polecenia podawanego w linii Control: w nadsyłanych artykułach; standardowo '<pathnews>/control' pathdb - ścieżka do plików używanych i zmienianych przez serwer (active, history i newsgroups); standardowo '<pathnews>/db' pathetc - ścieżka do katalogu z plikami konfiguracyjnymi; standardowo '<pathnews>/etc' pathrun - ścieżka do katalogu z plikami używanymi gdy serwer jest uruchomiony (pliki blokady, sockety kanałów); standardowo '<pathnews>/run' pathlog - ścieżka do katalogu gdzie zapisywane sa pliki z logami; standardowo '<pathnews>/log' pathhttp - ścieżka do katalogu gdzie umieszczane są pliki HTML (np. raport statusu); standardowo <pathlog> pathtmp - ścieżka do katalogu gdzie różne programy umieszczają swoje pliki tymczasowe; standardowo: <PATH wyspecyfikowany w --with-path w 'configure'> pathspool - ścieżka do katalogu będącego korzeniem dla magazynu danych; opcja obecnie nie używana; standardowo '<pathnews>/spool' patharticles - ścieżka do katalogu w którym składowane są artykuły; standardowo '<pathspool>/spool' pathoverview - ścieżka do katalogu w którym składowana jest baza overview; standardowo '<pathspool>/overview' pathoutgoing - ścieżka do katalogu w którym składowane są pliki wychodzące; standardowo '<pathspool>/outgoing' pathincoming - ścieżka do katalogu w którym składowane są przychodzące artykuły; standardowo '<pathspool>/incoming' patharchive - ścieżka do katalogu w którym składowane są archiwizowane artykuły; standardowo '<pathspool>/archive' pathuniover - ścieżka do katalogu w którym składowana jest zunifikowana baza overview; standardowo '<pathspool>/uniover' Opcje o nazwie zaczynającej się od 'backoff' są używane przez demona nnrpd do kontroli użytkowników o wysyłających wiadomości strumieniem o dużym natężeniu przy pomocy algorytmu backoff. Parametry tę są odczytywane na bieżąco w czasie pracy demona. Na potrzeby tego algorytmu użytkownicy są uporządkowani na podstawie ich adresu IP (albo nazwy symbolicznej, co specyfikuje opcja backoffout). Za każdym razem gdy dany host wyśle wiadomość, czas zajścia tego zdarzenia zostaje odnotowany. W momencie gdy w wyspecyfikowanym odstępnie czasu klient wyśle co najmniej określoną ilość wiadomości, algorytm backoff jest uruchamiany. Demon zasypia na określony czas; wiadomości w dalszym ciągu będą napływały, ale strumieniem o niższym natężeniu. Nowy czas bezczynności demona jest wyliczany na podstawie analizy, jak często napływać będą kolejne wiadomości. Jeżeli odstęp czasu pomiędzy kolejnymi nadesłanymi wiadomościami będzie mniejszy niż backoffpostfast, czas ten wyliczony będzie ze wzoru 1+(poprzedni_czas_bezczynności*backoff), jeżeli będzie większy niż backoffpostfast ale mniejszy od backoffpostslow, wówczas czas ten pozostanie bez zmian, jeżeli zaś będzie większy niż 14

backoffpostslow - zostanie wyzerowany i działanie algorytmu zacznie się od początku. Opcje używane tylko przez innd: pathalias - nazwa dodawana przed wyspecyfikowaną w pathhost, w momencie gdy wypełniane jest pole Path: nagłówka artykułu; standardowo nieustawiona hiscachesize - liczba kilobajtów przeznaczonych na cache w którym przechowywane są numery Message-ID: nadchodzących wiadomości; opcja użyteczna w przypadku, gdy duża ilość wiadomości nadchodzi zreplikowana i z opóźnieniem xrefslave - wartość logiczna specyfikująca, czy informacje zawarte w polu Xref: nagłówka będą wykorzystywane przy replikacji; opcja może być ustawiona w przypadku, gdy nnrpdposthost jest ustawione na wysyłanie wiadomości do macierzystego serwera; standardowo ustawione na 'false' nnrpdposthost - jeżeli wartość ustawiona jest na 'true', nnrpd i rnews wysyłają artykuły do określonego hosta; wartość może być ustawiona w przypadku, gdy xrefslave jest równiaż ustawione na 'true'; domyślnie ustawione na 'false' nnrpdpostport - port przez który dokonywane są połączenia w przypadku gdy nrpdposthost jest równe 'true'; standardowo ustawiony na 119 wireformat - jeżeli wartość ustawiona na 'true', wszystkie artykuły zapisywane są przez innd w formacie wire (znaki '\r\n' na końcu linii, podwójny odstęp na początku linii); jeżeli ustawiona jest opcja storageapi, wszystkie wiadomości są zapisywane w formacie wire i opcja te jest pomijana; wartość domyślna 'false' writelinks - jeżeli wartość jest ustawiona na 'true', wszystkie linki crosspost będą zapisywane w pliku history; opcja przydatna w sytuacji, gdy serwer obsługuje te linki; jeżeli ustawiona jest opcja storgeapi wszystkie takie linki są odrzucane; wartość domyślna 'true' status - jeżeli wartość ustawiona na '0' lub 'false', wówczas nie jest dokonywany żaden monitoring statusu; w przeciwnym wypadku opcja ta specyfikuje, co ile sekund ma być dokonywany monitoring; wartość domyślna '0' timer - jeżeli wartość ustawiona na '0' lub 'false', wówczas nie jest dokonywany żaden monitoring wydajności; w przeciwnym wypadku opcja ta specyfikuje, co ile sekund ma być dokonywany monitoring; wartość domyślna '0' peertimeout - ile sekund może być otwarty kanał nieaktywny przychodzący zanim serwer zamknie połączenie; wartość domyślna '0' readerswhenstopped - jeżeli wartość ustawiona na 'false', wówczas klienci mają w dalszym ciągu prawo łączyć się gdy serwer jest w stanie paused lub throttled ; wartość domyślna 'false' allownewnews - wartość logiczna specyfikująca, czy klienci mają prawo wykonywać polecenie 'NEWNEWS'; wartość domyślna 'true' chaninacttime - specyfikuje po ilu sekundach bezczynności serwer ma zaznaczać kanały jako bezczynne; wartość standardowa wynosi 600 chanretrytime - specyfikuje ile sekund serwer ma czekać aby powtórnie odtworzyć kanał komunikacji; wartość standardowa wynosi 300 maxconnections - maksymalna dozwolona liczba przychodzących połączeń; wartość standardowa wynosi 50 artcutoff - artykuły starsze niż wyspecyfikowana tutaj liczba dni są odrzucane; wartość domyślna wynosi 14 nntplinklog - czy plik zawierający nntplink info powinienn być umieszczany w logach; wartość domyślna 'false' nntpactsync - ile artykułów powinno być przetworzonych zanim zostanie to zalogowane jako operacja NNTP; wartość domyślna wynosi 200 badiocount - ile wadliwych operacji I/O może być wykonanych zanim kanał komunikacji zostanie uśpiony lub zamknięty; wartość domyślna wynosi 5 pauseretrytime - wyspecyfikowana tutaj liczba sekund powinna zostać odczekana, zanim kanał zostanie uznanay za nieaktywny; wartość standardowa wynosi 300 blockbackoff - liczba sekund do odczekania podczas wykonywania komendy zapisu 'EWOULDBLOCK'; wartość domyślna wynosi 120 icdsynccount - ile artykułów ma być zapisanych aby dokonana zastała kolejna zmiana w pliku active lub history; wartość domyślna wynosi 10 bindaddress - adres interfejsu na którym ma pracować innd; wartość musi być podana w notacji "kropkowej"; wartość 'all' lub brak wartości oznacza, że innd będzie nasłuchwał na wszystkich interfejsach; jeżeli ustawiona jest zmienna środowiskowa INND_BIND_ADDRESS, wartość tej opcji zastanie nadpisana; standardowo wartość nieustawiona sourceaddress - adres interfejsu dla wychodzących połączeń NNTP; wartość musi być podana w notacji "kropkowej"; jeżeli wartość jest równa 'all' lub nie jest wcale ustawiona, wówczas system operacyjny sam wybiera interfejs; standardowo wartość nieustawiona port - port TCP na którym serwer ma nasłuchiwać (standardowo 119) Opcje używane przez nnrpd i inews przy odbieraniu wiadomości od klientów: 15

checkincludedtext - jeżeli wartość jest ustawiona na 'true', wówczas artykuły nadsyłane przed klientów muszą mieć mniej niż 50% linii zawierających > ; wartość domyślna 'false' localmaxartsize - maksymalny rozmiar artykułu wysyłanego lokalnie (standardowo 1000000) mimevesion - jeżeli parametr jest ustawiony, wówczas nnrpd dodaje do nagłówka artykułu pole MIME specyfikujące używaną wersję Multipurpose Internet Mail Extension; standardowo wartość nieustawiona mimecontenttype - jeżeli dodawane są pola nagłówka MIME, wówczas opcja ta specyfikuje wartość dla pola Content-Type nagłówka; wartość standardowa wynosi "text/plain; charset=us-ascii." mimeencoding - jeżeli dodawane są pola nagłówka MIME, wówczas opcja ta specyfikuje wartość dla pola Content-Transfer-Encoding-Header nagłówka; wartość standardowa wynosi "7bit" spoolfirst - jeżeli wartość jest ustawiona na 'true', wówczas nnrpd umieszcza nadchodzące artykuły w spool'u zanim wyśle je do innd; ustawienie jest opcji przyspiesza działanie, może jednak spowodować że wiadomości te nigdy do innd nie dotrą; potrzebne jest wtedy cykliczne wywoływanie 'rnews -U'; wartość domyślna wynosi 'false' complaints - jeżeli wartość jest ustawiona, jest ona umieszczana w polu X-Complaints-To: nagłówka artykułu; w przeciwnym wypadku jest tam umieszczany domyślny adres newsmastera articlemmap - wartość logiczna specyfikująca, czy nnrpd ma używać mapowania (funkcja mmap()) artykułów w pamięci, czy też wykorzystywać zwykły dostęp do pliku; wartość domyślna 'false' clienttimeout - ile sekund nnrpd może utrzymywać nieaktywne zanim zostanie ono zamknięte; wartość domyślna wynosi 600 Następujące tutaj opcje są używane przez skrypt startowy 'rc.news': decnetdomain - opcja specyfikuje nazwę domeny dla klientów łączących się przez DECNET; połączenia takie są dozwolone tylko w przypadku, gdy było to uwzględnione podczas kompilacji (opcja 'AF_DECnet'); domyślnie wartość nieustawiona innflags - flagi przekazywane do INN w momencie startu; standardowo nieustawione doinnwatch - wartość logiczna specyfikująca, czy ma być uruchamiany program innwatch; wartość domyślna 'true' innwatchsleeptime - liczba sekund jaką innwatch ma być uśpiony zanim dokona kontroli; wartość standardowa wynosi 600 pgpverify - wartość logicza specyfikująca, czy należy wykonywać weryfikacji pgp dla wiadomości kontrolnych (oprócz wiadomości 'cancel'); wartość standardowa 'false' controlfailnotice - wartość logiczna używana w parze z usecontrolchan: jeżeli jest ona równa 'true' a usecontrolchan jest ustawiona na 'false', wówczas każdy problem z przetwarzaniem wiadomości kontrolnych jest raportowany administratorowi za pośrednictwem maila; w przeciwnym wypadku, gdy wartości obu tych opcji są przeciwne, wówczas nic nie jest raportowane; wartość domyślna wynosi 'false' logcycles - ile logowań powinno wykonać news.daily zanim logi będą nadpisywane; wartość domyślna wynosi 3 innwatchpauseload - średnie obciążenie (* 100) serwera przy którym innwatch powinien zatrzymać pracę innd; wartość domyślna wynosi 1500 innwatchhiload - średnie obciążenie (* 100) serwera przy którym innwatch powinien "przydusić" (ang. throttle) pracę innd; wartość domyślna wynosi 2000 innwatchloload - średnie obciążenie (* 100) serwera przy którym innwatch powinien przywrócić normalną pracę innd; wartość domyślna wynosi 1000 innwatchspoolspace - zajętość przestrzeni (podana w jednostkach wyjściowych inndf) osiągnięcie której w bazie artykułów i bazie overview ma spowodować "przyduszenie" innd przez program innwatch; wartość domyślna wynosi 800 innwatchbatchspace - zajętość przestrzeni (podana w jednostkach wyjściowych inndf) osiągnięcie której w bazie artykułów wychodzących ma spowodować "przyduszenie" innd przez program innwatch; wartość domyślna wynosi 25000 innwatchspoolnodes - zajętość przestrzeni (podana w jednostkach wyjściowych inndf) osiągnięcie której w bazie artykułów ma spowodować "przyduszenie" innd przez program innwatch; wartość domyślna wynosi 200 docnfsstat - wartość logiczna spacyfikująca, czy należy uruchomić program cnfsstat; wartość domyślna wynosi 'false' 8.2. newsfeeds Artykuły odczytane przez dany serwer mogą być następnie rozesłane do innych serwerów których nazwy zostały wpisane w pliku konfiguracyjnym newsfeeds. Wpisy w tym pliku określają zasady i ograniczenia (nazwy grup, maksymalną liczbę kroków do przebycia) jakim 16

podlegać musi artykuł by mógł zostać przesłany. Istnieją różne formy (tzw. rodzaje newsfeeda) w jakich serwer traktuje strumień danych w celu ewentualnego przekazania go dalej: log: Identyfikatory nagłówków są zapisywane jedynie w pliku logów systemowych <ścieżka_logów_inn>/news. Forma ta jest równoważna formie przesyłania danych przez plik, gdy plik ten nie jest nigdzie zapisywany. plik: Identyfikatory wiadomości są zapisywane dodatkowo w odpowiednim pliku wsadowym (dla każdego site'a powinien być ustawiony oddzielny plik). Informacje zapisane w tym pliku mogą być następnie wykorzystane przez program innxmit do transferu danych na dany site. innxmit może być wykonywany cyklicznie, za pomocą demona cron. Ponieważ dane przed zapisem ich w pliku wsadowym są wcześniej przechowywane w wewnętrznym buforze, przed każdym wywołaniem innxmit wskazane jest wypróżnienie bufora (operacja flush). program: Opcja ta pozwala na swobodne dysponowanie odbieranymi artykułami. Dla każdej wiadomości wykonywany jest program, do którego ścieżka podawana jest jako parametr. Programem takim może być np. mailer. kanał: Opcja pozwalająca na szybką transmisję danych o dużym natężeniu. Program, do którego ścieżka podawana jest w parametrze, otwiera połączenie nntp do zdalnego site'u. Poprzez to połączenie odbierane wiadomości są w czasie rzeczywistym przesyłane dalej. W przypadku problemów z połączeniem (awarie na łączu, przepełnienie wewnętrznego bufora) dane są kolejkowane w pliku specjalnie wybranym dla danego site'a (tak jak w przypadku transmisji przez plik). eksploder: Transmisja danych przez eksploder jest równoważna transmisji poprzez kanał, wzbogaconej o możliwość interpretacji i wykonywania poleceń serwera INN. Jeżeli w strumieniu wejściowym eksplodera pojawi się linia zaczynająca się od znaku '!' (wykrzyknik), jest ona traktowana jako polecenie do wykonania i jest przesyłana do interpretera poleceń ctlinnd. Przykładowymi poleceniami do wykonania mogą być rozkazy dodania / usunięcia grupy (newgroup group / rmgroup group) bądź też polecenie odświeżenia bufora / buforów (flush sitename / flush). lejek: Lejek (ang. funnell) jest to pomocnicze narzędzie, pozwalające rozdzielać strumień danych w celu przesłania go dalej do różnych site'ów. Lejek definiujemy tak jak zwykły site pobierający dane w jednej ze standardowych form (np. również jako lejek), następnie tak zdefiniowany lejek może służyć jako źródło danych dla innych site'ów. # newsfeeds # Określa dokąd ma wędrować odebrany strumień danych. Składnia pojedyńczego wpisu w pliku: sitename[/exclude,exclude...]\ :pattern,pattern...[/distrib,distrib...]\ :flag,flag...\ :param sitename - nazwa site'u do którego kierowany jest strumień danych exclude - jeżeli we wpisie występuje co najmniej raz to pole, dany artykuł NIE będzie wysłany do danego site'u jeżeli wyspecyfikowana tutaj nazwa wystąpiła w polu Path nagłówka pattern - pole zapisane w formacie 'wildmat'; specyfikuje grupy artykuły z których mają być wysłane do danego site'u distrib - jeżeli we wpisie występuje co najmniej raz to pole, dany artykuł będzie wysłany do danego site'u tylko wówczas gdy pole Distribution: nagłówka pasuje do podanych tutaj nazw flag - flagi pozwalają wyspecyfikować dodatkowe opcje dla wpisu: <size - rozmiar wiadomości musi być mniejszy niż size 17

>size - rozmiar wiadomości musi być większy niż size Achecks - dodatkowe wymagania wyspecyfikowane przez checks są sprawdzane przed wysłaniem artykułu Bhigh/low - opcje bufora Fname - specyfikuje nazwę pliku który ma być użyty przy przesyłaniu strumienia danych przez plik Gcount - artykuł zostanie przesłany do site'u tylko wówczas, gdy został wysłany do co najwyżej count grup Hcount - artykuł zostanie przesłany do site'u tylko wówczas, gdy w polu Path: nagłówka znajduje się co najwyżej count wpisów Isize - rozmiar wewnętrznego bufora przy przesyłaniu danych przez plik Nmodifiers - przy pomocy tej opcji można wyspecyfikować, by dany site otrzymywał tylko moderowane lub tylko niemoderowane grupy Ppriority - priorytet 'nice' dla programu lub kanału przesyłającego dane Ooriginator - przy wyspecyfikowaniu tej opcji artykuły które maja być przesłane muszą posiadać w nagłówku pole X-Trace: w którym z kolei 1 pole musi pasować dozadanego parametru; originator podawany jest w formacie 'wildmat' Ssize - w przypadku gdy rozmiar danych dla danego site'u przekroczy size, system dokonuje ich kolejkowania w odpowiednim pliku wymiany; zwykle używane tylko tylko przy transmisji poprzez kanał lub eksploder Ttype - specyfikuje rodzaj feeda dla danego site'u: c - kanał f - plik l - log m - lejek (ang. funnell) p - program x - eksploder Witems - dodatkowe opcje param - znaczenie tego pola zalezy od rodzaju feeda, np. nazwa lejka, w przypadku programu lub kanału - pełna ścieżka dostępu do odpowiedniego programu Przykład użycia lejka: plus.ds14.agh.edu.pl:pl.*,com.*:tm:lejek! galaxy.uci.agh.edu.pl:*/com.*:tm:lejek! lejek!:*:tc:/usr/bin/nntpfanout Przykład z życia wzięty: 192.168.26.34:*:Tf,Fwymiana: Default of everything to everybody except for junk, control, anything with "local" as the newsgroup prefix (i.e. matches "localhost.stuff") or groups under foo. Articles posted to any group under alt.binaries.warez will not get propagated, even if they're cross posted to something that is. ME\ :*,@alt.binaries.warez.*,!junk,!control*,!local*,!foo.*\ /world,usa,na,gnu,bionet,pubnet,u3b,eunet,vmsnet,inet,ddn,k12\ :: 8.3. readers.conf Plik readers.conf reguluje dostęp przez klientów do serwera nnrpd. Zawarte tutaj informacje definiują nam kto i na jakich zasadach ma prawo czytania wiadomości z określonych grup i wysyłania na nie. Istnieją 2 typy wpisów występujących w tym pliku: opcje oraz grupy konfiguracyjne. Opcje definiowane w pliku (w obrębie grup konfiguracyjnych) są zapisywane w formie pary <opcja>/<parametr>. Format wpisu jest następujący: w linii występuje nazwa opcji zakończona dwukropkiem, co najmniej 1 znak biały oraz parametr lub parametry oddzielone przecinkami (ciąg parametrów można dodatkowo wziąć w cudzysłów, co pozwala na umieszczenie dowolnej liczby białych znaków pomiędzy poszczególnymi parametrami). Przykłady opcji: hosts: *.example.com hosts: "*.example.com, *.example.net" hosts: *example.com,*example.net Długości linii w pliku podlegają ograniczeniom, które wynoszą przeważnie nieco mniej niż 2^13 (około 8,180 znaków). Wiele opcji jako typ parametrów przyjmuje wartości logiczne. Logiczna prawda może być specyfikowana przez "true", "yes" lub "on", natomiast fałsz wyrażany jest za pomocą parametrów "false", "no" lub "off". 18

Istnieją 2 typy grup konfiguracyjnych: auth{ i access{. Zadaniem tych grup jest odpowiednio autentykacja i autoryzacja użytkowników łączących się z serwerem. Każda z tych grup posiada ściśle określony zestaw opcji przy pomocy których są one konfigurowane. Grupa auth{ definiowana jest w następujący sposób: auth <name>{ hosts: <host-wildmat> auth: <auth-program> res: <res-program> default: <defuser> default-domain: <defdoamin>... etc. Zadaniem tej grupy jest kwalifikacja części połączeń do serwera jako określonych użytkowników identyfikowanych przez nazwę kwalifikowaną (<nazwa_użytkownika>@<domena>). Uzyskane w ten sposób identyfikatory służą w dalszej kolejności do autoryzacji dostępu do określonych grup na określonych zasadach. Autoryzacja dostępu konfigurowana jest za pomocą innej grupy konfiguracyjnej - grupy access{. Jest ona definiowana: access <nazwa> { users: <identity-wildmat> newsgroups: <group-wildmat>... etc. Każda grupa access{ "przechwytuje" połączenia od określonych użytkowników i określa zakres ich uprawnień. Uprawnienia takie mogą polegać na możliwości odczytu wiadomości z określonej grupy, wysyłania do niej, filtracji wysyłanych wiadomości, etc. # readers.conf # Kontrola dostępu i konfiguracja nnrpd Format wpisów w pliku: auth "<name>" { hosts: "<hostlist>" auth: "<authprog>" res: "<resprog>" default: "<identity>" default-domain: "<email-domain>" access "<name>" { users: "<userlist>" newsgroups: "<newsgroups>" read: "<read>" post: "<post>" access: "<perm>" auth{ - sekcja odpowiedzialna za autentykację użytkowników, definiująca grupę dostępu; każdy wpis w pliku powinien umożliwiać identyfikację użytkownika pod względem nazwy i domeny z której się łączy; posiada szereg opcji podanych w formacie: <opcja>: <parametry> opcje: hosts - lista hostów oddzielonych przecinkami, podanych podanych w formacie wildmat, oznaczających bądź to nazwy domen, bądź adresy IP, bądź też bloki adresów IP zapisane w formacie CIDR; specyfikują adresy, wywołania z których będą analizowane w tej sekcji res - jeżeli chcemy by nazwa [i hasło] użytkownika pobierane były przez zewnętrzny, specjalizowany program, w tej linijce musimy to wyspecyfikować; wyspecyfikowane programy muszą znajdować się fizycznie w katalogu <pathbin>/auth/resolv; w jednej sekcji auth{ może znajdować się więcej niż jedna opcja res:, 19