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í
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 21:21 | Nová verze Ladislav Hagara | Komentářů: 0
včera 11:44 | Zajímavý projekt

Na Indiegogo byla spuštěna kampaň na podporu herní mini konzole a multimediálního centra RetroEngine Sigma od Doyodo. Předobjednat ji lze již od 49 dolarů. Požadovaná částka 20 000 dolarů byla překonána již 6 krát. Majitelé mini konzole si budou moci zahrát hry pro Atari VCS 2600, Sega Genesis nebo NES. Předinstalováno bude multimediální centrum Kodi.

Ladislav Hagara | Komentářů: 0
včera 00:10 | Nová verze

Byla vydána verze 4.7 redakčního systému WordPress. Kódové označením Vaughan bylo vybráno na počest americké jazzové zpěvačky Sarah "Sassy" Vaughan. Z novinek lze zmínit například novou výchozí šablonu Twenty Seventeen, náhledy pdf souborů nebo WordPress REST API.

Ladislav Hagara | Komentářů: 1
6.12. 12:00 | Zajímavý projekt

Projekt Termbox umožňuje vyzkoušet si linuxové distribuce Ubuntu, Debian, Fedora, CentOS a Arch Linux ve webovém prohlížeči. Řešení je postaveno na projektu HyperContainer. Podrobnosti v často kladených dotazech (FAQ). Zdrojové kódy jsou k dispozici na GitHubu [reddit].

Ladislav Hagara | Komentářů: 25
6.12. 11:00 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2016-8655 v Linuxu zneužitelné k lokální eskalaci práv. Chyba se dostala do linuxového jádra v srpnu 2011. V upstreamu byla opravena minulý týden [Hacker News].

Ladislav Hagara | Komentářů: 2
5.12. 22:00 | Komunita

Přibližně před měsícem bylo oznámeno, že linuxová distribuce SUSE Linux Enterprise Server (SLES) běží nově také Raspberry Pi 3 (dokumentace). Obraz verze 12 SP2 pro Raspberry Pi 3 je ke stažení zdarma. Pro registrované jsou po dobu jednoho roku zdarma také aktualizace. Dnes bylo oznámeno, že pro Raspberry Pi 3 je k dispozici také nové openSUSE Leap 42.2 (zprávička). K dispozici je hned několik obrazů.

Ladislav Hagara | Komentářů: 6
5.12. 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 50
5.12. 06:00 | Zajímavý článek

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 10
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 17
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (8%)
 (5%)
 (3%)
Celkem 786 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

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: 300×
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.