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 23:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. brněnský sraz, který proběhne v pátek 20. října od 18:00 hodin v restauraci Time Out na adrese Novoměstská 2 v Řečkovicích. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
včera 21:44 | Nová verze

Byla vydána verze 5.2.0 multiplatformního virtualizačního nástroje Oracle VM VirtualBox. Jedná se o první stabilní verzi z nové větve 5.2. Z novinek lze zmínit například možnost exportování VM do Oracle Cloudu, bezobslužnou instalaci hostovaného systému nebo vylepšené GUI. Podrobnosti v seznamu změn. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 1
včera 14:00 | Zajímavý projekt

Byl spuštěn Humble Down Under Bundle. Za vlastní cenu lze koupit multiplatformní hry The Warlock of Firetop Mountain, Screencheat, Hand of Fate a Satellite Reign. Při nadprůměrné platbě (aktuálně 3,63 $) také Hacknet, Hacknet Labyrinths, Crawl a Hurtworld. Při platbě 12 $ a více lze získat navíc Armello.

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

Google Chrome 62 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 62.0.3202.62 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 35 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 2
včera 11:00 | Zajímavý článek

Článek (en) na Mozilla.cz je věnován vykreslování stránek ve Firefoxu. V průběhu roku 2018 by se ve Firefoxu měl objevit WebRender, jenž by měl vykreslování stránek urychlit díky využití GPU.

Ladislav Hagara | Komentářů: 4
včera 08:22 | Bezpečnostní upozornění

NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost) informuje o zranitelnosti ROCA v procesu generování RSA klíčů, který se odehrává v softwarové knihovně implementované například v kryptografických čipových kartách, bezpečnostních tokenech a dalších hardwarových čipech vyrobených společností Infineon Technologies AG. Zranitelnost umožňuje praktický faktorizační útok, při kterém útočník dokáže vypočítat

… více »
Ladislav Hagara | Komentářů: 3
včera 01:23 | Zajímavý software

Příspěvek na blogu otevřené certifikační autority Let's Encrypt informuje o začlenění podpory protokolu ACME (Automatic Certificate Management Environment) přímo do webového serveru Apache. Klienty ACME lze nahradit novým modulem Apache mod_md. Na vývoj tohoto modulu bylo uvolněno 70 tisíc dolarů z programu Mozilla Open Source Support (MOSS). K rozchození HTTPS na Apache stačí nově přidat do konfiguračního souboru řádek s ManagedDomain. Minutový videonávod na YouTube [reddit].

Ladislav Hagara | Komentářů: 2
17.10. 14:15 | Komunita

Daniel Stenberg, autor nástroje curl, na svém blogu oznámil, že obdržel letošní Polhemovu cenu, kterou uděluje Švédská inženýrská asociace za „technologickou inovaci nebo důvtipné řešení technického problému“.

marbu | Komentářů: 10
17.10. 13:40 | Pozvánky

Cílem Social Good Hackathonu, který se uskuteční 21. a 22. října v Brně, je vymyslet a zrealizovat projekty, které pomůžou zlepšit svět kolem nás. Je to unikátní příležitost, jak představit nejrůznější sociální projekty a zrealizovat je, propojit aktivní lidi, zástupce a zástupkyně nevládních organizací a lidi z prostředí IT a designu. Hackathon pořádá brněnská neziskovka Nesehnutí.

… více »
Barbora | Komentářů: 1
17.10. 00:44 | Pozvánky

V sobotu 21. října 2017 se na půdě Elektrotechnické fakulty ČVUT v Praze uskuteční RT-Summit – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt.

… více »
Pavel Píša | Komentářů: 8
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (12%)
 (1%)
 (0%)
 (1%)
 (72%)
 (13%)
Celkem 69 hlasů
 Komentářů: 5, poslední dnes 07:28
    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: 304×
    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: 46 | 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: 67 | 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.