Open source počítačová hra na hrdiny NetHack (Wikipedie, GitHub) byla vydána v nové verzi 5.0.0. První verze této hry byla vydána v roce 1987.
Evropská komise naléhavě vyzvala členské státy EU, aby kvůli ochraně nezletilých na internetu urychlily zavádění unijní aplikace pro ověřování věku a zajistily její dostupnost do konce roku. Členské státy mohou zavést aplikaci EU pro ověřování věku jako samostatnou aplikaci nebo ji integrovat do takzvané evropské peněženky digitální identity.
Richard Biener oznámil vydání verze 16.1 (16.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 16. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.
Zulip Server z open source komunikační platformy Zulip (Wikipedie, GitHub) byl vydán ve verzi 12.0. Přehled novinek v příspěvku na blogu.
Před 30 lety, tj. v úterý 30. dubna 1996, byl spuštěn Seznam.cz.
Byly zpracovány a zveřejněny všechny videozáznamy, které stojí za zveřejnění, z konference FOSDEM 2026.
Od úterý 28. dubna musí nově uváděné notebooky v Evropské unii podporovat nabíjení přes USB-C. Jednotná nabíječka byla schválena Evropským parlamentem v říjnu 2022.
Byly publikovány informace o kritické zranitelnosti CVE-2026-31431 pojmenované Copy Fail v Linuxu, konkrétně v kryptografii (AF_ALG). Běžný uživatel může získat práva roota (lokální eskalaci práv). Na všech distribucích Linuxu vydaných od roku 2017. Pomocí 732bajtového skriptu. V upstreamu je již opraveno. Zranitelnost byla nalezena pomocí AI Xint Code.
Textový editor Zed dospěl do verze 1.0. Představení v příspěvku na blogu.
Vývojáři svobodného 3D softwaru Blender představili (𝕏, Mastodon, Bluesky) nejnovějšího firemního sponzora Blenderu. Je ním společnost Anthropic stojící za AI Claude a úroveň sponzoringu je Patron, tj. minimálně 240 tisíc eur ročně. Anthropic oznámil sponzorství v tiskové zprávě Claude for Creative Work.
Ahoj
zajímalo by mě, jak by se měl řešit převod domény aby byl pro organizaci co nejméně bolestivý. Mám namysli situaci, kdy se fyzickému serveru změní IP adresa (změna poskytovatele, přemístění serveru) a je potřeba na autoritativním serveru přepsat A záznam. Než ostatní DNS servery na Internetu načtou změnu od autoritativního DNS dané domény může uběhnout několik dní v závislosti na nastavení jednotlivých DNS serverů.
popis problému:
Autoritativní DNS server pro naši doménu nase.cz je u poskytovatele. Přemisťovali jsme fyzický server(změnila se jeho IP adresa).Poprosili jsme našeho poskytovatele o změnu A záznamu. Několik dní nám přicházeli požadavky střídavě na starou a na novou IP adresu serveru.Trvalo ještě několik dní než ostatní DNS servery na Internetu načetli změnu a požadavky chodili na novou IP adresu.
Četl jsem článek www.root.cz/serialy/dnssec-a-bezpecne-dns/ kde mě zaujal postup jakým se aktualizuje klíč:
"po podepsání zónového souboru je zapotřebí počkat, až se zóna rozdistribuuje na všechny nameservery a následně počkat dobu, která je rovná nebo vyšší TTL záznamů DNSKEY (a jejich podpisů)"
Jakým způsobem se řeší změna A záznamu na autoritativním DNS serveru? Je potřeba vždy vydržet několik dní chaosu, nebo se to dá řešit nějak elegantně?
děkuji za radu
Tomáš Jurman
Plynulého přechodu se dá dosáhnout třeba tak, že na nové IP adrese spustíš Apache (předpokládám, že jde hlavně o web) s mod_proxy a ten bude všechny příchozí požadavky proxovat na původní server (klient se připojuje jen k novému serveru a ten mu zprostředkuje obsah z toho původního). Až přestanou chodit požadavky na původní IP adresu, můžeš provést migraci serveru.
Případně by mělo fungovat i to, že bys danému DNS jménu přidal dvě IP adresy (s různými prioritami) a v případě nedostupnosti jedné, by měl klient použít druhou, viz Round robin DNS.
Plynulého přechodu se dá dosáhnout třeba tak, že na nové IP adrese spustíš Apache (předpokládám, že jde hlavně o web) s mod_proxy a ten bude všechny příchozí požadavky proxovat na původní server (klient se připojuje jen k novému serveru a ten mu zprostředkuje obsah z toho původního). Až přestanou chodit požadavky na původní IP adresu, můžeš provést migraci serveru.To možná bude jednodušší ssh -L s tím, že tak může směrovat třeba i maily nebo MySQL.
djbdns má pro tohle zabudovanou podporu – můžete tam nastavit do kdy platí starý záznam, server pak automaticky nastavuje TTL tak, aby bylo nejvýš pár vteřin přes zadaný čas. V okamžiku stanoveném zadaným časem se pak starý záznam přestane poskytovat a začne se poskytovat záznam nový. Doba, kdy jsou pak „v oběhu“ obě dvě IP adresy, je tak zkrácená na pár vteřin.
djbdns jsem uváděl jen pro to, že některé servery pro to mohou mít vestavěnou podporu, a pak je škoda ji nevyužít. Ono se stejně vyplatí mít kolem období změny malé TTL, protože se snadno může stát, že na novém serveru nebude vše fungovat, jak má, a bude potřeba se rychle vrátit k původnímu serveru; a občas se při přesunech také podaří původní server rozbít dřív, než bylo v plánu
Autoritativní DNS server pro naši doménu nase.cz je u poskytovatele. Přemisťovali jsme fyzický server(změnila se jeho IP adresa).Poprosili jsme našeho poskytovatele o změnu A záznamu. Několik dní nám přicházeli požadavky střídavě na starou a na novou IP adresu serveru.Trvalo ještě několik dní než ostatní DNS servery na Internetu načetli změnu a požadavky chodili na novou IP adresu.
Zřejmě měl váš poskytovatel nastaven velmi dlouhý TTL pro záznamy. Několik dnů je dost neobvyklá hodnota, za přijatelné maximum lze považovat 3600 (1h). Při přesunu serveru nejprve týden dopředu kontaktuji správce DNS (nejsou-li u nás) a požádám je o nastavení TTL na 600. Během přesunu nechám změnit záznam. Než nový stroj nabootuje, jdou všechny požadavky již na novou IP. "Chaotické požadavky" chodí opravdu jen těch 10 minut (kdy nejede ani starý, ani nový server, takže je to jedno). A vůbec se nestydím tam pak nechat těch 600 trvale. Nastavovat dlouhé TTL nemá moc důvodů.
www.qcm.cz. 600 IN A 91.214.192.20
Tiskni
Sdílej: