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 20:33 | Komunita

MojeFedora.cz informuje (en), že Fedora 27 přináší snadný přístup k Red Hat Enteprise Linuxu. Virtualizační nástroj Boxy nyní umožňuje jednoduše stáhnout a nainstalovat Red Hat Enterprise Linux, který je pro vývojáře zdarma. Vytvořit lze neomezené množství virtuálních mašin s RHEL.

Ladislav Hagara | Komentářů: 1
dnes 19:00 | Komunita

Konsorcium Linux Foundation oficiálně představilo licence pro komunitní otevřená data Community Data License Agreement (CDLA). První licence je copyleftová CDLA-Sharing a druhá permisivní CDLA-Permissive. Odpovědi na často kladené otázky ve FAQ.

Ladislav Hagara | Komentářů: 0
dnes 13:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. pražský sraz, který proběhne ve čtvrtek 26. října od 18:00 hodin v karlínském Pivovarském klubu. Najdete jej kousek od metra Florenc na adrese Křižíkova 17, Praha 8. 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
dnes 06:00 | Zajímavý software

Byla vydána verze 0.56 open source platformy Home Assistant (GitHub) pro monitorování a řízení inteligentní domácnosti naprogramované v programovacím jazyce Python verze 3 a bežící také například na Raspberry Pi. Pro vyzkoušení je k dispozici demo [reddit].

Ladislav Hagara | Komentářů: 0
včera 16:55 | Nová verze

Byla vydána verze 1.0 klienta F-Droid určeného pro instalaci aplikací do Androidu ze softwarového repozitáře F-Droid (Wikipedie), alternativy k Google Play, nabízející pouze svobodný a otevřený software. Podrobnosti v přehledu změn [Hacker News].

Ladislav Hagara | Komentářů: 6
včera 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 10
21.10. 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
21.10. 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
20.10. 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
20.10. 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (0%)
 (0%)
 (1%)
 (75%)
 (13%)
Celkem 228 hlasů
 Komentářů: 8, poslední včera 23:02
    Rozcestník

    Stavíme poštovní server – 6 (virtuální uživatelé)

    25. 11. 2009 | Lukáš Jelínek | Sítě | 15416×

    U dedikovaných poštovních serverů nevyužívají uživatelé obvykle nic jiného než právě poštovní služby. Existuje samozřejmě možnost skloubit systémové (unixové) uživatele se schránkami v různých doménách, nicméně by bylo zbytečné, aby byly pro tyto účely v systému normální uživatelské účty. Proto se využívají tzv. virtuální uživatelé. Existuje řada způsobů, jak s nimi v poštovním prostředí pracovat.

    Obsah

    O virtuálních uživatelích

    link

    Základní informace o smyslu a vlastnostech virtuálních uživatelů jste se mohli dočíst už v minulém dílu. Důležité je, že virtuální uživatelé existují nezávisle na těch systémových, mohou být vázáni k různým doménám (slouží-li server například v rámci hostingu), lze využívat řadu metod přístupu k datům o nich atd. To jsou všechno výhody, které výrazně usnadňují využití pro poštovní služby a někdy jsou přímo podmínkou fungování v dané situaci.

    Jaké informace jsou tedy potřeba pro úspěšné fungování virtuálních uživatelů? Není toho mnoho:

    • pro které domény se místně doručuje
    • odkud brát informace o uživatelích a heslech
    • jak uživatele ověřovat

    U domén jde o to, že server přijme zvenčí zprávy jen pro domény, do kterých doručuje. Informace o těchto doménách musí nějakým způsobem získávat. Podobně potřebuje mít k dispozici i informace o uživatelích a heslech, a rovněž vědět, jakým způsobem uživatele ověřovat (autentizační metody, schémata hesel, ověřovací prostředek).

    Konfigurace doručování

    link

    Jak tohle celé uchopit? Jako první je na řadě rozhodnutí, jak budou vůbec informace uloženy. To záleží na současné situaci (jaké technologie se např. ve firmě používají), k čemu bude server sloužit, jak často se bude něco měnit, zda bude potřeba měnit hesla apod. Nejjednodušší je uložení dat v obyčejných souborech, tedy v rámci konfigurace a dalších souborů.

    Základní konfigurace

    link

    O doručování došlých zpráv se stará Postfix, proto potřebuje mít k dispozici informace o tom, do kterých domén má doručovat a kde se nachází úložiště toho kterého uživatele. Protože jde o virtuální uživatele, lze s klidem zapomenout na nějaké domovské adresáře a prostě si říct, že bude úložiště umístěno například v adresáři /var/mail/virtual.

    V tomto adresáři budou adresáře jednotlivých domén a pod nimi adresáře uživatelů (v nich pak normální úložiště Maildir, případně mbox). Proto uživatel s adresou franta@moje.domena bude mít schránku na /var/mail/virtual/moje.domena/franta. Je to prosté. V konfiguraci to pak bude vypadat nějak takhle:

    virtual_mailbox_domains = moje.domena jina.domena dalsi.domena
    virtual_mailbox_base = /var/mail/virtual
    virtual_mailbox_maps = hash:/etc/postfix/vmailbox
    virtual_alias_maps = hash:/etc/postfix/virtual
    virtual_minimum_uid = 100
    virtual_uid_maps = static:100
    virtual_gid_maps = static:100
    

    Parametr virtual_mailbox_domains přímo definuje, pro které domény bude Postfix doručovat. V seznamu nesmí být doména uvedená v mydestination (parametr mydestination zde lze v konfiguraci klidně vynechat, použije se výchozí hodnota). virtual_mailbox_base je ono místo, pod kterým bude úložiště schránek. Další dva parametry říkají, kde se nachází tabulka schránek, resp. aliasů (viz dále).

    Seznam domén lze místo virtual_mailbox_domains samozřejmě definovat i někde venku (třeba v hešové tabulce, takže se pak cesta k ní uvede zde), ovšem obvykle to v takto jednoduchém případě není potřeba. Případně lze parametr dokonce vynechat, použije se pak automaticky to, co je obsaženo ve virtual_mailbox_maps – není to ale dobrý nápad, protože někdy mohou být v doméně definovány pouze aliasy a žádné schránky, pak by samozřejmě doručování nefungovalo.

    Zbývající tři parametry se týkají uživatele a skupiny. Služba virtual, která se stará o doručování virtuálním uživatelům, si totiž zjišťuje, pod jakým uživatelem a skupinou provede doručení do konkrétní schránky. Lze doručovat pod různými uživateli, nicméně v tomto případě bude uživatel jediný, konkrétně s UID=100 (může to být třeba uživatel nazvaný vmail; nesmí být totožný s uživatelem, pod nímž běží Postfix, tedy typicky uživatelem postfix). Totéž se týká i skupiny. Parametr virtual_minimum_uid říká, jakou minimální hodnotu musí zjištěný identifikátor mít (zde má pouze formální význam, protože je hodnota nadefinována natvrdo).

    Pozor na to, aby měl adresář úložiště správně nastavena práva. Vlastník a skupina by měly být nastaveny na správné hodnoty (podle konfigurace uvedené výše), jakýkoli přístup pro jiné uživatele by měl být zakázán (tj. maska adresáře nejlépe 0700, případně 0750).

    Schránky a aliasy

    link

    Dále je potřeba vytvořit zmíněný seznam e-mailových schránek, tedy soubor /etc/postfix/vmailbox. Ten bude obsahovat vždy dvojici adresy a cesty, kde se schránka nachází. Tady je příklad takového souboru (na počtu mezer nebo tabulátorů oddělujících hodnoty dvojice nezáleží):

    franta@moje.domena     moje.domena/franta/
    tereza@moje.domena     moje.domena/tereza/
    postmaster@moje.domena moje.domena/postmaster/
    
    petr@jina.domena       jina.domena/petr/
    

    Z příkladu je snad všechno zřejmé. Důležité je, aby cesta končila lomítkem, protože to signalizuje, že jde o schránku typu Maildir. Pokud by se nepoužilo, Postfix by to chápal jako mbox. Cesty jsou relativní vzhledem k virtual_mailbox_base, tedy pod /var/mail/virtual.

    Dalším souborem bude /etc/postfix/virtual, tedy tabulka aliasů. Vypadá podobně jako tabulka schránek, jen místo cesty je tam cílová adresa:

    abuse@moje.domena         postmaster@moje.domena
    root@moje.domena          franta@moje.domena
    
    postmaster@jina.domena    postmaster@moje.domena
    abuse@jina.domena         postmaster@jina.domena
    
    postmaster@dalsi.domena   postmaster@moje.domena
    abuse@dalsi.domena        postmaster@dalsi.domena
    

    Všimněte si dvou věcí. Především toho, že jeden alias může směřovat na jiný alias – tedy zde například abuse@jina.domena směřuje na postmaster@jina.domena, což je alias schránky postmaster@moje.domena. Takhle to jde řetězit skoro nekonečně (v praxi do limitu nastaveného parametrem virtual_alias_recursion_limit, v současné době je výchozí hodnota 1000). Druhá důležitá věc je, že je zde definován alias pro uživatele root (využívají se virtuální aliasy, nikoli lokální).

    Adresa s uživatelem postmaster musí být definována v každé doméně – je to striktní požadavek RFC 2821 (stejně tak i draftu RFC 5321) a navíc standardní cesta, jak kontaktovat správce serveru. Nezáleží na tom, zda je adresa implementována jako schránka nebo alias k jiné schránce, ale zprávy by měl někdo pravidelně číst. Adresa postmaster musí být funkční i jako lokální (to se zajistí tak, že je správně nakonfigurována schránka postmaster pro doménu definovanou parametrem myorigin – podobně se postupuje i pro uživatele root). RFC 2142 definuje také adresu abuse, určenou k oznamování zneužití služby – měla by být definována pro nejvyšší doménu využívanou určitým subjektem (v praxi typicky doména 2. úrovně), ale v praxi se adresa skutečně využívá zřídka. V různých RFC najdete i další speciální adresy spjaté s jinými službami.

    Netřeba dodávat, že oba textové soubory je třeba převést na hešové tabulky příkazem postmap. Celý soubor konfigurace pro Postfix tedy nyní vypadá takto (včetně omezení přístupu v podobě z minulého dílu):

    myhostname = postak.moje.domena
    myorigin = $mydomain
    
    biff = no
    delay_warning_time = 4h
    
    mynetworks = 127.0.0.0/8
    
    smtpd_client_restrictions =
      permit_mynetworks,
      check_sender_access hash:/etc/postfix/access,
      permit
    
    smtpd_sender_restrictions =
      permit_mynetworks,
      reject_non_fqdn_sender,
      reject_unknown_sender_domain,
      check_sender_access hash:/etc/postfix/access,
      permit
    
    smtpd_recipient_restrictions =
      permit_mynetworks,
      reject_non_fqdn_recipient,
      reject_unknown_recipient_domain,
      check_recipient_access hash:/etc/postfix/access,
      reject_unauth_destination,
      permit
    
    smtpd_error_sleep_time = 30
    smtpd_soft_error_limit = 10
    smtpd_hard_error_limit = 20
    
    smtpd_helo_required = yes
    disable_vrfy_command = yes
    
    virtual_mailbox_domains = moje.domena jina.domena dalsi.domena
    virtual_mailbox_base = /var/mail/virtual
    virtual_mailbox_maps = hash:/etc/postfix/vmailbox
    virtual_alias_maps = hash:/etc/postfix/virtual
    virtual_minimum_uid = 100
    virtual_uid_maps = static:100
    virtual_gid_maps = static:100
    

    Konfigurace přístupu k poště

    link

    Nyní je tedy situace taková, že Postfix správně doručuje do schránek, nelze se k nim však zatím dostat. Je proto potřeba nakonfigurovat také program Dovecot. I ten bude nyní plně založen na informacích uložených v souborech, je to ale o něco složitější – je totiž potřeba pracovat také s hesly.

    Hesla a autentizace

    link

    Při práce s hesly (resp. s autentizací obecně) se používají dva důležité termíny: autentizační mechanismusschéma hesel. Oba spolu souvisejí. Autentizační mechanismus je vlastně protokol, podle něhož se provádí ověření uživatele, kdežto schéma hesel je způsob, jakým jsou hesla uložena. Jde o to, že na tom, jaké schéma se pro uložení hesel použije, závisí množina použitelných autentizačních mechanismů. Základním pravidlem je, že pokud je heslo uloženo v otevřeném tvaru (schéma PLAIN), lze ho využít pro všechny mechanismy. Naopak pro mechanismus PLAIN (heslo se posílá v otevřeném tvaru) lze využít libovolné schéma uložení hesel. Ostatní případy jsou specifické a většina vzájemných kombinací není z principu možná.

    minulém dílu seriálu si můžete všimnout, že v situaci, kdy lze heslo pouze ověřit (tedy ne přímo získat), jsou autentizační možnosti omezené a lze použít pouze metody PLAINLOGIN, tedy ty, kdy se posílá heslo v otevřeném tvaru. To je však v kombinaci s nešifrovaným přenosem nebezpečné, proto je výhodnější mít hesla raději uložena v otevřeném tvaru a pro autentizaci využívat různé bezpečnější mechanismy (s možností nabídnout jich více najednou).

    Nyní už je tedy jasné, že budou hesla uložena tak, jak jsou. Proto je potřeba zvlášť pečlivě nastavit přístupová práva k souboru s hesly (viz dále). Soubor může být umístěn například v /etc/dovecot/passwd, proto se v konfiguračním souboru dovecot.conf nastaví toto:

    passdb passwd-file {
      args = scheme=plain username_format=%u /etc/dovecot/passwd
    }
    

    Tento fragment říká, že se jako databáze hesel použije soubor typu passwd-file (soubor „jako passwd“), schéma uložení je PLAIN, uživatelská jména jsou uvedena včetně domény (%u) a soubor je umístěn na dané cestě. Podobnou sekci je třeba přidat i pro databázi uživatelů:

    userdb passwd-file {
      args = username_format=%u /etc/dovecot/passwd
    }
    

    K souboru s hesly smí mít přístup jen uživatel, pod nímž poběží program provádějící autentizaci. Tímto uživatelem nesmí být root, uživatel dovecot ani uživatel určený pro přístup ke zprávám (např. vmail). Vhodným řešením je založit speciálního uživatele, například dovecot-auth, a toho oprávnit k přístupu k datům. Tento uživatel se pak nastaví v konfiguraci (viz dále).

    Ještě je potřeba dodefinovat, kde má Dovecot hledat schránky a pod jakým uživatelem a skupinou ke zprávám přistupovat (podobně jako v případě Postfixu). Protože Postfix používá jediného uživatele a skupinu, bude nastavení úplně stejné. Tady jsou konfigurační pravidla:

    mail_location = maildir:/var/mail/virtual/%d/%n
    first_valid_uid = 100
    last_valid_uid = 100
    first_valid_gid = 100
    last_valid_gid = 100
    

    Cesta ke schránce se bude tvořit automaticky z uživatelského jména včetně domény (uživatelé se budou přihlašovat celou e-mailovou adresou), to se rozloží na své složky a použije v cestě. Jediným platným identifikátorem pro uživatele i skupinu je 100, tedy například onen uživatel vmail. Nyní už zbývá jen vytvořit soubor s uživatelskými jmény a hesly.

    franta@moje.domena:{plain}nejakeheslo:100:100:::
    tereza@moje.domena:{plain}jineheslo:100:100:::
    postmaster@moje.domena:{plain}dalsiheslo:100:100:::
    petr@jina.domena:{plain}jestejineheslo:100:100:::
    

    Každý řádek obsahuje přihlašovací jméno uživatele (tedy jeho adresu), heslo včetně schématu, UID a GID. Soubor může obsahovat ještě další údaje, například o tom, ze kterých adres je uživateli povolen přístup. Podrobnosti najdete v dokumentaci pro Dovecot. Pokud chcete použít heslo s jiným schématem než PLAIN, můžete využít nástroj dovecotpw, který dokáže generovat hesla ve formátu podle schématu (např. CRAM-MD5 nebo CRYPT).

    To už je v podstatě vše, co je potřeba je zdárnému fungování přístupu ke schránkám. Tady je celý konfigurační soubor pohromadě (včetně základních nastavení z minulého dílu):

    protocols = imap pop3
    
    ssl = no
    disable_plaintext_auth = no
    
    mail_location = maildir:/var/mail/virtual/%d/%n
       first_valid_uid = 100
    last_valid_uid = 100
    first_valid_gid = 100
    last_valid_gid = 100
    
    protocol imap {
      imap_client_workarounds = outlook-idle
    }
    
    protocol pop3 {
      pop3_uidl_format = %08Xu%08Xv
      pop3_client_workarounds = outlook-no-nuls oe-ns-eoh
    }
    
    auth default {
      mechanisms = plain login cram-md5 digest-md5 ntlm
    
      passdb passwd-file {
        args = scheme=plain username_format=%u /etc/dovecot/passwd
      }
    
      userdb passwd-file {
        args = username_format=%u /etc/dovecot/passwd
      }
    
      user = dovecot-auth
    }
    

    V sekci auth default si všimněte, že oproti minulému dílu přibyly další autentizační mechanismy (CRAM-MD5, DIGEST-MD5NTLM; je to množina těch nejčastěji používaných). Lze je bez problémů používat, vzhledem k tomu, jak jsou uložena hesla. Na konci sekce je pak vidět přiřazení uživatele dovecot-auth pro přístup k heslům.

    Autentizace pro odesílání zpráv

    link

    Popsané řešení vyhovuje v situaci, kdy je poštovní server součástí sítě, ze které k němu uživatelé přistupují, a lze tedy rozlišovat oprávněnost odesílání „ven“ podle síťových adres. Jenže často je server někde na Internetu a přístup je potřeba k němu mít odkudkoliv (a současně nedovolit jeho zneužití k rozesílání spamu) – to je třeba typický případ pošty u hostingových služeb. Pak je potřeba zavést ověřování totožnosti uživatelů, kteří chtějí něco poslat mimo daný server.

    Zapnutí kontroly je v zásadě velmi triviální (viz dále), problém ovšem nastává s tím, odkud čerpat data k ověřování. Byl by nesmysl mít dvě samostatné databáze, jednu pro Dovecot a druhou pro Postfix, když by v obou byly totožné údaje a každá změna by se musela promítnout do obou databází.

    Naštěstí to tak být nemusí. Pro ověřování uživatelů se totiž využívá technologie SASL (podle RFC 4422). A Dovecot umí vystupovat jako poskytovatel služeb SASL, takže se jeho databáze využije i pro účely Postfixu. Oba programy se ale musí správně nakonfigurovat.

    Protože poskytování SASL funguje podle modelu klient/server, musí pro fungování autentizace v Postfixu běžet i Dovecot. Pokud nepoběží, nebude možné přes Postfix odesílat zprávy, protože uživatel nepůjde ověřit.

    Dovecot jako poskytovatel SASL

    link

    Dovecot poskytuje autentizační služby prostřednictvím lokálního (unixového) socketu. Ten musí být umístěn tam, kam Postfix vidí (i pokud služba běží v prostředí chroot), a musí mít správně nastavena práva. Může to vypadat přibližně takto:

    auth default {
    
      …
    
      socket listen {
        client {
          path = /var/spool/postfix/private/auth
          mode = 0660
          user = postfix
          group = postfix
        }
      }
    }
    

    Místo oněch tří teček je původní obsah sekce auth default. Parametr path je cesta uvnitř pracovního prostoru programu Postfix, vlastník i skupina souboru bude postfix (pod tímto uživatelem Postfix obvykle běží) a oprávnění bude nastaveno na čtení a zápis pro uživatele i skupinu. To je ze strany programu Dovecot vše, po startu s tímto nastavením bude poskytovat na uvedeném socketu autentizační služby.

    Ověřování uživatelů v Postfixu

    link

    Zbývá nastavit ještě druhou stranu, tedy program Postfix. První je na řadě to, aby program vůbec využíval autentizační služby. Tady je sada konfiguračních parametrů, které se přidají k aktuální konfiguraci v main.cf:

    smtpd_sasl_type = dovecot
    smtpd_sasl_path = private/auth
    smtpd_sasl_auth_enable = yes
    broken_sasl_auth_clients = yes
    

    smtpd_sasl_type říká, jaký typ poskytovatele SASL se bude používat (výchozí je cyrus). V parametru smtpd_sasl_path je obsažena cesta k socketu pro komunikaci (počítá se zde relativně k bázovému adresáři Postfixu; tato hodnota je vhodná i pro prostředí chroot, které se obvykle používá). Využití autentizace je samozřejmě potřeba také zapnout pomocí smtpd_sasl_auth_enable. Poslední nastavení (broken_sasl_auth_clients) se týká podpory „rozbitých“ klientů (např. starší verze programů Microsoft Outlook Express nebo Microsoft Exchange), které vyžadují nestandardní deklaraci autentizačních metod (zapnutí této volby nevypne standardní deklaraci, pouze přidá ještě tu nestandardní).

    Nyní je však ještě potřeba upravit pravidla pro restrikce přístupu tak, aby bylo doručení do místních schránek povoleno odkudkoliv, zatímco odesílání ven jen autentizovaným uživatelům (plus samozřejmě odesílání z vlastní sítě, kterou lze – při umístění serveru volně na Internetu – nastavit na lokální adresy).

    smtpd_recipient_restrictions =
      permit_mynetworks,
      reject_non_fqdn_recipient,
      reject_unknown_recipient_domain,
      check_recipient_access hash:/etc/postfix/access,
      permit_sasl_authenticated,
      reject_unauth_destination,
      permit
    

    Rozdíl je v přidání pravidla permit_sasl_authenticated, které říká, že pokud byl uživatel ověřen pomocí SASL, je mu povoleno odeslání libovolnému příjemci (tedy samozřejmě za předpokladu, že nebyl příjemce odmítnut některým z předchozích pravidel). Na ostatní odesílající klienty se bude vztahovat pravidlo další, tedy reject_unauth_destination, proto budou smět posílat poštu jen adresám, pro které tento server doručuje (viz minulý díl).

    Uživatelé v databázi

    link

    Téměř každý, kdo si vyzkouší popsané řešení založené na souborových seznamech uživatelů, aliasů atd., brzy narazí na limity takového řešení. Spravovat soubory je nepohodlné, musí to dělat vždy administrátor (lze si představit nějaké nástroje pracující nad těmito soubory, ale to je drbání se levou nohou za pravým uchem), při některých operacích se musí sahat hned na čtyři místa.

    Proto je pro i jen trochu větší poštovní server (tedy skoro každý) mnohem výhodnější použít nějaké lepší řešení. Jedním z nich jen využít některou z podporovaných databází. Jak takovou databázi navrhnout, jaké informace do ní dát a jak k ní připojit Postfix a Dovecot, to bude předmětem příštího dílu.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    25.11.2009 08:01 ubuntak
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 6 (virtuální uživatelé)
    Sleduju tento serial od pocatku a opet super. Jen tak dal. Uz se tesim na pokracovani.
    vladky avatar 25.11.2009 17:03 vladky | skóre: 18
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 6 (virtuální uživatelé)
    Suhlasim, je to super serial a vzdy sa neviem dockat dalsieho dielu. Dufam ze sa v niektorej z buducich casti bude riesit aj sposob antispamoveho riesenia.
    Luk avatar 25.11.2009 20:36 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 6 (virtuální uživatelé)
    Dufam ze sa v niektorej z buducich casti bude riesit aj sposob antispamoveho riesenia.
    Ano, ale ještě to bohužel chvilku potrvá.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    25.11.2009 08:52 Honza
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 6 (virtuální uživatelé)

    Toto řešení již bylo kdysi popsáno (v Poštovní server s virtuálními účty trochu jinak). Doufám, že se dočkáme i řešení přes LDAP

    25.11.2009 12:56 Zdeněk Burda | skóre: 61 | blog: Zdendův blog | Praha
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 6 (virtuální uživatelé)
    Něco jako tohle? - namátkou vybraná konfigurace na nějakém nepoužívaném serveru, mělo by to fungovat, ale není to asi zrovna optimální

    dovecot-ldap.conf:

    hosts = localhost
    dn = cn=ldapproxy,dc=domain,dc=tld
    dnpass = tajneheslo
    auth_bind = yes
    auth_bind_userdn = uid=%u,ou=users,o=%d,o=hosting,dc=domain,dc=tld
    ldap_version = 3
    base = o=hosting,dc=domain,dc=tld
    scope = subtree
    user_attrs = mailMessageStore=home,mailQuotaSize=quota=maildir:storage
    user_filter = (&(objectClass=posixAccount)(objectClass=qmailUser)(mail=%u)(employeeType=mail)(description=active))
    pass_attrs = mail=user
    pass_filter = (&(objectClass=posixAccount)(objectClass=qmailUser)(mail=%u)(employeeType=mail)(description=active))
    user_global_uid = 1011
    user_global_gid = 1011
    
    + nastavení postfixu ve stylu:
    domains_server_host = localhost
    domains_search_base = o=hosting,dc=domain,dc=tld
    domains_query_filter = (&(o=%s)(objectClass=organization)(description=active))
    domains_result_attribute = o
    domains_scope = one
    domains_cache = no
    domains_bind = yes
    domains_bind_dn = cn=ldapproxy,dc=domain,dc=tld
    domains_bind_pw = tajneheslo
    domains_version = 3
    
    aliases_server_host = localhost
    aliases_search_base = o=hosting,dc=domain,dc=tld
    aliases_query_filter = (&(objectClass=qmailUser)(mail=%s)(description=active)(employeeType=mail))
    aliases_result_attribute = mailForwardingAddress
    aliases_scope = sub
    aliases_cache = no
    aliases_bind = yes
    aliases_bind_dn = cn=ldapproxy,dc=domain,dc=tld
    aliases_bind_pw = tajneheslo
    aliases_version = 3
    
    accounts_server_host = localhost
    accounts_search_base = o=hosting,dc=domain,dc=tld
    accounts_query_filter = (&(objectClass=qmailUser)(mail=%s)(description=active)(employeeType=mail))
    accounts_result_attribute = mailMessageStore
    accounts_result_format  =  %s/Maildir/
    accounts_scope = sub
    accounts_cache = no
    accounts_bind = yes
    accounts_bind_dn = cn=ldapproxy,dc=domain,dc=tld
    accounts_bind_pw = tajneheslo
    accounts_version = 3
    
    alternate_server_host = localhost
    alternate_search_base = o=hosting,dc=domain,dc=tld
    alternate_query_filter = (&(objectClass=qmailUser)(mailAlternateAddress=%s)(description=active)(employeeType=mail))
    alternate_result_attribute = mailMessageStore
    alternate_result_format  =  %s/Maildir/
    alternate_scope = sub
    alternate_cache = no
    alternate_bind = yes
    alternate_bind_dn = cn=ldapproxy,dc=domain,dc=tld
    alternate_bind_pw = tajneheslo
    alternate_version = 3
    
    dovecot_destination_recipient_limit = 1
    virtual_transport = dovecot
    
    -- Nezdar není hanbou, hanbou je strach z pokusu.
    25.11.2009 16:39 Honza
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 6 (virtuální uživatelé)
    Možná, netušil jsem, že konfigurace je tak dlouhá. Vyzkouším! Přiznám se, že LDAP není můj šálek čaje...
    Luk avatar 25.11.2009 20:35 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 6 (virtuální uživatelé)
    Jak na to tak zběžně koukám, tak by to mohlo fungovat. Článek o využití LDAPu samozřejmě bude (přespříště ;-)).
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    Luk avatar 29.11.2009 22:48 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 6 (virtuální uživatelé)
    Koukl jsem na to znovu a dal to souvislosti s tím, co jsem zjistil v dokumentaci. Přinejmenším pro Dovecot by to zcela jistě nešlo použít (tedy pro verze 1.2 a 1.1), je to konfigurák pro 1.0 a některé parametry jsou již v novějších verzích jiné (a ty staré už to neumí). Postfix je na tom se zpětnou kompatibilitou lépe (přece jen Dovecot 1.0 byl ještě dost neustálený, kdežto Postfix už je tu s námi dlouho), ale ruku do ohně bych za funkčnost nedal.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    pele avatar 25.11.2009 16:58 pele | skóre: 28 | blog: Bleabr | UH
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 6 (virtuální uživatelé)
    Jaky je duvod k tomu, ze virtualni domena nesmi byt stejna jako mydestinations? Daji se pak kombinovat lokalni a virtualni ucty pro stejnou domenu?

    Jinak super clanek, diky za nej.
    Pravda má jednu velkou výhodu: člověk si nemusí pamatovat, co řekl.
    25.11.2009 17:06 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 6 (virtuální uživatelé)
    Je to právě proto, že "lokální" a "virtuální" domény se obsluhují jiným způsobem, řeší to v rámci Postfixu jiná služba. Takže v mydestinations definujete lokální domény a ve virtualdomains definujete virtuální domény. Kombinovat to můžete třeba pomocí aliasů. Důležité je pochopit ten základní princip, ono se to totiž ani moc netýká domén, jako účtů - lokální domény jsou určeny pro systémové účty, pošta se doručuje do "systémového" adresáře pro poštu konkrétního systémového uživatele. Virtuální domény jsou určeny pro virtuální (nesystémové) účty, doručování musí být explicitně nakonfigurováno (je nutné říci, jak z virtuálního účtu získat informace o úložišti e-mailů).
    pele avatar 27.11.2009 08:25 pele | skóre: 28 | blog: Bleabr | UH
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 6 (virtuální uživatelé)
    Diky, muj problem byl v mydestination, jestlize je tato promenna prazdana vse je ok. A posta chodi i na virtualni ucty.
    Pravda má jednu velkou výhodu: člověk si nemusí pamatovat, co řekl.
    29.11.2009 21:43 faha
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 6 (virtuální uživatelé)

    Ulozeni informaci v prostych/hash souborech ma samozdrejme i svuj duvod, krome samozdrejme na prvni pohled horsi udrzovatelnosti (coz lze odbourat pomoci nekoli skriptu), ale prinaseji vyssi vykon zpracovani zprav.

    Ono je sice moc pekne reseni(i na pohled  napr.pro zakaznika) drzet informace o uctech v relacni DB (a to vcetne anti spam/vir reseni, forwardu ...), ale uvedovme si jak je tento proces narocny na DB, prichod jednoho emailu spousti pomerne narocnou proceduru a co teprve v pripade zpracovani i nejakou tu dekadu vetsiho poctu (1ky,10ky, 100ky tisic ), db permanentne pretizena, uzamykani tabulek ... apod. co horsi se muze stat nez, ze to DB nevydrzi a sesype se... problem

    Videl jsem reseni prave na rozsahlych hash-mapach, ktere navic dokazalo rozlozit zatez na vice serveru, informace se skutecne udrzovaly v DB, nikoliv vsak informace nutne pro sluzby, ale info ze ktereho se generovali hash-mapy

    Vyhoda byla v jiz zminene rychlosti, nezavislost na DB (i kdyz se DB zhroutila nic se nedelo, pouze clovek neni schopen pridat/upravit/smazat uzivatel,ale system jede dal), nastroje zajistujici tento chod meli samozdrejme web rozhrani, za kterym sedela "opice".

    Takze bych nezatracoval textove soubory.

    Luk avatar 29.11.2009 23:04 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 6 (virtuální uživatelé)
    Ulozeni informaci v prostych/hash souborech ma samozdrejme i svuj duvod, krome samozdrejme na prvni pohled horsi udrzovatelnosti (coz lze odbourat pomoci nekoli skriptu), ale prinaseji vyssi vykon zpracovani zprav.

    Vyšší výkon přinášet nemusejí, zejména pokud se často mění.
    Ono je sice moc pekne reseni(i na pohled napr.pro zakaznika) drzet informace o uctech v relacni DB (a to vcetne anti spam/vir reseni, forwardu ...), ale uvedovme si jak je tento proces narocny na DB, prichod jednoho emailu spousti pomerne narocnou proceduru a co teprve v pripade zpracovani i nejakou tu dekadu vetsiho poctu (1ky,10ky, 100ky tisic ), db permanentne pretizena, uzamykani tabulek ... apod. co horsi se muze stat nez, ze to DB nevydrzi a sesype se... problem
    Problém to je, pokud se to špatně navrhne a/nebo realizuje. Databází může být více exemplářů (replikují se z jednoho zdroje) na samostatných strojích, ještě s on-line zálohováním (replikací) do geograficky vzdálené lokality. Například. Když něco uhnije, jede se dál. Problém s přetížením vzniká typicky při špatném návrhu DB.
    Videl jsem reseni prave na rozsahlych hash-mapach, ktere navic dokazalo rozlozit zatez na vice serveru, informace se skutecne udrzovaly v DB, nikoliv vsak informace nutne pro sluzby, ale info ze ktereho se generovali hash-mapy
    Jenže pokud se tam dějí změny, musí se to pořád všechno přegenerovávat znovu. I kvůli drobnosti, kdy se v DB updatuje jeden atribut v jediném řádku, se tady musí generovat celý obrovský soubor.
    Takze bych nezatracoval textove soubory.
    Soubory nezatracuji, je vidím jejich místo tam, kde je málo dat a hlavně se málo mění. Pro uložení více dat vidím jako lepší řešení použít databázi.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.