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í
×
    dnes 12:33 | Zajímavý projekt

    MALUS je kontroverzní proprietarní nástroj, který svým zákazníkům umožňuje nechat AI, která dle tvrzení provozovatelů nikdy neviděla původní zdrojový kód, analyzovat dokumentaci, API a veřejná rozhraní jakéhokoliv open-source projektu a následně úplně od píky vygenerovat funkčně ekvivalentní software, ovšem pod libovolnou licencí.

    NUKE GAZA! 🎆 | Komentářů: 10
    dnes 03:55 | Bezpečnostní upozornění

    Příspěvek na blogu Ubuntu upozorňuje na několik zranitelností v rozšíření Linuxu o mandatorní řízení přístupu AppArmor. Společně jsou označovány jako CrackArmor. Objevila je společnost Qualys (technické detaily). Neprivilegovaný lokální uživatel se může stát rootem. Chyba existuje od roku 2017. Doporučuje se okamžitá aktualizace. Problém se týká Ubuntu, Debianu nebo SUSE. Red Hat nebo Fedora pro mandatorní řízení přístupu používají SELinux.

    Ladislav Hagara | Komentářů: 2
    včera 17:22 | Nová verze

    Byla vydána nová verze 19 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v changelogu.

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

    Bitwig Studio (Wikipedie) bylo vydáno ve verzi 6. Jedná se o proprietární multiplatformní (macOS, Windows, Linux) digitální pracovní stanici pro práci s audiem (DAW).

    Ladislav Hagara | Komentářů: 4
    včera 02:11 | Komunita

    Společnost Igalia představila novou linuxovou distribuci (framework) s názvem Moonforge. Jedná se o distribuci určenou pro vestavěné systémy. Vychází z projektů Yocto a OpenEmbedded.

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

    Google Chrome 146 byl prohlášen za stabilní. Nejnovější stabilní verze 146.0.7680.71 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 29 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.

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

    D7VK byl vydán ve verzi 1.5. Jedná se o fork DXVK implementující překlad volání Direct3D 3 (novinka), 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.

    Ladislav Hagara | Komentářů: 0
    11.3. 23:22 | Nová verze

    Bylo vydáno Eclipse IDE 2026-03 aneb Eclipse 4.39. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.

    Ladislav Hagara | Komentářů: 4
    11.3. 10:22 | Upozornění

    Ze systému Slavia pojišťovny uniklo přibližně 150 gigabajtů citlivých dat. Jedná se například o pojistné dokumenty, lékařské záznamy nebo přímou komunikaci s klienty. Za únik může chyba dodavatelské společnosti.

    Ladislav Hagara | Komentářů: 14
    11.3. 10:11 | IT novinky

    Sněmovna propustila do dalšího kola projednávání vládní návrh zákona o digitální ekonomice, který má přinést bezpečnější on-line prostředí. Reaguje na evropské nařízení DSA o digitálních službách a upravuje třeba pravidla pro on-line tržiště nebo sociální sítě a má i víc chránit děti.

    Ladislav Hagara | Komentářů: 36
    Které desktopové prostředí na Linuxu používáte?
     (16%)
     (7%)
     (0%)
     (11%)
     (29%)
     (2%)
     (5%)
     (2%)
     (13%)
     (25%)
    Celkem 1065 hlasů
     Komentářů: 26, poslední včera 08:56
    Rozcestník

    Dotaz: Proc ukladat uzivatele v LDAP a ne v SQL

    16.9.2012 18:29 hermelin | skóre: 21
    Proc ukladat uzivatele v LDAP a ne v SQL
    Přečteno: 531×
    Zdravim Muzete mi nekdo vysvetlit proc pouzivat LDAP a ne SQL na databazi uzivatelu? Ano openLDAP ma jednoduchou replikaci, ano LDAP je standart, ano LDAP muze byt kompatibilni s jinymi OS (AD, Novel apod.)

    Ale jeho slozitost i zadavani dat mi prijde krajne neprijemne. V MySQL udelam tabulku, kdykoliv si ji mohu upravit, kdykoliv si mohu menit select (s vysledkem jsem opravdu sam svym panem). V LDAP sem vazany spousty standarty a podminkami.

    Neberte prosim dotaz jako ze bych chtel vyprovokovat nejakou flame ale spis me opravdu zajima proc pouzit LDAP a ne SQL ktere je z meho pohledu mnohem flexibilnejsi.

    Diky moc za odopovedi

    Řešení dotazu:


    Odpovědi

    H0ax avatar 16.9.2012 18:58 H0ax | skóre: 36 | blog: Odnikud_nikam
    Rozbalit Rozbalit vše Re: Proc ukladat uzivatele v LDAP a ne v SQL
    jde o to, co je to za databázi userů, jaký je její účel
    uid=0(root) gid=0(root) skupiny=0(root)
    16.9.2012 19:11 hermelin | skóre: 21
    Rozbalit Rozbalit vše Re: Proc ukladat uzivatele v LDAP a ne v SQL
    Myslim klasiku - passwd, samba, ftp, pripadne autorizace na webovych rozhranich apod.
    Řešení 2× (mozog, H0ax)
    16.9.2012 20:10 Jooky (inactive) | skóre: 39 | blog: Jooky | Bratislava
    Rozbalit Rozbalit vše Re: Proc ukladat uzivatele v LDAP a ne v SQL
    Zasadny rozdiel medzi LDAP, NIS a podobnymi databazami v porovnani s SQL je v ich rychlosti. V pripade SQL databaz by nemal byt velky rozdiel v rychlosti vkladania dat a ich vyberania. Naproti tomu databazy LDAP, NIS, atd. su primarne optimalizovane na citanie a rychlosti zapisu sa nedava velka priorita. Uz z principu sa neda spravit databaza, ktora bude rychla na citanie a nedotkne sa to rychlosti zapisu.

    Velmi zalezi ako budu udaje pouzivane a ako sa bude k nim pristupovat. V pripade email servra a emailov vo virtualnych domenach bude stacit aj MySQL bez specialnej konfiguracie. Rychlost dorucovania emailov vacsinou nie je taka rychla, aby sa odrazila rychlost MySQL na ich dorucovani (samozrejme nemyslim nejaky obrovsky email server).

    V pripade pouzitia databazy ako uloziska Unix accountov je situacia uplne ina. Kazdy jeden prikaz ps, ls, find a iny pracujuci s Unix login udajmi vyprodukuje celkom dost dotazov. Hoci to nie je uplne viditelne, tak uz len taky "ps -ef" prikaz potrebuje prelozit UID/GID na meno. To iste "ls -l" v nejakom adresari a samozrejme kazda jedna sluzba/prikaz pracujuca s pravami na systeme. Samotnemu jadru toto mapovanie nevadi, kedze pracuje len s cislami, ale aby system pracoval "svizne" tak aj app musia pracovat rovnako rychlo.

    V tomto momente je presne na mieste spomenut LDAP. Tie obmedzenia a restrikcie su primarne na dosiahnutie rychlosti citania. Ked nastartujem nejaky file manager an pozriem sa napr do /tmp, tak ocakavam, ze a mi zobrazi obsah co najrychlejsie. Kedze suborovy system doda len UID:GID, tak je potrebne sa na kazdu jednu kombinaciu pozriet do zaznamov LDAP-u a to mozu byt tisicky dotazov, u ktorych ocakavame "okamzite" odpoved. Naproti tomu pridavanie uzivatelov, menenie hesla a inych parametrov je v porovnani s mnozstvom "citacich" dotazov zanedbatelne malo. Na zmenu hesla uzivatel pocka aj par sekund, ale na odpoved systemu pri "normalnej" praci nie.
    Řešení 2× (mozog, H0ax)
    16.9.2012 20:36 Marv-CZ | skóre: 21
    Rozbalit Rozbalit vše Re: Proc ukladat uzivatele v LDAP a ne v SQL
    LDAP je specializovaná databáze pro adresáře. Na rozdíl od SQL přímo kopíruje hierarchickou strukturu reality v podobě stromu. Dalším bonusem je způsob nastavení přístupových práv až na úroveň jednotlivých položek.

    S tím zadávání je to přesně naopak. Jistě na nejnižší úrovni je to komplikovanější. Ale pokud se budeme bavit o nástrojích v GUI, tak si hezky klikáš záznamy přímo do stromové struktury. I s tím omezením je to přesně naopak. Pokud máš nahraná správná schémata, máš k dispozici předdefinované typy položek pro vše potřebné. A na rozdíl od SQL nejsi omezen definicí tabulky. Můžeš si k záznamu přidávat položky podle libosti. Má třeba uživatel 10 e-mailových adres? Tak jich přidáš 10 a nemusí tě trápit, že ve struktuře tabulky SQL jsou pole jen na dvě.

    Samozřejmě jsou situace, kdy je lepší LDAP, jiné kdy je lepší SQL. Záleží, k čemu a jak to bude sloužit. Např. v rámci firmy bude lepší LDAP, který bude přirozeně odrážet třeba geografické umístění zaměstnanců a u každého si můžeš ukládat libovolně různé údaje. Naproti tomu pro velkého poskytovatele e-mailových schránek bude lepší SQL, protože zvládne rychleji velké objemy dat a formát záznamu je stejně dán striktně předem.
    16.9.2012 21:13 erg8
    Rozbalit Rozbalit vše Re: Proc ukladat uzivatele v LDAP a ne v SQL
    Podle mě ve většině případů vůbec nezálaží na rychlosti sql db vs ldap, ale na způsobu použití. Např. mailové účty mám v mysql, protože k nim ukládám i informace o využití kvóty (tj. časté čtení i zápis) a používám spoustu "nestandardních" atributů. Co se týče rychlosti, jde jen o to správně navrhnout databázi, ale i pro několik stovek tisíc uživatelů by to mělo být třeba na mail dostatečné. Co se týče rychlosti sql db při použití v NSS na linuxu, tak tam není rychlost také kritická - dá se používat cache. Zásadní otázka zůstává: chceš aby každý koncový počítač měl přístup ke všem uživatelům a jejich heslům? Pokud ne - zvol LDAP, pokud ano - můžeš použít nějakou relační db.
    16.9.2012 22:34 hermelin | skóre: 21
    Rozbalit Rozbalit vše Re: Proc ukladat uzivatele v LDAP a ne v SQL
    Diky vsem za jasne a vycerpavajici odpovedi. Jsem zase o neco chytrejsi :-)
    17.9.2012 00:34 Martin Matějek | skóre: 12 | blog: Flying_circus | Kladno
    Rozbalit Rozbalit vše Re: Proc ukladat uzivatele v LDAP a ne v SQL
    Ještě bych dodal jednu věc, kterou tu (myslím) nikdo nezmínil. Když chceš jednotné přihlašování do různých služeb, tak ti LDAP ušetří práci právě tím, že je to standard. Při použití SQL musíš každé aplikaci nastavit správné SQL dotazy.

    Například takhle:
    # please modify SQL queries for your database
    
    # add user
    add_user_sql = ""
    
    # remove user
    remove_user_sql = ""
    
    # update password
    update_passwd_sql = ""
    
    [...]
    # do something
    do_something_sql = ""
    
    LDAP je standardizovaný, takže pro různé operace (např. změny atributů) programu stačí akorát základní údaje, tj. jak ověřit uživatele, a operace s LDAPem provádí pomocí funkcí definovaných v nějakém API.
    Don't judge me by the friends I keep. No, no, no. Judge me by the enemies I have slain!

    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.