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 13:44 | Nová verze

    Byla vydána beta verze Linux Mintu 22.2 s kódovým jménem Zara. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze novou XApp aplikaci Fingwit pro autentizaci pomocí otisků prstů nebo vlastní fork knihovny libAdwaita s názvem libAdapta podporující grafická témata. Linux Mint 22.2 bude podporován do roku 2029.

    Ladislav Hagara | Komentářů: 0
    dnes 13:00 | IT novinky

    Provozovatel internetové encyklopedie Wikipedie prohrál v Británii soudní spor týkající se některých částí nového zákona o on-line bezpečnosti. Soud ale varoval britského regulátora Ofcom i odpovědné ministerstvo před zaváděním přílišných omezení. Legislativa zpřísňuje požadavky na on-line platformy, ale zároveň čelí kritice za možné omezování svobody slova. Společnost Wikimedia Foundation, která je zodpovědná za fungování

    … více »
    Ladislav Hagara | Komentářů: 1
    dnes 12:55 | Nová verze

    Byla vydána verze 2.0.0 nástroje pro synchronizaci dat mezi vícero počítači bez centrálního serveru Syncthing (Wikipedie). Přehled novinek na GitHubu.

    Ladislav Hagara | Komentářů: 2
    dnes 12:33 | IT novinky

    Americký prezident Donald Trump se v pondělí osobně setkal s generálním ředitelem firmy na výrobu čipů Intel Lip-Bu Tanem. Šéfa podniku označil za úspěšného, informují agentury. Ještě před týdnem ho přitom ostře kritizoval a požadoval jeho okamžitý odchod. Akcie Intelu v reakci na schůzku po oficiálním uzavření trhu zpevnily asi o tři procenta.

    Ladislav Hagara | Komentářů: 9
    včera 04:55 | Nová verze

    Byl vydán Debian GNU/Hurd 2025. Jedná se o port Debianu s jádrem Hurd místo obvyklého Linuxu.

    Ladislav Hagara | Komentářů: 5
    včera 02:44 | Komunita

    V sobotu 9. srpna uplynulo přesně 20 let od oznámení projektu openSUSE na konferenci LinuxWorld v San Franciscu. Pokuď máte archivní nebo nějakým způsobem zajímavé fotky s openSUSE, můžete se o ně s námi podělit.

    lkocman | Komentářů: 5
    9.8. 21:11 | Nová verze

    Byl vydán Debian 13 s kódovým názvem Trixie. Přehled novinek v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 8
    9.8. 15:55 | Zajímavý software

    WLED je open-source firmware pro ESP8266/ESP32, který umožňuje Wi-Fi ovládání adresovatelných LED pásků se stovkami efektů, synchronizací, audioreaktivním módem a Home-Assistant integrací. Je založen na Arduino frameworku.

    Indiánský lotr | Komentářů: 0
    8.8. 15:33 | Nová verze

    Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.8.

    Ladislav Hagara | Komentářů: 11
    8.8. 14:22 | IT novinky

    Herní studio Hangar 13 vydalo novou Mafii. Mafia: Domovina je zasazena do krutého sicilského podsvětí na začátku 20. století. Na ProtonDB je zatím bez záznamu.

    Ladislav Hagara | Komentářů: 1
    Kolik tabů máte standardně otevřeno ve web prohlížeči?
     (46%)
     (21%)
     (4%)
     (5%)
     (3%)
     (1%)
     (1%)
     (18%)
    Celkem 338 hlasů
     Komentářů: 23, poslední 4.8. 13:01
    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: 491×
    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.