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 01:44 | Zajímavý projekt

Kampaň na podporu chytrého telefonu Librem 5, jenž by měl respektovat bezpečnost, svobodu a soukromí uživatelů, úspěšně skončila. Bylo vybráno více než 2,1 milionu dolarů, tj. cíl kampaně byl splněn na více než 141 %. Objednáno bylo cca 3 000 telefonů. Telefon Librem 5 by měl být k dispozici v lednu 2019.

Ladislav Hagara | Komentářů: 1
včera 21:11 | Komunita

Ke zhlédnutí jsou videozáznamy přednášek z konferencí All Systems Go! (media.ccc.de) a GStreamer Conference 2017 (ubicast.tv) konaných o víkendu 21. a 22. října. All Systems Go! v Berlíně a GStreamer Conference 2017 v Praze.

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

    Stavíme poštovní server – 7 (uživatelé v databázi)

    4. 12. 2009 | Lukáš Jelínek | Sítě | 15336×

    Údaje o e-mailových schránkách a jejich uživatelích lze uchovávat například v souborech (jako v minulém dílu seriálu) nebo v databázi. Právě návrhem takové databáze a jejím využitím v programech Postfix a Dovecot se bude zabývat tento článek.

    Obsah

    Proč použít databázi a jakou zvolit?

    link

    Ukládání libovolných informací do souborů je jednoduché. Prostě se něco někam napíše a je to tam. Takto lze u poštovního serveru spravovat schránky a aliasy, zejména je-li jich jen tolik, že je lze spočítat na prstech jedné ruky. „Legrace“ nastává, pokud je schránek či aliasů trochu více (to trochu mohou být už desítky, ale servery běžně mívají stovky, tisíce nebo desetitisíce poštovních schránek) – spravovat něco takového ručně editací souborů je práce vysloveně za trest, nehledě na značné riziko vzniku chyb.

    To ale samozřejmě není vše. Často je potřeba, aby každou doménu mohl spravovat někdo jiný, aby si každý uživatel mohl sám změnit heslo nebo aby šlo toto všechno provádět přes nějaké snadno ovladatelné webové rozhraní. Ano, dalo by se něco takového realizovat i nad soubory, ale proč? Proč, když existují databáze?

    Jak Postfix, tak Dovecot umožňují získávat potřebné informace (o schránkách a jejich umístění, o uživatelích, heslech atd.) z různých databází, podle toho, jak jsou programy zkompilovány. To ale teď není až tak důležité. Důležitější je, co všechno použití databáze přináší:

    • strukturované uložení informací
    • možnost využít stejná data pro různé účely (a přizpůsobit tomu strukturu databáze)
    • nastavování oprávnění přístupu podle potřeby
    • možnost snadno aktivovat/deaktivovat schránky nebo aliasy
    • snadná správa uložených dat (speciálními i obecnými nástroji)

    Hlavní výhodou je, že se data v databázi strukturují podle svého určení a není třeba, aby byla redundantní. Například informace o doménách se ukládají jen jednou (takže změna domény znamená změnu jedné položky). Databázi pro poštu lze sloučit s databází pro jiné účely (resp. mít jednu velkou databázi), například pro všechny služby v rámci hostingu.

    Pokud to zvolený databázový systém umožňuje, lze přesně ovládat přístup k datům. Proto může mít například Postfix přístup jen k tomu, co nezbytně potřebuje (což jsou informace o schránkách, ale už ne třeba o heslech). Výkonnost řešení (rychlost přístupu k datům, zátěž systému) záleží samozřejmě na různých faktorech, včetně návrhu databáze, který je vždy kompromisem mezi rychlostí a jinými požadavky (omezení redundance dat, integrita, konzistence, propojení s jinými daty atd.).

    Aktivace či deaktivace schránky, aliasu nebo třeba celé domény je otázkou změny jediné hodnoty v databázi. Nad daty lze pracovat nástroji k tomuto účelu vytvořenými (například administrační centrum hostingu), ale stejně tak i přes databázové konzole pomocí SQL příkazů.

    Všude, kde se v tomto článku hovoří o uživatelích, se jedná vždy o virtuální uživatele, není-li explicitně uvedeno něco jiného.

    Volba databáze

    link

    Má-li jedna databáze sloužit jak pro Postfix, tak pro Dovecot, máme v současné době na výběr dvě: MySQLPostgreSQL. Dovecot samotný zvládá ještě SQLite. Který ze dvou uvedených databázových systémů použít, to už záleží na dalších okolnostech – například na tom, zda se budou data sdílet ještě s něčím dalším (co vyžaduje konkrétní databázi) nebo prostě která databáze bude instalována ještě z nějakého dalšího důvodu. Obecně by se našly důvody pro jednu či druhou databázi a není smyslem tohoto článku posuzovat kvality databázových systémů.

    Příklady v celém článku budou připraveny pro databázi MySQL (konkrétně pro verzi 5.0), nicméně modifikace pro PostgreSQL není nic obtížného. Napojení databází na poštovní programy je v obou případech v zásadě stejné.

    link

    Při přípravě databáze pro poštovní server je potřeba si nejprve ujasnit, které informace se vůbec budou uchovávat a v jaké struktuře. Může to vypadat třeba takto:

    • doména (název, stav)
    • schránka (uživatel, doména, heslo, stav)
    • alias (uživatel, doména, cíl, stav)

    Požadavky jsou vskutku minimální, protože se řeší opravdu jen to, co je nezbytné pro fungování poštovního systému. Návrh vychází z toho, že umístění schránek v úložišti je pevně dáno doménou a uživatelem, že se používají pevné hodnoty UID a GID a že se neřeší žádné uživatelské kvóty ani jiné speciality.

    Takto abstraktně definovanou databázi je teď potřeba přetavit v konkrétní SQL kód, v tomto případě pro databázi MySQL.

    Databázové tabulky

    link

    Výše definovaná trojice souborů dat se tedy nyní stane třemi tabulkami. Budou definovány pro engine InnoDB, takže pak půjde využít veškerý komfort včetně cizích klíčů a transakcí. Pokud někdo upřednostňuje rychlost, může zvolit engine MyISAM, ale musí se postarat o náhradu chybějící funkcionality.

    CREATE TABLE Domains
    (
    dom_id INTEGER AUTO_INCREMENT,
    dom_name VARCHAR(100) NOT NULL UNIQUE,
    dom_enabled BOOL NOT NULL DEFAULT 1,
    PRIMARY KEY (dom_id)
    )
    ENGINE=InnoDB;
    
    CREATE TABLE Mailboxes
    (
    mb_id INTEGER AUTO_INCREMENT,
    dom_id INTEGER NOT NULL,
    mb_user VARCHAR(100) NOT NULL,
    mb_password VARCHAR(100) NOT NULL,
    mb_enabled BOOL NOT NULL DEFAULT 1,
    PRIMARY KEY (mb_id),
    FOREIGN KEY (dom_id) REFERENCES Domains (dom_id) ON DELETE CASCADE ON UPDATE CASCADE,
    UNIQUE INDEX (dom_id, mb_user)
    )
    ENGINE=InnoDB;
    
    CREATE TABLE Aliases
    (
    al_id INTEGER AUTO_INCREMENT,
    dom_id INTEGER NOT NULL,
    al_user VARCHAR(100) NOT NULL,
    al_target VARCHAR(100) NOT NULL,
    al_enabled BOOL NOT NULL DEFAULT 1,
    PRIMARY KEY (al_id),
    FOREIGN KEY (dom_id) REFERENCES Domains (dom_id) ON DELETE CASCADE ON UPDATE CASCADE,
    UNIQUE INDEX (dom_id, al_user)
    )
    ENGINE=InnoDB;
    

    Tabulka Domains definuje pouze domény s unikátními názvy a jejich stav (aktivní ano/ne). Zbývající dvě tabulky už jsou zajímavější a jsou hodně podobné. Obsahují cizí klíč do tabulky domén (přes který se spojují záznamy a také zajišťuje referenční integrita – smazání domény bude mít za následek smazání všech schránek a aliasů v dané doméně) a také kombinovaný unikátní index přes identifikátor domény a jméno uživatele. Je to proto, že rozhodující pro vyhledávání je právě tato kombinace (která se nesmí v databázi opakovat), ne samotný uživatel. Tabulka aliasů je vytvořena pro směrování na obecné cíle, tedy bez ohledu na to, zda jdou zprávy na některou z místních schránek nebo ven.

    Uvedené řešení není ani nejrychlejší, ani úplně čisté. Lze ho považovat ze relativně jednoduchý kompromis mezi rychlostí a ostatními požadavky. Návrh je cílen čistě na MySQL a využívá některé implicitní vlastnosti (např. ty, které zde vyplývají z definice atributu jakožto primárního klíče) – pro jiné databáze by bylo potřeba SQL kód přizpůsobit.

    Oprávnění databázových uživatelů

    link

    Nyní přichází další důležitý krok. Je potřeba definovat oprávnění tak, aby každý z programů přistupoval jen k tomu, co potřebuje. Proto databázový uživatel postfix bude mít přístup jen k informacím důležitým pro doručování (čili ne k heslům), zatímco uživatel dovecot zase jen k autentizačním údajům (tedy ne k aliasům). Takto by vypadaly příslušné příkazy:

    GRANT SELECT ON Domains TO 'postfix'@'localhost' IDENTIFIED BY 'heslopropostfix';
    GRANT SELECT (mb_id, dom_id, mb_user, mb_enabled) ON Mailboxes TO 'postfix'@'localhost';
    GRANT SELECT (al_id, dom_id, al_user, al_target, al_enabled) ON Aliases TO 'postfix'@'localhost';
    
    GRANT SELECT ON Domains TO 'dovecot'@'localhost' IDENTIFIED BY 'hesloprodovecot';
    GRANT SELECT (mb_id, dom_id, mb_user, mb_password, mb_enabled) ON Mailboxes TO 'dovecot'@'localhost';
    

    Vždy první z příkazů v každé skupině nastavuje heslo pro příslušného uživatele. Toto heslo se použije pro autentizaci uživatele při připojení k databázi. Tento první příkaz také nastavuje uživatelům právo získávat data ze všech sloupců tabulky Domains. Zbývající příkazy se týkají ostatních tabulek. Všimněte si, že příkaz pro Postfix k tabulce Mailboxes neposkytuje oprávnění získávat uživatelská hesla (Postfix je nepotřebuje) a že pro Dovecot zde naopak není příkaz poskytující práva k aliasům (ty totiž nepotřebuje zase Dovecot).

    Ostatním databázovým uživatelům nastavte práva dle potřeby. Zásadou samozřejmě je, aby byla nastavena nejmenší možná práva, se kterými si uživatel při své činnosti vystačí.

    Aby šlo s databází něco zkoušet, je samozřejmě potřeba, aby byla naplněna daty. Při experimentech lze využít například nástroje jako phpMyAdmin, případně konzolového klienta. Pokud využijete druhý přístup, můžete vkládat data pomocí SQL příkazů, jako jsou tyto:

    INSERT INTO Domains SET dom_name='moje.domena';
    
    INSERT INTO Mailboxes SET dom_id=1, mb_user='franta', mb_password='nejakeheslo';
    INSERT INTO Mailboxes SET dom_id=1, mb_user='tereza', mb_password='jineheslo';
    
    INSERT INTO Aliases SET dom_id=1, al_user='postmaster', al_target='franta@moje.domena';
    

    Při vkládání můžete samozřejmě využít vícenásobný INSERT a jiná vylepšení. Výše uvedené příkazy ukazují jen princip vkládání, a to za předpokladu, že se po vložení domény do tabulky Domains hodnota syntetického klíče dom_id nastavila na hodnotu 1 (což platí při prvním vkládání do prázdné tabulky; obecně je potřeba si skutečnou hodnotu zjistit dotazem). Při využití enginu InnoDB může být celé vkládání provedeno v jediné transakci (pomocí START TRANSACTIONCOMMIT), takže pokud se během vkládání přijde na to, že je někde něco špatně, lze pomocí ROLLBACK všechno snadno vrátit do původního stavu.

           

    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ář

    4.12.2009 06:54 Lampa
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 7 (uživatelé v databázi)
    hmm a jak vidim taky neresi, ze prednost ma alias pred mailboxem(kdy bude v tabulce aliasu stejne jmeno jako v mailboxech), alias domeny; co se tyce dovecotu neni lepsi pouzit prefetch a vratit vse v jednom dotazu nez delat 2 dotazy ?
    Luk avatar 4.12.2009 13:49 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 7 (uživatelé v databázi)
    hmm a jak vidim taky neresi, ze prednost ma alias pred mailboxem(kdy bude v tabulce aliasu stejne jmeno jako v mailboxech)
    To lze řešit buď na aplikační úrovni (aplikace pracující nad databází nedovolí, aby bylo jmeno v obou tabulkach), nebo rozštěpením DB relací s vytvořením další tabulky, čímž se to zajistí na databázové úrovni (to je čistší, ale sežere to víc výkonu).
    co se tyce dovecotu neni lepsi pouzit prefetch a vratit vse v jednom dotazu nez delat 2 dotazy
    V tomto případě ano, protože se v dotazu na uživatele netahají žádné doplňkové informace. Mám v plánu uvést tyto optimalizace pohromadě později v samostatném článku.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    7.12.2009 06:43 Lampa
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 7 (uživatelé v databázi)
    uvidime, jak rekl slepy, co bude dal

    preposilani mailu s lokalni kopii, je taky velice zadana vec
    4.12.2009 07:50 Martin22
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 7 (uživatelé v databázi)
    A proc pouzivat innodb a ne myisam ?
    4.12.2009 07:55 Lampa
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 7 (uživatelé v databázi)
    myisam nema podporu foreign key a transakci, na kterych je to zalozeno
    Luk avatar 4.12.2009 13:51 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 7 (uživatelé v databázi)
    Přesně, také to v článku říkám. Možná to není dostatečně srozumitelné, pak je to asi moje chyba, měl bych používat lepší formulace ;-)
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    4.12.2009 21:44 Kvakor
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 7 (uživatelé v databázi)
    U popisu řešení tabulek se píše, že InnoDb je kompromis mezi rychlostí a jednoduchostí. Osobně bych se nejspíš rozhodoval podle toho, jak často je databáze upravována a jak moc je zatížený poštovní a databázový server. Při větším množstí úprav je výhodnější InnoDb (díky podpoře transakcí a cizích klíčů), ale pokud je změn málo, provoz velký a databázový server málo výkonný (např. je to původně router nebo NAS s alternativním "firmwarem"), nejspíš by byly MyISAM tabulky výhodnější - transakce nemají u téměř read-only dat smysl, cizí klíč jde celkem snadno odemulovat použitím několika SQL příkazů a při neexcistenci více domén ho není třeba.
    8.12.2009 07:37 Luboz
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 7 (uživatelé v databázi)
    Dakujem za clanok, zaujimave citanie. Uz sa ale tesim na pokracovanie, nakolko skor alebo neskor ma caka tiez prechod z lokalnych userov na Active Directory... Poprosim teda sa zmienit aj o AD v nasledujucom clanku, ak je to mozne... Dakujem
    Luk avatar 8.12.2009 12:20 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 7 (uživatelé v databázi)
    Vzhledem k tomu, že příští článek už je nějakou dobu napsán, tak už do něj těžko zasáhnu ;-) Nějaké zmínky o AD tam samozřejmě jsou, nicméně již dopředu říkám, že praktické zkušenosti s využitím AD pro tyto účely nemám (pouze s OpenLDAP a s Apache Directory Serverem), takže v tomto bohužel nemohu sloužit.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    16.8.2010 19:41 Tom@T
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 7 (uživatelé v databázi)
    Ahoj, potreboval bych mensi radu, dle navodu az sem vse rozchodil, problem mi nastal pri vyuziti mysql. Postupoval jsem podle instrukci, ale nepodarilo se mi spojit s databazi.

    /var/log/mail.log ,hlasi po restartu dovecotu:
    Aug 16 19:34:32 queeg dovecot: Dovecot v1.0.15 starting up
    Aug 16 19:34:33 queeg dovecot: auth(default): Error in configuration file /etc/dovecot/mysql.conf line 6: Expecting '='
    Aug 16 19:34:33 queeg dovecot: Auth process died too early - shutting down
    Aug 16 19:34:33 queeg dovecot: child 3661 (auth) returned error 89

    soubor mysql.conf mam prepsany spravne - nekolikrat zkontrolovano, nikde jsem nenasel kde by chyba mohla byt, MYSQL na urovni prikazu neumim. Na uveden radku 6 je:

    FROM Mailboxes NATURAL JOIN Domains \

    Pokud mate nekdo nejaky tip tak moc diky
    26.8.2010 10:03 Tom@T
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 7 (uživatelé v databázi)
    takze to musi byt v jedinem radku bez /
    10.10.2010 15:14 depka | skóre: 20 | blog: eterity
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 7 (uživatelé v databázi)
    neni zde unikatni klic v tabulce aliasu na skodu? neumozni mi pak replikovat email na vice aliasu?
    8.7.2011 13:39 Jaroslav
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 7 (uživatelé v databázi)
    Nedaří se mi docílit přeposílání KOPIE emailu. Uživatelé jsou v databázi, přesně jak je tu popsáno. Mám existující uživatele jednicka@domena.cz a dvojka@domena.cz. Chci aby mail který dostala jednička byl okopírován dvojce.

    Do Aliases dám:
    al_user = jednicka
    al_target = jednicka@domena.cz, dvojka@domena.cz

    Výsledkem je, že jednička email správně dostane, ale dvojka dostane 2 kopie. Je to logické, ale dočetl jsem se, že "Postfix is smart enough to not get into a loop". Zjevně to tak není. Věděl by prosím někdo, jak dosáhnout toho, aby oba dostali stejný mail jen jednou?
    8.7.2011 14:45 Jaroslav
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 7 (uživatelé v databázi)
    Ještě to doplním: stejné chování při použití recipient_bcc_maps. Zdá se, že to má něco společného s nastaveními pro amavis: receive_override_options=no_address_mappings.

    Založit nové vláknoNahoru

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