All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Polish FAQ update.
@ 2003-06-26 14:02 Maciej Soltysiak
  2003-06-27 23:25 ` Fabrice MARIE
  0 siblings, 1 reply; 5+ messages in thread
From: Maciej Soltysiak @ 2003-06-26 14:02 UTC (permalink / raw)
  To: netfilter-devel

Hello,

this patch:
- adds a missing section 3.17
- adds the translated section 3.18 about REJECT
- corrects typos
- introduces smoother and less crappy jargon-like vocabulary.

Please apply.

Regards,
Maciej

Index: netfilter-faq.sgml
===================================================================
RCS file: /cvspublic/netfilter/documentation/FAQ/pl/netfilter-faq.sgml,v
retrieving revision 1.6
diff -u -r1.6 netfilter-faq.sgml
--- netfilter-faq.sgml	15 Sep 2002 11:34:46 -0000	1.6
+++ netfilter-faq.sgml	26 Jun 2003 13:59:19 -0000
@@ -5,12 +5,12 @@
 <title>netfilter/iptables FAQ</title>
 <author>Harald Welte &lt;laforge@gnumonks.org&gt;&nl;
 Tłumaczenie: Maciej Sołtysiak<tt><htmlurl name="solt@dns.toxicfilms.tv" url="mailto:solt@dns.toxicfilms.tv"></tt></author>
-<date>Version $Revision: 1.6 $, $Date: 2002/09/15 11:34:46 $
-Tłumaczenie: Czwartek 25 Lipca 2002 $</date>
+<date>Version $Revision: 1.40 $, $Date: 2003/03/06 11:37:02 $</date>
+Tłumaczenie: Czwartek 26 Czerwca 2003 $</date>

 <abstract>
-Ten dokument zawiera Frequently Asked Questions napotkane na liście
-mailingowej netfilter. Komentarze / dodatki / objaśnienia są mile widziane
+Ten dokument zawiera najczęściej zadawane pytania (Frequently Asked Questions) występujące na liście
+dyskusyjnej netfilter. Komentarze / dodatki / objaśnienia są mile widziane
 i powinny być kierowane do utrzymującego FAQ.
 </abstract>

@@ -19,7 +19,7 @@
 <sect>Pytania ogólne
 <p>
 Ten rozdział zawiera ogólne pytania dotyczące netfiltra (i nie tylko) jakie
-napotkaliśmy na liscie dyskusyjnej.
+napotkaliśmy na liście dyskusyjnej.

 <sect1>Skąd mogę wziąć netfilter/iptables?
 <p>
@@ -37,7 +37,7 @@
 <url url="http://netfilter.filewatcher.org/">.
 </sect1>

-<sect1>Czy jest wersja netfiltra na Linuxa 2.2?
+<sect1>Czy jest wersja netfiltra na Linuksa 2.2?
 <p>
 Nie, nie ma. Ale jeśli ktoś chce zacząć, nie powinno to być zbyt trudne z
 uwagi na przejrzysty interface do stosu sieci.
@@ -47,16 +47,16 @@

 <sect1>Czy jest moduł ICQ conntrack/NAT?
 <p>
-Jeśli jesteś przyzwyczajony do maskarady na Linuxach 2.2, zawsze uzywałes
+Jeśli jesteś przyzwyczajony do maskarady na Linuksach 2.2, zawsze używałeś
 modułu ip_masq_icq by działaly bezpośrednie połączenia ICQ klient-klient.
 <p>
 Nikt nie zaimplementował ponownie tego modułu do netfiltra, ponieważ
-protokół ICQ jest ochydny :) Ale myślę, że to kwestia czasu zanim będzie
+protokół ICQ jest ohydny :) Ale myślę, że to kwestia czasu zanim będzie
 dostępny.
 <p>
 Rusty kiedyś wskazał na to, że tylko moduły dla protokołów z przynajmniej
 jednym wolnym klientem i jednym wolnym serwerem będą integrowane do
-głównej dystrybucji netfiltra. Co do ICQ, darmowe są tylko klienty, więc
+głównej dystrybucji netfiltra. Co do ICQ, darmowi są tylko klienci, więc
 kryteria odrzucają ten moduł. (wolnym w sensie swobody, nie jak wolny żółw
 czy darmowy, tj. definicja RMS - Richarda M. Stallmana)
 </sect1>
@@ -64,7 +64,7 @@
 <sect1>Co się stało z modułami ip_masq_vdolive / ip_masq_quake?
 <p>
 Niektóre z nich nie są wymagane, a niektóre nie zostały jeszcze przeniesione
-do netfiltra.  Netfilter wykonje pełną rejestrację połączeń (connection
+do netfiltra.  Netfilter wykonuje pełne śledzenie połączeń (connection
 tracking) nawet dla UDP i ma zasadę by nie przeszkadzać pakietom w miarę
 możliwości, więc czasami to 'po prostu działa'.
 </sect1>
@@ -73,13 +73,13 @@
 <p>
 Jądra 2.4.x są stabilną wersją, więc nie możemy ot tak wysyłać aktualnego
 kodu do głównego jądra.  Cały kod jest rozwijany i testowany najpierw w
-netfilter patch-o-matic.  Jeśli chcesz używac którejś z nowych funkcji
-netfiltra, będziesz musiał zastosować jeden lub kilka patchy z
+netfilter patch-o-matic.  Jeśli chcesz używać którejś z nowych funkcji
+netfiltra, będziesz musiał zastosować jedną lub kilka łat z
 patch-o-matic.  Możesz znaleźć patch-o-matic w najnowszym pakiecie
-netfiltra (lub oczywiscie w CVS) i ściągnąć ze strony domowej netfiltra.
+netfiltra (lub oczywiście w CVS) i ściągnąć ze strony domowej netfiltra.

 <p>
-patch-o-matic ma teraz trzy rózne opcje:
+patch-o-matic ma teraz trzy różne opcje:
 <itemize>
 <item>make pending-patches
 <item>make most-of-pom
@@ -88,10 +88,10 @@

 <p>
 Pierwszy jest po ty by upewnić się czy wszystkie ważne poprawki (które
-zostały wysłane do utrzymujących kernel) są w jądrze. Drugi `most-of-pom`
-dodatkowo pyta o nowe patche, które można zastosować bez konfliktów. Trzecia
+zostały wysłane do utrzymujących jądro) są w jądrze. Drugi `most-of-pom`
+dodatkowo pyta o nowe łaty, które można zastosować bez konfliktów. Trzecia
 opcja `patch-o-matic` jest dla prawdziwych ekspertów którzy chcą widzieć
-wszystkie patche - ale miej świadomość, mogą ze sobą konfliktować.
+wszystkie łatki - ale miej świadomość, mogą powodować konflikty.
 <p>
 patch-o-matic ma fajny interfejs użytkownika. Po prostu wpisz

@@ -106,8 +106,8 @@
 </verb></tscreen>

 w najwyższym katalogu pakietu netfilter.  patch-o-matic sprawdza czy
-każdy patch zastosowałby się w żródle jądra jakie masz zainstalowane.
-Jeśli tak, zobaczysz opcje: możesz przeczytać więcej o patchu,
+każda łatka zaaplikowałaby się w źródle jądra jakie masz zainstalowane.
+Jeśli tak, zobaczysz opcje: możesz przeczytać więcej o łacie,
 zastosować go lub przejść do następnego ...

 Więcej informacji na temat patch-o-matic jest w netfilter extensions HOWTO.
@@ -127,23 +127,23 @@
 <sect>Problemy podczas kompilacji
 <p>

-<sect1>Nie mogę skompilować iptables-1.1.1 z kernelem &gt;= 2.4.0-test4
+<sect1>Nie mogę skompilować iptables-1.1.1 z jądrem &gt;= 2.4.0-test4
 <p>
-To znany problem. Mechanizm wykrywania które patche zastosować jest zepsuty.
-Spróbój "make build" zamiast "make".
+To znany problem. Mechanizm wykrywania które łaty zastosować jest zepsuty.
+Spróbuj "make build" zamiast "make".

 <p>
 Lepsze rozwiązanie: zaktualizuj do iptables-1.1.2 lub późniejszych.

 </sect1>

-<sect1>Nie mogę skompilować iptables 1.1.0 z ostatnimi kernelami (&gt;= 2.3.99-pre8)
+<sect1>Nie mogę skompilować iptables 1.1.0 z ostatnimi jądrami (&gt;= 2.3.99-pre8)
 <p>
 Wewnętrzne struktury w iptables zmieniły się. Uaktualnij iptables do &gt;= 1.1.1

 </sect1>

-<sect1>Niektóre patche patch-o-matic z iptables-1.2.1a nie działają z kernelem &gt;= 2.4.4
+<sect1>Niektóre łaty patch-o-matic z iptables-1.2.1a nie działają z jądrem &gt;= 2.4.4
 <p>
 Proszę użyj iptables-1.2.2 lub netfilter CVS.
 </sect1>
@@ -153,16 +153,16 @@
 Najprawdopodobniej doświadczasz problemów z funkcją zwaną
 <tt>ip_nat_setup_info</tt>.
 <p>
-Jeśli używasz iptables &lt;= 1.2.2, <bf>MUSISZ</bf> zastosować patche 'dropped-table' i 'ftp-fixes'.
+Jeśli używasz iptables &lt;= 1.2.2, <bf>MUSISZ</bf> zastosować łaty 'dropped-table' i 'ftp-fixes'.
 <p>
-Jeśli używasz iptables &gt; 1.2.2 lub swieży CVS, proszę <bf>nie</bf> stosuj
+Jeśli używasz iptables &gt; 1.2.2 lub świeży CVS, proszę <bf>nie</bf> stosuj
 `dropped-table', gdyż jest niekompatybilny z BALANCE, NETMAP, irc-nat, SAME
 i talk-nat.
 </sect1>

-<sect1>Mam problemy z kernelem z patchami Alana Coxa 2.4.x-acXX
+<sect1>Mam problemy z jądrem z łatami Alana Coxa 2.4.x-acXX
 <p>
-Główny zespół netfiltra opiera rozwój na kernelach Linusa, więc serii -ac
+Główny zespół netfiltra opiera rozwój na jądrach Linusa, więc serii -ac
 używaj na własne ryzyko.
 </sect1>

@@ -198,19 +198,19 @@
 <p>
 Prawdopodobne powody to:
 <itemize>
-<item>osiągnięto maksymalną liczbę wpisów w bazie danych śledzonych połączeń
+<item>osiągnięto maksymalną liczbę wpisów w bazie śledzonych połączeń
 <item>nie można określić pakietu odpowiadającego na połączenie (multicast, broadcast)
 <item>kmem_cache_alloc zawodzi (brak pamięci)
 <item>odpowiedź na niepotwierdzone połączenie
-<item>pakiet mulitcastowy (zobacz poprzednie pytanie)
+<item>pakiet multicastowy (zobacz poprzednie pytanie)
 <item>pakiet icmp jest za krótki
 <item>pakiet icmp jest sfragmentowany
-<item>pakiet icmp ma złą suma kontrolną
+<item>pakiet icmp ma złą sumę kontrolną
 </itemize>

 <p>
-Jeśli chcesz mieć bardziej szczegółowe logowanie tych pakietów (tj. jeśli
-podejrzewasz, ze to remote probe / pakiety skanujące), użyj następującej
+Jeśli chcesz bardziej szczegółowo logować te pakiety (tj. jeśli
+podejrzewasz, że to zdalna sonda (remote probe) / pakiety skanujące), użyj następującej
 regułki:
 <tscreen><verb>
 iptables -t mangle -A PREROUTING -j LOG -m state --state INVALID
@@ -229,39 +229,39 @@
 Ale ktoś pisze nowy bridging code, zerknij na <url url="http://bridge.sourceforge.net/">
 <p>
 Zauważ, że wsparcie dla bridge'ującego firewalla jest uważane za skrajnie
-ekperymentalne.
+eksperymentalne.

 </sect1>

 <sect1>Moduł IRC nie obsługuje DCC RESUME
 <p>
-Więc, jest to połowiczna prawda. Tylko moduł NAT nie jest w stanie obsłużyć
-ich.  Jeśli firewallujesz bez NATa, powinno działać.
+Jest to połowiczna prawda. Tylko moduł NAT nie jest w stanie obsłużyć ich.
+Jeśli jest to firewall bez NAT, powinno działać.

 </sect1>

-<sect1>Jak działa SNAT do wielu adresow?
+<sect1>Jak działa SNAT do wielu adresów?
 <p>
 Netfilter stara się jak najmniej zmieniać pakiety. Więc jeśli mamy
-swieżo-przeładowaną maszynę i ktoś za SNAT'em otwiera połączenie z loklanym
+świeżo-przeładowaną maszynę i ktoś za SNAT'em otwiera połączenie z loklanym
 portem 1234, netfilter tylko zmienia adres IP a port zostaje ten sam.
 <p>
 Jak tylko ktoś inny otworzy inne połączenie z tym samym źródłowym portem,
 netfilter musiałby zmienić IP i port jeśli ma tylko jeden IP dla SNAT.
 <p>
 Ale jeśli jest dostępny więcej niż jeden, <bf>ponownie</bf> tylko musi
-zmieniac część IP.
+zmieniać część IP.
 </sect1>

 <sect1>ip_conntrack: maximum limit of XXX entries exceeded
 <p>
 Jeśli zauważysz następujące wpisy w syslogu, wygląda na to, że baza danych
 conntrack nie ma wystarczającego miejsca na twoje środowisko. Connection
-tracking domyślnie obsługuje do pewnego poziomu liczbę wspolbieżnych połączeń.
+tracking domyślnie obsługuje do pewnego poziomu liczbę współbieżnych połączeń.
 Ta liczba zależy od rozmiaru pamięci (przy 64MB: 4096, 128MB: 8192, ...).
 <p>
 Możesz z łatwością zwiększyć maksymalną liczbę rejestrowanych połączeń, ale
-miej na uwadze, że każde połączenie zjada około 350 bajtów nie-swappowalnej
+miej na uwadze, że każde połączenie zjada około 350 bajtów nieswappowalnej
 pamięci jądra.
 <p>
 By zwiększyć ten limit do np 8192, wpisz:
@@ -272,7 +272,7 @@

 </sect1>

-<sect1>Jak wylistować trackowane / maskaradowane połączenia, podobnie jak 'ipchains -L -M' w 2.2.x
+<sect1>Jak wylistować śledzone / maskaradowane połączenia, podobnie jak 'ipchains -L -M' w 2.2.x
 <p>
 Jest plik w filesystemie proc, zwany <tt>/proc/net/ip_conntrack</tt>.
 Możesz wyświetlić jego zawartość pisząc:
@@ -292,33 +292,33 @@

 <sect1>iptables-save / iptables-restore z iptables-1.2 wywala segfaulty
 <p>
-Znany Bug.  Uaktualnij do najświeższego CVS lub użyj iptables &gt;= 1.2.1
+Znany błąd.  Uaktualnij do najświeższego CVS lub użyj iptables &gt;= 1.2.1
 jak tylko będzie dostępne.
 </sect1>

 <sect1>Mijają wieki zanim iptables -L wyświetli regułki
 <p>
-To dlatego, że iptables robi DNS lookup dla każdego adresu. Jakoże każda
+To dlatego, że iptables robi DNS lookup dla każdego adresu. Jako że każda
 regułka składa się z dwu adresów, w najgorszym przypadku wychodzi na 2
-DNS lookupy na regułke.
+DNS lookupy na regułkę.
 <p>
 Problem jest, jeśli używasz prywatnych adresów IP (10.x.x.x lub 192.168.x.x),
 DNS nie jest w stanie rozwiązać nazwy hosta i czekamy na timeout. Suma
 wszystkich timeoutów może być bardzo duża, w zależności od zestawu regułek.
 <p>
-Używaj opcji -n (numeric) w iptables by pominąc reverse DNS lookups.
+Używaj opcji -n (numeric) w iptables by pominąć reverse DNS lookups.
 </sect1>

-<sect1>Jak zrobić by target LOG nie logował na konsole?
+<sect1>Jak zrobić by target LOG nie logował na konsolę?
 <p>
 Musisz skonfigurować syslogd odpowiednio:
-Target LOG loguje do facility kern przy priorytecie warining (4).
+Target LOG loguje do facility kern przy priorytecie warning (4).
 Zobacz strony man od syslogd.conf by przeczytać więcej o facilities i
 priorytetach.
 <p>
 Domyślnie, wszystkie wiadomości na priorytecie bardziej poważnym niż debug (7)
 są wysyłane na konsole. Jeśli zwiększysz to do 4, zamiast 7, sprawisz, że
-logi nie bedą się pojawiały na konsoli.
+logi nie będą się pojawiały na konsoli.
 <p>
 Miej na uwadze, że to także pociąga za sobą inne ważne logi i nie pojawią
 się na konsoli (to nie wpływa na syslog).
@@ -352,12 +352,12 @@

 <sect1>Jak używać target LOG / Jak mogę LOGowac i DROPowac?
 <p>
-Target LOG jest czymś co nazywamy "nie-kończący target", tj. nie kończy
+Target LOG jest czymś co nazywamy "niekończący target", tj. nie kończy
 podróży pakietu.  Jeśli użyjesz target LOG, pakiet będzie zalogowany i
 podróż będzie kontynuowana od następnej regułki.
 <p>
 Więc jak mam logować i zrzucać pakiet jednocześnie? Nic prostszego, możesz
-stworzyć własny chain, zawierający te dwie regułki:
+stworzyć własny łańcuch, zawierający te dwie regułki:

 <tscreen><verb>
 iptables -N logdrop
@@ -366,7 +366,7 @@
 </verb></tscreen>
 <p>
 Teraz za każdym razem jak będziesz chciał logować i zrzucić pakiet, możesz
-po prostu użyc "-j logdrop".
+po prostu użyć "-j logdrop".

 </sect1>

@@ -375,20 +375,20 @@
 Krótka odpowiedz brzmi: nie da się tego zrobić prawidłowo używając
 netfiltra. Większość robaków używa prawidłowych protokołów wyższej warstwy
 (tj. HTTP, SMTP (np. VB script w załączniku listu), lub wykorzystuje
-jakąkolwiek inną znaną dziurę w demonie obsługującym protokół). Mowiąc
+jakąkolwiek inną znaną dziurę w demonie obsługującym protokół). Mówiąc
 protokół wyższych wartsw, mamy na myśli ponad TCP/IP. Jako że iptables nie
 rozumie protokołów wyższych wartsw, jest prawie nie możliwe filtrowanie ich
 prawidłowo. Do tego potrzeba proxy filtrujących na poziomie aplikacji.
 <p>
-Proszę nie używaj matchu strign z patch-o-matic zamiast takiej aplikacji.
+Proszę nie używaj matchu string z patch-o-matic zamiast takiej aplikacji.
 Nie da rady sobie z fragmentowanymi pakietami (tj. zapytanie HTTP rozbite na
 dwa pakiety TCP), z technikami unikania systemów IDS, itd... zostałeś
 ostrzeżony! Match string jest przydatny ale w innych celach.
 </sect1>

-<sect1>kernel loguje: Out of windows data xxx
+<sect1>jądro loguje: Out of windows data xxx
 <p>
-Używasz patcha tcp-window-tracking z patch-o-matic, którego kod śledzi czy
+Używasz łaty tcp-window-tracking z patch-o-matic, którego kod śledzi czy
 pakiety dopuszczonych strumieni TCP mają zgodne numery
 sekwencji/potwierdzenia (sequence/acknowledgement), rozmiary segmentów, itd.
 pakietów. Kiedy wykryje, że pakiet jest nieakceptowalny (out of the window),
@@ -402,7 +402,7 @@
 <item>SEQ is over the upper bound (ponad oknem odbiorczym)
 </itemize>
 <p>
-Takze, w nowszych wersjach logowanie można całkowicie wyłączyć poprzez
+Także, w nowszych wersjach logowanie można całkowicie wyłączyć poprzez
 sysctl
 <tscreen><verb>
 echo 0 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_log_out_of_window
@@ -410,7 +410,7 @@

 </sect1>

-<sect1>Dlaczego system śledzenia połączeń (connectrion tracking) śledzi połączenia UNREPLIED (bez odpowiedzi) z dużym timeoutem?
+<sect1>Dlaczego system śledzenia połączeń (connection tracking) śledzi połączenia UNREPLIED (bez odpowiedzi) z dużym timeoutem?

 <p>
 Sprawdziłeś /proc/net/ip_conntrack i znalazłeś wpisy połączeń w stanie
@@ -426,9 +426,29 @@
 </sect1>
 <sect1>Dlaczego nie zaimplementowano opcji 'iptables -C' (--check) ?

+<p>
+Po pierwsze dlatego, że jesteśmy leniwi ;). A szczerze mówiąc, implementacja
+opcji check jest prawie niemożliwa jak tylko zaczynamy stateful firewalling.
+Tradycyjne firewalle nie przetrzymujące informacji o stanie połączenia
+(są stateless) opierają swoje decyzje tylko w oparciu o informacje zawarte
+w nagłówkach pakietów. A że śledzeniem połączeń (i regułami opartymi o '-m
+state'), decyzja o filtrowaniu zależy od nagłówka+dane, a także od
+nagłówka+dane poprzednich pakietów danego połączenia.
+
+
+</sect1>
+
+<sect1>Dlaczego nie mogę używać REJECT w łańcuchu PREROUTING?
+<p>
+Target REJECT służy do filtrowania. Tabela filter ma łańcuchy
+INPUT/OUTPUT/FORWARD, zatem REJECT może być tylko używany w tych łańcuchach
+(i podłańcuchach, naturalnie).
+
+Użytkownicy netfiltra nie filtrują pakietów w tabeli nat czy mangle.
 </sect1>
 </sect>

+
 <sect>Pytania o rozwój netfiltra

 <sect1>Nie rozumiem jak używać target QUEUE z przestrzeni użytkownika (userspace)
@@ -458,18 +478,18 @@

 </sect1>

-<sect1>Moja aplikacja libipq mowi "Failed to receive netlink message: No buffer space available"
+<sect1>Moja aplikacja oparta na libipq zgłasza "Failed to receive netlink message: No buffer space available"
 <p>
-Oznacza to, ze bufor socketu Netlink po stronie kernela wyczerpał pamięc;
+Oznacza to, że bufor gniazda (socket) Netlink po stronie jądra wyczerpał pamięć;
 aplikacja przestrzeni użytkownika nie jest w stanie obsłużyć ilości danych
 dostarczonych z jądra.
 <p>
 <quote><em>Czy jest możliwe by zwiększyć bufory jądra bym nie wpadał na ten
 problem?</em></quote>
 <p>
-Tak, są to standardowe sockety Netlink i możesz dostroić rozmiary buforów
+Tak, są to standardowe gniazda (sockety) Netlink i możesz dostroić rozmiary buforów
 wejściowych (receive buffer) poprzez /proc/sys/net/core, sysctl lub używać
-opcji socketa SO_RCVBUF na deskryptorze pliku.
+opcji gniazda (socketa) SO_RCVBUF na deskryptorze pliku.
 <p>
 Możesz także spróbować zapewnić by aplikacja czytała dane najszybciej jak to
 jest możliwe. Jeśli nie potrzebujesz całego pakiety, spróbuj kopiować mniej
@@ -485,14 +505,14 @@
 pobrać przez CVSweb <url url="http://cvs.netfilter.org/cgi-bin/cvsweb/netfilter/TODO/">
 </sect1>

-<sect1>Naprawiłem buga lub napisałem nowy moduł. Co mam zrobic?
+<sect1>Naprawiłem błąd lub napisałem nowy moduł. Co mam zrobić?
 <p>
-Jeśli chcesz to opublikować, wyślij to listy mailingowej netfilter-devel.
+Jeśli chcesz to opublikować, wyślij to listy dyskusyjnej netfilter-devel.
 Instrukcja jak zostać subskrybentem jest w <url url="http://lists.netfilter.org/mailman/listinfo/netfilter-devel/">.

-Prawidłowy sposób wysyłania patchy:
+Prawidłowy sposób wysyłania łat:
 <itemize>
-<item> Temat zaczynający sie <bf>&#91;PATCH&#93;</bf>
+<item> Temat zaczynający się od <bf>&#91;PATCH&#93;</bf>
 <item> Załączone prosto w ciele wiadomości, bez MIME.
 <item> wpis cvs-checkin/Changelog poza diffem.
 <item> forma `diff -u old new', spoza katalogu root pakietu (tj. może być stosowany z -p1 będąc pod odtarowanym katalogiem.
@@ -501,7 +521,7 @@
 Jeśli napisałeś nowe rozszerzenie, lub dodałeś nowe opcje do starego
 rozszerzenia, zwykle dobrze jest zaktualizować także
 netfilter-extension-HOWTO by włączyć opis nowej funkcjonalności. Dodatkowo,
-przyciągnie to więcej użtykowników do rozszerzenia i pozwoli na uzyskanie
+przyciągnie to więcej użytkowników do rozszerzenia i pozwoli na uzyskanie
 więcej informacji od użytkowników.
 </sect1>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Polish FAQ update.
  2003-06-27 23:25 ` Fabrice MARIE
@ 2003-06-27 15:29   ` Maciej Soltysiak
  2003-06-27 23:43     ` Fabrice MARIE
  0 siblings, 1 reply; 5+ messages in thread
From: Maciej Soltysiak @ 2003-06-27 15:29 UTC (permalink / raw)
  To: Fabrice MARIE; +Cc: netfilter-devel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 104 bytes --]

> Could you send the patch again, this time mime encoded ?
Sure.

> Dziękuję.
Proszę.

> Fabrice
Maciej

[-- Attachment #2: faq_pl --]
[-- Type: TEXT/PLAIN, Size: 19190 bytes --]

Index: netfilter-faq.sgml
===================================================================
RCS file: /cvspublic/netfilter/documentation/FAQ/pl/netfilter-faq.sgml,v
retrieving revision 1.6
diff -u -r1.6 netfilter-faq.sgml
--- netfilter-faq.sgml	15 Sep 2002 11:34:46 -0000	1.6
+++ netfilter-faq.sgml	26 Jun 2003 13:59:19 -0000
@@ -5,12 +5,12 @@
 <title>netfilter/iptables FAQ</title>
 <author>Harald Welte &lt;laforge@gnumonks.org&gt;&nl;
 Tłumaczenie: Maciej Sołtysiak<tt><htmlurl name="solt@dns.toxicfilms.tv" url="mailto:solt@dns.toxicfilms.tv"></tt></author>
-<date>Version $Revision: 1.6 $, $Date: 2002/09/15 11:34:46 $
-Tłumaczenie: Czwartek 25 Lipca 2002 $</date>
+<date>Version $Revision: 1.40 $, $Date: 2003/03/06 11:37:02 $</date>
+Tłumaczenie: Czwartek 26 Czerwca 2003 $</date>
 
 <abstract>
-Ten dokument zawiera Frequently Asked Questions napotkane na liście
-mailingowej netfilter. Komentarze / dodatki / objaśnienia są mile widziane
+Ten dokument zawiera najczęściej zadawane pytania (Frequently Asked Questions) występujące na liście
+dyskusyjnej netfilter. Komentarze / dodatki / objaśnienia są mile widziane
 i powinny być kierowane do utrzymującego FAQ.
 </abstract>
 
@@ -19,7 +19,7 @@
 <sect>Pytania ogólne
 <p>
 Ten rozdział zawiera ogólne pytania dotyczące netfiltra (i nie tylko) jakie
-napotkaliśmy na liscie dyskusyjnej.
+napotkaliśmy na liście dyskusyjnej.
 
 <sect1>Skąd mogę wziąć netfilter/iptables?
 <p>
@@ -37,7 +37,7 @@
 <url url="http://netfilter.filewatcher.org/">.
 </sect1>
 
-<sect1>Czy jest wersja netfiltra na Linuxa 2.2?
+<sect1>Czy jest wersja netfiltra na Linuksa 2.2?
 <p>
 Nie, nie ma. Ale jeśli ktoś chce zacząć, nie powinno to być zbyt trudne z
 uwagi na przejrzysty interface do stosu sieci.
@@ -47,16 +47,16 @@
 
 <sect1>Czy jest moduł ICQ conntrack/NAT?
 <p>
-Jeśli jesteś przyzwyczajony do maskarady na Linuxach 2.2, zawsze uzywałes
+Jeśli jesteś przyzwyczajony do maskarady na Linuksach 2.2, zawsze używałeś
 modułu ip_masq_icq by działaly bezpośrednie połączenia ICQ klient-klient.
 <p>
 Nikt nie zaimplementował ponownie tego modułu do netfiltra, ponieważ
-protokół ICQ jest ochydny :) Ale myślę, że to kwestia czasu zanim będzie
+protokół ICQ jest ohydny :) Ale myślę, że to kwestia czasu zanim będzie
 dostępny.
 <p>
 Rusty kiedyś wskazał na to, że tylko moduły dla protokołów z przynajmniej
 jednym wolnym klientem i jednym wolnym serwerem będą integrowane do
-głównej dystrybucji netfiltra. Co do ICQ, darmowe są tylko klienty, więc
+głównej dystrybucji netfiltra. Co do ICQ, darmowi są tylko klienci, więc
 kryteria odrzucają ten moduł. (wolnym w sensie swobody, nie jak wolny żółw
 czy darmowy, tj. definicja RMS - Richarda M. Stallmana)
 </sect1>
@@ -64,7 +64,7 @@
 <sect1>Co się stało z modułami ip_masq_vdolive / ip_masq_quake?
 <p>
 Niektóre z nich nie są wymagane, a niektóre nie zostały jeszcze przeniesione
-do netfiltra.  Netfilter wykonje pełną rejestrację połączeń (connection
+do netfiltra.  Netfilter wykonuje pełne śledzenie połączeń (connection
 tracking) nawet dla UDP i ma zasadę by nie przeszkadzać pakietom w miarę
 możliwości, więc czasami to 'po prostu działa'.
 </sect1>
@@ -73,13 +73,13 @@
 <p>
 Jądra 2.4.x są stabilną wersją, więc nie możemy ot tak wysyłać aktualnego
 kodu do głównego jądra.  Cały kod jest rozwijany i testowany najpierw w
-netfilter patch-o-matic.  Jeśli chcesz używac którejś z nowych funkcji
-netfiltra, będziesz musiał zastosować jeden lub kilka patchy z
+netfilter patch-o-matic.  Jeśli chcesz używać którejś z nowych funkcji
+netfiltra, będziesz musiał zastosować jedną lub kilka łat z
 patch-o-matic.  Możesz znaleźć patch-o-matic w najnowszym pakiecie
-netfiltra (lub oczywiscie w CVS) i ściągnąć ze strony domowej netfiltra.
+netfiltra (lub oczywiście w CVS) i ściągnąć ze strony domowej netfiltra.
 
 <p>
-patch-o-matic ma teraz trzy rózne opcje:
+patch-o-matic ma teraz trzy różne opcje:
 <itemize>
 <item>make pending-patches
 <item>make most-of-pom
@@ -88,10 +88,10 @@
 
 <p>
 Pierwszy jest po ty by upewnić się czy wszystkie ważne poprawki (które
-zostały wysłane do utrzymujących kernel) są w jądrze. Drugi `most-of-pom`
-dodatkowo pyta o nowe patche, które można zastosować bez konfliktów. Trzecia
+zostały wysłane do utrzymujących jądro) są w jądrze. Drugi `most-of-pom`
+dodatkowo pyta o nowe łaty, które można zastosować bez konfliktów. Trzecia
 opcja `patch-o-matic` jest dla prawdziwych ekspertów którzy chcą widzieć
-wszystkie patche - ale miej świadomość, mogą ze sobą konfliktować.
+wszystkie łatki - ale miej świadomość, mogą powodować konflikty.
 <p>
 patch-o-matic ma fajny interfejs użytkownika. Po prostu wpisz
 
@@ -106,8 +106,8 @@
 </verb></tscreen>
 
 w najwyższym katalogu pakietu netfilter.  patch-o-matic sprawdza czy
-każdy patch zastosowałby się w żródle jądra jakie masz zainstalowane.
-Jeśli tak, zobaczysz opcje: możesz przeczytać więcej o patchu,
+każda łatka zaaplikowałaby się w źródle jądra jakie masz zainstalowane.
+Jeśli tak, zobaczysz opcje: możesz przeczytać więcej o łacie,
 zastosować go lub przejść do następnego ...
 
 Więcej informacji na temat patch-o-matic jest w netfilter extensions HOWTO.
@@ -127,23 +127,23 @@
 <sect>Problemy podczas kompilacji
 <p>
 
-<sect1>Nie mogę skompilować iptables-1.1.1 z kernelem &gt;= 2.4.0-test4
+<sect1>Nie mogę skompilować iptables-1.1.1 z jądrem &gt;= 2.4.0-test4
 <p>
-To znany problem. Mechanizm wykrywania które patche zastosować jest zepsuty.
-Spróbój "make build" zamiast "make". 
+To znany problem. Mechanizm wykrywania które łaty zastosować jest zepsuty.
+Spróbuj "make build" zamiast "make". 
 
 <p>
 Lepsze rozwiązanie: zaktualizuj do iptables-1.1.2 lub późniejszych.
 
 </sect1>
 
-<sect1>Nie mogę skompilować iptables 1.1.0 z ostatnimi kernelami (&gt;= 2.3.99-pre8)
+<sect1>Nie mogę skompilować iptables 1.1.0 z ostatnimi jądrami (&gt;= 2.3.99-pre8)
 <p>
 Wewnętrzne struktury w iptables zmieniły się. Uaktualnij iptables do &gt;= 1.1.1
 
 </sect1>
 
-<sect1>Niektóre patche patch-o-matic z iptables-1.2.1a nie działają z kernelem &gt;= 2.4.4
+<sect1>Niektóre łaty patch-o-matic z iptables-1.2.1a nie działają z jądrem &gt;= 2.4.4
 <p>
 Proszę użyj iptables-1.2.2 lub netfilter CVS.
 </sect1>
@@ -153,16 +153,16 @@
 Najprawdopodobniej doświadczasz problemów z funkcją zwaną
 <tt>ip_nat_setup_info</tt>. 
 <p>
-Jeśli używasz iptables &lt;= 1.2.2, <bf>MUSISZ</bf> zastosować patche 'dropped-table' i 'ftp-fixes'.
+Jeśli używasz iptables &lt;= 1.2.2, <bf>MUSISZ</bf> zastosować łaty 'dropped-table' i 'ftp-fixes'.
 <p>
-Jeśli używasz iptables &gt; 1.2.2 lub swieży CVS, proszę <bf>nie</bf> stosuj
+Jeśli używasz iptables &gt; 1.2.2 lub świeży CVS, proszę <bf>nie</bf> stosuj
 `dropped-table', gdyż jest niekompatybilny z BALANCE, NETMAP, irc-nat, SAME
 i talk-nat.
 </sect1>
 
-<sect1>Mam problemy z kernelem z patchami Alana Coxa 2.4.x-acXX
+<sect1>Mam problemy z jądrem z łatami Alana Coxa 2.4.x-acXX
 <p>
-Główny zespół netfiltra opiera rozwój na kernelach Linusa, więc serii -ac
+Główny zespół netfiltra opiera rozwój na jądrach Linusa, więc serii -ac
 używaj na własne ryzyko.
 </sect1>
 
@@ -198,19 +198,19 @@
 <p>
 Prawdopodobne powody to:
 <itemize>
-<item>osiągnięto maksymalną liczbę wpisów w bazie danych śledzonych połączeń
+<item>osiągnięto maksymalną liczbę wpisów w bazie śledzonych połączeń
 <item>nie można określić pakietu odpowiadającego na połączenie (multicast, broadcast)
 <item>kmem_cache_alloc zawodzi (brak pamięci)
 <item>odpowiedź na niepotwierdzone połączenie
-<item>pakiet mulitcastowy (zobacz poprzednie pytanie)
+<item>pakiet multicastowy (zobacz poprzednie pytanie)
 <item>pakiet icmp jest za krótki
 <item>pakiet icmp jest sfragmentowany
-<item>pakiet icmp ma złą suma kontrolną
+<item>pakiet icmp ma złą sumę kontrolną
 </itemize>
 
 <p>
-Jeśli chcesz mieć bardziej szczegółowe logowanie tych pakietów (tj. jeśli
-podejrzewasz, ze to remote probe / pakiety skanujące), użyj następującej
+Jeśli chcesz bardziej szczegółowo logować te pakiety (tj. jeśli
+podejrzewasz, że to zdalna sonda (remote probe) / pakiety skanujące), użyj następującej
 regułki:
 <tscreen><verb>
 iptables -t mangle -A PREROUTING -j LOG -m state --state INVALID
@@ -229,39 +229,39 @@
 Ale ktoś pisze nowy bridging code, zerknij na <url url="http://bridge.sourceforge.net/">
 <p>
 Zauważ, że wsparcie dla bridge'ującego firewalla jest uważane za skrajnie
-ekperymentalne.
+eksperymentalne.
 
 </sect1>
 
 <sect1>Moduł IRC nie obsługuje DCC RESUME
 <p>
-Więc, jest to połowiczna prawda. Tylko moduł NAT nie jest w stanie obsłużyć
-ich.  Jeśli firewallujesz bez NATa, powinno działać.
+Jest to połowiczna prawda. Tylko moduł NAT nie jest w stanie obsłużyć ich.
+Jeśli jest to firewall bez NAT, powinno działać.
 
 </sect1>
 
-<sect1>Jak działa SNAT do wielu adresow?
+<sect1>Jak działa SNAT do wielu adresów?
 <p>
 Netfilter stara się jak najmniej zmieniać pakiety. Więc jeśli mamy
-swieżo-przeładowaną maszynę i ktoś za SNAT'em otwiera połączenie z loklanym
+świeżo-przeładowaną maszynę i ktoś za SNAT'em otwiera połączenie z loklanym
 portem 1234, netfilter tylko zmienia adres IP a port zostaje ten sam.
 <p>
 Jak tylko ktoś inny otworzy inne połączenie z tym samym źródłowym portem,
 netfilter musiałby zmienić IP i port jeśli ma tylko jeden IP dla SNAT.
 <p>
 Ale jeśli jest dostępny więcej niż jeden, <bf>ponownie</bf> tylko musi
-zmieniac część IP.
+zmieniać część IP.
 </sect1>
 
 <sect1>ip_conntrack: maximum limit of XXX entries exceeded
 <p>
 Jeśli zauważysz następujące wpisy w syslogu, wygląda na to, że baza danych
 conntrack nie ma wystarczającego miejsca na twoje środowisko. Connection
-tracking domyślnie obsługuje do pewnego poziomu liczbę wspolbieżnych połączeń.
+tracking domyślnie obsługuje do pewnego poziomu liczbę współbieżnych połączeń.
 Ta liczba zależy od rozmiaru pamięci (przy 64MB: 4096, 128MB: 8192, ...).
 <p>
 Możesz z łatwością zwiększyć maksymalną liczbę rejestrowanych połączeń, ale
-miej na uwadze, że każde połączenie zjada około 350 bajtów nie-swappowalnej
+miej na uwadze, że każde połączenie zjada około 350 bajtów nieswappowalnej
 pamięci jądra.
 <p>
 By zwiększyć ten limit do np 8192, wpisz:
@@ -272,7 +272,7 @@
 
 </sect1>
 
-<sect1>Jak wylistować trackowane / maskaradowane połączenia, podobnie jak 'ipchains -L -M' w 2.2.x
+<sect1>Jak wylistować śledzone / maskaradowane połączenia, podobnie jak 'ipchains -L -M' w 2.2.x
 <p>
 Jest plik w filesystemie proc, zwany <tt>/proc/net/ip_conntrack</tt>. 
 Możesz wyświetlić jego zawartość pisząc:
@@ -292,33 +292,33 @@
 
 <sect1>iptables-save / iptables-restore z iptables-1.2 wywala segfaulty
 <p>
-Znany Bug.  Uaktualnij do najświeższego CVS lub użyj iptables &gt;= 1.2.1
+Znany błąd.  Uaktualnij do najświeższego CVS lub użyj iptables &gt;= 1.2.1
 jak tylko będzie dostępne.
 </sect1>
 
 <sect1>Mijają wieki zanim iptables -L wyświetli regułki
 <p>
-To dlatego, że iptables robi DNS lookup dla każdego adresu. Jakoże każda
+To dlatego, że iptables robi DNS lookup dla każdego adresu. Jako że każda
 regułka składa się z dwu adresów, w najgorszym przypadku wychodzi na 2
-DNS lookupy na regułke.
+DNS lookupy na regułkę.
 <p>
 Problem jest, jeśli używasz prywatnych adresów IP (10.x.x.x lub 192.168.x.x),
 DNS nie jest w stanie rozwiązać nazwy hosta i czekamy na timeout. Suma
 wszystkich timeoutów może być bardzo duża, w zależności od zestawu regułek.
 <p>
-Używaj opcji -n (numeric) w iptables by pominąc reverse DNS lookups.
+Używaj opcji -n (numeric) w iptables by pominąć reverse DNS lookups.
 </sect1>
 
-<sect1>Jak zrobić by target LOG nie logował na konsole?
+<sect1>Jak zrobić by target LOG nie logował na konsolę?
 <p>
 Musisz skonfigurować syslogd odpowiednio:
-Target LOG loguje do facility kern przy priorytecie warining (4).
+Target LOG loguje do facility kern przy priorytecie warning (4).
 Zobacz strony man od syslogd.conf by przeczytać więcej o facilities i
 priorytetach.
 <p>
 Domyślnie, wszystkie wiadomości na priorytecie bardziej poważnym niż debug (7)
 są wysyłane na konsole. Jeśli zwiększysz to do 4, zamiast 7, sprawisz, że
-logi nie bedą się pojawiały na konsoli.
+logi nie będą się pojawiały na konsoli.
 <p>
 Miej na uwadze, że to także pociąga za sobą inne ważne logi i nie pojawią
 się na konsoli (to nie wpływa na syslog).
@@ -352,12 +352,12 @@
 
 <sect1>Jak używać target LOG / Jak mogę LOGowac i DROPowac?
 <p>
-Target LOG jest czymś co nazywamy "nie-kończący target", tj. nie kończy
+Target LOG jest czymś co nazywamy "niekończący target", tj. nie kończy
 podróży pakietu.  Jeśli użyjesz target LOG, pakiet będzie zalogowany i
 podróż będzie kontynuowana od następnej regułki.
 <p>
 Więc jak mam logować i zrzucać pakiet jednocześnie? Nic prostszego, możesz
-stworzyć własny chain, zawierający te dwie regułki:
+stworzyć własny łańcuch, zawierający te dwie regułki:
 
 <tscreen><verb>
 iptables -N logdrop
@@ -366,7 +366,7 @@
 </verb></tscreen>
 <p>
 Teraz za każdym razem jak będziesz chciał logować i zrzucić pakiet, możesz
-po prostu użyc "-j logdrop".
+po prostu użyć "-j logdrop".
 
 </sect1>
 
@@ -375,20 +375,20 @@
 Krótka odpowiedz brzmi: nie da się tego zrobić prawidłowo używając
 netfiltra. Większość robaków używa prawidłowych protokołów wyższej warstwy
 (tj. HTTP, SMTP (np. VB script w załączniku listu), lub wykorzystuje
-jakąkolwiek inną znaną dziurę w demonie obsługującym protokół). Mowiąc
+jakąkolwiek inną znaną dziurę w demonie obsługującym protokół). Mówiąc
 protokół wyższych wartsw, mamy na myśli ponad TCP/IP. Jako że iptables nie
 rozumie protokołów wyższych wartsw, jest prawie nie możliwe filtrowanie ich
 prawidłowo. Do tego potrzeba proxy filtrujących na poziomie aplikacji.
 <p>
-Proszę nie używaj matchu strign z patch-o-matic zamiast takiej aplikacji.
+Proszę nie używaj matchu string z patch-o-matic zamiast takiej aplikacji.
 Nie da rady sobie z fragmentowanymi pakietami (tj. zapytanie HTTP rozbite na
 dwa pakiety TCP), z technikami unikania systemów IDS, itd... zostałeś
 ostrzeżony! Match string jest przydatny ale w innych celach.
 </sect1>
 
-<sect1>kernel loguje: Out of windows data xxx
+<sect1>jądro loguje: Out of windows data xxx
 <p>
-Używasz patcha tcp-window-tracking z patch-o-matic, którego kod śledzi czy
+Używasz łaty tcp-window-tracking z patch-o-matic, którego kod śledzi czy
 pakiety dopuszczonych strumieni TCP mają zgodne numery
 sekwencji/potwierdzenia (sequence/acknowledgement), rozmiary segmentów, itd.
 pakietów. Kiedy wykryje, że pakiet jest nieakceptowalny (out of the window),
@@ -402,7 +402,7 @@
 <item>SEQ is over the upper bound (ponad oknem odbiorczym)
 </itemize>
 <p>
-Takze, w nowszych wersjach logowanie można całkowicie wyłączyć poprzez
+Także, w nowszych wersjach logowanie można całkowicie wyłączyć poprzez
 sysctl
 <tscreen><verb>
 echo 0 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_log_out_of_window
@@ -410,7 +410,7 @@
 
 </sect1>
 
-<sect1>Dlaczego system śledzenia połączeń (connectrion tracking) śledzi połączenia UNREPLIED (bez odpowiedzi) z dużym timeoutem?
+<sect1>Dlaczego system śledzenia połączeń (connection tracking) śledzi połączenia UNREPLIED (bez odpowiedzi) z dużym timeoutem?
 
 <p>
 Sprawdziłeś /proc/net/ip_conntrack i znalazłeś wpisy połączeń w stanie
@@ -426,9 +426,29 @@
 </sect1>	
 <sect1>Dlaczego nie zaimplementowano opcji 'iptables -C' (--check) ?
 
+<p>
+Po pierwsze dlatego, że jesteśmy leniwi ;). A szczerze mówiąc, implementacja
+opcji check jest prawie niemożliwa jak tylko zaczynamy stateful firewalling.
+Tradycyjne firewalle nie przetrzymujące informacji o stanie połączenia
+(są stateless) opierają swoje decyzje tylko w oparciu o informacje zawarte
+w nagłówkach pakietów. A że śledzeniem połączeń (i regułami opartymi o '-m
+state'), decyzja o filtrowaniu zależy od nagłówka+dane, a także od
+nagłówka+dane poprzednich pakietów danego połączenia.
+
+
+</sect1>
+
+<sect1>Dlaczego nie mogę używać REJECT w łańcuchu PREROUTING?
+<p>
+Target REJECT służy do filtrowania. Tabela filter ma łańcuchy
+INPUT/OUTPUT/FORWARD, zatem REJECT może być tylko używany w tych łańcuchach
+(i podłańcuchach, naturalnie).
+
+Użytkownicy netfiltra nie filtrują pakietów w tabeli nat czy mangle.
 </sect1>
 </sect>
 
+
 <sect>Pytania o rozwój netfiltra
 
 <sect1>Nie rozumiem jak używać target QUEUE z przestrzeni użytkownika (userspace)
@@ -458,18 +478,18 @@
 
 </sect1>
 
-<sect1>Moja aplikacja libipq mowi "Failed to receive netlink message: No buffer space available"
+<sect1>Moja aplikacja oparta na libipq zgłasza "Failed to receive netlink message: No buffer space available"
 <p>
-Oznacza to, ze bufor socketu Netlink po stronie kernela wyczerpał pamięc;
+Oznacza to, że bufor gniazda (socket) Netlink po stronie jądra wyczerpał pamięć;
 aplikacja przestrzeni użytkownika nie jest w stanie obsłużyć ilości danych
 dostarczonych z jądra.
 <p>
 <quote><em>Czy jest możliwe by zwiększyć bufory jądra bym nie wpadał na ten
 problem?</em></quote>
 <p>
-Tak, są to standardowe sockety Netlink i możesz dostroić rozmiary buforów
+Tak, są to standardowe gniazda (sockety) Netlink i możesz dostroić rozmiary buforów
 wejściowych (receive buffer) poprzez /proc/sys/net/core, sysctl lub używać
-opcji socketa SO_RCVBUF na deskryptorze pliku.
+opcji gniazda (socketa) SO_RCVBUF na deskryptorze pliku.
 <p>
 Możesz także spróbować zapewnić by aplikacja czytała dane najszybciej jak to
 jest możliwe. Jeśli nie potrzebujesz całego pakiety, spróbuj kopiować mniej
@@ -485,14 +505,14 @@
 pobrać przez CVSweb <url url="http://cvs.netfilter.org/cgi-bin/cvsweb/netfilter/TODO/">
 </sect1>
 
-<sect1>Naprawiłem buga lub napisałem nowy moduł. Co mam zrobic?
+<sect1>Naprawiłem błąd lub napisałem nowy moduł. Co mam zrobić?
 <p>
-Jeśli chcesz to opublikować, wyślij to listy mailingowej netfilter-devel.
+Jeśli chcesz to opublikować, wyślij to listy dyskusyjnej netfilter-devel.
 Instrukcja jak zostać subskrybentem jest w <url url="http://lists.netfilter.org/mailman/listinfo/netfilter-devel/">.
 
-Prawidłowy sposób wysyłania patchy:
+Prawidłowy sposób wysyłania łat:
 <itemize>
-<item> Temat zaczynający sie <bf>&#91;PATCH&#93;</bf>
+<item> Temat zaczynający się od <bf>&#91;PATCH&#93;</bf>
 <item> Załączone prosto w ciele wiadomości, bez MIME.
 <item> wpis cvs-checkin/Changelog poza diffem.
 <item> forma `diff -u old new', spoza katalogu root pakietu (tj. może być stosowany z -p1 będąc pod odtarowanym katalogiem.
@@ -501,7 +521,7 @@
 Jeśli napisałeś nowe rozszerzenie, lub dodałeś nowe opcje do starego
 rozszerzenia, zwykle dobrze jest zaktualizować także
 netfilter-extension-HOWTO by włączyć opis nowej funkcjonalności. Dodatkowo,
-przyciągnie to więcej użtykowników do rozszerzenia i pozwoli na uzyskanie
+przyciągnie to więcej użytkowników do rozszerzenia i pozwoli na uzyskanie
 więcej informacji od użytkowników.
 </sect1>
 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Polish FAQ update.
  2003-06-26 14:02 [PATCH] Polish FAQ update Maciej Soltysiak
@ 2003-06-27 23:25 ` Fabrice MARIE
  2003-06-27 15:29   ` Maciej Soltysiak
  0 siblings, 1 reply; 5+ messages in thread
From: Fabrice MARIE @ 2003-06-27 23:25 UTC (permalink / raw)
  To: netfilter-devel


Hello,

On Thursday 26 June 2003 22:02, Maciej Soltysiak wrote:
> Hello,
> this patch:
> - adds a missing section 3.17
> - adds the translated section 3.18 about REJECT
> - corrects typos
> - introduces smoother and less crappy jargon-like vocabulary.
> Please apply.

Your patch yields rejects for me here.. :
[root@localhost pl]# patch -p0 < /home/fabrice/patch2.diff 
patching file netfilter-faq.sgml
Hunk #9 FAILED at 127.
Hunk #10 succeeded at 153 with fuzz 2.
Hunk #13 succeeded at 272 with fuzz 2.
Hunk #20 succeeded at 426 with fuzz 1.
1 out of 23 hunks FAILED -- saving rejects to file netfilter-faq.sgml.rej

Could you send the patch again, this time mime encoded ?

Dziękuję.

Have a nice day,

Fabrice,
--
Fabrice MARIE

"Silly hacker, root is for administrators"
       -Unknown

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Polish FAQ update.
  2003-06-27 15:29   ` Maciej Soltysiak
@ 2003-06-27 23:43     ` Fabrice MARIE
  0 siblings, 0 replies; 5+ messages in thread
From: Fabrice MARIE @ 2003-06-27 23:43 UTC (permalink / raw)
  To: netfilter-devel


Hello,

On Friday 27 June 2003 23:29, Maciej Soltysiak wrote:
> > Could you send the patch again, this time mime encoded ?
> Sure.
> > Dziękuję.
> Proszę.
> > Fabrice
> Maciej

This time the patch applied without a glitch. Please check that all the
accents are still fine :)

Have a nice day,

Fabrice.
--
Fabrice MARIE

"Silly hacker, root is for administrators"
       -Unknown

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH] Polish FAQ update
@ 2003-12-11 10:15 Maciej Soltysiak
  0 siblings, 0 replies; 5+ messages in thread
From: Maciej Soltysiak @ 2003-12-11 10:15 UTC (permalink / raw)
  To: netfilter-devel

