Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za květen (YouTube).
Úřad pro ochranu osobních údajů řeší desítky stížností na jednotné měsíční hlášení zaměstnavatele, které stát spustil počátkem dubna. Systém, jenž má firmám odlehčit od desítek formulářů, nejenže výrazně zatížil jejich účetní oddělení, ale docházelo v něm i k únikům osobních dat zaměstnanců k firmám, kde nepracovali. Podle ministerstva práce a sociálních věcí stála za problémem technická chyba. „Incident se týkal několika stovek
… více »Byla vydána (𝕏, Bluesky) nová verze 22.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
Vim Classic byl vydán ve verzi 8.3. Drew DeVault oznámil tento fork editoru Vim (verze 8.2.0148, tj. těsně před zavedením Vim9 skriptování) v březnu letošního roku. Důvodem forku bylo, že vývojáři editorů Vim a Neovim začali při vývoji využívat LLM.
Open source konference DevConf.CZ 2026 proběhne 18. a 19. června v Brně na FIT VUT. Publikován byl program a spuštěna byla registrace.
Společnost JetBrains uvolnila verzi 2 svého open-source velkého jazykového modelu (LLM) pro vývojáře Mellum.
Probíhá konference Microsoft Build 2026. Microsoft představuje své novinky: kvantový čip Majorana 2, Surface Laptop Ultra a Surface RTX Spark Dev Box s NVIDIA RTX Spark, Intelligent Terminal, Coreutils for Windows (fork Rust Coreutils), AI modely MAI, AI agenta Scout, platformu pro agent-first zařízení Project Solara, …
Google Chrome 149 byl prohlášen za stabilní. Nejnovější stabilní verze 149.0.7827.53 přináší řadu novinek. Podrobný přehled v poznámkách k vydání. Vylepšeny byly také nástroje pro vývojáře.
Pluto.jl, reaktivní notebook pro programovací jazyk Julia, dospěl do verze 1.0.
Byla vydána nová verze 12.0.0 vizuálního programovacího jazyka Snap! (Wikipedie) inspirovaného jazykem Scratch (Wikipedie). Přehled novinek na GitHubu.
Ř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>
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: