Dotaz: Algoritmus pro atomickou aktualizaci uživatelských jmen ve více zdrojích

[racecondition]

Ahoj. Napsal jsem si jednoduchou aplikaci pro centrální monitoring několika uživatelských databází. V zásadě jde o to, že mám centrální databázi, do které periodicky tahám ze všech spravovaných databází nějaká data (především využití kvót a další monitoring) a ta data si pak prohlížím centrálně v té centrální databázi. Tato aplikace rovněž umí měnit hromadně uživatelská hesla a chtěl bych aby uměla měnit i uživatelská jména. Problém je, že ty databáze jsou navzájem "propojené" právě na základě uživatelského jména. Proto pokud bych měnil to jméno, je to potřeba udělat nejlépe atomicky ve všech databázích najednou. Nepřišel jsem ale na to, jak to udělat, protože může třeba nastat:

* - centrální db
*  - spravovaná postgresql databáze
*  - spravovaná OpenLDAP databáze


postup změny hesla:
1. zamknu příslušné řádky v centrální databázi
2. změním jméno ve spravované postgresql db
3. selhání změny jména v OpenLDAP db, protože v té samé chvíli někdo založil uživatele se stejným jménem v této db
proto:
 4. pokusím se změnit jméno v postgresql databázi zpět, ale nastane problém, protože to staré jméno v tu samou chvíli zabere jiný (nový) uživatel

... v této chvíli mám naprosto nekonzistentní záznamy, protože nyní bude monitoring fungovat jen na databázi postgresql, ale ještě ke všemu nad úplně jiným uživatelem (ačkoliv počítám s tím, že pokud má uživatel ve všech db stejné jméno, jedná se o toho samého člověka, tak zde by měl třeba jiné uid či jiné údaje ...)

... No snad jsem tu situaci popsal jasně. Nedokážu vymyslet způsob, jakým by uživ. jméno šlo bezpečně změnit (nedá se předpokládat, že všechny spravované databáze umí transakce apod. věci). Napadá vás prosím někoho řešení nebo bych se na to měl vykašlat a v případě potřeby měnit jména ručně v každé databázi zvlášť (nebo neměnit vůbec) a neriskovat nekonzistenci dat? Existují v dnešní době vůbec systémy, které neumožňují změnu uživatelského jména?

Odpovědi

[l4m4]

Je zapotřebí nejprve všechna úložistě zamknout pro změnu, teprve až se to podaří, tak změnu provést. Pokud to některá úložiště neumějí, tak to provést na aplikační úrovni vytvořenm nějakého zamykacího záznamu (který se může týkat např. jen konkrétních id), což ovšem pak musejí všechny aplikace, které mohou měnit záznamy, ctít.

[racecondition]

S relačními databázemi nebude problém se zamykáním, ale pochybuji, že to umí třeba openldap a další. S tím, že to ty ostatní aplikace musí ctít je problém.

[l0gik]

IMHO postup by měl bejt IMHO takovejdle:

- nové jméno se zabere, ale neprovede se změna (např. založením fake usera, když nechceš )

- provede se změna ve všech child databázích

- dokončí se změna v postgresql, nebo se vrátí změny

Zdá se mi ale, že tam máš nějakej principiální problém: pokud nemáš zajíštěnou centrální autoritu na usernamy, tzn. někdo může obejít Tvůj systém a měnit přímo ldap, jak máš v modelovym případu, tak to bude děravý vždy: někdo může v jedné child databázi zabrat nové jméno a někdo jiný v druhé child databázi staré jméno a tímpádem prostě není cesta zpět.

Řešení je buďto zavést centrální autoritu, přes kterou jedině bude povoleno zakládat či měnit uživatele, nebo zavést 1:n relaci mezi uživatelem a jeho usernamy v různých databázích s tím, že v drtivé většině případů to budou vždy stejná.

[Šangala]

Pokud tabulky/záznamy mají i jiný jednoznačný identifikátor, tak si vytvoříte aplikační transakci.

1. Shromáždíte si tyto ID, tím si i „optimisticky“ ověříte dostupnost pro další úkony.
2. A začnete provádět změny v jednotlivých DB od nejkritičtější (asi LDAP) a měl by jste používat ta ID k identifikaci záznamu (v LDAPu to asi nebude úplně možné).
3. Každou změnu musíte mít potvrzenou - ošetřeno její provedení.

• Pokud proběhla poslední změna, je vše OK.
• Pokud libovolná selže, musíte provést rollback této aplikační transakce dle těch ID, tj. začnete je v opačném pořadí vracet do původního stavu.
  • Pokud nastane jakákoliv chyba, máte všechny informace aby jste si repotoval stavy a musíte si to opravit ručně (nebo dalším-něčím později).
• Pokud nastane chyba v „této“ aplikace, jste v háji, takže logovat(a flushovat) akce a jejich průběh.

[racecondition]

Jediný jednoznačný identifikátor přes všechny db je uživatelské jméno.

[Kit]

1. Uživatelská jména by se neměla měnit
2. Vytváření uživatelských jmen je nutné udělat přes nějakou centrální autoritu, nejlépe asi přes LDAP
3. Při změně jména nejprve založit nové jméno v LDAP a teprve v případě úspěchu začít měnit uživatelská jména v ostatních databázích
4. Teprve po kompletní změně smazat staré jméno v LDAP
5. Nepřipustit založení uživatele databáze, pokud není ověřen v LDAP

LDAP je výhodné, protože se snadno klonuje na podřízené stroje a přitom jeho změna se dělá výhradně centrálně. Nemůže tedy dojít ke kolizi.

Nevím, co obnáší pojem "Centrální databáze" a co v ní je, ale vypadá to, že by to měl být LDAP. Mít 2x LDAP je však zbytečné.

[xkucf03]

Uživatelská jména by se neměla měnit

Spíš primární klíč by se neměl měnit. Otázka je, jestli používat uživatelské jméno jako PK. Ale uživatelská jména se docela mění – např. vdané ženy budou chtít nové jméno, prominentní uživatelé můžou chtít nějaké nestandardní, nebo když se jména generují automaticky a někomu tam vyjde nevhodná posloupnost písmen jako třeba „fuck“ tak se to pak taky mění. Ale zažil jsem i uživatele, který chtěl změnit číselné ID, protože se mu nelíbilo a chtěl jiné…

[Kit]

O používání uživatelského jména jako PK jsem nedávno s někým vedl debatu. Pokud se uživatelské jméno nemění, je IMHO jeho použití jako PK docela výhodné.

V lepších databázích se při změně PK automaticky aktualizují i FK, ale nemůžeme to očekávat od hybridní sestavy tazatele. Možná by skutečně stálo za to každému uživateli systému generovat unikátní syntetické názvy databází. To by mj. umožnilo, aby jeden uživatel měl víc databází stejného typu.

[Filip Jirsák]

Obecně se to řeší vícefázovým commitem (obvykle dvoufázovým) – v první fázi ve všech prostředích uděláte ty náročné změny (zamykání řádků, výpočty atd.) a vše dostanete do stavu, že stačí jednoduchá akce, kterou potvrdíte, že ty změny platí. V druhé fázi pak všude ty změny potvrdíte (nebo pokud se někde nepodařila první fáze, zrušíte je). Druhá fáze je velmi jednoduchá, takže je větší pravděpodobnost, že se všude povede. Pokud se přesto nepovede, máte problém… Je také možné ještě před začátkem někam uložit popis toho, co vlastně chcete provést – pokud se pak akce nepovede, můžete ji alespoň podle tohoto postupu zopakovat.

Váš případ nemá univerzální a spolehlivé řešení – klidně se může stát, že někdo založí uživatele v LDAPu a někdo jiný stejné jméno ale pro jiného uživatele v databázi, a máte z toho taky konflikt – a ani jste nemusel nic přejmenovávat. Předpokládám tedy, že nejde o oprávnění k přístupu do velína atomové elektrárny a že to tedy nějakou tu nespolehlivost snese.

Postupoval bych tak, že bych vytvářel duplicitní záznamy – pokud chci nějaký účet přejmenovat, vytvořím záznam s duplicitními údaji, novým jménem a příznakem, že je neaktivní. Když se to povede všude, překlopím příznaky – staré záznamy zneaktivním a nové aktivuji. Nakonec smažu staré neaktivní záznamy. Případně si můžete přidat atributy označující, v jaké fázi přejmenování se daný záznam nachází a jaké je cílové/původní jméno. Všechny změny samozřejmě logujte, abyste případně věděl, kde už proběhly a kde ne. Také se to dá řešit organizačně – přejmenování naskriptujete na 3:10 ráno a zakážete mezi 3:00 a 3:30 jakékoli změny v uživatelských databázích.

[Kit]

Váš případ nemá univerzální a spolehlivé řešení – klidně se může stát, že někdo založí uživatele v LDAPu a někdo jiný stejné jméno ale pro jiného uživatele v databázi, a máte z toho taky konflikt – a ani jste nemusel nic přejmenovávat.

Stačí nadefinovat pravidlo, že všechny tyto změny je nutné nejprve autorizovat v LDAPu a na konci potvrdit. Potom ke kolizi nemůže dojít. Nikdo nesmí bez souhlasu LDAPu založit, přejmenovat nebo zrušit databázi.

[pht]

Přejmenování uživatele bych asi nedělal, kloudnější je založit nového a přetahat k němu data, pak starého případně smazat. Narozdíl od přejmenování jsou tohle všechno vratné operace, takže můžete k problému přistoupit optimisticky: všechno naivně zkusit provést a v případě neúspěchu změny vrátit a informovat uživatele. Předpokládám totiž že pravděpodobnost toho Vašeho katastrofálního scénáře je nula nula nic, takže naco se obtěžovat s nějakým zamykáním.

[racecondition]

No pravděpodobnost toho katastrofického scénáře je nyní naprosto nulová (přímý přístup k ostatním db mám v součastnosti jen já), v budoucnu bude skoro nulová. To ale neznamená že nemůže nastat a že by se to nemělo ošetřit. Ale díky za názory a nejspíš půjdu zlatou střední cestou: nejprve zavolám update na všechny podřízené databáze - v této fázi se ještě změny neprojeví, ale zamkne se co se dá a nastaví se netrvalé změny a poté po úspěchu zavolám na všechny commit. Musím počítat s tím, že v případě OpenLDAPu příp. jiných adresářových služeb nebude ta první fáze fungovat a všechny změny vytvoří teprve commit, protože pokud bych založil dočasného uživatele a v tu chvíli mi spadla aplikace, tak bych musel mít něco jako transakční log, aby se ty změny potom vrátily - to ale zanáší obrovskou pravděpodobnost dalších chyb. Za další by vytvoření dočasného uživatele mohlo vyvolat neplechu tam, kde by v budoucnu mohly běžet nějaké watchdogy hlídající existenci nového záznamu s tím, že automaticky založí uživateli třeba někde adresáře. Takže to výsledné řešení bude mít určitou pravděpodobnost neúspěchu, ale budu se snažit ji udržet jen teoretickou (nepustit nikoho nebo jen málokoho k přímé editaci ostatních db). Pokud by nastal problém, tak veškeré změny loguji + mám vytvořený docela ukecaný debugger, který mohu zapnout.

[racecondition]

Tak nakonec jsem se na to vykašlal úplně. Změnu uživatelského jména implementovat nebudu. Uvědomil jsem si, že největší problém je výpadek aplikace během změn, kde některé zůstanou provedené, jiné ne. To by se sice dalo obejít nějakým automatickým spouštěním všech neprovedených operací po znovu spuštění aplikace, ale to už by mohlo být pozdě (mohla by to být dlouhá doba a informace "zastarat").

[pht]

To ale neznamená že nemůže nastat a že by se to nemělo ošetřit.

Optimistická strategie, o které jsem hovořil, to ošetřuje, ale předpokládá, že se změna povede napoprvé, tudíž nepoužívá zámky. Viz např. http://en.wikipedia.org/wiki/Optimistic_concurrency_control

Uvědomil jsem si, že největší problém je výpadek aplikace během změn, kde některé zůstanou provedené, jiné ne.

To lze řešit stejným způsobem. Napište si program, který ověří konzistenci všech databází a můžete ho pouštět třeba cronem nebo napojit na nagios/zabbix/... V případě nekonzistence můžete opravit buď ručně nebo jednoduché případy automatizovat. Ale je zase potřeba zvážit, kolik "oprav" za rok se bude dělat, jestli má nějaká jejich automatizace význam.