V neděli 11. října proběhne rotace klíče kořenové zóny. Podruhé v historii. Ondřej Filip na blogu CZ.NIC: "Pokud je pro Vás DNS protokol spíše výzva, ale přesto spravujete nějakou síť či DNS resolver, zkuste si jednoduchý test, který připravila firma Cloudflare na této adrese. Obzvláště zbystřit byste měli, pokud uvidíte nějaká červená políčka."
Vláda Spojených států se rozhodla vyřadit americkou softwarovou společnost Microsoft a několik dalších velkých technologických podniků z programu, který umožňuje kvalifikovaným zahraničním pracovníkům získat povolení k trvalému pobytu. Oznámila to včera administrativa amerického prezidenta Donalda Trumpa. Opatření zdůvodnila rozsáhlým zneužíváním programu, který je dlouhodobě terčem kritiky ze strany Trumpových příznivců, neboť prý znevýhodňuje americké pracovníky.
Datové centrum největší ruské technologické společnosti Jandex v Rjazaňské oblasti se stalo cílem dronového útoku a zastavilo provoz. Jandexu se někdy přezdívá „ruský Google“. Provozuje nejoblíbenější internetový vyhledávač v Rusku nebo aplikace pro objednávky jídla a taxi. Využívají jej desítky milionů lidí v rusky mluvících zemích.
Francouzská společnost Mistral AI představila Mistral Large 4 (interně přezdívaný 'le Chonk', volně přeloženo 'pořádný macek'), 'open-weight multimodální hybridní instruct-and-reasoning model s architekturou granulárního MoE, nativně podporující více jak 160 jazyků'. Model má přes jeden bilión parametrů, z nichž při práci využívá 49 miliard, kontextové okno o délce milion tokenů a obrazový enkodér o 1,6 miliardách parametrů.
… více »Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.20. Díky 227 přispěvatelům.
Simon Long oznámil Raspberry Pi Desktop pro PC a Mac s Intelem postavený na aktualizovaném Debianu 13 Trixie. S klientem Raspberry Pi Connect pro vzdálenou správu. Ke stažení je vedle Raspberry Pi OS pro Raspberry Pi.
ESP32-C3 adblock přemění lacinou vývojovou desku ESP32‑C3 na samostatný DNS blokovač nejenom reklamních domén, minimalistickou alternativu k populárnímu Pi-hole. ESP32-C3 adblock místo objemných názvů domén ukládá jejich 40-bitové FNV-1a hashe do flash paměti, které pak binárně prohledává, kontrola jedné domény trvá přibližně 10 milisekund. Blocklist pojme až 537 tisíc domén a lze jej spravovat přes webové rozhraní. Projekt zatím
… více »ArtCraft je sada open source aplikací pro práci s obrázky a videi "inspirovaných" aplikacemi od Adobe. Napsaných v Rustu. Pro MacOS, Windows i Linux. Běží také ve webovém prohlížeči. Aktuálně se jedná o 7 aplikací: PhotoCraft (Photoshop), VectorCraft (Illustrator), FilmCraft (Premiere Pro), LightCraft (Lightroom), PdfCraft (Acrobat), EffectCraft (After Effects) a DesignCraft (InDesign). Zdrojové kódy jsou k dispozici na GitHubu.
Strands Decider 2B je malý open-source model s 2 miliardami parametrů, určený k rychlé klasifikaci vstupů a rozhodování mezi možnostmi, generující odpovědi ve stylu modelu Jev. Strands dosáhl přibližně 72% shody s Jevem na veřejné testovací sadě JevBench (tento benchmark pochopitleně nepředstavuje přímé srovnání s modelem Jev). Zdrojové kódy jsou k dispozici na GitHubu pod licencí Apache-2.0, váhy modelu na Hugging Face.
Ve věku 90 let zemřela americká softwarová inženýrka Margaret Hamiltonová, která vedla tým, jenž vyvíjel letový software pro program Apollo amerického Národního úřadu pro letectví a vesmír (NASA).
Dobrý den.
Kdysi jsem si rozchodil ověřování účtů vůči LDAP a čerpal jsem z návodu Zděňka Burdy: http://ldap.zdenda.com/. Pokud nejsem v síti, heslo se ověří z cache a systém bez problému najede. Problém nastane ale ve chvíli, když jsem připojený k jakékoliv jiné sítí a ověření se neúměrně protáhne, protože se hledá můj LDAP server. Dá se, prosím Vás, někde nastavit nějaký timeout, jak dlouho se má v případě připojení LDAP server hledat, popř. určit, že online ověření bude probíhat pouze, pokud bude PC aktuálné v konkrétním síťovém rozsahu? Díky moc.
tak si nainstalujte/spustite sluzbu NSCD. netreba v nej nic standardne nastavovat. NSCD je Name Switch Caching Daemon a jeho pouzitie je prave v takychto pripadoch.
...alebo uz nizsie spominany SSSD (ak je sucastou vasej distribucie). NSCD bude urcite.
tak si nainstalujte/spustite sluzbu NSCD. netreba v nej nic standardne nastavovat. NSCD je Name Switch Caching Daemon a jeho pouzitie je prave v takychto pripadoch.Nejsem si teď úplně 100% jistý, ale mám podezření, že nscd na takovéto případy není vůbec stavěný.
Neviem o inej aplikacii/utilite, ktora by poskytovala takuto funkcnost. Ked si vezmete ze SSSD je relativne nova vec, tak okrem NSCD osobne nic ine nepoznam.
A vyzera ze na podobne pouzitie asi stavany je.
podla popisu cacheuje do suborov. dlzka platnosti zaznamov nieje zavisla od restartu sluzby/systemu ale od konfiguracneho parametra. da sa zvlast nastavit pre pozitivne aj negativne odpovede. na linku, ktory som pastol je vidiet ukazku cachingu po dobu 30 dni (avsak ta dlzka je asi pritiahnuta za vlasy v tomto pripade).
a ano, podla mojho pochopenia sa cacheuje len to, co je pocas jeho behu dotazovane a nie databazu ako celok. ano, je to urcite obmedzenie, ale ak uvazime ze zariadenie ktore sa pouziva aj v offline rezime je notebook konkretneho cloveka (jedneho pouzivatela), tak tipujem ze funkcnost demona je vo vacsine postacujuca.
podla popisu cacheuje do suborov.Asi bych si to měl někdy pořádně načíst, vypadá to, že to toho umí daleko víc, než jsem tušil.
ale ak uvazime ze zariadenie ktore sa pouziva aj v offline rezime je notebook konkretneho cloveka (jedneho pouzivatela), tak tipujem ze funkcnost demona je vo vacsine postacujuca.Pak bych to ale viděl spíš jako užitečný hack, než jako plnohodnotné řešení.
Na vyriesenie tohto problemu je tiez k dispozicii utilita: nss_updatedb. Citujem: "The nss_updatedb utility maintains a local cache of network directory user and group information. Used in conjunction with the pam_ccreds module, it provides a mechanism for disconnected use of network directories. These tools are designed to work with pam_ldap and nss_ldap, also available from PADL."a ano, podla mojho pochopenia sa cacheuje len to, co je pocas jeho behu dotazovane a nie databazu ako celok. ano, je to urcite obmedzenie, ale ak uvazime ze zariadenie ktore sa pouziva aj v offline rezime je notebook konkretneho cloveka (jedneho pouzivatela), tak tipujem ze funkcnost demona je vo vacsine postacujuca.
Takze suma sumarum. Problem je v chybajucom cachingu, kedze normalne sa vzdy vsetko preklada on-the-fly. Moznosti na riesenie - teda caching demony - su potrebne pri pouzivani zariadenia prepojeneho s adresarovou sluzbou v offline rezime.
Moznosti:
/etc/init.d/nscd start).
Je mozne, ze tie TTL hodnoty su vo Vasom pripade male. Totiz keby ste si spravili strace na lubovolnu aplikaciu (napr getent, id, etc.) tak zistite, ze po nacitani vsetkych potrebnych konfigurakov (nsswitch.conf, passwd, group, (libnss_)ldap.conf, ..) nasleduje pouzitie NSCD socketu. A iba v pripade, ze NSCD nie je zapnute (teda socket neexistuje), tak aplikacia pokracuje v pripajani sa na databazy (napr. LDAP) (postupne podla nsswitch.conf), ktore su vykonfene v konfigurakoch, ktore predtym nacitala.
V principe si teda myslim, ze pokial bezi NSCD, tak aplikacia sa sama nikdy priamo nepripaja na cielovu databazu/zdroj, pretoze aj keby NSCD nemal k dispozicii dany/ziadany zaznam, tak toto spojenie vykona on (NSCD) sam a nasledne tieto data preposle aplikacii a zaroven ich nacacheuje do svojej internej cache.
strace na id a nejdýl to visí na:
connect(4, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("10.0.10.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
poll([{fd=4, events=POLLOUT|POLLERR|POLLHUP}], 1, 5000) = 0 (Timeout)
kde 10.0.10.1 je adresa LDAP serveru
read(3, "# Dynamic resolv.conf(5) file fo"..., 4096) = 172
read(3, "", 4096) = 0
close(3) = 0
munmap(0x7f0a5fe7c000, 4096) = 0
uname({sys="Linux", node="hp-ntb", ...}) = 0
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = 0
ok, a ked sa to connectlo, tak co bolo dalej? boli tam nejake read/write operacie? inak povedane treba prist na to, preco vam nebola vratena nacacheovana hodnota.
druha vec: ako to skusate? predstavujem si to nasledovne:
Mne sa to proste cele nezda. Ak ma raz dane udaje nacacheovane NSCD, tak nieje jediny dovod ich ziadat znova aj keby mala byt konektivita k adresarovej sluzbe funkcna. Proste nacacheovane zaznamy maju svoje TTL pocas ktorej su v platnosti a vtedy nema co ziadny dotaz smerovat na externu sluzbu.
@Dan: mozete sem pastnut obsah suboru /etc/nscd.conf ? Tiez napiste co mate za distribuciu a verziu.
Ja si toto spravanie vyskusam vo vlastnom environmente pre porovnanie.
# /etc/nscd.conf # logfile /var/log/nscd.log # threads 4 # max-threads 32 # server-user nobody # stat-user somebody debug-level 0 # reload-count 5 paranoia no # restart-interval 3600 enable-cache passwd yes positive-time-to-live passwd 600 negative-time-to-live passwd 20 suggested-size passwd 211 check-files passwd yes persistent passwd yes shared passwd yes max-db-size passwd 33554432 auto-propagate passwd yes enable-cache group yes positive-time-to-live group 3600 negative-time-to-live group 60 suggested-size group 211 check-files group yes persistent group yes shared group yes max-db-size group 33554432 auto-propagate group yes # hosts caching is broken with gethostby* calls, hence is now disabled # per default. See /usr/share/doc/nscd/NEWS.Debian. enable-cache hosts no positive-time-to-live hosts 3600 negative-time-to-live hosts 20 suggested-size hosts 211 check-files hosts yes persistent hosts yes shared hosts yes max-db-size hosts 33554432 enable-cache services yes positive-time-to-live services 28800 negative-time-to-live services 20 suggested-size services 211 check-files services yes persistent services yes shared services yes max-db-size services 33554432 enable-cache netgroup yes positive-time-to-live netgroup 28800 negative-time-to-live netgroup 20 suggested-size netgroup 211 check-files netgroup yes persistent netgroup yes shared netgroup yes max-db-size netgroup 33554432Moc dekuju.
no, pozrime sa na casovanie:
positive-time-to-live passwd 600 negative-time-to-live passwd 20
toto znamena, ze pozitivne odpovede (na passwd databazu) sa cachuju na 600s (co je 10minut). Negativne na 20 sekund.
samozrejme ze tieto hodnoty su uplne naprd v pripade, ze chcete nscd vyzivat v pure-offline rezime. kedze to s notebookom nestihnete prejst ani domov/do inej siete a uz su zaznamy expirovane. v tomto pripade sa bavime o absolutnom case od ulozenia do cache po skutocny casovy koniec na zaklade parametra TTL (teda nerata sa len cisty cas pokial je PC zapnuty, ale komplet cas).
skuste tieto hodnoty upravit nasledovne:positive-time-to-live passwd 86400 negative-time-to-live passwd 86400 positive-time-to-live group 86400 negative-time-to-live group 86400
potom restartnut NSCD, porobit v online rezime nejake operacie na dotazy pouzivatelov a skupin (id, getent,....) no a nasledne prejst od offline rezimu alebo do kompletne inej siete. tu uz budete mat dostatocny cas, nakolko zaznamy v cache maju platnost cely den.
skuste to otestovat a dajte feedback
nscd -i passwd" a "nscd -i group" aby ste vsetky existujuce nacacheovane zaznamy vymazali (kedze asi budu stale s povodnym TTL)myslim si ze zaznamy expiruju. NSCD demona netrapi ze ste v offline rezime, on take veci neriesi.
druha moznost je nastavit vysoke TTL na zaznamy (pre pozitivne aj negativne odpovede), napr 30 dni. a po pripojeni do firemnej/spravnej siete proste zaznamy invalidovat (teda nechat ich okamzite expirovat) uz spominanym prikazom "nscd -i passwd" a "nscd -i group". a pocas doby pripojenia sa nacacheuju zaznamy znova. toto je sice manualny postup (na tu invalidaciu a zistenie spravnej siete), ale mozno by sa to dalo nejak vyladit aby to bolo automatizovane (ale mozno by ten sposob spocival v pouziti vlastneho skriptu, neviem).
Proste nacacheovane zaznamy maju svoje TTL pocas ktorej su v platnosti a vtedy nema co ziadny dotaz smerovat na externu sluzbu.Tak pokud má problémy s tím, že služba laguje na cizích sítích, tak je pravděpodobné, že je TTL v tu dobu už pryč.
nss_updatedb mam, asi jsem to prehledl. Mam nastaveno presne takto http://www.ictspecialista.cz/archives/609
passwd: files ldap [NOTFOUND=return] db group: files ldap [NOTFOUND=return] dba crond?
sudo echo '#!/bin/sh' | sudo tee /etc/cron.daily/upd-local-nss-db && sudo echo `which nss_updatedb` ldap | sudo tee -a /etc/cron.daily/upd-local-nss-db && sudo chmod +x /etc/cron.daily/upd-local-nss-db
) a funguje to presne tak, ako o tom pisem:
Sice ako LDAP connector som nepouzil nss_ldap (klasicka PADL verzia), ale nss-pam-ldapd (kedze nss_ldap uz podla vsetkeho nieje sucastou CentOS 6). Ale to by malo byt uplne jedno, kedze princip komunikacie jednotlivych komponentov je rovnaky.
Viete si to realne predstavit s X rovnakymi zamestnancami vo firme s firemnym notebookom a nutnosti pripojenia na firemny adresar? ja teda nie :) o bezpecnosti nehovoriac.
Tiskni
Sdílej: