* [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 <laforge@gnumonks.org>&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 >= 2.4.0-test4
+<sect1>Nie mogę skompilować iptables-1.1.1 z jądrem >= 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 (>= 2.3.99-pre8)
+<sect1>Nie mogę skompilować iptables 1.1.0 z ostatnimi jądrami (>= 2.3.99-pre8)
<p>
Wewnętrzne struktury w iptables zmieniły się. Uaktualnij iptables do >= 1.1.1
</sect1>
-<sect1>Niektóre patche patch-o-matic z iptables-1.2.1a nie działają z kernelem >= 2.4.4
+<sect1>Niektóre łaty patch-o-matic z iptables-1.2.1a nie działają z jądrem >= 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 <= 1.2.2, <bf>MUSISZ</bf> zastosować patche 'dropped-table' i 'ftp-fixes'.
+Jeśli używasz iptables <= 1.2.2, <bf>MUSISZ</bf> zastosować łaty 'dropped-table' i 'ftp-fixes'.
<p>
-Jeśli używasz iptables > 1.2.2 lub swieży CVS, proszę <bf>nie</bf> stosuj
+Jeśli używasz iptables > 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 >= 1.2.1
+Znany błąd. Uaktualnij do najświeższego CVS lub użyj iptables >= 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>[PATCH]</bf>
+<item> Temat zaczynający się od <bf>[PATCH]</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 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 <laforge@gnumonks.org>&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 >= 2.4.0-test4
+<sect1>Nie mogę skompilować iptables-1.1.1 z jądrem >= 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 (>= 2.3.99-pre8)
+<sect1>Nie mogę skompilować iptables 1.1.0 z ostatnimi jądrami (>= 2.3.99-pre8)
<p>
Wewnętrzne struktury w iptables zmieniły się. Uaktualnij iptables do >= 1.1.1
</sect1>
-<sect1>Niektóre patche patch-o-matic z iptables-1.2.1a nie działają z kernelem >= 2.4.4
+<sect1>Niektóre łaty patch-o-matic z iptables-1.2.1a nie działają z jądrem >= 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 <= 1.2.2, <bf>MUSISZ</bf> zastosować patche 'dropped-table' i 'ftp-fixes'.
+Jeśli używasz iptables <= 1.2.2, <bf>MUSISZ</bf> zastosować łaty 'dropped-table' i 'ftp-fixes'.
<p>
-Jeśli używasz iptables > 1.2.2 lub swieży CVS, proszę <bf>nie</bf> stosuj
+Jeśli używasz iptables > 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 >= 1.2.1
+Znany błąd. Uaktualnij do najświeższego CVS lub użyj iptables >= 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>[PATCH]</bf>
+<item> Temat zaczynający się od <bf>[PATCH]</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 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 <laforge@gnumonks.org>&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 <laforge@gnumonks.org>&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.