Portál AbcLinuxu, 6. května 2025 06:10
/etc/nsswitch.conf
– ale jde to jenom globálně, tj. pořadí v jakém se budou hledat skupiny (např. nejprve v LDAP, pak v souborech). Vezme se údaj z první databáze, ve které skupina je uvedená – tj. nelze mít stejnou skupinu i v souboru i v LDAP a čekat, že se tyto dvě skupiny spojí. Tj. pokud dáte LDAP na první místo, budou se jako první prohledávat skupiny v LDAP i pro uživatele z lokálního souboru, a pokud bude příslušná skupina nalezena v LDAP, jako by už v /etc/groups
nebyla.
nsswitch.conf
).
Ani mne nenapadá důvod, proč by mělo být potřeba hledat skupiny k uživatelům v LDAPu jen v LDAPu – běžné je to, že v souborech máte jen „systémové“ uživatele – root a uživatele, pod kterými běží služby, plus případně související skupiny – aby systém běžel, i když nebude mít přístup k LDAPu. No a lidské uživatele a jejich skupiny už pak máte v LDAPu. Nenapadá mne důvod, proč by se tyto „systémové“ a „lidské“ účty a skupiny měly nějak prolínat. Třeba má váš problém řešení v jiném uspořádání skupin.
nss_initgroups backlink
v ldap.conf
, ale to by asi znamenalo změnit strukturu LDAP databáze – a pouze jsem to našel v dokumentaci, nemám v praxi vyzkoušené, jak to funguje.
group: compat [SUCCESS=continue] ldapTo by možná mohlo dělat to, co potřebuju, ne? Jen doufám že se compat nepřeskočí i v případě, že ldap bude nedostupný.
nss_reconnect_tries 6 nss_reconnect_sleeptime 1 nss_reconnect_maxsleeptime 2 nss_reconnect_maxconntries 6 bind_policy soft bind_timelimit 30Pokud změním bind_policy na hard, se kterým by to asi fungovalo tak jak má a nemusel bych vůbec řešit tuhle diskusi se to sekne při bootu, protože se neustále prohledává tento zdroj i když je omezen počet pokusů a v nsswitch.conf je ldap [NOTFOUND=continue] compat. Možná byste mi pomohl s tímhle ??
[NOTFOUND=continue]
se uplatní, pokud není skupina nalezena – nikoli v případě, že nefunguje spojení. Navíc tohle chování je defaultní. To nastavení, které máte, by mělo vést k maximálnímu timeoutu 11 sekund (jestli dobře počítám). Přikládám výpis z Gentooovského ldap.conf, ať to nemusím složitě vysvětlovat:
# Timeout behavior # Upstream nss_ldap hard-codes these values: #nss_reconnect_tries 5 # number of times to double the sleep time #nss_reconnect_sleeptime 4 # initial sleep value #nss_reconnect_maxsleeptime 64 # max sleep value to cap at #nss_reconnect_maxconntries 2 # how many tries before sleeping # This leads to a delay of 124 seconds (4+8+16+32+64=124) per lookup if the # server is not available. # For Gentoo's distribution of nss_ldap, as of 250-r1, we use these values # (The hardwired constants in the code are changed to them as well): nss_reconnect_tries 4 # number of times to double the sleep time nss_reconnect_sleeptime 1 # initial sleep value nss_reconnect_maxsleeptime 16 # max sleep value to cap at nss_reconnect_maxconntries 2 # how many tries before sleeping # This leads to a delay of 15 seconds (1+2+4+8=15) # If you are impatient, and know your LDAP server is reliable, fast or local, # you may wish to use these values instead: #nss_reconnect_tries 1 # number of times to double the sleep time #nss_reconnect_sleeptime 1 # initial sleep value #nss_reconnect_maxsleeptime 1 # max sleep value to cap at #nss_reconnect_maxconntries 3 # how many tries before sleeping # This leads to a delay of 1 second.Problém bude asi právě jen s tou skupinou
plugdev
. Protože ta je potřeba už při inicializaci zařízení udev
em, tzn. ještě před tím, než se inicializuje síťová karta a tedy před tím, než se LDAP může připojit k síti. Je to takový provblém, co bylo dřív, jestli vejce, nebo slepice udev
), a pak start sítě předřadit i udev
(nebo hotplug
) startovacímu skriptu. Což může být docela ošklivý zásah do startovacích skriptů.
Další možnost je mít dva nsswitch.conf
, jeden pro boot (kde bude pořaíd compat ldap) a druhý, kterým se ten první po bootu nahradí (s opačným pořadím). To taky není moc hezké řešení, navíc pro aplikaci platí nejspíš ten, který viděla při svém startu – protože si jej při startu přečte a dál jej již nekontroluje.
Nejlepší řešení by byla knihovna nss, která by uměla obalit volání více podřízených knihoven a vytvořit z toho jednu sdruženou skupinu. Nic takového jsem ale nenašel. Jenom popis podobného problému.
Z těch řešení, která nevyžadují nic programovat ani se pokoušet rozbít init skripty mne napadá snad jenom použít nscd
(který asi stejně používáte) a pro group
mu nastavit persistent
na yes
(vizte man nscd.conf
). Ovšem zase bude potřeba zařídit, aby se nscd
spustil ještě před hotplug…
nscd
, bude to 11 sekund pokaždé, když nějaký program tyhle údaje potřebuje (jeden proces si ty údaje asi bude cachovat, ale jakmile se spustí jiný, znovu bude čekat těch 11 sekund). Ale je fakt, že po těch 11 s by ten proces měl skočit na compat a tam už by to mělo projít. Nejsem si taky jist, co přesně dělá nss_reconnect_maxconntries
– tipoval bych, že je to počet pokusů, kdy se při neúspěchu snaží hned znova navázat spojení, a teprve když se tenhle počet vyčerpá, pokouší se navázat spojení až po pauze (která se pokaždé zdvojnásobí). Ovšem zjištění, že se nedaří navázat spojení, také může nějakou dobu trvat – opět tam musí být nějaký timeout, do kterého když se spojení nenaváže, vyhodnotí se to jako nemožnost navázat spojení. Tenhle timeout asi nastavuje bind_timelimit
(i když tedy z popisu si tím jistý nejsem), některé LDAP knihovny navíc tenhle parametr vůbec nemusí umět.
udev
v sobě spouští spoustu procesů? Každý ten proces pak začne od začátku – 1sekundový timeout, 2sekundový – a pak se spustí další proces (potomek udev
) a celé se to opakuje. Jestli můžete, zkuste zjistit PID těch čekajících procesů, nebo prostě jenom sledovat, zda se vždy před tím prvním 1sekundovým timeoutem nevytvoří nový proces.
Což by ale stejně odhalilo, proč dochází k tomu dlouhému hledání v LDAPu, ale nevyřešilo by to váš problém. Napadá mne jedině nějakým skriptem pravidelně stahovat seznam uživatelů skupiny plugdev z LDAPu a nahrazovat jím seznam uživatelů této skupiny v souboru /etc/group
. A v NSS pak mít normálně nejdřív compat a pak LDAP.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.