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

[ubuntak]

Sleduju tento serial od pocatku a opet super. Jen tak dal. Uz se tesim na pokracovani.

[vladky]

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]

Dufam ze sa v niektorej z buducich casti bude riesit aj sposob antispamoveho riesenia.

Ano, ale ještě to bohužel chvilku potrvá.

[Honza]

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

[Zdeněk Burda]

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

[Honza]

Možná, netušil jsem, že konfigurace je tak dlouhá. Vyzkouším! Přiznám se, že LDAP není můj šálek čaje...

[Luk]

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ě ).

[Luk]

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.

[pele]

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.

[Filip Jirsák]

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]

Diky, muj problem byl v mydestination, jestlize je tato promenna prazdana vse je ok. A posta chodi i na virtualni ucty.

[faha]

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]

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.