Dle plánu certifikační autorita Let's Encrypt nově vydává také certifikáty s šestidenní platností (160 hodin) s možností vystavit je na IP adresu.
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 14.0 (Mastodon). Forgejo je fork Gitei.
Just the Browser je projekt, 'který vám pomůže v internetovém prohlížeči deaktivovat funkce umělé inteligence, telemetrii, sponzorovaný obsah, integraci produktů a další nepříjemnosti' (repozitář na GitHubu). Využívá k tomu skrytá nastavení ve webových prohlížečích, určená původně pro firmy a organizace ('enterprise policies'). Pod linuxem je skriptem pro automatickou úpravu nastavení prozatím podporován pouze prohlížeč Firefox.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.18. Díky 174 přispěvatelům.
Miliardy korun na digitalizaci služeb státu nestačily. Stát do ní v letech 2020 až 2024 vložil víc než 50 miliard korun, ale původní cíl se nepodařilo splnit. Od loňského února měly být služby státu plně digitalizované a občané měli mít právo komunikovat se státem digitálně. Do tohoto data se povedlo plně digitalizovat 18 procent agendových služeb státu. Dnes to uvedl Nejvyšší kontrolní úřad (NKÚ) v souhrnné zprávě o stavu digitalizace v Česku. Zpráva vychází z výsledků víc než 50 kontrol, které NKÚ v posledních pěti letech v tomto oboru uskutečnil.
Nadace Wikimedia, která je provozovatelem internetové encyklopedie Wikipedia, oznámila u příležitosti 25. výročí vzniku encyklopedie nové licenční dohody s firmami vyvíjejícími umělou inteligenci (AI). Mezi partnery encyklopedie tak nově patří Microsoft, Amazon a Meta Platforms, ale také start-up Perplexity a francouzská společnost Mistral AI. Wikimedia má podobnou dohodu od roku 2022 také se společností Google ze skupiny
… více »D7VK byl vydán ve verzi 1.2. Jedná se o fork DXVK implementující překlad volání Direct3D 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Byla vydána verze 12.0.0 knihovny libvirt (Wikipedie) zastřešující různé virtualizační technologie a vytvářející jednotné rozhraní pro správu virtuálních strojů. Současně byl ve verzi 12.0.0 vydán související modul pro Python libvirt-python. Přehled novinek v poznámkách k vydání.
CreepyLink.com je nový zkracovač URL adres, 'díky kterému budou vaše odkazy vypadat tak podezřele, jak je to jen možné'. Například odkaz na abclinuxu.cz tento zkracovač převádí do podoby 'https://netflix.web-safe.link/logger_8oIlgs_free_money.php'. Dle prohlášení autora je CreepyLink alternativou ke zkracovači ShadyURL (repozitář na githubu), který dnes již bohužel není v provozu.
Na blogu Raspberry Pi byla představena rozšiřující deska Raspberry Pi AI HAT+ 2 s akcelerátorem Hailo-10 a 8 GB RAM. Na rozdíl od předchozí Raspberry Pi AI HAT+ podporuje generativní AI. Cena desky je 130 dolarů.
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.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
12.9.2009 17:17
12.9.2009 23:40
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 
13.9.2009 11:59
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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:
