Portál AbcLinuxu, 19. dubna 2024 08:42
Ú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.
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áší:
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.
Má-li jedna databáze sloužit jak pro Postfix, tak pro Dovecot, máme v současné době na výběr dvě: MySQL a PostgreSQL. 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é.
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:
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.
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.
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 TRANSACTION a COMMIT), 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.
Jestliže je databáze vytvořena a jsou v ní připravena nějaká data, lze přejít k propojení programů s databázovým serverem. Propojení spočívá v nakonfigurování programů a v definici dotazů, kterými se budou z databáze získávat data. První přijde na řadu program Postfix.
Úprava konfigurace oproti té minulé je velmi jednoduchá. Spočívá ve třech parametrech, z nichž každý nastaví datový zdroj (zde databázi) pro jednu konkrétní oblast:
virtual_mailbox_domains = mysql:/etc/postfix/mysql/vdomains.cf virtual_mailbox_maps = mysql:/etc/postfix/mysql/vmailbox.cf virtual_alias_maps = mysql:/etc/postfix/mysql/virtual.cf
Uvedení mysql: říká, že se jako zdroj použije databáze MySQL. Cesta, která za tím následuje, je k souboru se všemi údaji, které jsou potřebné pro provedení dotazu. Nyní je však potřeba vyřešit jeden problém – jak se k databázi připojovat. Většina služeb Postfixu totiž běží v prostředí chroot, což znamená, že nemají přístup k lokálnímu socketu MySQL serveru, přes který se komunikuje. Řešení je v zásadě čtvero:
rewrite) zrušit chrootproxymap, která má standardně přístup kamkoliv Každý ze způsobů má určité nevýhody. Internetový socket má o něco větší režii než unixový. Přesun socketu znamená přenastavit i všechny klienty, pro které má být k MySQL serveru povolen přístup tímto způsobem. Zrušení chroot o něco sníží bezpečnost. A konečně použití proxymap znamená opět režii navíc (ovšem někdy je tomu právě naopak, viz dále).
Pro který způsob se rozhodnout? Při malé zátěži lze bez problémů využívat internetový socket, u zatížených poštovních serverů je však mnohem výhodnější nasadit službu proxymap, protože nejen že vyřeší problém s přístupem, ale současně zredukuje počet souběžných připojení na databázový server, který by jinak zbytečně požíral systémové prostředky a případně i zabránil obsloužení některých klientů.
Každý ze souborů má následující formát (toto je příklad souboru vdomains.cf, tedy pro zjišťování domén):
hosts = 127.0.0.1 user = postfix password = heslopropostfix dbname = mail query = SELECT 1 FROM Domains WHERE dom_name='%s' AND dom_enabled=1
To je celé. První čtyři řádky obsahují údaje pro připojení k databázi (zde je databáze nazvána mail) a budou se opakovat i pro všechny ostatní dotazy v rámci programu Postfix. Nejzajímavější je ale poslední řádek, tedy samotný dotaz. Vzhledem k tomu, že se zde zjišťuje pouze existence domény v tabulce, jde pouze o to, zda dotaz vrátí nějakou odpověď nebo prázdnou množinu.
Hodnota %s zde reprezentuje dotazovaný klíč, tedy konkrétně hledanou doménu. Je-li nalezena (a musí být i aktivní, zapnutá), dotaz vrátí zpět číslo 1. Není to kritické – je totiž prakticky jedno, co vrátí, může to být klidně třeba i původní řetězec apod. Pro soubor vmailbox.cf by dotaz vypadal takto (první tři řádky souboru jsou stejné jako u souboru vdomains.cf):
Pokud se neuvede umístění databáze (hosts), Postfix využije výchozí nastavení, což však obvykle nebude fungovat kvůli prostředí chroot. Pro vzdálenou databázi (nebo místní v explicitním nastavení), je potřeba uvést parametr hosts a nastavit mu jednu či více (budou zkoušeny v náhodném pořadí) adres. Lze uvádět i cesty k unixovým socketů (s prefixem unix:). Pozor – pokud uvedete localhost, Postfix se vždy připojí přes unixový socket! Pro místní připojení přes internetový socket se musí adresa uvést číselně (127.0.0.1).
query = SELECT CONCAT(dom_name, '/', mb_user, '/') FROM Mailboxes NATURAL JOIN Domains WHERE mb_enabled=1 AND dom_enabled=1 AND mb_user='%u' AND dom_name='%d'
Tady už to vypadá trochu složitěji. Jediné, co dotaz vrací, je cesta ke schránce typu Maildir, čili něco jako doména/uživatel/ (na názvu sloupce nezáleží). Cesta je získána spojením domény a uživatelského jména, a to jen v případě, že je jak doména, tak i schránka aktivní. Parametry %u a %d znamenají uživatelské jméno z adresy, resp. doménu (klíč jde jako celá adresa, tu lze získat pomocí %s; uvedené dva symboly tento klíč rozdělí na samostatné části). Velmi podobně vypadá i dotaz pro aliasy, tedy v souboru virtual.cf:
query = SELECT al_target FROM Aliases NATURAL JOIN Domains WHERE al_enabled=1 AND dom_enabled=1 AND al_user='%u' AND dom_name='%d'
Dotaz dělá skoro totéž jako ten předchozí, tedy zde vrací cílovou adresu aliasu, jsou-li alias i doména aktivní. Nic dalšího už není potřeba nastavovat, toto všechno plně postačuje k tomu, aby Postfix správně doručoval podle hodnot v databázi.
Pokud budete chtít pro komunikaci s databází využít zmíněné řešení s využitím služby proxymap, je potřeba pozměnit konfiguraci Postfixu takto (jde v podstatě jen o přidání proxy: před každou hodnotu):
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql/vdomains.cf virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql/vmailbox.cf virtual_alias_maps = proxy:mysql:/etc/postfix/mysql/virtual.cf
Hodnota hosts v souborech se pak pro místní MySQL server nemusí vůbec definovat (nebo se nadefinuje jako localhost), služba proxymap se bude připojovat přes unixový socket. Pro základní funkčnost není třeba využívat toto řešení u služby local (tedy parametr virtual_mailbox_maps), ale protože proxymap řeší i problém s počtem souběžných připojení k databázi, je výhodnější stejným způsobem nastavit všechno.
Pozor na nastavení práv k uvedeným třem souborům. Přístup ke čtení smí mít jen uživatel postfix (přístup k zápisu nepotřebuje). Sice v tomto případě nelze přes přístup Postfixu získat příliš citlivé informace (není přístup k heslům uživatelů a hlavně nelze v databázi nic měnit), nicméně například u aliasy mají určitou citlivost a přístup k nim by neměl mít každý.
U programu Dovecot to bude velmi podobné, i když bude vše mít poněkud jinou syntaxi. Opět je potřeba upravit konfiguraci a vytvořit (v tomto případě jen dva) databázové dotazy. V konfiguračním souboru dovecot.conf se nastaví:
auth default {
mechanisms = plain login cram-md5 digest-md5 ntlm
passdb sql {
args = /etc/dovecot/mysql.conf
}
userdb sql {
args = /etc/dovecot/mysql.conf
}
user = dovecot-auth
socket listen {
client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix
}
}
}
Mechanismy a SASL socket (pro účely autentizace v programu Postfix) zůstávají stejné jako minule, mění se však zdroj hesel i uživatelů. V obou případech se nastaví stejný konfigurační soubor mysql.conf pro práci s databází (šel by samozřejmě nastavit pokaždé jiný). V tomto souboru bude vše potřebné pro získávání údajů z databáze:
default_pass_scheme = PLAIN driver = mysql connect = host=/var/run/mysqld/mysqld.sock dbname=mail user=dovecot password=hesloprodovecot password_query = SELECT mb_password AS password, '%u' AS user \ FROM Mailboxes NATURAL JOIN Domains \ WHERE mb_enabled=1 AND dom_enabled=1 AND mb_user='%n' AND dom_name='%d' user_query = SELECT 100 AS uid, 100 AS gid, '/var/mail/virtual/%d/%n' AS home \ FROM Mailboxes NATURAL JOIN Domains \ WHERE mb_enabled=1 AND dom_enabled=1 AND mb_user='%n' AND dom_name='%d'
Parametr default_pass_scheme říká, jaké je výchozí schéma uložení hesel (viz minulý článek), zde PLAIN. driver je označení databázového ovladače (mysql). Parametr connect uvádí vše potřebné pro připojení k databázi, zde tedy cestu k unixovému socketu, název databáze, uživatelské jméno a heslo.
Dále už jsou tu vlastní dotazy. Zde je to trochu jiné než u Postfixu. Vracených hodnot je víc a záleží na jejich pojmenování, proto se provádí aliasing. %n zde má stejný význam jako %u u Postfixu, tedy jméno uživatele, zatímco zde %u znamená uživatele včetně domény. V dotazu na uživatele se UID a GID vrací jako pevné hodnoty, cesta ke schránce je také v podstatě pevná, protože je sestavena před odesláním dotazu do databáze. Dotaz jako takový tedy vlastně jen testuje existenci schránky a to, zda je schránka a doména aktivní.
Opět pozor na nastavení práv k souboru. Měl by ho mít oprávnění číst jen uživatel dovecot-auth. Dostanou-li se k obsahu souboru běžní uživatelé, mohou zjišťovat hesla k poštovním schánkám, tedy velmi citlivé informace.
Po provedení všech popsaných úkonů by měl server (samozřejmě po načtení nových konfigurací) kompletně fungovat s údaji z databáze. Jedná se skoro o minimum, co lze prostřednictvím databáze provozovat, možnosti jsou mnohem širší, záleží na konkrétních potřebách a cílech.
Nasazení databáze přináší mnoho výhod, ne vždy je to však to nejlepší řešení. Například ve firemním prostředí bývají uživatelé soustředěni v centrální databázi přístupné protokolem LDAP (konkrétních implementací je řada – například OpenLDAP, Apache Directory Server, Novell eDirectory, Lotus Domino, Active Directory a mnoho dalších). Pak je zbytečné mít ještě nějakou samostatnou databázi pro poštu, potřebné údaje lze získávat pomocí LDAP.
LDAP patří mezi technologie, které není až tak úplně jednoduché zkrotit (nebo se to nich alespoň říká), proto mohou existovat určité obavy ohledně správného nastavení poštovního serveru, aby LDAP využíval. Že to tak děsivé není, se ukáže v příštím dílu seriálu.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.