Portál AbcLinuxu, 13. května 2025 23:11
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.
2.12.2012 15:24
pavlix | skóre: 54
| blog: pavlix
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.
2.12.2012 23:18
pavlix | skóre: 54
| blog: pavlix
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.
3.12.2012 09:02
pavlix | skóre: 54
| blog: pavlix
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:
5.12.2012 12:30
pavlix | skóre: 54
| blog: pavlix
7.12.2012 14:54
pavlix | skóre: 54
| blog: pavlix
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).
7.12.2012 20:50
pavlix | skóre: 54
| blog: pavlix
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č.
7.12.2012 23:36
pavlix | skóre: 54
| blog: pavlix
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:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.