[-- Attachment #1: Type: text/plain, Size: 3289 bytes --]

Hi,

this patch fixes my screwups with the translation.

Also I'd like to point out, that there is a problem with
sgmltools and linuxdoc-tools. They both have has bad translations of
polish words for:
Next, Previous, Index
They have:
Nastny, Poprzedni, Spis Trei
instead of:
Następny, Poprzedni, Spis Treści

I have just sent the patch to the maintainer of Lang.pm.
You might want to patch your
/usr/share/linuxdoc-tools/LinuxDocTools/Lang.pm
(or whatever the path is for Lang.pm)
with the Lang.pm.diff patch.

I can't belive it hasn't been fixed yet. I have noticed it about 1,5 year
ago :-|
Okay, here they go: FAQ patch, Lang.pm patch.


Index: documentation/FAQ/pl/netfilter-faq.sgml
===================================================================
RCS file: /cvspublic/netfilter/documentation/FAQ/pl/netfilter-faq.sgml,v
retrieving revision 1.8
diff -u -r1.8 netfilter-faq.sgml
--- documentation/FAQ/pl/netfilter-faq.sgml 16 Oct 2003 07:36:38 -0000 1.8
+++ documentation/FAQ/pl/netfilter-faq.sgml 11 Dec 2003 10:03:45 -0000
@@ -4,10 +4,8 @@

 <title>netfilter/iptables FAQ</title>
 <author>Harald Welte &lt;laforge@gnumonks.org&gt;&nl;
-<date>Version $Revision: 1.8 $, $Date: 2003/10/16 07:36:38 $</date>
+<date>Version $Revision: 1.9 $, $Date: 2003/12/11 10:55:39 $</date>
 Tłumaczenie: Maciej Sołtysiak<tt><htmlurl name="solt@dns.toxicfilms.tv"
url="mailto:solt@dns.toxicfilms.tv"></tt></author>
-<date>Version $Revision: 1.8 $, $Date: 2003/10/16 07:36:38 $</date>
-Tłumaczenie: Środa 15 Października 2003 $</date>

 <abstract>
 Ten dokument zawiera najczęściej zadawane pytania (Frequently Asked
Questions) występujące na liście
@@ -123,8 +121,6 @@
 jest w iptables. Zerknij w NAT HOWTO na stronach domowych netfiltra.
 </sect1>

-</sect>
-
 <sect1>Czy iptables/ip6tables jest w stanie zrobić IPv6 NAT?
 <p>
 Nie, rdzeń NAT nie obsługuje transjacji IPv6 lub IPv6/IPv4 jakiegokolwiek
@@ -144,8 +140,6 @@
 </sect1>

 <sect1>Czy netfilter/iptables wspiera failover/HA?
-
-Does netfilter/iptables support failover/HA?
 <p>
 Odpowiedź jest prosta 'tak' i 'nie'.
 <p>
@@ -159,7 +153,7 @@
 <p>Jeśli chcesz przechować połączenia NAT: <bf>Nie</bf>.
 <p>Jeśli filtrujesz bez przechowywania stanu (stateless): <bf>Tak</bf>
 </sect1>
-
+</sect>


 <sect>Problemy podczas kompilacji
@@ -280,9 +274,7 @@
 <tscreen><verb>
 ip_conntrack: max number of expected connections N of M reached for
aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb
 </verb></tscreen>
-</sect1>

-<sect1>
 <p>
 Zasadniczo nie ma się czym przejmować, szczególnie gdy <tt>N</tt> i
 <tt>M</tt> sa <tt>1</tt>, a po tej wiadomości jest <tt>, reusing</tt>.


--- Lang.pm~ 2002-03-25 14:46:40.000000000 +0100
+++ Lang.pm 2003-12-11 11:07:41.000000000 +0100
@@ -185,7 +185,7 @@
      "it" => "Avanti",
      "ro" => "Înainte",
      "ja" => "źĄ¤ÎĽÚĄźĽ¸",
-     "pl" => "Nastny",
+     "pl" => "Następny",
      "ko" => "´ŮŔ˝"
   },
   "Contents" => {
@@ -201,7 +201,7 @@
      "it" => "Indice",
      "ro" => "Cuprins",
      "ja" => "ĚÜźĄ¤Ř",
-     "pl" => "Spis Trei",
+     "pl" => "Spis Treści",
      "ko" => "Â÷ˇĘ"
   },
   "Table of Contents" => {
@@ -217,7 +217,7 @@
      "it" => "Indice Generale",
      "ro" => "Cuprins",
      "ja" => "ĚÜźĄ",
-     "pl" => "Spis Trei",
+     "pl" => "Spis Treści",
      "ko" => "Â÷ˇĘ"
   }
 };

[-- Attachment #2: Lang.pm.diff --]
[-- Type: application/octet-stream, Size: 709 bytes --]

--- Lang.pm~	2002-03-25 14:46:40.000000000 +0100
+++ Lang.pm	2003-12-11 11:07:41.000000000 +0100
@@ -185,7 +185,7 @@
      "it" => "Avanti",
      "ro" => "Înainte",
      "ja" => "¼¡¤Î¥Ú¡¼¥¸",
-     "pl" => "Nastny",
+     "pl" => "Nastêpny",
      "ko" => "´ÙÀ½"
   },
   "Contents" => {
@@ -201,7 +201,7 @@
      "it" => "Indice",
      "ro" => "Cuprins",
      "ja" => "Ìܼ¡¤Ø",
-     "pl" => "Spis Trei",
+     "pl" => "Spis Tre¶ci",
      "ko" => "Â÷·Ê"
   },
   "Table of Contents" => {
@@ -217,7 +217,7 @@
      "it" => "Indice Generale",
      "ro" => "Cuprins",
      "ja" => "Ìܼ¡",
-     "pl" => "Spis Trei",
+     "pl" => "Spis Tre¶ci",
      "ko" => "Â÷·Ê"
   }
 };

[-- Attachment #3: faq.diff --]
[-- Type: application/octet-stream, Size: 2029 bytes --]

Index: documentation/FAQ/pl/netfilter-faq.sgml
===================================================================
RCS file: /cvspublic/netfilter/documentation/FAQ/pl/netfilter-faq.sgml,v
retrieving revision 1.8
diff -u -r1.8 netfilter-faq.sgml
--- documentation/FAQ/pl/netfilter-faq.sgml	16 Oct 2003 07:36:38 -0000	1.8
+++ documentation/FAQ/pl/netfilter-faq.sgml	11 Dec 2003 10:03:45 -0000
@@ -4,10 +4,8 @@
 
 <title>netfilter/iptables FAQ</title>
 <author>Harald Welte &lt;laforge@gnumonks.org&gt;&nl;
-<date>Version $Revision: 1.8 $, $Date: 2003/10/16 07:36:38 $</date>
+<date>Version $Revision: 1.9 $, $Date: 2003/12/11 10:55:39 $</date>
 T³umaczenie: Maciej So³tysiak<tt><htmlurl name="solt@dns.toxicfilms.tv" url="mailto:solt@dns.toxicfilms.tv"></tt></author>
-<date>Version $Revision: 1.8 $, $Date: 2003/10/16 07:36:38 $</date>
-T³umaczenie: ¦roda 15 Pa¼dziernika 2003 $</date>
 
 <abstract>
 Ten dokument zawiera najczê¶ciej zadawane pytania (Frequently Asked Questions) wystêpuj±ce na li¶cie
@@ -123,8 +121,6 @@
 jest w iptables. Zerknij w NAT HOWTO na stronach domowych netfiltra.
 </sect1>
 
-</sect>
-
 <sect1>Czy iptables/ip6tables jest w stanie zrobiæ IPv6 NAT?
 <p>
 Nie, rdzeñ NAT nie obs³uguje transjacji IPv6 lub IPv6/IPv4 jakiegokolwiek
@@ -144,8 +140,6 @@
 </sect1>
 
 <sect1>Czy netfilter/iptables wspiera failover/HA?
-
-Does netfilter/iptables support failover/HA?
 <p>
 Odpowied¼ jest prosta 'tak' i 'nie'.
 <p>
@@ -159,7 +153,7 @@
 <p>Je¶li chcesz przechowaæ po³±czenia NAT: <bf>Nie</bf>.
 <p>Je¶li filtrujesz bez przechowywania stanu (stateless): <bf>Tak</bf>
 </sect1>
-
+</sect>
 
 
 <sect>Problemy podczas kompilacji
@@ -280,9 +274,7 @@
 <tscreen><verb>
 ip_conntrack: max number of expected connections N of M reached for aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb
 </verb></tscreen>
-</sect1>
 
-<sect1>
 <p>
 Zasadniczo nie ma siê czym przejmowaæ, szczególnie gdy <tt>N</tt> i
 <tt>M</tt> sa <tt>1</tt>, a po tej wiadomo¶ci jest <tt>, reusing</tt>.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-12-11 10:15 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-06-26 14:02 [PATCH] Polish FAQ update Maciej Soltysiak
2003-06-27 23:25 ` Fabrice MARIE
2003-06-27 15:29   ` Maciej Soltysiak
2003-06-27 23:43     ` Fabrice MARIE
  -- strict thread matches above, loose matches on Subject: below --
2003-12-11 10:15 Maciej Soltysiak

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.