V pátek 6. a sobotu 7. března proběhl v pražském sídle Nejvyššího kontrolního úřadu (NKÚ) Hackathon veřejné správy 7.1. Publikovány byly vytvořené aplikace. V kategorii projektů rozvíjených z krajského kola zvítězil tým „Mackokládi“. Čtyři středoškoláci ze Dvora Králové uspěli s aplikací KompaZ. Jde o digitálního průvodce, který pomůže s rychlou a srozumitelnou orientací v životních i krizových situacích „krok za krokem“. Aplikace
… více »QGIS, svobodný desktopový GIS, byl vydán v nové hlavní verzi 4.0. Změny zahrnují několik nových analytických a editačních funkcí, rozšíření podpory 3D, více možností úprav uživatelského rozhraní či mnoho dalších zlepšení použitelnosti. Řada 3.44 má aktualizace plánovány do září.
Dan Blanchard vydal knihovnu pro Python chardet v nové verzi 7.0.0. S novou verzí byla knihovna přelicencována z LGPL na MIT. Souhlasili s tím všichni přispěvatelé? Dan Blanchard souhlasy vůbec neřešil. Zaúkoloval umělou inteligenci (Claude), aby knihovnu zcela přepsala a výslovně jí nařídil, aby nepoužila žádný LGPL kód. Dan Blanchard tvrdí, že se jedná o clean room design. Protistrana argumentuje, že umělá inteligence byla trénována
… více »Andy Nguyen si na svou herní konzoli PlayStation 5 (PS5) pomocí exploitu Byepervisor nainstaloval Linux (Ubuntu). V Linuxu si spustil Steam a PS5 tak proměnil v Steam Machine. Na PS5 může hrát hry, které jsou vydané pouze pro PC a jsou na Steamu [Tom's Hardware].
Správce sbírky fotografií digiKam byl vydán ve verzi 9.0.0. Jedná se o větší vydání provázené aktualizacemi knihoven. Mnoho dílčích změn se vedle oprav chyb týká uživatelského rozhraní, mj. editace metadat.
Byla vydána verze 2026 distribuce programu pro počítačovou sazbu TeX s názvem TeX Live (Wikipedie). Přehled novinek v oficiální dokumentaci.
Jihokorejská Národní daňová služba (NTS) zabavila kryptoměnu Pre-retogeum (PRTG) v hodnotě 5,6 milionu dolarů. Pochlubila se v tiskové zprávě, do které vložila fotografii zabavených USB flash disků s kryptoměnovými peněženkami spolu se souvisejícími ručně napsanými mnemotechnickými obnovovacími frázemi. Krátce na to byla kryptoměna v hodnotě 4,8 milionu dolarů odcizena. O několik hodin ale vrácena, jelikož PRTG je extrémně nelikvidní, s denním objemem obchodování kolem 332 dolarů a zalistováním na jediné burze, MEXC [Bitcoin.com].
Komunita kolem Linuxu From Scratch (LFS) vydala nové verze knih s návody na instalaci vlastního linuxového systému ze zdrojových kódů Linux From Scratch 13.0 a Beyond Linux From Scratch 13.0. Pouze se systemd.
Byla vydána nová stabilní major verze 25.12 linuxové distribuce primárně určené pro routery a vestavěné systémy OpenWrt (Wikipedie). Jedná se o nástupce předchozí major verze 24.10. Přehled novinek v poznámkách k vydání. Podporováno je více než 2200 zařízení.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za únor (YouTube). Odstraněn byl veškerý kód napsaný ve Swiftu. JavaScriptový engine LibJS byl reimplementován v Rustu.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
ssh -N -R 22222:localhost:22 server
("server" má v .ssh/config adresu, port a uživatele). S připojením není problém, to by mělo být všude stabilní. Tunel vždy chvíli funguje, ale po zhruba deseti minutách přestane odpovídat. Po jeho zrušení a opětovném zadání příkazu výše:
Error: remote port forwarding failed for listen port 22222
Podle návodů na internetu funguje na opravení, když na serveru zabiju proces, který tento port používal (nestat -> kill). Ale to je velmi nepraktické a v praxi nepoužitelné. Záhadou mně je, že toto spojení nefunguje, ale stejný tunel (samozřejmě s rozdílným portem) přes stejný server z jiného stroje (na jiné lokaci) bez komplikací funguje. Nedokázali byste poradit, jak se této blokace portu zbavit?
-f (background fork) -T (nealokuje pseudo tty) [-C (komprese..) optional]Zadruhe, spojeni pravdepodovne vyhori na timeout, necinnost Duvod muze byt rozdilna konfigurace klienta, ale port na serveru zustane "bimdnuty". To muzes overit debugovanim.
-v (-vv -vvv)Zatreti, resenim by mohlo byt upravit konfiguraci. Naprikl ad. Pridat do .ssh/config(klient):
ServerAliveInterval 300 (5minut) (ServerAliveCountMax 3) (3 pokusy)Nebo parametry konfiguracnich souboru(server):
TCPKeepAlive yes ClientAliveInterval 300 ClientAliveCountMax 3No a konecne autossh varianta(nepouzivam..):
autossh -M 20000 -f -N server -R 22222:localhost:22 -C
Možná je lepší položit otázku abstraktněji, tedy jak dosáhnout určitého cíle. Cílem je zjevně dostat se zvenčí na nějaký stroj ve vnitřní síti, na který se z nějakého důvodu nedá zvenku routovat. Měl bych jisté tušení, jaký důvod to asi bude. Takže: Není náhodou řešením IPv6?
Před deseti lety, když ještě IPv6 nebyl všude běžně dostupný, jsem taky provozoval pár (desítek) takových SSH tunelů, aby stroje za NATem (tedy za morem a neštovicemi v jednom) mohly být dostupné skrz tohle SSH over SSH. Vždycky to stálo za hovno. Někdy tunely vydržely den, někdy hodinu. Někdy se samy obnovovaly, někdy ne. Někde někdo změnil nastavení firewallu a najednou TCP spojení automaticky vypršela po 10 minutách, pokud nebyla opravdu hodně aktivní, tedy TCP keepalive k udržení spojení nestačil. (!) Důvodem prý bylo, aby na nějakém NAT routeru nedocházely porty, když spousta spojení od strojů z vnitřní sítě zůstane viset. Tak se prostě méně aktivní nebo neaktivní spojení zabila, zkrátka ve prospěch těch, která (zdánlivě) něco dělají. Tohle byl vždycky zoufalý a předem prohraný boj. Internet, ve kterém se nedá routovat z kteréhokoliv stroje na kterýkoliv jiný, prostě není Internet, je to něco polovičatého a na houby. Do prvních videokonferenčních aplikací se v roce 2002 prostě zadala IP adresa protistrany a všechno fungovalo. NAT ale postupně způsobil, že tak běžná a samozřejmá věc jako komunikace mezi libovolnými dvěma počítači prostě fungovat přestala. Místo relativně bezpečných přímých spojení, u kterých se dá dohodnout bezpečné šifrování, zvítězily prasárny typu Skype, kde end to end šifrování není a kde je to s bezpečností opravdu zlé. Zkrátka a dobře, snaha o spolehlivě fungující permanetní SSH tunely je podle mě předem prohraná bitva, zatímco IPv6 je v každém ohledu výhra.
No ale mně IPSec road warrioři (StrongSwan) taky občas selhávají na některých divně nakonfigurovaných sítích, kde NAT záměrně nectí TCP spojení ani UDP „mapování“. Sice ne napořád, obnovují se mnohem spolehlivěji než u toho SSH, ale u některých spojení i výpadek v řádu několika desítek sekund docela dost vadí. NAT router, který si nakonfiguruju sám, takové divné věci nedělá, ale různé polorozbité sítě vidím všude možně. Internet s NATem zkrátka není Internet.
VPN (například IPSec) má přesto jednu zásadní výhodu: Road warrior může mít stálou veřejnou IP adresu (IPv6, samozřejmě). Funguje tam IPv6 přes IPv4 (i všechny 3 ostatní kombinace) a na toho road warriora se pak dá připojovat zvenčí na standardní port 22 (pokud příslušný VPN/IPSec server správně routuje), bez speciálních portů a jiných nepravidelností.
Mně se JuiceSSH z Androidu připojuje všude přes IPv6, kdykoliv vidí AAAA záznam… Zrovna s Androidem rozhodně problém nebude. Pokud poskytovatel neumí IPv6, je to samozřejmě horší problém. Není ale důvod používat SixXS, když je ke každé veřejné IPv4 adrese automaticky k dispozici 6to4 s 2^80 IPv6 adres. Zejména od doby, co nic.cz před cca 5 lety začal provozovat vlastní server s magickou adresou 192.88.99.1 (což je adresa, která má podle konvence vést k nejbližší 6to4 bráně), je i rychlost a stabilita bez nejmenších problémů. Jenom musí mít člověk na routeru alespoň tu jednu veřejnou IPv4 adresu, jinak už nepomůže nic. 
Tiskni
Sdílej:
