abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 21:32 | Nasazení Linuxu

Canonical představuje nejnovější verzi chytré helmy DAQRI s Ubuntu pro rozšířenou realitu. K vidění bude příští týden v Barceloně na veletrhu Mobile World Congress 2017.

Ladislav Hagara | Komentářů: 0
včera 21:31 | Pozvánky

Pro zájemce o hlubší znalosti fungování operačních systémů připravila MFF UK nový předmět Pokročilé operační systémy, v rámci něhož se vystřídají přednášející nejen z řad pracovníků fakulty, ale dorazí také odborníci ze společností AVAST, Oracle, Red Hat a SUSE. Tento předmět volně navazuje na kurz Operační systémy ze zimního semestru, ale pokud máte praktické zkušenosti odjinud (například z přispívání do jádra Linuxu) a chcete si

… více »
Martin Děcký | Komentářů: 0
včera 21:30 | Pozvánky

Czech JBoss User Group Vás srdečně zve na setkání JBUG v Brně, které se koná ve středu 1. března 2017 v prostorách Fakulty Informatiky Masarykovy Univerzity v místnosti A318 od 18:00. Přednáší Tomáš Remeš a Matěj Novotný na téma CDI 2.0 - New and Noteworthy. Více informací na Facebooku a na Twitteru #jbugcz.

mjedlick | Komentářů: 0
20.2. 23:45 | Zajímavý software

Na blogu Qt bylo představeno Qt 3D Studio. Jedná se o produkt dosud známý pod názvem NVIDIA DRIVE™ Design Studio. NVIDIA jej věnovala Qt. Jedná se o několik set tisíc řádků zdrojového kódu. Qt 3D Studio bude stejně jako Qt k dispozici jak pod open source, tak pod komerční licencí. Ukázka práce s Qt 3D Studiem na YouTube.

Ladislav Hagara | Komentářů: 10
20.2. 17:50 | Komunita

Nadace The Document Foundation (TDF) zastřešující vývoj svobodného kancelářského balíku LibreOffice slaví 5 let od svého oficiálního vzniku. Nadace byla představena 28. září 2010. Formálně byla založena ale až 17. února 2012.

Ladislav Hagara | Komentářů: 0
20.2. 12:50 | Komunita

Mozilla.cz informuje, že dosud experimentální funkce Page Shot z programu Firefox Test Pilot (zprávička) se stane součástí Firefoxu. Page Shot je nástroj pro vytváření snímků webových stránek. Umí výběr oblasti, prvku stránky (např. odstavce), nebo uložení snímku celé stránky. Snímky lze ukládat na disk nebo nahrávat na server Mozilly. Nedávno bylo oznámeno, že se součástí Firefoxu stane Activity Stream.

Ladislav Hagara | Komentářů: 32
20.2. 04:10 | Nová verze

Po 10 týdnech vývoje od vydání Linuxu 4.9 (zprávička) oznámil Linus Torvalds, mj. již 20 let žijící v USA, vydání Linuxu 4.10 (LKML). Přehled nových vlastností a vylepšení například na Kernel Newbies a v Jaderných novinách (1, 2 a 3). Kódové jméno Linuxu 4.10 je Fearless Coyote.

Ladislav Hagara | Komentářů: 22
19.2. 15:55 | Zajímavý projekt

Vyzkoušet si příkazy a vyřešit několik úkolů lze na stránkách Commandline Challenge (CMD Challenge). Úkoly lze řešit různými způsoby, důležitý je výsledek. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.

Ladislav Hagara | Komentářů: 18
18.2. 17:35 | Bezpečnostní upozornění

Německá Bundesnetzagentur (obdoba českého ČTU) zakázala na německém území prodej panenky Cayla kvůli „špionáži“ dětí. Tato elektronická hračka obsahuje mikrofon, reproduktor a kameru a bezdrátové komunikační rozhraní, pomocí kterého se hračka připojuje na servery výrobce. Takovýmto způsobem může hračka pomocí umělé inteligence „odpovídat“ na dotazy dítěte. Hlavní problém bude ale asi někde jinde, podle prvotních zpráv může

… více »
Petr Tomášek | Komentářů: 34
17.2. 15:30 | Bezpečnostní upozornění

CSIRT.CZ upozorňuje, že bezpečnostní experti objevili nový typ malwaru, jenž cílí na open source e-commerce platformu Magento. Malware je zajímavý tím, že se jedná o první svého druhu, jehož kód zůstává skrytý v SQL databázi zasaženého e-shopu. Škodlivý kód je volán pomocí tzv. SQL trigerru, který je spouštěn při každém vytvoření objednávky v systému.

Ladislav Hagara | Komentářů: 6
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (13%)
 (2%)
 (72%)
 (3%)
 (10%)
Celkem 679 hlasů
 Komentářů: 61, poslední včera 13:06
Rozcestník

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

9.9.2011 15:56 racecondition
Algoritmus pro atomickou aktualizaci uživatelských jmen ve více zdrojích
Přečteno: 303×
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

9.9.2011 16:16 l4m4
Rozbalit Rozbalit vše Re: Algoritmus pro atomickou aktualizaci uživatelských jmen ve více zdrojích
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.
9.9.2011 16:44 racecondition
Rozbalit Rozbalit vše Re: Algoritmus pro atomickou aktualizaci uživatelských jmen ve více zdrojích
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.
9.9.2011 17:23 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: Algoritmus pro atomickou aktualizaci uživatelských jmen ve více zdrojích
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á.
9.9.2011 17:32 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Algoritmus pro atomickou aktualizaci uživatelských jmen ve více zdrojích
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.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
9.9.2011 18:18 racecondition
Rozbalit Rozbalit vše Re: Algoritmus pro atomickou aktualizaci uživatelských jmen ve více zdrojích
Jediný jednoznačný identifikátor přes všechny db je uživatelské jméno.
9.9.2011 18:21 Kit
Rozbalit Rozbalit vše Re: Algoritmus pro atomickou aktualizaci uživatelských jmen ve více zdrojích
  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 avatar 10.9.2011 17:19 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Algoritmus pro atomickou aktualizaci uživatelských jmen ve více zdrojích
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é…
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
10.9.2011 17:40 Kit
Rozbalit Rozbalit vše Re: Algoritmus pro atomickou aktualizaci uživatelských jmen ve více zdrojích
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.
9.9.2011 19:48 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Algoritmus pro atomickou aktualizaci uživatelských jmen ve více zdrojích
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.
9.9.2011 20:35 Kit
Rozbalit Rozbalit vše Re: Algoritmus pro atomickou aktualizaci uživatelských jmen ve více zdrojích
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.
9.9.2011 20:12 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Algoritmus pro atomickou aktualizaci uživatelských jmen ve více zdrojích
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.

In Ada the typical infinite loop would normally be terminated by detonation.
9.9.2011 21:04 racecondition
Rozbalit Rozbalit vše Re: Algoritmus pro atomickou aktualizaci uživatelských jmen ve více zdrojích
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.
10.9.2011 02:04 racecondition
Rozbalit Rozbalit vše Re: Algoritmus pro atomickou aktualizaci uživatelských jmen ve více zdrojích
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").
10.9.2011 13:29 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Algoritmus pro atomickou aktualizaci uživatelských jmen ve více zdrojích
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.
In Ada the typical infinite loop would normally be terminated by detonation.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.