Počítačová hra Factorio (Wikipedie) nově běží nativně na ARM64 Linuxu a headsetu Steam Frame.
Fugleramme, v překladu 'ptačí rámeček', je open-source projekt postavený na Raspberry Pi, který pomocí lokální umělé inteligence BirdNET-Go rozpoznává ptačí druhy podle jejich zpěvu a na displeji následně zobrazuje koláž tvořenou odpovídajícími ilustracemi. Databáze obsahuje přes 800 ručně vybraných historických přírodovědných ilustrací více než 400 druhů ptáků.
… více »Unicode Consortium, nezisková organizace koordinující rozvoj standardu Unicode, oznámila vydání Unicode 18.0. Přidáno bylo 13 007 nových znaků. Celkově jich je 172 808. Přibylo 9 nových Emoji.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 169 (pdf).
Byla vydána nová verze 6.4 programovacího jazyka Swift (Wikipedie). Zdrojové kódy jsou k dispozici na GitHubu.
Německý kancléř Friedrich Merz (CDU) se během debaty s finalisty studentské vědecké soutěže Jugend forscht vyjádřil pro konec anonymity na internetu a vyslovil názor, že pro uživatele Internetu by měla platit podobná právní odpovědnost jako pro novináře tradičních médií. Na dotaz studenta, jak by se tedy povinnost uvádět pravé jméno slučovala s prací investigativních novinářů nebo ochranou jejich zdrojů, Merz neodpověděl, ve své
… více »Společnost Fujitsu představila FUJITSU-MONAKA CPU a Fujitsu MONAKA Server. Navrženo, vyvinuto a vyrobeno v Japonsku. Pro suverénní AI infrastrukturu.
Předprodej v květnu představených notebooků Googlebook, nástupců notebooků Chromebook, bude spuštěn v pondělí 21. září.
Byla vydána betaverze Fedora Linuxu 45 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 20. října. S konzolí kmscon místo fbcon. Současně byla vydána betaverze Fedora Linux Asahi Remixu 45. S podporou čipů M3.
Po půl roce vývoje od vydání verze 50 bylo vydáno GNOME 51 s kódovým názvem "A Coruña" (Mastodon). Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře. Videopředstavení na PeerTube a YouTube.
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: