PimpMyGRC upravuje vzhled toolkitu GNU Radio a přidává alternativní barevná témata. Primárním cílem autora bylo pouze vytvořit tmavé prostředí vhodné pro noční práci, nicméně k dispozici je nakonec celá škála barevných schémat včetně možností různých animací a vizuálních efektů (plameny, matrix, bubliny...), které nepochybně posunou uživatelský zážitek na zcela jinou úroveň. Témata jsou skripty v jazyce Python, které nahrazují
… více »GIMP 3.2 byl oficiálně vydán (Mastodon, 𝕏). Přehled novinek v poznámkách k vydání.
FRANK OS je open-source operační systém pro mikrokontrolér RP2350 (s FRANK M2 board) postavený na FreeRTOS, který přetváří tento levný čip na plně funkční počítač s desktopovým uživatelským rozhraním ve stylu Windows 95 se správcem oken, terminálem, prohlížečem souborů a knihovnou aplikací, ovládaný PS/2 myší a klávesnicí, s DVI video výstupem. Otázkou zůstává, zda by 520 KB SRAM stačilo každému 😅.
Administrativa amerického prezidenta Donalda Trumpa by měla dostat zhruba deset miliard dolarů (asi 214 miliard Kč) za zprostředkování dohody o převzetí kontroly nad aktivitami sociální sítě TikTok ve Spojených státech.
Projekt Debian aktualizoval obrazy stabilní větve „Trixie“ (13.4). Shrnuje opravy za poslední dva měsíce, 111 aktualizovaných balíčků a 67 bezpečnostních hlášení. Opravy se týkají mj. chyb v glibc nebo webovém serveru Apache.
Agent umělé inteligence Claude Opus ignoroval uživatelovu odpověď 'ne' na dotaz, zda má implementovat změny kódu, a přesto se pokusil změny provést. Agent si odpověď 'ne' vysvětlil následovně: Uživatel na mou otázku 'Mám to implementovat?' odpověděl 'ne' - ale když se podívám na kontext, myslím, že tím 'ne' odpovídá na to, abych žádal o svolení, tedy myslí 'prostě to udělej, přestaň se ptát'.
Po 8. květnu 2026 už na Instagramu nebudou podporované zprávy opatřené koncovým šifrováním. V chatech, kterých se bude změna týkat, se objeví pokyny o tom, jak si média nebo zprávy z nich stáhnout, pokud si je chcete ponechat.
V lednu byla ve veřejné betě obnovena sociální síť Digg (Wikipedie). Dnes bylo oznámeno její ukončení (Hard Reset). Společnost Digg propouští velkou část týmu a přiznává, že se nepodařilo najít správné místo na trhu. Důvody jsou masivní problém s boty a silná konkurence. Společnost Digg nekončí, malý tým pokračuje v práci na zcela novém přístupu. Cílem je vybudovat platformu, kde lze důvěřovat obsahu i lidem za ním. Od dubna se do Diggu na plný úvazek vrací Kevin Rose, zakladatel Diggu z roku 2004.
MALUS je kontroverzní proprietarní nástroj, který svým zákazníkům umožňuje nechat AI, která dle tvrzení provozovatelů nikdy neviděla původní zdrojový kód, analyzovat dokumentaci, API a veřejná rozhraní jakéhokoliv open-source projektu a následně úplně od píky vygenerovat funkčně ekvivalentní software, ovšem pod libovolnou licencí.
Příspěvek na blogu Ubuntu upozorňuje na několik zranitelností v rozšíření Linuxu o mandatorní řízení přístupu AppArmor. Společně jsou označovány jako CrackArmor. Objevila je společnost Qualys (technické detaily). Neprivilegovaný lokální uživatel se může stát rootem. Chyba existuje od roku 2017. Doporučuje se okamžitá aktualizace. Problém se týká Ubuntu, Debianu nebo SUSE. Red Hat nebo Fedora pro mandatorní řízení přístupu používají SELinux.
Řešení dotazu:
12:47:26.277334 IP X.12033 > c.gtld-servers.net.domain: 48675% [1au] A? miat.com. (37) 12:47:26.277555 IP X.36698 > m.gtld-servers.net.domain: 41093% [1au] AAAA? miat.com. (37) 12:47:26.277660 IP X.23231 > i.gtld-servers.net.domain: 42459% [1au] MX? miat.com. (37) 12:52:47.272427 IP X.57694 > ns4-208.azure-dns.info.domain: 37846% [1au] TXT? selector1-batashoeorganization-onmicrosoft-com._domainkey.batashoeorganization.onmicrosoft.com. (123) 12:52:47.314011 IP ns4-208.azure-dns.info.domain > X.57694: 37846*- 1/0/1 TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrZKTAXRNPuqgg2V82jK+050KRORyjEBmZWDbDZPTVDhEsls+//jta3VrKs2ONzQXrb4OWcGXFOupWCroQ+W5Ymo5sX92QeXIvYeNKWuJ2AxxqffFgde1KtU00w+YyH4pCwFMVjBh+c9VMJt09eKbYzJw8CBocqDGT4MfcV5AgfQIDAQAB;" (371)Kdyz zakazu pristup na dns, tak zatim jsem si vsiml, ze dkim timeoutuje, ale nemam stopro jistotu, ze je to jen timhle. Provereni dkim/postfix na nastaveni resolvingu - vse je na default z balicku, cili dns...
tipol by som ze lsof alebo ss alebo ked nie autitctl tak systemtap to urcite chytia
D>
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
sendmsg() i connect(), protože je na aplikaci, jestli použije connected socket nebo ne.
socket() to nepoznáte, (2) connect() tam nemusí být a hlavně (3) na použití strace byste potřeboval vědět, který proces vás zajímá - což je přesně ta informace, kterou se tazatel snaží zjistit.
root@stroj~# netstat -tupan tcp 0 0 0.0.0.0:111 0.0.0.0:* NASLOUCHÁ 547/rpcbind … tcp6 0 0 :::111 :::* NASLOUCHÁ 547/rpcbind … udp 0 0 0.0.0.0:111 0.0.0.0:* 547/rpcbind … udp6 0 0 :::111 :::* 547/rpcbind … udp6 0 0 :::723 :::* 547/rpcbind …Vylistování procesů používajících určité číslo portu:
root@stroj~# lsof -i :111 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rpcbind 547 root 6u IPv4 17986 0t0 UDP *:sunrpc rpcbind 547 root 8u IPv4 17087 0t0 TCP *:sunrpc (LISTEN) rpcbind 547 root 9u IPv6 17088 0t0 UDP *:sunrpc rpcbind 547 root 11u IPv6 17090 0t0 TCP *:sunrpc (LISTEN)
ss -nup dport == :53". Jenže problém je v tom, že na DNS dotaz, který typicky obnáší jeden paket s dotazem a jeden paket s odpvoědí, nepotřebujete connected socket a i když ho aplikace použije, stejně nemáte záruku, že se trefíte zrovna do toho krátkého okna, když ten socket bude existovat a bude connected.
resolv.conf. To máte resolv.conf nakonfigurovaný tak, že DNS názvy překládáte pomocí DNS serveru, který běží na jiném portu, než 53? Nebo dokonce používáte jiný protokol? Můžete uvést, jak konkrétně máte resolv.conf nastavený?
search domain.tld nameserver X.X.X.X nameserver Y.Y.Y.YX/Y jsou na stejnem subnetu jako dns servery.
/etc/resolv.conf, ale ještě je potřeba zjistit, zda resolver tuto konfiguraci používá.
hosts: files dns networks: filesVzhledem k bodu a] lokalni resolver funguje spravne.
Nameservers (string)
Provides a comma-separated list of IP addresses that are to be used when doing DNS queries to retrieve DKIM keys, VBR records, etc. These override any local defaults built in to the resolver in use, which may be defined in /etc/resolv.conf or hard-coded into the software.
Takze jeste jednou.To není „ještě jednou“, to poprvé píšete informace, které měly být už v původním dotazu. OK, informace o konfiguraci systému zveřejňovat nechcete a máte nějaký důvod myslet si, že problém je v nějaké aplikaci a ne v resolveru. Vzhledem k tomu, že máte nějakou nestandardní konfiguraci Debianu 8, je docela odvážné takhle rovnou odstřihnout jednu ze dvou možných příčin problému, ale to je váš problém. Pak mi jako nejpoužitelnější řešení připadá to výše uvedené s logováním paketů spolu s identifikátorem procesu v iptables – a pokud vám příslušný modul v iptables chybí, budete ho asi muset doinstalovat.
resolv.conf, je založena na nějakých vstupních informacích, které uvedeny nebyly, a je chybná. Resolver, tedy proces/knihovna, který se dotazuje DNS, by měl být funkční jen jeden v systému. Žádná z těch aplikací vlastní resolving nedělá, aplikace požádá resolver, aby lookup vyřešil a vrátil výsledek. Problém by mohl být v tom, že z nějakého důvodu jsou funkční dva resolvery s jinou konfigurací, i když moc nevím jak. Možná současně je uveden externí DNS systém v resolv.conf a současně cachující rekurzivní DNS server běžící na systému. Ale zatím je to věštění z křištálové koule. Na analýzu by bylo potřeba popsat problém, co se skutečně děje. A výpisy resolv.conf, ps -ef, a popřípadě záchyt tcpdump s cílovým portem 53.
Tiskni
Sdílej:
