Byla vydána nová stabilní verze 24.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Uakari. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Byla vydána nová verze 1.48.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Fernando F. Mancera. Mimo jiné se v nastavení místo mac-address-blacklist nově používá mac-address-denylist.
Před 25 lety, 31. května 1999, započal vývoj grafického editoru Krita (Wikipedie). Tenkrát ještě pod názvem KImageShop a později pod názvem Krayon.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 24.05.0 editoru videa Kdenlive (Wikipedie). Ke stažení brzy také na Flathubu.
David Revoy, autor mj. komiksu Pepper&Carrot, se rozepsal o své aktuální grafické pracovní stanici: Debian 12 Bookworm, okenní systém X11, KDE Plasma 5.27, …
Wayland (Wikipedie) byl vydán ve verzi 1.23.0. Z novinek lze vypíchnout podporu OpenBSD.
Craig Loewen na blogu Microsoftu představil novinky ve Windows Subsystému pro Linux (WSL). Vypíchnout lze GUI aplikaci pro nastavování WSL nebo správu WSL z Dev Home.
V sobotu 1. června lze navštívit Maker Faire Ostrava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Webový server Caddy (Wikipedie) s celou řadou zajímavých vlastností byl vydán ve verzi 2.8 (𝕏). Přehled novinek na GitHubu.
Byla vydána verze 3.0 (@, 𝕏) svobodného softwaru HAProxy (The Reliable, High Performance TCP/HTTP Load Balancer; Wikipedie) řešícího vysokou dostupnost, vyvažování zátěže a reverzní proxy. Detailní přehled novinek v příspěvku na blogu společnosti HAProxy Technologies.
Problem je jasny - nemam nativni ipv6 konektivitu a chtel jsem rozjet ipv6 v cele lokalni siti. 6to4 podle clanku na wikipedii vypadalo jako idealni reseni. Prefix 2002::/16 vyhrazen pro 6to4 ipv6 adresy odpovidajici ipv4 adresam a verejny anycast 2002:c058:6301:: slouzici jako open gateway k nativni ipv6. Pro pruchod ipv4 siti se ipv6 packety obali ipv4 hlavickou, cilova ipv4 adresa se nastavi podle cilove ipv6 adresy (z adresy 2002:aaaa:bbbb:: se pouzije aaaa:bbbb) a hlavicka protokol na ipv6. Pro tento prevod se na linuxu pouziva spec. tunel typu "sit". Vse vypadalo jako zalezitost nekolika prikazu. Jenze.
Najit problem bylo o to horsi, ze nebyl na me strane jako vzdy, ale anycast 2002:c058:6301:: zatim holt nefunguje a je potreba pouzit adresu ::192.88.99.1 - prefix ::/96 se pouzival pro podobne ucely driv. Toto vedet, tak tim nestravim x hodin a nezverejnuju tento navod - nastavit radvd (daemon starajici se o Neighbour Discovery) uz byla lahudka.
Nejdriv je potreba povolit prijmani a odesilani ipv4 packetu s protokol = ipv6 v hlavicce. Takoveto packety neprojdou pres NAT, takze je potreba vse nastavovat na stroji s verejnou ip.
iptables -I INPUT -p ipv6 -j ACCEPT iptables -I OUTPUT -p ipv6 -j ACCEPT
Vytvorit zarizeni "sit0" ktere bude ipv6 packety obalovat ipv4 hlavickou
ip tunnel add sit0 mode sit ip link set sit0 uptunely jde vypsat takto
ip tunnel show
Ted uz jen pridat ipv6 adresu a nastavit routovani 6to4 adres (2002::/16) pres sit0. Jako ipv6 adresu muzete nastavit cokoliv ve tvaru 2002:aaaa:bbbb:cokoliv. kde aaaa:bbbb je verejna ipv4 adresa stroje. Chodžto se pro ipv6 pouziva jina notace je potreba prevest desitkovy zapis ip adresy na sestnactkovy:
#128.13.13.13 je verejna ip stroje printf "2002:%02x%02x:%02x%02x::1" 128 13 13 13 # + pridani prefixu 2002: + adresa prefix::1
verejnou adresu hezky vraci whatismyip.org:
printf "2002:%02x%02x:%02x%02x::1\n" `curl -s whatismyip.org|tr "." " "`
pridani adresy
ip -6 a a 2002:XXXX:ZZZZ::1/16 dev sit0
Od ted stroj umi 6to4
ping6 6to4.nro.net
Ale bylo by hezke domluvit se i s nativni ipv6 - stacilo by pridat default gateway 2002:c058:6301:: - ale tyto relay jeste nepodporuji "novy" standard, takze je potreba pouzit ::192.88.99.1 (coz neni takovy problem, protoze pri nahozeni sit0 rozhrani se samy vytvorili ipv6 adresy ::ipv4/96)
ip -6 route add default via ::192.88.99.1 ping6 www.kame.net ping6 ipv6.google.com
Delat gateway pro jiny nez vas subnet je zbytecne a nez si zvykenete na ipv6 tak muzete nasimulovat vedlejsi efekty NAT 
ip6tables -I FORWARD -i sit0 -o sit0 -j DROP ip6tables -I FORWARD -i sit0 -m state --state NEW -j DROP
Ted zbyva zpristupnit ipv6 ve zbytku lokalni site. Nejdriv povolte forwardovani
echo 1 > /proc/sys/net/ipv6/conf/default/forwarding
Nastavte routovani tak, aby router vedel kde najit masinky
# XXXX:ZZZZ je samozrejme verejna ipv4 v hexadecimalnim tvaru ip -6 route add 2002:XXXX:ZZZZ::/48 dev eth3 # k eth3 je pripojena lokalni sit
Navic je potreba distribuovat verejny prefix lokalni siti a tim umoznit autokonfiguraci - na to se hodi radvd
aptitude install radvd cp /usr/share/doc/radvd/examples/simple-radvd.conf /etc/radvd.conf
Tento konfigurak je velice jednoduchy ale dela(spolu s vychozim nastavenim) to co je potreba.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
cat /usr/share/doc/radvd/examples/simple-radvd.conf
interface eth0
{
AdvSendAdvert on;
prefix 2001:db8::/32
{
};
};
Jedine co je potreba zmenit - interface kam chceme prefix distribuovat a samotny prefix - jako prefix ale neni idealni pouzit 48 bitu dlouhy prefix - klienti ho pak nepouziji pro autokonfiguraci - ale je potreba ho prodlouzit na /64
Update: Navic je tu problem s MTU (maximalni velikost packetu kterou je zarizeni schopno prenest) tunelu sit0, ktery je o 20B (hlavicky) mensi nez MTU rozhrani ktere vyuziva (u neethernet rozhrani je potreba nastavit rucne - napr. na 1472 u sit pres pppoe). Jelikoz na masinkach na nasi sit mame MTU 1500 a tudiz MSS (hodnota (cast tcp hlavicky) kterou system oznamuje jakou maximalni velikost by mel mit prenaseny packet ; vychozi MTU-60) po pricteni ipv6 hlavicek je vetsi nez MTU naseho routeru muze dochazet k problemum - ty by melo resit pmtud, ale bohuzel hodne firewallu zahazuje imcp packety. Proto je potreba nastavit MSS na nasich masinka v siti rucne na MTU sit0 routeru - 60 (60B pro ipv6 hlavicky). Tuto hodnotu nejde ale oznamovat pres ND a proto musime sirit MTU - coz neni idealni reseni problemu, ale jelikoz toto MTU budou mit vsechny systemy stejne - nebude to zpusobovat problemy. Proto je potreba do radvd.conf pridat jeste nastaveni.
AdvLinkMTU 1480;
cat /etc/radvd.conf
interface eth3
{
AdvSendAdvert on;
AdvLinkMTU 1480;
prefix 2002:XXXX:ZZZZ::/64
{
};
};
/etc/init.d/radvd restart # nacteni noveho konfigu
Nastaveni prikazy ip a ifconfig ale samozrejme neprizije restart a stejne tak nastaveni v /proc. Jak tyto hodnoty nastavit po restartu se bohuzel casto lisi od distribuce, dale pro debian (a ubuntu):
ulozit nastaveni iptables a ip6tables
/etc/init.d/iptables save active /etc/init.d/ip6tables save active
povolit ipv6 forwardovani po rebootu, v souboru /etc/sysctl.conf
net.ipv6.conf.default.forwarding=1)
nastaveni tunelu a routovani po rebootu, v soboru /etc/network/interfaces
auto sit0 eth3 iface sit0 inet6 static pre-up /sbin/ip tunnel add sit0 mode sit pre-up /sbin/ip link set sit0 up address 2002:XXXX:ZZZZ::1 netmask 16 gateway ::192.88.99.1 iface eth3 .... .... konfigurace lokalniho ipv4 eth3 .... post-up /sbin/ip -6 route add 2002:XXXX:ZZZZ::/48 dev eth3
Tiskni
Sdílej:
28.7.2008 16:33
David Watzke | skóre: 74
| blog: Blog...
| Praha
cd /etc/init.d && ln -s net.lo net.sit0a pak přidat do
/etc/conf.d/net
link_sit0="eth0" # eth0 je internet
config_sit0="ip6to4"
depend_sit0() {
need net.eth0
}
Toto je alternativa pouze k
iface sit0 inet6 static pre-up /sbin/ip tunnel add sit0 mode sit pre-up /sbin/ip link set sit0 up address 2002:XXXX:ZZZZ::1 netmask 16 gateway ::192.88.99.1Ale je stejne to ma gentoo vyreseno hezci nez stable deb
28.7.2008 22:17
David Watzke | skóre: 74
| blog: Blog...
| Praha
Si asi moc daleko nedocetl - asi ani na konec prvni vetySpíš jsem reagoval na tvoje
Jak tyto hodnoty nastavit po restartu se bohuzel casto lisi od distribuce, dale pro debian (a ubuntu)a doplnil info pro Gentoo. Jinak v6 firewall zatím nepoužívám - mám jen
iptables -A INPUT -i eth0 -p ipv6 -j ACCEPTa prázdno v ip6tables, ale dělá se to snadno, stejně jako u v4 - nastavěj se pravidla, potom
/etc/init.d/ip6tables savea pak stačí ip6tables přidat do nějakýho runlevelu.
Takoveto packety neprojdou pres NAT, takze je potreba vse nastavovat na stroji s verejnou ip.A jsem tam kde jsem byl
Samozrejme mluvim vo zaNATovanem pripojeni. Ten, kdo ma verejnou IPv4, imho ani moc IPv6 nepotrebuje. Jediny, co se pro nej zmeni bude ze si uz nebude svoji adresu tak snadno pamatovat. A bude cool mezi geeky.
29.7.2008 19:14
David Watzke | skóre: 74
| blog: Blog...
| Praha
.
30.7.2008 09:34
David Watzke | skóre: 74
| blog: Blog...
| Praha
), ale adminum odpadne par problemu - no a ty jeste zavaznejsi snad jeste pred tim nez se objevi. Ale mozna mas pravdu a udrzovat ty workaroundy "naporad" by vyslo levneji. Jiste ze ty to tunnely nejsou nic vic nez tunnely
Proste je potreba presvedcit ISP aby postupne presli na IPv6, jenze, uprimne, kolik z nich je ochotno takovy narocny krok podstoupit...
Benefit je tam, že předtím měli public IP jednu na celou síť, teďka maj jednou na každej počítač.No mit kazdy pocitac v siti doahnutelny z venku mi teda jako naka vyhoda taky nepripada.
No mit kazdy pocitac v siti doahnutelny z venku mi teda jako naka vyhoda taky nepripada.Ve své síti můžeš nasadit firewall na hraniční router.
Pokud potrebuju nakou sluzbu na nakym pocitaci z vnitrni site propojit s necim z venku, naroutuju prislusnej port/porty ne?A když ji potřebuješ na dvou počítačích tak uděláš co?
No mit kazdy pocitac v siti doahnutelny z venku mi teda jako naka vyhoda taky nepripada.Pokud nebude dosažitelný vůbec, můžeš odpojit kabel.
Ja preferuju reseni, kdy nemusim mit na kazdym pocitaci super silnej firewall. Pokud potrebuju nakou sluzbu na nakym pocitaci z vnitrni site propojit s necim z venku, naroutuju prislusnej port/porty ne?Taky preferuju toto řešení, ale s veřejnými adresami. Já radši bezpečnost vyřešenou pořádně a bez zkriplených služeb.
Nojo, nekdo zas predpoklada ze kdyz neni na kazdym pocitaci public IP tak jsou zkrpleny sluzby...A nejsou snad? FTP - nefunguje v normálním režimu. Podle conntrack modulů dále nefungují IRC, SIP, H.323 a dost dalších. Přenášení souborů v Jabberu a dalších IM sítích - nefunguje. Torrent a další P2P - zpravidla fungují hůř. A tak dál. Tohle všechno jsou věci, které obtěžují normálního uživatele, který je za NATem a kterému je to, že si někdo může forwardovat porty, úplně k ničemu. Protože k čemu je mi, že lze forwardovat porty, když Jabber prostě čeká, že soubory se přenášejí na 8010 a tečka.
Pokud potrebuju ve firme FTP, udelam jeden server s public IP pristupnou jak zvenku tak zevnitr (vicero interface) a bude to ne?Ne, minimalne budes muset jeste udrzovat dve ruzny dns zone a dve ruzny konfigurace ftp serveru - oproti reseni s dostatkem adres a firewallu bez NAT.
Proč?Pokud potrebuju ve firme FTP, udelam jeden server s public IP pristupnou jak zvenku tak zevnitr (vicero interface) a bude to ne?Ne, minimalne budes muset jeste udrzovat dve ruzny dns zone
a dve ruzny konfigurace ftp serveruProč?
- oproti reseni s dostatkem adres a firewallu bez NAT.Veřejná IPv4 adresa funguje stejně dobře jako veřejná IPv6, problém vidím v počtu adres.
Ne, minimalne budes muset jeste udrzovat dve ruzny dns zone Proč?V lokalni siti budes prece ke sluzbe pristupovat pres jine ip nez z venku.
a dve ruzny konfigurace ftp serveru Proč?www.proftpd.org/docs/directives/linked/config_ref_MasqueradeAddress.html , samozrejme ze tuto hodnotu muzou nejake ftp servery resit chytreji, ale potom te NAT omezuje na pouziti jen vyvoleneho kodu - a to je jeste horsi.
Proč? Nevidím žádný důvod a ani to tak nedělám.Ne, minimalne budes muset jeste udrzovat dve ruzny dns zone Proč?V lokalni siti budes prece ke sluzbe pristupovat pres jine ip nez z venku.
FTP sice nepoužívám, ale ani k tomuhle nevidím rozumný důvod. Pokud je rozumně nakonfigurovaná síť, tak ani jeden z těch dvou problémů nenastane.a dve ruzny konfigurace ftp serveru Proč?www.proftpd.org/docs/directives/linked/config_ref_MasqueradeAddress.html , samozrejme ze tuto hodnotu muzou nejake ftp servery resit chytreji, ale potom te NAT omezuje na pouziti jen vyvoleneho kodu - a to je jeste horsi.
Zajimavy.To jistě.
Ten ftp server je za DNAT.To je nová informace, kterou jsi asi zapoměl napsat.
Jak to nastavis aby packety chodily s odpovidajici src MACIP protokol žádný MAC adresy nezná (MAC adresy jsou o vrstvu níž). Takže nezájem, do toho FTP serveru ani klientu vůbec nic neni.
a src IPPokud by server nebyl za DNAT, vůbec nic by se neřešilo, takhle v přidáš nějaký pravidlo navíc.
a nechodil veskery traffic pres gw?Proč? Od čeho ji máme? (Teda pokud to s tím "veškterý traffic" nemyslíš obecněji než jsem to pochipil, ale to by nenastalo.)
To je nová informace, kterou jsi asi zapoměl napsat.Nojo, spatne jsem precetl ten kralykuv prispevek - auu
Ale v tom pripade je to cely uplne mimo
Ale jo kdyz na gw nastavis DNAT i pro -i lokalni_if, tak ti ten packet (ktery z lokalu posles na ftp://public_ip:ftpport ) pak na ftp server prijde stejnej jak z lokalu az na src MAC adresu - a system ho pak muze zahoditJak to nastavis aby packety chodily s odpovidajici src MACIP protokol žádný MAC adresy nezná (MAC adresy jsou o vrstvu níž). Takže nezájem, do toho FTP serveru ani klientu vůbec nic neni.
Proč? Od čeho ji [gw] máme?Protoze druha moznost je udelat DNAT i MASQUERADE pro -i lokalni_if -d public_ip --dport ftp - a pak traffic kterej by sel jen mezi client->ftp server pude client->gw->ftp server PS: to -i lokalni_if je obecnejsi, v iptables budes muset pouzit ip adresy
Ale v tom pripade je to cely uplne mimo
packet (ktery z lokalu posles na ftp://public_ip:ftpport ) pak na ftp server prijde stejnej jak z lokalu az na src MAC adresuAž na to, že jsi zapoměl, že IP packet žádnou MAC adresu nemá. Nehledě na to, že stačí vědět, co chceš a nastavit to, žádnej jinej než znalostní problém tu fakt nehledej.
Takze by stacilo na "ftp serveru" "fejkovat" src adresu a bude ti chodit pres gateway jen cast trafficu ktery by nemusel vubec, ale stejne toto udrzovat neni zrovna nejpohodlnejsi.
Rad se priucim, kdyz ukazes jak nastavit aby byl server pristupny pres verejnou ip z klienta ktery je na stejnem segmentu a zaroven byl pristupny z internetu (ale nemas dostatek ip adres takze je za NATem) - navic spojeni mezi klientem a serverem samozrejme nemuze jit zbytecne pres gateway (krome inicializace).
Tim se problem posouvaProblém, který nikdy neexistoval se nikam neposouvá.
ale nemas dostatek ip adres takze je za NATemPokud nemáš dostatek IP adres (tzn ani jednu), nemáš kde provozovat NAT (a provozuje ho někdo jiný). Pokud máš jednu veřejnou adresu, není nutné provozovat tak složitá řešení. Pokud se přecejenom z nějakého důvodu rozhodneš to řešit složitě, tak máš možnost si nastudovat, jak TCP/IP funguje a jak funguje firewall. A jestli chceš detailní přednášku, tak u toho potřebuju aspoň na stůl dostat pořádnej kus masa a nějaký pivo :D.
samozrejme nemuze jit zbytecne pres gatewayA jakou by sis přál barvu tý gateway? A smí být napájená elektřinou? Hele a přes switch to taky nesmí jít, co? Začínám mít nepříjemný pocit, že jen ztrácím čas tím, že se snažím přesvědčit někoho, že existuje jednoduché a funkční řešení, zatímco ten člověk se snaží nalézt takové podmínky, aby se mohl hřát u srdce, až tomu řešení jakkoliv zabrání.
. Mas jednu adresu (ale nemas dostatek aby si mel alespon jednu pro kazdy stroj pristupny z Netu (i to je malo ale), takze na gateway(ta ma jedina verejnou ip) provozujes SNAT a navic DNAT k ruznym serverum ktere bezi na jinych strojich. Sluzby na techto serverech chces mit pristupne i z Netu i z LAN. Proto potrebujes ty skaredosti jako dva proftpd s dvema ruznyma konfigama (MasqueradeAddress) a spravovat dve ruzne dns zone _a nebo_ cpat vsechen traffic pres tuto gw.
) - i kdyz to by stejne jako to prvni reseni nefungovalo s proftpd a passive ftp . Vsechny tyhle workaroundy ale slouzi pouze k tomu aby router a server mohly bezet na jinem stroji - kdybys chtel mit verejne sluzby na vic strojich nez mas adres tak jedine kdyz na routeru _NATujes veskery traffic_ k temto serverum (a nebo k nim pristupovat pomoci ruznych adres )
Kazdopadne verim ze bys dokazal vymyslet jak poresit i toto bez zbytecneho NATu gigabitoveho trafficu ale ta moje reakce na puvodni kralykuv komentar mela ukazat ze i kdyz mas verejnou ip adresu ale nemas _minimalne_ jednu pro kazdy stroj na kterem chces mit sluzby pristupny z Netu tak to znacne zkomplikuje reseni site.
To je nová informace, kterou jsi asi zapoměl napsat.A precejen jsem to napsal
oproti reseni s dostatkem adres a firewallu bez NAT.
A myslim si ze existujou lepsi reseni (nez verejna sit i NAT).Třeba živit se v jinym oboru? :D Nebo... to odříznout od internetu úplně? Nebo... zkriplit sluby víc - to je nejčastější řešení... pustit třeba jen HTTP přes proxy.
a co se tyce tech ostatnich jako voip apod. tak pokud budou ve firme vyuzivany, stejne budou pravdepodobne jen interni...Můžeš určovat pravidla svojí firmě, jiný firmy to můžou mít jinak.
Neboli nejak zkryplim sluzby, jak tomu ty s oblibou rikas (i kdyz nevim co je na tom zkryplenyho). Jestli chces, aby vsechny tvoje pocitace/nody v tvoji siti byly zvenku jako celek pristupny se vsema sluzbama co na nich kdo spusti nebo nespusti tak prosim, kdo chce kam, pomozme mu tam, anebo proti gustu zadny disputat...Podsouváš mi skoro opak toho, co jsem řekl. Nepozorný čtenář by ti to mohl sežrat a mě nebaví pořád vysvětlovat, co jsem napsal a co ne.
nastavim tam pravidla aby poustel jen nektery sluzby nekterym smerem na nektere adresy vevnitr.Ano, tomu se říká firewall. Dokonce se tomu říkalo firewall ještě než začaly docházet adresy a vymýšlely se různé obezličky. Je tu ještě jeden problém s NATem. Ve skutečnosti nemusí vůbec dělat to, co si myslíš a za některých okolností by tě to mohlo ještě dost překvapit. On totiž nechrání úplně stejně jako firewall, který pustí jen odchozí spojení. Dokonce různé implementace NATu můžou mít velmi různé vlastnosti. Je to asi jako si koupit zaručeně bezpečný zámek u vietnamců, možná funguje a možná taky ne.
a co se tyce tech ostatnich jako voip apod. tak pokud budou ve firme vyuzivany, stejne budou pravdepodobne jen interni...Možná, možná ne. Když už by šlo o firmu, tak řešením by mohlo být firewall zakazující všechno dovnitř + výjimky ze zákazu pro služby, které se ve firmě používají a je potřeba, aby byly dostupné zvenku (např. ty telefony).
Nojo, nekdo zas predpoklada ze kdyz neni na kazdym pocitaci public IP tak jsou zkrpleny sluzby... Takovy lidi se taky podepsali na ipv4 adress drain...Jasně :D. Tak když se nepřešlo včas na dostatečně velkej prostor čísel... tak radši z problémů obviníme, ty, kteří chtějí ty čísla využívat. Přečti si někdy, co se píše na webu RIPE o IP adresách. Mají být přidělovány podle potřeby a zdarma. Můj názor, že přirozených čísel existuje je dost na to, aby se daly počítače očíslovat. Stačí jenom používat vhodnej mechanismus, což IPv4 (kvůli nízké horní hranici) už dlouho neni.
Ja preferuju reseni, kdy nemusim mit na kazdym pocitaci super silnej firewall.Jako kdyby to nebylo jedno. Pokud se ti někdo dostane přes silnej FW na hraničním routeru, zvládne to samé i u počítače ve vnitřní síti bez ohledu na to, jestli tam taky máš silnej FW nebo ne.
Alespoň myslím, že si to myslel takhle...
28.7.2008 19:23
3of5 | skóre: 8
| blog: ta_technika
post-up /sbin/ip -6 route add 2002::XXXX:ZZZZ::/48 dev eth3Pozor na jednoznačnost
.
Taky by asi...To spíš zavání řešením (2).
aby router a server mohly bezet na jinem strojiPrávě, což je samo o sobě (jak sám píšeš) nesmysl, pokud nemáme několik samostatnou IP pro server.
Kazdopadne verim ze bys dokazal vymyslet jak poresit i toto bez zbytecneho NATu.Pořešit bez NATu bych to sice asi dokázal, ale musel bych to nahradit podobně komplikovanou technikou. Neexistuje jediný rozumný důvod, proč číslovat internet prostorem, který už nestačí. Pro telefonní čísla ani adresy domů se NAT nepoužívá :). Celý stávající koncept šetření číslama se mi zdá hloupý.
30.7.2008 04:57