Český telekomunikační úřad zahajuje novou etapu využívání vysokofrekvenčního rádiového spektra v pásmu 26 GHz. Toto pásmo bude od 1. 7. 2026 otevřeno pro provoz moderních bezdrátových sítí, zejména sítí páté generace (5G), pevných bezdrátových přístupových sítí (FWA) a lokálních či průmyslových sítí určených například pro výrobní areály, logistická centra nebo technologické kampusy. Současně s otevřením pásma 26 GHz přistoupil ČTÚ ke zpřístupnění informací o využívání rádiových kmitočtů v tomto pásmu.
Logitech představil myš Signature Comfort Plus M850 L s polstrovanou opěrkou dlaně pro větší pohodlí a sadu s touto myší a klávesnicí s integrovanou opěrkou dlaní Signature Comfort Plus Combo MK880.
Gaël Duval se rozepsal o novinkách a plánech Murena a /e/OS. Počet uživatelů telefonů Murena a mobilního operačního systému /e/OS bez aplikací a služeb od Googlu se blíží 100 000. Ambicí je, aby se /e/OS stal třetí mobilní platformou v Evropě i na světě, s potenciálem dostat se i na PC. Blíží se vydání nové verze 4 s funkcemi zálohování a obnova, import e-mailů z Gmailu a rozpoznávání hlasu. Murena Workspace přinese videohovory, elektronický podpis a správu zařízení (MDM).
Dnes a zítra probíhá Ubuntu Summit 26.04. Na programu je řada zajímavých přednášek. Sledovat je lze na YouTube. Úvodní slovo měli Mark Shuttleworth a Jon Seager.
Lazygit byl vydán ve verzi 0.62.0. Jedná se o TUI (Text User Interface) nadstavbu nad gitem.
Jiří Eischmann se v příspěvku na svém blogu o rozepsal o tom, kam se vyhledávání v jeho očích posledních 10 let posunulo, jaké má zkušenosti s AI vyhledáváním, proč na něm nechce záviset a jaké vyhledávací služby ho v poslední době zaujaly.
Wayland kompozitor Labwc byl vydán ve verzi 0.20.0. Labwc je inspirován správcem oken Openbox. Postavený je na wlroots.
AlmaLinux OS byl vydán ve verzích 9.8 s kódovým jménem Olive Jaguar a 10.2 s kódovým jménem Lavender Lion. Podrobnosti v poznámkách k vydání (9.8 a 10.2). Opraveny byly zranitelnosti Copy Fail (CVE-2026-31431), Dirty FRAG, Fragnesia (CVE-2026-46300), nginx Rift (CVE-2026-42945) a SSH Keysign Pwn (CVE-2026-46333).
Seznam.cz vykázal za rok 2025 tržby v celkové hodnotě 6,454 miliardy korun. Oproti roku 2024 nárůst o 3,68 %. Zisk před zdaněním oproti předcházejícímu roku poklesl, a to o 11,21 % na 1,330 miliardy korun. Vlastní velké jazykové modely SeLLMa najdou dnes uživatelé téměř na všech seznamáckých službách. Na všechny obsahové služby byla zavedena technologie text-to-speech, díky níž si mohou uživatelé přehrát články v audio verzi namluvené
… více »Vláda představila strategické digitalizační projekty. Roadmapa zahrnuje celkem 55 projektů napříč státní správou, z toho 22 prioritních projektů vycházejících přímo z programového prohlášení vlády a 33 projektů založených na platné legislativě. Portfolio pokrývá oblasti financí, zdravotnictví, digitální identity, dat, registrů, dopravy, krizového řízení, sociálních agend i kybernetické bezpečnosti.
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:
