Po více než roce vývoje od vydání verze 5.40 byla vydána nová stabilní verze 5.42 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 64 vývojářů. Změněno bylo přibližně 280 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Byla vydána nová stabilní verze 7.5 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 138. Přehled novinek i s náhledy v příspěvku na blogu.
Sniffnet je multiplatformní aplikace pro sledování internetového provozu. Ke stažení pro Windows, macOS i Linux. Jedná se o open source software. Zdrojové kódy v programovacím jazyce Rust jsou k dispozici na GitHubu. Vývoj je finančně podporován NLnet Foundation.
Byl vydán Debian Installer Trixie RC 2, tj. druhá RC verze instalátoru Debianu 13 s kódovým názvem Trixie.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červen (YouTube).
Libreboot (Wikipedie) – svobodný firmware nahrazující proprietární BIOSy, distribuce Corebootu s pravidly pro proprietární bloby – byl vydán ve verzi 25.06 "Luminous Lemon". Přidána byla podpora desek Acer Q45T-AM a Dell Precision T1700 SFF a MT. Současně byl ve verzi 25.06 "Onerous Olive" vydán také Canoeboot, tj. fork Librebootu s ještě přísnějšími pravidly.
Licence GNU GPLv3 o víkendu oslavila 18 let. Oficiálně vyšla 29. června 2007. Při té příležitosti Richard E. Fontana a Bradley M. Kuhn restartovali, oživili a znovu spustili projekt Copyleft-Next s cílem prodiskutovat a navrhnout novou licenci.
Svobodný nemocniční informační systém GNU Health Hospital Information System (HIS) (Wikipedie) byl vydán ve verzi 5.0 (Mastodon).
Open source mapová a navigační aplikace OsmAnd (OpenStreetMap Automated Navigation Directions, Wikipedie, GitHub) oslavila 15 let.
Vývojář Spytihněv, autor počítačové hry Hrot (Wikipedie, ProtonDB), pracuje na nové hře Brno Transit. Jedná se o příběhový psychologický horor o strojvedoucím v zácviku, uvězněném v nejzatuchlejším metru východně od všeho, na čem záleží. Vydání je plánováno na čtvrté čtvrtletí letošního roku.
Stejné dns jméno pro komunikaci na interní síti i na veřejné. Tj. v interní síti se přes "sluzba.corp.domena.cz" dostaneme na web serveru 192.168.1.1
Z veřejné sítě se dostaneme přes "sluzba.corp.domena.cz" na veřejnou IP (třeba i s port forwardem) na ten stejný server / stejnou službu.
Pokud nemáme k dispozici dns API (nebo neumíme emulovat editování txt přes web interface), tak jediné rozumné ověření v současné době je přes "http-01", tj. server, kde generujeme žádost, musí být přístupný z venku. Resp. musí být přístupný ověřovací klíč/acme žádost v kombinaci s dns jménem. V tomto případě pak vypadá Split DNS jako nezbytnost.
Pokud je nějaký web dostupný jen z interní sítě, tak by i nebylo špatné informovat uživatele o tom, že se na něj dostanou jen z VPN. Tzn., pokud zadají url z veřejné sítě a nejsou na vpn, dostanou hlášku, ať se na vpn připojí.
Zkusil jsem nasadit Split DNS právě kvůli LetsEncrypt, ale i kvůli informační hlášce a kvůli tomu, že nějaké aplikace jsou dostupné jak z interní sítě, tak z veřejné a nechci dělat uživatelům zmatek s různými dns jmény. Velký problém je ale dns cache. Uživatel není na vpn, otevře web, zjistí z hlášky, že musí na vpn, tak se přihlásí, ale stále se mu adresa překládá s veřejnou IP, prostě se tahá z cache.
Windows mají by default službu, která si dělá dns cache. Dále Chrome je v tomto ještě horší, protože má v sobě vlastní mechanismus a drží si vlastní dns cache. Nicméně ta by měla být maximálně 1min (chrome://net-internals/#dns ), nicméně má další fce, které zřejmě občas ignorují nastavené dns v systému. Jednou z těch fcí je u mobilní app "Async DNS resolver" (chrome://flags), v desktop verzi se to jmenuje "preconnect predictor". Další fce v mobilní app je "spořič dat". Dokud neexistuje pro jméno veřejné dns, tak se o těchto fcí člověk nedozví, ale jakmile se dns záznam vytvoří, tak se postupně začnou všechny možné super cool featurky ozývat.
V kombinaci s BYOD je řešení nějaké cache docela blbě řešitelné. Zkusil jsem to nahodit jako FAQ v error hlášce, ozvalo se asi 10 lidí z 300 a postupně se vše vyřešilo a FAQ upravilo. Nicméně toto nevypadá jako ideální cesta. Možná to půjde, možná ne.
Proto přemýšlím, zda touto cestou jít, nebo se na to vykašlat, požádat si o 2r. wildcard cert od nějaké CA, držet ho na jednom místě na jednom proxy serveru a finýto. A zbytek věcí neřešit.
Jak jste na tom vy? Používáte někdo Split DNS? Případně pokud ano, jak řešíte dns cache a problémy s tím spojené? Nebo všechno máte přístupné i z venku a tak je vám jedno, jak se dns přeloží?
Zdar Max
Tiskni
Sdílej:
V praci pouzivame velku reverznu proxy, cez ktoru ide pristup k internym serverom a jej IP je vystavena v DNS zaznamoch. Tie su verejne. Ked niekto pristupuje z firmy z 802.1x autorizovaneho ethernet portu, tak sa nemusi dalej overovat. Inak sa k proxy overuje klientskym certifikatom alebo menom a heslom a podla kombinacie overenia dostane pristup.
Proxy vynucuje https a ma wildcard certifikat pre vsetky interne domeny. Celkovo je to jednoduche, umoznuje to kontrolovany a bezpecny pristup aj bez VPN.
Verejny popis: https://ai.google/research/pubs/pub43231
Používáte někdo Split DNS?Nie. Čo tak firemná Android/iOS appka aby to bolo userfriendly aj spolahlivé. Na desktope NWjs aplikácia.
Jo, normálně to používám.
Historicky to byl trochu opruz zmínit každému uživateli, že pokud chce jít na server, musí si nejdříve pustit VPNku, ale kupodivu to nezpůsobovalo ani moc problémů. Respektive si nyní nevybavuji jediný. Jen jsem to holt všem novým uživatelům prostě důrazně zmínil.
Jelikož používám víceméně výhradně OpenVPN, tak mně to již nepálí, neboť od nějaké doby mají pro Windows klienta parametr, aby vyprázdil cache při připojení. Na Linuxu to dělá NetworkManager automaticky a z mobilů se zatím nikdo nepřipojuje, takže nevím jak to tam funguje.
Ovšem výše uvedený nápad s routováním veřejných adres zní zajímavě. Také nad tím popřemýšlím :)
fd00::...
).