Příspěvky

1

Desktop / Re:GNOME sebere stisk klávesy

« kdy: 08. 12. 2024, 16:06:13 »

Sice ne přímo v Debianu, ale používám GNOME (od 3.32 přes novější 40-47) a graf. terminál (Gnome Terminal, Gnome Console - kgx) na víc různých distribucích, také s Waylandem a nikdy se mi popisovaná věc neděla.
Nemůže to být problém nějakého přizpůsobení, nebo rozšíření v Gnome Shellu, či použitého terminálu?
Zkusil bych si vytvořit nového uživatele, nechat všechno ve výchozím nastavení (žádný Classic nebo přidávání dalších rozšíření) a zkusit problém replikovat.
Případně to pak ještě zúžit a ověřit, jestli se to děje i s jinou aplikací pro terminál, např. Kitty, aby se rozlišilo, jestli je to záležitost Gnome Shellu.

2

Sítě / Re:Přepínání rychlosti routeru

« kdy: 06. 12. 2024, 23:50:04 »

Ani nevím jestli ten vypůjčený izolátor umožňoval PoE. Na přesný typ jsem odkaz nenašel a byl to 1Gbbs.
Máte pravdu u krabiček píšou dole v detailech že zádné napájení přes ne jít nemůže https://www.wimo.com/en/iso-plus  Ono je to těžké určit jak se těch 13.5 Mhz do kabelu dostává. Je to alchymie i když s dražšími měřáky to musí být zjistitelné. Uznávám že optika by byla určitě čistším řešením. Jsem spokojený za 2K hodně muziky mají děti:-)

Podle mě tam taky nemohlo procházet PoE, pokud v obou případech galvanicky odděluje a je to pasivní, tak to se nedá udělat moc jinak než trafem, přes které neprojde DC.
Akorát teď jak se ještě koukám na ten půjčený izolátor do DIN lišty, co jste posílal, tak ten je podle dokumentace stejně jen do 100Mbit. Takže by u něj třeba nemusely být zapojené všechny páry, příp. by tam mohla být i třeba menší šířka pásma (gigabit má 2x vyšší frekvenci). Takže by vám to stejně nepomohlo.

Já se s podobnými izolátory setkal jen jednou v nemocnici, ale koukal jsem na to jen ze zvědavosti, když jsem řešil něco jiného.. Když jsem se pak místního technika ptal, tak je to primárně kvůli tomu, že lékařská technika musí splňovat přísnější normy. A ta vestavěná trafa, co jsou v normálních ethernetových portech, tomu nevyhovují.

Nic, tak každopádně, ať vám to běhá

3

Sítě / Re:Přepínání rychlosti routeru

« kdy: 06. 12. 2024, 23:19:11 »

To me prijde jako mega blbost. Ethernet kabel neni z podstaty galvanicky spojeny se zarizenim, protoze v kazdem sitovem portu je oddelovaci trafo

Takze pomohlo ono zkraceni, nebo uprava vedeni trasy.

Tak hlavně, že to teď funguje po všech možných pokusech.

Ale přesně jak jsi zmiňoval, to mě napadlo taky. Vypadá, že je izolátor úplně pasivní, nejspíš tam taky trafo na každý pár. Nemohlo to třeba oproti tomu trafu, co je v Eth portu v routeru, pomoc třeba i s lepším CMRR?
Přičemž je pak zajímavé, že předtím p. Peterkovi nezabral stejně ten izolátor do DIN lišty, co posílal předtím. Tam taky nejspíš nebude nic jiného než zase trafo. Takže možná to bude teď kombinace konkrétního izolátoru, úprava vedení a těch feritů..?

4

Software / Re:Raspberry - systemové logy

« kdy: 06. 12. 2024, 11:43:49 »

No zkombinujete -p err s tím --since "24 hours ago", co psal P. Krčmář.
Ale samozřejmě bude záležet, jestli to co hledáte, bude mít tu správnou prioritu (-p) error, která odpovídá těm syslog levelům. Tohle pak záleží na programu, aplikaci, co ty záznamy vytváří.
Pokud je to ze systemd služby, tak to můžete dál zúžit třeba pomocí -u <nazev.service>
Případně pokud jsou to konrkétní komponenty (aplikace) tak za journalctl napíšete její cestu. Např. journalctl /usr/sbin/cron
Mrkněte se asi spíš na nějaký ucelenější přehled těch funkcí, třeba tady:
https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs

5

Software / Re:Komprimace do tar s datem a časem

« kdy: 06. 12. 2024, 11:02:48 »

Zkuste vyhodit ty jednoduché úvozovky okolo formátovacího řetězce pro date a pak před každé procento přidat zpětné lomítko, abyste to odescapoval.

Ale tohle je přesně ten opruz, který může vést i k nečekaným výsledkům (vezměte si, že třeba děláte nějaký mazací one-liner, co se bude pokaždé chovat jinak, podle toho jestli se spustí z cronu, nebo interktivního shellu - to může dopadnou i pěkným průšvihem). Proto je podle mě lepší ten sh skript.

6

Software / Re:komprimace do tar s datem a časem

« kdy: 06. 12. 2024, 10:50:26 »

Není úplně dobrý nápad používat tyhle shell věci a spec. znaky přímo v crontabu. Podle konkrétního démona cron a zvoleného shellu (nastavení SHELL= v crontab) můžete narazit na problémy se zápisem těch procent, co se pak musí escapovat, těch stejně tak těch apostrofů, případně vnořených úvozovek. Většinou to jde přepsat i do té jednořádkové podoby, aby to crond sežral, ale je lepší se tomu vyhnout.

Udělal bych si nějaký shell skript např. (/usr/local/bin/documents-backup.sh), u kterého bych si odladil funkčnost, a pak mu přidal záznam v crontabu, kde by bylo už jen např. /bin/bash /usr/local/bin/documents-backup.sh

Jinak jestli budete to budete mít napsané jako skript, můžete se pak mrknout i na použití systemd timerů místo cronu na spouštění.

https://documentation.suse.com/smart/systems-management/html/systemd-working-with-timers/index.html
https://wiki.archlinux.org/title/Systemd/Timers

Na moderních distribucích je tohle většinou lepší varianta s víc možnostmi, byť musíte typicky pro každý timer udělat dva soubory.

7

Sítě / Re:Root.cz přes IPv6 se nezobrazí ve Firefoxu

« kdy: 06. 12. 2024, 09:14:18 »

Problém s IPv6 (na DSL cetinu) jsem také měl jakmile vyšla verze firmware 7.16 takže jsem se vrátil na 7.15.3 jelikož nebyl čas to řešit a problém zmizel.

Teď už myslím verze 7.16.2 takže zkuste nejdříve na nejnovější a pokud ne zvažte downgrade.

Nemyslím si, že by to byl ten primární problém, o kterém píše. Jak pak vyplynulo z další diskuze, tak je to spíš věcí konfigurace (správná velikost MTU v PPPoE klientovi, případně její posílání v ND (RA) nebo přidání pravidla pro MSS clamping). Viz můj dlouhý post výše. Nesouvisí to až tak s případným bugem, pokud to není dobře nastaveno.

Mikrotik, který jsem používal na testy, měl firmware s RouterOS 7.13 tuším někdy z loňska.
Teď po testech jsem to aktualizoval 7.16.2, chovalo se to úplně stejně.

8

Sítě / Re:Root.cz přes IPv6 se nezobrazí ve Firefoxu

« kdy: 06. 12. 2024, 01:10:12 »

O.K. tak si sám napíšu update.
Vrtalo mi to hlavou a ozkoušel jsem si to na Mikrotiku s VDSL modemem v bridge režimu (O2, Cetin).
PPPoE klient nastavený na MTU 1492, to chodilo podle předpokladu dobře.

Vyzkoušel jsem si všechny zmíněné scénáře

- Nenastavovat nic dál, nechat to na dynamické zjišťování PMTU až ke klientovi
ICMPv6 je ve výchozím nastavení RouterOS povolené, zpráva packet too big (PTB) prochází na stanice.
První spojení se nenaváže, ale vytvoří se záznam v lokální routovací tabulce s menším MTU pro hosta venku (server). Dá se v Linuxu ověřit přes ip -6 route show cache. Další spojení pak proběhne v pohodě s použitím nové MTU.

Horší pak je, jak se tohle chování projeví se standardními aplikacemi. Chrome i FF dlouho čeká na timeout s chybou, nebo se musí načítání stránky přerušit a refreshnout. Druhé spojení pak načte základní stránku, ale pak se typicky čeká znovu (další servery s reklamou, skripty, diskuzí atp.), takže zas přerušit a dát refresh. Totéž pak třeba telefon s iOSem. Prakticky nepoužitelné.

To btw. vysvětluje i to zdánlivě divné chování, co popisoval tazatel. Není to tak, že by to chodilo v konkrétním browseru a jiném ne. Pokud to zkouší nejprve v jedné aplikaci, tak se to nenačte, ale udělá se PMTU záznam a v druhé, co zkouší později, už to pak po dobu jeho platnosti záznamu chodí.

- MSS clamping
Na RouterOS jsem to naklikal v GUI pro mangle tabulku a forward chain. Případně přes konzoli něco jako:

Kód: [Vybrat]

/ipv6 firewall mangle add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes
protocol=tcp tcp-flags=syn
Tohle zafunguje vcelku spolehlivě a vyřeší problémy s načítáním většiny stránek.
Nevýhoda je, že to logicky funguje jen na TCP spojení. UDP spojení to neřeší, nemají MSS field.
Takže by se muselo spoléhat na to, že ty aplikace, co UDP používají, si vyřeší reconnect po zjištění PMTU (viz předchozí způsob). Nevím například, jak to je s aktuálním použitím QUIC/HTTP3, co běží přes UDP, jaké mají servery MTU, a jestli je dobré na tenhle workaround spoléhat do budoucna.

- snížení inzerovaného MTU v RA (ND) na 1492
To samozřejmě řeší komunikaci všemi protokoly, aby to prošlo přes WAN síť, a funguje spolehlivě. Nevýhoda už tu byla předtím zmíněná, pokud spolu klienti komunikují v LAN mezi sebou po IPv6, používají také menší MTU.
Otázka je, jak velký je tohle prakticky problém.. za mě je to pořád preferovaná varianta, jak to řešit pro většinu menších sítí.

Takže - pick your poison. A víceméně mi to odpovídá na otázku, proč třeba někteří výrobci SOHO routerů/modemů, které jsem viděl, měli ve výchozím nastavení všechno naráz - bylo povolené ICMPv6, MSS clamping a ještě k tomu replikovali MTU od upstream linky v RA.

9

Sítě / Re:Root.cz přes IPv6 se nezobrazí ve Firefoxu

« kdy: 05. 12. 2024, 14:10:14 »

Podle mě to tak být nemá. Jakým MTU pak komunikuje takový klient po lokální síti (přes switch)? MTU má mít klient na 1500, pokud komunikuje skrz něco, co má menší MTU, tak se mají fragmentovat. Ne že má mít klient za každých okolností MTU nejmenší, které má zařízení, které je po cestě v komunikaci.

Beru, to je moje blbá a příliš kategorická formulace v tomhle kontextu. Teoreticky máte samozřejmě pravdu a není to optimální přesně z důvodů, co jste popisoval. Na stranu druhou, pokud tazatel opravdu neblokuje ICMP6, mělo by tedy fungovat PMTUD, a přesto se mu něco ztrácí a má problémy s připojením, tak by to bylo první, co bych za dané situace zkusil. A mít na PPPoE klientu MTU 1480 a v RA pak 1492 nedává smysl. Buď tedy nechat RA na 1500 a zkoumat proč přesně nechodí v konkrétních spojeních PMTUD, nebo srovnat to inzerované MTU s upstream spojením, případně ještě zkusit MSS clamping (v iptables je to clamp-mss-to-pmtu, neznám přesně syntaxi téhož v RouterOS), jak je i zmíněno v linkovaném článku od p. Caletky.

Já jsem primárně vycházel z toho, že většina "běžných" modem/routerů (jak přímo od providerů, tak koupené ve volném prodeji), co jsem viděl na XDSL linkách od Cetinu, prostě v tom RA inzeruje MTU z WAN rozhraní, případně je tam pak i rovnou zapnutý ten zmíněný clamping (to je třeba případ ASUSWRT), přestože je zároveň průchozí ICMP6 a ty PTB pakety. Jestli to dělají jen pro sichr a nemuselo by to být, nebo tím třeba obcházejí potíže u některých specifických klientů (op. systémů), je věc druhá.

Nevím, jak daleko je s problémem tazatel, nějak se už neozval, pokud to úplně nevzdal.
Můj troubleshooting by šel tak, že bych si na úvod potvrdil, že to souvisí s MTU a není to jiný problém, třeba tím, že na test sundám MTU na lokální síťovce v počítači - klidně i třeba na 1400. Pokud by se mi pak stránky načítaly, vrátil bych to zpět a řešil až návazně jak to udělat dál, donastavit ten router, monitorovat ICMP6, ozkoušet i ostatní klienty (telefony, televize atp.).

10

Software / Re:FFmpeg a výroba náhledů v AVIF

« kdy: 04. 12. 2024, 09:45:52 »

Tahle zpráva je omyl, pardon

11

Software / Re:FFmpeg a výroba náhledů v AVIF

« kdy: 04. 12. 2024, 09:43:29 »

Chápu, to je samozřejmě také možnost, udělat z toho nejdřív např. bezztrátové png, a pak to převést třeba pomocí avifenc.
Je to tak, že kodeky pro AV1 se stále poměrně dost mění (v porovnání se stabilními implementacemi jako např. x264, LAME atp.) a když ten ffmpeg někdo sestavuje proti rok starým verzím knihoven, tak můžou nastat problémy. Ale taky se to usadí.

Jinak kdybyste si chtěl někdy dělat svoje statické buildy, ať už z jakéhokoliv důvodu, tak většinou docela dobrý začátek je tohle repo:
https://github.com/markus-perl/ffmpeg-build-script
Můžete to buildovat i s Dockerem v podstatě nezávisle na distribuci, případně upravit podle potřeby.

12

Software / Re:FFmpeg a výroba náhledů v AVIF

« kdy: 03. 12. 2024, 23:12:06 »

Tady kdyžtak ještě tučnější verze, jsou tam zapečené i non-free a GPL knihovny. Chybí akorát CUDA, to ale, počítám, ve virtuálu asi nepoužijete..
https://filetransfer.io/data-package/3H3pGYs5

13

Software / Re:FFmpeg a výroba náhledů v AVIF

« kdy: 03. 12. 2024, 22:46:55 »

Jo, teď na to koukám.. John zřejmě přestal buildovat ffmpeg, včetně těch gitů . Všechno je to staré.
libaom je tam víc než rok stará verze 3.2, co neumí ty timebase, jak vám to píše. V knihovně už je commit, co to opravoval pro podobná použití, aktuální release libaom je 3.11.

Tady máte aktuální release verzi ffmpeg 7.1, statický build pro Linux, mělo by to jít i na starším Ubuntu
https://filetransfer.io/data-package/VKIdPRim

Je to teď jen narychlo bez GPL a non-free věcí, ale na thumbnaily by to mělo stačit, dekodéry tam jsou.
Plná verze s x265, x264 atd. se mi ještě kompiluje.

14

Distribuce / Re:Ako nainstalovat najnovsie balicky na Ubuntu Server?

« kdy: 03. 12. 2024, 14:58:48 »

Dají se selektivně instalovat i balíčky z novějších distribucí, buď manuálně nebo přidáním repa s apt pinningem. Akorát se nedá říct obecně, jestli je to dobrý nápad. Protože při určitém řetězci závislostí to klidně může vyměnit půl systému a příp. jej komplet rozstřelit. Ffmpeg jsem si na různé aplikace občas kompiloval sam, abych tam měl své věci nebo přesné knihovny. Nebo, pokud to bude stačit, tak je dělá John V. Sickle. https://johnvansickle.com/ffmpeg/

15

Server / Re:NAS + cloud, jaké řešení vybrat

« kdy: 03. 12. 2024, 11:57:08 »

Aha, už jste to vysvětlil, chcete to obráceně
Jasně, pak beru, že musíte řešit VPSku s určitým výkonem a dostupností na hostování.