Portál AbcLinuxu, 24. května 2024 22:50
Používá-li se například ve firmě technologie LDAP, lze ji s výhodou využít i pro získávání údajů pro poštovní server. Bude to o něco složitější než v případě databáze MySQL, nicméně z globálního pohledu si tak lze výborně usnadnit práci.
LDAP (Lightweight Directory Access Protocol) je protokol pro přístup k údajům v adresáři – jak pro čtení a vyhledávání, tak pro přidávání, modifikaci a mazání. Protokol vznikl ze složitějšího protokolu DAP (X.511), který je součástí množiny X.500 vytvořené ITU-T a je pro běžné použití příliš složitý. Veškerá data jsou uložena ve stromové struktuře. Celý systém funguje na bázi klient-server, čili někde běží jeden nebo více serverů, k nimž se připojují klientské programy.
Strom LDAP je složen z objektů, každý objekt má své atributy. Například objekt třídy inetOrgPerson má atributy uid, cn, sn, gn, mail, userPassword (reprezentují identifikátor uživatele, jeho celé jméno, příjmení, křestní jméno, e-mailovou adresu a heslo) a mnohé další. Objekt je v rámci stromu jednoznačně identifikován pomocí rozlišovacího jména (Distinguished Name, DN), které vlastně popisuje cestu k objektu. Na každé úrovni se používá ještě relativní rozlišovací jméno (RDN), které zajišťuje unikátnost každého objektu. K rozlišování se používá vhodný atribut v rámci daného objektu (např. u uživatelů jejich přihlašovací jméno).
V rámci DN se používá tzv. sufix, což je část DN, která se při běžném používání adresáře nemění. Může se použít například doménový název (pokud je neměnný), případně nějaký jiný rozlišovač. Cílem je zajistit celosvětovou unikátnost každého rozlišovacího jména.
Pro přístup k záznamům lze nastavovat přístupová oprávnění. Typicky administrátor může měnit uložené údaje, všichni mají právo číst určité informace, někteří uživatelé mohou číst i další údaje apod.
O tom, jak budou třídy objektů vypadat, jaké atributy budou obsahovat, jakou budou mít kardinalitu atd., rozhoduje schéma. Typická instalace LDAP serveru obsahuje základní schémata definovaná v dokumentech RFC (například RFC 2256 definuje, jak vypadá schéma pro objekty uživatelů), může obsahovat i nějaká specifická. Pokud to jde, je dobré se držet základních schémat, usnadňuje to pozdější manipulaci, přechod na jiný software apod. – nevýhodou je, že to často znamená použití atributů k jiným účelům, než pro které vznikly, byť se tak třeba nepoužívají.
Informace z LDAP lze využít k řadě účelů. Asi nejjednodušší je obyčejné vyhledávání informací (například z poštovního klienta při hledání e-mailové adresy nějaké osoby). Dále lze podle LDAP autentizovat uživatele (záznamy mohou obsahovat hesla, certifikáty a další údaje), zjišťovat jejich parametry (např. domovský adresář, shell, periodu pro změnu hesla) a třeba také doručovat poštu. To bude také jedním ze dvou účelů využití technologie LDAP na poštovním serveru (tím druhým bude samozřejmě autentizace uživatelů). V adresáři LDAP může být i mnoho dat nesouvisejících s uživateli, třeba počítače, různé skupiny všeho možného, geografické informace, konfigurace programů apod.
Implementací LDAP serverů existuje celá řada. Ve světě GNU/Linuxu je asi nejznámější OpenLDAP, často se používá Microsoft Active Directory, dále tu máme například Apache Directory Server, OpenDS, Novell eDirectory, tinyldap, Mandriva Directory Server a mnoho dalších. Liší se především ve způsobu uložení dat, v konfiguraci, v použitých technologiích apod. K využití služeb LDAP není až tak důležité, o který konkrétní server se jedná, záleží hlavně na tom, jak je nastaven a s jakou strukturou dat pracuje. Struktura může být dána řadou požadavků, které je potřeba skloubit.
Poštovní server obvykle využívá LDAP v režimu čtení (dotazování), neprovádí žádné změny v datech, byť to obecně není úplně vyloučeno. Při doručování pošty je třeba ověřit, zda cílová adresa existuje a kam se má pošta doručovat. Při přístupu k poště (protokoly POP3 a IMAP) je důležité opět samozřejmě úložiště, ale také ověřování uživatelů. Uživatele je případně třeba ověřovat i při odesílání pošty.
Dotazování LDAP se principiálně neliší od dotazování jiných datových zdrojů, například databáze MySQL. Rozdíl je jen v drobnostech, které se ale samozřejmě mohou poměrně zásadně promítnout do konfigurace poštovního softwaru. Přestože má LDAP pověst mlhou zahalené a těžko zkrotitelné technologie, při dobrém pochopení základních principů není složité nastavit programy Postfix a Dovecot tak, aby správně komunikovaly se LDAP serverem.
Záleží samozřejmě na tom, zda se využívá již existující strom s informacemi, do kterého se případně jen doplní další potřebné údaje, anebo se začíná „na zelené louce“ a struktura LDAP informací bude přizpůsobena potřebám poštovního serveru.
Pokud se bude LDAP používat pro účely lokálních (systémových) uživatelů, je situace o něco jednodušší, protože lze celou problematiku vytěsnit z konfigurace poštovního serveru a ponechat ji jen v konfiguraci systému jako celku. Pak se pro ověřování uživatelů a zjišťování dalších údajů o nich (jak pro poštovní účely, tak i pro všechny ostatní) využije NSS a PAM (konkrétně v GNU/Linuxu knihovny libnss_ldap a pam_ldap). Proto se poštovní serverové programy nastaví stejně, jako kdyby se jednalo o obyčejnou uživatelskou databázi v souborech passwd, shadow atd. Jediné, co by se mohlo řešit přímo na úrovni poštovního serveru, by byly aliasy.
Jiná situace bude v případě uživatelů virtuálních, kde protokolem LDAP komunikují přímo Postfix a Dovecot. Oba programy pak musí být náležitě nastaveny, aby se správně připojovaly na LDAP server (případně více serverů; LDAP server bývá pro svou důležitost často přítomen v síti vícekrát, jeden jako hlavní, ostatní jako podřízené servery) a generovaly správné dotazy na potřebné údaje.
Jednoduchým případem je situace, kdy poštovní server obsluhuje pouze jedinou doménu. Znamená to, že se na domény vůbec není třeba dotazovat (ta jediná se uvede v konfiguraci) a struktura stromu LDAP by v podstatě vůbec nemusela informaci o doméně nést. Představme si například takovouto podobu adresáře LDAP:
Znamená to, že například uživatel s přihlašovacím jménem (a též názvem e-mailové schránky) franta bude mít DN v podobě uid=franta,dc=moje,dc=domena. Sufix bude v tomto případě dc=moje,dc=domena, protože to je část, která zůstane vždy stejná. Nyní jde o to, jak rozlišit, co je skutečný uživatel, co alias a jak rozlišit uživatele, kteří nemají e-mailovou schránku. Protože ale objekt inetOrgPerson, který je vhodné použít pro uložení dat o uživateli, obsahuje mnoho atributů, z nichž řada zůstává nevyužita, lze některý z těchto atributů použít pro uložení dalších údajů.
Vhodným kandidátem může být například preferredDeliveryMethod, což je původně atribut určující, jak přednostně doručovat uživateli informace. Protože tento atribut často zůstává nevyužitý, lze například určit, že jeho hodnota physical bude odpovídat e-mailové schránce, zatímco mhs bude alias. Ostatní hodnoty nebudou mít pro e-mailový server význam. Takto se při dotazech vyfiltrují relevantní hodnoty.
Protože u aliasu je potřeba ještě definovat cílovou adresu, bude nutné zvolit ještě další vhodný atribut (atribut mail není vhodný; pokud se totiž adresář LDAP používá i pro vyhledávání příjemce pošty v poštovních klientech, měl by obsahovat vždy adresu příslušející k objektu, ne cílové adresy použité k přesměrování). Volný bývá například atribut physicalDeliveryOfficeName, který je původně určen pro název kanceláře pro fyzické doručování (a tedy dost pravděpodobně není využit).
Čili už je jasné, jak bude vypadat struktura LDAP, ale teď je potřeba to přenést do konfiguračního souboru programu Postfix. Oproti dřívější konfiguraci (například té použité pro MySQL, která byla zase přejata z řešení pomocí souborů) se v souboru main.cf změní jen toto:
virtual_mailbox_domains = moje.domena virtual_mailbox_maps = ldap:/etc/postfix/ldap/vmailbox.cf virtual_alias_maps = ldap:/etc/postfix/ldap/virtual.cf
Rozdíl je to tedy jen kosmetický, o to více práce ale čeká přímo v souborech pro konfiguraci komunikace se serverem LDAP. První z nich (vmailbox.cf) je určen pro informace o schránkách a může mít například tuto podobu:
server_host = ldap.moje.domena search_base = dc=moje,dc=domena scope = one query_filter = (&(preferredDeliveryMethod=physical)(uid=%u)) result_attribute = uid result_format = moje.domena/%s/ bind = no
Parametr server_host říká, k jakému serveru se má Postfix připojit. Lze uvést i číslo portu, případně cestu k lokálnímu socketu. Pokud je v síti více LDAP serverů a Postfix by měl vědět o všech (při výpadku některého z nich funguje vyhledávání dál, protože se vyžijí ty ostatní), lze je uvést například takto:
server_host = ldap://ldap.moje.domena:10389
ldap://ldap2.moje.domena:10389
ldap://ldap3.moje.domena:10389
Příklad současně ukazuje i uvedení nestandardních portů (uvedený port je typický například pro Apache Directory Server; Active Directory zase používá port 3268). Dalším parametrem v konfiguraci je search_base. To je bázová cesta k prohledávání – vůči této cestě se budou hledat relativní rozlišovací jména. Parametr scope určuje rozsah prohledávání – v tomto případě to bude jedna úroveň (více není potřeba).
Jak bude vlastní vyhledávání fungovat, to už určuje parametr query_filter, do kterého lze podle potřeby vložit „procentové“ symboly, podobně jako při tvorbě SQL dotazů (viz minulý článek). Čili zde se atribut uid filtruje podle jména uživatele, což je přesně to, co zajistí kontrolu existence uživatele. Druhou část, tedy kontrolu na existenci schránky, zajišťuje test atributu preferredDeliveryMethod na hodnotu physical (všimněte si, že pro vyjádření logického výrazu se zde používá prefixová notace, tedy nejdřív operátor, pak jeho parametry).
Další dva atributy určují podobu výsledku vyhledávání. Pokud LDAP najde objekt splňující podmínky filtru, vrátí atribut uvedený v parametru result_attribute a učiní tak ve formátu definovaném parametrem result_format. Protože má být výsledkem relativní cesta k úložišti typu Maildir, bude se vrácená hodnota skládat z domény a nalezeného uživatelského identifikátoru. Poslední parametr, bind, vypíná otevření relace na serveru, protože u novějších verzí LDAP serverů je to zbytečné a jen by to spotřebovávalo výkon.
Pozor na to, že při uvedeném řešení musí být oprávnění na LDAP serveru nastavena tak, aby měl libovolný (i neověřený) uživatel přístup pro čtení uvedených atributů (resp. pro atribut preferredDeliveryMethod stačí i přístup k porovnání). Obvykle to není problém splnit, protože nejde o citlivé informace.
Podobným stylem se připraví i soubor virtual.cf s konfigurací pro aliasy. Rozdíl bude jen ve filtru (hledá se jiná hodnota preferredDeliveryMethod) a ve vraceném výsledku (bude to hodnota atributu physicalDeliveryOfficeName). Příklad už asi ani nepotřebuje komentář, protože by měl být dostatečně srozumitelný sám o sobě:
server_host = ldap.moje.domena search_base = dc=moje,dc=domena scope = one query_filter = (&(preferredDeliveryMethod=mhs)(uid=%u)) result_attribute = physicalDeliveryOfficeName result_format = %s bind = no
Nyní by měl být server Postfix připraven k doručování do schránek uživatelů uvedených v adresáři LDAP. Podobně jako v případě MySQL lze samozřejmě využít službu proxymap, která omezí počet spojení na LDAP server a může tak snížit jeho zátěž.
U programu Dovecot to bude o něco složitější. Kromě informací o schránkách se totiž bude pracovat i s hesly. Celý problém ověřování hesel lze řešit dvojí cestou. Buď se uživatel přímo ověří pomocí autentizace LDAP, anebo se heslo získá jako kterákoli jiná informace a pak se použije běžným způsobem (viz minulé díly). První metoda je o něco bezpečnější (heslo se nedostane mimo LDAP), je však pomalejší a omezuje škálu autentizačních mechanismů (jde o stejný problém jako třeba při autentizaci přes PAM). Následující odstavce budou založeny na metodě druhé, tedy založené na stejném principu, jako při využití MySQL v minulém dílu seriálu.
Heslo se v rámci LDAP objektu inetOrgPerson ukládá do atributu userPassword. Do tohoto atributu se uloží jak samotné heslo, tak i použité schéma a případně také „sůl“ (tedy dodatečná informace použitá pro zašifrování hesla). Protože v tomto případě bude – v zájmu použití co nejširší škály autentizačních mechanismů – heslo uloženo vždy v otevřeném tvaru (plain), sůl se samozřejmě nepoužije a ani nebude uvedeno schéma.
Protože se heslo bude v otevřeném tvaru také přenášet z LDAP serveru na poštovní server (pokud nejde o totožný stroj), je důležité data chránit proti případnému odposlechu. Lze tedy buď využít přímo TLS nebo SSL, anebo posílat data tunelem. Toto pravidlo samozřejmě platí obecně při posílání citlivých dat, nejen pro tento případ.
Konfigurace bude nápadně připomínat tu, která byla využita pro řešení s MySQL. Přestože UID a GID lze uvést v konfiguraci pro LDAP (podobně, jako tomu bylo v minulých dvou článcích, tedy u souborového řešení a MySQL), jde o neměnné hodnoty a mohou být tedy nadefinovány globálně – netýká se to samozřejmě jen konfigurace pro LDAP, lze to použít i v jiných případech. Nastavení patří na nejvyšší úroveň konfigurace, tedy například za last_valid_gid.
mail_uid = 100 mail_gid = 100
V sekci auth default se změní jen toto (sekce passdb a userdb budou nahrazeny uvedeným fragmentem):
passdb ldap {
args = /etc/dovecot/ldap.conf
}
userdb ldap {
args = /etc/dovecot/ldap.conf
}
Vlastní konfigurace bude pak obsažena v souboru ldap.conf. Tady je příklad takového souboru (pozor na přístupová práva – heslo pro LDAP je citlivou informací!):
hosts = ldap.moje.domena tls = yes dn = uid=dovecot,ou=users dnpass = nejakeheslo scope = onelevel base = dc=moje,dc=domena user_attrs = =home=/var/mail/virtual/%d/%n user_filter = (&(preferredDeliveryMethod=physical)(uid=%n)) default_pass_scheme = PLAIN pass_attrs = uid=user=%$@moje.domena, userPassword=password pass_filter = (&(preferredDeliveryMethod=physical)(uid=%n))
Vypadá to trochu divoce, možná složitěji než u Postfixu, ale je to v podstatě jednoduché. V parametru hosts je seznam LDAP serverů (zde jeden), případně i s čísly portů. Místo něj lze použít parametr uris, kdy se místo obyčejných adres používají plné URI, tedy i včetně schématu. Jednotlivé servery se vždy oddělují mezerou. Parametr tls zapíná TLS komunikaci (server ji samozřejmě musí podporovat; lze použít také SSL přes URI začínající ldaps://, opět je třeba podpora serveru anebo použití něčeho jako stunnel).
Parametry dn a dnpass slouží k autentizaci LDAP klienta, protože jde o přístup k citlivým informacím (heslům). Uvedený příklad předpokládá, že jde o uživatele uid=dovecot,ou=users, čili že uživatelé jsou uvedeni pod objektem třídy organizationalUnit s RDN users. Konkrétní nastavení záleží samozřejmě na tom, jak vypadá struktura konkrétního stromu – klidně by mohlo jít i o uživatele pod dc=moje,dc=domena, kde jsou umístěny uživatelé pro schránky, nic tomu nebrání.
Pro vyšší výkon by bylo možné udělat dvě věci – buď oddělit dotazování na uživatele do samostatného souboru (kde by se nemuselo používat šifrování ani autentizace), anebo pro dotazování na uživatele použít přímo dotaz pro hesla, případně statickou definici se šablonou (protože existence uživatele se ověří dotazem na heslo). Tím se ovšem částečně „pohřbí“ flexibilita a pro využití například doručovacího agenta nebo některých pluginů by se tato forma musela opustit. Informace o těchto „zlepšovácích“ se souhrnně objeví v některém z pozdějších dílů seriálu.
Parametr scope říká, kde všude se budou objekty hledat. Zde je to onelevel, tedy jediná úroveň stromu. base má stejný význam jako search_base u Postfixu, tedy bázová cesta k prohledávání.
Následující parametry už souvisejí přímo s dotazy. user_attrs mapuje (pro dotazování na uživatelské schránky) atributy LDAP na atributy programu Dovecot, ovšem v tomto případě se ve skutečnosti nic nemapuje. Dotaz je pouze testem na existenci uživatele, nejsou potřeba žádné hodnoty z databáze. Proto se hodnota sestavuje napevno, což říká onen tvar „=proměnná“, protože obecné mapování má podobu proměnnáLDAP=proměnnáDovecot. Zde je to ovšem jinak, proměnná LDAP chybí, zato ale následuje definice hodnoty pomocí šablony, podobně jako třeba u mail_location v hlavní konfiguraci.
Teď je na místě udělat drobnou vsuvku, která se měla objevit již v předminulém dílu seriálu. V tomto příkladě, stejně jako ve všech dosud uváděných (s virtuálními uživateli), se úložiště pošty a domovský adresář shodovaly. Bylo to pro jednoduchost, aby nevznikala další adresářová úroveň nebo jiné složité řešení, a tady to nijak nevadí. Ovšem pokud se budou využívat některé pluginy, které si do domovského adresáře ukládají informace (to bude například Sieve při využití doručovacího agenta; ale nerad bych teď předbíhal), je lepší toto oddělit a udělat například v „domovském adresáři“ virtuálního uživatele ještě podadresář pro poštu, aby v souborech a adresářích nevznikal zmatek.
Parametr user_filter slouží k vyhledávání (filtrování) záznamů. Je to prakticky stejné jako u Postfixu. Úplně stejnou podobu má také parametr pass_filter. Zajímavější je však pass_attrs, a to ve své první části (druhá je prosté mapování atributů). Formát uid=user=%$@moje.domena říká, že se atribut uid (identifikace uživatele v LDAP objektu inetOrgPerson) namapuje do Dovecot atributu user tak, že jeho hodnota nahradí symbol %$. Je to potřeba, protože Dovecot zde pracuje s uživatelskými jmény v podobě celé e-mailové adresy, přitom v adresáři LDAP se hledají jen samotná jména. Pokud by se přiřazení provedlo přímo, Dovecot by získal nesprávnou informaci, chyběl by zavináč a doména.
Tím je Dovecot nakonfigurován a měl by fungovat standardním způsobem pro oba podporované protokoly. Samozřejmě se stejná autentizace využije i pro účely programu Postfix, tedy při odesílání pošty směrem ven z počítačů mimo mynetworks – ale to není nic nového, nijak se to neliší od chování v předchozích dílech.
Většina nasazení technologie LDAP se odehrává uvnitř firem a jiných organizací, tedy obvykle na jediné doméně. Někdy je ale potřeba (i v těchto případech, ale třeba i pro využití LDAP u webhostingu, byť to není až tak obvyklé) obsluhovat domén více. Strom LDAP může být zhruba stejný, je však záhodno přidat jednu úroveň (zde ou=domains), aby byla prohledávaná část stromu samostatná a „netloukla“ se s dalšími informacemi uloženými ve stromě.
První věc, kterou je potřeba řešit, jsou dotazy na domény. Lze mít samozřejmě domény nadefinovány jinde, ale pokud už se LDAP používá na jednu věc, bylo by nesmyslné udržovat ještě nějaká data jinde. Potíž je ale v tom (a podobné to bude i v dalších případech), že nelze nijak jednoduše nadefinovat prohledávání po jednotlivých složkách celého doménového jména (po jednotlivých úrovních, od TLD až po koncovou doménu).
Proto nezbývá, než to udělat méně efektivně a do nějakého atributu každého z objektů „koncových“ domén (tedy těch, které poštovní server obsluhuje) vložit celý název domény. Tedy pro doménu moje.domena bude objekt s dc=moje,dc=domena obsahovat v nějakém atributu (lze zvolit opět například physicalDeliveryOfficeName) celý název, tedy moje.domena. V souboru main.cf se potom změní jeden řádek:
virtual_mailbox_domains = ldap:/etc/postfix/ldap/vdomains.cf
Soubor vdomains.cf je určen pro dotazování na domény a bude mít tuto podobu:
server_host = ldap.moje.domena search_base = ou=domains scope = sub query_filter = (&(physicalDeliveryOfficeName=%s)(objectClass=domain)) result_attribute = physicalDeliveryOfficeName result_format = %s bind = no
Oproti předchozí situaci se změnila vyhledávací báze (search_base), která zde odpovídá kořeni stromu domén. Prohledávat se bude podstrom (scope = sub; je to výchozí hodnota, ani by tu nemusela být uvedena). Filtr nyní testuje na název domény onen atribut physicalDeliveryOfficeName, ale současně ještě filtruje na typ objektu domain, aby šlo skutečně o informace o doménách. Formát výsledku je prosté přenesení textu.
Podobným způsobem je třeba upravit také vmailboxes.cf. Pro správnou funkci je třeba vyplnit atribut mail, podle kterého se nyní bude hledat.
server_host = ldap.moje.domena search_base = ou=domains scope = sub query_filter = (&(preferredDeliveryMethod=physical)(mail=%s)(objectClass=inetOrgPerson)) result_attribute = mail result_format = %d/%u/ bind = no
Jak si můžete všimnout, hledá se nyní právě podle atributu mail (celé e-mailové adresy) a objekty se filtrují podle třídy inetOrgPerson. Vrácený atribut se přeformátuje tak, aby tvořil správnou relativní cestu k úložišti. Soubor virtual.cf pro aliasy pak bude mít tuto podobu:
server_host = ldap.moje.domena search_base = ou=domains scope = sub query_filter = (&(preferredDeliveryMethod=mhs)(mail=%s)(objectClass=inetOrgPerson)) result_attribute = physicalDeliveryOfficeName result_format = %s bind = no
Zde je odchylka od původní podoby ještě menší. Změnila se vyhledávací báze, rozsah prohledávání a přibyla filtrace podle třídy objektů.
Kdo pochopil jádro problému u konfigurace Postfixu, jistě nyní dokáže správně nakonfigurovat i Dovecot. Rozdíl bude prakticky jen v syntaxi konfiguračního souboru. Tady je jedna z možných podob souboru ldap.conf (hlavní konfigurační soubor dovecot.conf se samozřejmě nemění):
hosts = ldap.moje.domena tls = yes dn = uid=dovecot,ou=users dnpass = nejakeheslo scope = subtree base = ou=domains user_attrs = =home=/var/mail/virtual/%d/%n user_filter = (&(preferredDeliveryMethod=physical)(mail=%u)(objectClass=inetOrgPerson)) default_pass_scheme = PLAIN pass_attrs = mail=user, userPassword=password pass_filter = (&(preferredDeliveryMethod=physical)(mail=%u)(objectClass=inetOrgPerson))
Asi to ani nepotřebuje komentář. Soubor je dokonce jednodušší než ten pro jedinou doménu. Vyžaduje (stejně jako konfigurace pro Postfix) ale samozřejmě vyplněný atribut mail u každého uživatele, především je ale operačně dost náročný. Jak tomu čelit? Jednou z možností je rezignovat na plně stromovou strukturu a umístit všechny domény do jedné úrovně. Případně lze strukturu zachovat a samostatně do ploché struktury umístit jejich aliasy (to ale znamená, že se tyto aliasy musí také spravovat). Našla by se asi i další řešení, která ale přesahují rámec tohoto článku a lépe by se k nim vyjádřili znalci protokolu LDAP.
Toto byl poslední článek v řadě těch, které se věnovaly uložení informací o poštovních schránkách, uživatelích, aliasech atd. (sice není nadobro konec, některé záležitosti se znovu objeví v pozdějších článcích, ale prozatím je to všechno). Nyní přijde čas pro neméně důležité věci, mezi které patří ochrana proti nevyžádané poště čili spamu. Postfix sám o sobě i s pomocí dalších nástrojů má mnoho možností, jak se spamem úspěšně bojovat, proto by bylo chybou tyto nástroje náležitě nevyužít.
11.12.2009 07:00
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Jen bych se chtel zeptat, zdali bude take uvedena konfigurace dovecotu jako LDA ( treba se Sieve ci procmail pro presun SPAMU do adresare ci automaticke promazavani SPAM adresar)?Samozřejmě bude.
Pak taky, zda-li byste mohl dokoncit tu vsuvku o podadresarich kvuli pluginum. Co vsechno se zmeni (user_attrs?).Teď jen ve stručnosti. Jde o to, že pokud se například využívá Sieve a nad domovským adresářem pracuje ManageSieve (ať už jako součást Dovecotu nebo jako samostatný program, např. PySieved), budou se v klientovi zobrazovat i soubory, které nemají. A obráceně, Dovecot bude adresář vytvořený pro účely Sieve (kam se budou ukládat Sieve skripty) považovat za poštovní složku (pokud bude název začínat tečkou, jak je obvyklé), čili ji bude klientům nabízet společně s jinými složkami. To není stav, o který by člověk zrovna stál. Ale znovu říkám, ve všech příkladech dosud používaných v seriálu využití "domovského adresáře virtuálního uživatele" nijak nevadilo, proto jsem také nevytvářel další adresářovou úroveň. Při použití se samozřejmě user_attrs nezmění, protože tam je právě domovský adresář, který zůstane stejný. Změní se naopak mail_location (například na maildir:/var/mail/virtual/%d/%n/Maildir, pokud bude pošta v adresáři Maildir pod domovským adresářem). U Postfixu by se změnil result_format (v tomto případě na %d/%u/Maildir/).
12.12.2009 15:15
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
12.12.2009 15:43
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
), umím z něj číst, ale vůbec nechápu princip jeho činnosti (nenašel jsem ani návod pro blbé, takže soudím, že to bude triviální a někdy prostě nastane ahááááá efekt) ani jej neumím nainstalovat. Přesto jsem mnoho let spokojeným adminem.
12.12.2009 16:25
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
vůbec nechápu princip jeho činnostiCo na tom nechápeš? Základní princip je naprosto triviální. Je to prostě strom objektů a každý objekt může mít atributy (jaké přesně a které jsou povinné atd., to záleží na schématu). Ten strom může vycházet třeba z hierarchie DNS nebo být úplně jiný, podle potřeby. Představ si to třeba jako XML strom nebo něco takového (třeba registry ve Windows
), je to jedno. Jak si to server vnitřně reprezentuje (třeba klidně jako nějaký XML soubor, databázi nebo jako objekty v C++, které se pak binárně zapisují na disk), to už je čistě implementační záležitost.
K jednotlivým objektům a atributům lze pak nastavovat práva.
ani jej neumím nainstalovatInstalace je taktéž triviální. Netriviální může být u některých implementací počáteční konfigurace (např. u OpenLDAP). Ale jsou implementace, kde je to také jednoduché (třeba Apache Directory Server; pro něj existuje také klikátko Apache Directory Studio, kterým lze jak pracovat se stromem, tak i konfigurovat server).
12.12.2009 18:37
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
, resp. napadají mě technologie, které zvládnou totéž co si myslím, že má být LDAP (nasazení LDAPu tak jak jej máme u nás by šlo snadno přepsat do SQL).
ad 2) Zde to bude zřejmě tím OpenLDAPem.
Není to technologie, kterou bych musel znát (nemám to kde využít), takže to nechám v klidu jiným. Pokud o tom někdo napíše srozumitelný článek včetně příkladů nasazení (od nejjednodušších, řekněme pro ověřování uživatelů na jedné mašině (místo /etc/passwd)), rád si jej přečtu. A jistě nebudu sám.
12.12.2009 22:04
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Pokud je to ovšem celé, tak pak nechápu smysl samotného LDAPu , resp. napadají mě technologie, které zvládnou totéž co si myslím, že má být LDAP (nasazení LDAPu tak jak jej máme u nás by šlo snadno přepsat do SQL).LDAP je především komunikační protokol. O to jde v první řadě. A protože tento protokol má poměrně širokou podporu, lze ho využívat v mnoha programech. Lze měnit klientský i serverový software podle potřeby, aniž by se musel měnit zbytek celku.
13.12.2009 21:52
otula | skóre: 45
| blog: otakar
| Adamov
Pokud o tom někdo napíše srozumitelný článek včetně příkladů nasazení (od nejjednodušších, řekněme pro ověřování uživatelů na jedné mašině (místo /etc/passwd)), rád si jej přečtu. A jistě nebudu sám.Jo, k tomu článku pro blbé se také přidávám
S (open)LDAP jsem se dostal do fáze, kdy běží (jakože se jen samoúčelně spustí bez použitelných dat), ale nejsem tam schopen nic rozumného nasáčkovat tak, abych to mohl jakkoliv použít. Většina návodů se spoléhá na nějaké skripty, které udělají většinu práce (ale tyto skripty v Archu nejsou). Chtěl jsem začít zdrojem adres pro mailové klienty, ale nějak jsem se neprokousal k výsledku.
Pro Lukáše: kdyby se ti chtělo napsat knihu o LDAP, určitě bys měl jistého minimálně jednoho kupce
Pro Luka - pokud budeš psát knihu, dobře si to rozmysli, moc čtenářů mít nebude. LDAP je hodně komplexní a vyžaduje dost znalostí souvisejících věcí. O Tebe starost nemám, evidentně o tom hodně víš. Problém je se čtenáři, protože je to může odradit. Příklady použití jsou docela komplexní, leckdy zasahují spíš do podnikové sféry a vyžadují dost času a experimentů.
14.12.2009 00:40
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Pro Luka - pokud budeš psát knihu, dobře si to rozmysli, moc čtenářů mít nebude.Knihu psát nebudu - viz níže
14.12.2009 11:43
otula | skóre: 45
| blog: otakar
| Adamov
14.12.2009 00:40
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Pro Lukáše: kdyby se ti chtělo napsat knihu o LDAP, určitě bys měl jistého minimálně jednoho kupceZaprvé nejsem odborník na LDAP (proto píšu v článku, že "lépe se vyjádří znalec LDAP" - a to já bohužel nejsem), zadruhé teď dokončuji zapracování odborné korektury do knihy na úplně jiné téma, takže o psaní knih zase nějakou dobu nebudu chtít ani slyšet
14.12.2009 11:47
otula | skóre: 45
| blog: otakar
| Adamov
Zaprvé nejsem odborník na LDAP (proto píšu v článku, že "lépe se vyjádří znalec LDAP" - a to já bohužel nejsem), zadruhé teď dokončuji zapracování odborné korektury do knihy na úplně jiné téma, takže o psaní knih zase nějakou dobu nebudu chtít ani slyšetTo je škoda. Píšeš pěkně "čitelně" :)
13.12.2009 00:55
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Čemu by tak hrozně vadilo to, kdybychom si vytvořili vlastní schema ?Nevadilo by. Tedy aspoň v tomto případě (u některých programů by vadilo, protože ty napevno počítají s objekty určitých tříd). Akorát že by se muselo vymýšlet a muselo by se nainstalovat. Pokud se použije hotové schéma, toto celé odpadá.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.