🚀 go-pugleaf

Posted-By: auto-faq 3.1.1.2
Archive-name: news-pl-faq/part2


                Newsy w Polsce (FAQ) - część 2. - serwery news
                                       
   Poniższy tekst, to druga część FAQ na temat newsów w Polsce,
   zawierająca uwagi na temat konfigurowania serwerów news. Wszelkie
   poprawki i uzupełnienia proszę kierować na adres
   tsurmacz@ict.pwr.wroc.pl Aktualną wersję całego FAQ można znaleźć
   zawsze we Wrocławiu przez WWW:
   http://www.usenet.pl/doc/news-pl-faq.htpl oraz w grupach news
   pl.news.admin i pl.answers.
     _________________________________________________________________
   
                            Spis treści części 2.:
                                       
   Konfiguracja serwera news 
          Jak podłączyć serwer news do sieci usenet?
          Jak skonfigurować serwer news (grupy pl.*)
          
        Plik active
                
        Plik newsfeeds
                Uwagi dotyczące serwerów mających feedy zagraniczne
                
        Plik moderators
                
        Plik distrib.pats
                
        Plik distributions
                
        Plik newsgroups
                
        Plik control.ctl
                
          Co robić z listami typu "checkgroups"?
          Jak skonfigurować mail2news i news2mail
          mail2news z użyciem procmaila
          Newsfeed za pomocą UUCP 
          Kompresja batchów za pomocą gzip 
          UUCP 'pośrednie' (czyli jak wykonać cyber!papaja!rnews)
          Inne możliwości przyspieszania transmisji 
     _________________________________________________________________
   
                          Podłączanie nowych serwerów
     _________________________________________________________________
   
   Jeśli chcesz do sieci Usenet news podłączyć własny serwer, po pierwsze
   należy zastanowić się, czy skórka warta jest wyprawki. Mały serwer z
   kilkunastoma lub nawet kilkuset grupami może być niewart instalacji ze
   względu na czas spędzany następnie na jego konfigurowanie. Duży serwer
   natomiast wymaga wręcz ogromnego pasma danych, jeśli mają na nim byc
   założone wszystkie grupy. W styczniu 2003 wielkość ,,feedu''
   obejmującego same grupy pl.* to około 20-40 MB/dziennie, wszystkie
   grupy hierarchii BIG8 - około 1-2 GB/dziennie, wszystkie grupy
   włączając w to alt.* - około 120-200 GB dziennie. I niestety z każdym
   rokiem te wielkości się mniej więcej podwajają.
   
   Musisz też u siebie zainstalować serwer news, czyli program innd,
   działający w środowisku UNIX. Alternatywnym programem serwera news
   jest Diablo w systemie UNIX, jednak nie ma on sensu dla niewielkich
   instalacji newsowych. "Serwery news" oparte o oprogramowanie
   Microsoftu nie są i nie będą podłączane do sieci Usenet i to
   bynajmniej nie z powodu niechęci reszty administratorów do tej firmy,
   lecz z powodu masy problemów, jakie ten "serwer" powoduje przez to, że
   nie bardzo przejmuje się standardami dotyczącymi systemu news. Jeśli
   nadal chcesz uruchomić u siebie serwer news, musisz uzgodnić to z
   administratorem innego serwera, który "da ci feed", czyli skonfiguruje
   swój serwer tak, by przesyłał do twojego wybrane grupy oraz akceptował
   artykuły wysyłane z twojego serwera. Informacje jak skonfigurować
   różne pliki serwera znajdziesz w następnym punkcie, natomiast przy
   uzyskiwaniu feedu od innego serwera musisz przekazać jego
   administratorowi kilka kluczowych informacji koniecznych do właściwego
   skonfigurowania łącza po drugiej stronie. Są to m.in:
   
     * Nazwa i adres IP twojego serwera news. Jeśli ma kilka adresów IP -
       wszystkie z nich. Jeśli wysyłał będzie artykuły z innego adresu
       niż adres, na jaki ten drugi serwer ma się z nim łączyć, także to
       zaznacz.
     * Nazwa, jaką twój serwer wpisuje w polu Path:
     * Dane kontaktowe - adres email, imię i nazwisko osoby
       odpowiedzialnej za sewrer news, w miarę możliwości także kontakt
       telefoniczny w razie jakichś nagłych wypadków.
     * Listę grup news, jakie chcesdz otrzymywać w formacie pliku
       newsfeeds. Wysyłając ją w tym właśnie formacie zaoszczędzisz pracy
       osobie po drugiej stronie łącza, a być może nawet jest to jedyny
       sposób, by twoja prośba w ogóle została rozpatrzona.
     * Jeśli już masz jakieś feedy z innych serwerów -- informację o
       nich.
       
   W odpowiedzi powinieneś dostać list zawierający podobne dane dotyczące
   serwera, z którego będziesz otrzymywał i wysyłał artykuły.
   Najważniejsze z nich są:
     * Adres/nazwa do wysyłania news -- wpisz go do nntpsend.ctl lub
       innfeed.conf.
     * Adres/nazwa, z którego będziesz otrzymywał artykuły. Wpisz ją do
       hosts.nntp lub incoming.conf.
     * Zawartość pola Path: twojego sąsiada -- wpisz ją w odpowiednim
       miejscu pliku newsfeeds. Jeśli masz kilku sąsiadów, wpisz tę nazwę
       do konfiguracji dotyczącej ich wszystkich, aby nie przesyłać
       artykułów między nimi.
       
   Przeładuj pliki konfiguracyjne odpowiednią komendą ctlinnd reload i
   przetestuj czy połączenie działa poprawnie (oraz poproś administratora
   drugiego serwera, by przetestował, czy może się połączyć z tobą).
   
   Bardzo ważnym aspektem uruchomienia usługi serwera news są oprócz
   aspektów technicznych zasady, na jakich podłączane są nowe serwery.
   Najważniejsze z tych zasad wymienione są poniżej:
     * W sieci Usenet-PL serwery dzielą się na tzw. huby i liście. Hub to
       serwer, który ma łącze z wieloma innymi serwerami i oprócz
       udostępnianai artykułów swoim użytkownikom, służy także do
       transferu danych pomiędzy serwerami, z którymi ma łączność.
       Serwerami takimi są przeważnie duże serwery news w sieciach
       akademickich, a także news.tpi.pl, news.onet.pl i kilka innych.
       Wszystkie pozostałe (w tym także twój) jest liściem -- tzn.
       powinien zajmować się wyłącznie otrzymywaniem artykułów,
       obsługiwaniem swoich użytkowników oraz wysyłaniem listów
       pochodzących od tych użytkowników do swojego sąsiada (lub
       sąsiadów).
       Jeśli masz tylko jednego sąsiada, sprawa jest prosta, jeśli jednak
       skonfigurowałeś (lub masz zamiar w przyszłości) uzyskać także inne
       łącze/feed, to po pierwsze musi to być feed od innego huba (a nie
       liścia), po drugie - w pliku newsfeeds musisz zadbać o to, by nie
       przesyłać artykułów pomiędzy tymi hubami. Zajrzyj do przykładów
       opisujących plik newsfeeds, a także informacje dotyczące list
       wykluczeniowych w przypadku feedów zagranicznych, bo to jest
       praktycznie ta sama sytuacja.
       W przypadku wykrycia liści, które liśćmi nie są, bo przesyłają
       artykuły także innym serwerom, są one odcinane do czasu
       wyjaśnienia sytuacji i naprawienia problemu.
     * Autoryzacja dostępu Twój serwer news nie powinien dawać dostępu do
       news "wszystkim", lecz tylko wybranej grupie użytkowników, którą
       można zidentyfikować w razie problemów. Może to być dostęp na
       hasło wymagający wsześniejszej rejestracji (i pozwalającej na
       uniemożliwienie ponownej rejestracji osobom uporczywie
       przeszkadzającym innym przez wysyłanie spamów lub inne nadużycia)
       albo dostęp dla wąskiej klasy adresów IP ograniczonej do własnej
       firmy/sieci osiedlowej itp. Także w tym drugim przypadku powinna
       być możliwość identyfikacji pojedynczego użytkownika -- jeśli w
       sieci lokalnej używasz dynamicznych adresów nadawanych np. przez
       DHCP, powinieneś także zadbać o archiwizowanie logów serwera
       pozwalających na identyfikację komputera/użytkownika, który łączył
       się z twoim serwerem news. Dane takie powinny umożliwiać
       znalezienie winnych w przypadku nadużyć co najmniej 1-2 tygodnie
       wstecz.
     * Bramki www-news Obecnie nie jest dozwolone tworzenie żadnych
       bramek www-news pozwalających na wysyłanie artykułów do systemu
       usenet news. Z reguły bramki takie nie umożliwiają żadnej
       autoryzacji dostępu, albo mają ją zaimplementowaną w sposób
       trywialny do obejścia, stają się więc szybko źródłem spamów i
       innych nadużyć. Są też źródłem mnóstwa innych problemów, takich
       jak niepoprawnie formatowane nagłówki, brak w nagłówkach
       informacji pozwalających na identyfikację nadawcy (jego adresu IP,
       nazwy konta, itp.), czy wręcz pętle wysyłające do newsów artykuły
       pochodzące z newsów, zwrotów o niemożności dostarczenia jakichś
       listów, czy całej masy innego śmiecia. Aby uruchomić taką bramkę,
       wymagane byłoby żmudne przetestowanie, czy spełnia ona wszystkie
       wymagania związane ze współpracą z serwerami news, a nawet i wtedy
       podłączenie newsów do serwera WWW powoduje z reguły zalew grup
       dyskusyjnych nowymi "newbie", nie zdającymi sobie sprawy z tego,
       czym są grupy dyskusyjne, jakie w nich obowiązują zasady i że
       każda grupa ma swoją ściśle określoną tematykę, a nie jest kolejną
       ikonką na pulpicie, służącą za miejsce do gadania o wszystkim.
     * Edukacja użytkowników Użytkownicy twojego serwera news powinni
       otrzymywać informacje na temat systemu Usenet news - jak z niego
       korzystać, jakie w nim obowiązują zasady, co jest dozwolone, a co
       zabronione. Możesz w tym celu odsyłać ich do dokumentacji
       dostępnej pod adresem http://www.usenet.pl/doc/ (w szczególności
       do informacji o FAQ-bocie i regułach dotyczących wysyłania
       artykułów w grupach pl.* oraz do artykułów FAQ możliwych do
       znalezienia w pl.answers, a także do Netykiety wysyłanej
       periodycznie do pl.answers i pl.news.nowe-grupy. Zajrzyj także na
       http://faq-bot.usenet.pl/ -- jest tam wiele informacji dotyczących
       zasad obowiązujących w poszczególnych grupach.
     _________________________________________________________________
   
                            Konfigurowanie serwerów
     _________________________________________________________________
   
   Ogólna uwaga dotycząca wszystkich konfiguracji -- BARDZO WAŻNE!!!
   
   Serwery news nie mogą pozwalać na pisanie do grup hierarchii pl.*
   każdemu bez jakiejkolwiek autoryzacji. Jeśli serwer ma być z założenia
   otwarty dla wszystkich, to musi zawierać system kont i
   uwierzytelniania. Celem systemu musi być uniknięcie sytuacji
   niekontrolowanego anonimowego dostępu do usenetu przez ten serwer,
   gdyż takie sytuacje prędzej czy później prowadzą do nadużyć
   odbijających się echem po całym usenecie.
   
   Dotyczy to nie tylko samych serwerów news, ale i wszelkiego rodzaju
   bramek z innych usług, np. email, www, wap, itp.
   
                   Jak skonfigurować serwer news (w Polsce)
                                       
   To zależy od samego serwera... i najlepiej wyjaśnione jest w
   odpowiednich README lub FAQ towarzyszących serwerowi. Poniżej jednak
   parę uwag specyficznych dla właściwego skonfigurowania serwera w
   Polsce. Z góry zastrzegam, że dotyczy to praktycznie wyłącznie serwera
   INN, gdyż tylko takie miałem okazję konfigurować i na tym się znam ;-)
   
   Poza tym większość zainstalowanych serwerów (i w Polsce i na świecie)
   to właśnie INN. Instalacja pozostałych (takich jak DNEWS na przykład)
   wymaga zdecydowanie więcej samozaparcia, a efektem bardzo często jest
   serwer, którego i tak nie można podłączyć do sieci Usenet News z
   powodu wad w implementacji protokołu NNTP i spustoszenia. jakie to
   sieje w sieci (np. redystrybucja starych artykułów z nowymi
   Message-Id:) Przez $inn określał będę katalog, w którym znajduja się
   pliki serwera, a więc np. standardowym miejscem na 'active' jest
   $inn/active lub $inn/lib/active, serwer news to $inn/bin/innd itp...
   
Plik active ($inn/active)

   Plik ten zawiera spis wszystkich grup, które serwer otrzymuje. Jeśli
   uruchamiamy nowy serwer, najlepiej jest ściągnąć aktualną wersję
   takiego pliku z innego serwera news (który będzie nas w newsy zasilał)
   za pomocą protokołu nntp, lub z ftp.uu.net poprzez ftp. Pierwsze
   wyjście polega na wykonaniu '$inn/bin/getlist -h jakiś.serwer.news.pl
   active', drugie - użyciu 'anonymous ftp' ale uwaga... ftp.uu.net, mimo
   że od jakiegoś czasu posiada także grupy pl.*, to nie wszystkie
   niestety zostały tam poprawnie założone. Dlatego lepiej skorzystać z
   fragmentów pliku active, dotyczącego grup pl, a znajdującego się pod
   adresem http://www.usenet.pl/doc/pl.active. Plik ten jest codziennie
   automatycznie uaktualniany na podstawie pliku active serwera
   news.ict.pwr.wroc.pl.
   
   Po otrzymaniu takiego pliku 'active', najlepiej wyzerować w nim
   numerki oznaczające numery artykułów prostą instrukcją:

        mv active active.old
        awk '{printf ("%s 0000000000 0000000001 %s\n", $1, $4)}' < active.old >
 active

   nie zapominając o tym, że jeśli serwer news już działa, to MUSI zostać
   wczesniej zatrzymany np. przez '$inn/bin/ctlinnd pause xx', a ponowne
   uruchomienie powinno nastąpić przez:

        ctlinnd reload active ''
        ctlinnd go ''

   Jeśli dopisać trzeba pojedyncze nowe grupy w już działajacym serwerze,
   należy do tego użyć 'ctlinnd newgroup pl.nazwa.grupy y', bez
   uprzedniego zatrzymywania serwera. Jeśli grupa jest moderowana,
   zamiast 'y' powinno oczywiście pojawić się 'm'.
   
Plik newsfeeds ($inn/newsfeeds lub $inn/site/newsfeeds)

   Zależy od tego, kto zasila nas w newsy i komu newsy są dalej posyłane.
   Jest on naprawdę dobrze udokumentowany w INND FAQ oraz na stronie
   manuala, wystarczy więc może jedynie 2 małe przykłady...
   
   'feed' dla komputera o adresie 'news.host.pl' dopisującego w polu
   'Path:' nazwę 'news.host.somewhere.in.pl' powinien w najprostszym
   przypadku wyglądać tak:

        xxx/news.host.somewhere.in.pl\
                :*/!local:Wnm:

   gdzie xxx jest dowolnym (w miarę krótkim, bo pojawia się wielokrotnie
   w logach) akronimem reprezentującym dany host, wystepującym również w
   pliku 'nntpsend.ctl':

        xxx:news.host.pl:::-T1720 -t300

   gdzie nazwa 'xxx' zostaje związana z adresem internetowym
   'news.host.pl'. Warto przy okazji zwrocić uwage na parametr -T1720
   (lub podobny) zamiast 'standardowego' -T1800. Parametr -Tn oznacza, że
   jedna sesja nntpsend nie może trwać dłużej niż n sekund. W przypadku
   n=1800, oznaczałoby to dokładnie 30 minut. Standardowo nntpsend jest
   startowany z crontab-a co 10 minut, a wygląda to mniej więcej tak:

        0,10,20,30,40,50 * * * * /usr/lib/news/nntpsend

   Gdy pojawia się sytuacja, że newsów jest na tyle dużo, że nntpsend
   jest w stanie pełne 30 minut wykorzystać, to kończenie tuż po tym, jak
   crontab wystartował nowego nntpsend, który się skończył, stwierdziwszy
   że poprzedni jeszcze działa, jest marnotrawieniem kolejnych 10 minut,
   czyli 25% przepustowości łącza. Dlatego czas dla -T powinien być
   wielokrotnością 10 minut, pomniejszoną o 1-2 minuty, by dać programowi
   nntpsend czas na 'posprzątanie' w momencie kończenia działania. Drugą
   sprawą pozwalającą przyspieszyć docieranie news z jednego końca Polski
   w drugi jest to, by na sąsiadujących serwerach news czasy wysyłania
   batchów były nieco poprzesuwane, np. jeśli 'mapka' serwerów wyglada
   tak:

        bilbo   <--->   okapi   <--->   sun1000

   to jeśli, przykładowo, na bilbo nntpsend startuje o pełnej godzinie i
   dalej co 10 minut, to na okapi powinno to być np. 5 minut po pełnej
   godzinie i dalej co 10 minut (czyli 5,15,25,...), a na sun1000 znowu o
   pełnej godzinie. Natomiast jeśli jeszcze istnieje dodatkowe połączenie
   bilbo <---> sun1000, to jeszcze lepiej jest, gdy bilbo ma 0,10,...,
   okapi np. 3,13,23,33,... a sun1000 6,16,26,...
   
   Drugi krótki i z życia wzięty przykład (wg mapki z pierwszej części
   FAQ). newsfeeds na okapi: uw dostaje wszystkie lokalne artykuły (tzn.
   takie, które nie były w Warszawie ani w USA) oraz comp.security* które
   nadchodzą z USA lub lokalnie:

        cocos!all/news.nask.pl,uw.edu.pl,plonk.apk.net\
            :*,!pwr.*,/!local,!pwr,!wroc\
            :Tm:cocos

        cocos!sec/news.nask.pl,uw.edu.pl\
            :!*,comp.security*,alt.security*/!local,!pwr,!wroc\
            :Tm:cocos

        cocos:!*:Tf,Wnm:

   Pierwsze 2 linijki to 'wejście lejka' o wspólnym ujściu nazwanym
   'cocos', przy czym 'cocos' nie ma tutaj NIC wspólnego z nazwą
   komputera, na który zostanie to wysłane. Pierwsza linijka odnosi się
   do wszystkich artykułów, które nie nadeszły z Warszawy ani z USA
   (przez serwer plonk.apk.net), druga - do wszystkich artykułów z grup
   'security', które nie nadeszły z Warszawy. WPisanie kilku nazw
   (pochodzących z Path: tych serwerów) zapobiega przesyłaniu artykułów
   pomiędzy nimi. Ostatnia linia to 'ujście lejka' prowadzące do pliku
   'cocos' w katalogu /var/news/out.going (lub odpowiednio innym), gdzie
   zapisywane są odsyłacze do artykułów, wykorzystywane co 10 minut przez
   innxmit. Symboliczna nazwa 'cocos' jest tłumaczona na rzeczywisty
   adres komputera (którym jest 'news.uw.edu.pl') w pliku 'nntpsend.ctl':

        cocos:news.uw.edu.pl::-T1720 -t300

  Uwagi dotyczące serwerów mających feedy zagraniczne
  
   Newsy do Polski spływają kilkoma drogami i poprzez sieci różnych
   operatorów (TPSA, NASK, POL-34), nie grozi nam więc sytuacja, że
   wskutek awarii pojedynczego serwera news (np. chwilowego zapchania
   dysku na którymś z serwerów news) zostaniemy całkiem odcięci od
   dopływu nowych newsów ze świata lub zaczniemy otrzymywać je ze
   znacznym opóźnieniem. Z drugiej strony jednak bez odpowiedniej
   konfiguracji może to prowadzić do niepożądanego "tranzytu" newsów np.
   z USA do USA przez kilka serwerów w Polsce.
   
   Można tego uniknąć odpowiednio definiując reguły wykluczania w pliku
   newsfeeds (po znaku "/" w nazwie feedu). Do tego potrzebna jest jednak
   znajomość wszystkich połączeń Polski ze światem i tego, co zagraniczne
   serwery news wpisują w polu Path:
   
   news.uoregon.edu,hammer.uoregon.edu,arclight.uoregon.edu,fu-berlin.de
          
   news.nacamar.de,newsfeed.nacamar.de,news.apfel.de,news.maxwell.syr.edu
          Serwery w USA i Niemczech, wymieniające BIG 8, pl.* i inne
          grupy z serwerem w ICM.
          
   news.apk.net (aka plonk.apk.net, ale to pierwsze wystarczy)
          Serwer w USA (Cleveland, Ohio), wymieniające BIG 8 i pl.* z
          serwerem news.uw.edu.pl, a także comp, news i pl z serwerem
          news.ict.pwr.wroc.pl (gzipowane batche UUCP).
          
   newscore.univie.ac.at
          Serwery w Austrii, znane poprzednio (przed 12.01.1998) jako
          01-newsfeed.univie.ac.at i 02-newsfeed.univie.ac.at, a jeszcze
          wcześniej jako newsfeed.ACO.net, wymieniające BIG 8, de.*, pl.*
          i inne grupy z serwerem NASK
          
   newsfeed.sunet.se
          Serwer w Szwecji wymieniający BIG 8, de.*, pl.* i inne grupy z
          serwerem UW. Wcześniej znany jako sunic
          
   news.icmp.lviv.ua
          Serwer na Ukrainie. Połączenie przez NASK. Sam także otrzymuje
          newsy innymi drogami (z USA i Europy), dlatego dobrze jest
          także umieścić go na liście.
          
   news.cistron.nl
          Serwer w Holandii, wymieniający wyłącznie grupy linux.* z
          serwerem news.uw.edu.pl.
          
   news.miracle.net
          
   nntp.uio.no
          Serwery news w USA (Connecticut) i Norwegii (Oslo),
          wymieniające z serwerem news.ict.pwr.wroc.pl niewielkie feedy
          zawierające hierarchie pl.* i linux.*.
          
   Powyższa lista nie jest pełna, jako że po raz pierwszy powstała w roku
   1995, a feedy potrafią się zmieniać i co 2-3 tygodnie. W miarę
   aktualna, pełna lista "excludes" powinna wyglądać następująco:

jakiś-feed/news.apk.net,newsfeed.sunet.se,\
        news.icmp.lviv.ua,news.cistron.nl,news.micro-net.net,\
        news.uoregon.edu,hammer.uoregon.edu,arclight.uoregon.edu,\
        newsfeed.nacamar.de,news.nacamar.de,news.apfel.de,\
        news-spur1.maxwell.syr.edu,\
        www.nntp.primenet.com,nntp.primenet.com,\
        fu-berlin.de,fci-se,newscore.univie.ac.at\
        : ......

Plik moderators

   Standardowy plik przychodzący z dystrybucją INND, uzupełniony na
   początku o linię: nowość!

                pl.*:%s@usenet.pl

   co powoduje wysyłanie artykułów w moderowanych grupach pl.* na adres
   typu nazwa-grupy-z-kropkami-zamienionymi-na-kreski@usenet.pl. Linia
   taka znajduje się już w standardowej (tzn. rozprowadzanej wraz ze
   źródłami serwera) dystrybucji INND począwszy od wersji 1.5.
   
   usenet.pl jest adresem klasy MX wskazującym na hosty utrzymujące pełną
   listę wszystkich 'moderatorów' grup pl (obecnie są to
   galaxy.uci.agh.edu.pl i okapi.ict.pwr.wroc.pl). Domena ta powstała na
   początku sierpnia 1995, zastępując stosowaną uprzednio domenę
   moderators.fuw.edu.pl.
   
Plik distrib.pats

   Plik ten należy uzupełnić o lokalne dystrybucje, tam gdzie one
   występują, np.:

        10:pwr.*:pwr                 - We Wrocławiu
        10:umk.*:umk                 - W Toruniu

   a także ew. niektóre grupy, które mają inną dystrybucję, niż wynika to
   z ich nazwy, np. we Wrocławiu:

        30:pl.listserv.email-d:pwr

   gdyż pl.listserv.email-d jest lokalną grupą wrocławską mimo nazwy
   'pl.' i artykuły posłane do tej grupy otrzymują standardowo
   dystrybucję 'pwr'. Specjalne definiowanie domyślnej dystrybucji pl dla
   grup pl.* jest błędem, gdyż powinno to być 'world' (a w ogóle, to
   najlepiej zamiast 'world' pozostawić wtedy "pustą" dystrybucję,
   oznaczającą cały świat) - a dystrybucja pl ma rzeczywiście oznaczać
   rozsyłanie artykułów wyłącznie do serwerów w Polsce.
   
Plik distributions

   Zawiera opisy poszczególnych dystrybucji. To, co dla Polski
   najważniejsze, poniżej:

        pl        Polska
        pl-news   Polska, wyłącznie news, bez list dyskusyjnych
        krakow    Kraków
        cyfronet  Kraków
        torun     Toruń
        warszawa  Warszawa
        umk       UMK w Toruniu
        pwr       Politechnika Wrocławska
        wroc      Wrocław
        world     Cały świat
        inet      Internet
        mimuw     Wydz. Matematyki Informatyki i Mech. Uniw. Warszawskiego
        local     lokalny serwer news

Plik newsgroups

   Plik z jednolinijkowymi opisami poszczególnych grup. Opis grup pl.*
   wysyłany jest regularnie w trzeciej części tego FAQ w grupach
   pl.news.admin i pl.answers, a regularnie raz na dwa miesiące także w
   postaci tzw. "checkgroups message". Dostępny jest także poprzez WWW
   pod adresem: http://www.usenet.pl/doc/pl.newsgroups. Lista grup, wraz
   z aktualnym plikiem active, dostępna jest w 3. części tego FAQ.
   
   Plików tego można użyć do sprawdzenia, czy lista grup na serwerze jest
   aktualna w następujący sposób:

    lynx -source http://www.usenet.pl/doc/pl.newsgroups | \
    $inn/control/checkgroups

   lub:
    lynx -source http://www.usenet.pl/doc/news-pl-faq.3 | \
    sed -e '1,/^=== /d' -e '/^--- /d' | \
    $inn/control/checkgroups

Plik control.ctl

   Plik ułatwiający 'centralne' i zautomatyzowane tworzenie nowych grup.
   Polega ono na tym, że w pewnej hierarchii news (np. w grupach pl.*)
   pewna osoba zostaje uznana za autorytatywną, jeśli chodzi o tworzenie
   nowych grup i kasowanie starych, czego dokonuje przez wysłanie
   odpwiednio sformatowanych artykułów news, zawierających pewne magiczne
   zaklęcia. Aby zaklęcia te były zrozumiałe dla serwerów news, w ich
   pliku control.ctl muszą się oczywiście pojawić odpowiednie linie
   konfiguracji. Obecnie, aby zabezpieczyć się przed "podróbkami" listów,
   w wielu hierarchiach news stosowana jest metoda podpisywania tych
   specjalnych artykułów kluczem PGP. Tak jest w hierarchii "BIG 8"
   (comp, news, rec, talk, itd.), jak i w niektórych hierarchiach
   narodowych (de, fr, uk), a od października 1996, także w hierarchii
   pl.
   
   Aby był sprawdzany podpis PGP, potrzebne jest oczywiście odpowiednie
   oprogramowanie na serwerze - sam program pgp oraz skrypty 'pgpverify'
   i poprawiony 'parsecontrol' serwera news. Znajdują się one w
   dytrybucji INN począwszy od wersji 1.5, a dla poprzednich wersji (a
   także serwerów CNEWS) można ściągnąć z sieci odpowiednie poprawki.
   Więcej informacji na ten temat można przeczytać pod adresem
   ftp://ftp.pwr.wroc.pl/pub/networking/news/misc/pgpcontrol/ (mirror
   strony z ftp.uu.net). Tam można także znaleźć klucz PGP używany w
   hierarchii pl.
   
   Jeśli jednak na serwerze nie jest dokonywana weryfikacja PGP, musi
   wówczas wystarczyć metoda "tradycyjna", jako że artykuły specjalne
   podpisane przez PGP są też poprawnie rozpoznawane, gdy PGP nie ma na
   serwerze (ale oczywiście nie da się wtedy zweryfikować ich
   autentyczności).
   
   Trzeba pamiętać, że OSTATNI pasujący opis zostaje użyty, tak więc w
   okolicach końca pliku należy dopisać dla grup pl.*:

        ##  PL newsgroups  - bez weryfikacji kluczem PGP
        newgroup:michalj@*fuw.edu.pl:pl.*:doit=newgroup
        rmgroup:michalj@*fuw.edu.pl:pl.*:doit=rmgroup
        newgroup:newgroup@usenet.pl:pl.*:doit=newgroup
        rmgroup:newgroup@usenet.pl:pl.*:doit=rmgroup

   Jeżeli natomiast serwer został skonfigurowany do weryfikacji artykułów
   specjalnych przez PGP, to zamiast powyższych linii należy wpisać linie
   następujące:
   
    ##  PL newsgroups - weryfikacja kluczem PGP
    newgroup:newgroup@usenet.pl|michalj@*fuw.edu.pl:pl.*:verify-pl.announce.new
groups
    rmgroup:newgroup@usenet.pl|michalj@*fuw.edu.pl:pl.*:verify-pl.announce.newg
roups
    checkgroups:newgroup@usenet.pl|michalj@*fuw.edu.pl:pl.*:verify-pl.announce.
newgroups

   UWAGA! - W obu przypadkach między '*' a 'fuw' nie ma kropki!
   
   Poza tym dobrze jest przy okazji sprawdzić sposób reakcji serwera na
   'sendsys'. Poniżej znajduje się 'preferowany' sposób dla standardowych
   zapytań - automatyczna odpowiedź, jeśli podany został argument (czyli
   jeśli np. komputer okapi otrzyma 'cmsg sendsys icm' - to odeśle
   fragment pliku newsfeeds dotyczący icm), oraz brak odpowiedzi, jeśli
   argumentu nie ma (by uniknąć potencjalnych bomb-maili)

        ##  SENDSYS
        sendsys:*@uunet.uu.net:*:doit=miscctl
        sendsys:*:*:doifarg

   Na serwerach w Polsce dobrze jest także dopisać następujące linie:
        sendsys:*@adm.usenet.pl:*:doit=miscctl
        version:*@adm.usenet.pl:*:doit=miscctl

   spowodują one wysłanie pliku newsfeeds lub listu zawierającego w
   treści numer wersji serwera, jeżeli odpowiednio sformatowany artykuł
   specjalny nadejdzie z adresu znajdującego się w domenie adm.usenet.pl.
   Pozwala to na uaktualnianie informacji o serwerach news w Polsce i ich
   wzajemnych połączeniach (np. w celu uaktualnienia mapki zamieszczonej
   w części pierwszej tego FAQ), bez konieczności ciągłego zawracania
   głowy poszczególnym administratorom serwerów news (bo serwer sam
   wysyła odpowiedź, a administratora jedynie informuje w krótkim liście,
   że odpowiedź została wysłana).
     _________________________________________________________________
   
                    Co robić z listami typu "checkgroups"?
                                       
   Od czasu do czasu wysyłany jest tzw. "checkgroups message" dla grup
   pl.*, tzn. specjalny artykuł naws zawierający listę wszystkich
   aktywnych grup. Artykuł taki wyróżniony jest odpowiednią linią
   "Control:", dzięki czemu każdy serwer news, który taki artykuł
   otrzyma, zależnie od konfiguracji - przesyła go swojemu
   administratorowi pocztą elektroniczną, lub automatycznie go wykonuje i
   jeśli wykryje jakieś rozbieżności pomiędzy przesłaną listą grup, a
   lokalnie istniejącymi grupami w tej hierarchii, to informuje o tym
   administratora. W pierwszym z tych dwóch przypadków, w liście tym
   serwer dołącza na początku komentarz mówiący w jaki sposób należy z
   tym artykułem postąpić. Jest to zwykle polecenie postaci
   $inn/control/docheckgroups < PLIK.
   
   Nie należy się obawiać, że uruchomienie docheckgroups cokolwiek zmieni
   lub coś "zepsuje". Program ten porównuje jedynie listę grup w
   dostarczonym mu na wejściu pliku z listą grup znajdującą się w plikach
   active i newsgroups. W przypadku niezgodności informacje o tym
   drukowane są na standardowym wyjściu w formacie skryptu sh. Tak więc
   można program docheckgroups uruchomić raz dla sprawdzenia, czy
   wszystko jest ok, a następnie w przypadku wykrycia niezgodności i
   zaakceptowania zmian wykonać program ponownie, jego wynik skierowując
   do programu sh (albo do pliku, a następnie do sh):
   
        $inn/control/docheckgroups < PLIK | sh -

   Artykuł "checkgroups" wysyłany jest 2 miesiące (1 dnia miesiąca w
   miesiące nieparzyste) z adresu newgroup@usenet.pl. Jeśli artykuł taki
   potrzebny jest "od zaraz" (np. przy konfigurowaniu nowego serwera
   news), można sobie poradzić inaczej:
   
     * Spod adresu http://www.usenet.pl/doc/pl.newsgroups ściągnąć
       aktualną listę grup pl.* w formacie pliku newsgroups.
     * Uruchomić program docheckgroups podając mu plik pl.newsgroups na
       wejście.
     * To, co z niego wyjdzie zapamiętać w pliku i uruchomić jako skrypt.
       
   Oprócz tego, co jakiś czas (ale niezbyt często) wysyłane są na nowo
   specjalne artykuły "tworzące" grupy, które już dawno istnieją. Np.
   pl.test, pl.news.admin i inne. Jeśli 'zakładana' grupa już istnieje na
   serwerze, to serwer ignoruje taki artykuł specjalny, jeśli nie
   istnieje - tworzy grupę. Nie wymaga to żadnej dodatkowej konfiguracji
   ponad tę, opisaną przy okazji opisu zawartości pliku "control.ctl".
     _________________________________________________________________
   
                    Jak skonfigurować mail2news i news2mail
                                       
   mail2news i news2mail to dwa programy odpowiedzialne za spinanie ze
   sobą (jak sama nazwa wskazuje) newsów i maila, tzn. list dyskusyjnych.
   Wydawać by się mogło, że w zasadzie są one niepotrzebne, no bo cóż...
   - wystarczyłoby pewnie z jednej strony skonfigurować serwer news tak,
   by artykuły przychodzące do pewnej grupy były przekazywane
   bezpośrednio jednemu z programów typu mail, mailx, mh lub sendmail, w
   drugą stronę natomiast - utworzyć odpowiedni "alias" pocztowy typu np.

        "|/usr/lib/news/sendnews"

   gdzie sendnews jest prostym skryptem dopisującym na początku nazwę
   grupy i posyłającym dalej całość do programu 'inews', który przekaże
   artykuł serwerowi.
   
   Tak prosto jednak nie da się tego zrobić. Problem polega na tym, ze
   każdy artykuł wysłany na listę dyskusyjną trafiłby do news, po czym z
   news zostałby odesłany ponownie na listę dyskusyjną, tak więc na
   liście każdy artykuł pojawiałby się dwukrotnie. Jeśli na dodatek
   listserwer nie przekazuje (tzn. gubi) 'Message-ID', może się okazać,
   że artykuł ponownie wraca do news, skąd dalej zostaje zakolejkowany do
   listserwera i zaczyna się robić (nie)wesoło... Jeśli 'Message-ID' jest
   przez listserwer przekazywany jak należy, sytuacja taka nie będzie
   miala miejsca, gdyż artykuł posłany ponownie do news (z tym samym
   Message-ID) zostanie przez serwer news odrzucony jako duplikat (i
   zwykle wygeneruje list do Postmastera), może to jednak powodować
   zamieszanie na liście dyskusyjnej.
   
   Ważne jest więc po pierwsze zagwarantowanie, by artykuł trafiający z
   listserwera do news nie zostawał wysłany z powrotem na listę, a także
   by listserwer nie gubił ani nie modyfikował Message-ID:, a także by
   generować Message-ID: w momencie przekazywania listu z e-maila do
   news, jeśli list go nie zawiera. W miarę możliwości należy także
   ustawić na listserwerze opcje 'NOACK', oznaczającą że listy wysłane z
   adresu serwera news nie są do niego ponownie odsyłane.
   
   Do tego właśnie służą oba wspomniane programy. mail2news dokonuje
   przefiltrowania nagłówka maila, usuwając niepotrzebne lub niezgodne z
   RFC822 pola (np. 'Received:' jest w newsach w ogóle bez znaczenia).
   Jeżeli list nie posiada 'Message-ID:', to jest on generowany, ponadto
   tworzone jest pole 'Path:' z wpisanym odpowiednim tekstem, np. 'Path:
   gateway', dzięki czemu w serwerze news możliwe jest wysyłanie na listę
   dyskusyjną wyłącznie artykułów, które serwer news otrzymał od innych
   serwerow, a nie od mail2news (a więc nie majacych 'gateway' w polu
   'Path:'). Opcjonalnie, mail2news potrafi także odfiltrować często
   posyłane na adres listy (zamiast listserwera) artykuły typu 'unsub
   nazwa-listy'.
   
   W drugą stronę - news2mail usuwa z nagłówka pola nieistniejące w
   e-mailu (typu 'Path:', 'Supersedes:', itd.), ignoruje wszystkie listy
   typu 'control', tzn. np. kasujące poprzedni artykuł, martwi się o
   właściwe 'From:' i 'Sender:', by była możliwa odpowiedź do autora, a
   nie tylko na listę, oraz parę innych rzeczy. No i to co najważniejsze
   - przy właściwej konfiguracji każdy artykuł pojawia się dokładnie raz
   na liście i raz w newsach.
   
   Pakiet mail2news nie jest na razie dostępny na żadnym anonymous ftp
   (podobno miał zostać włączony do INN v1.5, ale tak się nie stało),
   jest bowiem na razie w wersji 'beta' (choć trwa to już od końca 1993
   roku), należy się więc skontaktować z autorem (Rich Salz -
   rsalz@uunet.uu.net), by otrzymać jego kopię. Dobrze jest także
   skontaktować się ze mną (pod adresem tsurmacz@ict.pwr.wroc.pl), aby
   uzyskać poprawki do tego programu, zapewniające właściwe traktowanie
   nagłówków "Content-Type:" i innych, które występują w
   listach/artykułach zawierających polskie znaki diakrytyczne. Istnieje
   także (na razie w fazie zaawansowanych testów) wersja w PERLu napisana
   przez Piotra Piątkowskiego, która dodatkowo potrafi dokonywać
   przekodowania z Quoted Printable na 8bit artykułów wysyłanych do
   newsów z poczty i odwrotnie w drugą stronę. W dalszej części opisany
   jest pakiet mail2news Richa Salza.
   
   Przed kompilacją należy sprawdzić kilka parametrów - jakiego typu
   program używany jest do wysyłania poczty (sendmail czy mh), co
   dopisywane ma być w polu 'Path:' (standardowe 'gateway' czy np.
   'gateway.pwr.wroc.pl'), czy adresy 'From:' news2mail ma generować z
   'Path:', czy bezpośrednio z 'From:' w artykule (w czasach, gdy
   stosowanie adresów uucp staje się przeszłością, należy używać tego
   drugiego), oraz gdzie znajduje się serwer news (a jeśli na tej samej
   maszynie - gdzie sa jego biblioteki - a dokładniej: program inews lub
   rnews). Rożnica pomiędzy inews a rnews może okazać się istotna, bowiem
   inews jest tak naprawdę programem przewidzianym do "interaktywnego"
   przyjmowania newsów od użytkownikow, kontroluje więc m.in. format
   daty, a czasem także np. czy ilość cytowanego tekstu nie jest większa
   od nowego tekstu (jeśli tak zostal skompilowany). inews informuje
   także o błędach na stdout lub stderr, co w przypadku mail2news kończy
   się przekazaniem błędu dalej, czyli do sendmaila i co za tym idzie,
   zwrócenie listu do nadawcy (Sender:), czyli zwykle właściciela listy
   oraz lokalnego postmastera.
   
   W 80% list dyskusyjnych wszystko dziala jednak jak należy, a wówczas
   inews jest o tyle lepszy, że poprzez zwracanie błędów w sposób
   natychmiastowy zwraca uwagę administratora news na to, że cos jest nie
   tak. Natomiast błędy występujace przy dostarczaniu artykułów za pomocą
   rnews sa zwykle przez ten program po cichu ignorowane, a odbicie
   znajdują jedynie w logach z pracy serwera. Istotne jest jednak to, że
   mail2news umożliwia podanie 'agenta news' jako parametr przy
   uruchomieniu, tak więc bez konieczności rekompilacji, można w dowolnym
   momencie inews zmienić na rnews lub odwrotnie.
   
   Po skompilowaniu mail2news pozostaje juz właściwie tylko skonfigurować
   serwer news i listserwer, by przesyłały sobie nawzajem artykuły.
   Najpierw o tym, jak to zrobić z mail2news, bo z tym jest zwykle więcej
   problemów...
   
   Rozpatrzmy taki przykład - tworzymy grupę "pl.nowa.grupa", którą
   łączymy z listą "nowa-lista" obsługiwaną przez listserv@plearn.edu.pl.
   Serwerem news, na którym tego dokonujemy jest "serwer.news.pl". Musimy
   serwer news 'zapisać na tę listę', tzn. np. stworzyć w /etc/aliases
   serwera (lub innego koputera w pobliżu) alias:

        pl-nowa-grupa: "|/usr/local/news/bin/mail2news -npl.nowa.grupa -dlocal"

   Teraz wypadałoby grupę 'pl.nowa.grupa' utworzyć za pomocą 'ctlinnd
   newgroup pl.nowa.grupa y' (lub zgodnie ze składnią serwera news --
   powyższy przykład jest dla serwera INN) i przetestować, czy poczta
   wysyłana na adres pl-nowa-grupa@serwer.news.pl trafia do newsow. Po
   pierwsze - wysyłając email-a na ten adres, a jeśli cos nie działa -
   testując ręcznie:

        % cat > test.posting
        From: użytkownik@serwer.news.pl
        To: pl-nowa-grupa
        Message-ID: test-1@serwer.news.pl
        Date: Mon, 1 Aug 1994, 12:00 MET

        test
        ^D
        % cat test.posting | /usr/local/news/bin/mail2news -npl.nowa.grupa -dlo
cal

   (albo nagrać jakis list wysłany samemu sobie do pliku i probować go
   przekazać do mail2news).
   
   Jesli w tym momencie chcemy przetestowac, jak z dostarczaniem newsów
   poradzi sobie rnews zamias inews, wystarczy wpisac:

        % cat test.posting | \
        /usr/local/news/bin/mail2news -=/usr/local/news/bin/rnews -npl.nowa.gru
pa -dlocal test

   słowo 'test' (lub dowolne inne) na końcu jest konieczne z tego
   względu, że mail2news przekazuje 'agentowi news' parametr '-h' oraz
   wszystkie inne, których sam nie interpretuje (czyli '-h test') - inews
   wymaga '-h' bez parametrów, dla rnews po '-h' musi wystąpić nazwa
   'hosta' która zostanie zapisana w logach serwera. Pamiętać należy też
   o tym, że o ile mail2news wykorzystujący inews może być uruchomiony
   "niedaleko" serwera, to rnews da się uruchomić wyłącznie na serwerze,
   albo na komputerze, który z serwerem news ma połączenie via UUCP.
   Jeśli wszystko działa tak jak trzeba, pozostaje zapisać serwer news
   jako subskrybenta listy dyskusyjnej: albo poprosić właściciela listy
   by dopisał do niej adres pl-nowa-grupa@serwer.news.pl, albo zrobić to
   samemu, posyłając e-mail z adresu pl-nowa-grupa do listserwera. Jak
   posłać maila z takiego adresu? O tym chyba wszyscy wiedzą, ale jakby
   nie, to jako root (albo jeden z 'trusted users' sendmaila - np.
   'news') należy wykonać:

        # cat | /usr/lib/sendmail -fpl-nowa-grupa@serwer.news.pl listserv@plear
n.edu.pl
        From: pl-nowa-grupa@serwer.news.pl
        To: listserv@plearn.edu.pl

        sub nowa-lista "mail to news gateway at serwer.news.pl"
        ^D

   W ciągu kilku lub kilkudziesięciu minut powinien się w newsach pojawić
   pierwszy artykuł - z odpowiedzią serwera i informacją "You have now
   subscribed to list nowa-lista" itd. Jeśli tak, to wszystko na
   najlepszej drodze. Aby poustawiać wszystkie opcje dystrybucji jak
   należy, poślij listserwerowi (ponownie z adresu
   pl-nowa-grupa@serwer.news.pl) list o treści:

        set nowa-lista full
        set nowa-lista noack

   Pierwsza linia oznacza, że listserwer ma posyłać pełne nagłówki (a
   więc włącznie z Message-ID), druga - że artykuły przesłane z serwera
   news nie będą do niego ponownie wysyłane. Opcje powyższe działają
   poprawnie w przypadku listserwerów bitnetowych oraz 'listproc-a', inne
   listserwery mogą wymagać nieco innych komend, na przykład 'set
   nowa-lista norepro' itp.
   
   Jeśli wszystko działa jak należy, pora na wysyłanie newsów na listę. W
   pliku newsfeeds należy dopisać linię mniej więcej następującej treści:

    nowa-lista/gateway\
        :pl.nowa.lista,/!local,!pl-news\
        :Tp:/usr/local/news/bin/news2mail nowa-lista nowa-lista \
        pl-nowa-grupa@serwer.news.pl plearn.edu.pl

   (ostatnie 2 linijki w zasadzie powinny zmieścić się w jednej, ale dla
   czytelności podzieliłem ja na dwie - TS). Argumenty podane dla
   news2mail oznaczają że:
   
     * (1 i 4) - poczta zostanie dostarczona na adres
       nowa-lista@plearn.edu.pl,
     * (2 i 4) - w polu 'To:' będzie wpisane nowa-lista@plearn.edu.pl,
     * (3) - w polu 'Sender:' będzie wpisane pl-nowa-grupa@serwer.news.pl
       - 4. argument jest tutaj ignorowany, bo w adresie już jest '@'
       
   Poza tym 'From:' zawsze zawiera adres z pola 'From:' w artykule news
   (chyba że w trakcie kompilacji wybrano opcje generowania 'From:' na
   podstawie 'Path:')
   
   'Sender:' - powinien być adresem, jakiego użyliśmy zapisując mail2news
   na listę, większość z list bowiem nie akceptuje listów wysyłanych
   przez osoby nie będące subskrybentami listy. Aby więc listy wysłane w
   newsach trafiały w sposób pewny na listę, użytkownik występujący w
   polu 'Sender' lub 'From' musi być na listę zapisany - co łatwo
   osiągnąć definiując właściwie pole 'Sender'. Ponadto, aby 'Sender:'
   wpisane przez news2mail było respektowane przez sendmail-a (lub innego
   agenta :-) pocztowego), trzeba jeszcze upewnić się, że użytkownik
   'news' (z tym id działa serwer news, a więc i news2mail przez niego
   uruchamiany) jest wpisany w sendmail.cf jako 'trusted user', (opcja
   'Trusted' jest bez znaczenia w sendmail 8.6.x, ale począwszy od wersji
   8.7.1 ponownie jest respektowana), np:

        DT root uucp news

   Najlepiej oczywiście na początek zamiast adresów listserwera wpisać
   własny i przetestować, czy artykuł wysłany w news trafia do e-maila
   jak należy. Po wykonaniu 'ctlinnd reload newsfeeds' i wysłaniu
   artykułu do news, albo od razu powinien on zostać dostarczony
   email-em, albo zakolejkowany. Wówczas '/usr/lib/sendmail -q'
   przyspieszy jego dostarczenie. No a gdy już okaże się, że artykuł
   dotarł i wyglądał mniej więcej tak:

    From news.test@cyber.ict.pwr.wroc.pl Sat Aug  6 18:05:02 1994
    Return-Path: <news.test@cyber.ict.pwr.wroc.pl>
    Received: from cyber by asic.ict.pwr.wroc.pl (4.1/SMI-4.1)
        id AA14199; Sat, 6 Aug 94 18:05:01 +0200
    Received: from NEWS GATEWAY by cyber with netnews
        for ts@asic (ts@asic)
    From: tsurmacz@sprocket.ict.pwr.wroc.pl (Tomasz Surmacz)
    Message-Id: <320c32$ena@cyber.ict.pwr.wroc.pl>
    Sender: news.test@cyber.ict.pwr.wroc.pl
    Subject: test news2mail

    test news2mail - wysłany przez tin-a uruchomionego na komputerze
    'sprocket', połączonego z serwerem news 'cyber', gdzie grupa
    pwr.nowa.lista w newsfeeds opisana jest jako:

    list-test/gateway\
        :!*:pwr.nowa.lista:Tp:\
        /bin/news2mail ts ts news.test@cyber.ict.pwr.wroc.pl asic

   (tzn. miał właściwy adres From: oraz Sender:), to możemy zmienić
   własny adres na adres listserwera, jeszcze raz wykonać 'ctlinnd reload
   newsfeeds' i mieć nadzieję, że wszystko działa jak trzeba. Gdy już
   grupa zostanie także utworzona na innych serwerach news, wystarczy
   tylko przestawić dystrybucję w aliasie:

        pl-nowa-grupa: /usr/local/news/bin/mail2news -npl.nowa.grupa -dlocal

   na:
        pl-nowa-grupa: /usr/local/news/bin/mail2news -npl.nowa.grupa -dworld

   (lub w ogóle zlikwidować '-d' zakładając, że serwer nie dopisze
   żadnej, a więc będzie szło w świat, ale lepiej to wówczas sprawdzić).
   To wszystko...
   
   Ostatnia uwaga, dotycząca uruchamiania różnych bramek -- powyższy opis
   ma za zadanie pomóc w konfiguracji bramek uruchamianych dla własnych
   lokalnych potrzeb, niedostępnych z zewnątrz i dla "wszystkich".
   Pojawiające się ostatnio (2001-2003) jak grzyby po deszczu bramki
   wrzucane do różnorakich serwisów www i nie wymagające żadnej
   autoryzacji dostępu (przez co szybko stają się źródłem spamów, trolli
   i innych abuserów), będą tępione z całą surowością.
     _________________________________________________________________
   
                         mail2news z użyciem procmaila
                                       
   Problemem pojawiającym się po skonfigurowaniu mail2news w sposób
   opisany w powyższym punkcie jest to, że wszelkiego rodzaju błędy w
   dostarczaniu poczty trafiającej z newsów na listę dyskusyjną są
   przesyłane z powrotem do bramki mail2news, a więc trafiają do grup
   news. Aby tego uniknąć warto skorzystać z programu procmail i
   odfiltrować takie listy wyrzucając je do /dev/null lub zapisując do
   odpowiedniego pliku, ale nie wysyłając do news.
   
   Jeśli na serwerze news zainstalowanych jest kilka bramek mail2news,
   można je wszystkie obsługiwać za pomocą jednego pliku z regułkami
   procmaila, separując odpowiednie listy na grupy news po nagłówkach To:
   lub innych, można też dla każdej grupy stworzyć osobny alias z osobnym
   plikiem .rc, zakładając, że plik ten obsługuje wyłącznie jedną listę
   dyskusyjną, połączoną z jedną bramką mail2news. Jako że różnica polega
   jedynie na wpisaniu odpowiednich regułek, w dalszej części opisu nie
   ma znaczenia, który z tych sposobów został wybrany.
   
   Wszystkie pliki .rc bramek najlepiej umieścić w jednym katalogu, np.
   ~news/mail2news. Program procmail, wywoływany pośrednio przez plik
   /etc/aliases uruchamiany będzie z opcją -m, oznaczającą, że ma działać
   jako filtr poczty, czytając konfigurację z jawnie podanego pliku
   konfiguracyjnego z regułami filtrowania poczty. W tym trybie procmail
   zachowuje się jednak różnie, zależnie od tego, w jakim katalogu
   znajduje się ten plik. Jeśli jest to plik, którego pełna ścieżka
   rozpoczyna się od /etc/procmailrcs/ i nie zawiera w nazwie odwołań
   pośrednich w górę (czyli do katalogów `..'), to poczta będzie
   dostarczana z prawami użytkownika, który jest właścicielem tego pliku.
   Dopuszczalne są dowiązania symboliczne, ale nie zawierające w ścieżce
   katalogów `..'. Jeżeli te warunki nie są spełnione, albo program
   procmail nie ma ustawionego bitu suid, poczta będzie dostarczana w
   standardowy sposób, tzn. z takimi prawami użytkownika, jakie zostaną
   ustawione przez agenta pocztowego wywołującego procmail (czyli zwykle
   program sendmail), będzie to więc zazwyczaj użytkownik daemon i grupa
   mail (tak naprawdę zależy to jednak od tego, co jest wpisane w
   konfiguracji sendmail.cf).
   
   Właściwe prawa dostępu do katalogu, zawierającego pliki z regułami
   filtrowania poczty, do samych plików z tymi regułami oraz wszystkich
   innych plików, potrzebnych procmailowi do zapisywania logów itp., są
   kluczowe dla prawidłowego działania całości. Jeśli występują
   jakiekolwiek błędy, najprawdopodobniej są one spowodowane właśnie tym,
   że procmail wykonywany jesy jako inny użytkownik i nie ma prawa
   odczytu konfiguracji lub zapisu logów.
   
   Najlepiej, aby procmail wykonywany był jako użytkownik news, dlatego z
   katalogu /etc/procmailrcs dobrze jest utworzyć dowiązanie symboliczne
   do odpowiedniego katalogu posiadanego przez użytkownika news lub
   tworzyć pliki konfiguracyjne jako użytkownik newss bezpośrednio w
   podkatalogu /etc/procmailrcs.
   
   Należy więc wykonać jedną z dwóch rzeczy:
   
        mkdir /etc/procmailrcs
        cd /etc/procmailrcs
        ln -s ~news/mail2news mail2news
lub:
        mkdir /etc/procmailrcs
        cd /etc/procmailrcs
        mkdir mail2news
        chown news mail2news
        chgrp news mail2news
        chmod 2755 mail2news

   W katalogu tym tworzymy plik xxx.rc, mający za zadanie obsługiwać
   bramkę grupy pl.xxx. Plik ten powinien być posiadany przez użytkownika
   news:

        PATH=/bin:/usr/bin:/usr/local/bin
        HOME=/home/news
        MAILDIR=$HOME/mail2news
        DEFAULT=$MAILDIR/Default        #completely optional
        LOGFILE=$MAILDIR/from           #recommended

        :0:
        * From.*MAILER-DAEMON
        warning

        :0
        *
        |/usr/local/news/bin/mail2news -o'Lista xxx' -npl.xxx xxx

   Plik ten ma za zadanie odfiltrowywać całą pocztę pochodzącą od
   użytkownika MAILER-DAEMON do pliku warning, a pozostałą pocztę
   przekazywać do programu mail2news, wywoływanego z odpowiednimi
   parametrami (zostały one omówione w poprzednim punkcie). Informacja o
   każdym liście zostaje zapisana w pliku from. Taka konfiguracja
   przydatna jest do testowania działania bramki. Po sprawdzeniu
   działania lepiej jest skierować listy od demona do /dev/null, wpisując
   taką właśnie nazwę zamiast `warning', podobnie można także postąpić z
   logiem z pracy procmaila, czyli plikiem from. Alternatywne wyjście, to
   uruchomienie wykonywanego raz dziennie lub raz na tydzień z cron-a
   skryptu, który będzie kasował zawartość tych plików, jako że
   pozostawione całkiem bez nadzoru rosłyby ciągle, zajmując coraz więcej
   miejsca na dysku.
   
   Ostatnią rzeczą do zrobienia jest wpisanie lub modyfikacja
   odpowiedniego aliasu w pliku /etc/aliases, a powinien on wyglądać
   następująco:

        news.xxx: "|/usr/local/bin/procmail -m /etc/procmailrcs/mail2news/xxx.r
c"
     _________________________________________________________________
   
                              Newsfeed przez uucp
                                       
  0. Dlaczego?
  
   Internetowy protokół transferu news NNTP, oprócz wielu zalet, ma też
   wady.
   
   Przesłanie jednego artykułu odbywa się w następujacy sposób:
   
   Nadawca: mam artykuł
   Obiorca: sprawdza, odpowiada: nie mam, dawaj go.
   N: nadaje, czeka.
   O: potwierdza odbiór.
   N: mam artykuł
   ...

   Taki synchroniczny sposób przesyłania artykułów po jednym oznacza, że
   szybkość transferu news może być znacznie mniejsza od pasma linii
   łączącej nadawcę z odbiorcą, zwłaszcza jeśli komputery połączone są
   linią satelitarną lub jeśli komputer-odbiorca jest na tyle wolny, że
   dużo czasu zajmuje mu sprawdzenie, czy dany artykuł już ma. W bardzo
   poważny sposób można to poprawić stosując tzw. "streaming nntp", co
   oznacza, że nadawca pcha strumień newsów nie czekając na
   natychmiastowe potwierdzenia, lecz uzyskując je nieco później. Do tego
   trzeba jednak nowszej wersji INND (innd1.4unoff2 już to ma).
   
   Opóźnienie wprowadzane przez linię satelitarną wynosi ok. 800ms, co
   oznacza, ze nawet najszybsza linia i najszybszy komputer nie są w
   stanie przesłać po takiej linii więcej niz ok. 100000 artykułów na
   dobę, przy obecnej 'dawce' rzedu 70000. W praktyce jest jeszcze
   gorzej, bo pozostałe etapy też trwają.
   
   Drugą wadą jest też brak jakiejkolwiek kompresji przesyłanych danych,
   a doświadczenie wykazuje, że na zawartości artykułów newsowych można
   osiagnąć współczynnik kompresji do ok. 50% pierwotnej wielkości. Ta
   wada jest z kolei bardzo istotna w przypadku łącz o małej
   przepustowości.
   
   Obu tych wad nie posiada sposób przesyłania za pomocą tzw. 'compressed
   batches over uucp'. Przesyła się w paczkach - a więc nie trzeba czekać
   na potwierdzenie każdego artykułu. Kompresuje się - a więc danych do
   przesłania jest mniej.
   
   Oczywiście, ten sposób też ma wady:
     * wymaga uruchomienia oprogramowania uucp.
     * może się zdarzyć, że w paczce przyjdzie niepotrzebnie coś, co już
       mamy (to grozi tylko wtedy, kiedy mamy feedy z różnych miejsc).
     * przepełnienie dysku grozi dużo poważniejszymi konsekwencjami.
       
   Wady te są jednak w wielu przypadkach z nawiązką rekompensowane
   zaletami.
     _________________________________________________________________
   
  I. Konfiguracja uucp
  
    Standardowe UUCP
    
   Poniżej opisana jest konfiguracja standardowego UUCP w SunOS 4.1.x, na
   innych powinno być podobnie. Konfiguracja z użyciem Taylor UUCP w
   następnym punkcie
   
   Zakładamy, że łączymy ze sobą komputery alfa.aaa.aaa (site name
   AAA.aaa) i omega.zzz.zzz (site name ZZZ.zzz). Dalsze instrukcje
   dotyczą alfy, na omedze wszystko tak samo, tylko odwrotnie.
   
   1. Założyć nowego użytkownika przez dopisanie do /etc/passwd
          
        Uomega:ZZZZZZ:4:8::/var/spool/uucppublic:/usr/lib/uucp/uucico

          gdzie ZZZZZZ jest oczywiście zakodowanym hasłem. Numer
          użytkownika i grupy powinien być taki jak dla użytkownika
          nuucp. 'Home directory' - w zasadzie dowolny, np.
          /var/spool/uucp, itp. Ważne by nie był to katalog z prawem
          zapisu dla 'wszystkich' (czyli 777 lub 1777).
          
   2. Włączyć uucpd
          Dopisać w /etc/inetd.conf linię:
          

        uucp    stream  tcp     nowait  uucp    /usr/etc/in.uucpd in.uucpd

          lub jeśli stosowany jest pakiet tcp_wrappers:
          
        uucp    stream  tcp     nowait  uucp    /usr/etc/tcpd in.uucpd

          i posłać do inetd sygnał HUP.
          
          W tym drugim przypadku warto też pamiętać o dopisanu komputera
          omega.zzz.zzz do listy tych, którym wolno łączyć się z demomem
          "in.uucpd"
          
   3. Pliki konfiguracyjne uucp.
          
          Do /etc/Systems dopisać:
          
        omega Any TCP - omega.zzz.zzz in:--in: Ualfa word: AAAAAA

          gdzie AAAAAA jest niezakodowanym hasłem użytkownika Ualfa na
          komputerze omega. W Solarisie 2.x plikiem tym jest
          /etc/uucp/Systems, natomiast w przypadku używanego często
          'Taylor uucp' jest to oczywiście 'sys'. (Podobnie z następnymi
          plikami). Przy okazji Taylor UUCP, warto wspomnieć, że w pliku
          sys zamiast hasła można wpisać '\P', a zamiast nazwy
          użytkownika - '\L', dopisać dwie opcje: 'called-login *' i
          'called-password *', po czym te poufne dane umieścić w pliku
          'call' w postaci trójki 'nazwa-uucp-systemu nazwa-konta hasło',
          czyli np.:
          
        omega   Ualfa   AAAAAA

          Często występującym błędem uniemożliwiającym poprawne
          połączenie dwóch serwerów przez UUCP jest to, że komputer
          nawiązujący połączenie usiłuje ustawiać 7-bitowe wysyłanie
          danych z kontrolą parzystości, podczas gdy "serwer" spodziewa
          się danych 8-bitowych. Tak na przykład jest na SUNach z SunOSem
          i Solarisem. Można temu jednak prosto zaradzić, uzupełniając
          powyższą linię w pliku Systems w taki sposób:
          
        omega Any TCP - omega.zzz.zzz "" P_ZERO in:--in: Ualfa word: AAAAAA

          Do /etc/Permissions lub odpowiednika dopisać:
          
        LOGNAME=Uomega MACHINE=omega VALIDATE=omega COMMANDS=/usr/local/news/rn
ews

   (Oczywiście, należy podać prawdziwą ścieżkę do programu rnews).
          
   4. Periodyczne przeglądanie kolejek uucp włącza się przez crontab:
          
        su uucp
        crontab </usr/lib/uucp/uudemon.crontab

          I juz.
          
          Uwaga: standardowo crontab ustawia uruchamianie programu
          uudemon.hour co 30 minut. Warto - zwłaszcza do testów na
          początek - uruchamiać go częściej.
     _________________________________________________________________
   
    Taylor UUCP
    
   Zakładamy, tak jak poprzednio, że łączymy ze sobą komputery
   alfa.aaa.aaa (uuname - AAA.aaa) i omega.zzz.zzz (site name ZZZ.zzz).
   Instrukcje dotyczą alfy, na omedze wszystko tak samo, tylko odwrotnie.
   
   1. Tak jak i w "zwykłym" UUCP - założyć nowego użytkownika przez
          dopisanie do /etc/passwd
          

        Uomega:ZZZZZZ:4:8::/var/spool/uucppublic:/usr/lib/uucp/uucico

          (ZZZZZZ - zakodowane hasło. Numer użytkownika i grupy taki, jak
          dla użytkownika nuucp). Zależnie jednak od tego, jak
          uruchamiamy demona uucico, ten krok może okazać się zbędny.
          Przyjmijmy, że uucico będzie dokonywać autentykacji
          użytkowników samodzielnie. Wówczas modyfikacja /etc/passwd nie
          jest konieczna.
          
   2. Włączamy demona uucp.
          Dopisujemy w /etc/inetd.conf linie:
          

        uucp    stream  tcp     nowait  uucp    /usr/local/lib/uucp/uucico uuci
so -s -l

          lub jeśli stosowany jest pakiet tcp_wrappers:
          
        uucp    stream  tcp     nowait  uucp    /usr/etc/tcpd /usr/local/lib/uu
cp/uucico -s -l

          i posyłamy do inetd sygnał HUP.
          
          Uruchomienie uucico z opcjami '-s -l' powoduje, że dokonywać
          ono będzie sprawdzenia nazwy i hasła użytkownika samodzielnie.
          Można oczywiście stosować wyjście z in.uucpd, pamiętając
          jednak, że in.uucpd ZAWSZE woła potem /usr/lib/uucp/uucico,
          należy więc umieścić w tym miejscu uucico z pakietu Taylor
          uucp. Hasła i loginy, jakie uucico akceptuje, znajdują się w
          pliku passwd, ale nie w katalogu /etc, tylko w tym, w którym
          jest cała reszta plików konfiguracyjnych Taylor UUCP (załóżmy,
          że jest to katalog /etc/uucp, ale to zależy od parametrów
          kompilacji Taylor UUCP oraz zawartości "głównego" pliku
          konfiguracyjnego).
          I ponownie - jeśli stosujemy tcpd, pamiętajmy o dopisanu
          komputera omega.zzz.zzz do listy tych, którym wolno łączyć się
          z demomem "uucico"
          
   3. Pliki konfiguracyjne uucp.
          
          Do /etc/sys (A dokładniej - do pliku 'sys' w katalogu z
          konfiguracją Taylor UUCP) należy dopisać:
          

        system omega
        time Any
        port TCP
        address omega.zzz.zzz
        called-login Uomega
        call-login *
        call-password *
        chat ogin:--ogin:--ogin:--ogin: \L word: \P
        protocol tfigGa
        commands rmail rnews

          a w pliku call:
          
         omega    Ualfa   AAAAAA

          gdzie AAAAAA jest niezakodowanym hasłem użytkownika Ualfa na
          komputerze omega. Hasło to na omedze znaleźć się musi w
          /etc/uucp/password w takiej postaci:
          

        Ualfa     AAAAAA

   To, czy w pliku passwd hasła są zakodowane, czy nie, zależy od opcji
          kompilacji Taylor UUCP.
          
   3. Dobrze jest sprawdzić, czy w pliku port znajduje się definicja
          "portu" o nazwie TCP, z którego mamy zamiar korzystać:
          

    port TCP
    type tcp

   4. Periodyczne przeglądanie kolejek uucp włącza się przez crontab:
          
        su uucp
        crontab </usr/lib/uucp/uudemon.crontab

          Jeśli brak nam natomiast "standardowego" uudemon.crontab,
          wpisać możemy sami:
          

0,15,30,45 * * * * /usr/lib/uucp/uucico -somega
0 7 * * * /usr/lib/uucp/uustat -Q -o 120 -y 144 -N -W "Still undelivered after
5 days"
5 7 * * * /usr/lib/uucp/uustat -Q -o 168 -N -K -W "Still undelivered after 7 da
ys, removed from the UUCP queue"

          I już. Jeżeli w przyszłości oprócz omegi pojawią się inne
          systemy, to także należy dla nich dopisać odpowiednie linie z
          'uucico', albo uruchamiać 'obdzwanianie' wszystkich systemów za
          pomocą "uucico -sall".
          
          Uwaga: 15 minut jest tu tylko orientacyjnym czasem, co jaki
          można przesyłać kolejki uucp. Warto samemu zbadać, jaki czas
          będzie najlepszy i dopasować to do potrzeb serwera news.
          Ostatnie dwie linijki w powyższym przykładzie oznaczają, że
          jeśli batch siedzi w kolejce 120-144 godzin (czyli 5-6) dni, to
          ostrzegamy "nadawcę" zadania (czyli w tym przypadku "news") o
          niemożności przesłania batcha, po 7 dniach (168 godzin)
          niedostarczone batche usuwamy.
     _________________________________________________________________
   
  II. Konfiguracja C News do wysyłania batchów
  
   Wszystkie operacje jako user news.
   
    1. Założyć katalog:
        mkdir /usr/spool/news/out.going/omega
    2. W pliku /usr/lib/news/sys wpisać:

        ZZZ.zzz:all,!control/all,!local:f:/usr/spool/news/out.going/omega/togo
   Lista wysyłanych grup i dystrybucji oczywiście do indywidualnego
       ustalenia.
    3. W pliku /usr/lib/news/batchparms wpisać:

        omega           200000  20      batcher compcun viauux
    4. Uruchomić wysyłanie batchów przez dopisanie do crontaba linii:

        05,15,25,35,45,55 * * * * /usr/lib/newsbin/batch/sendbatches omega
   Uwaga: Można co 10 minut, można rzadziej. Dobrze jest, aby było to
       skorelowane z godzinami, kiedy uruchamiany jest uudemon.hour -
       tak, aby uudemon startował zaraz po przygotowaniu paczki do
       wysłania. Można np. przygotowywać paczki o 00 i 30, a demona
       startować o 05 i 35. Im częściej będziemy to robić, tym mniejsze
       będą opóźnienia w rozchodzeniu się news, ale nie należy
       przesadzać, żeby nie przeciążyć komputera i nie zniweczyć zysków,
       które uzyskaliśmy dzięki paczkowaniu. Jeżeli używamy Taylor UUCP,
       to należy pamiętać, by zamiast uudemon.hour, odpowiednio często
       uruchamiać z crontaba użytkownika uucp komendy uucico kontaktujące
       się z innym systemem, tak jak to zostało opisane powyżej, albo np:

        7 8-16 * * * /usr/local/lib/uucp/uucico -somega
        7,17,37 17-23,0-6 * * * /usr/local/lib/uucp/uucico -somega
     _________________________________________________________________
   
  III. Konfiguracja C News do odbierania batchów
  
   Uruchamiany przez uucp program rnews nagrywa nadchodzące paczki w
   katalogu /usr/spool/news/in.coming. Aby zostały one skonsumowane przez
   C News, należy dokonać - do wyboru - jednej z dwóch operacji:
   
    1. uruchamiać co pewien czas program newsrun przez wpisanie do
       crontaba:

        09,19,29,39,49,49,59 * 1-31 * 0-6     /usr/lib/newsbin/input/newsrun
   (Tak dobrać, żeby się uruchamiał w parę minut po nadejściu każdej
       paczki.)
       albo
    2. stworzyć plik /usr/lib/news/rnews.immed, co sprawi, że rnews
       będzie automatycznie uruchamiać newsrun.
       Jeśli feed jest duży i wiemy, że za każdym obiegiem sendbatches
       maszyna omega posyła nam średnio więcej niż jeden batch, polecam
       sposób pierwszy. Jeśli dostajemy tylko niewielkie batche,
       pojedyncze i nie za każdym obiegiem sendbatches, polecam sposób
       drugi.
     _________________________________________________________________
   
  IV. Konfiguracja INN do wysyłania batchów.
  
   1. Utworzenie feedu w pliku newsfeeds, przykładowo:
          
            cocos/fuw.edu.pl\
                :*,!torun.*,!umk.*,!mat.*,/!torun,!umk,!mat\
                :Tf,Wnb:

          Zwykły feed używa na ogół parametrów "Tf,Wnm". Feed UUCP -
          "Tf,Wnb" - co powoduje tworzenie w /var/spool/news/out.going
          pliku o innym formacie niż dla NNTP, zawierającego ścieżki do
          artykułów i ich wielkości. 'cocos' to tutaj zarówno nazwa pliku
          w katalogu out.going jak i adres UUCP adresata. Adres nie musi
          byc zarejestrowany w mapach UUCP. Identyfikatory do Path:_ są
          te same, co dla feedu nntp. Dla porównania, ten sam feed w
          wersji nntp:
          
            uw/uw.edu.pl\
                :*,!torun.*,!umk.*,!mat.*,/!torun,!umk,!mat\
                :Tf,Wnm:

   2. Poprawienie skryptu /usr/local/news/bin/sendbatch.
          
          W systemie Solaris 2.3, przy korzystaniu ze "standardowego"
          UUCP należy zwrócić uwagę na parametr _PATH_COMPRESS w pliku
          config.data serwera, a jeśli jest już na to za późno, w pliku
          sendbatch poprawić linię:
          

        COMPRESS=/usr/ucb/compress

   i
          
        UUXFLAGS="- -r -n -gd"

   na
          
        COMPRESS=/usr/bin/compress
        UUXFLAGS="- -r -n"

          ponieważ ścieżka do compress jest inna (w Solarisie 2.4
          ponownie jest już w /usr/bin). Linię z parametrami programu uux
          należy poprawić zawsze, gdyż uux w systemie Solaris nie rozumie
          grade 'd'.
          
          Aby temu zaradzić, można skompilować (na Solarisie, Linuxie i
          innych systemach) "Taylor UUCP" - kompiluje się bez problemów,
          poza jednym małym - jeśli planujemy używać UUCP także przez
          modem, trzeba KONIECZNIE w pliku "policy.h" zdefiniować
          'HAVE_POSIX_TERMIOS', zamiast liczyć na to, że system sam
          zgadnie (według opisu), bo w Solarisie zgaduje
          'HAVE_SYSV_TERMIO' i źle działa z szybkimi (potrzebującymi
          sprzętowej kontroli przepływu) modemami, a na Linuxach
          kompilator zgaduje HAVE_BSD_TERMIO, zamiast stosować
          HAVE_POSIX_TERMIOS.
          
          INN FAQ zaleca, aby rozmiar pojedynczego batcha zwiększyć z
          
               DEFBYTES=50000

   do 200000 bajtów, zarówno dla połączeń TCP jak i telefonicznych. Można
          to zrobić przez zmianę wartości tej zmiennej w skrypcie lub
          podanie opcji -s200000 przy wywołaniu sendbatch w cronie.
          
   3. Periodyczne wywoływanie sendbatch.
          
          Do crontab użytkownika news należy dopisać:
          
        9,19,29,39,49,59 * * * * /usr/local/news/bin/sendbatch -c cocos >/dev/n
ull 2>&1

          gdzie cocos to adres UUCP adresata. Częstotliwość nie musi być
          tak duża. Opcja -c może byc zastąpiona opcją -cg wg propozycji
          Michała (p. III. Konfiguracja INN do nadawania z kompresją gzip
          poniżej). Warto też wpisać pewne ograniczenia, aby w przypadku
          jakiejś awarii po drugiej stronie nie zapchać dysku
          narastającymi kolejkami batchów. Można to zrobić za pomocą
          opcji -m przy wywołaniu skryptu sendbatch z crontaba, jak
          poniżej:
          

        9,19,29,39,49,59 * * * * /usr/local/news/bin/sendbatch -m12000000 -s100
000 -c cocos >/dev/null 2>&1

   W powyższym przykładzie batche są kompresowane (opcja -c), każdy z
          nich nie dłuższy niż 100kB (opcja -s), a na dodatek jeżeli
          wielkość zgromadzonych na dysku batchów przekroczy 12 tys.
          bloków (czyli zależnie od standardowej wielkości bloku
          dyskowego - 6 lub 12 MB), to generowanie batchów zostaje
          wstrzymane - identyfikatory "wychodzących" newsów są nadal
          gromadzone w /var/news/out.going/cocos i
          /var/news/out.going/cocos.uucp, ale plik 'cocos.uucp' zostanie
          użyty do wygenerowania następnego batcha, dopiero wtedy, gdy
          nieco ubędzie batchów już znajdujących się w kolejce do
          wysłania.
          
          Wielkość podana jako argument opcji '-m' to ilość bajtów na
          dysku, które mogą zająć batche, ale tak jest tylko w wypadku
          1024-bajtowych bloków na dysku (BSD, Linux, SunOS). W SysV
          (AIX, Solaris, IRIX) komenda 'df' i pokrewne podają dane
          zakładając 512-bajtowe bloki, a więc jeśli batche mają zajmować
          nie więcej niż 10 MB, to należy podać liczbę 20.000.000.
          
          Warto też od razu zauważyć, że metoda ograniczania batchów nie
          zadziała, gdy transmitujemy batche uucp w sposób pośredni, co
          zostało opisane w dalszej części.
     _________________________________________________________________
   
  V. Konfiguracja INN do odbierania batchów.
  
   Nic nie trzeba robić - wszystko jest "wbudowane" standardowo. Należy
   jedynie zadbać, by w /bin/rnews znalazł się program rnews z
   dystrybucji innd, oraz mimo wszystko do crontab-a użytkownika news
   dopisać jednak następującą linijkę:

        7 0,6,12,18 * * * /bin/rnews -U

   a więc raz lub kilka razy dziennie uruchamiać program rnews z pakietu
   INND. Opcja '-U' powoduje, że rnews nie szuka batchów na wejściu, lecz
   przeszukuje katalog /usr/spool/news/in.coming . W normalnych warunkach
   nie jest to konieczne, natomiast przydaje się w sytuacjach awaryjnych,
   gdy z jakiegoś powodu serwer przestaje przyjmować newsy (np. padł,
   albo się zapchał), wtedy batche UUCP (oraz newsy dostarczane przez
   mail2news) trafiają właśnie do /usr/spool/news/in.coming. Serwer sam
   przeszukuje ten katalog podczas uruchamiania, ale nie podczas
   odblokowywania (ctlinnd go ''), jeśli był zapchany. Dlatego dobrze
   jest rnews uruchamiać także z crontab-a.
     _________________________________________________________________
   
Kompresowanie batchów przy pomocy gzip

   Standardowy sposób kompresji programem 'compress' nie jest zbyt
   wydajny. Dlatego, jeśli już mamy działający feed batchowy, proponuję
   uruchomienie kompresjii za pomocą programu 'gzip'. Oczywiście, obie
   strony muszą się umowić, że bedą tego programu używały, dlatego nie
   radzę tego zmieniać globalnie, a tylko osobno dla każdego feedu. Można
   najpierw skonfigurować dekompresję po stronie odbierającej bez zmian u
   nadawcy, gdyż gzip rozumie formaty .gz (gzip - ale nie zip!), .Z
   (stary compress) i .z (jeszcze starszy pack).
     _________________________________________________________________
   
  I. Konfiguracja C News do nadawania z kompresją gzip
  
   1. Stworzyć nowy skrypt kompresujący batche, pod nazwą
   /news/lib/newsbin/batch/gzipcun

        #! /bin/sh
        # Invoke gzip, adding silly 2.11-compatible header.
        echo "#! cunbatch"
        gzip

   (pamiętać, żeby zrobić 'chmod +x /news/lib/newsbin/batch/gzipcun')
   
   2. W pliku batchparms zmienić compcun na gzipcun
     _________________________________________________________________
   
  II. Konfiguracja C News do odbierania z dekompresją gzip
  
   1. Poprawić program ../input/newsspool.c
     _________________________________________________________________
   
*** newsspool.c.orig    Tue Nov 26 16:52:21 1991
--- newsspool.c Mon Oct 17 19:05:03 1994
***************
*** 31,36 ****
--- 31,37 ----
  char *progname;

  extern void error(), exit();
+
  #ifdef UTZOOERR
  extern char *mkprogname();
  #else
***************
*** 237,246 ****
  #     define  GOOP7LEN        (sizeof(goop7)-1)       /* strlen(goop7) */
        static char suf7[] = ".7";
        static char comp[2] = { 037, 0235 };    /* compress's magic no. */
        register char *p;
        register int nleft;
  #     define  MINCBATCH       5               /* one character, compressed */
!
        nleft = count;
        p = bufp;

--- 238,249 ----
  #     define  GOOP7LEN        (sizeof(goop7)-1)       /* strlen(goop7) */
        static char suf7[] = ".7";
        static char comp[2] = { 037, 0235 };    /* compress's magic no. */
+       static char gzip[2] = { 037, 0213 };    /* gzip's magic no. */
+       static char sufg[] = ".gz";
        register char *p;
        register int nleft;
  #     define  MINCBATCH       5               /* one character, compressed */
! #     define  MINCGZIP        21              /* one character, gzipped */
        nleft = count;
        p = bufp;

***************
*** 254,259 ****
--- 257,269 ----
                return(0);
        }

+       if (p[0] == gzip[0] && p[1] == gzip[1]) {       /* gzipped */
+               if (nleft < MINCGZIP)
+                       return(count);
+               suffix = sufg;
+               return(0);
+       }
+
        if (*p++ != '#' || *p++ != '!')         /* doesn't start with #! */
                return(0);
        nleft -= 2;
***************
*** 268,274 ****
        if (nleft >= GOOPLEN+1 && STREQN(p, goop, GOOPLEN)) {
                p += GOOPLEN;
                nleft -= GOOPLEN;
!               suffix = suf;
        } else if (nleft >= GOOP7LEN+1 && STREQN(p, goop7, GOOP7LEN)) {
                p += GOOP7LEN;
                nleft -= GOOP7LEN;
--- 278,287 ----
        if (nleft >= GOOPLEN+1 && STREQN(p, goop, GOOPLEN)) {
                p += GOOPLEN;
                nleft -= GOOPLEN;
!               if (p[1] == gzip[0] && p[2] == gzip[1])  /* gzipped */
!                 suffix = sufg;
!               else
!                 suffix = suf;
        } else if (nleft >= GOOP7LEN+1 && STREQN(p, goop7, GOOP7LEN)) {
                p += GOOP7LEN;
                nleft -= GOOP7LEN;
     _________________________________________________________________
   
   Skompilować i zainstalować jako /news/lib/newsbin/input/newsspool
   
   W zasadzie można się bez tej zmiany obejść, wtedy newsspool błędnie
   nadaje typ plikom rozszerzenie .Z zamiast .gz, ale programowi gunzip
   (patrz niżej) to nie szkodzi.
   
   2. W skrypcie /news/lib/newsbin/input/newsrun zmienić nastepująco:
     _________________________________________________________________
   
*** newsrun.orig        Thu Oct 27 23:14:45 1994
--- newsrun     Mon Oct 17 15:41:39 1994
***************
*** 121,127 ****
                # Decompress if necessary.
                text=$tmp
                case $f in
!               *.Z)    uncompress <$f >$text   ;;
                *.7)    c7decode <$f | uncompress >$text        ;;
                *.t)    >$tmp           # in case compress left trash
                        text=$f
--- 121,128 ----
                # Decompress if necessary.
                text=$tmp
                case $f in
!               *.gz)   gunzip <$f >$text       ;;
!               *.Z)    gunzip <$f >$text       ;;
                *.7)    c7decode <$f | uncompress >$text        ;;
                *.t)    >$tmp           # in case compress left trash
                        text=$f
     _________________________________________________________________
   
   W zasadzie wystarczy dodać linijkę z .gz, ale traktowanie plików .Z
   programem gunzip nie zaszkodzi, za to umożliwia poprawne działanie
   nawet, jeśli nie chciało nam się przerabiać programu newsspool.
     _________________________________________________________________
   
  III. Konfiguracja INN do nadawania z kompresją gzip
  
   Proponuję dodać nową opcję do skryptu /usr/local/news/bin/sendbatch
     _________________________________________________________________
   
*** sendbatch.orig      Thu Oct 27 23:29:30 1994
--- sendbatch   Thu Oct 27 23:31:54 1994
***************
*** 14,19 ****
--- 14,21 ----
  COMP=
  COMPFLAGS=
  COMPRESS=/usr/ucb/compress
+ GZIP=/usr/local/bin/gzip
+ GZIPFLAGS=
  ECHO=
  ##  Not a config param since this is the remote rnews.
  RNEWS=rnews
***************
*** 75,80 ****
--- 77,87 ----
      -c)
        COMP="; exec ${COMPRESS} ${COMPFLAGS}"
        ECHO="echo '#! cunbatch'"
+       continue
+       ;;
+     -cg)
+       COMP="; exec ${GZIP} ${GZIPFLAGS}"
+       ECHO="echo '#! cunbatch'"
        continue
        ;;
      +c)
     _________________________________________________________________
   
   W wywołaniu sendbatch (cron) zmienić -c na -cg
     _________________________________________________________________
   
  IV. Konfiguracja INN do odbierania z dekompresją gzip
  
   Trzeba zmienić w pliku config/config.data w źródłach INN
            _PATH_COMPRESS          /usr/ucb/compress
            _PATH_COMPRESSEXT       .Z

   na
            _PATH_COMPRESS          /usr/local/bin/gzip
            _PATH_COMPRESSEXT       .gz

   lub podobnie. Potem niestety trzeba przekompilować (make update) i na
   nowo nagrać programy INN. Jeśli nagramy wszystkie z tą poprawką, to
   całe INN bedzie odtąd używalo gzip do kompresji log-files itp.
   (Gdzieniegdzie jest to tak właśnie zrobione "standardowo"). Jeśli
   chodzi nam tylko o to, żeby rnews rozumiało batche kompresowane przez
   gzip, to wystarczy zainstalować na nowo tylko program rnews.
     _________________________________________________________________
   
UUCP 'pośrednie' (czyli jak wykonać cyber!papaja!rnews)

   Spotykanym czasem problemem związanym z rozsyłaniem news jest jak
   wysłać newsy z serwera za pomocą UUCP do systemu, z którym serwer nie
   ma bezpośredniego łącza UUCP (np. na serwerze news nie ma modemu, a
   newsy trzeba przesyłać przez telefon). Przykładowa sytuacja
   zilustrowana jest poniżej.
   
             uucp/tcpip                 uucp/modem
     news  <------------>  cyber  <----- - - - - ----->  papaja
   serwer news

   'papaja' oznacza system, na którym chcemy odbierać newsy, a który
   łączy się z systemem 'cyber' przez modem, używając protokołów UUCP.
   cyber i news też mają połączenie UUCP, ale oparte o TCP/IP, gdyż oba
   znajdują się w sieci lokalnej. Problem polega na takim ustawieniu
   systemów, by na serwerze news generować batche dla komputera papaja, i
   aby docierały one poprawnie na miejsce.
   
   Jeśli jest możliwe łączenie się komputera papaja z siecią za pomocą
   protokołów SLIP lub PPP, to problem można rozwiązać definiując na
   serwerze news system papaja i każąc im łączyć się bezpośrednio, za
   pomocą UUCP/tcpip. Inne wyjście to skorzystać z komputera cyber
   wyłącznie jako "przekaźnika" połączeń, tzn. zamiast 'login-shell-a'
   typu uucico wykonać "rlogin news" z odpowiednim username, którego
   shellem oczywiście będzie uucico, ale już na docelowym systemie.
   Gorzej, gdy to cyber ma dzwonić przez telefon do systemu papaja.
   
   Najbardziej "klasyczne" i uniwersalne rozwiązanie to taka generacja
   batchów na serwerze, by trafiały one na miejsce przeznaczenia
   całkowicie za pomocą protokołów UUCP. W tym celu należy zmienić
   komendę 'uux', której używa skrypt 'sendbatch', a najprościej zrobić
   to, definiując odpowiedni plik w katalogu /var/news/out.going.
   
   W "normalnym" przypadku (i w tym też) w pliku newsfeeds serwera news
   znaleźć się powinna definicja 'feedu' papaja (jako feedu UUCP!), co
   powoduje utworzenie w /var/news/out.going pliku o takiej samej nazwie,
   używanego do zapamiętywania, które artykuły trzeba do tego komputera
   wysłać. Standardową komendą wysyłającą newsy jest "uux - -gd -n
   ${SITE}!rnews", gdzie '${SITE}' zostaje zastąpione nazwą uucp hosta
   odbierającego batch. W przypadku braku bezpośredniego połączenia musi
   tu jeszcze wejść host pośredni, a więc komenda powinna wyglądać tak:
   
 uux - -r -gd -n ${INTERMEDIATE_SITE}!${SITE}!rnews

   a więc np. "uux - -gd -n cyber!papaja!rnews". Aby taką komendę
   zdefiniować, wystarczy utworzyć plik o nazwie
   '/var/news/out.going/${SITE}.cmd', a więc np.
   /var/news/out.going/papaja.cmd, a w nim wpisać odpowiednią komendę
   'uux' (podaną wyżej). Tworzone w ten sposób batche przeznaczone będą
   (ostatecznie) dla systemu papaja, ale ich transfer nastąpi na system
   cyber i dopiero stamtąd trafią we właściwe miejsce.
   
   niestety, kolejnym problemem pojawiającym się po utworzeniu pliku
   ${SITE}.cmd jest to, że sendbatch przestaje uwzględniać opcje -c i -cg
   umożliwiające kompresję batchów, traktując zawartość pliku ${SITE}.cmd
   dosłownie, bez najmniejszych modyfikacji. Jeżeli wysyłane batche mają
   być kompresowane, przedstawioną powyżej komendę należy zosatąpić inną:
   
 (echo '#! cunbatch' ; exec /usr/bin/compress) | uux - - -r -n -gd ${INTERMEDIA
TE_SITE}!${SITE}!rnews

   Zamiast /usr/bin/compress można oczywiście użyć programu gzip, o ile
   tylko system docelowy potrafił będzie takie batche rozpakować.
   
   Zależnie od tego, jak w systemie uucp zdefiniowane są dozwolone czasy
   łączenia się z innymi systemami, pożądane jest zwykle używanie w
   powyższych poleceniach 'uux' opcji '-r, sprawiającej, że wykonanie uux
   nie będzie od razu wywoływać programu uucico, aby natychmiast połączyć
   się z drugim systemem. Częstą bowiem sytuacją jest zdefiniowanie, że
   system "domowy" może łączyć się ze swoim sąsiadem uucp o dowolnej
   porze, co oznacza, że w dowolnym momencie można stwierdzić, że
   wystarczy pisania listów i czas wykonać stosowne uucico. Brak opcji -r
   powodowałby natychmiastowe uruchomienie uucico po utworzeniu przez
   sendbatch pierwszej paczki artykułów, co może być przydatne na
   serwerze news tworzącym batche dla systemu "domowego", ale
   najprawdopodobniej nie jest pożądane na serwerze "domowym",
   powodowałoby bowiem natychmiastową próbę dzwonienia.
   
   Pamiętać też trzeba o okresowym generowaniu batchów za pomocą skryptu
   "sendbatch" (jak to zostało już wcześniej opisane, oraz o tym, że
   opcja '-m' ograniczająca wielkość znajdujących się w kolejce batchów
   jest tutaj bezużyteczna. Batche te są tutaj bowiem kolejkowane na
   komputer 'cyber', a nie 'papaja', a więc sprawdzenie wielkości kolejki
   na papaję nic nie da.
     _________________________________________________________________
   
Inne możliwości przyspieszenia transmisji News

   Jeżeli największym problemem są opóźnienia, a nie przepustowość linii,
   to prostym tymczasowym rozwiązaniem może byc podział feedu na dwa lub
   więcej i wysyłanie ich jako osobnych, równolegle działających feedów.
   Inne zastosowanie feedów równoległych, a właściwie drabinkowych, to
   poprawienie niezawodności. Jednak w przypadku zrównoleglenia feedów w
   układzie dwa komputery po jednej stronie kabla wysyłające do dwóch po
   drugiej stronie, zwiększa się nieco ilość duplikatów. Warto też
   zwrocić uwagę na maksymalny czas przesyłania news przez nntpsend
   (opcja -T, omówiona wcześniej) oraz godziny startowania batchów
   wysyłających newsy.
   
   Można też uruchomić stałe połączenie między serwerami - nntplink lub
   innfeed, też stosowany w układzie drabinkowym.
   
   Ale ten rozdział napisze już pewnie ktoś inny w następnej wersji...
     _________________________________________________________________
   
   Część pierwsza FAQ - ogólne informacje o grupach pl.*
   Część druga FAQ - konfigurowanie serwerów news
   Część trzecia FAQ - Lista istniejących grup pl.*
   Część czwarta FAQ - Formularz głosowania nad nowymi grupami pl.*
   
   FAQ po angielsku dla administratorów serwerów news poza Polską
     _________________________________________________________________
   
   
    22.12.2003
    
   UUCP:
          Michał Jankowski (Michal.Jankowski@fuw.edu.pl,
          michalj@adm.usenet.pl)
          Rafał Maszkowski (rzm@oso.chalmers.se,
          http://www.mat.uni.torun.pl/~rzm)
          
   Konfiguracja serwera, Taylor UUCP, wersja HTML całości:
          Tomasz Surmacz (tsurmacz@ict.pwr.wroc.pl,
          tsurmacz@adm.usenet.pl)
          
   RCS ID: $Id: news-pl-faq.2.htpl,v 2.21 2003/12/22 03:08:37 ts Exp ts $
     _________________________________________________________________
   
   [This site is vi powered!] (c) 1994-2004 Tomasz R. Surmacz, Michał
   Jankowski, Rafał Maszkowski
   
   Kopirajt i disclajmer:
   
   Powyższy tekst może być w niezmienionej postaci i w całości (wszystkie
   części FAQ), bez ograniczeń kopiowany i drukowany *na własny użytek*,
   przekazywany przez news, e-maila, umieszczany w sieci Internet na
   serwerach WWW, FTP itp. itd.), pod warunkiem przechowywania aktualnej
   wersji (nie starszej niż 2-3 miesiące). Publikowanie tego tekstu w
   inny sposób lub dokonywanie w nim modyfikacji, skrótów, oraz
   rozprowadzanie zmienionej wersji tego FAQ lub jego fragmentów wymaga
   zgody autorów.
   
   Aktualna wersja znajduje się zawsze pod adresem
   http://www.usenet.pl/doc/news-pl-faq.htpl i
   http://www.ict.pwr.wroc.pl/doc/news-pl-faq.html
   
   Autorzy niniejszego FAQ starają się, by wszelkie przedstawione w nim
   informacje były aktualne, ale gwarantować tego nie są w stanie. Jeśli
   po przeczytaniu tego dalej nic nie rozumiesz, program tin czyta
   konfigurację z jakiegoś dziwnego pliku, albo twój ulubiony serwer news
   właśnie się na ciebie obraził -- sorry!, C'est la vie... Jeśli błąd
   jest w tekście - napisz na adres tsurmacz@adm.usenet.pl - może
   poprawię.

Posted-By: auto-faq 3.1.1.2
Archive-name: news-pl-faq/part3

W tej części FAQ zawarte są opisy grup news znajdujących się w hierarchii
pl.* oraz fragment pliku 'active' zawierający definicje wszystkich grup pl.* .

Zawsze aktualna (bo uaktualniana codziennie w nocy) wersja tej listy
znajduje się pod adresem http://www.usenet.pl/doc/pl.newsgroups .
To, co znajduje się w tym artykule, to przetworzona zawartość plików
pl.newsgroups i pl.active w dniu 23.03.2010.

Fragment z opisami grup (między '^=== ' a '^--- ') nadaje sie wprost do
wpuszczenia na wejscie programu 'checkgroups'.

Artykuł ten ma także swoją wersję HTML pod adresem
http://www.usenet.pl/doc/news-pl-faq.3.html -- Zapraszam na tę
stronę szczególnie tych, którzy lubią newsy czytać za pomocą programu
netscape i podobnych - jest tam klikalna lista *WSZYSTKICH* grup pl.* -
i to lista ZAWSZE AKTUALNA, gdyż zarówno wersja tekstowa dostępna przez
FTP, jak i wersja HTML są uaktualniane automatycznie co noc.

Większość pełnych opisów grup (w postaci artykułów tworzących grupę,
zawierających jednocześnie podsumowanie wyników głosowania i opis tematyki
grupy) znajduje się pod adresem http://www.usenet.pl/opisy/

Tomasz Surmacz (Poprawki i uwagi jak zwykle -> tsurmacz@adm.usenet,pl)

### Plik newsgroups - opisy grup:
=== =--------------------------------------------------------------------
pl.announce.newgroups	Ogloszenia o nowych grupach. (Moderated)
pl.answers		Odpowiedzi na pytania, o ktorych wam sie nie snilo. (Moderated)
pl.biznes	Jak zarobic, jak nie stracic.
pl.biznes.banki		Funkcjonowanie bankow w Polsce i za granica.
pl.biznes.wgpw	Warszawska Gielda Papierow Wartosciowych, rynek kapitalowy w Polsce.
pl.comp.bazy-danych	Wszystko o bazach danych.
pl.comp.bazy-danych.msaccess	Visual Basic i MS Access.
pl.comp.cad	Komputerowe wspomaganie projektowania.
pl.comp.demoscena	Polska scena komputerowa.
pl.comp.dtp	Szeroko rozumiana poligrafia.
pl.comp.dtp.tex	Jezyk TeX - zastosowania i porady.
pl.comp.dtp.tex.gust	Jezyk TeX - zastosowania i porady - lista GUST-L. (Moderated)
pl.comp.gis	Wymiana informacji na temat Systemow Informacji.
pl.comp.grafika	Forum dyskusji milosnikow grafiki komputerowej.
pl.comp.grafika.grafika3d	Grafika 3d, modelowanie i animacja komputerowa.
pl.comp.lang.asm	Programowanie w asemblerze i kodzie maszynowym.
pl.comp.lang.c	C i C++ - kruczki, sztuczki, programowanie.
pl.comp.lang.delphi	Delphi i Pascal - kruczki, sztuczki, programowanie.
pl.comp.lang.delphi.bazy-danych	Programowanie baz danych w Delphi.
pl.comp.lang.funkcyjne	Programowanie w jezykach funkcyjnych.
pl.comp.lang.java	Programowanie w jezyku Java.
pl.comp.lang.javascript	Stosowanie JavaScript.
pl.comp.lang.pascal	Programowanie w jezyku Pascal.
pl.comp.lang.perl	Perl - zastosowania, porady.
pl.comp.lang.php	Programowanie w jezyku PHP.
pl.comp.lang.python	Programowanie w jezyku Python.
pl.comp.lang.ruby	Programowanie w jezyku Ruby.
pl.comp.lang.tcl	Jezyk Tcl/Tk i zwiazane z nim aplikacje.
pl.comp.lang.vbasic	Programowanie w Visual Basic.
pl.comp.mail	Poczta elektroniczna na co dzien.
pl.comp.mail.mta	Mail Transfer Agents - konfigurowanie i administracja.
pl.comp.multimedia	Tworzenie prezentacji multimedialnych.
pl.comp.nowe-programy	Tutaj pochwal sie nowym programem.
pl.comp.objects		Obiektowa technologia tworzenia oprogramowania i C++.
pl.comp.ogonki		O polskich literkach w komputerach.
pl.comp.os.advocacy	Dyskusje o wyzszosci jednych systemow nad innymi.
pl.comp.os.bsd	Systemy spod znaku Daemona.
pl.comp.os.linux	Linux - system operacyjny dla kazdego.
pl.comp.os.linux.debian	System Operacyjny Debian GNU/*.
pl.comp.os.linux.programowanie	Programowanie w systemie Linux.
pl.comp.os.linux.sieci	Sieci - konfiguracja i uzytkowanie w systemie Linux.
pl.comp.os.linux.sprzet	Sprzet dzialajacy pod Linuxem.
pl.comp.os.ms-windows.vista	Windows Vista.
pl.comp.os.ms-windows.win3	Microsoft Windows 3.xx - radosci i smutki.
pl.comp.os.ms-windows.win9x	Microsoft Windows 95 i 98 - blaski i cienie.
pl.comp.os.ms-windows.winnt	MS Windows NT na wszelkich platfomach sprzetowych.
pl.comp.os.ms-windows.xp	Windows XP.
pl.comp.os.os2	OS/2 z zewnatrz i od srodka.
pl.comp.os.unix		Unix w bardzo roznych systemach.
pl.comp.pecet		Pecety, czyli sprzet komputerowy klasy PC.
pl.comp.programming	Programowanie w jezykach wszelkich.
pl.comp.security	Bezpieczenstwo systemow i sieci komputerowych. (Moderated)
pl.comp.sieci	Sieci w Polsce dla poczatkujacych i zaawansowanych.
pl.comp.sieci.bezprzewodowe	Nie kabluj.
pl.comp.sys.amiga	Grupa dyskusyjna uzytkownikow komputera Amiga.
pl.comp.sys.atari	Grupa dyskusyjna uzytkownikow komputerow atari.
pl.comp.sys.macintosh	Komputery Macintosh i dyskusje na ich temat.
pl.comp.sys.novell	Wszystko o Novellu.
pl.comp.sys.palmtop	Komputery kieszonkowe.
pl.comp.sys.palmtop.palmos	Komputery kieszonkowe - PalmOS.
pl.comp.sys.sun.admin	Administrowanie komputerami Sun.
pl.comp.sys.x11	X Window System - system otwarty i rozproszony.
pl.comp.tlumaczenia	Tlumaczenie literatury komputerowej. (Moderated)
pl.comp.www	World Wide Web w Polsce i po polsku.
pl.comp.www.nowe-strony		Nowe strony www - info, dyskusje, opinie.
pl.comp.www.server-side		Skrypty CGI, PHP, ASP, SSI itp.
pl.comp.xml	XML, SGML i tematy pokrewne.
pl.fidonet.bramka	Fido widziane z Internetu.
pl.gazety.donosy	Donosy z Warszawy :-) (Moderated)
pl.hum.pisarstwo	Jak nie pisac do szuflady.
pl.hum.poezja	O poezji i poetach, pisaniu i czytaniu wierszy.
pl.hum.polszczyzna	Aby jezyk gietki powiedzial wszystko, co pomysli glowa.
pl.hum.teatr	Teatr. Polski i swiatowy. Repertuarowy i alternatywny.
pl.hum.tlumaczenia	Z polskiego i na polski.
pl.hum.x-muza	Dla tych, ktorzy nad MegaHit przedkladaja Mistrzow Kina.
pl.internet.komunikaty	Komunikaty o problemach z lacznoscia, "trouble tickets" itp. (Moderated)
pl.internet.mordplik	Nie bedzie spamer plul nam w twarz!
pl.internet.polip	Problemy Internetu polskiego i swiatowego.
pl.internet.pomoc	Jestem tu nowy - pomozcie!
pl.irc	Dyskusje polskich uzytkownikow IRC.
pl.listserv.chomor-l	Polski humor, Lista chomor-l@archimedes.pol.lublin.pl
pl.listserv.dziennikarz	Lista dyskusyjna Dziennikarz.
pl.listserv.plotki	Lista polskich plotkarzy. (plotki@ia.pw.edu.pl)
pl.listserv.polwro	Lista ludzi zwiazanych z Politechnika Wroclawska.
pl.misc.budowanie	Budowanie i remontowanie domow i mieszkan.
pl.misc.dieta	Co, ile i kiedy jesc, zeby sie najesc a nie przejesc.
pl.misc.elektronika	Urzadzenia elektroniczne od srodka.
pl.misc.kolej	Od drezyny do TGV.
pl.misc.konsumenci	Problemy polskich konsumentow.
pl.misc.meteorologia	Meteorologia na co dzien.
pl.misc.militaria	Wojskowosc, strategia, technika wojskowa, etc.
pl.misc.paranauki	Psychotronika, UFO, astrologia, magia...
pl.misc.ratownictwo	Ratownictwo drogowe, pomoc przedmedyczna, drogi w Polsce.
pl.misc.samochody	Samochod nie tylko zza kolka.
pl.misc.samochody.garbusy	Uzytkownicy i milosnicy VW Garbusa.
pl.misc.telefonia	Telefonia, telefony - uslugi, przepisy, urzadzenia.
pl.misc.telefonia.gsm	Dyskusja o telefonii komorkowej GSM i pochodnych.
pl.misc.telefonia.gsm.gielda	Ogloszenia o kupnie/sprzedazy telefonow GSM.
pl.misc.telefonia.gsm.sms	Tekstowy serwis informacyjny.
pl.misc.telefonia.isdn	Cyfrowa Siec z Integracja Uslug - pytania, dyskusje.
pl.misc.telefonia.wap	Sluchawka on-line.
pl.misc.transport	O transporcie i logistyce.
pl.misc.transport.miejski	Komunikacja miejska dla fanow i uzytkownikow.
pl.news.admin	Administratorzy polskich news - laczcie sie! (Moderated) (Moderated)
pl.news.czytniki	Czytniki news - konfiguracja, uzytkowanie.
pl.news.nowe-grupy	Zakladanie nowych grup w hierarchii pl.*. (Moderated) (Moderated)
pl.ogloszenia.kupie	Ogloszenia o kupnie roznych rzeczy.
pl.ogloszenia.rozne	Ogloszenia rozne.
pl.ogloszenia.sprzedam	Ogloszenia o sprzedazy roznych rzeczy.
pl.praca.dyskusje	Dyskusje na temat pracy.
pl.praca.oferowana	Ogloszenia o pracy. (Moderated)
pl.praca.szukana	Ogloszenia o poszukiwaniu pracy.
pl.pregierz	Usenetowy pregierz publiczny.
pl.rec.akwarium	Akwarystyka.
pl.rec.anime	Grupa milosnikow anime, mangi i jezyka japonskiego.
pl.rec.ascii-art	Rysowanie znakami ASCII.
pl.rec.audio	Audio i Hi-Fi dla kazdego.
pl.rec.dom	Dom - budynek i miejsce w ktorym sie zyje.
pl.rec.fantastyka.advocacy	O wyzszosci jednych dziel fantastycznych nad innymi.
pl.rec.fantastyka.babylon5	Pozdrowienia z Babylonu 5.
pl.rec.fantastyka.film	Fantastyka na malym i duzym ekranie.
pl.rec.fantastyka.sf-f	Science Fiction & Fantasy, lista sf-f@uci.agh.edu.pl.
pl.rec.fantastyka.startrek	Wszystko dla fanow - filmy, seriale, ksiazki.
pl.rec.fantastyka.starwars	Gwiezdne Wojny: filmy, ksiazki, komiksy, gry w swiecie GW.
pl.rec.fantastyka.x-files	ONI nie pozwalaja na krotki opis.
pl.rec.film	Filmy w kinie, tv i na wideo.
pl.rec.film.animowany	Wszelkie filmy animowane - z wyjatkiem mangi.
pl.rec.foto	Fotografia - co, jak i czym.
pl.rec.foto.art	Fotografia jako Sztuka.
pl.rec.foto.cyfrowa	Sprzet, technika fotografowania i obrobki obrazu.
pl.rec.gory	Dyskusje o gorach i kwalifikowanej turystyce gorskiej.
pl.rec.gps	Satelitarny drogowskaz w sieci.
pl.rec.gry.brydz	Brydzysci po polsku o brydzu.
pl.rec.gry.go	Go, weiqi, baduk, czyli sztuka otaczania.
pl.rec.gry.karciane	Gry karciane oraz pasjanse.
pl.rec.gry.komputerowe	Rozkosze lamania glowy i joysticka.
pl.rec.gry.komputerowe.klasyka	Klasyka gier komputerowych.
pl.rec.gry.komputerowe.roguelike	Grimoiry tamtego swiata.
pl.rec.gry.komputerowe.rpg	Gry komputerowe z elementami RPG.
pl.rec.gry.komputerowe.sprzet	Sprzet przydatny graczom.
pl.rec.gry.konsole	Konsole do gier i gry na nie.
pl.rec.gry.mud		Dla graczy w MUDy.
pl.rec.gry.rpg		Gry RPG (Role Playing) bez komputera.
pl.rec.gry.scrabble	Dyskusje na temat gry Scrabble po polsku.
pl.rec.gry.strategiczne	Triumf umyslu nad slepa furia.
pl.rec.gry.szachy	Gimnastyka umyslu dla kazdego. (Moderated)
pl.rec.harcerstwo	Ogolnoswiatowa grupa dyskusyjna harcerstwa polskiego.
pl.rec.hihot	Wszystko do smiechu.
pl.rec.humor.kabaret	Scena kabaretowa - wczoraj i dzis.
pl.rec.humor.monty-python	A teraz cos z zupelnie innej beczki.
pl.rec.humor.najlepsze	Usenet na wesolo - znalezione w grupach pl.* (Moderated)
pl.rec.kajaki	Wiosla, kontry, pagaje.
pl.rec.kino-domowe	Po prostu kino w domu.
pl.rec.komiks	Grupa dla entuzjastow komiksu (i nie tylko).
pl.rec.ksiazki	Ksiazki, ktore warto (lub nie) przeczytac.
pl.rec.kuchnia	Uroki kuchni i rozkosze podniebienia.
pl.rec.lotnictwo	Ptakom podobni...
pl.rec.mineraly	Kolorowy swiat mineralow.
pl.rec.modelarstwo	Modele kartonowe, drewniane, plastikowe i inne.
pl.rec.motocykle	Motocykle - technika, rozrywka, turystyka.
pl.rec.muzyka	Wszystko o muzyce.
pl.rec.muzyka.bin	Muzyka w postaci binarnej.
pl.rec.muzyka.folk	Muzyka folkowa roznych kultur.
pl.rec.muzyka.gitara	Techniki gry na gitarze, tabulatury, rady, akordy, gitarzysci.
pl.rec.muzyka.gotyk	Muzyka gotycka i towarzyszaca jej otoczka.
pl.rec.muzyka.jazz	JAZZ we wszystkich kolorach teczy.
pl.rec.muzyka.klasyczna	Kameralnie i symfonicznie.
pl.rec.muzyka.koncerty	Ogloszenia i dyskusje o koncertach.
pl.rec.muzyka.metal	Artykuly metalowe.
pl.rec.muzyka.rock	Muzyka rockowa polska i zagraniczna.
pl.rec.muzyka.techno	Muzyka techno oraz informacje o imprezach.
pl.rec.nurkowanie	Nurkuj bracie pokis mlody!!!
pl.rec.ogrody	Ogrody ozdobne, warzywne, rekreacyjne, wodne, dydaktyczne.
pl.rec.paralotnie	Paralotnie, lotnie, szybowce i inne rozrywki latajace.
pl.rec.paranoja	Oni (i ONI) sa wszedzie.
pl.rec.radio	Radio, krotkofalarstwo itp.
pl.rec.radio.amatorskie	Krotkofalarstwo, packet radio, sport DX-owy.
pl.rec.radio.cb	CB-Radio - dyskusje techniczne, sprzet, ogloszenia.
pl.rec.robotki-reczne	Na drutach, szydelkiem, igla i nie tylko.
pl.rec.rowery	Rowery: sprzet, wyprawy, jazda w miescie.
pl.rec.sport	Dla kibicow i dla tych ktorzy sami uprawiaja sport.
pl.rec.sport.koszykowka	Koszykowka polska, europejska i NBA.
pl.rec.sport.kulturystyka	Trening, dieta, suplementacja.
pl.rec.sport.motorowe	Sporty motorowe.
pl.rec.sport.pilka-nozna	Grupa dla kibicow i sympatykow pilki noznej.
pl.rec.sport.siatkowka	Strefa siatkowki.
pl.rec.sport.tenis	Tenis na swiecie.
pl.rec.sport.zimowe	Snowboard, narty i inne zabawy na sniegu.
pl.rec.szaradziarstwo	Zadania diagramowe, graficzne, logiczne, wierszowane.
pl.rec.telewizja	Rozmowy milosnikow malego ekranu.
pl.rec.turystyka.tramping	Podrozowanie z plecakiem.
pl.rec.turystyka.zorganizowana	Wczasy z biurem podrozy.
pl.rec.uroda	Pielegnacja urody - teoria i praktyka.
pl.rec.wedkarstwo	Techniki polowu, przynety, sprzet, lowiska.
pl.rec.windsurfing	Windsurgfing i wszystko z nim zwiazane.
pl.rec.wspinaczka	Wspinaczka - przygoda, pasja, sport, sens zycia.
pl.rec.zbieractwo	Monety, karty telefoniczne, znaczki i inne kolekcje.
pl.rec.zeglarstwo	Zeglarze wod slonych i slodkich.
pl.rec.zeglarstwo.szanty	Szanty i piosenka zeglarska.
pl.rec.zwierzaki	Zwierzeta bedace naszymi przyjaciolmi.
pl.rec.zwierzaki.koty	KOTY. KOTY SA MILE.
pl.rec.zwierzaki.terrarium	Zwierzeta terraryjne i to co z nimi zwiazane.
pl.regionalne.gorny-slask	Gorny Slask, Zaglebie - pytania, komentarze, propozycje.
pl.regionalne.krakow	Krakowiaczek ci ja!
pl.regionalne.lodz	Forum mieszkancow miasta Lodzi i okolic.
pl.regionalne.lublin	Grupa mieszkancow i przyjaciol Lublina.
pl.regionalne.poznan	Poznan i okolice: Pyrlandia.
pl.regionalne.szczecin	Forum wymiany informacji o Szczecinie.
pl.regionalne.szczecin.ogloszenia	Ogloszenia dotyczace Szczecina i okolic.
pl.regionalne.trojmiasto	My, mieszkancy Trojmiasta!
pl.regionalne.warszawa	Wirtualna Warszawa - rozmowy, informacje.
pl.regionalne.warszawa.ogloszenia	Ogloszenia dotyczace Warszawy i okolic.
pl.regionalne.wroclaw	O Wroclawiu, nie tylko dla Wroclawian.
pl.sci.ai	Problematyka sztucznej inteligencji.
pl.sci.biologia	O rozlicznych genow manifestacjach.
pl.sci.chemia	Chemia czysta, technologia i inzynieria.
pl.sci.ekonomiczne	Nieznajomosc ekonomii szkodzi.
pl.sci.farmacja	Aptekarstwo, ziololecznictwo, analityka i chemia lekow.
pl.sci.filozofia	Miejsce spotkan filozofow (nie chlopskich).
pl.sci.fizyka	Forum fizykow polskich.
pl.sci.geodezja	Geodezja i kartografia.
pl.sci.historia	Ludzie i zdarzenia na przestrzeni wiekow. (Moderated) (Moderated)
pl.sci.inzynieria	Rozwiazujemy wszelkie inzynierskie zadania.
pl.sci.kosmos	Ogromny i pelen zagadek.
pl.sci.kosmos.seti	Poszukiwanie zycia poza Ziemia.
pl.sci.kosmos.seti	Poszukiwanie zycia poza Ziemia.
pl.sci.lesnictwo	O lesie i lesnikach, przyrodzie i ekologach.
pl.sci.matematyka	Zagadnienia krolowej nauk. (Moderated)
pl.sci.medycyna		Od pediatrii do patologii.
pl.sci.psychologia	Psychologia w zyciu codziennym.
pl.sci.socjologia	Socjologia i nauki pokrewne.
pl.sci.weterynaria	Leczenie zwierzat.
pl.soc.dekadentyzm	Antyspoleczne poglady, poezja, swirunki, kreacja.
pl.soc.dzieci	Jak miec dzieci i to przezyc.
pl.soc.dzieci.starsze	Do matury od przedszkola, ciezka jest rodzica dola.
pl.soc.edukacja	Edukacja i wychowanie od niemowlaka do umarlaka.
pl.soc.edukacja.szkola	Szkola i jej uzytkownicy - uczniowie.
pl.soc.genealogia	Poszukiwanie przodkow, historia rodow.
pl.soc.inwalidzi	Sieciowe forum osob niepelnosprawnych.
pl.soc.polityka		Dyskusje o polityce (lista polityka@mimuw.edu.pl).
pl.soc.polityka.wybory	Wybory i referenda w Polsce.
pl.soc.prawo	Prawo na co dzien - dyskusje, porady, opinie.
pl.soc.prawo.podatki	Podatki w Polsce.
pl.soc.religia	Dyskusje religijne (lista religia@uci.agh.edu.pl).
pl.soc.rodzina	Jak zyc w rodzinie i przetrwac.
pl.soc.savoir-vivre	Zasady kultury osobistej i ich zasadnosc.
pl.soc.seks	Wszystko o seksie (ale nie obrazki).
pl.soc.seks.moderowana	Kulturalnie o seksie i milosci. (Moderated)
pl.soc.seks.towarzyskie	"Biuro" ogloszen towarzyskich i matrymonialnych.
pl.soc.uroczystosci	Jak dobrze organizowac uroczystosci.
pl.soc.uzaleznienia	Uzaleznienia - jak zapobiegac, leczyc i walczyc. (Moderated)
pl.soc.wegetarianizm	Ideologia, a NIE przepisy.
pl.soc.zieloni	Polski ruch ekologiczny.
pl.test			Tu mozna wysylac wszelkie testy.
--- =--------------------------------------------------------------------

Plik active przedstawiony poniżej zawiera definicje wszystkich grup news
z hierarchii pl.*, które są aktywne na serwerze news.ict.pwr.wroc.pl,
co odzwierciedla dokładnie stan wszystkich grup pl.*, jakie istnieją.
Istotne są tak naprawdę dwie rzeczy -- nazwa grupy i jej 'stan':  "m" lub
"y".  Literka "m" na końcu opisu oznacza, że grupa jest moderowana, a więc
artykuły do niej wysyłane powinny trafiać e-mailem na adres moderatora
(jest to zawsze nazwa-grupy@usenet.pl, gdzie kropki w nazwie grupy
zamienione są na znaki '-').  Liczby pomiędzy nazwą grupy a 'm' lub 'y',
to najwyższy i najniższy numer artykułu na serwerze news.ict.pwr.wroc.pl
-- na innych serwerach będzie oczywiście inny, ale przy okazji daje to
pojęcie, jak dużo artykułów pojawia się w poszczególnych grupach.

### Plik active - aktualna lista grup news w hierarchii pl.*
=== ---------------------------------------------------------------------
pl.announce.newgroups 0000000829 0000000830 m
pl.answers 0000003255 0000003249 m
pl.biznes 0000177472 0000177312 y
pl.biznes.banki 0000522608 0000454273 y
pl.biznes.wgpw 0000473977 0000468639 y
pl.comp.bazy-danych 0000185525 0000185155 y
pl.comp.bazy-danych.msaccess 0000130727 0000130353 y
pl.comp.cad 0000053391 0000053342 y
pl.comp.demoscena 0000034096 0000034097 y
pl.comp.dtp 0000258666 0000240414 y
pl.comp.dtp.tex 0000016777 0000016744 y
pl.comp.dtp.tex.gust 0000025287 0000025238 m
pl.comp.gis 0000012333 0000012310 y
pl.comp.grafika 0000219773 0000219585 y
pl.comp.grafika.grafika3d 0000090530 0000090521 y
pl.comp.lang.asm 0000002140 0000002092 y
pl.comp.lang.c 0000285883 0000285281 y
pl.comp.lang.delphi 0000323925 0000323150 y
pl.comp.lang.delphi.bazy-danych 0000076860 0000076657 y
pl.comp.lang.funkcyjne 0000000946 0000000947 y
pl.comp.lang.java 0000149210 0000148930 y
pl.comp.lang.javascript 0000049213 0000049152 y
pl.comp.lang.pascal 0000092592 0000092578 y
pl.comp.lang.perl 0000051678 0000051619 y
pl.comp.lang.php 0000220311 0000211076 y
pl.comp.lang.python 0000027104 0000027013 y
pl.comp.lang.ruby 0000001290 0000001290 y
pl.comp.lang.tcl 0000000582 0000000582 y
pl.comp.lang.vbasic 0000103355 0000103286 y
pl.comp.mail 0000068329 0000068283 y
pl.comp.mail.mta 0000058527 0000058442 y
pl.comp.multimedia 0000033256 0000033254 y
pl.comp.nowe-programy 0000222764 0000222394 y
pl.comp.objects 0000018800 0000018800 y
pl.comp.ogonki 0000020560 0000020559 y
pl.comp.os.advocacy 0000473542 0000472576 y
pl.comp.os.bsd 0000021184 0000019410 y
pl.comp.os.linux 0000871833 0000870958 y
pl.comp.os.linux.debian 0000040789 0000040717 y
pl.comp.os.linux.programowanie 0000071316 0000071283 y
pl.comp.os.linux.sieci 0000239900 0000239686 y
pl.comp.os.linux.sprzet 0000073463 0000073413 y
pl.comp.os.ms-windows.vista 0000007218 0000007071 y
pl.comp.os.ms-windows.win3 0000005748 0000005747 y
pl.comp.os.ms-windows.win9x 0000160081 0000160080 y
pl.comp.os.ms-windows.winnt 0000221780 0000206230 y
pl.comp.os.ms-windows.xp 0000005648 0000005357 y
pl.comp.os.os2 0000033884 0000033885 y
pl.comp.os.unix 0000027150 0000027151 y
pl.comp.pecet 0001198514 0001153860 y
pl.comp.programming 0000188055 0000182422 y
pl.comp.security 0000064769 0000064698 m
pl.comp.sieci 0000043854 0000031151 y
pl.comp.sieci.bezprzewodowe 0000016371 0000016305 y
pl.comp.sys.amiga 0000066501 0000066498 y
pl.comp.sys.atari 0000037051 0000037047 y
pl.comp.sys.macintosh 0000130492 0000130410 y
pl.comp.sys.novell 0000130664 0000130649 y
pl.comp.sys.palmtop 0000011479 0000011472 y
pl.comp.sys.palmtop.palmos 0000009862 0000009860 y
pl.comp.sys.sun.admin 0000015911 0000015912 y
pl.comp.sys.x11 0000002211 0000002212 y
pl.comp.tlumaczenia 0000007340 0000007341 m
pl.comp.www 0000401328 0000393671 y
pl.comp.www.nowe-strony 0000217161 0000217049 y
pl.comp.www.server-side 0000061060 0000060641 y
pl.comp.xml 0000010131 0000010130 y
pl.fidonet.bramka 0000006768 0000006769 y
pl.gazety.donosy 0000003697 0000003678 m
pl.hum.pisarstwo 0000018603 0000018577 y
pl.hum.poezja 0000248650 0000242280 y
pl.hum.polszczyzna 0000118746 0000118479 y
pl.hum.teatr 0000005040 0000005035 y
pl.hum.tlumaczenia 0000251362 0000244918 y
pl.hum.x-muza 0000030282 0000030280 y
pl.internet.komunikaty 0000014297 0000014297 m
pl.internet.mordplik 0000040295 0000040061 y
pl.internet.polip 0000092187 0000091992 y
pl.internet.pomoc 0000018927 0000018911 y
pl.irc 0000145317 0000145318 y
pl.listserv.chomor-l 0000165399 0000165339 y
pl.listserv.dziennikarz 0000059344 0000059344 y
pl.listserv.plotki 0000186178 0000186114 y
pl.listserv.polwro 0000004024 0000004025 y
pl.misc.budowanie 0000390409 0000333245 y
pl.misc.dieta 0000060762 0000060732 y
pl.misc.elektronika 0000584913 0000545961 y
pl.misc.kolej 0000820867 0000718569 y
pl.misc.konsumenci 0000011037 0000011027 y
pl.misc.meteorologia 0000027960 0000027831 y
pl.misc.militaria 0000433785 0000404864 y
pl.misc.paranauki 0000205906 0000205711 y
pl.misc.ratownictwo 0000016000 0000016001 y
pl.misc.samochody 0002275884 0001979201 y
pl.misc.samochody.garbusy 0000193612 0000193513 y
pl.misc.telefonia 0000231707 0000226170 y
pl.misc.telefonia.gsm 0000992210 0000956660 y
pl.misc.telefonia.gsm.gielda 0000223498 0000223489 y
pl.misc.telefonia.gsm.sms 0000068858 0000068856 y
pl.misc.telefonia.isdn 0000038741 0000038741 y
pl.misc.telefonia.wap 0000001989 0000001990 y
pl.misc.transport 0000098988 0000098986 y
pl.misc.transport.miejski 0000226025 0000208198 y
pl.news.admin 0000029473 0000029458 m
pl.news.czytniki 0000100603 0000100585 y
pl.news.nowe-grupy 0000096749 0000096740 m
pl.ogloszenia.kupie 0000142750 0000142723 y
pl.ogloszenia.rozne 0000234399 0000234242 y
pl.ogloszenia.sprzedam 0000504544 0000504221 y
pl.praca.dyskusje 0000233953 0000233616 y
pl.praca.oferowana 0000074529 0000074363 m
pl.praca.szukana 0000134114 0000133893 y
pl.pregierz 0001771418 0001498807 y
pl.rec.akwarium 0000595975 0000595408 y
pl.rec.anime 0000131573 0000131556 y
pl.rec.ascii-art 0000036718 0000036698 y
pl.rec.audio 0000130590 0000130440 y
pl.rec.dom 0000118648 0000110135 y
pl.rec.fantastyka.advocacy 0000009593 0000009594 y
pl.rec.fantastyka.babylon5 0000027929 0000027928 y
pl.rec.fantastyka.film 0000000600 0000000595 y
pl.rec.fantastyka.sf-f 0000643842 0000603809 y
pl.rec.fantastyka.startrek 0000056583 0000056584 y
pl.rec.fantastyka.starwars 0000166723 0000166620 y
pl.rec.fantastyka.x-files 0000047612 0000047613 y
pl.rec.film 0000384173 0000374293 y
pl.rec.film.animowany 0000007660 0000007661 y
pl.rec.foto 0000805050 0000784144 y
pl.rec.foto.art 0000058905 0000058881 y
pl.rec.foto.cyfrowa 0000845747 0000748165 y
pl.rec.gory 0000289633 0000273388 y
pl.rec.gps 0000084706 0000074137 y
pl.rec.gry.brydz 0000065851 0000065846 y
pl.rec.gry.go 0000002190 0000002191 y
pl.rec.gry.karciane 0000084754 0000084754 y
pl.rec.gry.komputerowe 0000759619 0000730832 y
pl.rec.gry.komputerowe.klasyka 0000095961 0000095936 y
pl.rec.gry.komputerowe.roguelike 0000033264 0000033265 y
pl.rec.gry.komputerowe.rpg 0000110598 0000110583 y
pl.rec.gry.komputerowe.sprzet 0000305410 0000305396 y
pl.rec.gry.konsole 0000346561 0000324822 y
pl.rec.gry.mud 0000015319 0000015320 y
pl.rec.gry.rpg 0000153019 0000153020 y
pl.rec.gry.scrabble 0000023468 0000023469 y
pl.rec.gry.strategiczne 0000077884 0000077885 y
pl.rec.gry.szachy 0000025811 0000025812 m
pl.rec.harcerstwo 0000035730 0000035726 y
pl.rec.hihot 0000495275 0000495150 y
pl.rec.humor.kabaret 0000027327 0000027321 y
pl.rec.humor.monty-python 0000193958 0000193877 y
pl.rec.humor.najlepsze 0000036972 0000036941 m
pl.rec.kajaki 0000048392 0000047535 y
pl.rec.kino-domowe 0000218240 0000218089 y
pl.rec.komiks 0000037725 0000037726 y
pl.rec.ksiazki 0000141261 0000141113 y
pl.rec.kuchnia 0000325999 0000325580 y
pl.rec.lotnictwo 0000133752 0000128382 y
pl.rec.mineraly 0000006387 0000006388 y
pl.rec.modelarstwo 0000192728 0000192698 y
pl.rec.motocykle 0000621896 0000579184 y
pl.rec.muzyka 0000153028 0000153009 y
pl.rec.muzyka.bin 0000202681 0000202638 y
pl.rec.muzyka.folk 0000009758 0000009758 y
pl.rec.muzyka.gitara 0000383185 0000368201 y
pl.rec.muzyka.gotyk 0000020337 0000020332 y
pl.rec.muzyka.jazz 0000031307 0000031303 y
pl.rec.muzyka.klasyczna 0000006672 0000006657 y
pl.rec.muzyka.koncerty 0000010979 0000010979 y
pl.rec.muzyka.metal 0000160587 0000160577 y
pl.rec.muzyka.rock 0000180941 0000180937 y
pl.rec.muzyka.techno 0000180780 0000180781 y
pl.rec.nurkowanie 0000197059 0000196484 y
pl.rec.ogrody 0000226753 0000226368 y
pl.rec.paralotnie 0000293958 0000290371 y
pl.rec.paranoja 0000248161 0000247814 y
pl.rec.radio 0000049327 0000049328 y
pl.rec.radio.amatorskie 0000093110 0000092452 y
pl.rec.radio.cb 0000091535 0000086326 y
pl.rec.robotki-reczne 0000108868 0000108822 y
pl.rec.rowery 0001035631 0000967063 y
pl.rec.sport 0000033901 0000033901 y
pl.rec.sport.koszykowka 0000149247 0000148869 y
pl.rec.sport.kulturystyka 0000000473 0000000474 y
pl.rec.sport.motorowe 0000040591 0000040576 y
pl.rec.sport.pilka-nozna 0000536506 0000526108 y
pl.rec.sport.siatkowka 0000006998 0000006999 y
pl.rec.sport.tenis 0000020712 0000020711 y
pl.rec.sport.zimowe 0000151388 0000150990 y
pl.rec.szaradziarstwo 0000010321 0000010322 y
pl.rec.telewizja 0000259139 0000254580 y
pl.rec.turystyka.tramping 0000149222 0000140429 y
pl.rec.turystyka.zorganizowana 0000064173 0000064081 y
pl.rec.uroda 0000150877 0000150869 y
pl.rec.wedkarstwo 0000098058 0000097906 y
pl.rec.windsurfing 0000195508 0000195410 y
pl.rec.wspinaczka 0000013837 0000013836 y
pl.rec.zbieractwo 0000008421 0000008418 y
pl.rec.zeglarstwo 0000379042 0000348677 y
pl.rec.zeglarstwo.szanty 0000032177 0000032175 y
pl.rec.zwierzaki 0000245167 0000245034 y
pl.rec.zwierzaki.koty 0000044580 0000044500 y
pl.rec.zwierzaki.terrarium 0000016347 0000016348 y
pl.regionalne.gorny-slask 0000138364 0000138163 y
pl.regionalne.krakow 0000446965 0000421117 y
pl.regionalne.lodz 0000174205 0000173803 y
pl.regionalne.lublin 0000317470 0000317241 y
pl.regionalne.poznan 0000385079 0000380249 y
pl.regionalne.szczecin 0000220227 0000219900 y
pl.regionalne.szczecin.ogloszenia 0000125908 0000121452 y
pl.regionalne.trojmiasto 0000261696 0000261418 y
pl.regionalne.warszawa 0000544079 0000489848 y
pl.regionalne.warszawa.ogloszenia 0000191647 0000191472 y
pl.regionalne.wroclaw 0000595528 0000550310 y
pl.sci.ai 0000010654 0000010654 y
pl.sci.biologia 0000050886 0000042196 y
pl.sci.chemia 0000063748 0000063688 y
pl.sci.ekonomiczne 0000040100 0000040101 y
pl.sci.farmacja 0000007579 0000007580 y
pl.sci.filozofia 0000200415 0000193698 y
pl.sci.fizyka 0000217634 0000213315 y
pl.sci.geodezja 0000013429 0000013426 y
pl.sci.historia 0000103141 0000103010 m
pl.sci.inzynieria 0000026004 0000025768 y
pl.sci.kosmos 0000175451 0000174680 y
pl.sci.kosmos.seti 0000023249 0000023250 y
pl.sci.lesnictwo 0000003746 0000003746 y
pl.sci.matematyka 0000146430 0000146393 m
pl.sci.medycyna 0000261558 0000261288 y
pl.sci.psychologia 0000525423 0000417945 y
pl.sci.socjologia 0000017920 0000017920 y
pl.sci.weterynaria 0000021256 0000021253 y
pl.soc.dekadentyzm 0000067028 0000067019 y
pl.soc.dzieci 0000576017 0000571736 y
pl.soc.dzieci.starsze 0000066414 0000058836 y
pl.soc.edukacja 0000026704 0000026701 y
pl.soc.edukacja.szkola 0000057176 0000057036 y
pl.soc.genealogia 0000024927 0000024927 y
pl.soc.inwalidzi 0000054897 0000054858 y
pl.soc.polityka 0001575548 0001277969 y
pl.soc.polityka.wybory 0000030892 0000030882 y
pl.soc.prawo 0000634203 0000548931 y
pl.soc.prawo.podatki 0000221503 0000220525 y
pl.soc.religia 0000968690 0000892318 y
pl.soc.rodzina 0000095141 0000095139 y
pl.soc.savoir-vivre 0000049339 0000049335 y
pl.soc.seks 0000687750 0000687731 y
pl.soc.seks.moderowana 0000084311 0000084312 m
pl.soc.seks.towarzyskie 0000358841 0000358841 y
pl.soc.uroczystosci 0000000765 0000000764 y
pl.soc.uzaleznienia 0000005298 0000005299 m
pl.soc.wegetarianizm 0000123956 0000123955 y
pl.soc.zieloni 0000015411 0000015405 y
pl.test 0000666467 0000666027 y
--- ---------------------------------------------------------------------

Posted-By: auto-faq 3.1.1.2
Archive-name: news-pl-faq/part4


                Szablon zgłoszenia propozycji nowej grupy pl.*
                                       
   Sposób przeprowadzania głosowań w sprawie tworzenie nowych grup w
   hierarchii pl.* opisany jest w pierwszej części FAQ, tutaj natomiast
   znajduje się wyłącznie szablon formularza służącego do wygenerowania
   listu RFD (Request for Discussion), wysyłanego do grupy
   pl.news.nowe-grupy w celu rozpoczęcia dyskusji nad powstaniem grupy, a
   następnie CFV (Call for Votes) rozpoczynającego ostateczne głosowanie,
   którego celem jest weryfikacja sensu zakładania grupy.
   
   Szablonu tego należy także użyć do pierwszego zgłoszenia chęci
   założenia grupy, wypełniając cały formularz lub jego część i wysyłając
   do pl.news.nowe-grupy, a temat takiego listu powinien brzmieć
   'Propozycja: pl.xx.yyy.zzz' lub 'Propozycja: grupa o XXXXXX'. Taki
   formularz może być niekompletny, bo celem wysłania go publicznie do
   pl.news.nowe-grupy jest właśnie uzgodnienie z innymi wszelkich
   niejasności, takich jak dokładna nazwa grupy, opis itp. Propozycje
   zgłaszane publicznie mogą być formułowane w dowolny sposób, jednak
   jeśli ma się rozpocząć głosowanie nad grupą, propozycja CFV
   umieszczana w serwisie http://42.pl/cfv/ MUSI być wypełniona jak
   poniżej, dlatego lepiej to zrobić od razu, wysyłając najpierw wersję
   być może niekompletną, tzn. z niektórymi polami pozostawionymi bez
   wypełniania lub z uwagą "kto ma dobry pomysł?" itp., a potem
   wprowadzając poprawki zgłaszane przez innych dyskutantów.
   
   Jeżeli wszystkie dane dotyczące powstania grupy, takie jak jej nazwa,
   jednolinijkowy opis (*NIE* zaczynający się od 'Wszystko o...', 'Forum
   dyskusyjne takich a siakich', itp.) oraz opis dłuższy (przynajmniej
   3-4 zdania o tym, co będzie tematyką grupy, co w grupie NIE POWINNO
   się znaleźć, itp.), informacja o tym, czy grupa ma być moderowana, czy
   nie, a jeśli tak, to adres moderatora, to pomysłodawca powstania grupy
   powinien zredagować odpowiedni tekst (wzorzec zamieszczony poniżej) i
   umieścić go pod adresem http://42.pl/cfv. Aby móc zamieścić pod tym
   adresem swoje RFD (mające zostać przyszłym CFV) należy najpierw
   założyć sobie tam konto -- odbywa się to prosto i bezboleśnie, a hasło
   do konta wysyłane jest e-mailem.
   
   Jeżeli jeszcze istnieją jakieś wątpliwości dotyczące powyższych
   danych, to najpierw należy je wyjaśnić na forum grupy, a dopiero potem
   zredagować CFV i umieścić je pod wspomnianym adreesem. Jeżeli istnieją
   alternatywne propozycje nazwy grupy lub zostaną nadesłane np. 2 różne
   propozycje CFV tej samej lub podobnych grup, to CFV nie zostaje
   wysłane, lecz dyskusja wraca jako RFD (Request for Discussion) do
   grupy pl.news.nowe-grupy. Podobnie - jeśli na http://42.pl/cfv zostaną
   zgłoszone zastrzeżenia powodujące wstrzymanie procedury (status
   zmienia się na "do poprawienia"), wszelkie nieoczywiste sprawy należy
   dyskutować na łamach pl.news.nowe-grupy.
   
   Proponowana nazwa grupy musi spełniać kilka wymagań technicznych:
     * W nazwie mogą występować jedynie małe litery alfabetu łacińskiego,
       kropka, minus, plus i cyfry ([-+.0-9a-z])
     * Każdy człon nazwy (pomiędzy kropkami) nie może być dłuższy niż 14
       znaków i musi się zaczynać od litery.
     * Pierwszy człon to oczywiście 'pl', następnie nazwa odpowiedniej
       podhierarchii, np. 'comp', 'news', 'rec' itp. Należy starać się
       dopasować grupę do już istniejących hierarchii. Tworzenie nowych
       hierarchii będzie następowało jedynie w uzasadnionych i głęboko
       umotywowanych przypadkach. Tworzenie pojedynczych grup
       bezpośrednio w hierarchii pl.* jest praktycznie niemożliwe.
     * Jeśli proponowana jest nazwa n-członowa, to w momecie
       rozpoczynania głosowania (n-1) poziom już powinien istnieć w
       hierarchii pl. Przykładowo, jeśli istnieje już 'pl.comp.os', to
       można zaproponować 'pl.comp.os.lamerix' ale nie
       'pl.comp.os.lamerix.wersja2'. Czyli najpierw musi powstać grupa
       (lub hierarchia) "ogólniejsza", a dopiero gdy grupa wystarczająco
       się ożywi, można dokonać jej podziału na mniejsze i bardziej
       sprecyzowane.
       
   Propozycje RFD/CFV pozostawiane pod adresem http://42.pl/cfv są
   publicznie dostępne -- każdy może je obejrzeć, a także (po
   zarejestrowaniu się w serwisie) - złożyć zastrzeżenia (jednak
   ewentualna dyskusja z zastrzeżeniami powinna odbywać się w
   pl.news.nowe-grupy). Jeśli po około 2-3 tygodniach od zamieszczenia
   propozycji RFD/CFV (lub ostatniej wesj RFD/CFV, jeśli wprowadzane były
   poprawki) nie ma żadnych poważnych wątpliwości dotyczących
   nazwy/opisu/zawartości grupy, to status CFV zostaje zmieniony na "do
   głosowania" i w niedługim czasie rozpoczyna się głosowanie nad
   powstaniem grupy, zmianą statusu czy inną modyfikacją, której dotyczy
   to CFV.
   
   Przed rozpoczęciem wypełniania poniższego szablonu zastanów się też
   przez chwilę skąd wziąłeś tekst, który właśnie czytasz i czy na pewno
   jest on aktualny. Jeśli nagrałeś go sobie jakiś czas temu z internetu
   lub skopiowałeś z jakiegoś CD-ROMu z kompilacją internetowych stron,
   to może on być nieaktualny. Sprawdź datę znajdującą się na końcu i
   jeśli twoja wersja jest starsza niż 2-3 miesiące, to koniecznie
   ściągnij aktualną wersję bezpośrednio ze strony WWW podanej na końcu.
   
   A teraz aktualny 'wzorzec' co jest potrzebne. W wersji ostatecznej
   zmienić należy wszystkie XXX (pozostawiając wpisany tekst w tej samej
   linii, w której znajduje się nazwa pola zakończona dwukropkiem),
   usunąć wszystkie [komentarze] oznaczone nawiasami kwadratowymi, ew.
   tam, gdzie z tych komentarzy tak wynika, zamienić [TAK/NIE] itp. na
   odpowiedni tekst, usuwając rzecz jasna same nawiasy. Pozostałe rzeczy
   zostawić bez zmian.
   
   W liście grup należy wpisać grupy news, do których ma trafić CFV,
   czyli grupy, w których znajdzie się potencjalnie najwięcej
   zainteresowanych powstaniem nowej grupy. Grup tych nie powinno być
   więcej niż 6, a ich lista jest propozycją i może zostać zmieniona,
   jeśli tematyka proponowanej nowej grupy jest zbyt odległa od tematyki
   grupy, w której ma nastąpić ogłoszenie. Jeżeli po wysłaniu CFV autor
   jego propozycji jest nadal innego zdania, to może sam wysłać
   informację o głosowaniu do `spornych' grup.
   
   Oprócz opisu grupy można opcjonalnie umieścić fragment rozpoczynający
   się słowem "Uzasadnienie:", służący przekazaniu komentarzy, które
   także pojawią się w CFV, ale nie stanowią opisu grupy lecz cel tego
   głosowania - na przykład podział grupy na podgrupy, zmianę nazwy,
   wyodrębnienie grupy dlatego, że w grupie głównej jest wystarczająco
   wiele artykułów, by utworzyć nową, itp. itd.
   
   Ostatnia uwaga: proszę NIE wysilać się nad specjalnym, "ładnym"
   formatowaniem tekstu -- np. uzupełnianie tekstu spacjami, by wszystkie
   'odpowiedzi' zaczynały się w jednej kolumnie. Wszystkie linie będące
   kontynuacją linii poprzedniej powinny zaczynać się od kolumny nr 1, a
   tekst powinien być "normalnym" tekstem, jakie wysyłane są pocztą czy w
   usenet news -- bez żadnych <HTMLodziwolągów> i najlepiej do 80 znaków
   w linii. Jedynie w dłuższych opisach formatowanie tekstu *czasem* może
   być istotne, a w pozostałych polach tylko utrudnia przygotowanie
   ostatecznego CFV.
   
-----------------RFD--(Request for Discussion)------------------
Nazwa grupy: XXX

[grupa pl.xxx.xxxx, nazwa może zawierać wyłącznie znaki "a-z", "0-9",
"." (kropka) i "-" (minus), każdy człon musi zaczynać się od litery i
nie może być dłuższy niż 14 znaków]

Krotki opis: XXX

[Opis powinien być po polsku, ale nie zawierać polskich znaków
diakrytycznych, mieścić się w jednej linijce, kończyć się kropką,
wykrzyknikiem lub pytajnikiem i dodatkowo spełniać wymaganie, że
długość nazwy grupy zaokrąglona w górę do 16,24,32...  plus długość opisu
nie przekracza 80 znaków -- Po ludzku: aby zweryfikować, czy opis nie
jest zbyt długi, wpisz nazwę grupy, naciśnij tabulator, wpisz opis --
wszystko powinno się zmieścić w jednej, 80-znakowej, linii)]

Moderowana: [TAK/NIE]
Moderator: [adres e-mail, jeśli grupa ma być moderowana]

Opis: XXX
XXX
...

[Dłuższy opis - najlepiej, gdy po prostu "od siebie" zdefiniujesz
czemu służyć ma grupa i czego mają dotyczyć dyskusje.  Pamiętaj też,
że ten tekst ma zachęcić ludzi do głosowania nad powstaniem grupy
- zbytnie zawężenie (albo rozszerzenie :-) ), a czasem niewłaściwe
sformułowanie tematyki może spowodować, że zagłosują przeciw. W opisie
powinieneś przede wszystkim zdefiniować tematykę grupy, ale także
tematy zabronione (bo są inne grupy na ten temat), czy w NAJBLIŻSZEJ
przyszłości są planowane podgrupy (ale tylko te najbardziej realne,
a nie wszystkie możliwe), jeśli tak, to jakie i kiedy, jeśli grupa
ma być sprzężona z jakąś listą e-mail, to jaką, gdzie jest/będzie
bramka.  Warto też umotywować pomysł utworzenie grupy, dla kogo
ona będzie (wszystkich, 'zaawansowanych', 'początujących', itp.),
dodatkowe ograniczenia/zalecenia obowiązujące w grupie, jak się to
ma do innych (już istniejących) grup, itp. Opis kończy się linią
'Autor propozycji:' Do opisu tego 'odgórnie' może zostać doklejona
także mini-etykieta grup pl.* mówiąca o zakazie wysyłania binariów,
spamów, ogłoszeń reklamowych nie związanych ściśle z tematem listy
itp.  Opis pisz w czasie teraźniejszym i z użyciem polskich znaków
diakrytycznych, gdyż w przypadku utworzenia grupy staje się on
obowiązującym opisem grupy i na ten właśnie opis można się powoływać,
by niektórych uczestników grupy czasem upomnieć, gdy zbyt daleko
zbaczają od tematu.]

