Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek i s náhledy aplikací v Týden v GNOME a Týden v KDE.
Organizace Apache Software Foundation (ASF) vydala verzi 20 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Desktopové prostředí Cinnamon, vyvíjené primárně pro distribuci Linux Mint, dospělo do verze 6.0. Seznam změn obsahuje především menší opravy a v říjnovém přehledu novinek v Mintu avizovanou experimentální podporu Waylandu.
OpenZFS (Wikipedie), tj. implementace souborového systému ZFS pro Linux a FreeBSD, byl vydán ve verzích 2.2.2 a 2.1.14. Přináší důležitou opravu chyby vedoucí k možnému poškození dat.
V ownCloudu byly nalezeny tři kritické zranitelnosti: CVE-2023-49103, CVE-2023-49104 a CVE-2023-49105 s CVSS 10.0, 8.7 a 9.8. Zranitelnost CVE-2023-49103 je právě využívána útočníky. Nextcloudu se zranitelnosti netýkají.
I letos vychází řada ajťáckých adventních kalendářů. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2023. Pro programátory v Perlu je určen Perl Advent Calendar 2023. Zájemci o UX mohou sledovat Lean UXmas 2023. Pro zájemce o kybernetickou bezpečnost je určen Advent of Cyber 2023…
Byla vydána verze 2.12 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 23.11 Topi. Přehled novinek v Changelogu.
Po 4 měsících vývoje byla vydána nová verze 4.2 multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu a na YouTube.
Byla vydána nová stabilní verze 23.11 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Tapir. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
$ scp -P 22 gNOSVN.2.0.tar.gz user@aa.bb.cc.dd:
Password:
gNOSVN.2.0.tar.gz 100% 648KB 647.9KB/s 00:00
Vysledek naskoci okamzite po zadani hesla a dal uz nic, do promptu se to nevrati. Pro jina IP (zz.xx.cc.vv napriklad) to funguje bez problemu. (Pro kraticke soubory taky.) Na cilovem pocitaci se vytvori prazdny soubor gNOSVN.2.0.tar.gz a visi tam ssh:
30350 ? Ss 0:00 \_ sshd: user [priv]
30355 ? S 0:00 | \_ sshd: user@notty
30356 ? Ss 0:00 | \_ scp -t .
Na vzdaleny pocitac se da zalogovat:
$ ssh user@aa.bb.cc.dd
funguje to normalne. Kdyz jsem na tom pocitaci nalogovany, tak
$ scp -P 22 jmeno@pu.vo.dni.IP:gNOSVN.2.0.tar.gz .
Password:
gNOSVN.2.0.tar.gz 100% 648KB 647.9KB/s 00:00
probehne bez problemu a soubor prenese. (Cili stahnout jde, natlacit nikoli)
Stejne tak se soubor da na vzdalenem pocitaci scp-ckovat sem a tam bez problemu:
$ scp -P 22 gNOSVN.2.0.tar.gz user@127.0.0.1:
Password:
gNOSVN.2.0.tar.gz 100% 648KB 647.9KB/s 00:00
$ scp -P 22 gNOSVN.2.0.tar.gz user@192.168.1.100:
Password:
gNOSVN.2.0.tar.gz 100% 648KB 647.9KB/s 00:00
Cili se zda, ze ten pocitac sam o sobe funguje, ale neco po ceste to zmrsi ... (ten pocitac je za nejakym firewalem/NATem, od ktereho nemam klice - ssh-cknout se zkrz zvladnu, scp funguje jen obracene)
Ma nekdo ideu, cim by to mohlo byt, nebo jak to resit? Admin toho NATu je (asi) spis malo zkuseny a obtizne dostupny, takze idealne primo co tam ma upravit, pokud se to da takhle usoudit?
Řešení dotazu:
# scp -P 22 * user@aa.bb.cc.dd:
Password:
000.tmp 100% 0 0.0KB/s 00:00
001.tmp 100% 1024 1.0KB/s 00:00
002.tmp 100% 2048 2.0KB/s 00:00
jeden kilobyte se prenese okamzite, pri dvou to vytuhne ...
(Obracene tahani se tvari, ze zvlada stovky kB/s)
tcpdump
em – nejlepší by bylo na obou stranách, ale to asi bude obtížné. Leda byste ji přesměroval do souboru a pak nějak k sobě dostal ten soubor.
.cz.ssh: P 12773:12837(64) ack 3454 win 165 <nop,nop,timestamp 524620035 150010234>
.cz.ssh: P 12837:14277(1440) ack 3502 win 165 <nop,nop,timestamp 524620041 150010237>
.cz.ssh: P 14277:14341(64) ack 3550 win 165 <nop,nop,timestamp 524620047 150010239>
.cz.ssh: P 14341:15781(1440) ack 3598 win 165 <nop,nop,timestamp 524620052 150010241>
.cz.ssh: P 15781:15845(64) ack 3646 win 165 <nop,nop,timestamp 524620058 150010244>
.cz.ssh: P 15845:17285(1440) ack 3694 win 165 <nop,nop,timestamp 524620063 150010246>
.cz.ssh: P 17285:17349(64) ack 3742 win 165 <nop,nop,timestamp 524620069 150010248>
.cz.ssh: P 17349:18789(1440) ack 3790 win 165 <nop,nop,timestamp 524620075 150010250>
.cz.ssh: P 18789:18853(64) ack 3838 win 165 <nop,nop,timestamp 524620081 150010253>
.cz.ssh: P 18853:20293(1440) ack 3886 win 165 <nop,nop,timestamp 524620086 150010255>
.cz.ssh: P 20293:20357(64) ack 3934 win 165 <nop,nop,timestamp 524620092 150010257>
.cz.ssh: P 20357:21797(1440) ack 3982 win 165 <nop,nop,timestamp 524620098 150010260>
.cz.ssh: P 21797:21861(64) ack 4030 win 165 <nop,nop,timestamp 524620104 150010262>
.cz.ssh: . 21861:23309(1448) ack 4078 win 165 <nop,nop,timestamp 524620109 150010264>
.cz.ssh: P 23309:23317(8) ack 4078 win 165 <nop,nop,timestamp 524620109 150010264>
.cz.ssh: . 21861:23309(1448) ack 4078 win 165 <nop,nop,timestamp 524620164 150010266>
.cz.ssh: . 21861:23309(1448) ack 4078 win 165 <nop,nop,timestamp 524620274 150010266>
.cz.ssh: F 23317:23317(0) ack 4078 win 165 <nop,nop,timestamp 524620490 150010266>
.cz.ssh: . 21861:23309(1448) ack 4078 win 165 <nop,nop,timestamp 524620494 150010266>
.cz.ssh: . 21861:23309(1448) ack 4078 win 165 <nop,nop,timestamp 524620934 150010419>
.cz.ssh: . 23701:25149(1448) ack 4174 win 165 <nop,nop,timestamp 524621182 150009572>
Je mozne, ze nekde je velikost dana na 1500. Na nekolika dalsich strojich, kde to funguje, se to zastavilo na hodnote 988 a packety se zacaly delit (= slo jich vic za sebou, jakmile to presahlo hranici).
Da se nekde na cilovem stroji nastavit, aby chtel mensi velikost?
I kdybyste to nastavil na druhém konci, budou se jen pakety fragmentovat po cestě, ale zdrojový počítač se je pokusí odeslat vcelku, a opět to neprojde
Pro TCP spojení tomu lze předejít, viz target TCPMSS
Tiskni
Sdílej: