Grupy dyskusyjne USENET są niezwykle popularną usługą, funkcjonującą z powodzeniem od 20 lat. W chwili obecnej, dzienny ruch na wszystkich grupach wynosi kilkadziesiąt gigabajtów (ok. 50), z czego spory procent stanowi hierarchia alt.binaries.* (ok. 20 GB) przenoszona w całości tylko przez największe serwery. Pozostały procent światego ruchu na USENECIE stanowią grupy BIG8 (comp.*, humanities.*, misc.*, news.*, rec.*, sci.*, soc.*, talk.* -- ok. 10 GB) oraz reszta alt.*, a także regionalne grupy (ok. 10 GB), specyficzne dla konkretnych państw.

Struktura USENETu podzielona jest na serwery (tranzytowe i końcowe), które wymieniają artykuły między sobą poprzez protokół NNTP lub -- w chwili obecnej rzadziej spotykane -- batche UUCP. Istnieje również możliwość uruchomienia samodzielnego serwera, który przetrzymuje jedynie lokalne grupy. Programy klienckie porozumiewają się z serwerami z wykorzystaniem protokołu NNRP, czasami z wykorzystaniem bramki mail2news.

Uruchomienie serwera news dołączonego do struktury USENETu musi być poprzedzone oszacowaniem liczby klientów i feedów, a także określeniem objętości pobieranych hierarchii. W zależności od tego, należy przeznaczyć odpowiednio silną platformę sprzętową; zachodni ISP, których serwery przenoszą wszystkie światowe grupy, a dostęp do nich jest płatny opierają się najczęściej na maszynach klasy Sun E3500 i kilkuterabajtowych macierzach dyskowych. Autor administruje jednym serwerem USENET, przenoszącym tylko grupy pl.* przez trzy feedy, obsługującym do 10 jednoczesnych użytkowników i przechowującym artykuły przez 30 dni. Zadawalająca wydajność została uzyskana na komputerze pII 450 MHz, 256 MB RAM, z osobnym dyskiem SCSI na spool o wielkości 9 GB, działającym pod kontrolą systemu FreeBSD. W przypadku bardzo dużych serwerów może okazać się konieczne rozproszenie struktury na kilka serwerów, korzystających ze wspólnego spoola zamountowanego przez NFS.

Kolejnym ważnym krokiem jest decyzja, na jakim oprogramowaniu powininen działać serwer. Spora część produktów na tym rynku to oprogramowanie komercyjne (np. DNews, Typhoon/Cyclone); artykuł skupi się na opisie darmowego serwera INN pochodzącego z ISC, działąjącego pod kontrolą szerokiej gamy systemów Unixowych. Aktualna wersja to 2.3.2, wydana 3 maja 2001 r, dostępna pod adresem ftp://ftp.isc.org/isc/inn/inn-2.3.2.tar.gz oraz na lokalnych mirrorach. Istnieją również binarne pakiety dostosowane dla konkretnych dystrybucji systemu Linux. Dodatkowe informacje na temat administrowania serwerami USENET można znaleźć w książce H. Spencer'a oraz D. Lawrence'a "Managing Usenet", wydanej przez O'Reilly & Associates.

Kompilacja i instalacja oprogramowania powinna przebiec, podobnie jak w przypadku każdej innej aplikacji, tak więc ich opis zostanie tutaj pominięty. Dla początkujących najprostsze będzie zainstalowanie serwera z binarnego pakietu. Należy nadmienić, że zalecane jest wydzielenie osobnej maszyny do celów serwera USENET, a także, jeżeli istnieje taka potrzeba -- zadbanie o dużą liczbę wolnych i-węzłów na systemie plików, bowiem w przypadku metody przechowywania artykułów tradspool, każdy artykuł umieszczany jest w osobnym pliku. Katalog zawierający bazę artykułów powinien zostać umieszczony na osobnym systemie plików, odpowiednio zoptymalizowanym do tego celu. W przypadku FreeBSD warte polecenia będą opcje UFS_DIRHASH (ze zwiększonymi limitami pamięci) i SOFTUPDATES oraz mountowanie systemu plików z opcją noatime, ewentualnie async.

Kolejnym krokiem jest edycja plików konfiguracyjnych. Należy ona niewątpliwie do najbardziej skomplikowanej części instalacji. Jej złożoność uniemożliwia dokładne opisanie całej procedury w artykule, tak więc czytelnik powinien odwoływać się do przykładowej konfiguracji dostarczonej razem z dystrybucją INNa, a także do stron manuala.

Zacząć należy od ustawienia podstawowych parametrów w pliku /etc/news/inn.conf, takich jak domena, nazwa organizacji, nazwa serwera, czy wpis do nagłówka Path. Wytłumaczenie znaczenia wszystkich zmiennych znajduje się w manualu inn.conf(5), jednakże wartości domyślne większości są zadawalające w przypadku małych i średnich serwerów, w przypadku których wydajność nie jest najważniejsza.

Kolejnym plikiem, który powinien zostać poddany edycji jest storage.conf, w którym należy umieścić deklarację używanego formatu przechowywania wiadomości. Do wyboru mamy: tradspool (każdy artykuł w pojedynczym pliku, grupy w osobnych katalogach postaci pl/comp/os/freebsd), timehash (zbliżony do tradspool, katalogi z grupami podzielone na podkatalogi, aby uniknąć zbyt dużej liczby plików w pojedynczym katalogu), timecaf (zbliżony do timehash, artykuły są grupowane pod względem czasu nadejścia i przechowywane we wspólnych plikach) i cnfs (każda grupa w tzw. buforze cyklicznym, posiadającym stałą wielkość; nowe artykuły nadpisują stare). Najczęściej wybierany jest format cnfs ze względy na niewątpliwe zalety, takie jak: wydajność, brak wymagań co do ilości i-węzłów, brak przyrostu wielkości. Należy oczywiście wziąć pod uwagę jego wady, przede wszystkim brak możliwości kontrolowania czasu retencji artykułów. Grupy, w których minimalny czas retencji musi być zagwarantowany powinny być przechowywane w formacie timehash lub timecaf. Format pliku konfiguracyjnego pozwala na wyspecyfikowanie różnych rodzajów przechowywania w zależności od pewnych warunków, takich jak nazwa grupy czy wielkość artykułu.

W pliku readers.conf określamy klasy użytkowników (rozpoznawanych na podstawie IP lub domeny) powiązanych z prawami odczytu/zapisu konkretnych grup. Mechanizm ten został w tej formie wprowadzony w jednej z ostatnich wersji serwera, zastępując dość niewygodny i mało elastyczny nnrp.access. Należy dodać, że zgodnie z zasadami polskiego USENETu, udostępnianie możliwości wysyłania artykułow użytkownikom anonimowych dialup'ów TPSA jest niedozwolone.

Plik expire.ctl zawiera definicje czasu retencji dla poszczególnych grup, a także długość przechowywania historii odebranych wiadomości. Oczywiście zmiany czasu retencji ważne są tylko dla metod innych niż cnfs.

W przypadku, gdy zdecydowaliśmy się na format składowania cnfs, należy wyedytować plik cycbuff.conf i umieścić w nim definicje poszczególnych cyklicznych buforów (o nazwach takich, jak w storage.conf) oraz określić ich rozmiar. Bufory muszą zostać utworzone.

gdzie ścieżka i rozmiar są zgodne z zadeklarowanymi w cycbuff.conf. Po tych modyfikacjach można testowo uruchomić samodzielny serwer. W przypadku błędów w logach związanych z brakiem historii, należy utworzyć stosowne pliki zgodnie z przykładem podanym na stronie manuala makehistory(8). Do zarządzania serwerem służy komenda ctlinnd. Pomocna staje się ona przy wymuszaniu przeładowania konfiguracji, utworzenia/skasowania grupy, wstrzymania/wyłączenia serwera, a także wielu innych czynności. Dokładny opis poleceń ctlinnd znajduje się w manualu ctlinnd(8). Podczas pracy, cały system jest nadzorowany przez skrypt innwatch, który wykrywa brak miejsca na dysku, zbyt duże obciążenie i inne potencjalne kłopoty oraz zatrzymuje świadczenie usług w przypadku wystąpienia problemu. Wartości graniczne i testowane parametry można dostosować edytując plik innwatch.ctl.

W tej chwili pozostaje tylko zgłoszenie się do administartora jakiegoś serwera z prośbą o uzyskanie feed'a. Istnieją trzy alternatywne metody przesyłania artykułów: nntpsend/innxmit, innfeed oraz UUCP. Obecnie najpopularniejszy jest innfeed, który zestawia trwałe połączenie i przekazuje protokołem NNTP pojawiające się artykuły, na bieżąco i bez opóźnień. Przodkiem tej metody jest innfeed, który co określony czas opróżnia kolejkę oczekujących artykułów, łączy się ze zdalnym serwerem i wysyła paczkę wiadomości, także przy pomocy protokołu NNTP. Ostatnia metoda różni się znacznie od poprzednich, gdyż wykorzystuje system UUCP (ang. Unix-to-Unix copy) do transferowania skompresowanych batchy przez linie telefoniczne lub protokół TCP. Wymaga to wcześniejszej konfiguracji UUCP, jednakże jest bezkonkurencyjna na transkontynentalnych połączeniach o dużym opóźnieniu ze względu na kompresję i brak konieczności potwierdzania każdego artykułu. Autor używał przez długi czas feeda *.pl przez UUCP na linii modemowej 14400 bps.

Jako najprostsza zostanie opisana metoda z wykorzystaniem innfeed'a. Wystarczy jedynie wyedytować plik innfeed.conf i zadeklarować zdalny serwer. Pozostałe zmienne są opcjonalne, a ich wytłumaczenie znajduje się w manualu innfeed.conf(5). Kolejnym krokiem jest zezwolenie na przychodzące połączenia. Tak jak w poprzednim przypadku, dopisujemy jedynie nazwę serwera do pliku incoming.conf. Składnia obydwu plików jest bardzo prosta i nie wymaga wyjaśnień.

Jednym z ostatnich kroków jest edycja pliku newsfeeds, który definiuje "routing" artykułów między feedami. Dla naszej prostej konfiguracji wystarczy dodać wpis:

news.lublin.pl/lublin.pl:!junk, !control, pl.*, !local.*:Tm:innfeed!

W pierwszej linijce znajduje się nazwa serwera oraz nazwa dodawana do Path przez serwer; w drugiej -- spis grup zaliczonych i wykluczonych z feeda, a w trzeciej -- sposób transportu, w tym wypadku innfeed.

Teraz pozostaje już tylko ściągnąć plik active ze zdalnego serwera i przy pomocy prostego skryptu wykorzystującego ctlinnd, utworzyć grupy na lokalnym serwerze. Przykład:

awk '{ printf "/usr/bin/ctlinnd newgroup %s %s news\n", $1, $4; }' < active | sh

Dodawane nowe grupy będą tworzone automatycznie dzięki mechanizmowi tzw. control messages, które są podpisane stosownym kluczem PGP i rozprzestrzeniają się po całej hierarchii USENETu.

Do poprawnej pracy serwera wymagane jest regularne uruchamianie skryptu news.daily. W przypadku instalacji z pakietu, najprawdopodobniej został on już dodany do crona. Podczas działania skryptu, generowane są raporty, a także kasowane są przeterminowane artykuły (w przypadku tradspoola, timehasha czy timecafa).

Jak widać, konfiguracja pełnowartościowego serwera grup dyskusyjnych jest niezwykle złożona i nie można jej polecić początkującemu, czy nawet średniozaawansowanemu administratorowi. Dostępnych możliwości konfiguracji jest tak wiele, że nieodzowne jest wnikliwe przeczytanie dołączonej dokumentacji, ze szczególnym uwzględnieniem wszystkich stron manuala oraz FAQ. Pomocna również będzie lektura strony http://www.usenet.pl, która zawiera przystępnie napisane wprowadzenie do konfiguracji archaicznych wersji INNa. Powodzenia!

Wszystkie materiały na mojej stronie dostępne są na licencji Creative Commons Uznanie autorstwa-Użycie niekomercyjne-Na tych samych warunkach 2.5 Polska.