Uzasadnienie:
XXX
[Informacja "sankcjonująca" celowość tego głosowania.  Dlaczego grupa
jest potrzebna, albo dlaczego podział grupy jest potrzebny, ile listów
związanych z tą tematyką pojawiało się dotąd, itp.  W przypadkach
specjalnych (podział grupy, zmiana nazwy, zmiana statusu na moderowaną
lub odwrotnie, itp. - w tym miejscu można umieścić komentarze tłumaczące
przyczynę zmian]

Autor propozycji: [adres@email (Imię Nazwisko)]

[adres email/imię+nazwisko osoby ogłaszającej.  Adres ten zostanie
podany jako adres kontaktowy w sprawach MERYTORYCZNYCH dotyczących
propozycji powstania grupy.  Tam też będą kierowane pytania, gdyby
np. nadeszły 2 propozycje CFV lub występowały wątpliwości co do
nazwy, itp.].

Ogloszenie:
pl.news.nowe-grupy
pl.announce.newgroups
pl.XXX.XXX
XXX@XXX.XXX [adres listy]  xxx@xxx.xxx [adres listy lub osoby]

[Do jakich grup news oraz na jakie listy dyskusyjne należy wysłać
ogłoszenie o rozpoczęciu głosowania.  Grup news nie powinno być więcej
niż 6 (w tym pl.news.nowe-grupy i pl.announce.newgroups). W przypadku
list dyskusyjnych powinien zostać podany adres listy lub osoby, która
wyśle CFV na listę dyskusyjną.
Podanie adresu osoby oznacza, że w CFV pojawi się jedynie
informacja o tym, że CFV zostaje wysłane na tę listę, ale czynność
wysłania musi zostać dokonana przez autora propozycji (dostanie on kopię
CFV gotową do wysłania na listę w momencie ogłaszania głosowania). Jest
to konieczne w przypadku list moderowanych, oraz takich, które pozwalają
wysyłać email tylko osobom zapisanym na listę.  Jeżeli podany został
adres listy, to listserv musi przyjmować i rozsyłać listy od osób nie
będących subskrybentami tej konkretnej listy dyskusyjnej.]

Czas trwania: [Tydzien - XXX dni - Dwa tygodnie]

[Tydzień jest minimalnym czasem trwania i chyba na razie optymalnym.
Można ustalić czas dłuższy, ale nie więcej niż 2 tygodnie. Podany
czas może zostać nieznacznie zwiększony (ew. minimalnie zmniejszony).
Głosowania z reguły są kończone w piątek lub poniedziałek.]
 -----------------RFD-KONIEC-------------------------

   Chyba tyle. Jeśli o czymś zapomniałem, to uzupełnię w następnej
   wersji.
   
   I jeszcze raz, po raz ostatni: Propozycja jak powyżej musi najpierw
   zostać przedyskutowana w grupie pl.news.nowe-grupy, a dopiero potem
   może trafić na http://42.pl/cfv. Działający dotąd niezbyt skutecznie
   sposób z wysyłaniem CFV na adres cfv@usenet.pl przestaje obowiązywać.
   
   Uwagi co do powyższych raczej emailem do mnie, ew. w grupie
   pl.news.nowe-grupy...
   
   Tomasz Surmacz
   
   Przykładowy wypełniony formularz:
   
-----------------RFD--------------------------------
Nazwa grupy: pl.misc.diploki
Krotki opis: O wyzszosci Diplokow nad Triplokami.

Moderowana: NIE

Opis: Grupa poświęcona fascynującemu zagadnieniu, jakim są Diploki,
ich zwyczaje, życie, codzienne zachowanie oraz wpływ na jasność
świecenia Księżyca w ostatniej kwadrze.

Możliwe jest także wspominanie o Triplokach, aczkolwiek tylko w
kontekście pejoratywnym, zgodnie z opisem grupy.

Przykładowe zagadnienia mieszczące się w tematyce grupy:

- Zwyczaje godowe Diploków.  Opisywane zarówno przez fachowców, jak i
  obserwatorów-amatorów.

- "Diplodospotting" - relacje z miejsc, w których udało się
  zauważyć Diploki. Szczególnie wartościowe są oczywiście relacje
  naocznych świadków, a raczej niepożądane spekulacje prowadzące
  niechybnie do nagłego rozrastania się wątków i eskalacji wrogości.

- Sposoby ochrony Diploków przed wyginięciem.

Przykładowe zagadnienia nie mieszczące się w tematyce grupy:

- "Ile Diploków mieści się na główce szpilki?" - To i podobne pytania,
  wskazują na zupełnie niepoważne podejście do zagadnienia kogoś. kto Diploka
  nigdy sam nie widział, a "czego nie widać, tego nie ma".  Problemem
  hodowli usenetowych trolli zajmują się inne grupy w hierarchii pl.*,
  dlatego nie ma dla nich miejsca w grupie pl.misc.diploki.

- "Mój Diplok jest [większy/mniejszy] niż twój". - Takie stwierdzenia
  z reguły prowadzą do wzrostu stosunku szumu do użytecznych
  informacji wysyłanych w ramach grupy i niepotrzebnego podnoszenia
  napięcia oraz tzw. "flame wars".

- "Mam [pytona/inną gadzinę]. Czy Diploki będą dobrym zastępstwem
  królików?" - To grupa o Diplokach, a nie o pytonach. Poza tym do tak
  barbarzyńskich celów lepiej nadają się Triploki, a o tych nie należy
  raczej wspominać.

Tematy zabronione: Pentiaki (zwane czasem Pętakami) i Fufloki.
Ich istnienie jest przyczyną nieustających wojen religijnych i
niekończących się wątków, których w tej grupie być nie powinno.

Unikać też należy tzw. "flame wars" - listów nie wnoszących wiele
merytorycznie, a tylko podgrzewających dyskusję, skupiając się zwykle na
mało istotnych faktach lub stwierdzeniach przedpiśćcy. Wyrażanie niechęci
do współdyskutanta powinno ograniczać się do robienia dezaprobujących
min podczas wysyłania swoich artykułów.  Można także za pomocą palców
nie używanych właśnie do naciskania ENTER wykonywać gesty uznawane
powszechnie za obraźliwe. I tyle.

Zabronione jest także wysyłanie listów zawierających jakiekolwiek
binaria -- programów/zdjęć itp, jakikolwiek spam oraz dyskusje nie
związane z tematem grupy.  Nie jest to także miejsce na ogłoszenia
reklamowe, nawet jeśli są związane z tematem grupy.  Dopuszczalne są
pojedyncze ogłoszenia dotyczące ofert wymiany gadżetów związanych z
Triplokami, jednak powtarzające się ogłoszenia będą traktowane jak spam.

Autor propozycji: diplok@diplandia.org.pl

Ogloszenie:
pl.news.nowe-grupy
pl.announce.newgroups
pl.rec.fantastyka.sf-f
pl.rec.zwierzaki

Czas trwania: dwa tygodnie
 -----------------RFD-KONIEC-------------------------
     _________________________________________________________________
   
   Najnowszą wersję powyższego tekstu można znaleźć pod adresem
   http://www.usenet.pl/doc/news-pl-faq.4.htpl
     _________________________________________________________________
   
   Część pierwsza FAQ - ogólne informacje o grupach pl.*
   Część druga FAQ - Konfiguracja serwerów news w Polsce
   Część trzecia FAQ - Lista istniejących grup pl.*
   Część czwarta FAQ - Formularz głosowania nad nowymi grupami pl.*
   
   FAQ po angielsku, dla administratorów serwerów news poza Polską
   (FAQ to zawiera także listę serwerów poza Polską, na których można
   znaleźć grupy pl.*)
     _________________________________________________________________
   
   
    Tomasz R. Surmacz (tsurmacz%adm.usenet.pl) 12.10.2007
    RCS ID: $Id: news-pl-faq.4.htpl,v 3.6 2007/10/12 20:51:24 tsurmacz
    Exp tsurmacz $
     _________________________________________________________________
   
   [This site is vi powered!] (c) 1994-2007 Tomasz R. Surmacz
   
   Kopirajt i disclajmer:
   
   Powyższy tekst może być w niezmienionej postaci i w całości (wszystkie
   części FAQ), bez ograniczeń kopiowany i drukowany *na własny użytek*,
   przekazywany przez news, e-maila, umieszczany w sieci Internet na
   serwerach WWW, FTP itp. itd.), pod warunkiem przechowywania aktualnej
   wersji (nie starszej niż 2-3 miesiące). Publikowanie tego tekstu w
   inny sposób lub dokonywanie w nim modyfikacji oraz rozprowadzanie
   zmienionej wersji wymaga zgody autora. Autor automatycznie udziela
   takiej zgody odnośnie szablonu głosowania (RFD/CFV).
   
   Aktualna wersja całości FAQ znajduje się zawsze pod adresem
   http://www.usenet.pl/doc/news-pl-faq.htpl i
   http://www.ict.pwr.wroc.pl/doc/news-pl-faq.htpl
   
   Autor niniejszego FAQ stara się, by wszelkie przedstawione w nim
   informacje były aktualne, ale gwarantować tego nie jest w stanie.
   Jeśli po przeczytaniu tego dalej nic nie rozumiesz, program tin czyta
   konfigurację z jakiegoś dziwnego pliku, albo twój ulubiony serwer news
   właśnie się na ciebie obraził, - sorry!, C'est la vie... Jeśli błąd
   jest w tekście - napisz do mnie - może poprawię