Oliver Smith z Canonicalu shrnuje základní vlastnosti „neměnné“ distribuce Ubuntu Core také ve srovnání s protějšky Chrome OS, Fedora Silverblue a MicroOS. Canonical připravuje desktopovou variantu Ubuntu Core vedle dosavadní serverové/embedded.
Z aktualizovaného seznamu chyb (pdf) procesoru AMD EPYC 7002: #1474 - procesor se po 1044 dnech od posledního resetu zasekne [reddit].
Fossil (Wikipedie) byl vydán ve verzi 2.22. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
David Malcolm se ve svém příspěvku na blogu vývojářů Red Hatu rozepsal o vylepšeních statické analýzy (volba -fanalyzer) v GCC 13.
Byla vydána nová stabilní verze 23.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Stoat. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Příspěvek na blogu CZ.NIC upozorňuje na nový útok na weby v Česku. Na honeypotech na Turrisech byla zaznamenána nová aktivita útočníků - probíhající útok na FTP servery, které se vyskytují na stejné IP adrese, jako aktivní WEB server.
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi 2023.05. Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Linux Foundation Europe představila projekt RISE (RISC-V Software Ecosystem), jehož cílem je urychlit vývoj open source softwaru pro architekturu RISC-V.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu pro jednodeskové počítače na platformě ARM, byl vydán ve verzi 23.05. Přehled novinek v Changelogu.
Minulý týden proběhla openSUSE Conference 2023. Mimo jiné bylo oznámeno přejmenování systému MicroOS Desktop. MicroOS Desktop GNOME byl přejmenován na openSUSE Aeon a MicroOS Desktop Plasma na openSUSE Kalpa.
/sbin/ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up /sbin/modprobe iptable_nat /sbin/modprobe ip_conntrack_ftp /sbin/iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.0.0/24 -d 0/0 -j MASQUERADE /sbin/iptables -A FORWARD -s 192.168.0.0/24 -d 0/0 -j ACCEPT echo "1">/proc/sys/net/ipv4/ip_forwardkterá fungovala dopoavad bezvadně. Na mém druhém počítači notebooku (192.168.0.2) dnes však přestal správně pracovat prohlížeč. Jde otevřít například domovská stránka - google, ale když dám něco vyhledat a kliknu odkaz nic...Je však zvláštní, že některé servery fungují...například
http://www.idos.cznebo
http://www.redhat.com/magazinegaim funguje...nerozumím tomu...můžete poradit? nebo Zkoušel jsem pingovat některé mé kamarády a ping se nevracel.
1) pripojit z toho serveru na internet ti jde? ping neco_co_na_klientovi_nejde.cz elinks neco_co_na_klientovi_nejde.czano pripojeni ze serveru je neomezene a nemam s nim zadny problem, problem je jen s klientem...jak uz sem rekl klient nezobrazuje vetsinu www serveru...
2) mas dobre nastavene dns servery v /etc/resolf.confano mam ... /etc/resolv.conf nameserver1 *.*.*.* nameserver2 *.*.*.*
3) mas to same nastavene na klientech?ano...mam to tak jak to bylo nastavene drive a jelo to v poradku
4) co ti to vyhodi za hlasku kdyz zkusis z klienta ping/tracert (traceroute)?to mi bohuzel nejde ...dal sem to do konzole tohle..???
traceroute www.seznam.czda
1 192.168.0.1 (192.168.0.1) 0.110 ms 0.070 ms 0.092 ms 2 12.189.broadband3.iol.cz (85.70.189.12) 11.769 ms 12.997 ms 12.372 ms 3 225.189.broadband3.iol.cz (85.70.189.225) 11.760 ms 17.462 ms 17.392 ms 4 80.188.33.241 (80.188.33.241) 25.408 ms 17.780 ms 17.895 ms 5 80.188.33.241 (80.188.33.241) 20.855 ms 21.574 ms 24.364 ms 6 194.228.21.34 (194.228.21.34) 26.409 ms 25.381 ms 29.878 ms 7 nix.tgnet.cz (194.50.100.75) 30.194 ms 17.809 ms 17.721 ms 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *
dmesgKdyztak zvednout limit
cat /proc/sys/net/ipv4/ip_conntrack_max echo "163760" > /proc/sys/net/ipv4/ip_conntrack_max
iptables -L -n -t natdá
target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 192.168.0.0/24 0.0.0.0/0 SNAT all -- 192.168.0.0/24 0.0.0.0/0 to:85.71.153.199 Chain OUTPUT (policy ACCEPT) target prot opt source destinationa
iptables -L -ndá
Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 192.168.0.0/24 0.0.0.0/0 SNAT all -- 192.168.0.0/24 0.0.0.0/0 to:85.71.153.199 Chain OUTPUT (policy ACCEPT) target prot opt source destination [root@localhost pitat450]# /sbin/iptables -L -n Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT tcp -- 83.208.242.117 0.0.0.0/0 state NEW tcp dpt:21 ACCEPT tcp -- 10.1.4.52 0.0.0.0/0 state NEW tcp dpt:21 ACCEPT tcp -- 10.162.123.204 0.0.0.0/0 state NEW tcp dpt:21 ACCEPT tcp -- 213.29.64.24 0.0.0.0/0 state NEW tcp dpt:21 ACCEPT tcp -- 85.193.50.6 0.0.0.0/0 state NEW tcp dpt:21 ACCEPT tcp -- 85.193.50.2 0.0.0.0/0 state NEW tcp dpt:21 ACCEPT tcp -- 213.250.202.61 0.0.0.0/0 state NEW tcp dpt:21 ACCEPT tcp -- 213.220.221.19 0.0.0.0/0 state NEW tcp dpt:21 ACCEPT all -- 192.168.0.0/24 0.0.0.0/0 state NEW ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:67 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW TRUSTED all -- 0.0.0.0/0 0.0.0.0/0 state NEW Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT all -- 192.168.0.0/24 0.0.0.0/0 state NEW TRUSTED all -- 0.0.0.0/0 0.0.0.0/0 state NEW Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT icmp -- 0.0.0.0/0 192.168.0.0/24 DROP icmp -- 0.0.0.0/0 0.0.0.0/0 state INVALID Chain TRUSTED (2 references) target prot opt source destination ACCEPT icmp -- 0.0.0.0/0 85.71.153.199 icmp type 8 ACCEPT icmp -- 0.0.0.0/0 192.168.0.1 icmp type 8 DROP icmp -- 0.0.0.0/0 0.0.0.0/0 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachableděkuju za pomoc...
23:11:43.181382 IP 88.102.42.160.1041 > 213.29.7.236.80: S 12085437:12085437(0) win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK>
E..@..@.....Xf*........P..h....... .H..............
............
23:11:43.218289 IP 213.29.7.236.80 > 88.102.42.160.1041: S 855744578:855744578(0) ack 12085438 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 7>
E..4..@.:.......Xf*..P..3..B..h.....................
23:11:43.219326 IP 88.102.42.160.1041 > 213.29.7.236.80: . ack 1 win 8760
E..(..@.....Xf*........P..h.3..CP."8.p..
23:11:43.223561 IP 88.102.42.160.1041 > 213.29.7.236.80: P 1:442(441) ack 1 win 8760
E.....@.....Xf*........P..h.3..CP."8....GET /log_form.php?url=http://mail.centru
23:11:43.266289 IP 213.29.7.236.80 > 88.102.42.160.1041: . ack 442 win 54
Nic dalšího pak už na ppp0 z internetu nepřišlo a klient jen čeká a čeká na další data a žádná nedostává.
Nevim jestli není známa nějaká chyba v modulu ip conntrack nebo jestli není někde něco špatně nastavené, jestli se třeba nepřeplnilo nějaké pole.já mám také kernel 2.6 má Fedoru 5 a mám jí teď čerstvě nainstalovanou, to si myslím že vylučuje možnost přehlcení nějaké tabulky... jinak jak už sem řekl když bootnu (dualboot) vydle tak to jede ok...což znamená DNS sou taky ok...nějaké nastavení, ale jakto že to fungovalo a najednou ne! To by ukazovalo na nějakou změnu DNS serverů, já fakt nevim, každopádně sem fakt zvědavej čím to je...
Všiml jsem si, že soubory pod určitou velikost se stáhnou. Soubory nad určitou velikost se nestáhnou. Takže třeba malé obrázky se objeví, krátké HTML se objeví, ale třeba dlouhé CSS soubory se nenačtou nebo velké obrázky se nenačtou, taktéž dlouhé HTML kódy se nenačtou.Hm, rozbité Path MTU Discovery? Howto na LARTC by mohlo pomoci.
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 128
Kdybych si byl býval podrobně přečetl celé man iptables, tak bych to tam našel, přesně tento problém tam je popsán.
Odteď to perfektně funguje. Vřelé díky! :)
Pokud při prázdném FORWARD s policy ACCEPT a POSTROUTING v tabulce NAT správně nastaveném pro maškarádu ti fungují jen některé URL - to jest že webbrowser na klientu se připojí, pošle request, ale nedostane zpátky data (případně dostane jen na některé requesty), pak by to mohl být stejný problém jako u mne.
Takže když vyzkoušíš to, co radí na http://lartc.org/howto/lartc.cookbook.mtu-mss.html, tak by to mohlo pomoct.
Pomocí tcpdump jsem při porovnání komunikace z routeru na určitou www stránku s komunikací z klienta na tu samou www stránku dohledal, že z klienta přes router všecko prošlo, ale zpátky se vrátila jen část paketů. Nastavenímiptables -I FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 128
Feb 10 12:27:28 router pppd[518]: Couldn't increase MTU to 1500 Feb 10 12:47:52 router pppd[519]: Couldn't increase MTU to 1500 Feb 10 12:50:31 router pppd[854]: Couldn't increase MTU to 1500 Feb 10 13:03:13 router pppd[517]: Couldn't increase MTU to 1500 Feb 10 13:03:23 router pppd[853]: Couldn't increase MTU to 1500 Feb 10 19:40:27 router pppd[519]: Couldn't increase MTU to 1500dík
This target is used to overcome criminally braindead ISPs or servers
which block ICMP Fragmentation Needed packets. The symptoms of this
problem are that everything works fine from your Linux firewall/router,
but machines behind it can never exchange large packets:
Docela by me zajimalo, ktery cesky ISP je "criminally braindead".
Mozna je to novy trend jak zabranit sdileni linek.
Tiskni
Sdílej: